解耦预填充

解耦预填充#

为什么需要解耦预填充？#

此功能旨在优化大规模推理任务中的每输出令牌时间（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://vllm-ascend.readthedocs.io/en/latest/tutorials/pd_disaggregation_mooncake_multi_node.html

工作原理#

1. Design Approach#

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

2. Implementation Design#

我们的设计图如下所示，分别展示了拉取和推送方案。替代文本 替代文本

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缓存的释放，构建 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 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. Interface Design#

以 MooncakeConnector 为例，系统被组织为三个主要类：

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

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

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

4. Specifications Design#

此功能灵活，支持多种配置，包括MLA和GQA模型设置。它与A2和A3硬件配置兼容，并支持在多个P和D节点之间使用相同或不同的TP设置场景。

功能

状态

A2

🟢 功能正常

A3

🟢 功能正常

相同TP配置

🟢 功能正常

不同TP配置

🟢 功能正常

MLA

🟢 功能正常

GQA

🟢 功能正常

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

  • 🔵 实验性：实验性支持，接口和功能可能更改。

  • 🚧 开发中：正在积极开发，将很快支持。

  • 🟡 计划中：计划未来实现（部分可能已有开放的PRs/RFCs）。

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

可调试性/可观测性（DFX）分析#

1. Config Parameter Validation#

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

2. Port Conflict Detection#

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

3. PD Ratio Validation#

在非对称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）。

目录