vLLM 推送式 KV 傳輸瞄準 Prefill 與 Decode 之間的等待時間
vLLM 的推送式 KV 傳輸將快取交接工作提早進行；AWS 指出，與其拉取式基準測試相比，首個 token 延遲最多可改善 3 倍。首個 token 時間（time to first token，TTFT）量度請求在生成開始輸出前需等待多久。這項改動針對的是處理提示詞與生成答案之間的協調流程。
AWS 在 10 月 19 日的文章中亦表示，每個輸出 token 時間（time per output token，TPOT）最高可改善 30%，該指標量度每個後續 token 的生成時間。這些結果涉及在採用 AWS Elastic Fabric Adapter、即該公司低延遲伺服器互連技術的 Amazon EC2 P5en 執行個體上運行 Qwen3-32B。它們描述的是特定比較，而非承諾每個 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 的結果更具參考脈絡。這項貢獻針對的是較大型服務流程中的一個特定環節。其價值取決於改善該環節是否能推進服務實際的回應目標。
較早選擇解碼器以彈性換取重疊執行
保留 pull 的最有力理由，是能夠較遲才決定目的地的價值。
push 流程要求在交接前預先準備好接收端。這項承諾能實現重疊執行，但亦構成文章的核心取捨。營運方無法將協調延遲的降低，與目的地選擇的時機分開評估。
設想一項假設服務，其請求在解碼器池中分布不均。及早選擇目的地，代表在 prompt 處理完成前預留一條路徑。較遲選擇，則讓路由決策可取得較新的系統資訊。
兩種選擇都不會自動較優。若預填期間的狀況維持可預測，及早選擇可算是合理的交換。若情況出現顯著變化，較遲選擇便可能帶來以傳輸為重點的基準測試無法反映的營運價值。
關鍵問題是，這種彈性多常會改變結果。營運方應檢視延遲選擇是否確實能減少排隊、避開過載的工作程序，或提升服務一致性。缺乏這些觀察，彈性仍只是抽象好處，而非經量度的需求。
這亦是為何配對式部署無法解決所有路由問題。它提供了一個受控環境，用於檢視一次交接。對於多個目的地之間的選擇，它提供的證據較少，尤其當這些目的地承受不同工作負載時。
快取重用的論述亦引入另一個邊界。vLLM 在 10 月 12 日的文章中描述了雙向 KV 傳輸，會在後續對話回合中，將可重用的狀態由解碼端傳回預填端。該工作利用雙向 NIXL 讀取，以應對隨對話歷史增長而增加的重複運算。
這代表不同的最佳化目標。較短的正向交接和較少的重複 prompt 運算，均可提升回應速度。兩者的好處不應假定會自動疊加，也不應被當作量度相同工作來比較。
對話式助理正好說明這項分別。其首次請求，以及其後包含累積歷史的請求，可能對基礎設施提出不同要求。改善其中一次轉換，並不能證明那是整段對話的最佳策略。
就 vLLM 的 push 與 pull 而言，這表示當產品依賴工作階段行為時，評估應將其納入其中。一股由無關 prompt 組成的均勻流，只回答了較狹窄的問題。它不能取代對應用程式重複互動的測試。
停用快取的基準測試同樣值得審慎看待。移除重用有助隔離傳輸行為，但生產環境的重用會改變該行為的重要性頻率。經常避免完整傳輸的應用程式，面對的是不同的機會條件。
這並不會令受控比較失效，而是界定了其用途。營運方應保留孤立結果，同時加入工作負載評估，以還原應用程式實際的快取和路由決策。
報稱收益亦有證據邊界。這些數字來自參與其中的技術來源，而非本文所審閱的獨立重現結果。它們值得調查，但不足以支持普遍優越或保證整個叢集節省成本的說法。
因此，審慎的結論是明確的：及早準備有可理解的機制，但其整體價值仍取決於部署情況。穩妥的採用決策，必須同時量度協調效益及為此交換出去的彈性。
pull 基準也在改變
部分報稱優勢涉及傳輸準備工作在何處執行；pull 同樣可以重新檢視這項設計選擇。
一項公開的讀取器執行緒提案針對 NIXL pull 提交。其列明目的，是將讀取提交移至專用背景執行緒，從而減少引擎前向執行緒的工作。該提案保留在前向執行緒上輪詢完成狀態。
本文審閱的頁面將該提案列為開放狀態。這證明開發仍在進行，並非已交付的效能結果。它並未提供基礎，讓人聲稱未來的 pull 實作可媲美 push，或填補某個百分比的差距。
它的重要性在於概念層面。傳輸方向與執行位置是兩項獨立選擇。push 可受惠於較早準備目的地，而背景執行則處理另一種干擾來源。
這項分別改變了對基準領先幅度的詮釋。比較所反映的是當刻接受測試的實作。它不會永久將每項觀察到的好處，歸因於勝方所附帶的架構標籤。
對買家及營運方而言，實際後果是必須留意版本。「Push」和「pull」不足以描述評估環境。相關實作和設定，決定哪些準備步驟在哪裏執行。
這使維護歷史成為效能證據的一部分。後續的連接器更新可在不改變模型或硬件的情況下改變基準。當執行行為出現實質變化，團隊應重新檢視先前結論。
讀取器執行緒工作亦提供有用的測試，用以驗證底層解釋。若背景提交在可比較條件下改善 pull，將支持執行位置的重要性。單憑這點，卻不會消除重疊準備目的地的獨立好處。
相反，若改善有限，仍須加以詮釋。餘下延遲可能涉及其他依賴關係，或工作負載可能揭示不同限制。令人失望的結果，不會自動證明該提案設計在其他情況下毫無價值。
這正是效能報告需要克制之處。一份有用的報告會分開列出已量度的內容、解釋它的機制，以及仍屬假設的事項。混合這些類別會產生自信的標題，卻提供薄弱的營運指引。
對 vLLM 的 push 型 KV 傳輸而言，持久的教訓是檢視交接周邊的工作。連接器名稱概括行為，但不能解釋每一項延遲。對實際執行路徑進行效能分析仍屬必要。
持續演變的基準亦不鼓勵過早作出標準化決策。團隊可採用符合當前需要的設定，同時保留日後重新檢視的證據。目標是可靠服務，而不是對某個傳輸方向作永久效忠。
留意重現結果、pull 執行緒進展及路由行為
下一批有用證據將顯示，孤立的協調收益能否在實際部署選擇下維持。
在未來一至三個月，首個值得留意的訊號是針對貼近應用程式工作負載的獨立重現。最有參考價值的結果，會保留同一比較方式，同時改變 prompt 分布、快取行為及部署規模。一致的改善將強化更廣泛採用的理由。
重現亦應區分回應啟動與持續生成。服務需要知道它是否在整個互動過程中變得更靈敏。若有利結果只集中於要求異常高的基準測試點，便只支持較狹窄的部署決策。
第二個訊號是 pull 背景提交的進展。經審閱並發布的實作，再配合可比較的基準測試，將釐清執行位置的貢獻有多大。較小的差距將強化機制解釋，同時削弱將 push 視為絕對優越的理由。
這個訊號需要實際量度結果。僅合併變更只代表可用性，而非效能對等。在相關工作負載接受測試前，營運方不應把開發活動轉化為數字主張。
第三個訊號是超越固定預填—解碼配對的路由行為。結果應展示及早選擇目的地面對變化中的解碼器需求時會發生甚麼。若面向用戶的延遲維持穩定，將強化重疊執行於實際配置壓力下仍具價值的論點。
若較早承諾反而在其他地方造成更長隊列，偏好的部署邊界便會收窄。push 可能仍適合可預測的工作負載，而較遲選擇對其他工作負載仍具價值。這將細化結果，而非否定結果。
這些訊號讓討論繫於原始事件。問題在於，提前進行準備工作是否能在其自身營運條件下改善完整服務。對推理經濟效益的更廣泛主張，需要比這項連接器比較所提供的更廣泛證據。
對正在決定現時應如何行動的團隊，先從具代表性的請求追蹤和明確定義的回應目標開始。比較連接器結果時，保留模型、快取政策、路由行為及實作版本。記錄等待發生的位置，然後檢視較早準備能否減少該延遲，同時不會在其他地方造成更大的隊列。將受控基準與貼近生產環境的評估分開，使各自回答清晰問題。在將報稱比率轉化為容量決策前，先閱讀設計及基準條件。對 vLLM 的 push 型 KV 傳輸而言，有用的行動是對應用程式實際執行的交接進行有限度評估。較早準備目的地，是否能在服務必須承受的負載下，改善用戶所獲得的體驗？
