[RFC]: [KV Connector]: Support KV push from Prefill to Decode node using Nixl Connector

快速结论：该 RFC 提出在 vLLM Prefill/Decode (P/D) 分离架构中，由 Prefill 节点主动向 Decode 节点推送 KV 缓存，以减少首 token 延迟（TTFT）。根据 Issue 中提供的基准测试，Push 模式下 TTFT 相比 Pull 模式有 1.2x-3.0x 的改进，尤其在长序列、高 QPS 场景下显著。优先排查：确认 Nixl Connector 配置正确、EFA 启用、以及 KV 传输的 push 模式是否已在代码层面启用。

问题场景

在 vLLM P/D 分离部署中，当前使用 Pull 模式（Decode 节点通过 NIXL READ 从 Prefill 节点拉取 KV 块）。当请求为大 prompt（如 512-2048 token）或高并发（QPS 8-16）场景时，Decode 节点必须等待 Prefill 节点完成计算后再发起 KV 传输，导致临界路径上产生不必要的空闲等待，TTFT 显著偏高。此 RFC 提议增加 Push 模式，由 Prefill 节点主动发起 NIXL WRITE，以重叠计算与传输，降低首 token 延迟。

报错原文

# 当前 Pull 模式下的限制场景可抽象为如下流程：
1. Proxy sends request to P
2. P computes KV and finishes the request
3. Proxy sends request to D with P's kv_transfer_params
4. D allocates blocks, handshakes with P, and initiates NIXL READ
5. D begins decoding after transfer completes
# 在 Push 模式下，流程变为：
1. Proxy sends to P and D simultaneously
2. D allocates blocks and registers via ZMQ side channel with P
3. P computes KV and immediately pushes (WRITE) to D's pre-registered memory
4. D decodes after transfer completes

原因分析

Pull 模式下，D 节点必须先等待 P 节点完成计算、代理转发请求参数、D 分配块并与 P 握手后，才能发起 NIXL READ。这一过程中，D 空闲且 P 的 KV 块无法提前释放，导致临界路径延迟增加。Push 模式允许 Proxy 同时向 P 和 D 发送请求，D 提前分配块并注册到 P，P 完成计算后立即推送，从而实现计算与传输的重叠，显著缩短 TTFT。

环境排查

确认 vLLM 版本是否包含 PR #35264 或其他支持 Push 模式的 Nixl Connector 实现。
确认 AWS P5en / Trn2 实例或等效硬件已启用 EFA（Elastic Fabric Adapter）。
确认 KV_TRANSFER_CONFIG 中 kv_role 设置为 kv_both（P 节点）或 kv_consumer（D 节点），并且 kv_rank、kv_parallel_size、kv_buffer_size 等参数正确。
确认 Nixl Connector 的后端配置中 backends 包含 ["LIBFABRIC"]。
确认 P 和 D 节点的 VLLM_NIXL_SIDE_CHANNEL_HOST 设置正确，且网络互通。

解决步骤

升级 vLLM 并启用 Push 模式：确认使用的 vLLM 版本包含了 Push 模式的 Nixl Connector 支持（如 PR #35264 或后续合并版本）。

配置 KV_TRANSFER_CONFIG：根据以下模板设置 P 和 D 节点的环境变量，确保 kv_connector 为 NixlConnector，kv_buffer_device 为 cuda，并正确指定 kv_ip 和 kv_connector_extra_config。

# P node
export VLLM_NIXL_SIDE_CHANNEL_HOST=<prefill_node_ip>
KV_TRANSFER_CONFIG='{"kv_connector":"NixlConnector","kv_buffer_device":"cuda","kv_role":"kv_both","engine_id":"prefill-engine-001","kv_rank":0,"kv_parallel_size":2,"kv_buffer_size":2e11,"kv_ip":"'"<prefill_node_ip>"'","kv_connector_extra_config":{"backends":["LIBFABRIC"]}}

# D node
export VLLM_NIXL_SIDE_CHANNEL_HOST=<decode_node_ip>
KV_TRANSFER_CONFIG='{"kv_connector":"NixlConnector","kv_buffer_device":"cuda","kv_role":"kv_consumer","engine_id":"decode-engine-001","kv_rank":1,"kv_parallel_size":2,"kv_buffer_size":2e11,"kv_ip":"'"<prefill_node_ip>"'","kv_connector_extra_config":{"backends":["LIBFABRIC"]}}'

启动 API Server：在 P 和 D 节点分别启动 vLLM OpenAI 兼容 API 服务，使用相同的模型、TP 配置和 --max-num-seqs 参数。例如：

python3 -m vllm.entrypoints.openai.api_server \
     --model <model_path> \
     --dtype bfloat16 \
     --max-num-seqs <batch_size> \
     --max-model-len <max_seq_len> \
     --tensor-parallel-size <TP_DEGREE>

配置代理：确保调度代理（Proxy Server）支持同时向 P 和 D 发送请求（P 节点设置 do_remote_decode=True，D 节点设置 remote_block_ids=[] 和 push 标志）。Issue 中提到 Push 模式下 “Proxy exits the transfer critical path”。
性能验证：运行基准测试（如 vllm bench serve）对比 Pull 和 Push 模式下的 TTFT。Issue 中提供了使用 sonnet dataset 的测试结果，表明在 AWS P5en 实例上 Push 模式在 TP=8、QPS=8、输入长度 2048 等场景下 TTFT 提升了约 1.2x-3.0x。

验证方法

通过监控 TTFT（首 token 时间）、TPOT（每个输出 token 时间）和请求吞吐量来确认改进。Issue 中的基准数据表明，Push 模式在高 QPS 和长输入序列下更能体现优势，尤其 P99 TTFT 大幅下降（例如在 TP=8、QPS=16 场景下 P99 从 7880ms 降至 3681ms）。同时确认 Decode 节点不再等待 Prefill 计算结束才发起传输，且 P 节点的 KV 块在 WRITE 完成后即可释放。