PyTorchコミュニティがROCmのコンパイル時数値異常を報告、特定の確率計算が不正確になる可能性

PyTorchコミュニティは9月26日、AMD MI355X上で特定の切断正規分布の計算をコンパイルすると、本来ゼロである区間確率が1として計算されると報告した。事例では PyTorch 2.11.0 と ROCm 7.14.1 を使用している。確認時点で、このissueは未解決で、関連する修正もない。[問題報告](https://github.com/pytorch/pytorch/issues/198734)

関係する `log_ndtr` は、標準正規分布の累積確率の対数を計算する。例ではまず区間の境界を切断点に制限し、その後、本来同じ値になるはずの関数値を2つ引き算する。報告者の分析によると、バックエンドが2箇所の演算に異なる浮動小数点演算の融合を適用したため相殺が崩れ、その後の指数計算が差を増幅した。これは現時点での診断であり、独立した確認を待っている。[関数定義](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)

この種の問題は、モデルが正常に実行できるかどうかとは別の問題だ。公式ドキュメントによると、単精度浮動小数点数の有効数字は約7桁で、加算や乗算の順序を変えるだけでも結果に影響することがある。数学的に等価な計算でも、ビット単位で同じ結果になるとは限らない。実務上重要なのは、誤差がアプリケーションの要件を満たすかどうかだ。特に後続の処理に減算、除算、指数計算が含まれる場合、中間値の相対誤差だけを比べて判断することはできない。[数値精度に関する説明](https://docs.pytorch.org/docs/main/notes/numerical_accuracy.html)

報告された不具合では、失敗する形状がコンパイルの履歴に応じて変化する。`emulate_precision_casts=True` を追加したところ、2回の実行でそれぞれ21種類の形状がすべてテストに通った。ソースコードからは、実行層が浮動小数点演算の融合を制御するオプションを 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)