vLLM 基于推送的 KV 传输瞄准 Prefill 与 Decode 之间的等待
vLLM 基于推送的 KV 传输将缓存交接工作前移。AWS 表示，与其基于拉取的基准方案相比，这一方法可将首个 token 延迟最多改善 3 倍。首个 token 时间（TTFT）衡量请求在生成开始输出前需要等待多久。这项变化针对的是处理提示词与生成回答之间的协调环节。
AWS 在其 10 月 19 日的文章中还表示，每个输出 token 时间（TPOT）最高可改善 30%；该指标用于衡量后续每个 token 的生成时间。这些结果针对的是使用 AWS Elastic Fabric Adapter 的 Amazon EC2 P5en 实例上运行的 Qwen3-32B；Elastic Fabric Adapter 是该公司的低延迟服务器互连技术。这描述的是一项特定比较，而非对所有 vLLM 部署都能普遍加速的承诺。
核心较量在于推送与拉取两种协调方式。推送会更早准备接收端引擎；拉取则保留更晚决定生成应在何处运行的空间。对于将提示词处理与生成分开的运营者而言，这一消息提出了一个具体问题：为了缩短交接时间，他们应当以多少路由灵活性作为交换？
vLLM 基于推送的 KV 传输改变了交接开始的时机
这一变化将准备工作前移，减少了提示词处理完成后必须进行的工作。
Prefill 是处理输入 token 的推理阶段，会生成包含后续生成所需中间注意力状态的键值缓存。Decode 是生成输出 token 的阶段，会消费这些状态。解耦推理将这些阶段部署在不同的引擎实例上，从而在两者之间形成传输边界。
AWS 的 KV 传输基准测试使用一个 prefill 实例和一个 decode 实例比较推送与拉取。测试关闭了前缀缓存；否则，请求可复用先前计算的状态。测试采用 128 个输出 token、1,000 至 16,000 个 token 的输入长度，以及每秒一至八个查询的请求速率。
在负载要求较高的一端，AWS 报告拉取的 TTFT 约为 1,744 毫秒，而推送约为 540 毫秒。其报告的 TPOT 对比中，拉取约为 10.4 毫秒，推送约为 7 毫秒。在轻负载和较短输入条件下，两种模式的表现相近。
这些边界条件比标题中的倍数更重要。结果确定了一类交接协调开始变得重要的工作负载。它并不能证明使用率较低的服务、不同模型或更大规模部署也会获得同样收益。
实际含义在于，当响应能力恶化时，运营者应改变排查方向。缓慢的首次响应并不自动意味着提示词计算需要更多加速器容量。用于组织下一阶段的时间同样值得单独审视。
这一差异也改变了产品团队解读性能事件的方式。如果用户报告回答延迟，团队需要区分是在等待计算，还是在等待协调。增加资源对这两类原因的作用不同，而汇总延迟图表可能掩盖两者的区别。
因此，这项基准测试支持一个聚焦的结论：围绕缓存传输的时序会实质影响测得的体验。合适的下一步是识别该时序是否占据某项特定服务延迟中的重要部分。
将此称为拉取的通用替代方案，会夸大现有证据。更有用的理解是，vLLM 现在提供了另一种调度选择。运营者可以根据实际需要的工作负载和路由行为来评估这一选择。
这一时机值得关注，因为它是服务实现层面的改进，而非模型发布。团队无需假定模型质量发生变化，就可以对此展开研究。潜在收益存在于现有请求穿过基础设施的方式中。
服务团队除了计算问题，还面临协调问题
压力主要落在那些延迟目标依赖于将提示词处理与 token 生成分开的运营者身上。
vLLM 的解耦 prefilling文档将这种分离描述为可独立调优首个 token 延迟与 token 间延迟的方式。文档还指出，当提示词处理进入一个已经在生成回答的引擎时，会产生干扰。该文档将此功能标注为实验性，并明确警告不要将解耦本身视为吞吐量提升手段。
这为广泛的架构主张提供了重要制衡。分离工作创造了独立调优的机会，但也引入了责任。系统必须协调状态、选择目标位置，并让请求跨越额外边界持续推进。
以一个假设的文档助手为例，这些责任对应着可识别的用户行为。用户提交一份篇幅很长的文档，并等待回答开始出现。与此同时，其他用户期待已有回答能持续稳定地输出。
这些期待彼此相关，但不能互相替代。服务可以快速开始回答，随后却以不均匀的节奏输出；它也可以在开始后流畅生成，却让用户在任何内容出现前等待过久。
推送方案的重要性在于，运营者必须同时评估这两种体验。连接器决策应同时考量响应启动和持续生成，而不是只看单一有利的平均值。否则，团队可能改善了自己监控的指标，却忽视了用户实际注意到的体验。
这会促使基础设施负责人改进其测量模型。他们需要了解请求的各个阶段，以及总耗时。缺乏这种区分时，协调开销可能被误认为模型执行时间。
这也会对评估托管推理服务的采购方形成压力。报告中的加速比例需要结合基线、工作负载和运行边界来理解。采购方在利用此类结果比较服务之前，应询问结果背后发生了什么变化。
当应用混合处理长请求与短请求时，这一区分尤其相关。平均提示词长度会掩盖那些带来最大调度压力的请求。一项有说服力的评估应保留这种差异，而不是用统一输入取而代之。
这些内容都不能证明每个应用都需要解耦。决策仍应从服务已经观察到的约束开始。如果当前架构已满足响应目标，增加传输边界需要自身的理由。
不过，对于已经运行独立阶段的团队而言，连接器会成为性能规划的一部分。其行为影响路由器必须掌握的信息，以及资源在何时被锁定。这使这一变化的相关性超出了维护传输代码的工程师群体。
因此，产品与平台团队需要对成功建立共同描述。一个有用的描述应将用户可见的等待时间与基础设施测量和部署条件联系起来。它避免将连接器的基准测试当作应用的完整预测。
维护这些评估的团队可以将发现整理到一个可搜索的知识库中。将配置与结论放在一起，有助于后续审阅者理解早先结果为何适用或不适用。
提前设置目标位置赋予推送相对拉取的优势
推送改变了传输周围的依赖顺序，而不是免除了移动缓存状态的需要。
推送连接器设计文档介绍了 NixlPushConnector，这是一个使用 NVIDIA Inference Xfer Library（NIXL）协调传输的替代方案。接收端 decode 引擎分配目标内存并传达其位置。随后，prefill 引擎将完成的状态写入该已准备好的目标位置。
注册信息与完成的提示词状态可以以任意顺序到达。连接器会在发起写入前将它们匹配起来。后台写入线程负责处理推送专属操作，而完成状态记录则告知引擎何时接收的状态已经就绪。
这就是 vLLM 推送传输的核心解释：在有用的计算继续进行时安排目标位置，然后在其前提条件具备时完成交接。这种时序减少了必须等到 prefill 完成后才开始全部协调工作的需求。
将这种差异视为依赖关系问题，会更容易评估。如果准备工作无法在计算完成前启动，请求便需要依次等待两者。如果准备工作与计算重叠，决定生成何时能开始的路径上就会减少部分等待。
这种重叠仍有条件。接收端必须存在，其目标位置必须合适，且传输必须正确完成。提前准备改变的是这些责任发生的时机；并不会使它们变成可选项。
这也是为什么仅将推送描述为更快的网络操作会错过其机制。架构问题关乎哪些工作会阻塞进度。传输可以使用高性能硬件，而周围的软件仍可能让请求进行不必要的等待。
后台执行还带来另一项有用的区分。不再阻塞引擎循环的工作，仍会在某处消耗资源。因此，运营者应询问这些工作被转移到了哪里，以及该位置在持续需求下能否保持健康。
同样的推理也适用于解读 TPOT。如果与传输相关的变化同服务现有请求的执行路径竞争，便会影响持续生成。只评估新进入的请求，会遗漏这种交互。
因此，对于 vLLM 的推送与拉取比较，决定性对照范围比写入与读取更广。它涵盖目标选择、准备时机、执行归属和就绪信号。这些细节解释了为何改变连接器能够在不改变模型的情况下改变应用行为。
该实现也说明了，在任何部署决策中，正确性都应与性能并列考虑。若生成需要完整的预期状态，仅接收到部分状态并不足够。成功交接需要明确无歧义的就绪条件，尤其是在工作跨越多个参与方时。
NVIDIA 通过 Dynamo 的解耦服务架构提供了有用的行业参考。其文档描述了独立的 prefill 和 decode 资源池、路由器编排以及拓扑感知的传输考量。这表明确实存在可比较的协调问题，而非提供了相对于 vLLM 连接器的性能排名证据。
Dynamo 也是服务引擎的集成环境，因此将此描述为简单的公司对公司竞赛会产生误导。真正相关的竞争在于组织请求的不同方式。每种方法都必须协调部署位置、状态移动与生成就绪状态。
这一比较为 AWS 的结果提供了背景。该贡献涉及更大服务流程中的一个具体环节。它的价值取决于改善该环节是否能推进服务实际的响应目标。
更早选择 decoder 以灵活性换取重叠执行
保留 pull 的最有力理由，是能够更晚决定目标位置的价值。
push 流程要求在交接前准备好接收端。这种提前承诺能实现重叠执行，但也带来了本文的核心权衡。运营者无法脱离目标位置选择的时机，单独评估协调延迟的降低。
设想这样一种服务：请求在 decoder 池中分布并不均匀。提前选择目标位置，会在 prompt 处理完成前预留一条路径。更晚选择则能让路由决策获得关于系统状态的更新信息。
两种选择都不会天然更优。如果 prefill 期间的条件保持可预测，提前选择可以是一种合理交换。如果条件发生显著变化，更晚选择可能具有以传输为重点的基准测试无法捕捉的运营价值。
关键问题在于，这种灵活性多久会改变一次结果。运营者应考察延迟选择是否能显著减少排队、避开过载 worker，或提升服务一致性。没有这些观测数据，灵活性就仍是一项抽象优势，而非经过衡量的需求。
这也是为何成对部署无法解决所有路由问题。它为考察一次交接提供了受控环境。对于在多个目标位置之间作出选择时，尤其是这些目标位置负载各不相同时，它能提供的证据较少。
缓存复用的讨论又增加了一个边界。在 10 月 12 日的一篇文章中，vLLM 介绍了双向 KV 传输：它会在后续对话轮次中将可复用状态从 decode 返回至 prefill。随着对话历史增长，这项工作利用双向 NIXL reads 来解决重复计算问题。
这代表着不同的优化目标。更短的正向交接和更少的重复 prompt 计算都可能改善响应性。但不能想当然地认为其收益会自动叠加，也不应将两者视作对相同工作量的衡量。
对话式助手可以说明这种差异。它的首次请求与包含累积历史的后续请求，可能对基础设施提出不同要求。改善一次转换，并不能证明这是整个对话的最佳策略。
对于 vLLM 的 push 与 pull 而言，这意味着当产品依赖会话行为时，评估应将其纳入其中。由无关 prompt 组成的均匀流只回答了一个更狭窄的问题。它不能替代对应用重复交互的测试。
禁用缓存的基准测试同样需要谨慎对待。移除复用有助于隔离传输行为，但生产环境中的复用会改变这种行为的实际重要性。频繁避免完整传输的应用，其机会特征也会不同。
这并不使受控比较失效，而是界定了它的用途。运营者应保留这一孤立结果，同时增加能恢复应用实际缓存和路由决策的工作负载评估。
报告收益还存在证据边界。这些数字来自参与其中的技术来源，而非本文审查过的独立复现。它们值得进一步研究，但不足以支持普遍优越性或保证整个集群节省成本的说法。
因此，审慎的结论很明确：提前准备具有可理解的机制，但其整体价值仍取决于部署环境。稳健的采用决策必须同时衡量协调收益与其所交换的灵活性。
pull 基线也在变化
报告优势的一部分与传输准备在何处执行有关，而 pull 同样可以重新审视这一设计选择。
一项公开的reader-thread 提案针对 NIXL pull 提交。其声明目标是将 read 提交移至专用后台线程，从而减少引擎 forward 执行线程上的工作量。该提案仍将完成状态轮询保留在 forward 线程上。
本文审查的页面将该提案列为开放状态。这证明它仍在持续开发中，而非已交付的性能结果。它不能作为依据，声称未来的 pull 实现将匹配 push，或缩小某一特定百分比的差距。
其意义在于概念层面。传输方向与执行位置是两项独立选择。push 可以受益于更早的目标端准备，而后台执行则处理另一种干扰来源。
这种区分改变了对基准领先幅度的解读。比较所捕捉的是当时被测试的实现。它不会永久地将每一项观察到的收益归因于获胜者所附带的架构标签。
对于采购方和运营者而言，实际影响是需要关注版本。“Push”和“pull”不足以描述评估环境。相关实现和配置决定了哪些准备步骤会在哪里运行。
这使维护历史成为性能证据的一部分。后续 connector 更新可能在不改变模型或硬件的情况下改变基线。当执行行为发生实质性变化时，团队应重新审视先前结论。
reader-thread 工作也为检验底层解释提供了有用测试。如果后台提交在可比条件下改善了 pull，这将支持执行位置重要性的判断。但它本身并不能消除目标端设置重叠带来的独立收益。
反过来，有限的改善仍需要解释。剩余延迟可能涉及其他依赖关系，或者工作负载可能暴露出不同约束。令人失望的结果并不会自动证明该提案的设计在其他场景没有价值。
这正是性能报告需要保持克制的地方。一份有用的报告会区分已测量内容、解释其作用机制的内容，以及仍属假设的内容。将这些类别混在一起会产生自信的标题，却提供薄弱的运营指导。
对于基于 push 的 vLLM KV 传输，持久的经验是审视交接周围的工作。connector 名称概括了行为，却无法解释每一项延迟。对实际执行路径进行性能分析仍属必要。
不断演进的基线也不鼓励过早作出标准化决定。团队可以采用满足当前需求的配置，同时保留日后重新评估它的依据。目标是可靠的服务，而非对某种传输方向的永久忠诚。
关注复现、pull 线程进展与路由行为
下一项有价值的证据，将显示孤立的协调收益能否经受真实部署选择的考验。
未来一到三个月内，首先应关注跨越贴近应用形态的工作负载所进行的独立复现。最具信息价值的结果会保留相同的比较，同时改变 prompt 分布、缓存行为和部署规模。持续一致的改进将加强更广泛采用的理由。
复现还应区分响应启动与持续生成。服务需要了解它是否在整个交互过程中都更具响应性。若有利结果仅限于一个异常苛刻的基准测试点，则只支持更狭窄的部署决策。
第二个信号是 pull 后台提交的进展。经审查并发布的实现，再配合可比基准测试，将澄清执行位置究竟贡献了多少。更小的差距将加强对机制的解释，同时削弱将 push 视为绝对优越方案的理由。
这一信号需要实际测量结果。单纯合并一项变更只能证明其可用性，而非性能对等。在相关工作负载经过测试前，运营者应避免将开发活动转化为数字化结论。
第三个信号是固定 prefill-decode 配对之外的路由行为。结果应显示，当提前选择目标位置遇到变化中的 decoder 需求时会发生什么。稳定的面向用户延迟将加强这样的判断：在现实的部署压力下，重叠执行仍具价值。
如果提前承诺反而在其他位置造成更长排队，优选部署边界就会收窄。push 可能仍适合可预测的工作负载，而更晚选择对其他场景仍有价值。这将细化结果，而非否定它。
这些信号使讨论始终围绕原始事件。问题在于，在自身运行条件下，更早进行准备是否能改善完整服务。关于推理经济性的更广泛主张，需要比这一 connector 比较所提供的证据更广泛的支撑。
对于正在决定当下行动方案的团队，应从具有代表性的请求轨迹和明确定义的响应目标开始。比较 connector 结果时，应保持模型、缓存策略、路由行为和实现版本一致。记录等待发生的位置，再考察更早准备是否能在不于其他位置造成更大队列的情况下减少该延迟。将受控基准测试与贴近生产环境的评估分开，使两者各自回答明确的问题。在将报告的比率转化为容量决策前，先阅读设计与基准测试条件。对于基于 push 的 vLLM KV 传输，有效行动是对应用实际执行的交接进行有界评估。在你的服务必须承受的负载下，更早准备目标位置是否改善了用户实际获得的体验？
