GPU ハードウェア・ドライバ障害診断

状態: ドラフト (2026-10-06 更新)。 公式ドキュメントで確認した記述がベースであり、 コンシューマー向け GPU 3 種で読み取り専用として確認した部分(10節末尾の「実測」)のみ 直接確認した値です。データセンター向け GPU と実際の障害イベントは測定できませんでした。 文章末尾の「確認したバージョンと日付」および「確認できなかったこと」を先にお読みください。 作成規則: 実測データが基本であり、測定できなかったものは「未実測」と表示します。

目次

• 概要
• 1. 信号が流れる道
• 2. コンシューマー向け GPU とデータセンター向け GPU
• 3. XID の読み方
• 4. ECC、行リマッピング、リタイア
• 5. NVLink、NVSwitch、Fabric Manager
• 6. スロットリングと PCIe 降格
• 7. 遅い 1 つの GPU が全体を遅くする
• 8. Kubernetes の対応: 隔離と自動復旧
• 9. アラート設計
• 10. 実際にやってみる (読み取り専用)
• 外部根拠: 論文と公式資料で確認した内容
• 11. 面接で出そうな質問
• 12. よくある誤解
• 13. 参考文献と確認したバージョン
  • 実測: コンシューマー向け GPU 3 種で読み取った値 (読み取り専用)

概要

GPU 障害診断は 3 つの系統の信号を読み取る作業です。カーネルログの XID メッセージ、DCGM (Data Center GPU Manager) と nvidia-smi の指標、Kubernetes のノード状態です。

この記事を読み終えると面接で説明できるようになること

1. XID を「番号、カタログの即座の処置バケット、単独発生かどうか」の順序で読み解き、アプリのエラーとハードウェアのエラーを切り分ける方法
2. ECC、NVLink、スロットリング、PCIe 降格がどのような指標やコードに現れるか、そして遅い 1 つの GPU を見つける方法
3. 自動隔離・復旧パイプラインの構成、および何をPagerDutyで通知し何をチケットとして残すかの基準

1. 信号が流れる道

GPU + 드라이버(NVML)
 ├─ 커널 로그 "NVRM: Xid (PCI:0000:ca:00): 79, ..." ─► 로그 수집기(syslog 모니터)
 ├─ NVML 이벤트(XID) ─► 디바이스 플러그인 ─► 장치 unhealthy ─► kubelet allocatable 감소
 └─ DCGM ─┬─ dcgm-exporter :9400/metrics ─► Prometheus ─► 알림
          └─ health watch, dcgmi diag (능동 점검)

dcgm-exporter のデフォルト指標ファイル(default-counters.csv, main)から診断に使用するものです。括弧内はデフォルトの状態です。

DCGM API ドキュメントのフィールド名(例: ..._TEMP_CELSIUS)と exporter の指標名が異なる場合があるため、使用する exporter の CSV を基準とします。

2. コンシューマー向け GPU とデータセンター向け GPU

実験環境での実測値です。8GB クラスのノートPC用 GPU(ドライバ 595.91.07)の dcgm-exporter 原文には XID_ERRORS と PROF_* の行がなく、 MEMORY_TEMP およびリマッピング行の指標は 0 でした。0 が「サポートしており正常」なのか「非サポートだから 0」なのか、XID 行がない理由が exporter のバージョンによるものかコンシューマー向け GPU の制約によるものかは確認できませんでした。XID カタログの「適用対象」の列も A100 以降のデータセンター向け製品のみです。

3. XID の読み方

形式は NVRM: Xid (PCI 주소): 번호, 부가 정보 です。読み取る順序は ① カタログの即座の処置バケット、② 単独 (solo) なのか他の XID と一緒なのか (45 は他のエラーの結果としても記録される)、③ 同じ GPU で繰り返されるか、です。バケットは RESTART_APP(アプリのみ再起動)、 RESET_GPU, RESTART_BM(ノード再起動)、 IGNORE, CONTACT_SUPPORT です。Xid 154 は必要な復旧処置 (None, Drain P2P, Drain and Reset, GPU Reset Required, Node Reboot Required) を通知してくれます。

31 はカタログではアプリ側が多いとしつつも、GPU デバッグガイドでは「Suspected Hardware Problems」とされているため、単発はアプリ、繰り返しはハードウェアという分岐を直接設ける必要があります。デバイスプラグインは 13、31、43、45、68、109 を「アプリエラー」としてハードコードして無視し、NVML が critical と通知する残りの XID でデバイスを unhealthy として表示します(ソース)。ソースの FIXME には unhealthy から復帰するパスがないと記載されているため、リセット後にプラグインの再起動が必要であると推論されます(未確認)。

4. ECC、行リマッピング、リタイア

単一ビットエラーはハードウェアが訂正し、二重ビットは検出のみを行います。カウンターはドライバーロード以降の volatile と、生涯累積の aggregate に分かれます。Ampere 以降では行リマッピングがページリタイア(旧型は最大 64)に置き換わり、最大 512 回のリマッピングを行いますが、適用には GPU のリセットが必要です。リマッピング失敗フラグは、すでに 8 行がリマッピングされたバンクに再度試行した場合、すでにリマッピングした行に再度試行した場合、または合計 512 回に達した場合に立ち、RMA 判断の根拠となります。根拠となるドキュメントは A100 以降を基準としています。

nvidia-smi -q -d ECC,ROW_REMAPPER,PAGE_RETIREMENT

5. NVLink、NVSwitch、Fabric Manager

Fabric Manager (FM) は NVSwitch システムにおいて GPU 全体を 1 つのメモリファブリックとして結合し、リンクを監視します。HGX A100 は FM の初期化前に CUDA を開始すると cudaErrorSystemNotReady が発生します。Hopper 以降では GPU とスイッチが独自のリンク学習を行い、リセットに FM を必要としません。FM はドライバーと同一のバージョンである必要があります。74 が発生した場合は nvidia-smi nvlink -e で CRC・replay・recovery エラーカウンターを確認します。致命的な SXid は CUDA の処理を中断させ、74 と 45 を同時に残します。Blackwell ファミリーは NVLink 5 用の XID 144 から 150 番台を使用し、SXid は適用されません。Ampere NVSwitch システムは FM が稼働しているときにのみ GPU を 1 つずつリセットでき、そうでなければ NVLink で結ばれた GPU をまとめてリセットします。

6. スロットリングと PCIe 降格

clocks_event_reasons はビットマスクです。値は、GPU アイドル 0x1、アプリケーションクロック 0x2、SW 電力上限 0x4、HW スローダウン 0x8、同期ブースト 0x10、SW サーマル 0x20、HW サーマル 0x40、HW パワーブレーク 0x80、ディスプレイクロック 0x100、ボード制限 0x200、信頼性 0x400 です (go-nvml)。0x8 と 0x40 はコアクロックを半分以下に低下させ、0x80 は外部電源ブレーク信号であるため大きな意味を持ちます。Llama 3 の論文には、日中の気温が原因でスループットが日単位の周期で 1% から 2% 変動したと記載されています。PCIe は pcie.link.gen.current と pcie.link.gen.max, pcie.link.width.current を比較しますが、現在の値はアイドル時に低下する場合があるというマニュアルの説明に従い、負荷をかけている最中に測定する必要があります。再試行は PCIE_REPLAY_COUNTER であり、DCGM health の出力例では分間 8 回超を警告として表示しています。

7. 遅い 1 つの GPU が全体を遅くする

Meta は Llama 3 405B の 54 日間の期間において 466 回の中断 (予期せぬ中断 419 回) があり、予期せぬ中断の約 78% がハードウェア起因 (GPU 58.7%) であると報告しました。論文の原文を開いて確認したところ、この 58.7% は本文にそのように記載されているものの表 5 の印刷された比率を合計した値であり、同じ表の件数で再計算すると GPU 分類は 268 件であるため 419 件中の 64.0% となります (表の「Faulty GPU」の 30.1% は件数 148 件と一致しない印刷ミスとみられ、件数ベースでは 35.3%)。後述の「外部根拠」にまとめています。同記事には、動作はするものの遅いストラグラーは発見が難しく、1 つのストラグラーが数千の GPU を遅くする可能性があり、遅い通信として現れると記載されています。見つけ出す順序は筆者のまとめです。① ランク別のステップ・集合通信時間を比較します (PyTorch flight recorder)。② 遅いランクの GPU のスロットリング理由、温度、電力、PCIe の世代と幅、NVLink エラーを並べて確認します。③ ノードを空けた上で dcgmi diag -r 3(targeted_stress、nvbandwidth、nccl_tests を含む)で確認します。DCGM のドキュメントでは、これが包括的なハードウェア診断や RMA の根拠の代わりにはならないと明記されています。

8. Kubernetes の対応: 隔離と自動復旧

flowchart LR
  D["탐지<br/>XID, DCGM, 플러그인"] --> C["분류<br/>카탈로그 버킷, 반복 여부"]
  C --> Q["cordon·taint"]
  Q --> R["drain<br/>PDB 존중"]
  R --> X["복구<br/>GPU 리셋, 노드 재시작, 교체"]
  X --> V["검증<br/>dcgmi diag -r 1 또는 2"]
  V --> U["uncordon"]
  X -. 반복 실패 .-> H["사람 호출"]

unhealthy になってもすでに割り当てられたポッドはそのデバイスに紐づいたままとなるため (Kubernetes ドキュメント)、ドレインが必要です。1.36 の ResourceHealthStatus(ベータ)はコンテナの状態 allocatedResourcesStatus を通じてデバイスの健康状態を通知します。NVSentinel (v1.25.0、Beta/Stable、Kubernetes 1.34+、スタンドアロン DCGM が必要)は DCGM と syslog の XID を内蔵カタログで分類して cordon、drain、リセット・再起動までつなげ、5 分以内にノードの 50% が cordon された場合に停止するサーキットブレーカーを備えており、デフォルトではモニタリングのみを有効にします。Amazon EKS の node monitoring agent はよく知られている XID をノードの条件 AcceleratedHardwareReady=False に上げて 48 は再起動、74・79 は交換として記録し、分からない XID はイベントとしてのみ残します。ベンダーへ問い合わせる前には nvidia-bug-report.sh の出力、FM ログ、DCGM 診断ログを収集します（GPU デバッグガイド）。

9. アラート設計

Google の SRE 本には「機械的な応答であればページではない」と書かれています。以下はこれを適用した筆者の提案です。

10. 実際にやってみる（読み取り専用）

# GPU 가 있는 노드에서 실행
journalctl -k --no-pager | grep -E "NVRM: Xid" | tail   # dmesg 가 막힌 계정에서도 읽힘, 아래 「실측」 참고
nvidia-smi --query-gpu=index,name,pcie.link.gen.current,pcie.link.gen.max,pcie.link.width.current,temperature.gpu,power.draw,clocks_event_reasons.active --format=csv
nvidia-smi -q -d PERFORMANCE,ECC,ROW_REMAPPER | head -80

# 쿠버네티스에서 dcgm-exporter 지표 확인
kubectl -n gpu-operator get po -l app=nvidia-dcgm-exporter -o wide
curl -s http://<파드IP>:9400/metrics | grep -E "XID|REMAP|PCIE_REPLAY|VIOLATION"

使用率、電力、温度、VRAM、クロックしか見ないダッシュボードでは、GPU 固有のアラート規則が抜け落ちがちです。筆者は 8GB カードでサーバープロセスのロケータキャッシュが 6 分で 6.4 GB から 7.8 GB に増加するのを観察しており、こうした VRAM の傾向はアラートの練習に適した資料です。

外部的根拠：論文と公式資料で確認した内容

データセンター GPU や大規模クラスターがないため、実際の障害インシデントを測定することはできませんでした。その代わりに大規模運用レポートと NVIDIA の公式ドキュメントを開き、11 件の記述を突き合わせました。外部の数値は、機器や条件が異なるため、方向性と一致しているかどうかの判定のみ行いました。

ベンダーの数値は本文に記載されている条件のもののみを転載し、論文の本文を開けなかった資料は使用していません。

11. 面接で聞かれる可能性のある質問

1. XID 79 を確認しました。どう対応しますか？ PCIe 経由で GPU にアクセスできないという意味であり、カタログのバケットとしてはノードの再起動となります。cordon と drain を行った後に再起動し、繰り返される場合はリンク、電源、システムイベントログを確認して交換します。
2. XID 13 と 48 はどのように扱いますか？ 13 は大半がアプリのエラーなので Compute Sanitizer で確認し、同じ TPC・GPC で繰り返される場合はハードウェアを疑います。48 は訂正不能 ECC であるためリセットまたは再起動が必要であり、63・64 が伴う場合は drain してからリセットします。
3. 低速な GPU 1 枚をどのように見つけますか？ ランクごとの通信時間から疑わしいランクを絞り込み、その GPU のスロットリング理由、温度、PCIe、NVLink エラーを比較します。ノードを空にした後、 dcgmi diag -r 3 で確認します。
4. 自動復旧において何を注意すべきですか？ 同時実行数の上限とサーキットブレーカーにより一度に切り離されないようにし、繰り返し失敗する場合は人間に引き継ぎます。リセット時は GPU を使用しているプロセスがない状態にする必要があります。
5. どのような場合にページ（アラート）を鳴らしますか？ 機械的に処理されるものは自動化し、記録のみを残します。自動復旧に失敗したときや繰り返されるとき、利用可能な GPU が閾値を下回ったときにページを鳴らします。

12. よくある誤解

• 「XID が記録されると GPU の故障である」：13、31、43、45 はアプリのエラーである場合が多いです。
• 「XID_ERRORS 「 はエラーの回数である」：最後の XID の値です。
• 「使用率が高ければ正常」：低速な GPU でも使用率は高くなります。

13. 参考資料と確認したバージョン

すべて 2026-10-05 にアクセスしました。

• https://docs.nvidia.com/deploy/xid-errors/ （カタログ、最終更新 2026-09-09）
• https://docs.nvidia.com/deploy/a100-gpu-mem-error-mgmt/ , https://docs.nvidia.com/deploy/gpu-debug-guidelines/
• https://docs.nvidia.com/datacenter/dcgm/latest/ （feature-overview, dcgm-diagnostics, getting-started, dcgm-api-field-ids）
• https://github.com/NVIDIA/dcgm-exporter (default-counters.csv), https://github.com/NVIDIA/k8s-device-plugin (health.go), https://github.com/NVIDIA/go-nvml (const.go)
• https://docs.nvidia.com/deploy/nvidia-smi/index.html , https://docs.nvidia.com/datacenter/tesla/fabric-manager-user-guide/index.html
• https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/troubleshooting.html
• https://github.com/NVIDIA/NVSentinel , https://docs.nvidia.com/nvsentinel/ , https://docs.aws.amazon.com/eks/latest/userguide/node-health-nma.html
• https://arxiv.org/abs/2407.21783 , https://arxiv.org/abs/2505.05713 , https://sre.google/sre-book/monitoring-distributed-systems/
• https://docs.pytorch.org/tutorials/unstable/flight_recorder_tutorial.html , https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/

実測：コンシューマー向け GPU 3 種から読み取った値（読み取り専用）

デスクトップ向け 24GB 級（Ampere 世代、ドライバー 570.195.03）、ノートPC 向け 8GB 級（Ada 世代、595.91.07）、ノートPC 向け 6GB 級（Ampere 世代、595.91.07）において、 nvidia-smi -q -d ECC,ROW_REMAPPER,PAGE_RETIREMENT, --query-gpu フィールド、カーネルログを読み取りました。3 つともアイドル状態であり、何も変更していません。

• セクション 2 の表が述べていた「GA10x・Ada 列に行リマッピングが表示される」という点は製品によって異なっていました。 Ampere 世代のコンシューマー向け 2 種はドライバーが N/A を返し、Ada 世代のノートPC のみが値を返しました。この GPU では 0 が「サポートしており正常」を意味し、サポートしていない GPU では同じクエリが 0 ではなく N/A として返されました。したがって、ダッシュボードでは N/A と 0 を区別する必要があり、値が常に 0 であるという理由だけで正常と判断してはなりません。セクション 2 において 8GB 級ノートPC GPU の exporter が示したリマッピング 0 はこの値と一致しています。
• この 3 種（GDDR6 世代）では ECC カウンターが露出していませんでした。 3機種とも N/A であったため、ハードウェアカウンタでメモリエラーを検出できず、Xid ログやアプリケーションの異常動作に頼る必要があります。「コンシューマー向け GPU には ECC がない」と一般化することはできません。NVIDIA の RTX Blackwell ホワイトペーパーでは、GDDR7 の ECC が DRAM ダイに内蔵され、常に有効でソフトウェアで無効化できないと説明されており（カウンタが表示されるかは別問題）、RTX 30・40 世代のコンシューマー向け製品群に ECC がない旨を直接記載した公式文書は見つかりませんでした（nvidia-smi 文書の「コンシューマー向け製品群は情報が非常に限定的」という記述と、ECC モード項目が InfoROM オブジェクトを要求するという記述が間接的な根拠）。
• クエリのフィールド名は、ドライバー 570 と 595 の両方で有効でした。 remapped_rows.correctable, remapped_rows.uncorrectable, remapped_rows.pending, remapped_rows.failure, retired_pages.pending, ecc.errors.corrected.volatile.total, inforom.ecc, clocks_event_reasons.hw_thermal_slowdown, clocks_event_reasons.sw_power_cap, pcie.link.gen.gpucurrent がエラーなしで値または [N/A] を返しました。つまり、フィールド名が間違っているというエラーが発生しないため、N/A はフィールドが存在しないという意味ではなく、GPU が値を提供していないという意味になります。
• カーネルログは dmesg がブロックされている可能性があります。 3つのノードすべてで kernel.dmesg_restrict=1 であるため、一般アカウントの dmesg が read kernel buffer failed: Operation not permitted で失敗し、 journalctl -k は読み取れました。sudo が必要と案内されているコマンドがパスワードなしのアカウントではブロックされるため、運用点検スクリプトは journalctl -k を優先して使用する方が無難です。
• grep -iE "NVRM|Xid" は不正な行を検出します。 のようなログにおいて、このパターンは (1) NIC ドライバーがチップリビジョンを出力した XID 541 行と (2) Xid ではない NVRM: メッセージ（割り当て失敗の NV_ERR_NO_MEMORY）を同時に捉えました。どちらも GPU の障害ではないため、アラートのルールと点検コマンドは NVRM: Xid に絞り込む必要があります。実際の NVRM: Xid 行は3つのノードで0件でした。
• PCIe の世代はアイドル時に 1 に下がっていました。 3つのノードすべてで gpucurrent が 1 であり、最大値（4）とは異なっているように見えますが、アイドルの節電状態である可能性があるため、第6章の降格判定は負荷をかけた状態で再度読み取る必要があります。ノートPC向け GPU の1つは帯域幅が x8（最大 x16）となっており、設計上の理由による可能性があるため判定は見送りました。
• 負荷をかけて再度読み取りました（8GBクラスのノートPC向け GPU 1枚）。 サービングサーバーとして約80秒間負荷をかけながら、2秒ごとに38個のサンプルを読み取りました。PCIe の世代は最大の 4 で（37個、残り1個は 2）、帯域幅は 8 で一定でした。SM クロックの中央値は 2,640MHz（最大 3,105MHz には届かず、負荷開始時に 375MHz まで下がったサンプルがあった）、電力の中央値は 78W、最大 91.8W、温度は最高 63°C、使用率の中央値は 100% であった。**クロック制限の理由は負荷サンプル 37個すべてで 0（なし）**であり、アイドルサンプル1つのみが 0x01（アイドル）でした。つまり、この負荷では電力上限やサーマルスロットリングは発生しておらず、最大クロックに届かなかったのは制限理由なしで負荷と電力ポリシーに従ったものと推測されます。アイドル状態でもサーバープロセスが GPU を保持している場合は PCIe の世代が 4 に維持され（サンプル6個、SM クロック 1,890MHz、電力 8.7W）、プロセスが存在しないノードで読み取った世代 1 はコンテキストのない節電状態であった可能性が高いと考えられます（推測）。サーマルスロットリングと電力上限が実際に発生する高温・密閉環境についてはテストしていません（15分間の継続負荷は下記で確認し、クロック制限は発生しませんでした）。
• 15分間の継続負荷でもクロック制限の理由は発生しませんでした（8GBクラスのノートPC向け GPU 1枚）。 同じサーバーで同時 32 の負荷を 15分間継続してかけながら、2秒間隔で 443個のサンプルを読み取りました。PCIe は世代 4、帯域幅 8 で一定であり、SM クロックの中央値は 2,625MHz（範囲 1,890〜2,640）、電力の中央値は 78W、最大 93.2W、温度は最高 70°C でした。クロック制限の理由は、アイドルビットのサンプル1つを除けばすべて 0 でした（電力上限やサーマルスロットリングが発生したサンプルはない）。同じ時間帯のスループットは 829〜832 tok/s で、23回の測定において ±0.2% でした。80秒テストの最高温度 63°C より 7°C 上昇しましたが、この環境では熱が性能を低下させることはありませんでした。データセンターでの長時間の学習や、より高温の環境とは異なります。
• 負荷をかけても PCIe の世代が上がらない GPU に実際に遭遇しました（24GBクラスのデスクトップ向け GPU 1枚）。 この GPU はデバイスがサポートする最大リンクが 16GT/s（世代 4）で帯域幅が x16 ですが、行列積とホストから GPU への転送を 25秒間同時に実行して P0 状態、使用率 100%、SM クロック 1,950MHz になったにもかかわらず、 nvidia-smi の現在の世代は 1 であり、ホスト側から /sys/bus/pci/devices/<장치>/current_link_speed を3秒ごとに20回読み取った値もすべて 2.5GT/s（世代 1）でした。固定（pinned）メモリ 1GiB のホストからの GPU 転送は 1.7〜1.9GB/s、GPU からホストへの転送は 1.6〜2.2GB/s で、3回繰り返しても同じでした。PCIe 4.0 x16 の理論上の帯域幅（約 31.5GB/s）の約 6% です。同じ GPU のメモリ帯域幅（読み取り 905GB/s）と演算スループット（fp16 行列積 63〜71 TFLOPS）は正常であるため、リンクのみが低い世代に固定されている問題であると見られます。原因（マザーボードの設定、節電ポリシー、ライザーカード、スロット）は確認できていません（未確認）。この GPU のモデルロードと KV オフロードはホスト・GPU 間転送がボトルネックになるため、7GB モデルをロードする際に転送だけで約4秒（7 ÷ 1.8）かかり、8回の KV 読み込みのメリットも減少します（計算値）。確認方法は2つあります。負荷中に nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.gen.max --format=csv を読み取り、ホスト側の current_link_speed と max_link_speed を比較します。アイドル時に世代が低いのは正常ですが、持ち込みの 負荷中にも低い場合は降格です。

制限事項：コンシューマー向けモデル3機種のみであり、データセンター向け GPU の ECC、ロウリマップの失敗、XID 79 などの実際の障害には遭遇していません。DCGM の XID_ERRORS 指標がコンシューマー向け GPU で出力されない理由（エクスポーターのバージョン起因か、GPU の制約か）についても、今回のテストでは判別できませんでした（未確認）。

確認したバージョン：GPU Operator 26.7.1 バンドルの DCGM 4.6.1-1、DCGM Exporter 4.6.1-4.8.4、Kubernetes 安定板 v1.37.1。

確認できなかったこと：コンシューマー向け GPU の ECC・ロウリマップ・XID 指標の実際の出力、実験環境のエクスポーターのバージョン、クエリのフィールド名（第三者が公開した --help-query-gpu の出力に基づく）がドライバー 595 で有効かどうか、カタログのコンシューマー向け GPU への適用有無。アラート等級表と調査手順は公式の規定ではなく筆者の判断です。