PyTorch計算中のCUDAエラーを理解する

最初の失敗とそのコンテキストを保持する

このガイドは、起動が成功した後から始まります。PyTorchがデバイスを認識し、その後アプリケーションがバッチまたは演算子で失敗する状況です。小さな計算も一切動作しない場合は、初期診断からやり直してください。そうでなければ、最初のエラー、イテレーション番号、最後に完了したステップを保持します。最初の失敗後に続く一連のメッセージは、複数の独立した原因ではなく、その結果を表している可能性があります。

コードのリビジョン、Python と PyTorch のバージョン、バックエンド、数値型、入力の形状を記録してください。データについては、内容全体のコピーよりも内部識別子と次元を優先してください。問題のあるバッチを特徴づけるもの――長さ、存在しないターゲット、最後の不完全なバッチ、めったに使われない拡張や分岐――を探してください。この記録があれば、キャンペーン全体を再実行せずにそのケースを再現できます。

非同期性にもかかわらず問題のある起動を特定する

CUDA では、操作はキューに入れられ、Python 関数の戻り値の後で完了することがあります。そのため、CPU へのコピー中やスカラーの読み取り中に報告されるエラーは、先行する計算に由来する可能性があります。PyTorch のドキュメントはこの非同期実行について説明しています。トレースが示す行は調査すべき観測点であり、必ずしも原因ではありません。

NVIDIA/CUDA での短い再現には、CUDA_LAUNCH_BLOCKING=1 を付けた個別の起動を提案してください。このオプションは呼び出しを同期させ、エラーをその発生源に近づけることができます。これは診断用であり、計測用ではありません。また、大きなステップの間に一時的に同期を入れて、疑わしい範囲を狭めることもできます。その後、この計装は削除してください。通常のスケジューリングが変わってしまうからです。

次のコマンドは教育用であり、実行されていません。POSIX ターミナルと既存の train.py スクリプトを前提としています。この代入はこの起動にのみ適用されます。構文はご使用のシェルに合わせて調整してください。この NVIDIA の変数を ROCm スタックに一般化しないでください。

提案された診断用起動、未実行

CUDA_LAUNCH_BLOCKING=1 python train.py

エラー系統を早合点せずに読む

メッセージは調査範囲を狭めるが、再現可能なケースの代わりにはならない。ドメイン外のインデックス、誤ったデバイス上のテンソル、不可能な割り当ては、それぞれ異なる確認を要する。無効なデータ、演算子の契約、バイナリ環境の区別を保つこと。バッチ、精度、ライブラリを同時に変更すると、この区別が失われる。

デバイス上で実行されたアサーションの後は、同じプロセスで同じトレーニングを続行しようとしないこと。NVIDIAは、cudaErrorAssertが既存の割り当てを無効化し、プロセスを終了して再起動する必要があると示している。ノートブックでは、修正した再現の前にカーネルを再起動することを意味する。ただし、再起動しても誤ったターゲットや無効なインデックスは修正されない。

表をスクロールしてすべての列を表示してください。

診断の手がかり。メッセージと原因を自動的に対応付けるものではない
観測された手がかり	最初の確認	避けるべき結論
device-side assert	演算子のインデックス、ターゲット、条件	GPUが必ず故障している
Out of memory	形状、テンソルのライフタイム、プロセスのメモリ	CUDAのエラーはすべてVRAM不足が原因
演算子またはカーネルが利用不可	バージョン、拡張機能、バックエンド、dtype	すべてを無作為に再インストールする
異なる周辺デバイス	モデルと各入力の配置	出所を理解せずにコピーを追加する

NVIDIA：ランタイムエラーと cudaErrorAssert

実例: 4クラス問題におけるクラス4

出力が4つの列を持つ教育用の分類器を考えます。そのクラスは0から3までインデックス付けされています。値4を含むアノテーションファイルは、1から4のエンコーディングや、予期しない5番目のクラスを明らかにする可能性があります。単に出力サイズを増やすと、アノテーションの意味を解決することなく制約が消えてしまいます。

以下に示すチェックは、CPU へのターゲット転送前に適用されます。これは実行されていません。long 型のクラスインデックスに対する CrossEntropyLoss の契約を、ignore_index=-100 を明示的に選択して示したものです。確率分布からなるターゲットは対象外です。このシナリオでは [0, 2, 4] は拒否されるべきです。この期待される結果はルールから導かれたものであり、測定値として提示されたものではありません。

次に、データ準備におけるマッピングを修正し、クラス名との全単射を確認してください。すべてのソースが同じ規則を使用しているかどうかが分かるまで、至る所で1を引かないでください。問題のあるケースを、プロジェクトと一緒に保持する小さな検証用セットに追加してください。

クラスインデックスのための教育的なCPUガード

import torch

classes = 4
ignore_index = -100
target = torch.tensor([0, 2, 4], dtype=torch.long)
if target.ndim != 1 or target.dtype != torch.long:
    raise ValueError("Cibles : vecteur d’indices attendu")
valid = target[target != ignore_index]
if valid.numel() == 0:
    raise ValueError("Aucune cible exploitable dans ce batch")
if bool(((valid < 0) | (valid >= classes)).any()):
    raise ValueError("Indice de classe hors domaine")

PyTorch：ターゲットの形状・型・値域

トリガーを消さずにプログラムを縮小する

まず、同じ変換で単一の入力または単一のバッチだけを再実行してください。リモートのトラッキング、結果の書き込み、失敗と無関係な分岐を外します。dtype、形状、疑わしい演算子は維持してください。エラーが特定の長さやメモリ配置に依存している場合、任意の小さなテンソルでは再現しなくなるおそれがあります。

変更は一度に 1 つずつ比較します。任意拡張を無効化、参照実装の演算子、通常の精度、CPU 上に同等の演算があれば同じ演算の CPU 実行などです。CPU での成功は手がかりであり、CUDA での検証ではありません。カスタム関数の場合は、strides、連続性、サイズに関する前提も記録します。修正前に失敗し修正後に成功する例を見つけ、例外が出ないことだけでなく出力を検証します。

精度変更の切り分け

当初の範囲での正当性を検証する

受け入れ可能な修正は、最小ケース、隣接ケース、元の処理経路の代表的な部分を通過する必要があります。具体的には、最後のバッチ、短い入力、長い入力、マッピングの境界値を再度確認します。拒否された要素が識別可能であり、処理された入力数が想定どおりであることを確認します。例外を黙って無視すると、目に見えるクラッシュが不完全な結果に変わり得ます。

診断モードを外し、新しいプロセスから再開し、通常の構成で挙動を確認します。原因、適用した変更、非回帰のチェックを残します。学習を中断していた場合は、エラー前に検証済みの整合性あるチェックポイントから再開します。障害中に書き込まれたファイルがあるだけでは、その再開を保証するには不十分です。

新しいプロセスでの再開を検証する

より的を絞った分析を依頼すべきタイミングを知る

同じ最小ケースが有効な入力でも失敗する場合は、演算、形状、型、バックエンド、バージョン、最初の該当メッセージを含む具体的な依頼を用意します。個人識別情報や不要なパスは取り除きます。バイナリ拡張は独自の互換性マトリクスを必要とする場合があり、PyTorch の一般的なサポートがその拡張を自動的に検証するわけではありません。

ROCm では、PyTorch は torch.cuda インターフェースと cuda というデバイス名を維持します。NVIDIA の手順を適用する前に、torch.version.hip でこのスタックを識別してください。メッセージ、ツール、診断オプションは異なる場合があります。ここで説明するどの確認も、準備された環境が Kernodeck の提供内容と互換であることを証明するものではありません。GPU を選ぶ前に、これらの基準を使ってニーズを明確にしてください。

CUDAエラーが発生：どの操作を調べるべきか？