3.1 并行策略全解：张量并行、流水线并行与专家并行

3.1 并行策略全解：张量并行、流水线并行与专家并行

把 DeepSeek V4 这样的超大规模 MoE 模型塞进集群，本质上是一道「切分题」：把一张放不下的模型，沿着不同维度切开，摊到多张卡上，同时让它们协同完成一次前向推理。切法不同，通信量、显存占用和吞吐特性天差地别。这一节我们把三种主流并行维度——张量并行（TP）、流水线并行（PP）、专家并行（EP）——掰开揉碎讲清楚，并给出针对 MoE 的实战选型建议。

为什么单卡不行：先理解「放不下」的两种含义

很多人以为「放不下」只是显存问题，其实它有两种含义，决定了你该用哪种并行：

• 权重放不下：模型参数、优化器状态（推理时不需要，但权重本身巨大）超出了单卡显存。DeepSeek V4 总参数量以千亿、万亿计，即便 MoE 只激活部分专家，全部专家权重在推理时仍要常驻显存。这是空间维度的问题，靠切权重解决。
• 算力和并发喂不饱 / 延迟太高：即便权重勉强放下，单卡算力有限，高并发时排队严重。这是算力维度的问题，靠增加并行度、摊薄单卡负载解决。

记住这个判断：TP 和 PP 主要解决「放不下」，EP 主要解决「MoE 专家太多导致的显存与通信失衡」。 三者不是互斥选项，真实部署里经常叠加使用，比如 TP8 + EP32 这种组合在大型 MoE 集群里很常见。

张量并行（TP）：把一层「横着切」

张量并行是最直观也最常用的切法。它的核心思想是：把每一层的权重视为一个大矩阵，按行或按列切成几块，分别放到不同 GPU 上，每块只算一部分，最后用一次 All-Reduce 把结果相加。

以最典型的全连接层 Y = X · W 为例，直观理解如下。假设 W 是一个 4096×4096 的矩阵，我们按列切成两块 W1、W2（各 4096×2048），每张卡存一块。输入 X（形状 batch×4096）同时送两张卡，各自算出 X·W1 和 X·W2（各 batch×2048），拼起来就是完整的 Y（batch×4096）——这一步不需要通信。但下一层如果又要从 Y 出发做 Y·W'，而 W' 是按行切的，那每张卡手里的只是 Y 的一半维度，必须先把两部分求和（All-Reduce）还原成完整 Y 才能继续。于是一次前向里，每个张量并行组都要付出一次 All-Reduce 的通信代价。

TP 的特点与代价：

1. 通信密集：每层前向/反向都要 All-Reduce，通信量和序列长度、隐藏维度成正比。TP 越大，卡间通信越频繁，对 NVLink / 高速互联的依赖越强。
2. 适合单节点内：正因为通信频繁，TP 通常局限在单个节点内的多卡（靠 NVLink），不要跨节点做大 TP，否则通信延迟会直接吃掉并行收益。
3. vLLM 用法：启动参数 tensor-parallel-size（简写 --tp），例如 --tp 8 表示用 8 卡做张量并行。我的经验是：单节点 8 卡机器上，先把 tp 开满（=8），通常是最稳的起点。

踩坑提示：TP 跨 NUMA 节点（即一台机器插了两颗 CPU、各带一组 PCIe 直连的 GPU，但 GPU 间没有 NVLink 全互联）时，部分卡对之间的通信要走 CPU 内存，延迟骤增。遇到「tp 一大吞吐反而掉」的现象，第一反应应该是查 GPU 拓扑（nvidia-smi topo -m），而不是怀疑模型。如果拓扑显示是「PIX/NV#」说明走的是高速直连，若是「SYS」说明走了 CPU 桥，后者做大会让 TP 收益锐减。

流水线并行（PP）：把模型「竖着切」

流水线并行按层切：把模型的前 N 层放 GPU0，中间 N 层放 GPU1，最后 N 层放 GPU2。一个请求像流水线上的工件，依次流经各卡。

PP 的特点：

1. 通信量小：只在层与层的边界传激活值，远比 TP 的逐层 All-Reduce 轻。
2. 有「气泡」问题：如果简单地一个请求走完再放下一个，GPU 会轮流空闲，形成流水线气泡（bubble）。工程上用 micro-batch 把一批请求拆小、错峰注入，让各卡尽量同时忙碌，但气泡永远无法完全消除。
3. 适合跨节点扩展：因为通信少，PP 可以跨节点拉远，是「堆机器」的主要手段。
4. vLLM 用法：pipeline-parallel-size（--pp）。

我的主张：在 vLLM 高并发部署里，PP 通常作为 TP 填满单节点后的「扩容兜底」手段，而不是首选。因为 PP 的气泡会拉高尾延迟（P99），而高并发场景恰恰最在意尾延迟。除非单节点显存真的放不下且 EP 也已用满，否则我建议优先 TP+EP 组合，把 PP 留给「实在没招」的超大模型。具体到一个判断：当你发现单节点 TP+EP 已经放不下全部专家权重，且 OOM 无法靠降 gpu-memory-utilization 解决时，才引入 PP 跨节点——并且要同步接受 P99 上抬的心理准备。

专家并行（EP）：MoE 的专属解法

这是 DeepSeek V4 这种 MoE 模型最关键的并行维度。MoE 层由多个「专家」前馈网络加一个路由（router）组成：每个 token 只被路由到少数几个专家（如 8 选 2）。既然每次只激活个别专家，自然可以把不同专家放到不同 GPU 上——这就是专家并行。

EP 的核心难点是「All-to-All 通信」：每个 token 要被发到它命中的专家所在 GPU，算完再发回来。这不像 TP 的 All-Reduce 那样规整（所有卡贡献等长的分片再求和），token 的路由是动态的、不可预测的，所以通信模式高度不规则，对互联带宽极其敏感。直观想：TP 的 All-Reduce 像是「所有人把等长的纸条汇总」，EP 的 All-to-All 像是「每个人要把自己手里的信按收件人分拣到不同窗口」——后者随路由变化，分拣成本很难预测。

EP 的实战要点：

1. 专家负载不均：路由可能让少数「热门专家」过载，造成部分 GPU 忙死、其余空转。例如某批输入里 30% 的 token 都选中了同一个专家，那张卡就堵死。框架通常有专家负载均衡策略（如训练时的辅助负载损失、推理时的容量因子 capacity factor），但部署时仍建议观察各卡利用率，必要时调路由相关配置或引入专家冗余。
2. 容量因子与 token 丢弃：为避免单个专家被冲爆，EP 常设「专家容量」上限——一个专家本轮最多处理 N 个 token，超出的 token 要么丢弃（影响质量）、要么溢出到次优专家。这是吞吐与质量之间的真实权衡，调容量因子就是调这个平衡点。
3. EP 规模受限于专家总数：你把专家切得越碎（EP 越大），单卡存的专家越少、显存越省，但 All-to-All 越频繁。这里存在一个甜点区，需要结合实测找。
4. vLLM 用法：主要通过 --tensor-parallel-size 与专家并行相关的并行组合实现（具体暴露方式随版本演进，请以官方文档为准）；在 MoE 部署里常看到 TP 与 EP 叠加，例如把注意力头做 TP、把专家做 EP。

一个判断：如果你部署的是 DeepSeek V4 这类 MoE，却完全没用 EP，那你基本是在用「稠密模型的打法」硬扛 MoE——显存浪费、通信错位，性能会非常难看。EP 不是可选项，是必选项。

三种并行的通信代价对比

把三者放在一起比较，能帮你建立「什么场景用什么」的直觉。下面这张对比不是精确数字，而是定性量级，记住相对关系即可：

记住这条铁律：TP 和 EP 都吃高频通信，所以都尽量留在单节点 NVLink 域内；只有 PP 吃得消跨节点。 一旦你被迫把 TP 或 EP 跨节点拉，先量一下节点间带宽（通常只有节点内的几十分之一），大概率会发现并行收益被通信吃光。

三者如何组合：我的选型决策清单

在给出决策清单前，先补一个判断框架——「并行甜点」不是最大的并行度，而是「刚好放得下 + 通信不被放大」的那一点。很多人误以为并行度越大吞吐越高，实际上超过甜点后，通信开销的增长速度会超过算力增长，曲线掉头向下。下面这张图就是我反复验证过的定性规律：并行度从 1 增加到甜点，吞吐上升；越过甜点，通信反噬，吞吐回落。

真实集群里，TP、PP、EP 是叠加的。下面是我给高并发部署 DeepSeek V4 的实战决策顺序，照着走能少踩 80% 的坑：

决策清单（背下来）：

1. 先把单节点内的 TP 开满（通常 = 单机卡数），利用 NVLink 吃尽节点内带宽。
2. MoE 必上 EP，按专家数切分，解决专家权重显存与路由通信。
3. 只有当单节点 TP+EP 仍放不下时，才引入 PP 跨节点扩容，并接受尾延迟上升。
4. 永远先量 GPU 拓扑，再定并行度；不要拍脑袋设数字。

补充一个常被忽视的点：并行度不是越大越好。TP=8 时每张卡只存 1/8 权重，但每层一次 All-Reduce；若你硬上 TP=16 跨节点，通信开销可能让单卡算力利用率从 90% 掉到 50%。并行度的甜点在「刚好放得下 + 通信不被放大」处，而非「越大越狠」。

MoE 专属陷阱：专家并行的隐藏成本

既然 EP 是 DeepSeek V4 的必选项，这里单独把它的隐藏成本讲透，免得你踩了还不知道为什么慢。

第一，All-to-All 的带宽压力被低估。MoE 层里每个 token 都要被送到它命中的专家卡，算完再收回。假设一个 batch 有 4096 个 token、专家分布在 32 张卡上，那么每个 MoE 层都要做一次「把所有 token 按路由分发到 32 张卡」的全交换。这个数据搬运量 = batch × 隐藏维度 × 2（去+回）× 字节数，和 TP 的 All-Reduce 同量级甚至更大，且因为路由不均匀，实际链路容易局部拥塞。所以 EP 对节点内 NVLink 带宽的要求，一点不比 TP 低。

第二，专家容量浪费。为避免单专家被冲爆，EP 给每个专家设了容量上限（如每专家最多 256 个 token）。但在某个具体 batch 里，token 分布未必均匀填满每个专家的容量——没填满的容量就是浪费的显存与算力。容量因子设太大，浪费多；设太小，溢出 token 被丢弃或降级，质量掉。这是必须实测调的平衡点。

第三，张量并行与专家并行的交叠。现代部署常把注意力层做 TP（因为注意力头天然可切）、把专家层做 EP。但这带来「同一层内同时两种通信原语」的复杂度，调度器要在两种通信之间排好序，否则互相抢带宽。如果你的集群 NVLink 带宽有限，这两种通信叠加可能成为新瓶颈——这时要么降低 EP 规模、要么把注意力也并入 EP 的切分视野，具体看哪边更松。

本节小结

并行策略是高并发部署的地基。TP 横切层内、通信密但简单；PP 竖切层间、通信省但有气泡；EP 是 MoE 专属、靠 All-to-All 把专家摊开。地基选错，后面调度调得再花哨也救不回来吞吐。下一节我们在这套并行骨架上，讲怎么把显存预算算准、把调度喂饱——那才是把 GPU 利用率从 30% 拉到 80%+ 的真正战场。

给你的一句话带走：并行解决「放得下、算得动」，调度解决「算得满」；部署 DeepSeek V4，先 TP+EP 打底，PP 兜底，顺序别乱。通信代价记账要清楚：TP/EP 高频、留节点内，PP 低频、才跨节点。