【学习笔记】分布式推理：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 慢？
读完本文你将能：
区分 5 大并行策略的本质差异和适用场景
设计混合并行配置（3D / 4D 并行）
根据硬件 + 模型规模选对最优策略
在 vLLM / SGLang 上实战配置各种并行
排查通信瓶颈
我们开始。
一、为什么需要分布式
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 不仅是「装下」
分布式推理不只解决"装下"问题，还要解决：
吞吐：多卡分担同一请求 → 单请求快
并发：多副本独立处理 → 总吞吐高
长上下文：单卡 KV Cache 不够 → 跨卡分担
MoE 专家：稀疏激活 → 专家分布
跨机网络：高带宽互联 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 8000TP=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 并行策略详解