工程 / 工程
TTFT 提升最高 3 倍,TPOT 改善 30%
大语言模型推理通常分为预填充和解码两个阶段,分离式部署将二者运行在不同实例上以实现独立扩展。然而,这种架构要求在解码开始前将 KV 缓存从预填充实例传输至解码实例,传输效率直接决定首字时延(TTFT)。vLLM 默认采用拉取模式,解码端在预填充完成后才发起传输请求,协调与准备步骤均处于关键路径上。AWS 团队提出推送式 NIXL 连接器,让解码端提前注册目标内存块,预填充端在计算完成后立即主动写入,并通过专用后台线程承载传输任务,从而将协调开销移出关键路径。在搭载 AWS EFA 网络的 Amazon EC2 P5en 实例上,针对 Qwen3-32B 模型的基准测试显示,推送模式相比拉取模式可实现最高 3 倍的 TTFT 提升和 30% 的 TPOT 改善。该功能已作为加速器无关特性贡献至 vLLM 开源社区。
大语言模型推理包含两个计算特性截然不同的阶段:预填充阶段处理输入提示并构建键值缓存(KV Cache),解码阶段则逐令牌生成输出。分离式推理架构将两个阶段部署在独立实例上,使各自能够按需扩展并独立优化,从而提升整体资源利用率和吞吐量。但这一架构的代价是必须在解码开始前完成 KV 缓存的跨实例传输,传输效率因此成为影响首字时延的核心瓶颈。
vLLM 通过 NVIDIA 推理传输库(NIXL)连接器实现 KV 块传输,借助支持远程直接内存访问(RDMA)的互联网络(如 AWS EFA)在 GPU 或 AWS Trainium 设备内存之间直接传输数据,无需经过主机内存中转。然而,默认的拉取模式存在明显的串行化问题:路由器将预填充块 ID 转发给解码端后,解码端才开始分配目标块、准备传输描述符并发起 NIXL READ 操作,这些步骤全部落在首字时延的关键路径上。
推送式连接器通过重新设计协调流程解决上述问题。其核心思路是让解码端在分配本地内存块时立即向预填充端发送注册通知,告知目标块位置。预填充端收到注册信息后进行汇合匹配:若注册先于预填充完成到达,则等待计算结束;若预填充先完成,则等待注册到达。两个事件中后发生的那个触发传输,从而消除了解码端的往返发现延迟。
传输本身由预填充端的专用后台线程负责执行。该线程建立与解码实例的连接后,发起 NIXL WRITE 操作,将 KV 块直接写入解码端已注册的内存区域,并按张量并行分片分别寻址。预填充端和解码端可以使用不同的内部块布局,各自在传输时映射到本地物理布局,支持两侧使用不同的块大小。每次写入完成后,NIXL 向解码端发送完成通知,解码端在收到所有预期通知后才将请求标记为可解码状态。
在搭载 EFA 网络的 Amazon EC2 P5en GPU 集群上,以 1 个预填充实例加 1 个解码实例的配置部署 Qwen3-32B 模型进行基准测试,推送模式在高请求速率下相比拉取模式实现了最高 3 倍的 TTFT 提升和约 30% 的 TPOT 改善。该特性最初在 AWS Trainium 实例集群上构建和验证,随后以加速器无关的方式贡献至 vLLM 开源项目,GPU 环境下的测试结果证实性能增益同样适用。
推送式 KV 传输的优势在高并发场景下尤为显著,因为此时拉取模式的串行协调开销会随请求积压而放大。对于需要在分离式推理架构中兼顾响应速度与吞吐量的生产部署,该方案提供了一条无需更换硬件即可显著改善用户体验的优化路径。用户可通过 vLLM 官方仓库获取该功能,并参照 AWS 发布的基准复现指南在自有集群上验证效果。
要点
- 推送式 NIXL 连接器让解码端提前注册目标内存块,预填充完成后立即主动写入,消除了拉取模式中的往返协调延迟,将传输准备工作移出首字时延关键路径
- 在 Amazon EC2 P5en 实例配合 AWS EFA 网络的测试中,Qwen3-32B 模型的 TTFT 最高提升 3 倍,TPOT 改善约 30%,高请求速率下效果更为明显
- 该功能支持预填充端与解码端使用不同的 KV 块布局和块大小,具备加速器无关性,已正式贡献至 vLLM 开源社区,GPU 和 AWS Trainium 环境均可使用
- 专用后台传输线程将 KV 写入操作与模型前向计算解耦,避免传输开销占用解码实例的令牌生成计算资源,从而同时改善延迟和吞吐量两项指标
原始标题:Push-based KV transfer to improve TTFT and TPOT for disaggregated inference in vLLM
本文由 DataHub 基于公开来源整理,用于信息发现与摘要阅读;具体事实、数据和后续更新以原始来源为准。