1.1 大模型服务和传统 Web 服务到底差在哪

1.1 大模型服务和传统 Web 服务到底差在哪

我第一次被拉去救火一个"大模型对话产品大促崩了"的现场，是在两年前。当时的架构师很委屈——他们按经典 Web 的高并发套路把网关、负载均衡、无状态服务都搭得很标准，压测时单接口能扛 80 万 QPS，以为稳了。结果大促开场十分钟，TTFT（首字延迟）从 800ms 飙到 12 秒，GPU 集群显存接连 OOM，整个对话服务事实上瘫痪。复盘时大家才发现：他们压测的那个 80 万 QPS，和真实大模型对话的 80 万 QPS，根本不是同一个东西。

这一节我不想讲什么"高并发架构总论"，而是要把"高并发大模型服务"这个词彻底拆开——它到底指什么、和传统 Web 高并发差在哪、为什么照搬 Web 套路必崩。只有把这些口径校准了，后面所有章节的方案你才知道它在解决什么问题。

先把"QPS"这个词掰开：三个口径，混用就翻车

绝大多数容量误判，根子都在 QPS 口径混乱。大模型服务场景里，至少有三个完全不同的 QPS 口径，它们数量级能差几十倍：

连接层 QPS（Connect QPS），指每秒新建立的 TCP/HTTP 连接数。大模型对话大量用 WebSocket、SSE、HTTP/2 长流，一条连接建立后能挂几十秒到几分钟传流式 token。所以连接层 QPS 往往远低于传统短连接 Web——因为大量请求是在已有连接上多路复用，而不是每次新建。

业务层 QPS（Request QPS），指每秒用户发起的"一轮对话"请求数。这是产品同学嘴里的 QPS，也是计费、风控、限流最关心的。但这个数字离"GPU 要干多少活"还差着十万八千里。

推理层 QPS，这才是真正决定 GPU 成本和调度的口径。它通常更精确地用两个指标衡量：每秒完成的请求数（Requests/s），以及每秒生成的 token 数（Tokens/s）。同样 1 个业务请求，上下文 500 token 和上下文 8000 token，推理负载差十几倍。

我上面那个救火案例，压测时 80 万 QPS 是拿短连接 HTTP 打一个返回 "ok" 的空接口——连接层和业务层都到了 80 万，但推理层是 0（根本没调模型）。真实场景下，80 万业务 QPS 的推理负载，可能需要数千张 A100 才扛得住。用业务 QPS 去买 GPU，是新手最贵的一个错误，没有之一。

从今天起，你在任何方案评审里听到"我们要扛高并发"，第一反应都该是反问一句：你说的百万，是连接层、业务层、还是推理层？ 问不清楚的，方案一律打回。

大模型对话的三个"反 Web 直觉"

为什么经典 Web 那套"无状态 + 水平扩容 + 负载均衡"的金科玉律，原样搬到大模型对话上会崩？因为大模型对话有三个跟经典 Web 截然相反的特性，每一个都会把某个 Web 时代的最佳实践变成陷阱。

请求不是"短平快"，是"长流重"

经典 Web 请求的生命周期通常几十毫秒：读个缓存、查条 SQL、返回几百字节 JSON、连接关闭。整个连接在网关上驻留的时间极短，所以网关的并发模型是"高吞吐短连接"——同一台机器一秒能处理几万个这样的请求。

大模型对话完全是另一个物种。一次流式对话请求，从用户发送、到首字吐出、到流式输出结束，整条连接可能被占用 5 秒到 60 秒。这意味着：

• 同样的并发连接数，大模型对话的"连接驻留时间"是经典 Web 的几百倍。经典 Web 一台机器扛 1 万并发连接很轻松（因为每个连接只占几十毫秒），大模型对话同样 1 万并发连接，可能意味着 1 万条连接同时在流式推送 token，每条都要持续占用内存和带宽。
• 网关的超时配置、缓冲策略、连接复用逻辑全部要重写。Nginx 默认的 proxy_read_timeout 60s 在经典 Web 够用，在大模型对话里会直接掐断 2 分钟以上的长对话——用户的回答传到一半连接就没了，比直接报错还糟。
• proxy_buffering on 这个经典 Web 的默认优化，在流式场景是个性能杀手。它会让网关把上游响应缓冲完整再转发，结果用户看到的不是流式打字机效果，而是等了几十秒后一次性蹦出全部内容。必须显式 proxy_buffering off。

计算极重，而且延迟敏感

经典 Web 请求背后，往往是一次 DB 查询或缓存命中，CPU 消耗几乎可以忽略，单机扛几万 QPS 不在话下。大模型对话的每次请求背后是一次完整的大模型推理——这是真正"算力密集"的负载。

具体有多重？一个 70B 参数的模型，FP16 权重就 140GB，一次 prefill（预填充上下文）要跑整个 prompt 过一遍网络，decode（生成）阶段每生成一个 token 都要搬运这 140GB 的权重一遍。一个高并发大模型对话平台，GPU 集群的成本占整体 TCO 的 60% 到 80% 是常态。而经典 Web 里，计算成本通常只占很小的比例，大头在带宽和存储。

更麻烦的是延迟敏感。经典 Web 里一个请求慢 200ms 用户基本无感；大模型对话里 TTFT（首字延迟）从 500ms 涨到 2 秒，用户就会明显觉得"卡"，转化率直接下降。所以大模型对话的架构优化目标不是单纯的"高吞吐"，而是"高吞吐 + 低 TTFT"的双重约束，这两个目标很多时候是冲突的（比如批量越大吞吐越高，但单个请求的 TTFT 也越高）。

状态性强，上下文是命脉

经典 Web 的圣杯是"无状态"——请求之间互不依赖，任何一台机器都能处理任何请求，坏了直接摘掉换一台。这让水平扩容极其简单。

大模型对话是强状态性的。一次对话依赖会话上下文：历史消息、系统提示词、用户画像、上一轮工具调用的中间结果。这个上下文既影响推理成本（上下文越长，KV Cache 越大，prefill 越慢），又影响路由策略（同一个会话最好落到持有其上下文和 KV Cache 的节点，否则要么重新算一遍 prefill 浪费算力，要么中间状态对不上答非所问）。

我见过一个团队把推理服务做成完全无状态、前面挂个轮询负载均衡，结果同一会话连续两轮被打到两台不同机器，第二台要把整个上下文重新 prefill 一遍——KV Cache 完全没复用，prefill 成本翻倍，TTFT 直接翻倍。更糟的是某些依赖服务端会话状态的 Agent 功能，轮询分发后状态错乱，开始答非所问。这个反模式我们在 1.3 节会详细拆，这里先记住一个结论：把大模型对话的推理层当无状态服务，等于把"状态"这个最关键的因子扔给了随机数生成器。

一张图把"大模型服务"立起来

为了后面所有章节有共同语言，我们把一个高并发大模型服务抽象成四层。这张图后面会反复出现，请花一分钟记住它：

接入网关层是所有流量的第一站，负责长连接卸载（TLS 终止、四层负载）、七层路由转换、限流熔断、鉴权。这是第二章的主角，也是百万长连接会不会把入口压垮的第一道生死线。

对话编排层是引擎的大脑，负责把请求路由到正确的会话、组装上下文、决定调哪个模型、协调 Agent 多轮调用、把结果流式吐回。第四章的主角，决定每个请求如何被最优地服务。

模型推理集群是算力的肌肉，一组 GPU 节点跑 vLLM 或 TGI，按显存预算和调度策略吞吐请求。这一层是本系列另一本《vLLM 高并发部署》的主场，本书只在外部接口层面跟它打交道。

上下文与缓存层是降本的杠杆，管理会话历史压缩、KV Cache 复用、语义缓存。第三章的主角，也是高并发平台能不能打平成本的胜负手——缓存命中率每提升 10 个百分点，推理算力成本大约能降 8% 到 10%。

高并发到底"难"在哪：三道关口

把这四层立起来之后，"高并发难在哪"就有了具体答案——难在三道关口，每一道对应一层架构：

关口一：百万长连接怎么不把网关压垮。 百万业务 QPS 在流式长连接语义下，意味着可能同时有数百万条活跃连接挂着，每条都在持续推 token。传统 Web 的短连接网关扛不住这种"连接驻留"。第二章会拆四层卸载、连接池复用、背压的分层打法。

关口二：重计算怎么不被排队拖垮延迟。 高并发的推理请求涌向有限的 GPU，调度不当就在推理队列里排成长龙，TTFT 飙升。第四章的多模型分流、Agent 重请求隔离、优先级调度就是解这个。

关口三：上下文和成本怎么不被规模压垮。 高并发乘上每次请求的长上下文，等于海量 KV Cache 和历史存储。不做压缩和缓存，显存和算力成本指数级膨胀，平台直接亏损。第三章的语义缓存和上下文压缩，是这条关口能不能守住的关键。

这三道关口，本质对应的是大模型对话的"长连接、重计算、强状态"三个特性——这正是一开始说的"反 Web 直觉"的三条主线。后面整本书的方案，都是围绕这三道关口展开的。

这一节之后你该带走的判断力

读完这一节，我希望你在白板上能给别人讲清楚三件事：第一，大模型对话的 QPS 有连接层、业务层、推理层三个口径，用错口径买 GPU 是最贵的错误；第二，大模型对话的长连接、重计算、强状态三个特性，是怎么让经典 Web 套路失效的；第三，一个高并发大模型服务的四层抽象和三道关口分别是什么。

下一节 1.2，我们把"高并发"和"体验好"这种模糊的目标，翻译成一组可观测、可告警、可复盘的指标体系——因为后面每一个架构方案的好坏，都要回到那套指标去丈量，没有标尺就没法做决策。