vLLM 推出基于推送的 KV 传输，分离式推理的 TTFT 提升最高 3 倍
决策简报
Brief- 发生了什么
- AWS 为 vLLM 贡献了基于推送的 NIXL 连接器，把 KV 缓存传输的协调与准备工作移出关键路径，在 P5en 与 EFA 的 1P1D 部署上实测 TTFT 最高改善 3 倍、TPOT 改善 30%。
- 为什么重要
- Qwen 相关结果会影响评测基准、技术路线和后续产品判断。
- 影响谁
- Qwen
- 建议动作
- 升级或复核变更版本
- 地区可用性
- 暂未验证地区可用性差异。
关键事实
- AWS 为 vLLM 贡献了基于推送的 NIXL 连接器，把 KV 缓存传输的协调与准备工作移出关键路径，在 P5en 与 EFA 的 1P1D 部署上实测 TTFT 最高改善 3 倍、TPOT 改善 30%。 [src-aws-ml]
- 预填充侧新增后台传输线程并提前注册目标块，让解码实例在等待首 token 时不再串行执行元数据中继和 NIXL 描述符准备，代价是路由器必须在预填充完成前就选定解码实例，牺牲了一部分负载感知路由的灵活性。 [src-aws-ml]
由事件证据自动生成。
该推送模式由三个阶段组成：解码实例在分配目标块时即通过 NIXL 通知把块位置发给预填充实例；预填充完成后按请求 ID 配对，处理注册与预填充到达顺序不一致的情况；随后由预填充侧的专用后台线程发起 NIXL WRITE，直接把 KV 块写入解码实例注册的内存，并按张量并行 rank 逐一发送完成通知，解码侧收齐全部通知后才开始生成 token。由于描述符准备和传输提交不再占用两个引擎的主循环，这部分每请求开销不再拖慢模型执行。 基准测试使用 Qwen3-32B，在 1P1D 拓扑、Amazon EC2 P5en 实例加 EFA 互联、关闭前缀缓存的条件下，输入长度 1k 至 16k、请求速率 1 至 8 QPS。8 QPS 加 16k 输入时，拉取模式 TTFT 约 1744 毫秒，推送模式约 540 毫秒；TPOT 从约 10.4 毫秒降到约 7 毫秒。低负载短提示下两种模式差距很小。 对运行 vLLM 分离式预填充/解码部署的团队来说，启用方式是把预填充和解码服务器都配置为 NixlPushConnector，高请求速率和长上下文场景收益最明显；但推送模式要求提前选定解码实例，依赖负载感知路由做服务质量管理的团队需要权衡这一取舍。该特性先在 Trainium 集群上验证，再以与加速器无关的形式合入 vLLM。
摘要依据：已读全文详摘依据上方标注的来源范围整理，内容以原文为准。
来源
- AWS：Machine Learning Blog
Applied ML, infra, and deployment guidance useful for AI builders on AWS.
- AWS：Machine Learning Blog
留言
登入后即可留言，和其他 builder 交换实测心得。
还没有留言，抢头香。