GitHub Repo
vLLM 社群提出 MoE LoRA 後端修補，Blackwell 上指定 Triton 仍可能啟動失敗
10 月 12 至 13 日的 vLLM 社群回報指出，MoE LoRA 後端選擇可能忽略明確設定，並在全分片模式下觸發啟動錯誤。修補提案已加入設定檢查與單元測試，但尚未合併，也缺少完整 GPU 驗證。
vLLM 社群於 10 月 12 日回報一項未量化 MoE LoRA 的後端選擇缺陷：在符合特定條件的 Blackwell GPU 上，即使指定 --moe-backend triton，系統仍可能選用 FlashInfer 的 TRT-LLM 路徑。若同時啟用 --fully-sharded-loras，服務會在啟動分析階段觸發斷言。回報環境為 v0.31.0、SM103 GPU、CUDA 13 與 BF16 的 Qwen3.5-35B-A3B，作者亦指出開發分支存在相同邏輯。問題回報
回報將原因指向後端選擇函式：LoRA 分支先檢查 TRT-LLM 支援條件，卻未先處理使用者指定的後端。被選中的實作又以 add_inputs=False 呼叫 LoRA 運算，而下層核心不支援此參數與全分片模式並用。因此，單純追加 Triton 選項無法避開錯誤；作者表示，局部修改選擇條件後，同一命令才可啟動並提供服務。重現與程式路徑
這項缺口牽涉部署設定是否確實生效。官方文件將 --moe-backend 定義為 MoE 專家運算核心的選擇介面；全分片 LoRA 則讓完整 LoRA 計算沿張量平行配置分片，文件指出長序列、高秩或較大平行規模可能受益。對工程團隊而言，依此推論，調整效能參數時還須核對啟動日誌中的實際後端。引擎參數文件
10 月 13 日提出的 PR #61301 擬尊重明確指定的 Triton，並把全分片設定傳入 MoE 相容性檢查：自動選擇時可退回 Triton，明確要求不相容的 TRT-LLM 組合則提前拋出設定錯誤。作者列出三項通過的單元測試，但測試紀錄同時顯示兩項因 CPU 主機的 CUDA／ROCm 標記而跳過，不能視為完整 GPU 驗證。修補提案
截至查核，提案仍開放，且被標記需處理合併衝突。後續應追蹤維護者審查、Blackwell 實機測試及正式版本納入情況；目前證據不足以推定所有 MoE LoRA 部署都會失敗。提案狀態