推理并行：DP、TP、PP、EP 与 CP 怎么选

推理并行不是“GPU 越多越快”，而是在多个 rank 之间重新分配权重、激活、KV、Expert token 和请求。每一种切分都会减少一部分单卡压力，同时增加新的通信、同步或空泡。

1. 先分清三个目标

并行配置通常在解决三类不同问题：

目标	需要改善什么	常见起点
模型或 KV 放不下	每 rank 容量	TP、PP、EP、CP，或先量化
单请求太慢	关键路径计算时间	同节点 TP，前提是通信足够快
集群吞吐不足	同时服务的请求数	DP / replica，并配合负载均衡

“模型能放下”只是可行性，不等于配置高效。先做模拟器显存账本，再用真实 Case 测 TTFT、TPOT、吞吐和通信占比。

2. 五种并行各切什么

2.1 Data Parallel：切请求

DP 让每个 replica 持有完整模型，把不同请求交给不同 replica：

Replica 0: 完整模型 ← 请求 A、C
Replica 1: 完整模型 ← 请求 B、D

• 减少：单 replica 的请求压力；
• 增加：模型副本占用和路由复杂度；
• 适合：模型单副本能放下，希望扩展总吞吐；
• 不直接改善：单请求关键路径。

在线服务常把 DP 与请求路由、Prefix 亲和性和弹性伸缩一起设计。若只看 GPU 数而忽略流量分布，可能出现一个 replica 排队、另一个空闲。

2.2 Tensor Parallel：切层内张量

TP 把 Linear / Attention 等层内矩阵分到多个 rank，各 rank 计算局部结果，再通过 collective 合并：

W = [W0 | W1]
Y0 = XW0
Y1 = XW1
Y  = combine(Y0, Y1)

• 减少：每 rank 的权重、部分计算和部分临时张量；
• 增加：几乎每层都出现 AllReduce / AllGather / ReduceScatter；
• 适合：高速互联域内解决容量或降低单请求计算时间；
• 风险：Batch 太小、跨慢链路或 TP 过大时，通信吞掉计算收益。

TP 的收益必须按目标拓扑测试。逻辑上的 TP=8 不说明 8 个 rank 是否在同一 NVLink/NVSwitch 域。

2.3 Pipeline Parallel：切层

PP 把连续层段放到不同 stage：

Stage 0: Layer 0..N
        → activation
Stage 1: Layer N+1..M

• 减少：每 rank 的层数和权重容量；
• 增加：stage 边界传输、流水线空泡和调度复杂度；
• 适合：需要跨较慢链路扩展容量，或 TP 域已经用尽；
• 风险：在线推理的动态 Batch 和不等长请求让流水线更难填满。

PP 的通信频率低于逐层 TP，但单请求必须顺序经过各 stage。它更像容量与拓扑工具，不应默认视为降延迟工具。

2.4 Expert Parallel：切 Expert

EP 把 MoE Expert 分散到多个 rank。每层 Router 之后执行：

dispatch token → remote/local experts → combine result

• 减少：每 rank 常驻的 Expert 权重；
• 增加：All-to-All、负载不均和 padding/drop 策略；
• 适合：Expert 总权重很大、每 token 只激活少量 Expert；
• 风险：热点 Expert、跨节点放置和小消息会放大通信。

MoE 的参数作用域、Router 和 dispatch/combine 由 MoE 推理负责；本页只把 EP 放回全局并行坐标。

2.5 Context Parallel：切序列

CP 沿序列维分担长上下文计算或状态：

• 减少：单 rank 承担的序列计算、激活或部分 KV 压力；
• 增加：Attention 所需的 K/V 交换、归约或环形通信；
• 适合：单请求上下文超长，序列维本身成为容量或计算约束；
• 风险：通信模式与具体 Attention backend 强相关。

CP 不是 Prefix Cache，也不是把不同请求分给不同 GPU。它切的是一个请求内部的上下文维度。

3. 作用域：global 不能直接当 per-rank

并行推理最常见的建模错误，是把全局量直接填进单 rank 公式。

量	常见作用域	需要检查
Dense 权重	TP/PP 后部分分摊	是否有复制层、LM Head、embedding
Expert 权重	EP/TP/PP 组合分摊	shared expert 是否复制
KV Cache	取决于 Attention 与 TP/CP 布局	KV heads 是否真实切分
请求数 / Batch	可能是 replica、engine 或 global	调度器口径
通信量	每 collective / 每 rank / 全局总量	算法和拓扑
吞吐	每 replica / 每 engine / 集群	是否包含排队和失败

任何容量或吞吐结论都应携带：

model × dtype × TP × PP × EP × CP × DP
hardware/topology × ISL/OSL × concurrency

详见模拟器建模指南。

4. 组合时先尊重拓扑

一个常见但不是普遍最优的组合原则是：

1. 高速域内放通信频繁的 TP；
2. 按 Expert 放置设计 EP，尽量控制 All-to-All 跨域；
3. 跨较慢链路优先考虑通信频率较低的 PP 或副本级 DP；
4. 超长上下文再评估 CP 是否比增加 KV 容量更合适。

这只是设计起点。实际系统还受到：

• NUMA / PCIe 根复杂度；
• NIC 数量和 GPU-NIC 亲和性；
• collective 算法；
• 通信-计算重叠；
• Prefill 与 Decode 的不同消息大小；
• 调度器是否能保持各 rank 工作一致。

GPU Communication负责互联与 collective 基础；拓扑 profile 必须对应真实机器，不能把另一种 NIC 布局的假设直接复用。

5. 一个选择顺序

模型和目标 Batch 能否单卡放下？
├─ 能
│  ├─ 单请求延迟优先 → 测 TP=1/2/...，直到通信开始主导
│  └─ 集群吞吐优先   → 优先 DP / replica
└─ 不能
   ├─ Dense 权重主导 → 先量化，再在高速域内 TP；必要时 PP
   ├─ Expert 权重主导 → EP + 必要的 TP/PP
   ├─ KV/长上下文主导 → KV 压缩/量化/Paged KV，再评估 CP
   └─ 多项同时主导 → 建模各作用域后搜索组合

不要跳过“先量化/压缩是否更简单”这一问。增加 rank 会同时增加成本、故障面和通信，容量问题未必应该优先用分布式解决。

6. 怎么验证并行配置

服务指标

• TTFT、TPOT / ITL；
• 请求与 token 吞吐；
• P50 / P95 / P99；
• 稳态可承载并发；
• OOM、抢占和错误率。

执行证据

• 每 rank 权重、KV、workspace；
• collective 的次数、字节和关键路径时间；
• rank 间计算/通信不平衡；
• pipeline bubble；
• Expert 负载与 token dispatch 分布；
• CPU launch、同步和调度等待。

最小实验

固定模型、硬件、拓扑、输入/输出分布和精度，只改变一个并行轴。至少比较：

per-rank memory
critical-path latency
delivered throughput
communication share

如果吞吐增加只来自更多副本，应报告扩容效率；不要写成“单实例加速”。

7. 常见误区

• TP 翻倍，延迟就减半：collective、同步和小矩阵效率会限制收益。
• PP 通信少，所以一定更快：空泡和逐 stage 关键路径可能更重要。
• EP 只影响显存：dispatch/combine 和负载不均常在关键路径。
• global Batch 可以直接代入 per-rank 显存：调度和复制口径可能不同。
• 跨节点 TP 绝对不行：应以目标网络和 Case 测量；但更慢、更不稳定的链路必须被显式建模。
• 卡越多容量越大，吞吐必然更高：可行容量、理论容量和校准容量是三件事。

相关页面

• MoE 推理 — EP、Expert 参数和 dispatch/combine
• Kernel / Runtime 优化 — collective 之外的执行开销
• 推理框架对比 2026 — 各层如何组装为 Serving Stack
• GPU Communication — NVLink、NCCL、RDMA 与拓扑
• Megatron 并行 — 更完整的训练侧并行原理