实践 · vLLM
vLLM 为什么要把对话缓存送回输入处理节点
vLLM 介绍了一种把保留的缓存从生成节点送回下一次请求处理节点的方法。团队的长对话因此多了一个选择：传输已有数据，还是重新计算。对于已经分离处理阶段的服务，缓存的路线和节点互连可能比再添一块加速器更值得先研究。
这对买家意味着什么
输入处理与答案生成分离的本地服务，可以考虑用双向缓存传输优化后续对话。判断它是否有用，应观察后续轮次的等待时间以及实际传输路径，不能只看互不相关的简短问题回答得有多快。
下一次提问又带回了旧文本
在2026年10月12日的文章中，vLLM讨论了多轮对话中的双向 KV 缓存传输。关键变化是：处理输入文本的节点，可以取回答案生成节点保留下来的中间计算数据。对团队而言，这提供了一个具体的排查方向。继续对话时的延迟，可能来自再次处理历史文本，而不只是模型规模。
文章首先指出，这类请求会再次携带对话历史和工具结果。假设助手正在讨论一个错误修复，收到命令输出后继续分析，这是一个假设场景。用户看到的变化也许只有几行，但服务器收到的新请求仍然包含已经处理过的对话内容。因此，先前完成的计算可以被看成一种值得复用的资源，而不能只关注刚刚增加的文字。
单向传输只覆盖了半个循环
在分离式架构中，prefill 负责处理输入文本，decode 负责生成后续内容。按照作者描述的传统方案，缓存从前一个阶段流向后一个阶段。这条路线能够服务当前答案。可是答案完成后，decode 保留下来的缓存又会对下一次请求的准备阶段有用。下一阶段需要数据的位置，已经与原来的传输方向不同。
反向传输把这个循环接起来：prefill 可以复用 decode 在回答后保存的数据。因此，这项变化的价值要在一连串有关联的请求中观察。用彼此无关的短问题做展示，很难说明它的优势。答案最终有多长，也不能单独解释第一个新片段为什么迟迟没有出现，因为系统还要先处理随请求一起到达的上下文。
缓存不经过路由器搬运
在文章描述的架构中，路由器保存缓存块的元数据，实际的张量则直接在节点之间传输。元数据可以理解为关于已保存数据块的信息，张量则是承载中间计算结果的数组。采购服务器方案时，这个区别很重要：中央组件负责安排工作，但所有需要搬运的缓存数据并不会都穿过它。
作者在两个传输方向上都使用 NIXL READ。买家无需研究它的编程接口，也能理解其中的基础设施问题：工作节点之间的数据路径很重要。某个节点计算得更快，并不能回答把缓存送到另一个节点是否划算。因此，这类方案应交代节点互连，而不能只给出加速器清单。传输路线也是模型推断服务的一部分。
搬运现成结果，还是重新计算？
作者还指出，获取远端缓存受到一个可配置的重新计算阈值影响。这个参数背后是一个容易理解的选择：把已经算好的数据搬过来，或者再次处理文本。无法预先认定其中一种办法适合所有请求。具体的对话历史和传输条件都会影响这个选择，而阈值使它成为运行环境中的一项实际设置。
由此可以向集成方提出一个具体问题：简短的继续提问，与重新接上很长的历史，分别会走哪条路径？如果规则选择重新计算，没有发生缓存传输本身并不说明系统出了故障。应能看到实际选择的路径及其耗时。这样才能讨论延迟的原因，而不是把每一次慢回答都归因于计算能力不够。
团队服务要看第二次请求
在vLLM实验中，Qwen3-32B输入达到24K时，首个词元等待时间从778毫秒降至460毫秒。提示处理与生成分别运行在两台EC2 p5en.48xlarge上，每台有八块H200，并通过EFA互连；Qwen以bfloat16运行，每台节点采用张量并行8。实验关闭提示处理节点的前缀缓存，以模拟缓存丢失。复现方案使用vLLM 0.29.0、NIXL 1.4.1，以及让流式响应返回缓存元数据的补丁。因此，这属于具体多轮负载的结果，不能承诺单台服务器也会得到相同加速。自有集群还取决于互连、轮次间隔及缓存保留情况。
可以用一次有针对性的比较来评估：分别开启和关闭反向传输，运行同一段多轮会话，记录继续提问后等待第一个片段的时间。模型、历史和工具结果应保持一致。采购结论也很明确：对于已经采用分离式架构的团队服务，应先评估双向缓存模式，再决定是否增加计算资源。这项技术的长处，是在对话轮次之间保留已经完成的工作。
选购系统前要验证什么
- 路由器如何得知哪个节点保存着所需的数据块？
- 针对团队的实际负载，重新计算阈值设为多少？
- 所需的已保存数据块不存在时，请求如何继续？
- 多个会话同时运行时，继续对话的等待时间如何变化？
买家建议属于我们的编辑解读。原文并不证明目录中某款系统的速度或兼容性。