vLLM 长上下文推理新范式Decode Context Parallelism 底层原理与性能实测引言长上下文正在成为 Agent 时代的硬通货2026 年的 LLM 推理战场早已不是谁能生成的问题而是谁能低成本地处理百万 token 上下文的问题。智能体Agent要读完整代码仓库、翻遍长对话历史、在多轮工具调用中保持记忆Agent 基准的输入长度已经从 64K 一路拉到 1M token。上下文一长KV Cache 就成了第一瓶颈——它不参与计算却占用大量显存直接影响并发能力和单 token 成本。8 月 7 日vLLM 官方博客发布了一篇深度技术文章《Efficient Decode Context Parallelism with vLLM for Long Context Workloads》系统阐述了Decode Context ParallelismDCP解码上下文并行的原理与实测数据在 8×B200 节点上服务 Kimi K2.6DCP 能把吞吐从张量并行TP的 ~1,863 tok/s/GPU 拉到6,091 tok/s/GPU并发数从 64 直接干到 512 还只用掉 82% 的 KV 显存。这篇博客虽然只是 vLLM 众多更新中的一个但它代表了对长上下文推理底层组织方式的重新思考。本文带你把它拆开看透。一、问题根源TP 下 KV Cache 的按头切分天花板要理解 DCP先得明白传统张量并行Tensor Parallelism, TP在长上下文场景下为什么卡脖子。自回归解码时模型需要把历史 token 的 Key/Value 缓存下来供注意力计算使用这就是 KV Cache。在 TP 部署中KV Cache 是按注意力头attention head切分的每个 KV head 拥有独立的 K/V 张量head 是分发给 GPU 的最小粒度。问题在于现代模型的注意力机制恰恰在压缩 KV head 数量GQA分组查询注意力Qwen、Llama 家族等模型只保留少量 KV head如 Qwen3-235B 只有 4 个。TP 最多把 KV Cache 切到每 GPU 一个 head一旦 tensor_parallel_size 超过 KV head 数量就会有两个 GPU 持有同一份 KV head 的副本——缓存开始复制。MLA多头潜在注意力DeepSeek-V2/V3/R1、Kimi K2.6 等模型把 Key/Value 压缩进一个共享的低秩潜在向量等效 KV head 数 1。在纯 TP 下没有头可分潜在 KV Cache 被完整复制到每一张卡上。后果是致命的KV 复制吃掉显存能塞进 GPU 的并发请求数被锁死吞吐上不去、单 token 成本飙升。长上下文请求的 KV Cache 动辄几百 GB复制一份就是翻倍的开销。二、为什么偏偏是 Decode 阶段需要救先厘清一个概念大模型推理分两个阶段瓶颈完全不同。Prefill预填充用户输入一次性进来模型并行消化所有输入 token产出第一个输出 token。这个阶段计算密集、GPU 利用率高核心指标是 TTFT首字时延。长上下文下 Prefill 的痛点是一次算太多解法是让计算摊到更多 GPU 上Prefill Context Parallelism。Decode解码模型逐个生成 token每步只算一个 token但每步都要读一遍整条序列的 KV Cache。这个阶段是访存密集memory-bound的GPU 算力吃不满核心指标是 TPOT/ITL每 token 输出间隔。长上下文下 Decode 的痛点是KV Cache 太大塞不下并发。DCP 专治 Decode它不动 Prefill 的计算划分只在解码时把 KV Cache 按序列切到多卡上。这也是为什么它叫DecodeContext Parallelism——与面向 Prefill 的 PCPPrefill Context ParallelismvLLM 路线图中已有规划正好互补。再算一笔账感受一下 KV Cache 的量级。对 MLA 模型单条请求的潜在 KV Cache 大致为 2 × seq_len × latent_dim × bytes。以 latent_dim 512、FP81 字节为例一条 1M token 的请求就要吃掉约 1GB 显存如果这条请求横跨 1M 上下文8 卡 TP 下每人复制一份就是 8GB。而 DCP 按序列切分后每卡只存 1/8省下的显存足够再接纳 7 条同量级的并发请求——并发能力直接乘 8这就是吞吐跃升的数学根源。三、DCP 的核心思想按序列维度切 KVDCP 的思路非常直接既然按头切会遇到下限那就按序列context维度切。对一条 200K token 的请求4 卡 DCP 的分配方式是这样的GPU 0 持有 token 0–50K 的 KVGPU 1 持有 50K–100KGPU 2 持有 100K–150KGPU 3 持有 150K–200K。每张卡只存整条序列 KV 的 1/N。这样做的好处是加卡KV 单卡占用线性下降省出来的显存全部用于提升 batch size、接纳更多并发请求。在高带宽 GPU 互联NVLink、NVSwitch上多用户长上下文 Agent 服务的交互延迟依然可控。四、通信模式AllGather Q → Compute → AllGather ReduceScatterDCP 的解码过程遵循一个固定的三步节奏值得逐行理解Step 1AllGather Q。每张卡只算出了 query 的一个分片但注意力打分需要完整的 query 向量因此要在 DCP 组内做一次全收集。解码阶段 query 只有一个 token通信量极小几乎可以忽略。MLA 场景还有一个可选项通过 VLLM_DCP_Q_REPLICATE1vLLM PR #45964在加载时复制 query 投影解码时直接跳过这次 AllGather。Step 2Compute本地注意力。每张卡用完整 query 和本地 KV 切片做注意力计算。MLA 后端对应 k_up 步骤把潜在向量局部上投影还原出 K/VGQA 后端对应 tensor_broadcast共享 KV head 广播到对应的 query head。Step 3AllGather ReduceScatter。每张卡的注意力输出只是部分和只覆盖自己那段序列需要合并成真实输出。这里用到online-softmax 技巧各卡把自己的部分输出和 log-sum-expLSE全收集用 LSE 对部分结果重新加权合并再 ReduceScatter 把每个 head 的结果片归还给对应 GPU。下面用一段极简的 Python 演示 online-softmax 合并的数值逻辑让你直观感受为什么部分和能精确合并import math # 模拟 4 个 GPU 各自负责的序列片段上的注意力输出 # 每片返回: (部分加权和 numerator, 部分 softmax 分母 logsumexp) def online_softmax_merge(partials): partials: list of (weighted_sum_vec, lse) m -math.inf num None for n_i, lse_i in partials: # 经典 online-softmax: 用新片段的 LSE 更新全局最大值 m_new max(m, lse_i) if num is None: num n_i * math.exp(lse_i - m_new) else: num num * math.exp(m - m_new) n_i * math.exp(lse_i - m_new) m m_new return num / math.exp(m) # 模拟: 4 张卡, 各自对 200K 序列的 1/4 做 attention, d_model8 import random random.seed(42) d 8 partials [] for _ in range(4): n_i [random.random() for _ in range(d)] lse_i random.uniform(-2, 2) partials.append((n_i, lse_i)) merged online_softmax_merge(partials) # 对照: 直接把 4 段拼成完整序列, 一次性算 softmax seq [] for _ in range(4): scores [random.random() for _ in range(16)] # 每段 16 个 key seq.extend(scores) m_full max(seq) ref [math.exp(s - m_full) for s in seq] ref_sum sum(ref) expect [r / ref_sum for r in ref] # 全序列 softmax 概率(示意) print(online-softmax 合并结果(前3维):, [round(x, 6) for x in merged[:3]]) print(说明: online-softmax 与全局 softmax 数学等价, 误差仅在浮点精度内)数值上online-softmax 与一次性的全局 softmax完全等价误差只在浮点精度内这正是 DCP 能无损合并多卡部分结果的理论基础——既不用传完整的注意力矩阵又不会损失精度。五、性能实测8×B200 上的吞吐-交互帕累托前沿vLLM 团队在单台 8×B200 节点上服务 Kimi K2.6NVFP4 量化使用公开的 Mooncake 格式 Agent 长上下文 trace 复现测试并发从 16 扫到 512。数据分布很Agent输入中位数约 67K token、输出仅 ~400 token其中约 53% 请求在 64K重尾到 ~1M约 18% 在 8K 以下。| 指标 | 基线 TP | DCP ||---|---|---|| 显存打满时的并发 | 64100% KV 占用撞墙 | 512 时仍仅 82% || 吞吐上限 | ~1,863 tok/s/GPU |6,091 tok/s/GPU|| 200K 长序列表现 | 无法扩展 | 吞吐-交互曲线与短序列几乎重合 |结论很清晰DCP 的价值在于把并发天花板整体抬高——TP 在长上下文下先耗尽显存DCP 却能让吞吐随并发继续线性爬升甚至在 200K 的重度长序列区间保持稳定。六、上手配置一行参数启用 DCPDCP 已经原生集成进 vLLM只需在现有 TP 配置上追加一个参数。离线Offline APIfrom vllm import LLM, SamplingParams llm LLM( modeldeepseek-ai/DeepSeek-V2-Lite, tensor_parallel_size2, decode_context_parallel_size2, ) outputs llm.generate( [The future of AI is], SamplingParams(temperature0.8, top_p0.95), )在线Online Servingvllm serve deepseek-ai/DeepSeek-V2-Lite \ --tensor-parallel-size 2 \ --decode-context-parallel-size 2约束条件务必注意• **MLA 后端**DeepSeek-V2/V3/R1、Kimi K2.6由于等效 KV head 1序列可分到满 TP 度。要求 tensor_parallel_size decode_context_parallel_size 且整除vllm serve deepseek-ai/DeepSeek-R1 \ --tensor-parallel-size 8 \ --decode-context-parallel-size 8• **GQA 后端**Qwen3-235B、Llama 家族DCP 把本会重复的副本替换成不同的序列切片序列切分度上限 复制因子 tp // num_key_value_heads。要求整除关系# Qwen3-235B 的 num_key_value_heads 4, tp8 时 8//42 份冗余 # 因此 dcp 最大为 2 vllm serve Qwen/Qwen3-235B-A22B \ --tensor-parallel-size 8 \ --decode-context-parallel-size 2七、行业动向这不是 vLLM 一家的事DCP 是长上下文推理的行业级共识方向。NVIDIA 在 TensorRT-LLM 中推出了Helix ParallelismContext Tensor 混合并行目标同样是消除 TP 下的 KV 复制、支持百万 token 解码而 DCP 的早期工作正是 Moonshot AI月之暗面贡献并 upstream 到 vLLM 的PR #23734后续由 Red Hat AI 等社区成员持续加固。八、未来方向与总结vLLM 的 DCP 路线图包括更细粒度的 TP/DCP 并行度组合、多节点/单节点下更优的 All-to-All 通信内核、对 MTP 和投机解码Speculative Decoding的兼容、prefill/decode 分离部署P/D Disaggregation的加固以及扩展到 GLM-5.2、Kimi K3 等更多模型并推进 Prefill Context ParallelismPCP的落地。回到本质DCP 是对 GPU 组织方式的一次底层重构——注意力阶段按序列切分让每张卡只存 1/N 的 KV紧接着同一批 GPU 又立刻重组把 FFN 权重加载的开销摊到整个 GPU 池。结果是系统随上下文长度优雅扩展而不是在长上下文面前性能崩塌。对正在做长上下文 Agent 服务的团队来说--decode-context-parallel-size 这一行参数可能是 2026 年性价比最高的一次推理架构升级。参考vLLM Blog《Efficient Decode Context Parallelism with vLLM for Long Context Workloads》(2026-08-07)vLLM Decode Context Parallel 文档TensorRT-LLM Helix Parallelism 技术博客。 vLLM 长上下文推理新范式：Decode Context Parallelism 底层原理与性能实测
vLLM 长上下文推理新范式Decode Context Parallelism 底层原理与性能实测引言长上下文正在成为 Agent 时代的硬通货2026 年的 LLM 推理战场早已不是谁能生成的问题而是谁能低成本地处理百万 token 上下文的问题。智能体Agent要读完整代码仓库、翻遍长对话历史、在多轮工具调用中保持记忆Agent 基准的输入长度已经从 64K 一路拉到 1M token。上下文一长KV Cache 就成了第一瓶颈——它不参与计算却占用大量显存直接影响并发能力和单 token 成本。8 月 7 日vLLM 官方博客发布了一篇深度技术文章《Efficient Decode Context Parallelism with vLLM for Long Context Workloads》系统阐述了Decode Context ParallelismDCP解码上下文并行的原理与实测数据在 8×B200 节点上服务 Kimi K2.6DCP 能把吞吐从张量并行TP的 ~1,863 tok/s/GPU 拉到6,091 tok/s/GPU并发数从 64 直接干到 512 还只用掉 82% 的 KV 显存。这篇博客虽然只是 vLLM 众多更新中的一个但它代表了对长上下文推理底层组织方式的重新思考。本文带你把它拆开看透。一、问题根源TP 下 KV Cache 的按头切分天花板要理解 DCP先得明白传统张量并行Tensor Parallelism, TP在长上下文场景下为什么卡脖子。自回归解码时模型需要把历史 token 的 Key/Value 缓存下来供注意力计算使用这就是 KV Cache。在 TP 部署中KV Cache 是按注意力头attention head切分的每个 KV head 拥有独立的 K/V 张量head 是分发给 GPU 的最小粒度。问题在于现代模型的注意力机制恰恰在压缩 KV head 数量GQA分组查询注意力Qwen、Llama 家族等模型只保留少量 KV head如 Qwen3-235B 只有 4 个。TP 最多把 KV Cache 切到每 GPU 一个 head一旦 tensor_parallel_size 超过 KV head 数量就会有两个 GPU 持有同一份 KV head 的副本——缓存开始复制。MLA多头潜在注意力DeepSeek-V2/V3/R1、Kimi K2.6 等模型把 Key/Value 压缩进一个共享的低秩潜在向量等效 KV head 数 1。在纯 TP 下没有头可分潜在 KV Cache 被完整复制到每一张卡上。后果是致命的KV 复制吃掉显存能塞进 GPU 的并发请求数被锁死吞吐上不去、单 token 成本飙升。长上下文请求的 KV Cache 动辄几百 GB复制一份就是翻倍的开销。二、为什么偏偏是 Decode 阶段需要救先厘清一个概念大模型推理分两个阶段瓶颈完全不同。Prefill预填充用户输入一次性进来模型并行消化所有输入 token产出第一个输出 token。这个阶段计算密集、GPU 利用率高核心指标是 TTFT首字时延。长上下文下 Prefill 的痛点是一次算太多解法是让计算摊到更多 GPU 上Prefill Context Parallelism。Decode解码模型逐个生成 token每步只算一个 token但每步都要读一遍整条序列的 KV Cache。这个阶段是访存密集memory-bound的GPU 算力吃不满核心指标是 TPOT/ITL每 token 输出间隔。长上下文下 Decode 的痛点是KV Cache 太大塞不下并发。DCP 专治 Decode它不动 Prefill 的计算划分只在解码时把 KV Cache 按序列切到多卡上。这也是为什么它叫DecodeContext Parallelism——与面向 Prefill 的 PCPPrefill Context ParallelismvLLM 路线图中已有规划正好互补。再算一笔账感受一下 KV Cache 的量级。对 MLA 模型单条请求的潜在 KV Cache 大致为 2 × seq_len × latent_dim × bytes。以 latent_dim 512、FP81 字节为例一条 1M token 的请求就要吃掉约 1GB 显存如果这条请求横跨 1M 上下文8 卡 TP 下每人复制一份就是 8GB。而 DCP 按序列切分后每卡只存 1/8省下的显存足够再接纳 7 条同量级的并发请求——并发能力直接乘 8这就是吞吐跃升的数学根源。三、DCP 的核心思想按序列维度切 KVDCP 的思路非常直接既然按头切会遇到下限那就按序列context维度切。对一条 200K token 的请求4 卡 DCP 的分配方式是这样的GPU 0 持有 token 0–50K 的 KVGPU 1 持有 50K–100KGPU 2 持有 100K–150KGPU 3 持有 150K–200K。每张卡只存整条序列 KV 的 1/N。这样做的好处是加卡KV 单卡占用线性下降省出来的显存全部用于提升 batch size、接纳更多并发请求。在高带宽 GPU 互联NVLink、NVSwitch上多用户长上下文 Agent 服务的交互延迟依然可控。四、通信模式AllGather Q → Compute → AllGather ReduceScatterDCP 的解码过程遵循一个固定的三步节奏值得逐行理解Step 1AllGather Q。每张卡只算出了 query 的一个分片但注意力打分需要完整的 query 向量因此要在 DCP 组内做一次全收集。解码阶段 query 只有一个 token通信量极小几乎可以忽略。MLA 场景还有一个可选项通过 VLLM_DCP_Q_REPLICATE1vLLM PR #45964在加载时复制 query 投影解码时直接跳过这次 AllGather。Step 2Compute本地注意力。每张卡用完整 query 和本地 KV 切片做注意力计算。MLA 后端对应 k_up 步骤把潜在向量局部上投影还原出 K/VGQA 后端对应 tensor_broadcast共享 KV head 广播到对应的 query head。Step 3AllGather ReduceScatter。每张卡的注意力输出只是部分和只覆盖自己那段序列需要合并成真实输出。这里用到online-softmax 技巧各卡把自己的部分输出和 log-sum-expLSE全收集用 LSE 对部分结果重新加权合并再 ReduceScatter 把每个 head 的结果片归还给对应 GPU。下面用一段极简的 Python 演示 online-softmax 合并的数值逻辑让你直观感受为什么部分和能精确合并import math # 模拟 4 个 GPU 各自负责的序列片段上的注意力输出 # 每片返回: (部分加权和 numerator, 部分 softmax 分母 logsumexp) def online_softmax_merge(partials): partials: list of (weighted_sum_vec, lse) m -math.inf num None for n_i, lse_i in partials: # 经典 online-softmax: 用新片段的 LSE 更新全局最大值 m_new max(m, lse_i) if num is None: num n_i * math.exp(lse_i - m_new) else: num num * math.exp(m - m_new) n_i * math.exp(lse_i - m_new) m m_new return num / math.exp(m) # 模拟: 4 张卡, 各自对 200K 序列的 1/4 做 attention, d_model8 import random random.seed(42) d 8 partials [] for _ in range(4): n_i [random.random() for _ in range(d)] lse_i random.uniform(-2, 2) partials.append((n_i, lse_i)) merged online_softmax_merge(partials) # 对照: 直接把 4 段拼成完整序列, 一次性算 softmax seq [] for _ in range(4): scores [random.random() for _ in range(16)] # 每段 16 个 key seq.extend(scores) m_full max(seq) ref [math.exp(s - m_full) for s in seq] ref_sum sum(ref) expect [r / ref_sum for r in ref] # 全序列 softmax 概率(示意) print(online-softmax 合并结果(前3维):, [round(x, 6) for x in merged[:3]]) print(说明: online-softmax 与全局 softmax 数学等价, 误差仅在浮点精度内)数值上online-softmax 与一次性的全局 softmax完全等价误差只在浮点精度内这正是 DCP 能无损合并多卡部分结果的理论基础——既不用传完整的注意力矩阵又不会损失精度。五、性能实测8×B200 上的吞吐-交互帕累托前沿vLLM 团队在单台 8×B200 节点上服务 Kimi K2.6NVFP4 量化使用公开的 Mooncake 格式 Agent 长上下文 trace 复现测试并发从 16 扫到 512。数据分布很Agent输入中位数约 67K token、输出仅 ~400 token其中约 53% 请求在 64K重尾到 ~1M约 18% 在 8K 以下。| 指标 | 基线 TP | DCP ||---|---|---|| 显存打满时的并发 | 64100% KV 占用撞墙 | 512 时仍仅 82% || 吞吐上限 | ~1,863 tok/s/GPU |6,091 tok/s/GPU|| 200K 长序列表现 | 无法扩展 | 吞吐-交互曲线与短序列几乎重合 |结论很清晰DCP 的价值在于把并发天花板整体抬高——TP 在长上下文下先耗尽显存DCP 却能让吞吐随并发继续线性爬升甚至在 200K 的重度长序列区间保持稳定。六、上手配置一行参数启用 DCPDCP 已经原生集成进 vLLM只需在现有 TP 配置上追加一个参数。离线Offline APIfrom vllm import LLM, SamplingParams llm LLM( modeldeepseek-ai/DeepSeek-V2-Lite, tensor_parallel_size2, decode_context_parallel_size2, ) outputs llm.generate( [The future of AI is], SamplingParams(temperature0.8, top_p0.95), )在线Online Servingvllm serve deepseek-ai/DeepSeek-V2-Lite \ --tensor-parallel-size 2 \ --decode-context-parallel-size 2约束条件务必注意• **MLA 后端**DeepSeek-V2/V3/R1、Kimi K2.6由于等效 KV head 1序列可分到满 TP 度。要求 tensor_parallel_size decode_context_parallel_size 且整除vllm serve deepseek-ai/DeepSeek-R1 \ --tensor-parallel-size 8 \ --decode-context-parallel-size 8• **GQA 后端**Qwen3-235B、Llama 家族DCP 把本会重复的副本替换成不同的序列切片序列切分度上限 复制因子 tp // num_key_value_heads。要求整除关系# Qwen3-235B 的 num_key_value_heads 4, tp8 时 8//42 份冗余 # 因此 dcp 最大为 2 vllm serve Qwen/Qwen3-235B-A22B \ --tensor-parallel-size 8 \ --decode-context-parallel-size 2七、行业动向这不是 vLLM 一家的事DCP 是长上下文推理的行业级共识方向。NVIDIA 在 TensorRT-LLM 中推出了Helix ParallelismContext Tensor 混合并行目标同样是消除 TP 下的 KV 复制、支持百万 token 解码而 DCP 的早期工作正是 Moonshot AI月之暗面贡献并 upstream 到 vLLM 的PR #23734后续由 Red Hat AI 等社区成员持续加固。八、未来方向与总结vLLM 的 DCP 路线图包括更细粒度的 TP/DCP 并行度组合、多节点/单节点下更优的 All-to-All 通信内核、对 MTP 和投机解码Speculative Decoding的兼容、prefill/decode 分离部署P/D Disaggregation的加固以及扩展到 GLM-5.2、Kimi K3 等更多模型并推进 Prefill Context ParallelismPCP的落地。回到本质DCP 是对 GPU 组织方式的一次底层重构——注意力阶段按序列切分让每张卡只存 1/N 的 KV紧接着同一批 GPU 又立刻重组把 FFN 权重加载的开销摊到整个 GPU 池。结果是系统随上下文长度优雅扩展而不是在长上下文面前性能崩塌。对正在做长上下文 Agent 服务的团队来说--decode-context-parallel-size 这一行参数可能是 2026 年性价比最高的一次推理架构升级。参考vLLM Blog《Efficient Decode Context Parallelism with vLLM for Long Context Workloads》(2026-08-07)vLLM Decode Context Parallel 文档TensorRT-LLM Helix Parallelism 技术博客。