文章目录一 vLLM PD 分离部署概述1.1 为什么要做 PDPrefill/Decode分离部署 LLM 应用1.2 PD 分离架构概述1.3 vLLM 如何部署 PD 分离应用PD 分离离线推理实例disaggregated_prefill.sh PD分离脚本步骤解析一键部署使用方法推荐1.4 disaggregated_prefill.sh 脚本的已知 Bug 与修复二 vLLM PD 分离的设计方案三 PD 分离端到端流程解析四 KV Offloading Connector五 P2pNcclConnector 组件参考资料一 vLLM PD 分离部署概述1.1 为什么要做 PDPrefill/Decode分离部署 LLM 应用大模型推理通常可以拆成两个串行、但资源特征差异很大的阶段Prefill上下文处理输入整段 prompt上下文 token 数量通常较大主要成本对整段输入做前向计算计算量大同时生成并写入 KV Cache瓶颈更偏向算力、显存带宽和并行度Decode增量生成输入每步 1 个或少量新 token主要成本每步读取历史 KV Cache并追加写入新的 KV瓶颈更偏向显存容量和显存带宽。上下文越长、并发越高KV Cache 占用越明显算力需求相对更细碎batch 较小时计算不一定充分饱和但对内存系统要求很高核心矛盾是Prefill 和 Decode 对资源的侧重点不同。架设如果 Prefill 和 Decode 都放在同一组设备上这组设备既要支撑长 prompt 的 prefill 吞吐又要容纳长上下文、多并发请求的 KV Cache 常驻。对于大模型、长上下文和高并发场景这往往会让单一部署形态同时承受计算压力和 KV Cache 压力资源利用率不一定最优。从系统设计角度看Prefill 更偏计算密集Decode 更偏 KV Cache 常驻和读写密集。既然两个阶段的资源画像不同就可以把它们拆到不同的 vLLM 实例中运行Prefill 实例负责处理 prompt生成对应的 KV CacheDecode 实例接收或加载 Prefill 产生的 KV Cache然后继续生成后续 token路由/代理层负责把请求先送到 Prefill再把生成阶段交给 Decode在 vLLM 中PD 分离不是简单地把两个函数拆开调用而是依赖 KV transfer 机制。vLLM 通过 --kv-transfer-config 配置 KV connector并用 kv_role 区分实例角色例如kv_producer通常对应 Prefill 实例负责产出 KVkv_consumer通常对应 Decode 实例负责接收或加载 KVkv_both同时具备生产和消费 KV 的能力vLLM 的 KV transfer 抽象包括 KV pipe、KV lookup buffer 和 KV connector。这样做的原因是Prefill 实例和 Decode 实例处理请求的顺序可能不同不能只依赖简单 FIFO 管道还需要能够按请求/token 查找对应的 KV Cache。PD 分离的技术方案有以下优势资源利用率提升Prefill 和 Decode 的资源压力可以分开管理减少长 prompt 计算与 Decode 阶段 KV Cache 常驻/读写在同一实例上的竞争。成本和容量规划更灵活Prefill 节点可以更关注计算吞吐Decode 节点可以更关注 KV Cache 容量和带宽。实际是否采用不同型号设备需要结合模型大小、上下文长度、并发、网络带宽、KV 传输开销和硬件价格评估不能简单理解为 Decode 一定可以使用低端卡。更容易按阶段扩展当请求的输入很长、输出较短时Prefill 压力更突出当输出很长、并发较高时Decode 和 KV Cache 压力更突出。PD 分离后可以针对不同阶段做容量规划。不过它也会引入额外复杂度例如路由/代理、KV 传输、请求状态管理、失败回退和版本兼容性什么时候不需要 PD 分离模型较小、prompt 较短、并发不高。单卡或单组实例的算力和显存都足够。KV 传输和跨实例调度带来的开销大于收益。当前部署更重视简单性、稳定性和运维成本而不是极限吞吐或精细化资源隔离。总结因此PD 分离更适合大模型、长上下文、高并发并且 Prefill/Decode 负载差异明显的场景。对于普通规模的在线服务一体化部署通常更简单也更容易维护。1.2 PD 分离架构概述PD 分离应用的核心组成三个服务API Proxy 服务流量入口纯 CPU 部署无需 GPU负责请求路由、状态管理、响应聚合只需与 P/D 节点保持低延迟网络即可P 节点Prefill 节点专注 Prefill 阶段处理完整 prompt生成 KV Cache推荐高算力 GPU如 H200、H100D 节点Decode 节点专注 Decode 阶段读取 KV Cache持续生成 token可使用性价比更高 GPU如 H20、A100部署灵活性P 节点与 D 节点的推理服务所用代码完全相同同一镜像、同一代码仅计算设备不同。API Proxy 独立部署也是流量的出入口实现计算资源解耦。PD 分离应用的处理流程可简单总结为 6 步API Proxy 将请求发给 P 节点并在示例中将 max_tokens 改为 1使 P 节点主要完成 PrefillP 节点处理完整 prompt生成 KV Cache并通过 KV transfer 机制把相关 KV 提供给后续 Decode 使用Proxy 不把 P 节点生成的响应作为最终响应返回给用户Proxy 将原始请求转发给 D 节点D 节点通过 KV connector 加载或接收 Prefill 阶段产生的 KV Cache然后继续 DecodeD 节点将后续生成结果返回给 ProxyProxy 再返回给客户端这个流程对应的是 vLLM benchmark 中的简化 disaggregated prefill 示例。实际生产部署还需要处理请求状态、异常回退、KV 加载失败策略、超时、取消请求、流式响应和监控等问题。1.3 vLLM 如何部署 PD 分离应用vLLM 的 PD 分离功能依靠 KV transfer 模块完成可支持简单的 1P1D 场景。其关键流程为对同一请求先在 PPrefill节点完成 prefill 并产出 KV Cache再由 DDecode节点接续 decodeP、D 是两套独立引擎可对不同请求并发推进。由 KV connector 在后台异步把 KV Cache 从 P 节点传输到 D 节点。由 API proxy 负责把请求在 P、D 节点之间路由与编排协调整个交互过程。1P1D 场景下 PD 分离应用的软件流程图如下所示PD 分离离线推理实例examples/offline_inference/disaggregated-prefill-v1/run.sh 脚本展示了 vLLM 离线模式下的 pd 分离的预填充功能。运行 run.sh之前请确保你终端当前位于examples/offline_inference/disaggregated-prefill-v1 目录下并修改 prefill_example.py 和 decode_example.py 代码中的 model 为你本地权重路径。run.sh 会依次运行 prefill_example.py 和 decode_example.py。prefill_example.py - 仅执行预填充操作的脚本将 KV 状态保存至 local_storage 目录并将提示词保存至 output.txt。decode_example.py - 仅执行解码操作的脚本从 local_storage 目录加载 KV 状态并从 output.txt 加载提示词。代码运行成功后当前目录下会有 out.txt 文件。脚本运行成功后的示意图run.sh 脚本的作用简单来说是它不是普通“跑一次模型推理”的脚本而是一个两阶段prefill/decode以及离线 KV cache 复用 demo。它的核心目标是第一阶段先对一批 prompt 做推理并把 prefill 产生的 KV cache 通过 ExampleConnector 保存到外部共享存储第二阶段再重新加载这些 prompt验证能否从外部存储命中 KV cache而不是重新完整 prefill对比第二阶段是否出现External Cache Hit!Inject KV cache …更高吞吐 / 更短推理时间结合运行后日志信息可知上述目标都已经验证成功。# prefill 阶段吞吐量 WARNING 03-20 21:40:13 [example_connector.py:167] In connector.start_load_kv, but the attn_metadata is None Processed prompts: 100%|████████████████████| 4/4 [00:0100:00, 3.49it/s, est. speed input: 2636.49 toks/s, output: 3.49 toks/s] # decode 阶段吞吐量 WARNING 03-20 21:40:25 [example_connector.py:167] In connector.start_load_kv, but the attn_metadata is None Processed prompts: 100%|█████████████████| 4/4 [00:0000:00, 18.89it/s, est. speed input: 14276.27 toks/s, output: 189.02 toks/s]disaggregated_prefill.sh PD分离脚本步骤解析vLLM 官方示例位于 examples/online_serving/disaggregated_prefill.sh是用于 1P1D 最小在线 PD 分离部署。它通过 两个独立的 vLLM 实例 一个轻量 Proxy 实现 Prefill 和 Decode 彻底解耦KV Cache 通过 P2pNcclConnector进行高速点对点传输。脚本对应的整体架构拓扑如下1P 1D 最小示例:一键部署使用方法推荐1.4 disaggregated_prefill.sh 脚本的已知 Bug 与修复二 vLLM PD 分离的设计方案三 PD 分离端到端流程解析四 KV Offloading Connector五 P2pNcclConnector 组件参考资料vLLM 部署 PD 分离应用Inference without Interference:Disaggregate LLM Inference for Mixed Downstream WorkloadsP2P NCCL ConnectorInside vLLM’s New KV Offloading Connector: Smarter Memory Transfer for Maximizing Inference ThroughputvLLM PD分离KV cache传递机制详解与演进分析
vllm源码剖析19-LLM高级特性之PD分离技术详解
发布时间：2026/7/31 5:28:52
文章目录一 vLLM PD 分离部署概述1.1 为什么要做 PDPrefill/Decode分离部署 LLM 应用1.2 PD 分离架构概述1.3 vLLM 如何部署 PD 分离应用PD 分离离线推理实例disaggregated_prefill.sh PD分离脚本步骤解析一键部署使用方法推荐1.4 disaggregated_prefill.sh 脚本的已知 Bug 与修复二 vLLM PD 分离的设计方案三 PD 分离端到端流程解析四 KV Offloading Connector五 P2pNcclConnector 组件参考资料一 vLLM PD 分离部署概述1.1 为什么要做 PDPrefill/Decode分离部署 LLM 应用大模型推理通常可以拆成两个串行、但资源特征差异很大的阶段Prefill上下文处理输入整段 prompt上下文 token 数量通常较大主要成本对整段输入做前向计算计算量大同时生成并写入 KV Cache瓶颈更偏向算力、显存带宽和并行度Decode增量生成输入每步 1 个或少量新 token主要成本每步读取历史 KV Cache并追加写入新的 KV瓶颈更偏向显存容量和显存带宽。上下文越长、并发越高KV Cache 占用越明显算力需求相对更细碎batch 较小时计算不一定充分饱和但对内存系统要求很高核心矛盾是Prefill 和 Decode 对资源的侧重点不同。架设如果 Prefill 和 Decode 都放在同一组设备上这组设备既要支撑长 prompt 的 prefill 吞吐又要容纳长上下文、多并发请求的 KV Cache 常驻。对于大模型、长上下文和高并发场景这往往会让单一部署形态同时承受计算压力和 KV Cache 压力资源利用率不一定最优。从系统设计角度看Prefill 更偏计算密集Decode 更偏 KV Cache 常驻和读写密集。既然两个阶段的资源画像不同就可以把它们拆到不同的 vLLM 实例中运行Prefill 实例负责处理 prompt生成对应的 KV CacheDecode 实例接收或加载 Prefill 产生的 KV Cache然后继续生成后续 token路由/代理层负责把请求先送到 Prefill再把生成阶段交给 Decode在 vLLM 中PD 分离不是简单地把两个函数拆开调用而是依赖 KV transfer 机制。vLLM 通过 --kv-transfer-config 配置 KV connector并用 kv_role 区分实例角色例如kv_producer通常对应 Prefill 实例负责产出 KVkv_consumer通常对应 Decode 实例负责接收或加载 KVkv_both同时具备生产和消费 KV 的能力vLLM 的 KV transfer 抽象包括 KV pipe、KV lookup buffer 和 KV connector。这样做的原因是Prefill 实例和 Decode 实例处理请求的顺序可能不同不能只依赖简单 FIFO 管道还需要能够按请求/token 查找对应的 KV Cache。PD 分离的技术方案有以下优势资源利用率提升Prefill 和 Decode 的资源压力可以分开管理减少长 prompt 计算与 Decode 阶段 KV Cache 常驻/读写在同一实例上的竞争。成本和容量规划更灵活Prefill 节点可以更关注计算吞吐Decode 节点可以更关注 KV Cache 容量和带宽。实际是否采用不同型号设备需要结合模型大小、上下文长度、并发、网络带宽、KV 传输开销和硬件价格评估不能简单理解为 Decode 一定可以使用低端卡。更容易按阶段扩展当请求的输入很长、输出较短时Prefill 压力更突出当输出很长、并发较高时Decode 和 KV Cache 压力更突出。PD 分离后可以针对不同阶段做容量规划。不过它也会引入额外复杂度例如路由/代理、KV 传输、请求状态管理、失败回退和版本兼容性什么时候不需要 PD 分离模型较小、prompt 较短、并发不高。单卡或单组实例的算力和显存都足够。KV 传输和跨实例调度带来的开销大于收益。当前部署更重视简单性、稳定性和运维成本而不是极限吞吐或精细化资源隔离。总结因此PD 分离更适合大模型、长上下文、高并发并且 Prefill/Decode 负载差异明显的场景。对于普通规模的在线服务一体化部署通常更简单也更容易维护。1.2 PD 分离架构概述PD 分离应用的核心组成三个服务API Proxy 服务流量入口纯 CPU 部署无需 GPU负责请求路由、状态管理、响应聚合只需与 P/D 节点保持低延迟网络即可P 节点Prefill 节点专注 Prefill 阶段处理完整 prompt生成 KV Cache推荐高算力 GPU如 H200、H100D 节点Decode 节点专注 Decode 阶段读取 KV Cache持续生成 token可使用性价比更高 GPU如 H20、A100部署灵活性P 节点与 D 节点的推理服务所用代码完全相同同一镜像、同一代码仅计算设备不同。API Proxy 独立部署也是流量的出入口实现计算资源解耦。PD 分离应用的处理流程可简单总结为 6 步API Proxy 将请求发给 P 节点并在示例中将 max_tokens 改为 1使 P 节点主要完成 PrefillP 节点处理完整 prompt生成 KV Cache并通过 KV transfer 机制把相关 KV 提供给后续 Decode 使用Proxy 不把 P 节点生成的响应作为最终响应返回给用户Proxy 将原始请求转发给 D 节点D 节点通过 KV connector 加载或接收 Prefill 阶段产生的 KV Cache然后继续 DecodeD 节点将后续生成结果返回给 ProxyProxy 再返回给客户端这个流程对应的是 vLLM benchmark 中的简化 disaggregated prefill 示例。实际生产部署还需要处理请求状态、异常回退、KV 加载失败策略、超时、取消请求、流式响应和监控等问题。1.3 vLLM 如何部署 PD 分离应用vLLM 的 PD 分离功能依靠 KV transfer 模块完成可支持简单的 1P1D 场景。其关键流程为对同一请求先在 PPrefill节点完成 prefill 并产出 KV Cache再由 DDecode节点接续 decodeP、D 是两套独立引擎可对不同请求并发推进。由 KV connector 在后台异步把 KV Cache 从 P 节点传输到 D 节点。由 API proxy 负责把请求在 P、D 节点之间路由与编排协调整个交互过程。1P1D 场景下 PD 分离应用的软件流程图如下所示PD 分离离线推理实例examples/offline_inference/disaggregated-prefill-v1/run.sh 脚本展示了 vLLM 离线模式下的 pd 分离的预填充功能。运行 run.sh之前请确保你终端当前位于examples/offline_inference/disaggregated-prefill-v1 目录下并修改 prefill_example.py 和 decode_example.py 代码中的 model 为你本地权重路径。run.sh 会依次运行 prefill_example.py 和 decode_example.py。prefill_example.py - 仅执行预填充操作的脚本将 KV 状态保存至 local_storage 目录并将提示词保存至 output.txt。decode_example.py - 仅执行解码操作的脚本从 local_storage 目录加载 KV 状态并从 output.txt 加载提示词。代码运行成功后当前目录下会有 out.txt 文件。脚本运行成功后的示意图run.sh 脚本的作用简单来说是它不是普通“跑一次模型推理”的脚本而是一个两阶段prefill/decode以及离线 KV cache 复用 demo。它的核心目标是第一阶段先对一批 prompt 做推理并把 prefill 产生的 KV cache 通过 ExampleConnector 保存到外部共享存储第二阶段再重新加载这些 prompt验证能否从外部存储命中 KV cache而不是重新完整 prefill对比第二阶段是否出现External Cache Hit!Inject KV cache …更高吞吐 / 更短推理时间结合运行后日志信息可知上述目标都已经验证成功。# prefill 阶段吞吐量 WARNING 03-20 21:40:13 [example_connector.py:167] In connector.start_load_kv, but the attn_metadata is None Processed prompts: 100%|████████████████████| 4/4 [00:0100:00, 3.49it/s, est. speed input: 2636.49 toks/s, output: 3.49 toks/s] # decode 阶段吞吐量 WARNING 03-20 21:40:25 [example_connector.py:167] In connector.start_load_kv, but the attn_metadata is None Processed prompts: 100%|█████████████████| 4/4 [00:0000:00, 18.89it/s, est. speed input: 14276.27 toks/s, output: 189.02 toks/s]disaggregated_prefill.sh PD分离脚本步骤解析vLLM 官方示例位于 examples/online_serving/disaggregated_prefill.sh是用于 1P1D 最小在线 PD 分离部署。它通过 两个独立的 vLLM 实例 一个轻量 Proxy 实现 Prefill 和 Decode 彻底解耦KV Cache 通过 P2pNcclConnector进行高速点对点传输。脚本对应的整体架构拓扑如下1P 1D 最小示例:一键部署使用方法推荐1.4 disaggregated_prefill.sh 脚本的已知 Bug 与修复二 vLLM PD 分离的设计方案三 PD 分离端到端流程解析四 KV Offloading Connector五 P2pNcclConnector 组件参考资料vLLM 部署 PD 分离应用Inference without Interference:Disaggregate LLM Inference for Mixed Downstream WorkloadsP2P NCCL ConnectorInside vLLM’s New KV Offloading Connector: Smarter Memory Transfer for Maximizing Inference ThroughputvLLM PD分离KV cache传递机制详解与演进分析
