/ AI Infra

[Infra-7] Distributed Inference Parallelism: TP, PP, DP, CP, EP, and PD Disaggregation

A unified guide to DP, TP, PP, SP, CP, EP, and prefill-decode disaggregation in LLM inference: what each dimension partitions, how they compose, and where MoE and KV cache create practical coupling.

Jul 10, 20266 minInfra · Distributed Inference · Parallelism · MoE

讨论大模型推理并行时，最容易发生的一类误会，是把所有“多卡”方案都当成同一种拆分。TP、PP、DP、CP、EP 和 PD 分离都可能出现在同一套部署里，但它们切开的对象并不一样：有的切请求，有的切一层矩阵，有的切模型层，有的切上下文，有的切 MoE Expert，还有的切一次请求所处的推理阶段。

先给出本文最重要的结论：

TP、PP、DP、CP、EP 描述一个推理阶段内部如何分布计算。
PD 描述 Prefill 和 Decode 两个阶段如何放置到不同资源池。
 
因此，EP 和 PD 在逻辑切分维度上基本正交。

但这个结论经常被一个不准确的解释带偏：**PD 分离不是把 Attention 或 Cache 单独放到 Prefill，把 FFN 或别的计算放到 Decode。**Prefill 和 Decode 两侧都要执行完整 Transformer，包括 Attention、Dense FFN 或 MoE Expert。Prefill 产生、再交给 Decode 的主要状态是 KV Cache。

这篇文章建立一个统一坐标系，再用它解释这些并行方式如何组合，以及“逻辑正交”为何不代表工程上没有耦合。

1. 先用统一坐标系看问题#

把一个 Transformer 推理任务抽象为：

X[b, s, h], \qquad L, \qquad E, \qquad \Phi

其中：

维度	含义	常见并行
$b$	请求、batch、sequence 实例	DP
$s$	token、上下文长度	SP、CP、KV / sequence parallel
$h$	hidden、attention head、FFN intermediate	TP
$L$	Transformer 层号	PP
$E$	MoE expert 编号	EP
$\Phi$	Prefill、Decode 等推理阶段	PD 分离
模型副本	完整模型实例	Replica parallel / serving DP
候选 token	draft、verify、tree branch	speculative decoding

最简洁的记忆方式是：

DP：切请求
TP：切一层内部
PP：切模型层
SP / CP：切 token 序列
EP：切 expert
PD：切推理阶段

判断两个方案是否正交，可以先问一个朴素的问题：**它们是不是在切不同的下标？**这比从框架配置名出发更不容易混淆。

2. DP：按请求扩展模型副本#

Data Parallelism 在训练和推理中的侧重点不同。推理里的 DP 通常表示部署多个相同的模型副本，每个副本接收不同的请求或 batch：

GPU 0：完整模型，处理请求 A、B
GPU 1：完整模型，处理请求 C、D
...
GPU 7：完整模型，处理请求 X、Y

它主要提高系统总吞吐量，而不是让一个请求更快完成。普通 DP 副本之间通常具有以下特征：

权重相同，但处理的请求不同；
每个副本的 KV Cache 独立；
正常 token forward 不需要在副本间同步；
前置 Router 按负载、KV 命中或会话亲和性分发请求。

如果一个模型副本本身需要 TP=4，再部署两个副本：

DP = 2
TP = 4
总 GPU = 2 x 4 = 8
 
DP rank 0：GPU 0, 1, 2, 3
DP rank 1：GPU 4, 5, 6, 7

这里每个 DP rank 内部的四张卡共同承载一个模型。vLLM 也将这类推理 DP 描述为复制模型来处理独立请求 batch，并允许与 TP 等模型内并行组合。vLLM 的数据并行部署文档还讨论了 MoE 场景里更特殊的 DPA，后文会回到它。

3. TP：切一层内部的大矩阵#

Tensor Parallelism 把一个 Transformer 层内的大张量和矩阵计算分散到多张卡。例如线性层：

Y = XW

若将权重按列切分：

W = [W_0, W_1, \ldots, W_{p-1}]

每张卡可本地计算：

Y_i = XW_i

随后用 All-Gather、Reduce-Scatter 或 All-Reduce 让后续层拿到所需结果。Q/K/V projection、Attention output projection、FFN intermediate、LM head 的 vocabulary 维度，都是常见的 TP 切分对象。

TP 处理的是：同一个 token、同一层里的不同矩阵分片。

它的好处是降低单卡权重和中间张量占用，多张卡共同处理同一个 token；代价是几乎每层都有 collective communication。TP 通常更适合 NVLink、NVSwitch 这类节点内高速互联。跨节点把 TP 开得很大时，频繁 collective 的延迟和带宽成本往往会抵消计算收益。

Megatron 将 TP 定义为把单层参数张量分布到多张 GPU，而将 PP 定义为沿模型深度分布连续层；这两个定义准确抓住了二者的边界。Megatron Bridge parallelisms guide 是一个很好的对照参考。

4. PP：按层切成流水线#

Pipeline Parallelism 不拆单层矩阵，而是把不同 Transformer 层放到不同 stage。假设模型有 32 层、PP=4：

Stage 0：Layer 0  - 7
Stage 1：Layer 8  - 15
Stage 2：Layer 16 - 23
Stage 3：Layer 24 - 31

一个 token 的 hidden states 依次在 stage 间传递：

hidden states → Stage 0 → Stage 1 → Stage 2 → Stage 3

与 TP 的主要区别如下：

项目	TP	PP
切分位置	单层内部	层与层之间
同一个 token	多卡共同做一层	依次经过各 stage
主要通信	tensor shard、部分结果	stage 边界 activation
通信频率	几乎每层	每次跨 stage
主要风险	collective 开销	pipeline bubble

PP 能让模型沿深度跨更多设备扩展，通信也不必像 TP 一样发生在每一层内部。不过在线 decode 中，一个 token 仍要顺序穿过全部 stage，因此 PP 对单请求延迟并不天然友好。大量并发 sequence 或 microbatch 能让不同 stage 同时处理不同工作，从而改善吞吐；interleaved PP、virtual pipeline 和不均匀分层也都在减少 bubble。

5. SP 与 CP：都和序列有关，但不是同一回事#

SP 是一个有歧义的术语，必须先问清框架语境。

5.1 Megatron SP：TP 的补充#

Megatron 所说的 Sequence Parallelism，通常不是把完整 Attention 沿序列切开。它主要把原本未被 TP 切分的一些 activation，例如 LayerNorm、dropout 和 residual 相关 activation，沿 sequence 维度分给 TP ranks：

X \in \mathbb{R}^{B \times S \times H} \quad \Rightarrow \quad X_i \in \mathbb{R}^{B \times \frac{S}{p} \times H}

它通常与 TP 共用同一组 rank，不单独增加 GPU 数量，主要目标是减少 activation 内存。因此：

TP = 4，启用 Megatron SP，仍通常是 4 张卡。
不是 TP x SP = 16 张卡。

NVIDIA 的 parallelism 文档把它描述为沿序列分布部分 Transformer 层的计算和 activation，并明确它是 TP 的扩展。

5.2 CP：完整上下文的切分#

Context Parallelism 会沿 sequence 维度切分网络输入和所有层的 activation。长度为 128K、CP=4 时，可以是：

GPU 0：Token 0   - 32K
GPU 1：Token 32K - 64K
GPU 2：Token 64K - 96K
GPU 3：Token 96K - 128K

Linear、LayerNorm 一类 token-wise 运算可在本地完成，困难集中在 Attention。对于局部 query $Q_i$ ，attention 仍需要全局的 $K$ 和 $V$ ：

O_i = \operatorname{softmax}(Q_iK^\top)V

因此实现 CP / long-context attention 时，需要 Ring KV exchange、All-Gather K/V、Ulysses All-to-All，或把 online softmax 的局部结果做分布式合并。Megatron Core 的 CP 文档清楚地区分了 CP 的“全部 activation”切分和早期 SP 的“部分 activation”切分。

Prefill 的 query length 很长，CP 的价值通常更明显。普通自回归 decode 每步的 query length 近似为 1，不能简单把当前 query 再按 sequence 分开；但历史 KV Cache 仍可按上下文分布，这类实现通常称为 KV Parallel、sequence parallel attention 或 distributed attention。

6. EP：MoE 中按 Expert 切分#

Expert Parallelism 只适用于 MoE 模型。若某一 MoE 层有 64 个 expert，EP=8：

GPU 0：Expert 0  - 7
GPU 1：Expert 8  - 15
...
GPU 7：Expert 56 - 63

每个 token 先经过 router：

e = \operatorname{TopK}(\operatorname{Router}(x))

再被发送到拥有对应 expert 的设备执行，最后把输出送回原 token 所在位置：

Token → Router → All-to-All dispatch → Expert GEMM → All-to-All combine

所以 EP 的标志性通信并不是 TP 常见的 All-Reduce，而是 All-to-All 或 All-to-All-v，以及 token permutation / unpermutation。SGLang 的 Expert Parallelism 文档也是按这一模型描述 expert 权重分布和动态 token 路由。

需要特别强调：**EP 不负责 Attention。**一个 MoE Transformer block 大致仍是：

Attention → MoE Router → Experts

于是同一组 GPU 在不同子层可以采用不同语义：Attention 使用 TP，MoE 部分使用 EP。这正是 MoE 并行比“只看一个 world size”更难理解的原因。

6.1 TP + EP 与 ETP#

EP 切的是 expert 数量；单个 expert 的 FFN 矩阵还可以用 TP 再切，这通常称为 Expert Tensor Parallelism（ETP）：

Attention：TP = 4
MoE：experts 按 EP 分布
每个 expert 内部：可选 ETP = 2

概念上，这分别切 $E$ 和 FFN hidden 维度。但它也可能产生一条昂贵的通信路径：All-to-All 分发 token，expert 内部 collective，再 All-to-All 合并。EP 或 ETP 不是越大越好；要同时看每个 expert 的 token 数、GEMM 规模和网络拓扑。

6.2 DP + EP 与 DPA#

普通 DP 中，副本相互独立；但超大 MoE 的所有 expert 若在每个副本都复制一遍，代价会很高。于是会出现 Data Parallel Attention（DPA）这样的映射：

Attention：按请求做 DP
Experts：同一批 rank 之间做 EP

例如八张卡上，每张卡保存自己请求的 attention 状态和 KV Cache；请求进入 MoE 层时，token 又会通过 All-to-All 路由到其它卡上的 expert。此时：

Attention 看起来像 DP。
MoE 又要求所有 EP rank 以相同 collective 次序协作。

所以 DP 和 EP 在数学维度上正交，在执行上却高度同步。没有真实请求的 rank 也可能需要 dummy forward 来保持 collective 对齐；这是 vLLM 在 DPA / EP 说明中强调的现实约束。更广泛地说，复杂 MoE 部署应画各组件的 process group，而不应只机械地把所有“并行度”相乘。

7. PD 分离：切的是推理阶段，不是模型组件#

一次自回归请求的关键路径是：

Prompt
  ↓
Prefill：完整 Transformer forward，生成初始 KV Cache
  ↓
传输或复用 KV Cache
  ↓
Decode：每一步仍是完整 Transformer forward，持续追加 KV Cache

PD 分离将两个阶段放到不同实例或 GPU pool：

Request → Prefill Pool → KV Cache → Decode Pool → output tokens

Prefill 的批量更大、更偏计算密集；decode 每步计算较小，却频繁读取 KV Cache，更偏显存带宽、调度延迟和 token 间隔稳定性。将它们解耦后，可以独立追求 TTFT 和 ITL / TPOT。上一篇 PD 分离已从 serving 视角讨论过这一点。

关键纠正是：

Prefill Pool：Embedding、Attention、FFN / MoE、LM Head，完整执行。
Decode Pool：Embedding、Attention、FFN / MoE、LM Head，完整执行。
 
跨阶段的主要状态：KV Cache。

因此，下面两种理解都不对：

Prefill = Attention，Decode = FFN
Prefill 只生成 KV，Decode 只读取 KV 而不跑模型

vLLM 的 Disaggregated Prefilling 文档说明了 Prefill 与 Decode 实例可以分别设置自己的 TP、PP 等策略，并通过 KV connector 传递状态。这正好说明 PD 是更高一层的资源放置维度，而不是替代模型内部并行的机制。

8. 为什么 EP 和 PD 基本正交#

将某层计算写成：

F_{\Phi, L}(X)

其中 $\Phi \in \{\text{Prefill}, \text{Decode}\}$ 是阶段，MoE 层内部另有 expert 维度 $E \in \{0, \ldots, N_{expert}-1\}$ 。

PD：切 Phi，决定请求的这个阶段在哪个资源池执行。
EP：切 E，决定这个阶段内哪个设备持有和执行 expert。

它们切不同下标，所以逻辑上正交。一个合理的系统可能是：

Prefill Pool：TP_P、PP_P、CP_P、EP_P
Decode Pool：TP_D、PP_D、KV Parallel_D、EP_D

两侧甚至可以不同：

Prefill：TP = 8，EP = 8，偏向大 batch 和长序列
Decode：TP = 4，DP = 2，EP = 8，偏向低 token 延迟和并发

这正是 PD 分离的实际价值之一：Prefill 的 expert token batch 往往更大，大 EP 和 grouped GEMM 容易利用起来；decode 每个 sequence 每步通常只有一个 token，过大的 EP 可能带来更小的消息和 GEMM，反而更容易被 All-to-All 延迟主导。

9. 逻辑正交不等于工程上互不影响#

EP 和 PD 虽然切不同维度，却至少有三类重要耦合。

9.1 两侧都需要完整 MoE 执行能力#

Decode 并不会跳过 router 或 expert。每生成一个 token，仍需要：

Attention → Router → Experts → LM Head

因此 Decode pool 必须拥有可用的 expert 权重和 EP 通信组，或采用能等价执行 expert 的其它部署方案。

9.2 KV Cache 布局需要兼容或 reshard#

若 Prefill 使用 TP=8，KV head 可能在八个 rank 上分片；Decode 使用 TP=4 时，需要的 KV 分片范围可能不同。KV 不能总是直接“同 rank 拷贝”：

Prefill 的 TP=8 KV shards
        ↓
All-to-All / reshard / connector-specific conversion
        ↓
Decode 的 TP=4 KV shards

GQA、MQA、MLA 的 KV 布局又会让这个问题更加具体。理论上两端可以异构并行，不表示任意 KV connector 都支持该布局转换；实际兼容性必须以推理框架和 connector 的能力为准。

9.3 EP 流量与 KV 传输会争抢网络#

MoE 的 dispatch / combine 是 EP All-to-All 流量；PD handoff 是可能很大的 KV Cache 流量。若它们共用 RoCE、InfiniBand、PCIe 或 NVLink 路径，就会竞争带宽与队列：

EP：token dispatch / combine
PD：KV Cache transfer

所以“正交”只说明切分语义不同，不能保证物理资源互不干扰。网络拓扑、通信调度与隔离策略常常决定系统能否从这类组合中得到理论上的收益。

10. 组合关系：先看语义，再看 process group#

下表适合作为快速心智模型。✅ 表示自然组合，△ 表示能组合但性能或同步强耦合，⊂ 表示常作为补充或子语义。

组合	关系	说明
TP + DP	✅	每个 DP 副本内部使用 TP
TP + PP	✅	层内 TP、层间 PP，经典 3D parallelism
TP + CP	✅	hidden 与 sequence 分别切分
TP + Megatron SP	⊂	SP 通常共用 TP group，补充分片 activation
TP + EP	△	attention 可 TP、expert 可 EP，单 expert 还可 ETP
TP + PD	✅ / △	两侧可各自配置 TP；KV 可能需要 reshard
DP + PP	✅	每个副本是一条 pipeline
DP + CP	✅	每个请求副本内部可继续切长上下文
DP + EP	△	DPA 中 rank 需同步参与 MoE collective
PP + CP	✅	layer 与 sequence 分别切分
PP + EP	✅	每个 pipeline stage 的 MoE 层可再 EP
CP + EP	✅ / △	sequence 分片后的 token 还要 expert routing
EP + PD	✅ / △	逻辑正交，但两端都跑 expert 且会共享网络
SP + CP	视定义而定	Megatron SP 与 CP 切分范围不同；广义 SP 有时是 CP 的别名

对于 dense 模型且各维度确实构成独立笛卡尔积时，经常会写：

N_{GPU} = DP \times TP \times PP \times CP

但这不是通用乘法公式。Megatron SP 往往复用 TP rank；DPA + EP 中，同一组物理 rank 在 Attention 层被解释为 DP，在 MoE 层又被解释为 EP。例如：

8 张 GPU：Attention DP = 8，MoE EP = 8
不等于 8 x 8 = 64 张 GPU。

因此，面对复杂 MoE 系统时，更可靠的描述方式是列出或画出 process group：

Attention TP group
Attention DP group
Expert EP group
Expert TP group
Pipeline group
Context group

然后再判断这些 group 是笛卡尔积、复用同一批 rank，还是互相嵌套。

11. 不要与这些概念混为一谈#

一些常见技术会和并行一起出现，但它们不是新的模型切分维度：

技术	本质
Continuous batching	动态 batch 调度
Chunked prefill	将长 prefill 分块调度
Prefix caching	复用已有 KV Cache
PagedAttention	KV Cache 内存管理
CUDA Graph	减少 launch 开销
Quantization	降低计算与存储成本
FlashAttention	Attention kernel 优化
KV offloading	存储层级优化
Speculative decoding	减少 target decode 步数

Speculative decoding 是其中最容易被叫作“并行”的一个。它让 draft 模型提出多个候选 token，再由 target 模型批量验证，切的是候选 token / 时间步，而不是 hidden、layer 或 expert。它可以和 TP、EP、PD 组合，但不必然需要额外 GPU；很多实现会在同一组设备上交替运行 draft 与 target。可参见 SGLang speculative decoding 文档。

同样，chunked prefill 与 PD 分离都试图降低 Prefill 对 Decode 的干扰：前者仍在同一 engine 内交织调度，后者把它们放到不同 engine 或 GPU pool。两者可以互补，也可能按 workload 二选一。

12. 用三个层次判断“是否正交”#

以后遇到新的并行名称，可以按三个层次检查。

第一层：数学维度#

它切的是请求、hidden、layer、sequence、expert，还是 phase？例如 EP 切 $E$ 、PD 切 $\Phi$ ，所以数学上正交；TP 切 $h$ 、PP 切 $L$ ，也正交。

第二层：Process group#

它们的 rank group 是笛卡尔积、嵌套，还是复用？TP + DP 往往是每个 DP replica 内部一组 TP ranks；DPA + EP 则复用物理 ranks，并在 MoE forward 上发生集体同步。

第三层：性能资源#

即使数学维度和 process group 都不同，它们仍可能争抢同一种资源：

TP All-Reduce 与 EP All-to-All 争抢节点内互联；
EP All-to-All 与 PD KV transfer 争抢 RDMA；
PP activation 与 CP KV exchange 争抢跨节点带宽；
Prefill 与 Decode 争抢 HBM、SM 和 scheduler。

因此不存在脱离拓扑、消息大小和调度的“完全无耦合”并行策略。正交是一种有用的建模语言，不是性能保证。

13. 一个完整的 MoE + PD 系统#

将上述概念放回生产系统，可以得到这样的结构：

                         Global Router
                         /             \
                        v              v
               Prefill Pool       Decode Pool
               - DP_P             - DP_D
               - TP / CP_P        - TP / KV Parallel_D
               - PP_P             - PP_D
               - EP_P             - EP_D
                         \        /
                         KV Cache

每个 pool 内部又可能是：

PP：切 Transformer layer
 
每个 PP stage：
  Attention：TP 或 DPA，可选 CP / KV Parallel
  MoE：EP，可选 ETP

这也是现代分布式推理的核心视角：不是为整个模型选择一个唯一的“并行方式”，而是为不同阶段、不同组件与不同张量维度建立相应的 process group，并让数据、KV Cache 和通信路径保持可用。

结语#

把问题压缩成一句话：

模型内并行回答“这一阶段的模型如何在多卡上计算”；
PD 分离回答“请求的不同推理阶段应由哪一组资源执行”。

所以 EP 与 PD 基本正交，是因为前者切 expert 维度，后者切执行阶段，而不是因为 Prefill 只算 Attention、Decode 只使用 KV Cache。两边都要执行完整 Transformer，也都可能运行 MoE expert；它们真正交接的是 KV Cache，并会在 KV 布局、网络带宽和阶段性 expert 负载上互相影响。

参考资料#

vLLM, Disaggregated Prefilling: https://docs.vllm.ai/en/stable/features/disagg_prefill/
vLLM, Data Parallel Deployment: https://docs.vllm.ai/en/latest/serving/data_parallel_deployment/
NVIDIA, Megatron Bridge Parallelisms Guide: https://docs.nvidia.com/nemo/megatron-bridge/latest/parallelisms.html
NVIDIA, NeMo Framework Parallelisms: https://docs.nvidia.com/nemo-framework/user-guide/25.07/nemotoolkit/features/parallelisms.html
NVIDIA, Megatron Core Context Parallelism: https://docs.nvidia.com/megatron-core/developer-guide/0.15.0/api-guide/context_parallel.html
SGLang, Expert Parallelism: https://docs.sglang.ai/advanced_features/expert_parallelism.html
NVIDIA, Megatron Core MoE: https://docs.nvidia.com/megatron-core/developer-guide/0.15.0/api-guide/moe.html
SGLang, PD Disaggregation: https://docs.sglang.ai/advanced_features/pd_disaggregation.html
Efficiently Serving Large Multimodal Models Using EPD Disaggregation: https://arxiv.org/abs/2501.05460
SGLang, Speculative Decoding: https://docs.sglang.ai/advanced_features/speculative_decoding.html