vLLM中基于推送的KV传输优化分离式推理

随着DeepSeek-V3和Claude 3.5 Sonnet等现代大语言模型参数量飙升至数千亿规模，高效部署这些模型已不再依赖单一集群的盲目扩展，而是需要底层架构的持续创新。预填充与解码分离架构已成为核心技术范式，它将计算密集型的提示词处理（预填充）与内存带宽受限的Token生成（解码）过程拆分到不同的引擎实例中。然而，这种架构拆分带来了一个关键痛点：必须在预填充和解码实例之间高效传输键值（KV）缓存。在这篇技术评测中，我们将深入剖析vLLM中最新引入的基于NIXL连接器的推送式KV传输机制，分析它如何消除协调开销，从而大幅降低首字延迟（TTFT）并提升每个输出Token的耗时表现（TPOT）。

分离式LLM推理的网络瓶颈

在标准的单体式LLM服务架构中，单个GPU实例需要同时处理预填充阶段（并行处理输入提示词）和解码阶段（按顺序生成回复Token）。这两个阶段的硬件资源利用特征截然不同。预填充属于计算密集型任务，需要海量的并行矩阵乘法运算；而解码则受限于内存带宽，主要瓶颈在于以多快的速度将模型权重和KV缓存从高带宽内存加载到处理器核心中。

通过将预填充与解码拆分到独立的实例中，基础设施工程师可以针对每种工作负载定制硬件配置。例如，预填充节点可以采用高吞吐量的计算集群，而解码节点则专注于高内存带宽。然而，通过网络将生成的KV缓存从预填充引擎传输到解码引擎会引入显著的延迟。传统的拉取式架构要求解码实例主动请求并等待缓存到位，这使得数据传输直接处于关键执行路径上，从而导致推理流水线出现停顿。

引入基于推送的NIXL连接器

为了解决这一协调开销，vLLM集成了一种由NIXL连接器驱动的推送式KV传输机制。预填充引擎不再强迫解码引擎轮询数据，而是在计算完成后立即将KV缓存主动推送至目标解码实例。

这种设计转变将网络传输协调与主推理循环彻底解耦。通过利用亚马逊EC2 P5en实例上的AWS弹性结构适配器（EFA）等高性能网络织物，推送式NIXL连接器绕过了传统的内核网络栈，利用远程直接内存访问（RDMA）语义将张量数据直接写入目标GPU的内存缓冲区。

KV缓存传输机制架构对比

在AWS EC2 P5en实例上的性能基准测试

当部署在配有NVIDIA H100 GPU和AWS EFA的亚马逊EC2 P5en实例上时，基于推送的NIXL架构带来了巨大的性能提升。将传统的拉取式架构与vLLM全新的推送式集成进行对比的基准测试表明，各项核心指标均有显著改善：

1. 首字延迟（TTFT）： 在高并发请求负载下降低了最多3倍。由于KV缓存能够预先到达解码节点，解码引擎几乎可以瞬间开始生成Token。
2. 输出Token耗时（TPOT）： 性能提升高达30%。消除了传输停顿确保了稳定、可预测的Token生成速率，这对于实时AI代理和交互式聊天应用至关重要。

对于使用LangChain等框架编排复杂工作流，或通过n1n.ai API生态系统构建自定义多智能体系统的开发者而言，这些延迟的降低直接转化为更流畅的用户体验和更低的底层基础设施成本。

在vLLM中实现推送式KV传输

配置vLLM以结合推送式NIXL连接器运行分离式推理，需要在预填充和解码引擎实例中设置特定的初始化参数。以下是在分布式Python环境中部署该配置的实用代码模板：

from vllm import AsyncEngineArgs, AsyncLLMEngine

# 预填充引擎实例配置
prefill_engine_args = AsyncEngineArgs(
    model="deepseek-ai/DeepSeek-V3