【学习笔记】分布式推理：TP / PP / EP / CP 并行策略详解（20/35）

这一篇是部署服务化篇的收官，主题是大多数工程师在 70B+ 模型部署时都会被问到的问题：

并行怎么切？

这是一个看似简单实则复杂的问题。前面几篇我们已经多次提到 TP、PP、EP、CP，但都是浅尝辄止。今天我们把它们一次性讲透。

如果你做过相关工作，下面这些问题应该不陌生：

• 8 卡 H100 部署 Llama-3-70B，用 TP=8 还是 TP=4+PP=2？

• 跨机部署一定要 PP 吗？跨机能不能用 TP？

• DeepSeek-V3 671B 怎么切？专家并行（EP）是什么？

• 1M 上下文场景下，CP（Context Parallel）怎么和 TP 配合？

• 集群用 InfiniBand 200Gbps 够不够？

• 同样是 8 卡，为什么 TP=8 比 TP=4 慢？

读完本文你将能：

1. 区分 5 大并行策略的本质差异和适用场景

2. 设计混合并行配置（3D / 4D 并行）

3. 根据硬件 + 模型规模选对最优策略

4. 在 vLLM / SGLang 上实战配置各种并行

5. 排查通信瓶颈

我们开始。

---

一、为什么需要分布式

1.1 单卡装不下的硬上限

回顾前面我们算过的数字：

模型	FP16 显存	INT8 显存	INT4 显存
Llama-3-8B	16 GB	8 GB	4 GB
Llama-3-70B	140 GB	70 GB	35 GB
Llama-3-405B	810 GB	405 GB	203 GB
DeepSeek-V3 671B	1342 GB	671 GB	336 GB

单卡 H100/H200 上限是 80-141GB。所以：

• 8B / 14B：单卡跑得动

• 32B：单卡极限（INT4）

• 70B：必须多卡

• 405B / 671B：必须跨机

1.2 不仅是「装下」

分布式推理不只解决"装下"问题，还要解决：

1. 吞吐：多卡分担同一请求 → 单请求快

2. 并发：多副本独立处理 → 总吞吐高

3. 长上下文：单卡 KV Cache 不够 → 跨卡分担

4. MoE 专家：稀疏激活 → 专家分布

5. 跨机网络：高带宽互联 vs 低带宽 → 不同策略

不同需求对应不同的并行策略。

1.3 五大并行策略速览

DP - Data Parallel        ──  数据并行   ──  切请求
TP - Tensor Parallel      ──  张量并行   ──  切层内算子
PP - Pipeline Parallel    ──  流水并行   ──  切层
EP - Expert Parallel      ──  专家并行   ──  切 MoE 专家
CP - Context Parallel     ──  上下文并行 ──  切序列

下面逐个深入。

---

二、五大并行策略深度拆解

2.1 Data Parallel (DP)：最朴素的并行

做法：把同一个完整模型在多张卡上各放一份，每张卡处理不同的请求。

卡 0：完整模型 + 请求 A
卡 1：完整模型 + 请求 B
卡 2：完整模型 + 请求 C
卡 3：完整模型 + 请求 D

优点：

• 实现极简

• 无跨卡通信

• 线性扩展吞吐

缺点：

• 不省显存------每张卡都要装完整模型

• 70B 模型每张卡都要 140GB（FP16） → 单卡 H100 装不下，根本不能用 DP

适用场景：

• 模型小（< 单卡显存）

• 业务高并发

• 多副本部署（业务层路由）

与训练 DP 的区别：训练 DP 需要梯度同步（AllReduce），推理 DP 完全独立。

2.2 Tensor Parallel (TP)：层内切分

核心思想 ：把每一层的算子（attention、MLP）切到多张卡上并行计算。

2.2.1 Attention 切分

Multi-Head Attention 天然适合切：

原始：64 个 attention head 在 1 张卡
TP=8：8 个 head / 卡，共 8 张卡

每张卡算自己那 8 个 head，结果通过 AllReduce 合并。

2.2.2 MLP 切分

FFN 的 W1: [d, 4d] 和 W2: [4d, d] 用 行列分割：

W1 切列：每张卡持有 [d, 4d/N]
W2 切行：每张卡持有 [4d/N, d]

计算流程：

x → W1 (列切) → activation → W2 (行切) → AllReduce → output

中间结果不需要同步，只在最后做一次 AllReduce。

2.2.3 TP 的通信代价

每层 Transformer Block 通信约 2 次 AllReduce：

• attention 后的 AllReduce

• FFN 后的 AllReduce

对 Llama-3-70B（80 层）：

• 每次 forward：160 次 AllReduce

• 每次 AllReduce 通信量：~ d × batch × seq × 2 bytes

这就是为什么 TP 要求高速互联------通信跑不快，TP 直接变成性能杀手。

2.2.4 通信带宽要求

互联类型	带宽	是否能跑 TP
NVLink （H100）	900 GB/s	✅ 完美
NVLink （A100）	600 GB/s	✅ 好
PCIe 5.0	64 GB/s	△ 勉强
PCIe 4.0	32 GB/s	❌ 慢
InfiniBand 400G	50 GB/s	❌ 跨机太慢
以太网 100G	12.5 GB/s	❌ 完全不能

核心规则：

TP 必须用 NVLink 级别的互联，跨机做 TP 是灾难。

2.2.5 TP 的实际收益

理想：TP=8 → 8× 加速

现实：TP=8 → 5-6× 加速（通信开销吃掉一部分）

随着 TP 数增大，通信开销不成比例上升：

TP 数	实际加速	通信占比
1	1×	0%
2	1.8×	10%
4	3.3×	17%
8	5.5×	31%
16	7×	56% ⚠️

生产建议：TP 通常 ≤ 8（单节点内 NVLink），跨机要换 PP。

2.3 Pipeline Parallel (PP)：层间切分

核心思想：把模型的不同层放到不同卡上。

卡 0：layers [0-19]
卡 1：layers [20-39]
卡 2：layers [40-59]
卡 3：layers [60-79]

请求像在流水线上"流过":

时刻 1：请求 A 在卡 0
时刻 2：请求 A 在卡 1，请求 B 在卡 0
时刻 3：A 在卡 2，B 在卡 1，C 在卡 0
...

2.3.1 PP 的 bubble 问题

最朴素的 PP 有起始 + 结束的 bubble------前几个 step 后面的卡闲着，最后几个 step 前面的卡闲着：

时刻：  1  2  3  4  5  6  7  8
卡 0:   A  B  C  D  -  -  -  -    ← 后期闲
卡 1:   -  A  B  C  D  -  -  -    
卡 2:   -  -  A  B  C  D  -  -
卡 3:   -  -  -  A  B  C  D  -    ← 前期闲
                ^^^^^^^^^^^^
                只有这里满载

Bubble 占比 ：约 (PP - 1) / 总 step 数。如果总 step 数远大于 PP，bubble 影响小。

优化：1F1B、Interleaved 1F1B

通过更精细的调度，把不同 micro-batch 交错执行，bubble 显著降低：

传统 PP：    bubble ~ 40%
1F1B：       bubble ~ 20%
Interleaved：bubble ~ 5%
DualPipe（DeepSeek V3）：bubble ~ 0%

2.3.2 PP 的通信代价

PP 通信量比 TP 小得多------只在「层边界」传递激活值：

• 每层间一次 send/recv

• 通信量：batch × seq × d × 2 bytes

适合跨机部署------InfiniBand 完全够用。

2.3.3 TP vs PP 决策

因素	TP	PP
通信频率	高（每层 2 次）	低（层间 1 次）
通信量	大	小
适合互联	NVLink	InfiniBand / 跨机
实现难度	中	中等
Bubble	无	有（可优化）
推理友好	⭐⭐⭐⭐⭐	⭐⭐⭐
训练友好	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

推理首选 TP------除非跨机或单层太大。

2.4 Expert Parallel (EP)：MoE 专属

背景：DeepSeek-V3 / Mixtral 等 MoE 模型有大量专家（256+），如果按 TP 切，每张卡都要装所有专家------显存爆。

EP 的做法：

256 个专家 → 切到 8 张卡，每张卡 32 个专家
每个 token 选 8 个专家 → 通过 All-to-All 路由到对应卡

通信特点：

• All-to-All：每张卡都要和其他卡互发数据

• 通信量 = batch × seq × d × 2 bytes（不大，但全连通）

2.4.1 EP 的工程挑战

1. 专家负载不均

某些专家被频繁激活，某些几乎不用。

对策：

• 训练时引入 auxiliary loss-free 负载均衡（DeepSeek V3 创新）

• 推理时实时监控，动态调整

2. 跨卡 All-to-All 慢

跨节点 All-to-All 是分布式系统中最慢的通信模式。

对策：

• 同节点内尽量做完通信（节点内 EP）

• DeepEP 等专用 All-to-All 库

2.4.2 EP 的实际效果

DeepSeek V3（671B / 37B 激活）部署：

部署	配置	单卡显存	吞吐
纯 TP	TP=16	80 GB	慢
TP+EP	TP=4, EP=8 (32 卡)	80 GB	⭐ 最优
纯 EP	EP=32	80 GB	中等

2.5 Context Parallel (CP)：序列切分

场景：1M 上下文，单卡 KV Cache 几百 GB 装不下。

做法：把序列切到多卡，每张卡持有一部分 K/V，用 Ring Attention 累积。

1M 序列 / 8 卡 = 每卡 125K
卡 0: token [0, 125K)
卡 1: token [125K, 250K)
...
卡 7: token [875K, 1M)

通信特点：Ring 通信（环形传递 K/V），通信和计算 overlap。

第 15 篇我们详细讲过，这里不再展开。

CP 的适用场景

• 上下文 > 100K

• 模型不大（< 100B）------ 否则 TP 已经把卡用完了

• 高速互联（NVLink + IB）

---

三、混合策略：3D 并行 / 4D 并行

3.1 单一并行不够用

实际生产中，单一并行策略往往不够：

• 仅 TP：跨机变慢

• 仅 PP：单卡装不下大层

• 仅 EP：MoE 才有效

所以工业部署都是混合：

小模型 (8B-32B)：    TP 即可
大模型 (70B-405B)：  TP + PP
超大 MoE：          TP + PP + EP
长上下文：          TP + PP + CP
全场景：            TP + PP + EP + CP (4D)

3.2 3D 并行（最常见）

Llama-3-405B 跨机部署（16 卡 H100，2 节点）：

节点 1（8 × H100）  节点 2（8 × H100）
TP=8 in node       TP=8 in node
        ↘            ↙
         PP=2 across nodes

总并行度：TP=8 × PP=2 = 16 GPU

为什么这么切：

• TP=8 在单节点内 NVLink 通信

• PP=2 跨节点（IB 通信量小）

• 模型权重均匀分布

3.3 4D 并行（MoE 超大规模）

DeepSeek-V3 671B 部署（32 卡 H100，4 节点）：

TP=4 × EP=4 × PP=2 = 32 GPU
       ↓
  节点内：TP=4
  节点间：PP=2 + EP=4

配置思路：

• TP=4：单节点 4 卡切层内（每卡装 1/4 共享权重）

• EP=4：跨节点 4 路切专家（每节点 64 个专家）

• PP=2：横跨多组节点

3.4 计算公式

总卡数 = TP × PP × EP × CP × DP

举例：

8 卡部署 70B 模型：
  TP=8, PP=1, EP=1, CP=1, DP=1   → 1 个副本

16 卡部署 70B 模型：
  TP=8, PP=1, EP=1, CP=1, DP=2   → 2 个副本（高并发）

16 卡部署 70B 模型 + 长上下文：
  TP=8, PP=1, EP=1, CP=2, DP=1   → 单副本 1M 上下文

32 卡部署 405B 模型：
  TP=8, PP=4, EP=1, CP=1, DP=1   → 1 个副本

32 卡部署 671B MoE：
  TP=4, PP=2, EP=4, CP=1, DP=1   → 1 个副本

---

四、实战配置

4.1 vLLM 单机 TP（最常用）

# 8 卡 H100 部署 Llama-3-70B
vllm serve meta-llama/Llama-3-70B-Instruct \
    --tensor-parallel-size 8 \
    --dtype bfloat16 \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.92 \
    --port 8000

注意事项：

• TP 数必须是 num_attention_heads 的因子（Llama-3-70B 是 64 → TP 可以是 1/2/4/8/16/32/64）

• 单节点 NVLink 才合理 TP

4.2 vLLM 多机 TP + PP

# 2 节点 × 8 卡，部署 405B
# Master 节点
ray start --head --port=6379

# Worker 节点
ray start --address=<master_ip>:6379

# 在 Master 上启动 vLLM
vllm serve meta-llama/Llama-3-405B-Instruct \
    --tensor-parallel-size 8 \
    --pipeline-parallel-size 2 \
    --distributed-executor-backend ray \
    --dtype bfloat16 \
    --max-model-len 16384 \
    --port 8000

关键点：

• 必须用 Ray 作为分布式执行器

• 所有节点同样的 vLLM 版本

• 同样的模型权重路径（NFS / 分布式存储）

4.3 vLLM 长上下文 + CP

# 16 卡部署 70B + 1M 上下文
vllm serve meta-llama/Llama-3-70B-Instruct \
    --tensor-parallel-size 4 \
    --context-parallel-size 4 \
    --max-model-len 1048576 \
    --kv-cache-dtype fp8 \
    --rope-scaling '{"type":"yarn","factor":8.0}' \
    --enable-chunked-prefill \
    --port 8000

TP=4 + CP=4 = 16 卡：

• TP 切模型权重

• CP 切序列长度

4.4 SGLang EP 部署 MoE

# 32 卡部署 DeepSeek-V3
python -m sglang.launch_server \
    --model-path deepseek-ai/DeepSeek-V3 \
    --tp 4 \
    --ep 4 \
    --pp 2 \
    --dist-init-addr master:50000 \
    --nnodes 4 \
    --node-rank 0 \
    --enable-flashinfer \
    --port 30000

注意：SGLang 对 MoE 优化做得更好，EP 部署推荐用它。

4.5 配置选择决策树

模型规模？
  │
  ├─ < 30B → 单卡 (DP 多副本)
  │
  ├─ 30-70B → TP 单机
  │    └─ 上下文 > 128K → + CP
  │
  ├─ 70-200B (Dense) → TP 单机 / TP+PP 双机
  │
  ├─ 200B-1T (MoE) → TP + EP + PP 多机
  │
  └─ > 1T → 4D 并行 + 大型集群

---

五、网络拓扑与硬件要求

5.1 通信带宽对应表

互联	带宽	适合
NVLink 4 (H100)	900 GB/s	TP 任意
NVLink 3 (A100)	600 GB/s	TP ≤ 8
NVSwitch	900 GB/s	整机内 TP
InfiniBand HDR (200G)	25 GB/s	PP / EP
InfiniBand NDR (400G)	50 GB/s	PP / EP / 跨机
PCIe Gen5	64 GB/s	仅 DP
Ethernet RoCE 100G	12.5 GB/s	DP / 低强度 PP
Ethernet RoCE 400G	50 GB/s	PP / EP / 适度 TP

5.2 推荐架构

单机 8 卡训练 / 推理：

• 8 × H100 SXM5（NVLink + NVSwitch）

• 1.8 TB/s 二分带宽

• 完美做 TP=8

8 卡服务器 + 集群：

• 节点内：H100 SXM + NVLink

• 节点间：InfiniBand NDR 400G × 8 网卡

• 适合 TP=8 in node + PP/EP across nodes

经济型方案：

• 8 × RTX 4090（PCIe 互联）

• 适合 DP 多副本（不适合 TP）

• 不能跨机

5.3 通信瓶颈识别

部署后看 GPU 利用率：

nvidia-smi dmon -s u   # 实时 utilization
nvtop                   # 多卡可视化

异常模式：

• GPU 利用率 50-60% 周期波动 → TP 通信瓶颈

• GPU 利用率梯子状（前面满后面空）→ PP bubble

• 整体利用率 < 30% → 通信完全卡死

排查工具：

# NVIDIA Insight / Nsight Systems 跑 trace
nsys profile --output=trace python my_inference.py

# 看 NCCL 日志
NCCL_DEBUG=INFO vllm serve ...

---

六、生产常见问题

6.1 TP 反而变慢

症状：TP=8 比 TP=4 还慢。

原因：通信开销超过算力收益。

对策：

• 检查 NVLink 是否启用：nvidia-smi nvlink -s

• 降 TP 数（往往 TP=4 已经够）

• 提高 batch size（增大 compute / communication 比例）

6.2 PP bubble 严重

症状：GPU 利用率呈梯子状。

对策：

• 启用 1F1B 调度（vLLM 默认）

• 增加 micro-batch 数量

• 减少 PP 数（PP=2 通常足够）

6.3 MoE 专家不均衡

症状：某些卡显存满，某些卡空。

对策：

• 监控专家激活分布

• 训练阶段加 load balance loss

• 推理时启用 Expert Affinity（部分框架支持）

6.4 跨机延迟超预期

症状：跨机 PP 比预期慢 2-3 倍。

对策：

• 检查 InfiniBand 拓扑：ibstat

• 确认 NCCL 用了 IB：NCCL_IB_DISABLE=0 NCCL_NET=IB

• 测试通信带宽：nccl-tests/all_reduce_perf

6.5 显存不均衡

症状：某些卡 OOM，某些卡空闲。

对策：

• TP 数选择不当（不是 head 数的因子）

• PP 切分不均（用 --pipeline-parallel-balance）

• KV Cache 量化 + offloading

---

七、扩展话题与下一篇预告

7.1 Disaggregated Prefill/Decode（新趋势）

2025 年的新方向------把 prefill 和 decode 部署到不同集群：

Prefill 集群（compute-bound）：高算力 GPU、少量 KV 存储
Decode 集群（memory-bound）：大显存 GPU、强带宽

请求流：
  用户 → Prefill 集群（生成 KV） → 传到 Decode 集群（生成 token）

优势：

• 两类负载用不同硬件优化

• 资源利用率从 60% 提升到 90%+

• DeepSeek V3 / Llama 4 已经在用

7.2 异构硬件混部

未来推理集群可能不是同质化的：

• 高端 GPU 跑 prefill

• 低端 GPU 跑 decode

• CPU 处理 embedding

• NPU / TPU 跑特定任务

7.3 下一篇预告

部署服务化篇 5 篇圆满收官！下一阶段进入工程实践篇（第 21-25 篇）：

• 第 21 篇：GPU 选型指南 - A100/H100/4090/910B 性价比分析 ------ 从硬件视角看大模型部署：什么场景买什么卡？租 vs 买？国产卡现状？

• 之后是集群运维（22 篇）、权重管理（23 篇）、显存优化（24 篇）、成本测算（25 篇）。

工程实践篇 5 篇收官后，我们就接近系列后半段------RAG / Agent / 前沿话题。

---

八、结语：分布式推理是大模型工程的"内功"

读完本文你应该明白：

• 5 大并行策略：DP / TP / PP / EP / CP 各有适用场景

• TP 用 NVLink，PP 用 IB------通信带宽决定策略

• 混合并行：实际生产 70B+ 模型都是 TP+PP，超大 MoE 是 4D 并行

• 通信开销随并行度非线性增长------TP=16 不一定比 TP=8 快

• Disaggregated Prefill/Decode 是下一代架构趋势

参考文献：

分布式推理：TP / PP / EP / CP 并行策略详解