深度解读 · 约 4 分钟阅读
vLLM两种KV传输策略：不同延迟瓶颈，不是叠加加速
AWS两篇指南对照push交接与双向缓存复用，测试条件不同，不能把倍数相乘。
- 原文发布
- 本站发布
- 核实时间
AWS于10月19日发布两篇vLLM分离式推理指南，分别分析KV缓存传输的不同等待环节。本站合并解读其取舍，不把它们算成两次可叠加提速，也不当作测试模型的新版本发布。
听读资讯
朗读当前文章，或连续收听资讯。
正在准备听读…
设备语音
朗读由浏览器或设备处理，AISubHub 不向音频 API 发送文本。可用语音及锁屏播放能力因设备而异。
继续播放时可能重复一小段。
一分钟速览
- Push在P5en加EFA、一预填充一解码配置上，报告Qwen3-32B首词时间最多改善3倍、输出每词时间改善30%。
- 双向传输复用前轮解码缓存，在另一组缓存条件下，报告Qwen3-32B与GLM-5-FP8首词时间最多改善1.6及3.3倍。
同样架构不代表同一测试
预填充处理输入并建立KV缓存，解码利用缓存逐词输出。两类引擎独立扩容，同时增加生成前的状态交接。两文使用NIXL及支持的EFA硬件直接传设备内存，避免经主机中转。作者称最初在Trainium实现后贡献为跨加速器能力，但本文性能来自P5en GPU，不能推广为每种实例都支持直接内存传输。两种优化分别针对同一次请求的交接准备，以及下一轮重算旧上下文，必须分清等待发生在哪里。
Push把协调提前到计算期间
传统pull在预填充结束后经路由器转发位置，再由解码端分配并准备读取。Push让解码端在预填充仍计算时预留、登记目标块。生产端等登记和计算都完成，无论先后顺序，再由后台线程准备描述符、提交NIXL WRITE；解码端收到全部预期完成通知才使用缓存。这样减少解码主循环干扰，两端使用NixlPushConnector。但代价是更早选定解码节点；pull可等预填充结束再按负载选路由。
跨轮复用需要保留会话状态
双向设计保留解码端的提示与新生成响应KV，让下一轮预填充反向取回，避免重建历史。带状态路由器按conversation_id保存块位置元数据，而非KV张量。默认保留480秒，固定到期而不续租；过期后回普通预填充。默认复算阈值64个可复用词元：少于它时重算，达到或超过才可传输。AWS要求vLLM 0.21.0起、NixlConnector、两端开启bidirectional_kv_xfer并配合路由器，不是加一个开关就完成部署。
两组指标必须分别读
Push使用Qwen3-32B、一预填充一解码、P5en及EFA、128输出词元，关闭解码端前缀缓存以隔离传输。每秒8请求、16k输入时，pull首词约1744毫秒，push约540；高负载每输出词约10.4对7毫秒，轻负载短提示差异小。双向测试则关闭预填充端缓存，模拟本地历史丢失。长提示下Qwen在24k为778对460毫秒，GLM在20k为2334对702，对应该实验最多1.6与3.3倍；不是跨所有部署的统一排行。
本站分析：先选缓存政策再验收
Push原文明示，双向复用或延后选解码节点仍适合pull，因此不能把发表的提速倍数相乘。建议按真实轮次间隔、提示重合和负载，记录首词、逐词延迟、吞吐、内存与过期行为。只在复现实验时按其条件关闭缓存，不能当通用生产建议。还应测重试、旧位置元数据及会话隔离。这是本站验收建议，非作者额外结果；本站未部署或核算账单。价值在于明确协调、复用与路由的取舍，不是笼统保证任何应用都会更快。
有什么影响
团队应先判断瓶颈是单轮交接协调，还是多轮反复计算，再权衡路由灵活性、网络开销和缓存占用。
限制与可用性
这是AWS测试，本站未部署验证；模型、硬件、流量和缓存条件限制可比性。不能相乘收益，也不能推出个人会员额度或统一调用价格。
来源与证据
原文发布: 2026年10月19日 · 核实时间: 2026年10月20日
原文发布: 2026年10月19日 · 核实时间: 2026年10月20日
AI 辅助采编，依据所列一手来源核实。厂商自报结论注明归属，收录不代表背书。