GitHub Repo
PyTorch 提出 DTensor 數值修補，避免 NaN 清理改變分散式歸約結果
PyTorch 社群於 11 月 7 日提出修補，處理 DTensor 在最大值與最小值歸約完成前執行 nan_to_num，導致結果悄悄改變的問題。作者回報局部回歸測試通過，但提案尚未合併，多程序與 GPU 驗證仍待確認。
PyTorch 社群於 11 月 7 日提交 PR #203933，修正分散式張量 DTensor 的運算配置規則：nan_to_num 被列為可保留待歸約最大值、最小值配置的運算，然而遇到 NaN 或自訂無限大替代值時，這項最佳化可能改變答案。截至查核時，提案仍開放，尚未合併。修補提案
DTensor 透過配置描述資料如何分布；其中 Partial 表示各程序持有尚待歸約的局部值，Replicate 則表示各程序持有完整副本。官方文件說明，從前者轉為後者會執行 all_reduce，因此保留配置的規則也決定通訊與運算的先後順序。DTensor 文件
問題可用兩個程序分別持有 NaN 與 5 說明。依回報中的一般張量語義，先取最大值得到 NaN，再以 nan_to_num 清理，答案是 0；若先在各程序把 NaN 換成 0，再取最大值，答案卻是 5。自訂 posinf、neginf 替代值也可能破壞順序等價性。這是運算語義差異，並非浮點容許誤差。問題與重現程式
修補移除三個 nan_to_num 多載的相關保留規則，讓系統先轉成 Replicate()、完成歸約，再替換特殊數值。作者表示，在 CPU 的 LocalTensorMode、torch 2.14.1 環境重現四種案例，修改後均與預期一致，相鄰逐元素測試也通過；但這仍是作者回報，頁面顯示相關 CI 尚待核准啟動。驗證紀錄
對工程團隊而言，值得檢查的是分片張量經最大值或最小值歸約後，是否立即清理 NaN、Inf。可用含特殊值的輸入，比對分散式與一般張量結果；依文件與修補機制推論，提前完成歸約也可能改變通訊時點，效能須另行量測。後續應追蹤維護者審查、真實多程序測試及正式版本收錄情況，目前證據不足以推定一般訓練流程皆受影響。