跳转至

预填充-解码分离

为什么需要预填充-解码分离？

该特性旨在优化大规模推理任务中的**每个输出 Token 时间（TPOT）和**首个 Token 时间（TTFT）。其动机有两个方面：

  1. Adjusting Parallel Strategy and Instance Count for P and D Nodes
    Using the disaggregated-prefill strategy, this feature allows the system to flexibly adjust the parallelization strategy (e.g., data parallelism (dp), tensor parallelism (tp), and expert parallelism (ep)) and the instance count for both P (Prefiller) and D (Decoder) nodes. This leads to better system performance tuning, particularly for TTFT and TPOT.

  2. Optimizing TPOT Without the disaggregated-prefill strategy, prefill tasks are inserted during decoding, which results in inefficiencies and delays. 预填充-解码分离 solves this by allowing for better control over the system's TPOT. By managing chunked prefill tasks effectively, the system avoids the challenge of determining the optimal chunk size and provides more reliable control over the time taken for generating output tokens.

使用方法

vLLM Ascend 当前支持两种类型的连接器来处理 KV 缓存管理：

  • MooncakeConnector：D 节点从 P 节点拉取 KV 缓存。
  • MooncakeLayerwiseConnector：P 节点按层方式将 KV 缓存推送到 D 节点。

For step-by-step deployment and configuration, refer to the following guide:
https://docs.vllm.ai/projects/ascend/en/latest/tutorials/features/pd_disaggregation_mooncake_multi_node.html

工作原理

1.设计思路

在预填充-解码分离架构下，一个全局代理接收外部请求，将预填充请求转发给 P 节点，将解码请求转发给 D 节点；KV 缓存在 P 节点和 D 节点之间通过点对点（P2P）通信进行交换。

2.实现设计

Our design diagram is shown below, illustrating the pull and push schemes respectively. 示意图 示意图

Mooncake 连接器

  1. 请求被发送到代理的 _handle_completions 端点。
  2. 代理调用 select_prefiller 选择一个 P 节点并转发请求，配置 kv_transfer_params，设置 do_remote_decode=True、max_completion_tokens=1 和 min_tokens=1。
  3. P 节点的调度器完成预填充后，update_from_output 调用调度连接器的 request_finished 延迟 KV 缓存的释放，构造包含 kv_transfer_params 的 do_remote_prefill=True，然后返回给代理。
  4. 代理调用 select_decoder 选择一个 D 节点并转发请求。
  5. 在 D 节点上，调度器将请求标记为 RequestStatus.WAITING_FOR_REMOTE_KVS，预分配 KV 缓存，调用 kv_connector_no_forward 拉取远程 KV 缓存，然后通知 P 节点释放 KV 缓存，并继续解码以返回结果。

Mooncake 分层连接器

  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_completion_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 和不等 TP 配置场景。

功能 状态
A2 🟢 功能完善
A3 🟢 功能完善
相等 TP 配置 🟢 功能完善
不等 TP 配置 🟢 功能完善
MLA 🟢 功能完善
GQA 🟢 功能完善
  • 🟢 功能完善：完全可用，持续优化中。
  • 🔵 实验性：实验性支持，接口和功能可能发生变化。
  • 🚧 开发中：正在积极开发，即将支持。
  • 🟡 计划中：已计划未来实现（部分可能有开放的 PR/RFC）。
  • 🔴 无计划/已废弃：无计划或已被 vLLM 废弃。

DFX 分析

1.配置参数验证

通过检查 kv_connector 类型是否受支持，来验证 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）。