Efficient Decode Context Parallelism with vLLM for Long Context Workloads

发表时间: 2026-08 · Blog post by Seonghee Lee, Sungsoo Ha, Omri Almog (NVIDIA), Lucas Wilkinson (Red Hat AI) (blog.vllm.ai)

原文: https://blog.vllm.ai/blog/2026-08-07-decode-context-parallelism

作者/机构：Seonghee Lee, Sungsoo Ha, Omri Almog (NVIDIA), Lucas Wilkinson (Red Hat AI)

速读

一句话结论 本文在 vLLM 框架中实现了 Decode Context Parallelism (DCP) 技术，通过在序列维度切分 KV Cache 彻底解决了长上下文推理时的显存冗余瓶颈，在 8×B200 硬件上将长文本大模型的并发能力和单卡吞吐量提升了 3.2 倍。

要解决什么问题 长上下文（64K 到 1M tokens）推理在智能体应用中变得不可或缺，这会产生极其庞大的 KV Cache，而现有的张量并行（TP）机制在处理现代大模型时会遇到严重的显存冗余卡点。标准的 TP 是按注意力头来切分 KV Cache 的，每个 GPU 至少需要分到一个完整的头。然而，现代模型普遍采用分组查询注意力（GQA）或多头潜在注意力（MLA）架构，这两者都会触发 TP 的硬性下限。GQA 只有少量的 KV 头，而 MLA 更是将键值压缩成一个共享的低秩潜在向量，等效于全局只有一个 KV 头。当 TP 的并行度超过模型实际的 KV 头数量时，TP 就无法继续进行切分，只能在多个 GPU 之间完整复制同一个 KV 头的缓存。这种强制的显存复制导致 GPU 显存被迅速耗尽，系统无法接收更多的新请求，从而锁死了批处理大小的上限，最终导致并发量上不去、单 token 推理成本居高不下。

怎么做的 DCP 的核心思路是放弃按注意力头切分，改为在序列（上下文）维度对 KV Cache 进行切分。对于同一个请求的长序列，DCP 会将其按位置分块，让每个 GPU 只负责存储和读取该序列中某一段 token 的 KV Cache（例如对于 200K 的序列，4 张卡各存 50K）。这种设计直接绕开了 TP 依赖 KV 头数量的卡点，无论模型是 GQA 还是 MLA，随着 GPU 数量的增加，单卡上的 KV Cache 占用都会线性缩小，从而腾出显存来支撑更大的并发请求。在具体的解码阶段，DCP 的执行流程由三个关键部件构成。首先是 AllGather Q，因为每个 GPU 只计算了查询向量（Query）的片段，而注意力计算需要完整的 Query，所以通过通信在所有 GPU 上聚合出完整的单 token Query 向量（针对 MLA 架构，vLLM 支持在加载时复制 Query 投影矩阵来完全跳过这一步）。其次是 Compute，每个 GPU 使用完整的 Query 与自己本地存储的那部分 KV Cache 切片进行局部的注意力计算，在 vLLM 中这对应 MLA 的 k_up 操作或 GQA 的 tensor_broadcast 操作。最后是 AllGather + ReduceScatter，各 GPU 产出局部的注意力结果和 Log-Sum-Exp (LSE) 值，系统通过通信聚合这些局部结果，利用在线 Softmax 技巧根据 LSE 对局部结果进行重新加权和拼接，其核心合并逻辑可以表示为：

$$O = \sum_{i=1}^{N} \frac{\exp(LSE_i)}{\sum_{j=1}^{N} \exp(LSE_j)} O_i$$

随后通过 ReduceScatter 将最终结果求和，并把属于各个 GPU 负责的注意力头切片分发回去。

效果如何 实验在单节点 8×B200 GPU 上进行，测试模型为采用 NVFP4 精度的 Kimi K2.6，对比基线是采用标准张量并行（TP）且 KV Cache 存在跨卡复制的传统部署方案。测试数据使用 Mooncake 格式的真实长上下文多轮智能体轨迹数据集，输入长度中位数约 67K，呈现双峰分布（53% 的请求超过 64K，约 8% 超过 128K，3% 到 4% 超过 256K），输出长度较短约为 400 tokens。量化结果显示，基线 TP 方案在并发数达到 64 时显存占用就达到了 100% 并撞上性能墙，单卡吞吐量停滞在 1863 tok/s/GPU；而 DCP 方案能够持续扩展，在并发数达到 512 时，显存占用仅为 82%，单卡吞吐量飙升至 6091 tok/s/GPU。在按序列长度（小于 32K 到大于 200K）的分组对比中，DCP 在 200K 以上的超长上下文区间依然保持了高且稳定的吞吐量与交互延迟帕累托前沿，而基线在此区间因显存耗尽完全无法扩展。该方法的局限在于其并行度设置受到模型架构的严格约束：对于 MLA 模型，TP 并行度必须是 DCP 并行度的整数倍；对于 GQA 模型，DCP 只能利用原本会产生冗余复制的那些副本，其并行度上限不能超过 TP 并行度与 KV 头数量的商，即必须满足 (TP // num_kv_heads) % DCP == 0。

A1 主要贡献

长上下文推理在智能体AI（Agentic AI）领域正变得至关重要，因为AI助手需要对庞大的代码库和冗长的聊天记录进行推理。目前的智能体追踪基准测试运行范围已从64K一直延伸至1M（100万）个Tokens，这导致其KV缓存（KV Cache）也相应地变得极其巨大。在基准的张量并行（Tensor-Parallel, TP）设置下，KV缓存是按照注意力头（attention head）进行分区的，这就为其能够缩减的程度设定了一个硬性下限。

现代模型通常使用两种注意力机制之一，但两者都会触及上述下限：

  1. 分组查询注意力（GQA）模型：仅存储少量的KV头，而张量并行（TP）最多只能将KV缓存拆分到每个GPU一个头的程度。一旦TP规模超过了KV头的数量，缓存就会开始在各个GPU之间产生重复复制。
  2. 多头潜在注意力（MLA）模型：情况更为严重。MLA将键/值（Key/Value）压缩成一个单一的低秩潜在向量（latent vector），该向量在所有的查询头之间共享，因此它实际上只有一个KV头。在常规的TP下，没有多个头可供拆分，这意味着潜在KV缓存会在每一个TP节点（rank）上被完整地复制。

在上述两种情况下，重复的KV缓存会大量吞噬GPU内存，导致几乎没有空间来服务额外的请求。这限制了系统能够处理的并发请求数量，从而降低了吞吐量并推高了每个Token的成本。

核心创新与目标：
本文重点介绍并深入分析了vLLM框架中的解码上下文并行（Decode Context Parallelism, DCP）技术。DCP通过将KV缓存沿着序列维度在多个GPU之间进行切片，使得每个GPU只存储和读取KV缓存的一部分。这一设计释放了GPU内存，允许每个GPU承担更多的请求，从而在更大的批处理大小（batch size）下运行。在配备高带宽GPU间互联的系统上，DCP能够在同时服务多个长上下文智能体的同时，保持交互的响应性。随着长上下文智能体用例的兴起，DCP带来的收益比以往任何时候都更加具有现实意义。

DCP与TP对比示意图
DCP与TP对比示意图

A3 背景知识/关键Observation/设计原则

长上下文服务的挑战与张量并行（TP）的局限性。在张量并行（Tensor Parallelism, TP）机制下，KV缓存是严格按照注意力头（attention head）进行划分的。每一个KV头拥有其自身独立的K和V张量，而注意力头是能够分配给GPU的最小单元。标准的张量并行机制并不具备对单个注意力头的KV缓存进行切片的机制。因此，如果模型总共有$K$个KV头，系统可以将这些头的不同子集分配给不同的GPU，但这种划分的下限是每个GPU至少持有一个完整的KV头。一旦张量并行的规模（TP size）超过了$K$，系统中就没有足够多独立的KV头可供分配，这就导致两个或更多的GPU最终只能持有同一个KV头的KV缓存副本，而不是一个独一无二的切片。

A2 方法细节

解码上下文并行（DCP）的核心概念。与纯张量并行（TP）方法不同，解码上下文并行（Decode Context Parallelism, DCP）能够沿着序列（上下文）维度将KV缓存拆分到不同的GPU上。每个GPU被分配负责处理来自同一序列中一部分Token位置的KV缓存。例如，对于一个包含20万（200K）Token的单个请求，GPU 0可能持有第0到50K个Token的缓存，GPU 1持有50K到100K的缓存，GPU 2持有100K到150K的缓存，而GPU 3持有150K到200K的缓存。通过对KV缓存进行分片，每个GPU上的KV缓存占用量会随着GPU数量的增加而持续缩小，从而释放出大量内存，使系统能够提高批处理大小（batch size）并服务于更高的并发请求。
解码上下文并行KV缓存切片示意图

解码上下文并行（DCP）的处理流程。标准的解码上下文并行保持了简单的通信模式，遵循AllGather Q → Compute → AllGather + ReduceScatter的固定节奏。

  • 查询向量的全收集（AllGather Q）。每个GPU仅计算了查询（query）向量的一个片段，但注意力机制要求使用完整的查询向量来与任何键（key）进行评分计算。因此，需要在整个DCP组内进行一次全收集（all-gather）操作，从而在每个GPU上组装出一份完整的查询向量副本。在解码（decode）阶段，这一操作的通信开销非常低，因为查询仅仅是一个单一的Token。此外，作为多头潜在注意力（MLA）的一种可选替代方案，https://github.com/vllm-project/vllm/pull/45964 允许在模型加载时，在每个DCP组内复制（较小的）查询投影（query projection），这样在解码阶段就可以完全跳过这个查询向量的全收集步骤（通过设置环境变量VLLM_DCP_Q_REPLICATE=1）。
  • 注意力计算（Compute）。每个GPU在收集到的完整查询向量与其本地存储的KV缓存切片之间执行注意力计算。在vLLM的实现中，对于MLA模型这一步调用的是k_up操作，对于GQA模型这一步调用的则是tensor_broadcast操作。
  • 结果聚合（AllGather + ReduceScatter，即cp_lse_ag_out_rs）。各个GPU计算出的局部结果需要被合并成最终的真实输出。首先，AllGather操作会共享每个GPU的局部输出和对数求和指数（Log-Sum-Exp, LSE）；随后，LSE值被用于对这些局部结果进行重新加权和合并（即在线Softmax技巧，online-softmax trick）；最后，ReduceScatter操作将这些结果进行求和，同时只将每个GPU自身对应的注意力头切片返回给该GPU。

vLLM中的DCP配置参数。在vLLM中启用DCP非常简单，只需要在现有的张量并行设置之外，添加一个额外的参数：decode_context_parallel_size。

离线推理（Offline）使用方式。在Python脚本中进行离线推理时，可以直接在LLM初始化时传入相关参数。

from vllm import LLM, SamplingParams
 
prompts = [
    "The future of AI is",
]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
 
llm = LLM(
    model="deepseek-ai/DeepSeek-V2-Lite",
    tensor_parallel_size=2,
    decode_context_parallel_size=2,
)
outputs = llm.generate(prompts, sampling_params)

在线服务（Online）使用方式。在命令行启动vLLM服务时，通过添加对应的flag即可启用。

vllm serve deepseek-ai/DeepSeek-V2-Lite \
    --tensor-parallel-size 2 \
    --decode-context-parallel-size 2

MLA后端支持模型。目前支持的模型包括DeepSeek-V2 / V3 / R1，以及使用多头潜在注意力（Multi-head Latent Attention）的Kimi K2.6模型。

MLA模型的特殊性分析。MLA架构将键/值（Key/Value）压缩成一个单一的低秩潜在（latent）向量，该向量在所有的查询头（query heads）之间共享——这实际上相当于只有一个KV“头”。在纯张量并行（TP）下，由于没有多个头可供拆分，这种潜在KV缓存会在每一个TP rank上被完整地复制。TP无法缩小其内存占用，这使得MLA成为使用DCP的最理想候选者：因为整个缓存都是冗余的，所以整个缓存都可以按序列维度进行拆分。

MLA后端的DCP工作机制与约束条件。DCP沿着序列维度对潜在KV缓存进行分片，因此每个rank只存储其对应的一块潜在向量；在执行注意力计算时，每个rank会对其持有的潜在切片进行向上投影（up-project，即k_up步骤），以重建其所需的Keys/Values。由于有效的KV头数量为1，序列可以被拆分到与完整TP度相同的级别。因此，配置时需要满足以下约束条件：tensor_parallel_size >= decode_context_parallel_size，且tensor_parallel_size % decode_context_parallel_size == 0。

vllm serve deepseek-ai/DeepSeek-R1 \
    --tensor-parallel-size 8 \
    --decode-context-parallel-size 8

GQA后端支持模型。示例模型包括Qwen3-235B，以及其他采用分组查询注意力（Grouped-Query-Attention, GQA）机制的模型（如Llama系列等）。

GQA模型的特殊性分析。GQA模型存储了num_key_value_heads个KV头，而TP首先会按照这些头对KV缓存进行拆分。这种拆分方式只有在TP大小不超过num_key_value_heads时才能干净利落地工作；一旦tensor_parallel_size超过了该数量，KV缓存就开始产生重复，在不同的rank之间会出现tp // num_key_value_heads份完全相同的副本。

GQA后端的DCP工作机制与约束条件。DCP利用了这些本应重复的副本，转而用不同的序列块（sequence chunks）来填充它们，同时在它们的查询头之间广播共享的KV头（即“GQA的张量广播”步骤）。因此，序列拆分的程度受到重复因子tp // num_key_value_heads的上限限制，需满足以下约束：(tensor_parallel_size // num_key_value_heads) >= decode_context_parallel_size，且(tensor_parallel_size // num_key_value_heads) % decode_context_parallel_size == 0。

# Qwen3-235B has num_key_value_heads = 4; tp=8 gives 8//4 = 2 redundant copies,
# so dcp can be up to 2.
vllm serve Qwen/Qwen3-235B-A22B \
    --tensor-parallel-size 8 \
    --decode-context-parallel-size 2

A4 实验环境与实验结果

实验环境

  • 硬件配置：单节点 8 × NVIDIA B200 GPU。
  • 软件与模型：使用vLLM部署Kimi K2.6模型，采用NVFP4数据格式。
  • 数据集：采用公开的智能体长上下文追踪数据集（Mooncake trace格式，包含input_length、output_length和hash_ids字段，适用于基准测试KV缓存重用和前缀缓存行为）。
  • 负载特征：这是一个反映现实长周期智能体行为的多轮对话负载。输入长度中位数约为67k Tokens，输出较短（约400 Tokens）。输入分布呈双峰状：约53%的请求在64k以上（长尾达到约1M Tokens），约47%在中短区间（低于64k，其中18%低于8k）。约8%的请求超过128k，3-4%的请求超过256k。

实验结果

1. DCP与基准TP的整体性能对比

  • 实验内容：在固定模型、硬件和工作负载的前提下，仅改变解码期间KV缓存的分片方式（Baseline TP vs DCP），并扫描请求并发数（从16到512）。
  • 实验结果：基准TP由于在每个GPU上复制KV缓存，其内存在并发数达到64时迅速耗尽（100%），吞吐量在1,863 tok/s/GPU附近遇到瓶颈。相比之下，DCP通过沿序列维度分片KV缓存，在并发数达到512时，吞吐量飙升至6,091 tok/s/GPU，且此时KV缓存使用率仅为82%。
  • 分析结论：DCP的核心价值在于能够维持极高的并发量。特别是在长上下文运行中，基于复制KV的TP方法会率先耗尽内存，而DCP能够持续扩展，在整个吞吐量-交互性帕累托前沿上提供显著更高的单GPU吞吐量。
    TP与DCP吞吐量-延迟帕累托前沿对比
    TP与DCP不同并发下的系统性能指标
    并发度扫描详细数据表格

2. 按序列长度分类的性能比较

  • 实验内容：将请求按总序列长度（输入+输出）分为五个区间（<32k, 32–64k, 64–128k, 128–200k, 200k+），绘制吞吐量-交互性帕累托前沿图，以观察性能随上下文长度的变化。
  • 实验结果：即使在200k+的极端长度范围内，DCP依然保持了高且稳定的前沿曲线，短区间和长区间的曲线几乎重合。
  • 分析结论：在基准TP因内存不足而无法扩展的长上下文长度下，DCP使得吞吐量能够随着并发数的增加而扩展，同时保持了可用级别的单用户响应速度。
    不同序列长度下DCP与TP的性能对比图

A5 结论

研究结论：
解码上下文并行（DCP）代表了对长上下文推理中GPU组织方式的根本性重新思考。DCP不再强迫GPU复制KV缓存或处于未充分利用的状态，而是让每个GPU都发挥作用：在注意力计算期间对序列进行切片，然后立即重新配置这些相同的GPU，以在整个资源池中分摊FFN权重的加载。其结果是构建了一个能够随着上下文长度优雅扩展的系统，而不是在长上下文下性能退化。凭借vLLM中的原生支持，DCP已准备好以生产环境所需的吞吐量和延迟，为下一代长上下文智能体应用（从文档推理到多会话智能体流水线）提供强大动力。

未来工作（Future Work）展望：

  1. 细粒度并行控制：为TP和DCP添加更细粒度的并行大小支持，让用户能更精确地控制并行布局，回收因过度分片而损失的效率。
  2. 通信内核优化：为多节点和单节点环境开发更好的DCP全对全（A2A）通信内核，随着上下文长度和设备数量的增加，减少暴露的通信时间并改善与计算的重叠。
  3. 新特性兼容：提供对多Token预测（MTP）和推测解码（speculative decoding）的更好支持，确保DCP在提升效率的同时不牺牲推测方法的延迟优势。
  4. 分离式服务：加固预填充/解码（P/D）分离支持，使DCP在分离式服务部署中更加健壮。
  5. 生态扩展：将支持扩展到更广泛的后端类型，并与混合模型和动态分块流水线并行（Dynamic Chunked Pipeline Parallelism）集成；将DCP扩展至GLM-5.2和Kimi K3等更多模型，并推进预填充上下文并行（Prefill Context Parallelism, PCP）的长期路线图。

A7 补充细节

致谢与历史贡献。特别感谢NVIDIA团队的Anahita Bhiwandiwalla、Xin Li、Pavani Majety、Nidhi Bhatia、Roman Ageev、Pen Chung Li和Chris Hoge在整个研究过程中的审查、基准测试支持和工程投入。同时感谢Moonshot AI在https://github.com/vllm-project/vllm/pull/23734中向上游提交的初始解码上下文并行（DCP）工作，以及Lucas Wilkinson提供的实质性后续贡献，这些贡献帮助加固并扩展了DCP。作者还感谢了更广泛的vLLM社区，其开源引擎和持续合作使得此次基准测试工作成为可能。关于DCP部署的更多信息及相关历史，可参考https://docs.vllm.ai/en/latest/serving/context_parallel_deployment/#decode-context-parallel。

测试环境重申与未来基准测试计划。本文中的DCP测试结果是在NVIDIA B200 GPU上使用NVFP4精度的Kimi K2.6模型测量得出的，这些配置可以通过当前支持--decode-context-parallel-size参数的vLLM发布版本进行复现。团队目前正在针对Kimi K3模型进行DCP性能基准测试，并计划在该工作成熟后分享相关结果。