vLLM 雙向 KV 傳輸減少多輪代理中的重複運算
AWS 表示，使用 vLLM 雙向 KV 傳輸後，首個 token 的速度最高可提升 3.3 倍。這項技術能雙向在伺服器之間移轉可重用的模型運算。首個 token 時間（TTFT）衡量請求在回應開始前需要等待多久。這項改動針對一項特定低效問題：代理會重複處理其服務基礎設施其實已運算過的對話歷史。
AWS 在 10 月 19 日的文章中表示，Qwen3-32B 的改善最高達 1.6 倍，而 GLM-5-FP8 則最高達 3.3 倍。其 多輪推論基準測試採用透過 Elastic Fabric Adapter 連接的 Amazon EC2 P5en 執行個體；這是 AWS 為高要求分散式工作負載而設計的網絡技術。這些均為公司自行報告的結果，並非經獨立驗證的效能保證。
核心取捨在於：是重新運算舊有內容，還是從另一部伺服器取回可重用的運算成果。NVIDIA Dynamo 為這類基礎設施選擇提供了一個有用的業界參考。對正在開發代理的開發者而言，眼前的問題是：自己的工作負載是否花了足夠時間重複處理舊工作，以至值得增加額外協調成本。
vLLM 雙向 KV 傳輸改變了甚麼
這項功能可讓早前回應期間完成的運算工作，提供予處理下一個請求的伺服器使用。
鍵值快取（KV cache）會儲存語言模型處理序列時可重用的中間注意力資料。Prefill 處理輸入 token，即模型讀取的文字單位。Decode 則產生回應。在解耦式服務架構中，這兩個階段由不同工作節點負責。
這條新路徑之所以重要，是因為產生回應的伺服器持有該回應的有用運算成果。後續請求可以同時包含這些已產生的文字及較早的對話內容。若另一部伺服器處理該請求，原本有用的快取工作便可能仍滯留在產生回應的一端。
NIXL connector 指南描述了一個有狀態代理程式，用以跨回合追蹤快取位置。NIXL，即 NVIDIA Inference Xfer Library，提供傳輸機制。在其後的回合中，prefill 工作節點可在處理新輸入前，從 decode 工作節點擷取合資格的區塊。
這改變了可重用運算的來源位置，卻不會免除處理真正新增內容的需要。
設想一個說明性的編程代理正在調查建置失敗問題。它讀取錯誤訊息、提出解釋、呼叫工具，並接收測試結果。下一個模型請求同時包含熟悉的對話歷史和新證據。為熟悉部分重複進行運算，對調查不會帶來任何新資訊。
若移動既有運算所需時間少於重新建立它，擷取便具吸引力。這個條件正是該功能在經濟及技術層面的核心。若傳輸雖節省運算，卻增加更長等待時間，便會違背原意。
這亦解釋了為何這則消息不僅關乎更快的模型基準測試。模型可以維持不變，而服務系統則改變了先前工作在多次呼叫之間可保留多少。基礎設施的行為成為代理回應速度的一部分。
對產品團隊而言，這項區別有助釐清責任所在。後續回應緩慢，並不必然表示所選模型需要更換。應用程式可能正再次為已處理過的內容付出成本。
對基礎設施團隊而言，這改變了分析單位。若將每項請求視為互不相關，便可能忽略只有在請求屬於持續任務時才會出現的機會。對話因而與排程及快取管理相關。
因此，實際改變的範圍比持久代理記憶更窄，但更具體。它關乎附屬於持續輸入序列的可重用運算。代理能否記住正確事實，仍是另一個應用程式問題。
這條界線令公告保持實用。它識別出可量度的延遲來源，卻沒有聲稱能解決推理質素、工具可靠性，或代理周邊的所有延遲。
不斷增長的對話令服務團隊承受壓力
最受影響的團隊，是在同一任務中提供重複、內容密集模型呼叫服務的團隊。
壓力來自應用程式行為與以請求為導向的基礎設施之間的不匹配。代理的任務會跨越多次呼叫持續進行，而服務系統仍須決定每項請求之後可保留哪些運算成果。
以一個說明性的研究助理為例，這種不匹配很容易理解。它收集文件、比較發現、收到修正意見，然後修改答案。每個階段都引入新資訊，但大量工作內容仍然相關。
從使用者角度看，這些階段屬於同一項工作。從服務層角度看，每個階段都產生另一項需要處理輸入的請求。機會在於識別延續性，同時不假設輸入中的每個部分仍可重用。
這項區別對評估代理示範的企業買家很重要。回應迅速的開場互動，並不能證明長時間調查仍會保持迅速。評估應跟隨任務進入後續回合，包括修正及工具回傳結果。
這對決定投資方向的工程經理同樣重要。模型選擇、應用程式設計及服務配置，分別針對不同的延遲來源。在這些來源被區分前，籠統地抱怨代理感覺緩慢，幾乎無法提供指引。
vLLM 文件在其解耦式 prefill指引中作出了一項相關區分。分開 prefill 與 decode 後，可獨立調校兩者的延遲行為。文件亦提醒，解耦本身不會提升吞吐量，即系統在一段時間內完成的工作量。
這項提醒避免人們輕易將更快開始回應，推論為更高整體容量。應用程式可以改善一項延遲指標，而另一個瓶頸則維持不變。買家應詢問：擬議的基礎設施改動實際針對哪一種結果。
客戶支援代理正好說明差異。更快開始解釋可令對話感覺更靈敏，但不一定能縮短緩慢的帳戶查詢，或完成外部操作所需的時間。
同樣地，編程助理可以更早開始說明修復方法，卻未必能更早完成其測試套件。效能改善仍有價值，但其貢獻須放在更大的任務時間線中理解。
對知識工作者而言，與個人知識庫的關聯很實際：尋找有用資訊與處理重複內容會造成不同等待時間。改善其中一項，並不代表另一項也已有改善。
對產品團隊而言，這意味著應同時量度回應開始時間及完成任務的時間。否則，基礎設施帶來的收益可能在市場推廣中被誇大，或在開發過程中被忽略。
這正是 vLLM 多輪推論值得以整個序列評估的原因。重要問題不只是伺服器能否快速回答，而是隨著任務擴展，重複互動能否保留有用工作。
重用所競爭的是重新運算，而非競爭模型
最有力的比較，是同一持續工作負載的不同服務方式。
將這項公告變成模型排行榜會造成誤導。AWS 測試的是服務最佳化；結果並不能證明某個模型比另一個模型更有能力。
現有基準同樣值得審慎看待。vLLM 已支援自動前綴快取，當請求共享起始序列時，可重用快取運算。其文件指出，重複查詢文件及多輪對話均屬相關工作負載。
因此，雙向傳輸所解決的是跨工作節點存取可重用運算的問題，並非首次引入避免重複處理提示內容的普遍概念。
這項區別改變了團隊應如何理解比較結果。已可保留有用本機快取的部署，與反覆失去存取該快取能力的部署，起點並不相同。增量效益取決於既有系統實際做了甚麼。
vLLM 的 prefill 與 decode 分拆不僅造成運算問題，也造成部署位置問題。有用工作可能存在於部署中的某處，卻未必能在下一項請求需要的位置使用。
一個有用的比喻，是工程團隊因已完成的分析結果放在另一個小組手上而重複分析。欠缺的是存取及協調，而非原始運算速度。加快原始計算會處理問題的另一部分。
NVIDIA 的解耦式服務文件提供中立比較。Dynamo 將 prefill 與 decode 工作節點分開，並將這種分拆與按快取位置進行路由區分開來。它亦警告，解耦並非自動適合每一種工作負載。
這使 Dynamo 成為業界參考，而非直接競爭勝出的證據。文件顯示，工作節點放置、傳輸及重用是更廣泛的服務議題，但並未提供與此 AWS 配置相匹配的比較。
對買家而言，有用的競爭問題是：在可比條件下，替代系統是否能更有效率地處理其對話模式。單靠產品名稱無法回答這個問題。
同樣推理亦適用於既有部署內的 vLLM 多輪推論。團隊應將擬議路徑與其實際現行配置比較。與人為削弱的配置作比較，只能回答較狹窄的問題。
複雜度應放在哪裏亦是一項選擇。將工作保留在本機可簡化存取，但可能限制部署位置；遠端擷取則可擴大重用機會，但會引入協調及傳輸工作。
兩種方法都不會必然勝出。決定性的證據是，在應用程式的運作條件下，所節省的運算是否超過新增的工作量。
這個框架讓分析聚焦於已驗證事件。它避免虛構 AWS 與 NVIDIA 之間的競爭，因為實作本身便使用 NVIDIA 的傳輸技術。
這項公告更適宜理解為分散式推論的改良。它提供額外的重用途徑，然後仍由營運者負責確認該路徑何時值得採用。
快取存續成為效能方程式的一部分
重用功能只有在下一項請求到達時，有用的運算仍可使用，才能帶來價值。
連接器文件說明，解碼端的預設保留期為 480 秒，亦指出在觸發反向傳輸前，預設門檻為 64 個可重用 token。低於該門檻時，系統會在本機重新計算。
這些控制項揭示了標題背後的取捨。保留快取資料會佔用記憶體，擷取資料則會增加工作量；過早釋放資料，便會失去日後重用的機會。
正確選擇取決於任務的模式，而不是普遍偏好更多快取。很快恢復的對話，與使用者在檢視結果期間暫停的對話，所呈現的機會並不相同。
試想一個內部分析代理，在繼續執行前等待批准。下一個請求可能在短暫核對後到達，也可能要等到會議結束。即使模型沒有主動回應，在這兩段時間內保留計算結果都會帶來資源成本。
自動化代理則形成另一種模式。工具完成、重試及應用程式排程，都可能決定下一個請求何時到達。因此，營運人員應檢視實際回合之間的間隔，而非從精心修飾的示範中推斷。
擷取門檻亦帶來相應問題。遠端重用存在額外開銷，因此避免重新計算並不足以證明請求會更快。可重用的工作量必須足以抵銷取得成本。
就 vLLM 雙向 KV 傳輸而言，這表示設定決策可同時影響延遲及記憶體壓力。這些結果應一併檢視，而非各自獨立最佳化。
慶祝回應開始時間改善的團隊，也應詢問在兩次回應之間仍被佔用的是哪些資源。另一個減少保留記憶體的團隊，則應詢問因此增加了多少重複工作。
這些是評估問題，並非證明該功能必然損害容量。已發布的說法僅在既定條件下證實存在延遲改善機會。更廣泛的部署經濟效益仍需要額外量度。
工作階段處理同樣值得注意。系統需要把持續中的請求關聯至正確的既有計算結果。會中斷這種關聯的應用程式改動，可能削弱原本適合的工作負載。
例如，產品團隊可能重新設計建立或恢復對話的方式。這項看似獨立的應用程式改動，應促使團隊重新進行效能檢查。重用途徑依賴連續性傳達至服務層。
因此，vLLM 的 prefill 與 decode 邊界不只是模型服務專家的營運考量。應用程式工程師與基礎設施工程師需要共同理解任務如何跨請求延續。
更廣泛的教訓，是有意識地保留有用工作。快取保留、請求身分及傳輸決策，應放在同一場效能討論中。把它們視為無關設定，只會令最終行為更難解釋。
基準測試衡量的是特定的快取遺失情境
AWS 報告中最大的增益，應與產生該結果的基準一併解讀。
AWS 在 prefill worker 上停用了本機前綴快取，以模擬快取被逐出，或路由至沒有該對話快取區塊的 worker。其比較使用一個 prefill 節點及一個 decode 節點。
這是相關的情境，但並不代表每種正式環境部署。它探討的是當 prefill 端缺乏可重用的本機內容時會發生甚麼情況；並不能證明相較於能持續保留該內容的安排，亦有同樣優勢。
基準測試重現指南補充了一項重要實作細節。指引鎖定特定軟件版本，並包括一個修補程式，用於在串流回應中回傳傳輸中繼資料。因此，重現結果時必須留意經測試的軟件路徑。
這項細節之所以有用，正因為它涉及營運。單憑功能旗標，並不足以證明部署實際重用了遠端計算。請求流程必須攜帶尋找該計算結果所需的資訊。
獨立驗證仍是另一回事。重現材料令實驗更易檢視，但發布指引本身並不構成外部重現。
結果來自供應商，並不表示需要否定它。恰當做法是保留其適用範圍。AWS 報告的是已記錄設定下的效益；營運人員仍需為自己的流量尋找證據。
「最高」一詞同樣具有實質意義。它指的是一個有利的觀察結果，而非每個請求的預期結果。較短輸入、不同重用模式或不同部署條件，都需要各自量度。
回應開始延遲應與整體任務時長分開看待。首個 token 可以較早到達，但其餘回應所需時間可能相若。工具工作及應用程式處理仍可能不在改善範圍之內。
同樣地，功能設定之間的有利比較，並不能證明基礎設施支出會按比例下降。這種結論需要把資源及容量量度與延遲一併考慮。
有用的評估應保留正式環境的基準，而不是移除既有最佳化。接著應識別遠端重用在哪些方面能在這些最佳化以外增加價值。
測試亦應刻意納入不利情況。沒有可重用內容的請求、恢復中的對話，以及一般應用程式中斷，都有助界定改善的邊界。
這些情況並非基準測試的干擾因素。它們決定了基準測試中的有利條件，會在客戶實際使用的服務中出現多少次。
這正是對該公告採取懷疑角度的適當方式。機制已有文件記錄，報告結果亦很具體。尚未解決的問題，是這個機會在測試設定以外出現的頻率及價值。
營運人員未來三個月應留意甚麼
下一項有用證據，將把可重現的延遲改善與一般應用程式流量及營運條件連結起來。
第一個訊號是針對類似正式環境基準的獨立重現。強而有力的後續結果，會保留既有本機快取行為，並顯示遠端擷取何時能帶來增量效益。
這類證據會加強 vLLM 雙向 KV 傳輸作為既有服務系統實際補充方案的論點。若改善幅度小得多，則會收窄其最佳使用情境，但不會否定原來的快取遺失結果。
重現亦應令比較容易理解。讀者需要知道哪些部分維持不變、哪些部分有所改動，以及哪些請求受益。單一孤立的標題倍數無法解釋這些差異。
第二個訊號是在不同對話時機及負載下的效能。有用報告應涵蓋持續中的工作階段，以及暫停後再恢復的對話，並把延遲行為與保留記憶體及可用服務容量連結起來。
若結果能在這些條件下維持回應速度，將提升對更廣泛部署的信心。若結果需要異常有利的時機，則顯示應採取更具選擇性的使用方式。
這很重要，因為代理的任務排程往往由模型伺服器以外的因素決定。服務最佳化必須配合該排程，而不是假設應用程式總會配合。
第三個訊號，是圍繞路由及中繼資料提供更清晰的整合證據。營運人員應留意可重現的設定，證明遠端重用實際發生，同時在無法發生時展現可理解的行為。
這將減少在啟用功能與實際獲得效益之間的不確定性。相反，反覆出現的整合失敗，將增加採用該功能所需的營運成本。
這些訊號亦提供更好的替代方案比較方法。NVIDIA Dynamo 及其他服務安排，應面對相同的應用程式工作負載及成果指標。各自獨立的基準說法，不能單獨證明誰勝誰負。
對開發人員而言，眼前機會預設是調查性的，而非架構性的。在承諾採用更複雜的部署前，先確認後續請求花時間在哪裏。
對企業買家而言，應詢問示範的改善能否在與自身相似的任務中延續。納入後續回合、修正、工具等待及恢復的工作。短暫的開場交流，無法回答核心的重用問題。
對產品團隊而言，應保持回應速度與實用性之間的區分。當回應仍然正確，且任務仍能可靠完成時，更早開始回應才有價值。服務指標應與這些成果並列考量。
先從具代表性的代理工作階段開始，量度時間花在哪裏。在選擇最佳化前，分開輸入處理、回應生成、工具等待及應用程式工作。然後把遠端重用與部署中已有的快取行為作比較。要求證據證明有用的計算能在回合之間保留下來，並傳達至需要它的 worker。在相同工作負載下追蹤已完成任務的延遲及首個 token 延遲，並檢視記憶體使用量。vLLM 雙向 KV 傳輸提供了恢復重複工作的具體方法，但其價值取決於這些工作有多常能被重用。把已發布的基準測試視為可驗證的線索，然後根據應用程式實際服務的對話來評估該功能。
