vLLM 社群回報 AMD 預填充競態，非同步排程可能觸發 GPU 記憶體錯誤

9 月 27 日，vLLM 社群提交 AMD 推論後端的競態回報：同時使用 AITER MLA、FP8 KV 快取與非同步排程時，預填充可能觸發 GPU 記憶體錯誤。案例來自八張 MI355X 的開發版環境，並提供單卡獨立重現程式；正式版受影響範圍尚待確認。[問題回報](https://github.com/vllm-project/vllm/issues/58886)

回報者將原因指向跨批次共用的排程中繼資料。主機為下一批請求重寫緩衝區時，前一批 GPU 核心可能仍在排隊，因而讀到另一批的工作分配表。原有複製操作未納入目前執行串流的順序，事後同步也來不及阻止覆寫。[修補提案](https://github.com/vllm-project/vllm/pull/58887)

這涉及推論效能優化的基本取捨。vLLM 文件說明，非同步排程可減少 GPU 閒置間隙、改善延遲與吞吐量；AMD 文件則指出，非同步傳輸能與運算重疊，需利用串流及事件協調執行順序。依此機制，共用緩衝區的生命週期也是服務正確性的一環。[vLLM 設定文件](https://docs.vllm.ai/en/latest/configuration/engine_args/)、[AMD 非同步執行文件](https://rocmdocs.amd.com/projects/HIP/en/latest/how-to/hip_runtime_api/asynchronous.html)

修補提案改用兩組鎖頁主機暫存區產生排程資料，再沿目前串流複製到 GPU，並等待複製完成事件後才重用暫存區。作者測試中，一組原於第 111 筆請求出錯的負載，套用後完成全部 1,024 筆；相關崩潰測試使用替代權重，不能據此判定模型回答品質。[修補與測試結果](https://github.com/vllm-project/vllm/pull/58887)

作者也在 DeepSeek-V3 重現相同故障。ROCm 7.2 的預設服務測試雖未崩潰，獨立案例與調整佇列設定後仍可觸發，因此不能把降版視為根治。這些結果目前來自提交者，尚缺獨立驗證；靜默數值錯誤對準確率的影響也未被充分量化。[重現細節與限制](https://github.com/vllm-project/vllm/issues/58886)

截至查核，修補仍未合併。關閉非同步排程已在作者案例避開故障，符合條件的部署可先於測試環境比對，但效能代價須自行量測。[提案狀態](https://github.com/vllm-project/vllm/pull/58887) 工程端應保存映像標籤、後端選擇與快取精度，讓故障能和特定配置對照。驗證時應涵蓋新請求加入既有解碼批次的情境，觀察完成率與錯誤日誌，再比較吞吐量。後續應追蹤維護者審查、修補納入版本，以及真實權重下長輸入與多種併發負載的回歸結果。