PyTorch 關閉 Triton 解碼效能退化議題，3.9 分支回退修補恢復特定注意力核心速度

PyTorch 的 Triton 解碼效能退化追蹤在 10 月 26 日完成收尾：維護者確認大量警告訊息也已解決，將議題關閉。這是先前編譯器回退修補與驗證的後續進展，並非當天才發現的新缺陷；對準備升級推論環境的團隊而言，重點是確認實際安裝的建置內容。議題紀錄

問題最初由 SGLang 工作負載浮現，回報者另提供不需模型權重的獨立重現程式。Triton 修補說明指出，遮罩非同步複製的 predicate 運算元變更，與另一項全域載入變更交互作用，影響後端指令排程；GB200 上指定 GQA 解碼核心的延遲由約 10.9 微秒升至 17.4 微秒。暫存器、溢出與數值結果相同，顯示僅看資源占用不足以解釋退化。修補分析

處理方式是在 Triton 的 release/3.9.x 回退相關變更，修補已於 10 月 20 日合併。代價是放棄原變更在另一個管線化複製教學案例中的效益，反映編譯器最佳化可能因核心形狀與排程而產生不同結果。Triton 官方的注意力教學也提供可執行核心及不同精度、形狀的量測，適合作為理解這類效能差異的背景。合併紀錄、官方教學

後續 GB300 對照中，指定案例由較早建置的 16.86 微秒回到 10.72 微秒；另有參與者確認原先提及的 SGLang 工作負載在 GB200、GB300 恢復效能。不過，公開詳細數據主要仍是合成核心，不能換算成完整服務的吞吐提升。維護者還曾因環境保留同為 3.9.0 的舊 wheel 而測不到修補。工程師接下來應核對套件來源與建置，並以實際 KV 配置、批次及端到端延遲重測。驗證與限制