vLLM 被回報外部 KV 快取讀取失敗會終止引擎，影響範圍仍待確認

vLLM 社群於 9 月 21 日收到一項外部 KV 快取故障回報：使用 LMCacheMPConnector 執行混合注意力模型時，快取讀取失敗後，引擎程序也因斷言錯誤終止。回報附有環境、觸發步驟與錯誤日誌，目前仍開啟，尚未連結修補提案或公開的維護者確認。[問題回報](https://github.com/vllm-project/vllm/issues/57938)

案例使用 AMD MI325X 與 Gemma 4 31B 的 FP8 權重，模型混合滑動視窗及全域注意力，配置含六組 KV 快取。重現條件是透過 GDS／hipFile 後端讀取，並觸發儲存錯誤。雖然文字摘要寫作 0.29.1，環境輸出的版本實際是開發建置 `0.29.1rc1.dev47+gdc36fcce9`，不能據此判定正式版全面受影響。[環境與日誌](https://github.com/vllm-project/vllm/issues/57938)

關鍵在失敗範圍。案例設定 `kv_load_failure_policy=fail`；官方定義是讓受影響請求以錯誤結束，另一選項 `recompute` 才是重新排程計算失效區塊。回報者希望重新計算，但目前證據最直接指出的異常，是請求失敗擴大為引擎終止。僅把設定改成重新計算，還不能視為已驗證的解法。[失敗策略文件](https://docs.vllm.ai/en/latest/api/vllm/config/kv_transfer/)

日誌顯示，排程器先記錄一筆請求失敗，隨後在更新快取傳輸完成狀態時，檢查請求是否仍存在的斷言失敗。現行文件所列程式也保留該檢查；但這只能指出調查位置，無法證明是何處先移除請求，或哪個元件應負責修正。[排程器程式](https://docs.vllm.ai/en/latest/api/vllm/v1/core/sched/scheduler/)

這類故障值得部署者關注，因為 LMCache 多程序架構把快取獨立成服務，同一節點可供多個推論實例共用，並獨立配置快取資源。從此架構可推知，程序隔離之外，推論端仍須正確消化遠端錯誤，才能限制服務中斷範圍。[架構文件](https://docs.lmcache.ai/mp/index.html)

下一步應在隔離測試環境注入讀取失敗，確認其他請求能否持續服務，並追查取消請求與傳輸完成事件的先後順序。現有材料沒有故障發生率、跨硬體重現或正式修補結果；工程團隊應固定實際提交版本，等待最小重現測試與維護者界定影響範圍。驗收也應分別記錄單筆請求錯誤、程序重啟與其他請求延遲，避免只看健康檢查恢復，就認定故障已被隔離。