跳到主要内容

Decode 阶段 CP

KV 容量墙怎么逼出 KV 分片、pass-Q 为何比传 KV 量小几个数量级

核心要点：

  • decode 不需要 CP 只在 KV 装得下时成立
  • 1M 上下文 KV 单卡装不下，decode 必须切 KV
  • pass-Q: decode 传 query 而非 KV，量小几个数量级
  • 触发由 KV 容量墙 + HBM 带宽墙共同逼出
  • Helix 用层内时序流水解 KV+FFN 双瓶颈

名词定义​

名词定义
KV 容量墙KV cache 总量超过单卡可用显存，强制 decode 把 KV 切到多卡
HBM 带宽墙decode 每步读全量 KV，读取耗时由 HBM 带宽决定，构成 TPOT 下界
Helix 时序流水 (temporal pipeline)层内把 attention 与 FFN 用不同并行策略，同组 GPU 复用，消除空闲

pass-KV / pass-Q / CP 等共享名词见 7.1 总览 名词定义。本篇与 9.3 推理部署模式 划界：本篇讲序列切分后 decode 怎么跨卡算 attention, 09 讲 prefill/decode 部署架构 （共驻/解耦/KV 迁移）。

decode 阶段真的不需要 CP 吗？​

「decode 不需要 CP」只在 KV 装得下单卡时成立；1M 上下文 KV 单卡装不下时，decode 必须把 KV 切到多卡。

常见说法是 decode 阶段每步只生成 1 token, KV 已在本地、无需跨卡 attention 通信。这个结论的隐含前提是「每卡持有完整 KV」。前提在短上下文下成立：KV 体量小，配合 TP 切 head 即可单卡放下，decode 在本地完成。

前提在 1M 上下文下失效。KV cache 与序列长度线性，即便用 MLA 压缩，1M 上下文的 KV 仍达数十 GB 量级 [估算：V3 风格 MLA 每 token 每层约 1 KB, 61 层 1M token ≈ 70 GB]，加上模型权重后单卡放不下。KV 必须沿序列切到多卡，decode 就要做跨卡 attention — 这就是 decode 阶段的 CP。

decode CP 怎么传 Q 不传 KV (pass-Q)?​

decode CP 传 query 而非 KV，因为 decode 每步只有 1 个 query token，数据量比全量 KV 小几个数量级。Meta 把 prefill 与 decode 的 ring attention 分成 pass-KV 与 pass-Q 两个 lossless exact 变体[1]:

  • Pass-KV (prefill)：输入 token 切到各 CP rank，各 rank 算本地 Q/K/V，然后 K/V 在 rank 间交换，完成跨全上下文的 attention
  • Pass-Q (decode)：各 rank 持本地 KV 段，query 在 rank 间传递；每 rank 用本地 KV 段算 partial attention，再用 online softmax 合并

通信量对比清晰：pass-KV 每步传 $S/N$ 个 K/V （GB 级），pass-Q 每步传 1 个 query 向量 （KB 级）。decode 阶段 query 远小于 KV，所以「传 Q 不传 KV」把通信量压到极低。

Meta 还用启发式动态选择：按 KV cache miss rate （已缓存 KV 与新增 token 的相对规模），决定该步用 pass-KV 还是 pass-Q[1]。

pass-KV 与 pass-Q 的交叉阈值在 5% miss rate。Meta 在 H100/CP4/Llama3-405B 上的实测：

KV miss rate新 tokenspass-KV TTFT (ms)pass-Q TTFT (ms)赢家
1.0%1,2801023899pass-Q (-12%)
2.5%3,20011101046pass-Q (-6%)
3.25%4,16012991280pass-Q (-1.4%)
5.0%6,40013061302持平
10.0%12,80020812205pass-KV (-6%)
20.0%25,60033533617pass-KV (-7%)
50.0%64,00068457368pass-KV (-7%)
100.0%128,0001146212361pass-KV (-7%)

@tbl-par-cp-dec-crossover pass-KV vs pass-Q 交叉阈值实测 (H100 CP4 Llama3-405B)

交叉点的物理含义：低 miss rate 时新增 KV 少，传 Q（KB 级）比传 KV（GB 级）划算；高 miss rate 时 pass-KV 的计算量足够大（1608 μs），SendRecv（631 μs）被完全掩盖，而 pass-Q 的 All2All（1023 μs）仍暴露[1]。理论阈值 $2 \cdot N_{\text{KV}} / N_H = 12.5\%$，实测交叉更低（5%），因为 pass-KV overlap 在中等 miss rate 已生效。

decode CP 什么时候触发？​

decode CP 的并行度下界由 KV 容量墙与 HBM 带宽墙共同逼出，1M 上下文下这个下界必然大于 1。

容量墙给出硬下界：KV 切分卡数 $N_d$ 至少要让每卡 KV 装得下。

$$\begin{equation} N_d \geq \frac{M_{\text{KV}}}{C_{\text{chip}} - W_{\text{chip}}} \label{eq:par-cp-dec-capacity} \end{equation}$$
  • $M_{\text{KV}}$: KV cache 总量 (与 $S$ 线性)
  • $C_{\text{chip}}$：单卡 HBM 容量
  • $W_{\text{chip}}$：单卡权重与其他占用

带宽墙给出 TPOT 下界：decode 每步读全量 KV，读取耗时由聚合 HBM 带宽决定。

$$\begin{equation} \text{TPOT} \geq \frac{M_{\text{KV}}}{N_d \cdot B_{\text{HBM}}} \label{eq:par-cp-dec-tpot} \end{equation}$$

切到 $N_d$ 卡，每卡读 $M_{\text{KV}}/N_d$, TPOT 随 $N_d$ 下降。这是 decode CP 的核心价值：用更多卡的聚合 HBM 带宽并行读 KV，把 TPOT 压到延迟目标内，pass-Q 的网络通信只是为这个并行读付的过路费。

CP 改善 prefill 延迟，但会让 decode 延迟回退，因此业界常把 prefill 与 decode 解耦，两阶段用不同并行策略 (见 9.3 推理部署模式)。

Helix 怎么解 decode 的 KV + FFN 双瓶颈？​

Helix Parallelism 把 decode 的两个瓶颈 （读长 KV、加载 FFN 权重） 拆到层内时序流水的两段，同组 GPU 在两段用不同并行策略[2]。

多百万 token decode 同时受两个瓶颈压制：attention 读取长 KV cache, FFN 加载权重。两者的最优 sharding 不同，用单一并行策略会让一段成为另一段的拖累。

Helix 的做法是层内 temporal pipeline:

  • Attention 段：用 KV parallelism 把 KV cache 分片到多卡，缓解 KV 读取瓶颈
  • FFN 段：同一组 GPU 复用为 TP (dense) 或 TP×EP (MoE)，缓解权重加载瓶颈

通过给 attention 与 FFN 解耦并行策略、复用同一 GPU 池，Helix 消除阶段间空闲，在相同延迟约束下支持 32× 并发用户[2]。Helix 的 A2A 通信切换量与序列长度无关（仅 ∝ batch × hidden dim），HOP-B 在 batch 维度 overlap A2A 与 attention 计算。

Helix 已在 vLLM 落地：Helix A2A backend (PR #34883) 已合并，用 All-to-All 替代 AllGather+ReduceScatter，在 GB200 NVL72 上验证，NVSwitch 系统上延迟更低。

业界 decode CP 进展到哪？​

decode CP 是 2024-2025 的活跃工程方向，主流推理框架都在补：

系统 / 工作decode 阶段做法状态
Meta CP[1]pass-Q ring 变体，动态选 pass-KV/pass-Q （交叉阈值 ~5%）已发表，Llama3-405B 生产
NVIDIA Helix[2]KV parallelism + 层内时序流水复用 GPU已发表 (2025-07), vLLM A2A backend 已合并
DeepSeek V4MLA 压缩后 KV 仅 V3 的 ~10%, decode 对 CP 依赖大幅降低；prefill 用 round-robin token 分片生产 (2026-04)
vLLMDCP (Decode CP) 已合并；PCP (Prefill CP) 活跃开发；vllm-ascend 后端已支持多 PR 开发中
SGLangChunked PP （3.31× prefill 吞吐）；Q2 CP roadmap (#21788) ~20 PR多 PR 开发中
Untied Ulysses[3]Headwise chunking，中间 tensor -87.5%, 5M tokens on 8×H100ICML 2026
NanoCP[4]Request-level dynamic CP，吞吐 +3.27×, MoE 通信解耦arXiv 2026-05

@tbl-par-cp-dec-frameworks decode 阶段 CP 的业界进展

Takeaway​

知识点核心结论
前提澄清「decode 不需要 CP」只在 KV 装得下时成立
触发场景1M KV 单卡装不下 → decode 必须切 KV
pass-Qdecode 传 query （KB 级） 而非 KV （GB 级）
触发下界容量墙 + 带宽墙共同逼出 $N_d > 1$
Helix层内时序流水解 KV 读取 + FFN 加载双瓶颈

@tbl-par-cp-dec-takeaway decode 阶段 CP 核心知识点

参考资料​

  1. Meta, Context Parallelism for Scalable Million-Token Inference, arXiv:2411.01783, 2024. https://arxiv.org/abs/2411.01783
  2. NVIDIA, Helix Parallelism: Rethinking Sharding Strategies for Interactive Multi-Million-Token LLM Decoding, arXiv:2507.07120, 2025. https://arxiv.org/abs/2507.07120
  3. Ghadia et al., Untied Ulysses: Rethinking Sequence Parallelism with Headwise Chunking, ICML 2026, arXiv:2602.21196. https://arxiv.org/abs/2602.21196
  4. NanoCP: Request-Level Dynamic Context Parallelism for MoE, arXiv:2605.21100, 2026. https://arxiv.org/abs/2605.21100

延伸阅读​