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

《大模型知识与部署》系列 · No.20 / 35（部署服务化篇收官）
适合人群：AI 工程师、后端开发、分布式系统架构师
阅读时间：约 28 分钟

在这里插入图片描述

写在前面

我们已经走过部署服务化篇的 4 篇：

  • 第 16 篇 vLLM 部署实战（基础）
  • 第 17 篇 推理框架横评（选型）
  • 第 18 篇 本地化部署（轻量）
  • 第 19 篇 OpenAI 兼容 API（网关）

这一篇是部署服务化篇的收官，主题是大多数工程师在 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）切到多张卡上并行计算。

Attention 切分

Multi-Head Attention 天然适合切：

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

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

MLP 切分

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

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

计算流程：

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

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

TP 的通信代价

每层 Transformer Block 通信约 2 次 AllReduce：

  • attention 后的 AllReduce
  • FFN 后的 AllReduce

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

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

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

通信带宽要求
互联类型 带宽 是否能跑 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 是灾难。

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
...
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%
PP 的通信代价

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

  • 每层间一次 send/recv
  • 通信量：batch × seq × d × 2 bytes

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

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（不大，但全连通）
EP 的工程挑战

1. 专家负载不均

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

对策：

  • 训练时引入 auxiliary loss-free 负载均衡（DeepSeek V3 创新）
  • 推理时实时监控，动态调整

2. 跨卡 All-to-All 慢

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

对策：

  • 同节点内尽量做完通信（节点内 EP）
  • DeepEP 等专用 All-to-All 库
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 是下一代架构趋势

部署服务化篇（第 16-20 篇）正式收官。回顾这 5 篇：

篇号 主题
16 vLLM 部署实战
17 推理框架横评
18 本地化部署
19 OpenAI 兼容 API
20 分布式推理

从这 5 篇开始，你已经具备了从单机到集群、从开源到商业、从协议到网关、从单卡到多机的完整部署能力。

下一阶段进入工程实践篇（第 21-25 篇）——把推理优化和部署的"软实力"补上"硬实力"：硬件选型、运维监控、成本测算、显存优化。我们下篇见。

📮 关于「码海寻道」
这里是一个聚焦 AI 工程化、大模型部署、后端架构实战的技术专栏。
写最一线的踩坑经验，做最务实的技术拆解。

如果这篇文章对你有启发，欢迎点赞、转发、关注。我们下篇见。

# 分布式 # 人工智能 # 语言模型
Logo
加入AMD AI开发者计划！

免费领 150 小时云算力，进群参与显卡、AI PC 幸运抽奖

更多推荐

第20篇-推理部署实战-用Go构建vLLM推理客户端

/ ChatMessage 表示一条对话消息// ChatRequest 对应 POST /v1/chat/completions 的请求体// vLLM 扩展字段// ChatChoice 表示一个候选输出// Usage 表示 Token 计量（第 23 篇会深入讨论）// ChatResponse 对应响应体Created int64 `json:"created"` // Unix 时间戳

avatar AMD开发者中国社区

模型量化精度异常时的检查与止损

为了将 70B 大语言模型的部署成本打下来，我们将线上 vLLM 推理集群的模型权重与激活值从 FP16 全量量化到了 INT8（采用 W8A8 方案）。量化效果立竿见影：单卡 A100-80G 的显存占用直接从 140GB（需 2 卡并行）缩减到了 70GB，单卡即可拉起，推理吞吐量（Tokens/s）提升了将近一倍。然而上线不到两天，客服渠道就接到了多起投诉。在处理复杂代码推导和长文本逻辑分析

avatar AMD开发者中国社区

Agent强化学习训练框架Microsoft Agent-Lightning之训练环境部署

本文档详细记录了在Ubuntu 22.04系统上部署Agent-Lightning环境的完整流程。关键点包括：使用conda创建Python 3.12环境；安装特定版本的torch、vllm等核心组件；通过预编译wheel安装flash-attn以避免本地编译；解决了三个常见环境问题（libstdc++版本冲突、fastapi兼容性问题、transformers版本限制）。文档还提供了项目目录结构

avatar AMD开发者中国社区