vLLM 的 DCP：为长上下文推理解开 KV 缓存内存瓶颈

导语

长上下文不再只是模型能力展示，而是智能体系统的日常负载：代码仓库、长对话历史、多轮工具调用轨迹，动辄达到数万甚至上百万 token。vLLM 最新博客重点解释了 Decode Context Parallelism（DCP）为何会在这一场景变得重要：真正拖住吞吐的，往往不是计算本身，而是解码阶段不断膨胀的 KV cache。

核心要点

• 传统 TP 的切分边界有限：张量并行通常按注意力头划分 KV cache。对于 GQA 模型，KV 头数量本来就少；当并行度超过 KV 头数后，缓存会在多张 GPU 间重复。对于 MLA 模型，Key/Value 被压缩成共享的低秩 latent，几乎没有可按头继续切分的空间，因此复制问题更明显。
• DCP 改为按序列维度切 KV cache：同一个长请求的 token 缓存可以分布在多张 GPU 上。例如 200K token 的上下文可被拆成多个位置区间，每张 GPU 只负责其中一段。这样每卡缓存占用随 GPU 数增加而下降，释放出的显存可用于更大 batch 和更高并发。
• 解码通信开销相对可控：DCP 的流程包括收集 query、各卡在本地 KV 分片上计算注意力，再合并部分结果。由于 decode 阶段 query 只是单 token，相关通信成本相对可承受。对于 MLA，vLLM 还提供可选的 query projection 复制方式，以减少一次 query all-gather。
• 长上下文收益最明显：博客在单个 8×B200 节点上使用 Kimi K2.6、NVFP4 和 vLLM 进行测试。基线 TP 在并发 64 时 KV 使用率触顶，吞吐停在约 1,863 tok/s/GPU；DCP 在并发 512 时仍保持 82% KV 使用率，并达到 6,091 tok/s/GPU。按博客结论，这相当于长上下文智能体负载下约 3 倍吞吐提升。

意义与影响

DCP 的价值不在于让单个长请求“神奇变快”，而在于让服务端在长上下文条件下还能装下更多请求。对于智能体产品，这意味着同样硬件可以承载更多并发会话，同时保持可用的交互速度；对于云推理成本，则意味着复制型 KV cache 带来的显存浪费有机会被削减。

更值得注意的是，DCP 与当前模型架构趋势高度相关。GQA 和 MLA 都在减少 KV 表示规模，但也让“按头切分”的传统并行方式更早触及下限。vLLM 把 KV cache 改为按上下文维度分片，实际上是在为长上下文服务提供另一条扩展路径。随着智能体轨迹从 64K 扩展到 1M token，推理框架对缓存布局、GPU 间互联和批处理策略的优化，将越来越接近产品体验和成本结构的核心。

来源：vLLM Blog