大模型服务的大并发，是云厂商最核心的工程能力之一。为什么难？一个残酷的数字：模型参数量每年约 10 倍增长，而 GPU 显存带宽仅提升 1.5 倍。大模型推理工程师的核心使命早已不是「调参炼丹」，而是在算力与存力的夹缝中榨取硬件的每一丝潜力。

这篇文章把云厂商的「大并发」拆成三层技术栈：单实例层（把一张卡榨干）、集群层（把并发摊到多卡）、平台层（治理不被打爆），最后给出业务侧的接入指南。

一、三个本质矛盾

1. 显存矛盾：KV Cache 是推理显存的大头，管理不好直接 OOM——显存利用率决定「一张卡能同时服务多少个请求」，也就是并发上限
2. 算力矛盾：Prefill（预填充）是计算密集型，Decode（逐 token 解码）是访存密集型，两者对硬件需求完全不同，塞在同一个进程里互相拖累
3. 峰谷矛盾：大并发往往伴随剧烈波峰（秒杀、活动、晚间高峰），按峰值买卡成本爆炸，按均值买卡流量一来就崩

云厂商的方案，就是围绕这三个矛盾，在三个层次分别做文章。

二、单实例层：把一张卡「榨干」

1. PagedAttention：让显存利用率决定并发上限

传统静态批处理为每个请求按预估最大长度（max_seq_len）预分配连续物理显存，绝大多数被浪费。PagedAttention 借鉴操作系统虚拟内存分页的思路：

• 把 KV Cache 切成固定大小的「页」，按需分配，逻辑连续、物理可以不连续
• 不再预分配整块显存，显存碎片大幅减少，空间利用率大幅提升
• vLLM 是这套方案的代表实现，后来几乎所有主流框架都跟进

显存利用率上去后，同一张卡能同时容纳的请求数成倍增加——这是大并发的地基。

2. Continuous Batching：请求动态进出批次

传统静态批处理要等一个 batch 里所有请求都生成完才能换入新请求，GPU 大量空闲。连续批处理让请求「随到随进、随完随出」：有请求完成，立刻腾出位置换入排队中的新请求，GPU 保持满负荷运转，吞吐大幅提升。

实测案例：同样的 8 卡 A800、同样的 72B 模型，开启 Continuous Batching 后吞吐显著提升——同样的硬件，扛住了多得多的并发。

3. 前缀缓存：高并发场景的「免计算」红利

高并发场景有个黄金规律：大量请求共享前缀（系统提示词、少样本示例、Agent 工具描述、多轮对话历史）。SGLang 的 RadixAttention 和 vLLM 的 prefix caching 就是冲着复用来的：

• 命中缓存的请求，省去从缓存起点到终点的整个 prefill 计算
• 缓存命中的长度越长，TTFT（首 token 延迟）降得越明显——用户体感「秒回」
• 这正是火山方舟「上下文缓存」等平台特性的底层技术，多轮对话场景收益最大

4. 投机解码：2～3 倍的额外加速

用小模型「猜」几个 token，再由大模型一次验证，猜对了就白赚几步。投机解码可以把推理速度再提升 2～3 倍，是对前面几项的乘法加成。

三、集群层：把并发摊到多卡

单卡榨干之后，接下来是「摊」。

1. PD 分离：把两股水流分开治

Prefill 是计算密集型（一次吃一大段 prompt），Decode 是访存密集型（逐 token 吐字）。两者混在同一进程里，会出现「长文本 prefill 占着 GPU 算力，把 decode 请求全拖慢」的互相伤害。

PD 分离（Prefill-Decode Disaggregation，AMD 在 ROCm 博客提出）把两个阶段拆到两组独立服务：

• P 实例专门做 prefill，D 实例专门做 decode，KV Cache 经网络传给 decode 端
• 两组服务可以独立扩缩容——高峰时多扩 D 实例，长文档批量接入时多扩 P 实例
• 实战数据（DeepSeek-V3 类模型高并发负载）：TTFT 压到 1 秒内，吞吐翻倍

2026 年的生产级 LLM 推理几乎集体转向这类分离架构（DistServe、MoE-Centric 系列都是这条路线）。

2. MoE 专家并行：DeepSeek 类模型的专属打法

MoE 模型（DeepSeek-V3/R1 等）的难点是「每个 token 只激活少量专家，但所有专家权重都要放在显存里」。专家并行（EP）把专家切分到多张卡：

• 每张卡只放一部分专家，token 经路由分发到对应卡计算
• 配合 token 重排、负载均衡、fused MoE kernel 等手段，把「专家全放不下」变成「按需调度专家」
• 这是云厂商支撑 DeepSeek 类模型大并发流量的核心手段

3. 张量并行 / 流水线并行：把一个大模型切开

• 张量并行（TP）：单层矩阵切分到多卡，卡间高速互联（NVLink）
• 流水线并行（PP）：按层切分，流水线执行
• 两者解决「一个模型一张卡放不下」的问题，是大参数量模型服务多并发的必要前提

4. KV Cache 池化：以 KVCache 为中心的推理新基建

火山引擎 EIC（高性能分布式 KVCache）代表了一条新路线：

• KV Cache 从「每实例私有」变成「池化共享」，命中即免算
• 配合 GPU Direct RDMA 绕过 CPU 直连网络设备，低时延传输
• 全局缓存池让跨实例、跨时间的前缀复用成为可能——大并发下的收益不是线性的，是指数的

四、平台层：云厂商的「大并发治理」

引擎和集群解决「算得动」，平台解决「不被打爆」。

1. 统一推理运行时底座

2026 AI Infra Summit 上，vLLM 与 SGLang 社区联合发布 Unified Inference Runtime v3.0，阿里云 PAI、AWS SageMaker、火山引擎方舟等主流云平台宣布将其作为大模型托管服务的默认底座。LLM 推理正式告别「手工调优 CUDA Kernel」的作坊时代——云厂商把引擎层的所有优化做成开箱即用的默认能力。

2. 多层缓存体系

以火山方舟 DeepSeek 服务为例：内存 / SSD / 分布式三级缓存体系，命中率提升至 98%。大并发下大量请求直接命中缓存，等价于「免算并发」。

3. 量化推理引擎

INT8 等量化技术让模型推理速度提升 3 倍（实测延迟 < 200ms）。同样的 GPU 池，量化后能扛的并发直接翻倍——这是云厂商「性价比大并发」的常规操作。

4. 弹性伸缩：峰值来了机器也要「来得及」

• 手动或定时扩缩容应对可预见的流量波峰
• 结合冷启动优化（预热、Warm Pool、预测性弹性），把扩缩容延迟压到秒级
• 初始实例数按「预估 QPS ÷ 单实例吞吐」计算基准值，弹性伸缩兜住波动

5. 网关限流与配额：大并发的「防洪堤」

云厂商的大并发能力，一半在引擎，一半在流量治理：

• TPM / RPM 并发上限：按账号级或密钥级设置配额，业务高峰不互相挤占
• 主子账号分级：不同业务线分配独立配额
• 多通道调度：多密钥、多通道分摊流量，避免单点限流卡脖子
• 超时与最大并发数：超时太短误杀长文本生成，太长则单个请求长期占用资源拖垮整体吞吐——平台侧统一给出最佳实践

6. 全链路压测与容量规划

上线前用压测工具模拟真实分布（长短文本混合、思维链、多轮对话），验证「多少并发下 TTFT / TPOT / 错误率」达标，再据此确定配额与弹性策略。

五、业务侧：怎么「接住」云厂商的大并发能力

平台能力强，还要会用：

1. 算清需求：峰值 TPM = 日活 × 人均请求数 × 单请求平均 Token ÷ 高峰集中系数；并发数按高峰同时在线请求估算
2. 确认限流维度：账号级还是密钥级？是否支持主子账号分级配额？多业务线要分开申请
3. 多通道调度：大并发业务用多密钥分流，客户端做失败重试与退避
4. 用好前缀缓存：系统提示词固定化、对话历史复用，命中率越高，等效并发越高
5. 公有云 API 优先：大并发下自建集群的瓶颈会全部暴露（显存、调度、限流、弹性），而云厂商 API 已经把三层技术栈做成默认能力——按量计费 + 弹性伸缩，业务侧只管写好重试逻辑

六、总结

云厂商扛住大并发，靠的是三层递进：

1. 单实例层榨取：PagedAttention 提显存利用率、Continuous Batching 提吞吐、前缀缓存免计算、投机解码加倍——一张卡当几张卡用
2. 集群层扩展：PD 分离解耦算力矛盾、MoE 专家并行支撑 DeepSeek 类模型、TP/PP 切开大模型、KV Cache 池化全局复用
3. 平台层治理：统一运行时底座、三级缓存、量化引擎、秒级弹性、限流配额、压测容量规划

而站在业务视角，最简单的接法就是：把大并发交给平台消化，把精力放回业务本身。用火山方舟官方 API（通过向量云独享接入点），你不需要理解 PagedAttention 的每一行代码——你只需要知道，它已经在为你扛着并发。

关于向量云：大并发场景下的「免运维」选择

向量云（南京）科技有限公司依托字节跳动火山方舟官方授权，专注大模型应用落地：

向量云能力	说明
官方 API 免部署	火山方舟官方 API 与官方 Key 直连，大并发由平台消化
独享接入点	缓存与配额不被公共池挤占，高峰不排队
低折扣 Token	专属折扣价，用量越大越划算
缓存隔离降本	上下文缓存红利稳定落袋，高并发下成本优势显著
计费灵活	按量计费、即用即扣、注册充值 10 元起
协议兼容	OpenAI 兼容协议，业务代码几乎零改动

接入方式：注册后获取官方 API Key，把 base_url 指向向量云接入点即可直接调用火山方舟官方模型。