このガイドでは、GPU が接続された Compute Engine VM の一般的な問題（ハードウェア エラーやパフォーマンスのボトルネックなど）を診断して解決する方法について説明します。
NVIDIA DCGM を使用して GPU VM のトラブルシューティングを行う
NVIDIA Data Center GPU Manager（DCGM）は、クラスタ環境内の NVIDIA データセンター GPU の管理とモニタリングを行うためのツールセットです。
DCGM を使用して GPU 環境のトラブルシューティングを行う場合は、次の操作を行います。
- VM に接続されている GPU モデルに推奨される最新の NVIDIA ドライバを使用していることを確認します。ドライバのバージョンを確認するには、推奨される NVIDIA ドライバのバージョンをご覧ください。
- DCGM の最新バージョンがインストールされていることを確認します。最新バージョンをインストールするには、DCGM のインストールをご覧ください。
問題の診断
dcgmi 診断コマンドを実行すると、診断ツールから報告された問題とその対処方法を確認できます。次の例は、dcgmi diag -r memory -j コマンドの出力を示しています。
{
........
"category":"Hardware",
"tests":[
{
"name":"GPU Memory",
"results":[
{
"gpu_id":"0",
"info":"GPU 0 Allocated 23376170169
bytes (98.3%)",
"status":"Fail",
""warnings":[
{
"warning":"Pending page
retirements together with a DBE were detected on GPU 0. Drain the GPU and reset it or reboot the node to resolve this issue.",
"error_id":83,
"error_category":10,
"error_severity":6
}
]
}
.........
この出力スニペットを見ると、回復不能なエラーのため、GPU 0 でページ リタイアメントが保留されていることがわかります。出力には、一意の error_id と問題のデバッグに関するアドバイスが表示されます。この出力例では、GPU をドレインして VM を再起動することをおすすめします。ほとんどの場合、出力のこのセクションの手順で問題を解決できます。
A3 VM の GPU パフォーマンスに関する問題のトラブルシューティング
A3 マシンシリーズは、NVIDIA H200 または H100 GPU がアタッチされた状態で利用できます。このシリーズには、A3 Ultra（H200）、A3 Mega（H100）、A3 High（H100）、A3 Edge（H100）マシンタイプが含まれます。
障害のあるノードを特定する
マルチノード GPU クラスタでの大規模なトレーニング ジョブやベンチマーク ジョブが応答を停止したり、パフォーマンスが低下したりすることがあります。これは、1 つ以上のノードのパフォーマンスが低下し、オペレーション全体が遅くなることが原因で発生します。このセクションでは、NCCL ベンチマーク テストを実行するか、NCCL ログを分析して、障害のあるノードまたはホストマシンを特定する方法について説明します。
NCCL ベンチマーク テストを実行する
障害の原因となっているノードのグループを特定するには、all_reduce_perf などの NCCL ベンチマークを使用して、クラスタのサブセットを体系的にテストします。
- ノードセットを識別するには、ノードを論理セット（Slurm のパーティションなど）にグループ化します。
- ホストファイルを作成するには、ノードセットごとに個別のホストファイルを作成し、ホスト名とノードあたりの GPU 数を一覧表示します。指定するスロットの数は、A3 VM タイプの GPU 数によって異なります。たとえば、
a3-highgpu-8gVM には 8 個の GPU があるため、slots=8を指定する必要があります。 - ベンチマークを実行するには、各ノードセットに対して
all_reduce_perfベンチマークを個別に実行します。mpirun -x LD_LIBRARY_PATH --hostfile HOSTFILE_NAME -n TOTAL_PROCESSES \ ./build/all_reduce_perf -b 1G -e 8G -f 2 -g NUM_GPUS_PER_NODE次のように置き換えます。
HOSTFILE_NAME: ノードセットのノードのリストとノードあたりの GPU 数を含むホストファイルの名前。TOTAL_PROCESSES: ノードセット内のすべてのホストで起動する MPI プロセスの合計数。NUM_GPUS_PER_NODE: ノードあたりの GPU の数。すべての A3 マシンタイプの場合、この値は8です。
- 結果を分析するには、ジョブがハングするか、特定のノードセットでバス帯域幅（
busbw）が大幅に低下している場合、そのセットに障害がある可能性があります。 - さらに細分化するには、ノードセットに障害がある場合は、ホストファイルを半分に分割して再テストし、個々の不正なノードを特定するまでバイナリ検索を絞り込みます。
NCCL ログを分析する
ベンチマーク メソッドでノードを特定できない場合は、詳細な NCCL ログを分析します。
- デバッグ ロギングを有効にするには、ワークロードを実行するシェル セッションで次の環境変数を設定します。
export NCCL_DEBUG=INFO export NCCL_DEBUG_SUBSYS=INIT,NET,COLL export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"LOG_DIRECTORYは、ログを保存するディレクトリに置き換えます。%hと%pを使用してNCCL_DEBUG_FILEを設定すると、プロセスごとに一意の、インターリーブされていないログファイルが作成されます。mpirunを使用してマルチノード ワークロードを実行する場合は、-xフラグを使用して、これらの変数をすべてのノードに伝播します。次に例を示します。mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ... - 最初のエラーを見つけるには、次のコマンドを使用して、すべてのログファイルで最も古いタイムアウトまたは障害イベントを見つけます。
grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \ | sort | head -n 20LOG_DIRECTORYは、ログが保存されているディレクトリに置き換えます。 - 集団オペレーションをカウントする場合、ストラグラー ノードは完了する集団オペレーションの数が少なくなります。容疑者のランクの
"opCount"エントリ数をカウントします。grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -l次のように置き換えます。
LOG_DIRECTORY: ログが保存されるディレクトリHOSTNAME: ノードのホスト名PID: NCCL プロセスのプロセス ID
- ジョブが中止される前に、より多くのロギングデータを収集するには、データ転送のタイムアウトを一時的に増やします。
export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
GPU サーマル スロットリングをモニタリングする
A3 シリーズの VM は、負荷がかかった状態で温度が 87 °C を超えると、パフォーマンスが低下する可能性があります。クラスタ内のノード全体で GPU のサーマル スロットリングを確認するには、nvidia-smi または dcgmi を使用します。
nvidia-smi の使用
ノード上のすべての GPU の現在の温度とスロットリング ステータスを確認するには、次のコマンドを実行します。
nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv
出力の clocks_throttle_reasons.hw_slowdown 列の値が Active の場合、温度が高いため GPU がスロットリングされていることを示します。
dcgmi の使用
NVIDIA Data Center GPU Manager（DCGM）診断スイートには、熱違反のチェックが含まれています。レベル 1 の診断を実行するには、次のコマンドを実行します。
dcgmi diag -r 1
Thermal セクションの結果が Warn または Fail の場合、テスト中に熱違反が発生したことを示します。温度違反がクロック スロットリングを伴う場合、GPU が過熱している可能性が高く、さらなる調査が必要です。
Xid エラー
GPU が接続された VM を作成したら、アプリケーションが GPU にアクセスできるように、NVIDIA デバイス ドライバを GPU VM にインストールする必要があります。ただし、これらのドライバがエラー メッセージを返すことがあります。
Xid メッセージは NVIDIA ドライバからのエラーレポートで、Linux VM のオペレーティング システムのカーネルログまたはイベントログに出力されます。これらのメッセージは /var/log/messages ファイルに記録されます。原因の可能性を含む Xid メッセージの詳細については、NVIDIA のドキュメントをご覧ください。
Google による Xid エラーの処理方法
Google は、パッシブ ヘルスチェックを使用して GPU システムを評価します。ハードウェアの交換が示されている場合、Google は自動的に緊急メンテナンスを開始します。Google は Xid エラーを検出し、エラーコードがハードウェア障害の可能性が高いことを示すマシン（Xid 74、79、140 など）を事前に修理に送ります。一部の Xid コードは、ソフトウェアまたはハードウェアの問題が原因で発生する可能性があるため、Google はパターン マッチングを使用して修理をトリガーします。そのため、すべての発生が自動修理につながるわけではありません。
Xid エラーの種類
次のリストに、Xid エラーの 3 つの主なカテゴリと、推奨される復旧アクションを示します。
アプリケーション エラー: アプリケーション コード内の問題を示します。アプリケーション エラーには、Xid 13、31、94、95、137 などの Xid が含まれます。これらは、セグメンテーション違反と同様に、さまざまなタイプのメモリアクセス違反を示します。これらは ECC エラーを示すものではありません。これらのエラーのトラブルシューティングを行うには、次のいずれかのデバッグ方法を使用することをおすすめします。
- 直接デバッグ: cuda-gdb でアプリケーションを直接実行するか、Compute Sanitizer memcheck ツールを実行します。
- 例外後のデバッグ:
CUDA_DEVICE_WAITS_ON_EXCEPTION=1を使用してアプリケーションを実行します。例外が発生すると、GPU ドライバは終了せずにアプリケーションの状態をフリーズするため、後でデバッガ（cuda-gdb -p <PID>）をアタッチしてライブ スタック トレースを検査できます。
ドライバエラー: NVIDIA GPU ドライバが原因で発生した問題を示します。これらのエラーを解決するには、最新の NVIDIA ドライバ バージョンを使用していることを確認してください。Google はこれらのエラーをモニタリングし、ドライバの修正について NVIDIA と連携しています。
ファームウェアまたはハードウェアの回復可能なエラー: ハードウェアの交換なしで回復できるファームウェアまたはハードウェアのエラーを示します。これらのエラーを解決するには、GPU のリセットやインスタンスの再起動などの手動復旧措置を適用します。ファームウェアまたはハードウェアの回復可能なエラーには、ECC エラーの検出と軽減のさまざまな段階を示す誤り訂正符号（ECC）エラー（Xid 48、63、64 などの Xid に適用可能）が含まれます。ページ リタイアメントと ECC エラーの軽減の詳細については、NVIDIA の動的ページ リタイアメントに関するよくある質問をご覧ください。
Xid メッセージを確認する
GPU ワークロードが失敗した、応答を停止した、パフォーマンスが低下した理由を迅速に診断するには、インスタンスのカーネルログ（dmesg または /var/log/kern.log）で数値の NVIDIA Xid エラーコードを確認します。
次のサブセクションの Xid エラーテーブルを確認すると、次のことがすぐにわかります。
- 根本原因を特定する: 障害の原因が、アプリケーションのバグ（不正なメモリアクセスなど）、ドライバの競合、物理ハードウェアの障害（2 ビット ECC メモリエラーなど）のいずれであるかを特定します。
- 運用上のオーナーを決定する: GPU のリセット、VM の再起動、デバッガの実行など、すぐに適用する必要がある手動復旧対策と、Google がホストで積極的に管理している自動修復とハードウェア交換アクションを確認します。
- 適切な復元手順を実施する: 不要なトラブルシューティング手順を避け、手動復元で十分な場合と、ホストに障害があると報告する必要がある場合を正確に把握します。手動復元では不十分な場合があります。たとえば、エラーソースが GPU キャッシュ（SRAM）にあり、再マッピングできない場合（
Xid 48とSRAM Threshold Exceeded=Yesで示されます）、または GPU の再マッピング バンクが使い果たされている場合（Xid 64: All reserved rows for bank are remappedで示されます）です。このような場合、Google は GPU がハードウェア交換の対象であることを検出し、マシンを修理に送ります。ワークロードでエラーが繰り返し発生する場合や、メモリ障害が繰り返し発生する場合は、障害のあるホストを報告して、自動修復または交換を開始できます。GKE の場合は、GKE で障害のあるホストを報告する方法をご覧ください。
Xid の処理
以降のセクションでは、一般的な Xid エラー メッセージを技術カテゴリ別にグループ化し、正式な解決策と責任について説明します。
- GPU メモリエラー（Xid
48、63、64、92、94、95） - GPU システム プロセッサ（GSP）エラー（Xid
119、120） - 不正なメモリアクセス エラー（Xid
13、31、137） - その他の一般的な Xid エラー メッセージ（Xid
74、79、109、149）
GPU メモリエラー
GPU メモリは GPU で利用可能なメモリで、データの一時的な保存に使用できます。GPU メモリは誤り訂正符号（ECC）で保護されています。ECC は、単一ビットエラー（SBE）を検出して訂正し、ダブルビットの訂正不可能なエラー（DBE）を検出して報告します。
これらのメモリエラーは、GPU の寿命全体で発生することが予想されます。NVIDIA A100 GPU のリリース前は Dynamic Page Retirement がサポートされていました。NVIDIA A100 以降の GPU リリース（NVIDIA H100 など）では、HBM（DRAM）エラーに対して行再マッピング エラー回復が導入されています。ECC はデフォルトで有効になっています。ECC を有効にしたままにすることを強くおすすめします。
次の表に、一般的な GPU メモリエラーとその解決策を示します。
| Xid エラー メッセージ | ユーザー アクション | Google のアクション |
|---|---|---|
Xid 48: Double Bit ECC
ECC によってダブルビット（修正不可能）メモリエラーが検出されました。このエラーは、実行中のワークロードを常に中断し、Xid 48 を生成します。 |
|
Google は、HBM リマップバンクが枯渇した場合や、GPU のライフタイム SRAM エラーしきい値を超えた場合など、GPU がハードウェア交換の対象となるタイミングをモニタリングし、GPU を交換するためにマシンを修理に送ります。 |
Xid 63: ECC page retirement or row remapping recording
event
メモリ エラーが原因で、動的ページの廃止または行の再マッピング イベントが記録されたことを示します。 |
|
Google はエラーのしきい値をモニタリングし、GPU の物理的な修理または交換が必要な場合は、マシンを修理に送ります。 |
Xid 64: ECC page retirement or row remapper recording
failure
メッセージには次の情報が含まれています。 Xid 64: All reserved rows for bank are remapped
|
|
再マッピング バンクが枯渇すると（ |
次の Xid メッセージのうち少なくとも 2 つが同時に表示された場合:
メッセージには次の情報が含まれています。 Xid XX: row remap pending
|
|
リマップ バンクが使い果たされた場合、または GPU の物理的な修理や交換が必要な場合、Google はマシンを修理に送ります。 |
Xid 92: High single-bit ECC error rate |
この Xid メッセージは、GPU ドライバが修正可能なエラーを修正した後に返され、ワークロードには影響しません。この Xid メッセージは情報提供のみを目的としています。対応の必要はありません。 |
なし |
Xid 94: Contained error
GPU エラーが発生したことと、エラーが 1 つのアプリケーション内に含まれていたかどうかを示します。 Xid 94 単独ではエラーの根本原因を示すものではありません。根本原因を特定するには、同時に発生している他の Xid エラーとともに解釈する必要があります。 |
|
なし |
Xid 95: Uncontained error
GPU エラーが発生し、1 つのアプリケーションに限定されなかったことを示します。 Xid 95 単独ではエラーの根本原因は示されません。根本原因を特定するには、同時に発生している他の Xid エラーとともに解釈する必要があります。 |
なし |
GSP エラー
GPU System Processor（GSP）は GPU 上で動作し、低レベルのハードウェア管理機能を処理するマイクロコントローラです。
| Xid エラー メッセージ | ユーザー アクション | Google のアクション |
|---|---|---|
Xid 119: GSP RPC timeout |
|
なし。エラーが解決せず、サポートケースを登録すると、Google はサポート ワークフローを通じてハードウェアまたはドライバの状態を調査します。 |
Xid 120: GSP error |
不正なメモリアクセス エラー
アプリに不正なメモリアクセスの障害がある場合、次の Xid が返されます。
| Xid エラー メッセージ | ユーザー アクション | Google のアクション |
|---|---|---|
|
セグメンテーション違反と同様に、メモリアクセス違反が検出されました。これらのエラーは通常、GPU メモリが範囲外でアクセスされたか、無効なポインタや範囲外の配列の参照解除など、解放されたバッファでアクセスされたアプリケーション バグを示します。Xid 48 も存在しない限り、これらは ECC エラーを表すものではありません。 |
この問題を解決するには、アプリケーションのメモリアクセス エラーをデバッグします。cuda-gdb、Compute Sanitizer、cuda-memcheck を使用できます。 詳細については、NVIDIA Xid のドキュメントをご覧ください。 |
なし。ハードウェアの劣化が原因で、メモリへの不正アクセス エラーが誤って報告されるまれなケースでは、NVIDIA Data Center GPU Manager（DCGM）を使用して、さまざまなレベルのテスト範囲と期間で |
その他の一般的な Xid エラー メッセージ
| Xid エラー メッセージ | ユーザー アクション | Google のアクション |
|---|---|---|
Xid 74: NVLINK error |
|
なし |
Xid 79: GPU has fallen off the bus
これは、ハードウェアの問題により GPU が PCI バスから消えたため、ドライバが GPU と通信できないことを意味します。 |
ワークロードを復元するには、プロジェクトで緊急メンテナンスが有効になっているかどうかに応じて、次のいずれかの方法を使用します。
|
Google は、GPU が PCI バスから外れたことを検出し、マシンを修理に送ります。 |
Xid 109: Context switch timeout
Xid 109 は、NVIDIA GPU ドライバによって報告される一般的なエラーです。GPU インスタンスが、想定されるタイムアウト期間内にタスクのプリエンプションまたは切り替えに失敗した場合に生成されます。 Google は NVIDIA と協力して Xid 109 の調査を長年行っており、ドライバのバグによる既知の原因は最新のドライバで修正されています。Xid 109 はハードウェアの問題が原因ではありません。 |
|
なし |
次の例のように、0x02a について言及する Xid 149:これは、NVIDIA B200 GPU のファームウェアに影響する既知の問題を示しています。 |
|
なし |
OS のパッチ適用またはカーネルのアップグレード後の nvidia-smi の失敗に関するトラブルシューティング
メンテナンスの時間枠、OS パッチ適用実行、VM 再起動後に nvidia-smi が NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver で失敗した場合は、カーネル パッケージの保留を確認します。binary モードでの以前のドライバ インストールからのパッケージ ロックにより、一致するカーネル ヘッダーのインストールが妨げられることがあります。
この問題を診断して解決するには、オペレーティング システムを選択してください。
Ubuntu
実行中のカーネル バージョンを確認します。
uname -rbinaryモードでの以前のドライバ インストールで、--force-version、--installation-branch=lts、または NVIDIA RTX 仮想ワークステーション（vWS）コンピューティング インスタンスを使用する場合など、カーネル パッケージがロックされているかどうかを確認します。apt-mark showholdlinux-image-gcpまたはlinux-headers-gcpがリストに表示されているかどうかを確認します。実行中のカーネルにカーネル ヘッダーがインストールされているかどうかを確認します。
dpkg -l | grep "linux-headers-$(uname -r)"カーネル メタパッケージが保持されている場合は、パッケージ ロックを削除します。
sudo apt-mark unhold linux-image-gcp linux-headers-gcp実行中のカーネルのカーネル ヘッダーをインストールします。
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)NVIDIA カーネル モジュールを再ビルドして読み込みます。
DKMS モジュール ソースが登録されている場合（
sudo dkms statusを確認）:sudo dkms autoinstall sudo modprobe nvidia nvidia-smisudo dkms statusに登録済みの NVIDIA モジュールが表示されない場合（たとえば、以前に--dkmsなしで.runバイナリを使用してドライバをインストールした場合）、 Google Cloud GPU ドライバ インストーラを再実行します。sudo python3 cuda_installer.pyz install_driver
Debian
実行中のカーネル バージョンを確認します。
uname -rbinaryモードでの以前のドライバのインストールで、--force-version、--installation-branch=lts、または NVIDIA RTX 仮想ワークステーション（vWS）コンピューティング インスタンスを使用する場合など、カーネル パッケージがロックされているかどうかを確認します。apt-mark showholdlinux-image-cloud-amd64またはlinux-headers-cloud-amd64がリストに表示されているかどうかを確認します。実行中のカーネルにカーネル ヘッダーがインストールされているかどうかを確認します。
dpkg -l | grep "linux-headers-$(uname -r)"カーネル メタパッケージが保持されている場合は、パッケージ ロックを削除します。
sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64実行中のカーネルのカーネル ヘッダーをインストールします。
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)NVIDIA カーネル モジュールを再ビルドして読み込みます。
DKMS モジュール ソースが登録されている場合（
sudo dkms statusを確認）:sudo dkms autoinstall sudo modprobe nvidia nvidia-smisudo dkms statusに登録済みの NVIDIA モジュールが表示されない場合（たとえば、以前に--dkmsなしで.runバイナリを使用してドライバをインストールした場合）、 Google Cloud GPU ドライバ インストーラを再実行します。sudo python3 cuda_installer.pyz install_driver
RHEL と Rocky Linux
実行中のカーネル バージョンを確認します。
uname -rbinaryモードでの以前のドライバ インストールで、--force-version、--installation-branch=lts、NVIDIA RTX 仮想ワークステーション（vWS）コンピューティング インスタンスを使用する場合など、カーネル パッケージがロックされているかどうかを確認します。grep "^exclude=.*kernel" /etc/dnf/dnf.conf実行中のカーネルにカーネル ヘッダーがインストールされているかどうかを確認します。
rpm -qa | grep "kernel-devel-$(uname -r)"カーネル パッケージが除外されている場合は、
/etc/dnf/dnf.confのexclude=行からkernel*を削除します。実行中のカーネルのカーネル ヘッダーをインストールします。
sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)NVIDIA カーネル モジュールを再ビルドして読み込みます。
DKMS モジュール ソースが登録されている場合（
sudo dkms statusを確認）:sudo dkms autoinstall sudo modprobe nvidia nvidia-smisudo dkms statusに登録済みの NVIDIA モジュールが表示されない場合（たとえば、以前に--dkmsなしで.runバイナリを使用してドライバをインストールした場合）、 Google Cloud GPU ドライバ インストーラを再実行します。sudo python3 cuda_installer.pyz install_driver
セキュアブートのトラブルシューティング
セキュアブートが有効になっているコンピューティング インスタンスに NVIDIA ドライバをインストールし、nvidia-smi が NVIDIA ドライバと通信できない場合、セキュアブートによって署名されていないカーネル モジュールの読み込みがブロックされる可能性があります。
この問題を診断して解決するには、次の操作を行います。
署名がないか無効なため、セキュアブートがカーネル モジュールを拒否したかどうかを確認します。
sudo dmesg | grep -iE 'secure boot|nvidia'
セキュアブートによってモジュールがブロックされた場合は、ドライバ モジュールに手動で署名してマシン所有者キー（MOK）を登録するか、事前に署名されたカーネル モジュールを含む OS イメージを使用します。手順については、GPU ドライバをインストールする（セキュアブート VM）をご覧ください。
GPU をリセットする
問題によっては、GPU のリセットが必要になる場合があります。GPU をリセットする手順は次のとおりです。
- 1 つ以上の GPU が割り当てられた N1、G2、A2、G4 VM の場合は、VM を再起動します。
- 部分 GPU（1 つ未満の GPU がアタッチされている）を使用する G4 VM の場合は、次の操作を行います。
- A3、A4、A4X、A4X Max インスタンスの場合は、
sudo nvidia-smi --gpu-resetを実行します。- ほとんどの Linux VM では、
nvidia-smi実行可能ファイルは/var/lib/nvidia/binディレクトリにあります。 - GKE ノードの場合、
nvidia-smi実行可能ファイルは/home/kubernetes/bin/nvidiaディレクトリにあります。
- ほとんどの Linux VM では、
- GKE ノードの A3、A4、A4X、A4X Max インスタンスでは、gpu-reset-tool を使用して、ノード上のすべての GPU のリセットを自動化することもできます。このツールでは、ターゲット ノード名を指定するだけで済みます。
または、VM をリセットするか、VM を停止して再起動する場合にもその都度 GPU がリセットされます。VM のライフサイクル状態と VM の復元アクションの違いの詳細については、Compute Engine インスタンスのライフサイクルと Compute Engine インスタンスを一時停止、停止、リセットするをご覧ください。
サポートケースを登録する
このページのガイダンスに従っても問題を解決できない場合は、次の情報を収集してサポートケースを作成してください。
- 影響を受けるインスタンスが配置されているプロジェクトのプロジェクト ID。
- クラスタ内のすべてのインスタンス名または ID のリスト。
- トラブルシューティングで特定された疑わしいノードのリスト。
- デバッグ設定が有効になっている完全なインターリーブされていない NCCL ログ。
- ハードウェア ヘルスチェックの出力（
dcgmi、nvidia-smi）。 - 失敗している正確なベンチマークまたはワークロード コマンド。
- 関連するログファイル（ホストエンジン ログや診断ログなど）。これらを収集するには、デフォルトのインストールでは
/usr/local/dcgm/scriptsにあるgather-dcgm-logs.shを実行します。 - NVIDIA バグレポート。
nvidia-bug-report.shを実行します。Blackwell GPU の場合は、Blackwell GPU の NVIDIA バグレポートを生成するの手順に沿って操作します。 - エラーが発生する前に環境に加えた最近の変更に関する詳細。
次のステップ
GPU マシンタイプを確認する。