第三章 高并发进阶原理

第三章 高并发进阶原理

读完前两章，你已经能让 DeepSeek V4 在单卡甚至几张卡上「跑起来」，也摸清了 vLLM 的请求链路、PagedAttention 和连续批处理这三大支柱。但「跑起来」和「扛住高并发」之间，隔着一道实实在在的墙：显存不够、算力喂不饱、延迟忽高忽低。

这一章我们不堆名词，而是把高并发部署里最要命的两组原理讲透：并行切分和显存与调度调优。前者决定你能把模型摊到多少张卡、能扛多大吞吐；后者决定你在不 OOM 的前提下，能把每张卡的利用率榨到多高。

一个必须先建立的认知：高并发真正考验的是什么

很多团队把「高并发」简单理解为「多开几个进程、把 batch 调大」。结果往往是：并发一上来，延迟不降反升，GPU 利用率却始终卡在 40% 以下。这说明瓶颈根本不在你以为的地方。

高并发部署真正考验的是三件事的协同：

1. 空间切分能力：模型权重 + 全部并发的 KV Cache 能不能优雅地摊在有限显存里。这是并行策略和显存预算要解决的。
2. 时间复用能力：GPU 在一秒内能不能几乎不空转地连续处理请求。这是连续批处理和调度要解决的（第二章已铺垫）。
3. 通信效率：多卡协同时，卡间搬运数据的开销能不能被计算收益盖过。这是并行维度选择要解决的。

这三点里，第一点和第三点正是本章的主角。第二点在第二章讲调度器时已立过地基，这一章把它和显存预算拧到一起看。

为什么这一章对 DeepSeek V4 格外重要

DeepSeek V4 是 MoE（混合专家）模型：参数总量巨大，但每次推理只激活少数几个专家。这和稠密模型（每次推理所有参数都参与）有本质区别，带来两个部署上的特殊性：

• 权重「虚胖」：全部专家权重在推理时要常驻显存，但单次前向只用到其中一小部分。这意味着传统「按总参数量算显存」的思路会让你过度悲观，而「按激活量算」又会让你低估常驻成本——真实部署必须二者兼顾。
• 计算高度稀疏：单卡算力被大量「闲置专家」稀释，除非用专家并行（EP）把专家物理分散到不同卡、让每张卡只存自己负责的专家。这就是为什么 MoE 的并行打法和稠密模型完全不同。

所以本章所有讨论都围绕「MoE + 高并发」这个真实场景展开，而不是泛泛而谈通用 LLM。如果你之前只部署过稠密模型，请特别注意 3.1 节里专家并行那一整块——它是你绕不开的新功课。

本章的知识脉络与读者收益

把这一章读完，你应该能独立回答四个问题，这也是我写这两节的验收标准：

1. 给定一台具体机器（几卡、什么互联），我该用 TP/PP/EP 的什么组合最划算？
2. gpu-memory-utilization 和 max-num-seqs 凭什么这么设，调大调小分别会怎样？
3. 为什么吞吐上去了、尾延迟却崩了——是 Chunked Prefill 没开，还是并发过载？
4. 出现 OOM 或频繁抢占时，我该先动哪个旋钮，而不是盲目重启？

与前后章的关系

这一章是「原理层」：3.1 给你并行骨架，3.2 给你调度肌肉。它和第四章的实战案例是一体两面——原理在这里，战场在第四章。第四章会把本章的两套旋钮落到一个完整的生产级 DeepSeek V4 服务里，你会看到参数到底怎么填、压测报告怎么读。所以读本章时，请带着「这些参数我明天就要真填」的心态，而不是「了解一下」。

需要提醒的是，vLLM 的并行与调度参数随版本演进很快，文中给出的参数名（如 tensor-parallel-size、gpu-memory-utilization、max-num-seqs、enable-chunked-prefill、max-num-batched-tokens）属于长期稳定暴露的启动项，但具体默认值、取值范围与可组合性请以你部署时对应版本的官方文档为准，切勿凭旧教程照抄命令行。版本差异导致的参数失效，是最常见也最隐蔽的部署事故源。

一个贯穿全章的判断

请记住这句话，它决定了你这一章的阅读重心：并行策略选错，后面所有调优都是徒劳；而并行选对了却不调调度，GPU 会空转给你看。 3.1 是地基，3.2 是装修，顺序不能乱。先花力气把并行搞对，再回来抠显存和调度的甜点，是高并发部署唯一省力的路径。

真实代价：两个反例

为了让你对「选错」有痛感，我讲两个真实里反复出现的反例，都是血泪教训：

反例一：TP 跨节点硬上。 某团队机器是 2 节点各 8 卡，节点间只有普通以太网。他们图省事直接 --tp 16，以为是「最大并行最快」。结果每层一次 All-Reduce 都要跨节点走以太网，单卡算力利用率掉到 35%，吞吐还不如单机 8 卡的 --tp 8。正确的做法应是节点内 --tp 8，专家并行也留在节点内，跨节点只用 PP 兜底。

反例二：并发旋钮拍脑袋。 另一团队并行没问题，但 max-num-seqs 直接设 4096，压测一上来就 OOM，回退到 256 又发现 GPU 利用率只有 30%。他们花了三天「试数」，其实只要先按 KV 预算算一下上限（见 3.2），半小时就能锁定合理区间。这两个反例共同说明：高并发部署是「算出来的」，不是「试出来的」。

本章与实测数据的呼应

为了让你带着「可验证」的心态读，我先预告一个会在第四章压测里看到的现象：在合理的 TP+EP 并行下，把 gpu-memory-utilization 从 0.6 调到 0.9，并发上限大约能提升 40%~60%，吞吐随之线性上涨；但当 max-num-seqs 越过 KV 预算算出的上限后，再怎么加都只换来 OOM 或频繁抢占。这条曲线是真实的、可复现的，你读完 3.2 后自己跑一遍就能印证。

另外要强调：本章所有参数名和定性结论基于 vLLM 长期稳定的设计，但具体取值（如某版本默认 gpu-memory-utilization 是 0.9 还是 0.95、Chunked Prefill 是否默认开启）随版本变动。请养成一个习惯——部署前先查你所用版本的官方启动参数文档，把本文的「旋钮名」和「调优方向」落到你实际的「默认值」上，避免被版本差异暗算。

如果时间有限，本章最不能跳的是 3.1 的「三种并行通信代价对比」和 3.2 的「KV 预算算账示例」——前者帮你少花冤枉钱在错误并行上，后者帮你第一次就把并发设到合理区间，二者合起来能省下数天的试错。

在动手写代码之前，请先把「先并行、后调度」这六个字贴在显示器上。它是本章全部内容的浓缩，也是我见过最有效的高并发部署心法。

下面进入 3.1，我们把张量并行、流水线并行、专家并行这三种切法，连同它们的通信代价与选型铁律，一次性讲透。