>[大模型推理中的 PD 分离：计算特征、KV Cache 传输与引擎实现](https://mp.weixin.qq.com/s/-qEPXZFA6K00ieN-mBmsjw) 中对 `vLLM`、`SGLang` 与 `MindIE` 的 `PD` 实现的做了简单的说明，本篇在前篇的基础上，近一步细化三个推理引擎的的实现细节。

**大模型推理进入高并发、长上下文和混合负载阶段以后，`Prefill` 与 `Decode` 的调度关系逐渐成为推理服务延迟波动的重要来源**。`Prefill` 一次处理输入序列，通常具有更高的计算并行度；`Decode` 按自回归方式逐步生成输出，持续访问模型权重以及不断扩大的 `KV Cache`，对显存带宽、运行队列与调度间隔更加敏感。两种阶段共用同一组计算资源时，长输入请求与正在进行的逐 `Token` 输出会互相争夺计算时隙。

`PD Disaggregation` 将两个阶段部署为相对独立的推理实例。`Prefill` 实例负责处理输入和生成可复用的推理状态，`Decode` 实例接收状态后继续生成输出。这样可以分别选择 `TP/PP/DP/EP`、独立设置并发与批处理策略，并根据 `TTFT` 与 `TPOT` 的要求调配资源。真正让两端协同工作的关键，是 **跨实例传递模型状态、建立请求交接关系，并保证 `KV Cache` 在传输前后保持有效**。

> 注：本文以官方设计与开源实现为基础，分析 `vLLM`、`vLLM-Ascend`、`SGLang` 和 `MindIE Motor` 的 `PD` 技术路径。

# 一、`PD` 分离究竟分离了什么

在合设模式下（即PD 不分离），一个推理实例持续维护请求队列、`KV Block` 分配和运行中的 `Batch`。新请求进入后，调度器安排 `Prefill`；完成 `Prefill` 的请求进入后续 `Decode`。`Chunked Prefill` 可以通过限制每次处理的输入块大小来缓解调度干扰，但 `Prefill` 与 `Decode` 仍共享相同的设备资源和服务容量。

拆分之后，一个请求需要经过 `Router` 选择 `Prefill` 实例、执行前向计算、找到可接收状态的 `Decode` 实例、搬运 `KV Cache`、恢复模型位置与请求上下文，然后继续执行 `Decode`。`P` 和 `D` 两端通常均需装载相容的模型权重，单独运行的 `Decode` 无法凭空获得输入历史对应的 Attention 状态。**真正被迁移的是下一阶段推理所需的可恢复状态**，其中最主要的部分是 `KV Cache`，还可能涉及交接 `Token`、序列长度、位置、采样上下文、分块布局以及传输元数据。
![image](https://developer.qcloudimg.com/http-save/yehe-8159227/ea8897c90eed72ed64e33125f9995c50.jpg)
在这个过程中，系统同时存在两条链路。**控制链路**负责请求配对、目标 `KV Block` 预留、发送与接收地址交换、完成通知以及故障处置；**数据链路**负责大规模 `KV` 张量的搬运。控制链路通常由 `HTTP/RPC` 和内部消息协议承担，数据链路则倾向于借助 `NIXL`、`Mooncake`、`UCX/RDMA` 或 `Ascend` 专用传输机制。由于 `Decode` 在收到可用 `KV` 之前无法正确继续推理，传输阶段会进入首 `Token` 响应的关键路径。
这里还需要区分两个目标：`PD` 能够降低 `Prefill` 对 `Decode` 的尾延迟干扰，并允许两段独立配置容量；它也会增加模型副本与状态迁移成本。`vLLM` 官方文档特别提示，`PD` 分离本身不直接保证吞吐量增长。因此判断收益时，应比较相同硬件预算和 `TTFT/TPOT` 约束下的有效完成请求数，以及新增的网络与资源开销。
# 二、`vLLM`：以 `KV Connector` 为中心的执行引擎解耦

`vLLM` 的实现重点是把跨实例状态传输放到 `KV Connector` 抽象中。`vLLM V1` 的 `Scheduler` 管理请求状态、逻辑 `KV Block` 和调度决策，模型 `Worker` 持有真正的设备内存与 Attention 计算。`PD` 使 `Prefill` 和 `Decode` 运行在两个独立的 `vLLM` 实例里，每个实例内部均建立相应的 Connector。上层 `Proxy/Router` 负责把一个用户请求拆成前后相接的两个阶段。

从源码组织看，当前 `NIXL` 连接器进一步划分了 `Scheduler` 侧与 `Worker` 侧逻辑，并针对 `Pull`、`Push` 分别提供实现。**`Scheduler Connector` 决定何时迁移、哪些请求参与迁移以及何时释放缓存；`Worker Connector` 负责注册显存、取得物理块映射并执行设备间的数据交换。** 两者之间还要传递远端内存信息、块编号和传输完成状态。

![Disaggregated prefilling-vLLM](https://developer.qcloudimg.com/http-save/yehe-8159227/f9e60dee1959a8d92a048342831c0d20.jpg)
例如使用 `NixlConnector` 时，`P` 侧计算完成后需要保留对应的 `KV Block`，并暴露可用于远端读取或写入的元数据。`D` 侧根据请求上下文分配目标块，交换连接和缓冲区信息，Connector 随后执行异步传输。在传输成功且 `D` 完成接管后，`P` 侧才可以回收这批缓存。当前 `NIXL` 实现具有 `NixlPullConnector` 和 `NixlPushConnector` 两条路径，`NixlConnector` 在兼容接口中仍作为 `Pull` 实现的别名。低层传输还可以选择 `UCX`、`GDS`、`LIBFABRIC` 等插件或后端组合，具体要以版本兼容矩阵为准。

这种设计让 `vLLM` 内部仍然使用既有的请求调度、Paged KV 和模型执行机制；跨实例状态迁移由 Connector 承担。`LookupBuffer`、`Pipe` 与 Connector 接口为共享缓存、点对点传输和第三方接入提供了不同抽象层次。对平台开发者而言，`KV Connector`、路由组件与运行时版本需要一起固定，尤其需要核对 `KV dtype`、块布局、量化、模型架构和并行分组的兼容性。
# 三、`vLLM-Ascend`：同一引擎接口下的拉取与分层推送

`vLLM-Ascend` 延续 `vLLM` 的执行引擎与 `KV Connector` 思路，同时针对昇腾设备实现独立的计算后端和传输路径。其官方 `PD` 设计明确给出了 `MooncakeConnector` 和 `MooncakeLayerwiseConnector` 两条实现。**两种模式的关键区别是接收端何时建立，以及 `KV` 在哪一个计算时点开始转移。**
![解耦式预填充-vllm-ascend](https://developer.qcloudimg.com/http-save/yehe-8159227/2f4527cbdfbdcc2d7f5769db8800c0ef.jpg)

在 `MooncakeConnector` 的拉取模式中，全局 `Proxy` 先调用 `select_prefiller` 选择 `P` 实例，将请求标记为远端解码，并让 `P` 完成输入计算。`P` 通过 `request_finished` 延后释放缓存，把远端传输参数反馈给 `Proxy`。随后 `Proxy` 选择 `D` 实例；`D` 进入 `WAITING_FOR_REMOTE_KVS`，分配本地缓存空间并主动从 `P` 读取状态。传输完成后通知 `P` 回收资源，`D` 开始生成后续输出。数据始终沿 `P → D` 方向移动，`Pull` 描述的是由 `D` 发起读取的控制方式。

`MooncakeLayerwiseConnector` 调整了执行顺序：`Proxy` 先选定 `D`，由 `D` 预留目标缓存并向 `metaserver` 发送请求，随后协调 `P` 执行 `Prefill`。`P` 每完成可传输的层级，就可以将对应 `KV` 推送至已知的 `D` 接收空间，传输与剩余层的计算因此具备重叠机会。完成全部必需的层级写入并确认后，`D` 才继续 `Decode`。该机制的收益来自缩短 `KV Transfer` 在关键路径上暴露的时间，实际幅度取决于模型层数、每层 `KV` 体积、网络带宽、事件同步与设备拓扑。

官方目前列出了 `A2/A3`、`MLA/GQA` 以及部分非对称 `TP` 的支持；其中非对称场景要求 `P` 侧 `TP` 大于 `D` 侧，并且 `P TP` 为 `D TP` 的整数倍，同时不支持在一个 `PD` 请求内混用 `A2` 和 `A3`。这些限制应该在服务部署前完成校验，不能只凭“支持 `PD`”的布尔配置进行判断。

# 四、`SGLang`：`Bootstrap`、`KVManager` 与传输后端共同实现 `PD`

`SGLang` 在执行引擎中直接引入 `--disaggregation-mode prefill` 和 `--disaggregation-mode decode`，将请求处理路径分成两个角色。`SGLang Router` 负责选择对应实例并协调请求，内部 `Bootstrap` 机制负责建立某次 `P/D` 交接的身份与连接信息。对一次请求而言，`bootstrap_room` 等字段可以帮助关联发送方、接收方、并行 Rank 和传输状态。

在实际源码中，包含 `CommonKVManager`、`CommonKVSender`、`CommonKVReceiver` 与 `CommonKVBootstrapServer` 等实现，以及 Mooncake、NIXL 等后端的具体 `conn.py`。`P` 的调度器负责准备和发送 KV，`D` 的调度器负责分配接收空间、等待传输与恢复 Decode；底层后端负责数据搬运、连接状态和错误处理。`SGLang` 目前还提供 `Ascend` 的 `--disaggregation-transfer-backend ascend` 路径，官方示例搭配 `memfabric-hybrid` 与 `ASCEND_MF_STORE_URL`，使其 `PD` 能力可以部署到昇腾设备；具体可用的模型与算子组合仍需核对版本能力表。一个关键差异在于 **`SGLang` 的 `PD` 协议更深入地与运行时的 `KV` 管理、并行 Rank、分块计算及 Router 协作绑定在一起**。
![index - Want to be a MlSys wizard](https://developer.qcloudimg.com/http-save/yehe-8159227/a7338842c4852bda5864311d56161644.jpg)

`SGLang` 的非对称 `P/D` 配置尤其值得关注。例如 `P` 使用较大的 `TP` 完成密集计算，而 `D` 使用 `DP Attention` 或不同 Attention 并行布局来改善生成阶段吞吐与延迟，此时发送方的 `KV` 分片布局与接收方的设备内存分布可能不同。官方针对该场景提供 `SGLANG_DISAGG_STAGING_BUFFER` 和 `SGLANG_DISAGG_STAGING_POOL_SIZE_MB` 配置，允许增加中转缓冲来完成分片整理与数据转发。其逻辑可以理解为先聚合或整理发送布局，再传输并映射到目标布局。官方文档将这一 GPU Staging Buffer 主要用于非 `MLA` 的 `GQA/MHA` 路径，`MLA` 模型需采用对应的其他布局处理方式。具体代价会随 `TP/DP`、模型结构和通信后端改变。

`SGLang` 当前文档有一个关于内存调度的问题：默认策略会在 `Prefill` 结束之前，为请求提前预留 `Decode` 端的目的 `KV` 空间。长输入请求即使还在 `P` 上计算，也可能占用 `D` 的显存容量。现在可以在两端配置 `--disaggregation-decode-allocation-policy prefill_complete`，将目的缓存的预留延迟到 Prefill 完成以后；这样改善了目的端空间占用，但会增加传输交接的等待与重新分配环节。因此平台不能只调 `P:D` 实例数，还要考虑 **`D` 侧目的缓存的分配时机**。

另外，官方当前文档明确列出了 `prefill_complete` 与 GPU Staging Buffer、运行时 P/D 角色切换等功能的兼容限制，两种优化策略需要结合引擎版本分别验证。
# 五、`MindIE Motor`：将 `PD` 从引擎内部问题提升到集群运行管理

`MindIE Motor` 的技术侧重点与 `vLLM`、`SGLang` 不同。它在模型计算执行器之外增加了集群级请求调度和运行管理。官方 `3.1` 架构主要由 `Coordinator`、`Controller`、`EngineServer`、`NodeManager` 和部署管理组件构成，其中 `Coordinator` 是客户端请求的入口和调度中心，`Controller` 负责全局状态、故障决策与实例管理，`NodeManager` 负责节点级推理进程启动及健康状态上报，`EngineServer` 对接底层推理引擎。`3.1` 文档明确说明当前正式支持的底层引擎为 `vLLM`。
![image](https://developer.qcloudimg.com/http-save/yehe-8159227/29d370c67b1f81631dfc061f2e9712f7.jpg)
一次请求进入 `Coordinator` 后，由 Router、Scheduler、RequestManager 和 InstanceManager 共同完成 `P/D` 选择与状态管理。`Controller` 保持实例角色、心跳和故障状态，并向 `Coordinator` 同步实例变更。具体 `KV` 迁移继续交给底层 `vLLM-Ascend` 的 Connector，因此 **`MindIE Motor` 解决的是分布式推理域内的路由、实例编排、角色管理与恢复问题；`KV Connector` 解决设备内存状态迁移问题**。两个层次可以独立演进，也要求在部署时共同验证版本兼容。

在实际配置中，`motor_engine_prefill_config`、`motor_engine_decode_config` 对应 `P` 和 `D` 的执行配置，普通合设方式对应 `motor_engine_union_config`。Connector 可以通过 `kv_transfer_config` 指定 `MooncakeLayerwiseConnector` 以及 producer/consumer 角色。`MindIE Motor` 还提供了 `PD` 回退 Hybrid、故障自愈、实例身份调整等控制参数，但是否可用必须结合版本、模式和部署条件进行验证。相较于引擎内部只关心请求与 KV，`MindIE Motor` 还需要解决多实例运行状态的一致性和异常后恢复。

另一个值得关注的是 `KV Pooling`。官方 `3.1` 文档说明，`MindIE Motor` 可以在已部署的 `PD` 服务上使用 `vLLM-Ascend` 的 KV Pool 能力：`P` 将计算结果推送到共享缓存池，`D` 再从池中读取。这样便将直接 `P2P` 传输扩展为“`P → KV Pool → D`”的存储路径，新增了可复用性和集中式缓存管理能力，也引入了缓存目录、淘汰策略以及外部缓存系统故障域。它属于可选的数据面设计，部署 `MindIE PD` 并不必然需要额外的共享 KV Pool。
# 六、对比

|维度|`vLLM/vLLM-Ascend`|`SGLang`|`MindIEMotor3.1`|
|:-:|:-:|:-:|:-:|
|主要架构切入点|`KV Connector`，调度与传输解耦|运行时 `PD` 角色、`Bootstrap`、KV 管理及传输后端|集群级 `Coordinator`、`Controller` 与运行管理|
|典型请求入口|外部 `Proxy / Router`|`SGLang Router`|`Coordinator`|
|状态转移实现|`Scheduler Connector + Worker Connector`|`KVManager + KVSender/KVReceiver + Transport`|底层 `vLLM-Ascend KV Connector`|
|`KV` 传输|`NIXL`、`Mooncake` 等，按后端组合|`Mooncake`、`NIXL`、`Ascend` 等|`MooncakeLayerwise` 等底层连接器|
|`GPU/NPU`|`vLLM CUDA` 与 `vLLM-Ascend`|`CUDA` 与 `Ascend` 路径|面向 `Ascend`，官方当前以 `vLLM` 为执行引擎|
|重点工程问题|Connector 兼容、调度器与 Worker 的状态同步|Bootstrap、并行布局转换、目标 KV 分配与释放时序|实例角色、负载调度、故障隔离与恢复|

从实现上来看，`vLLM` 最适合被理解为“推理引擎内的可插拔状态迁移体系”；`SGLang` 把 `PD` 与自身的推理调度、分布式 Attention 和 KV 生命周期深度结合；`MindIE Motor` 则在引擎之外补齐集群运行管理。三个方向各自解决的问题不同，但从推理这个动作本身来看，其实都打差不差：请求身份匹配、目标缓存分配、传输执行、完成确认以及源端状态安全释放。

另外，`NIXL` 与 `Mooncake` 也不对应固定的某一种芯片或推理引擎。`vLLM CUDA` 可以使用 `NIXL` 或 `Mooncake`，`SGLang CUDA` 支持两者，`vLLM-Ascend` 则有自己的 `Mooncake` 实现和分层推送路径。
# 七、工程中需要关注的问题

**第一类是状态兼容性**。`P` 和 `D` 必须使用相容的模型权重、Tokenizer、Attention 结构、`KV dtype`、块大小与内存布局；不对称 `TP/DP/EP` 还会引入 KV 分片重排。一个部署版本需要同时锁定模型版本、引擎版本、设备后端和 Connector 版本，运行中切换其中任一关键配置都需要重新验证交接协议。

**第二类是缓存生命周期**。`P` 的缓存要保存到 `D` 确认完成接收为止；`D` 已经分配的目标块，只有在所有远端写入停止并完成确认后才能安全回收。超时、请求取消、连接断开和 `Decode` 异常都需要进入同一套状态机，否则容易出现显存泄漏、悬空远端写入或者跨请求内容覆盖。`SGLang` 2026 年路线图重点处理的正是这类远端写入与显存释放竞态。

**第三类是通信成本**。长输入、更多 Attention 层以及高并发会放大一次交接的 `KV` 体积。`Pull`、整块 `Push` 和 `Layer-wise Push` 在不同网络条件下表现不同；分层推送可以把部分传输与计算重叠，但也会增加同步次数。在多节点 `TP`、`DP Attention`、`MLA` 和 `MoE EP` 组合下，`KV` 数据的逻辑布局与物理分片也会影响实际可用的带宽。

**第四类是性能评价**。推理平台应按请求记录 `P Queue`、`Prefill Compute`、`KV Transfer`、`D Queue`、`First Decode` 与后续 `TPOT`，并在同一模型、同一硬件总量、相近输入输出分布下比较合设和分离部署。一个 `PD` 配置即使降低了尾部 `TPOT`，如果 `KV` 传输显著抬高 `TTFT`，或者模型副本减少了有效可用显存，其整体服务能力仍可能退化。
# 结语

`PD` 分离推动推理系统从单一实例内部的批处理优化，发展到跨实例的模型运行状态管理。`vLLM` 使用可插拔 `KV Connector` 组织状态迁移，`vLLM-Ascend` 在此基础上区分了读取式交接与逐层推送，`SGLang` 把 `Bootstrap`、并行布局和传输生命周期放进自身运行时，`MindIE Motor` 进一步扩展到集群级调度、实例状态与恢复管理。

通过分析，可以看到的是：**`PD` 分离的技术复杂度主要集中在请求协同、KV 状态迁移、并行布局兼容和生命周期管理。** 未来模型引入更多 `MLA`、`SWA`、`Mamba/SSM` 或多模态状态以后，交接对象也可能超出传统 `Key/Value` 张量，平台最终需要管理的是能够使另一个执行实例继续推理的完整可恢复模型状态。

----
### 官方资料与源码

- [vLLM — Disaggregated Prefilling](https://docs.vllm.ai/en/latest/features/disagg_prefill/)
- [vLLM — NIXL KV Connector](https://docs.vllm.ai/en/latest/api/vllm/distributed/kv_transfer/kv_connector/v1/nixl/)
- [vLLM-Ascend — Disaggregated-prefill Design](https://docs.vllm.ai/projects/ascend/en/main/developer_guide/Design_Documents/disaggregated_prefill.html)
- [SGLang — PD Disaggregation](https://github.com/sgl-project/sglang/blob/main/docs/docs/advanced_features/pd_disaggregation.mdx)
- [SGLang — PD 2026 Q4 Roadmap](https://github.com/sgl-project/sglang/issues/43699)
- [MindIE Motor 3.1 — Architecture](https://www.hiascend.com/document/detail/en/mindie/310/servicedeploy/servicedev/docs/en/architecture.md)
- [MindIE Motor 3.1 — Configuration](https://www.hiascend.com/document/detail/en/mindie/310/servicedeploy/servicedev/docs/en/user_guide/configuration/config_reference.md)
- [MindIE Motor 3.1 — KV Pooling](https://www.hiascend.com/document/detail/en/mindie/310/servicedeploy/servicedev/docs/en/user_guide/features/kv_cache_store/README.md)

大模型推理中的 PD 分离：计算特征、KV Cache 传输与引擎实现 中对 vLLM、SGLang 与 MindIE 的 PD 实现的做了简单的说明，本篇在前篇的基础上，近一步细化三个推理引擎的的实现细节。

PD 分离如何实现：vLLM、SGLang 与 MindIE 的架构和技术路径

高级系统架构师

人工智能

本文深入剖析vLLM、SGLang与MindIE在PD分离架构下的实现差异，重点解析KVCache传输、状态迁移及缓存生命周期管理。对比NIXL与Mooncake等传输后端，揭示Pull与分层推送机制优劣，并指出状态兼容性与通信成本等关键工程挑战，为高并发推理优化提供实践参考。

大模型推理

路由

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

PD 分离如何实现：vLLM、SGLang 与 MindIE 的架构和技术路径-腾讯云开发者社区-腾讯云

PD 分离如何实现：vLLM、SGLang 与 MindIE 的架构和技术路径

PD 分离如何实现：vLLM、SGLang 与 MindIE 的架构和技术路径

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐