vLLM 社群回報多機解碼延遲，空 KV 連接器也可能觸發效能下降

9 月 27 日，vLLM 社群提出多機解碼效能回報：0.30.0 使用 Model Runner V2 與非同步排程時，加入不做讀寫的 KV 快取連接器，也會增加延遲。測試使用雙節點、共 16 張 H100 80GB，執行 GLM-5.2 FP8，配置八路流水線平行與兩路張量平行。輸入約 1.2 萬 token、固定生成 1,024 token；八個請求同時執行時，每 token 延遲從 32.1 毫秒升至 60.0 毫秒。[社群回報](https://github.com/vllm-project/vllm/issues/58920)

官方程式碼可核對到關鍵差異：多程序執行器收到輸出聚合器時，會將 `output_rank` 設為 `None`，並收集所有工作程序的回覆。原本只需指定程序回傳結果的路徑，因而變成逐一讀取多個回覆佇列；即使訊息很小，回覆數量仍可能形成額外負擔。[0.30.0 執行器文件](https://docs.vllm.ai/en/v0.30.0/api/vllm/v1/executor/multiproc_executor/)

共享記憶體佇列的寫入端，在區塊尚未被讀完時會反覆檢查並呼叫 `sched_yield`。回報者將瓶頸歸因於等待期間的 Python 全域直譯器鎖競爭，妨礙主執行緒準備輸入；其診斷修改改用釋放鎖的等待方式後，額外延遲降至約 13%。這仍是作者的定位與測量結果。[佇列原始碼](https://github.com/vllm-project/vllm/blob/v0.30.0/vllm/distributed/device_communicators/shm_broadcast.py)、[診斷實驗](https://github.com/vllm-project/vllm/issues/58920)

這類瓶頸直接牽涉 V2 的設計目標。官方文件說明，非同步排程讓 CPU 準備下一步輸入，與 GPU 執行當前步驟重疊，並要求 CPU 操作維持非阻塞。據此推論，若回覆執行緒妨礙輸入準備，即使 GPU 運算核心沒有變慢，整體解碼節奏仍會受限。[V2 設計文件](https://docs.vllm.ai/en/latest/design/model_runner_v2/)

KV 連接器也是預填充與解碼分離架構的重要介面。官方文件將分離部署定位為分別調整首 token 時間與後續 token 延遲的方法，並提醒這項功能不會提高吞吐量。因此評估部署時，快取傳輸收益與控制路徑成本都應量測，不能僅從網路頻寬推估效果。[分離部署文件](https://docs.vllm.ai/en/latest/features/disagg_prefill/)

工程團隊可把未配置連接器、空連接器與實際連接器列為對照組，固定模型、平行拓撲與負載，同步觀察 token 間隔及 CPU 執行緒。現有證據限於單一部署，不能外推至所有硬體；截至查核，議題仍開啟，未見維護者確認或關聯修補。後續應追蹤回覆聚合、佇列容量與等待策略的上游變更。[議題狀態](https://github.com/vllm-project/vllm/issues/58920)