大きすぎる計算は、
黙ってまちがえる。

43 億個を超えると、数え方が一周して 0 に戻る

車の距離計が 99999 の次に 00000 に戻るのと同じ。壁(2³² 要素)の先のデータは、先頭のデータから計算した値になる。

対象は torch.bmm(バッチ行列積)。matmul と、Transformer の標準的な(eager)attention もこれを通る。PyTorch 2.4.1〜2.14.0 の 11 版すべてで起きる。誤差は 100% を超える大きさで、丸め誤差ではない。

3 つの規則で、全部の結果を説明できる

乱数入力の 1376 件すべてが、この 3 つの規則どおりだった。

こわいのは「少し大きくしただけ」で変わること

入力も出力も同時に壁を超える場合、壁の 2 倍(約 86 億要素)の近く、の両方でも同じ規則のまま。大きなメモリの奥に置いた小さなデータ(104 件)は全部正しかった。

答えは合っているのに、学習の材料だけ壊れる

推論は正しく見えるので気づけない。でもそのモデルは、まちがった勾配で学習している。エラーも NaN も出ない。

backward の走査 604 件。新しい規則は不要で、同じ 3 つの規則を勾配の計算(2 つの行列積)に当てはめると 592 件すべて一致。

機械を変えても、OS を変えても、最後の 1 桁まで同じ

チップだけ違う組と、OS だけ違う組の両方があるので、どちらの要因でもないと言える。正解の基準は常に CPU の倍精度(float64)。A100 の対照は現在、最新のコードで測り直し中(backward と拡張系列も追加)で、この段落の数字は更新予定。

感情分類モデルで、3 分の 1 の答えが壊れた

公開モデル(RoBERTa、3 クラス)に 2048 件を 1 回で流すと、壊れた分はほぼ 1 つのクラスに偏る。全体の正解率は 7 ポイントしか下がらないので、集計値だけ見ていると気づかない。

どの文が壊れるかは、内容ではなくバッチの中の位置で決まる。256 件ずつに分けて流せば全部正しい。

ルールは 1 つ:2³² 個以上のテンソルを GPU に作らない・読ませない

差し込むだけの見張り役(guard)を公開している。「黙ってまちがう」を「エラーで止まる」に変える。大きなバッチは GPU に載せる前に分割する。

backward の失敗も防げる(出力が先に止まるため)。代償として、正しく動く大きな実行の一部も止める(630 / 4095 件)。

外から測った記録であって、原因の解析ではない

• 中身(実装)は見ていない。入力と出力だけから判断した(black-box)。
• 測ったのは M2 世代の 2 台、macOS 26.6.2 と 27.0。macOS 14・15 は未測定(次の版で追加予定)。
• 系統的に測ったのは bmm だけ。ほかの演算は 26 件の簡易テストで「失敗がある」ことまで。
• 実モデルの例は 1 つ。ほかのモデルでは壊れ方が違うかもしれない。
• CUDA も万能ではない:torch.arange は CUDA でも 2³² の先が黙って 0 になる(報告済み、修正の提案あり)。

テンソル

数字をぎっしり並べた箱。要素の数 = 箱の中の数字の個数。

MPS

PyTorch が Apple の GPU を使うためのしくみ。

bmm

たくさんの行列のかけ算をまとめて行う命令。attention の中心。

転置(view)

データを並べ替えずに「縦横を入れ替えて読む」指定。これを無視されると全部ずれる。

静かな失敗

エラーも警告もなく、まちがった値が返ること。いちばん見つけにくい。

勾配

学習でモデルを直す方向を決める数値。壊れると学習が壊れる。

公開先:github.com/jniimi/mps-silent-failures(コード、測定の生データ、guard)。PyTorch への報告:Issue #197636。