解耦式预填充

为何采用解耦式预填充？

此功能旨在优化大规模推理任务中的单输出词元时间（TPOT）和首词元生成时间（TTFT）。主要动机有两点：

1. 灵活调整P节点与D节点的并行策略与实例数量 采用解耦式预填充策略，系统能够灵活调整P（预填充器）节点与D（解码器）节点的并行化策略（如数据并行（dp）、张量并行（tp）与专家并行（ep））及其实例数量。这使得系统性能调优更加精细，尤其有助于优化TTFT和TPOT。

2. 优化TPOT 若不采用解耦式预填充策略，预填充任务会穿插在解码过程中执行，导致效率低下与延迟。解耦式预填充通过提升对系统TPOT的控制能力解决了这一问题。系统通过有效管理分块预填充任务，不仅规避了确定最优分块大小的难题，还能更可靠地控制生成输出词元所需的时间。

---

使用方法

vLLM Ascend 目前支持两种用于管理KV缓存的连接器：

• MooncakeConnector：D节点从P节点拉取KV缓存。

• MooncakeLayerwiseConnector：P节点以分层方式将KV缓存推送到D节点。

关于分步部署与配置的详细指南，请参阅：https://docs.vllm.ai/projects/ascend/en/latest/tutorials/pd_disaggregation_mooncake_multi_node.html

---

工作原理

1.设计思路

在解耦式预填充架构下，一个全局代理接收外部请求，并将预填充任务转发给P节点，解码任务转发给D节点；P节点与D节点之间通过点对点（P2P）通信交换KV缓存（键值缓存）。

2.实现设计

我们的设计示意图如下所示，分别展示了拉取与推送两种方案。

Mooncake Connector 流程：

1. 请求被发送至代理的 _handle_completions 接口。

2. 代理调用 select_prefiller 选择一个P节点并转发请求，同时配置 kv_transfer_params，设置 do_remote_decode=True、max_tokens=1 以及 min_tokens=1。

3. P节点的调度器完成预填充后，update_from_output 调用调度连接器的 request_finished 来延迟释放KV缓存，构建包含 do_remote_prefill=True 的 kv_transfer_params，并返回给代理。

4. 代理调用 select_decoder 选择一个D节点并转发请求。

5. 在D节点上，调度器将请求标记为 RequestStatus.WAITING_FOR_REMOTE_KVS，预分配KV缓存，调用 kv_connector_no_forward 拉取远程KV缓存，随后通知P节点释放KV缓存，并继续解码以返回结果。

Mooncake Layerwise Connector 流程：

1. 请求被发送至代理的 _handle_completions 接口。

2. 代理调用 select_decoder 选择一个D节点并转发请求，同时配置 kv_transfer_params，设置 do_remote_prefill=True 并指定 metaserver 接口。

3. 在D节点上，调度器利用 kv_transfer_params 将请求标记为 RequestStatus.WAITING_FOR_REMOTE_KVS，预分配KV缓存，随后调用 kv_connector_no_forward 向元数据服务器发送请求，并等待KV缓存传输完成。

4. 代理的 metaserver 接口收到请求后，调用 select_prefiller 选择一个P节点并转发请求，同时将 kv_transfer_params 设置为 do_remote_decode=True、max_tokens=1 以及 min_tokens=1。

5. 处理过程中，P节点的调度器逐层推送KV缓存；所有层推送完成后，释放该请求并通知D节点开始解码。

6. D节点执行解码并返回结果。

3.接口设计

以 MooncakeConnector 为例，系统主要由三个核心类构成：

• MooncakeConnector：提供核心接口的基类。

• MooncakeConnectorScheduler：在引擎核心内调度连接器的接口，负责管理KV缓存传输的需求与完成状态。

• MooncakeConnectorWorker：在工作进程中管理KV缓存注册与传输的接口。

4.规格设计

此功能设计灵活，支持多种配置，包括配备MLA与GQA模型的部署。它与A2和A3硬件配置兼容，并能支持多个P节点与D节点间TP设置对等或不对等的场景。

功能	状态
A2	🟢 功能完备
A3	🟢 功能完备
对等TP配置	🟢 功能完备
非对等TP配置	🟢 功能完备
MLA	🟢 功能完备
GQA	🟢 功能完备

• 🟢 功能完备：完全可用，正在进行持续优化。

• 🔵 实验性：提供实验性支持，接口与功能可能发生变更。

• 🚧 开发中：正在积极开发，即将提供支持。

• 🟡 计划中：已规划未来实现（部分可能已有开放的PR或RFC）。

• 🔴 无计划/已弃用：暂无计划或已被vLLM弃用。

---

可维护性（DFX）分析

1.配置参数验证

通过检查 kv_connector 类型是否受支持、kv_connector_module_path 是否存在且可加载，来验证KV传输配置。传输失败时，输出清晰的错误日志以便诊断。

2.端口冲突检测

启动前，通过尝试绑定方式对配置的端口（如 rpc_port、metrics_port、http_port/metaserver）进行端口占用检查。若端口已被占用，快速失败并记录错误。

3.PD比例验证

在非对称PD场景下，根据预期值与调度约束验证P节点与D节点的TP比例，以确保系统正确可靠地运行。

---

限制条件

• 不支持异构的P节点与D节点——例如，在A2上运行P节点，在A3上运行D节点。

• 在非对称TP配置中，仅支持P节点的TP度数高于D节点，且P节点的TP数量是D节点TP数量的整数倍的情况（即 P_tp > D_tp 且 P_tp % D_tp = 0）。