PyTorch 社群回報 ROCm 編譯數值異常，特定機率計算可能失真

PyTorch 社群於 9 月 26 日回報，AMD MI355X 上的特定截斷常態分布計算，經編譯後會把應為零的區間機率算成一。案例使用 PyTorch 2.11.0 與 ROCm 7.14.1；截至查核時，議題仍待處理，尚無關聯修補。[問題回報](https://github.com/pytorch/pytorch/issues/198734)

涉及的 `log_ndtr` 計算標準常態累積機率的對數。範例先把區間邊界限制在截斷點，再相減兩個理應相同的函式值。回報者分析，後端對兩處運算採用不同的浮點融合方式，使抵消失效，之後的指數運算放大差異。這是目前的診斷，仍待獨立確認。[函式定義](https://docs.pytorch.org/docs/2.14/special.html#torch.special.log_ndtr)、[重現與分析](https://github.com/pytorch/pytorch/issues/198734)

從執行架構看，`torch.compile` 會擷取運算圖，預設交由 TorchInductor 產生加速器程式，GPU 路徑以 Triton 為重要基礎。因此，驗證範圍必須涵蓋實際產生的核心與編譯設定；原始公式正確、未編譯模式通過，都不足以證明部署路徑正確。這也說明為何回歸測試需要保留硬體與軟體版本資訊。[編譯器架構](https://docs.pytorch.org/docs/stable/torch.compiler.html)

這類問題與模型是否能成功執行是兩件事。官方文件說明，單精度約有七位十進位有效數字，加乘順序改變便可能影響結果；數學等價的計算，也不保證逐位一致。工程上的關鍵是誤差能否通過應用要求，尤其當後續步驟包含相減、除法或指數時，不能只比較中間值的相對差距。[數值精度說明](https://docs.pytorch.org/docs/main/notes/numerical_accuracy.html)

回報中的失敗形狀會隨編譯歷程改變；加入 `emulate_precision_casts=True` 後，兩輪各二十一種形狀均通過。原始碼也可確認，執行層會將浮點融合控制選項傳給 Triton；但關閉最佳化的效能代價仍須實測。[測試結果](https://github.com/pytorch/pytorch/issues/198734)、[編譯選項傳遞](https://github.com/pytorch/pytorch/blob/v2.11.0/torch/_inductor/runtime/triton_heuristics.py)

對維護機率模型的團隊，本文建議把邊界值、極小變異數及不同形狀的連續編譯納入回歸測試，並與未編譯執行結果對照；也應檢查機率範圍及總和，避免平均誤差掩蓋局部失效。後續要追蹤維護者能否在新版重現、修正落在哪個編譯層，以及暫時解法是否影響吞吐量。這份分析標註由 AI 生成並經回報者審閱，未測 CUDA 或其他 AMD 架構，尚不能推廣為全面性缺陷。[回報範圍與限制](https://github.com/pytorch/pytorch/issues/198734)