vLLM 社群追查 H20 MoE 調度低效，提出按專家負載選擇核心的修補

9 月 25 日，vLLM 社群提交 H20 推論效能回報，指出 FlashInfer 的 SM90 FP8 混合專家模型（MoE）路徑，可能因負載估算不當而選到低效的矩陣運算核心。作者已向 FlashInfer 提出修補；截至 9 月 27 日查核時仍未合併，也未證實是特定 vLLM 正式版引入的退化。[社群回報](https://github.com/vllm-project/vllm/issues/58799)

FlashInfer 的 `cutlass_fused_moe` 以 CUTLASS 執行融合專家運算，API 已支援專家平行的規模與程序編號，以及 FP8 區塊縮放。此次問題落在這條既有執行路徑，對使用多卡部署稀疏模型的團隊尤其相關。[官方 API 文件](https://docs.flashinfer.ai/generated/flashinfer.fused_moe.cutlass_fused_moe.html)

依回報，調度器原先把輸入 token 數當成工作量估計，但核心分支與矩陣分塊選擇需要的是每個專家的資料列數。測試設定有 288 個 token、每個 token 選六個專家，分攤至 400 個實體專家槽位後，平均僅 4.32 列。修補將估計改成「token 數乘以 top-k，再除以實體專家總數」，向上取整且至少為一，並在最壞情況的工作區容量計算完成後套用。[修補提案](https://github.com/flashinfer-ai/flashinfer/pull/5560)

這個案例顯示，總批次大小不足以描述專家實際處理的矩陣形狀。平均值也無法完整反映路由傾斜：少數專家接收大部分資料、其他程序沒有工作時，最佳核心選擇可能不同。因此，均勻分配與負載集中的測試結果，應分開解讀。

作者在八張 H20 上，以均勻路由測得 288-token 的局部 MoE 延遲由 1.808 毫秒降至 0.564 毫秒，約加速 3.21 倍。測試包含五次暖機與 24 次取樣，但計時未納入跨卡通訊，GPU 時脈亦未鎖定；這些數字不能直接換算成線上服務吞吐量。作者另附不依賴模型權重的合成重現腳本，供其他開發者檢查算子行為。[測試方法與結果](https://github.com/vllm-project/vllm/issues/58799)

驗證仍有缺口：基準是控制變因的原始碼回移版本，完整上游建置與原樣執行測試尚待完成；另有一組獨立參考比對在基準與修補版都失敗，原因未明。路由高度集中時，單一矩陣階段還曾變慢約 7.6%。工程團隊應追蹤上游審查，並在固定模型、量化方式與併發條件下，比較端到端延遲及輸出正確性；目前證據尚不足以推廣至其他 GPU 或專家平行規模。[驗證限制](https://github.com/flashinfer-ai/flashinfer/pull/5560)