Transformers 提出張量平行修補，避免梯度掛鉤拖慢編譯推論

Hugging Face Transformers 的張量平行實作出現新的效能修補提案。專案成員於 10 月 26 日提交 PR #49975，針對 ReplicatedWithGradAllReduce 調整梯度同步掛鉤的註冊時機，避免不需要梯度的推論仍攜帶會干擾 torch.compile 的模組級反向掛鉤。截至查核時，頁面顯示提案已進入合併佇列，尚未合併。修補提案

原始問題於 10 月 23 日回報，附有兩個 CPU 程序執行的小型隨機 Qwen3 重現案例：啟用 tp_plan="auto" 後，Dynamo 記錄到 11 次計算圖中斷，移除反向掛鉤後降為零。回報者另稱，在 AWS Trainium 上將 Qwen3-8B 分散至兩個 Neuron 核心時，保留掛鉤的解碼時間為每 token 140 毫秒，移除後為 37.6 毫秒。這是特定環境的回報數據，不能直接推廣至其他硬體或模型。問題與重現程式

這個掛鉤原本有訓練用途。官方文件說明，相關策略會複製參數並對梯度執行 all-reduce，適用於位在不同切分層之間、各程序只能看到部分注意力頭的正規化運算。問題在於，即使使用 torch.no_grad()，模組上已註冊的反向掛鉤仍可能讓編譯器中斷計算圖；因此，關閉梯度計算本身未必足以消除額外成本。張量平行文件

提案改在前向執行時檢查 torch.is_grad_enabled()，需要梯度才替實際載入的參數安裝梯度累積後掛鉤。延後註冊也避開權重載入時替換佔位參數、連帶丟失掛鉤的問題。作者另指出，這可處理舊掛鉤執行時參數梯度尚未產生、因而略過同步的潛在情況。實作說明

對部署團隊而言，這項變動提示了可檢查的效能瓶頸：張量平行與編譯同時啟用時，應觀察計算圖中斷原因，而非只比較裝置數量。後續應追蹤合併與發版狀態，並在實際模型上驗證解碼延遲及訓練梯度同步；目前公開提案提供測試腳本，但尚無可據以宣稱普遍加速幅度的完整結果。