GPU Health Checkとは？ECC・Xid・温度異常からLLM推論を守る

GPU使用率が高く、memoryにも余裕がある。それでもLLMの応答が急に遅くなり、別のworkerではCUDA errorが出ることがある。GPUが計算できていることと、健全に計算できていることは同じではない。

LLM servingでは、一台の不調なGPUがTensor Parallel group全体を待たせる。訂正不能なmemory errorやlink障害はrequest失敗やprocess停止にもつながる。GPU Health Checkは利用率を見るためではなく、正しい計算と安定した通信を継続できるか判断するために行う。

GPU使用率はhealthを表さない

GPU utilizationは、観測期間のうちkernelが動いていた割合である。高い利用率は故障の否定にならず、低い利用率も故障の証拠ではない。

温度や電力制限でclockが下がっても利用率は高くなりうる。逆に、上流queueが空なら健全なGPUでも利用率は低い。health判断では、少なくとも次の信号を組み合わせる。

ECC errorとmemoryの修復状態
driverがkernel logへ記録するXid
温度、power、clock、throttle理由
PCIe replay、NVLink error、fabric状態
CUDA context作成と小さな計算の成否
同型GPU間のthroughput、clock、powerの外れ値
CUDA error、NCCL timeout、TTFT、ITL

一つのmetricだけで故障を断定せず、同じGPU UUIDで時系列とapplication症状を結び付ける。

ECCは訂正済みと訂正不能を分ける

ECCはGPU memory内のbit errorを検出し、対応hardwareでは一部を訂正する仕組みである。Single-Bit Errorは訂正される場合があるが、訂正できたから無視してよいとは限らない。発生率の増加や同じ領域での反復は、memory劣化や環境要因の手掛かりになる。

Double-Bit Errorなどの訂正不能errorは、workloadの正しさや継続性に影響しうる。DCGMのmemory health watchは、volatileなdouble-bit ECC、faulty memory、pendingまたは過剰なpage retirement、row remap失敗などを評価する。

確認時はcurrent boot以降のvolatile countと、累積値であるaggregate countを混同しない。counterが非zeroかだけでなく、直近で増えたか、どのworkload中に増えたかを見る。

page retirementとrow remappingを見る

errorが見つかったmemory pageを使わないようにするpage retirementや、故障したmemory rowを予備rowへ置き換えるrow remappingがある。修復機能が動いたこと自体は即時故障を意味しないが、pending状態、修復失敗、予備資源の減少は運用判断に必要である。

再起動後に修復が反映される場合もあるため、単に再起動してcounterが消えたように見える状態を正常復帰としない。修復状態を確認し、必要なdiagnosticを通してからschedulerへ戻す。

Xidは原因ではなく調査の入口である

XidはNVIDIA driverがOSのkernel logまたはevent logへ出すGPU error reportである。hardware、driver、applicationのいずれも原因になりうる。Xid番号だけで「GPU故障」と決めるものではない。

Linuxでは最初のXid付近にGPU UUIDやPCI bus IDが記録される。時刻、Xid番号、GPU UUID、直前のrequestやjob、driver versionを保存する。GPU indexは並び替わる可能性があるため、GPU 2だけをincident記録へ残さない。

Xidごとに推奨対応は異なる。applicationの不正memory accessを示す場合も、PCIeやframe bufferのcorruptionが別のerrorとして表面化する場合もある。公式資料を参照し、codeごとのrunbookへ分岐する。

resetや再起動の前に証拠を残す

GPU resetやnode再起動は復旧を早める場合があるが、kernel log、counter、process状態などの証拠を失わせる。まず新規requestの割り当てを止め、可能なら既存requestをdrainし、次を採取する。

Xidを含むkernel logと時刻
GPU UUID、PCI bus ID、driver・firmware version
ECC、retired page、row remap、temperature、power、clock
PCIe、NVLink、NVSwitchのerrorと状態
process、container、model version、parallel group
CUDA、NCCL、model serverのlog
TTFT、ITL、throughput、error rateの変化

NVIDIAのnvidia-bug-report.shはdriver関連のdebug情報を収集する。productionでの実行権限、保存先、個人情報やsecretの取り扱いを事前にrunbookへ定める。

温度、電力、clock低下はstragglerを生む

GPUは温度やpower limitに近づくとclockを下げることがある。処理自体は成功しても、一つのrankだけ遅くなればAll-ReduceやAll-to-Allの同期点でgroup全体が待つ。

平均温度だけでは短いthermal excursionを見逃す。temperature、SM・memory clock、power draw、throttle reasonを同じ時間軸で確認する。同型GPUの同じworkloadと比較し、一台だけclockやthroughputが低い状態を検出する。

原因はGPU単体とは限らない。fan、airflow、rack吸気温度、power delivery、同居workloadも調べる。clock低下をmodel serverのbatch設定だけで補うと、障害の発見を遅らせる。

PCIeとNVLinkもhealthの一部である

GPU memoryとcomputeが健全でも、PCIeやNVLinkのerrorでcollectiveが遅延または失敗する。DCGMのhealth monitoringはPCIe replayやbus・fabric関連Xid、NVLink、driverなどを監視対象にできる。

LLM servingではNCCL timeoutやhangが最初の症状になることがある。application logだけで通信libraryの問題と断定せず、affected rankのGPU、link、NIC、switchをTopologyと照合する。同じGPUで再発するのか、同じPCIe switchやNVLink pathに偏るのかで調査範囲が変わる。

DCGMのpassive監視とactive診断を分ける

NVIDIA DCGMには、通常workloadを動かしたままtelemetryを評価するhealth monitoringと、専用の負荷をかけるdiagnosticsがある。

passive health monitoringは、保持したsampleからPCIe、memory、driver、thermal・power、NVLinkなどの既知のincidentを判定する。Healthyは、設定したwatchが保持期間内に問題を検出しなかったという意味である。すべてのsubsystemを検査したことや、負荷試験に合格したことまでは保証しない。

active diagnosticsは、CUDA context、memory、compute、PCIe、bandwidth、powerなどへtest workloadをかける。passive監視で問題がなくてもactive testで失敗することがあり、その逆もある。

active testはGPU compute、memory、PCIe、NVLink、CPU、power、coolingを消費し、running processと競合する。production trafficを載せたまま長いsuiteを実行せず、対象GPUまたはnodeをschedulerから外してから行う。

Pass、Fail、Skipを正しく読む

diagnosticのPassは、選択したtestが説明された範囲で問題を検出しなかったことを示す。GPU全体の永久的な健康証明ではない。

Failはhardware defectの検出だけでなく、prerequisite不足やtest実行失敗を含む場合がある。結果のcodeとmessageを読む。Skipは未検査であり、passとして数えない。

復帰条件は「commandが終了した」ではなく、必要なtestが対象GPUでpassし、counterが安定し、canary workloadでapplication metricも正常であることにする。

LLM servingで現れる症状

一つのrankだけDecodeが遅くなり、全体のITLが悪化する
NCCL collectiveがtimeoutする
CUDA contextの作成やmemory allocationが失敗する
workerが再起動loopへ入る
outputにNaNが混ざる、またはdiagnosticで計算結果の不一致が出る
replicaの一部だけTTFTとerror rateが悪化する

ただしOOMは常にhardware故障ではない。KV Cache不足、memory leak、batch設定、fragmentationでも起きる。CUDA errorやlatency悪化をhealth telemetryと関連付けて切り分ける。

隔離から復帰までの手順

alertへGPU UUID、node、時刻、severityを付ける
schedulerで対象GPUまたはnodeへの新規配置を止める
可能なrequestを別replicaへ逃がし、対象workerをdrainする
resetや再起動の前にlogとcounterを採取する
Xid、ECC、row remap、temperature、power、link、application症状を分類する
code別runbookに従ってprocess停止、GPU reset、node再起動、driver調査、hardware交換へ分岐する
idle状態で必要なactive diagnosticを実行する
小さなcanary workloadで正しさ、latency、collectiveを確認する
一部trafficから段階的にschedulerへ戻す
再発監視期間を設け、incident記録とcounter差分を残す

訂正不能ECCや重大なXidが出たGPUへ、自動再試行だけでtrafficを戻し続けない。別replicaでrequestを成功させる仕組みと、疑わしいdeviceを隔離する仕組みを分ける。

Kubernetesでの実装

KubernetesではDCGM ExporterなどでGPU telemetryを収集し、alertとnode・deviceの隔離へつなげる。metricを集めるだけで自動復旧は完成しない。

alert ruleには一時的なspikeを吸収する継続時間と、即時隔離すべきfatal eventを分けて持たせる。GPU単位で隔離できないscheduler構成なら、node全体をcordonしてworkloadをdrainする。MIGを使う場合も、instanceのerrorとphysical GPU全体の状態を区別する。

indexではなくUUIDを主keyにし、Pod、container、model、rank、PCI bus IDを関連付ける。device pluginやcontainer runtimeの再起動でindexが変わっても追跡できるようにする。

監視するmetric

corrected、uncorrected ECCの増分
volatile、aggregate ECC count
retired page、pending page、row remapの状態
Xid番号、発生時刻、GPU UUID、PCI bus ID
temperature、power draw、power limit、throttle reason
SM clock、memory clock、同型GPU間のperformance差
PCIe replay、NVLink・NVSwitch error
DCGM healthのsubsystem別Warning・Failure
diagnosticのtest、結果、code、対象entity
CUDA error、worker restart、NCCL timeout
GPU別のTTFT、ITL、token throughput、error rate
node隔離から復帰までの時間と再発率

counterの絶対値だけでなく、deployment、driver更新、firmware更新、室温変化の前後差を見る。

障害試験

alertからGPU UUIDとPodを特定できるか確認する
一台のworkerを停止し、requestが別replicaへ退避するか確認する
persistentなhealth eventで新規配置が止まるか確認する
drain中に新しいlong requestが入らないか確認する
log採取前にautomationが再起動しないか確認する
active diagnosticがproduction workloadへ混入しないか確認する
SkipをPassとして復帰判定しないか確認する
GPU index変更後もUUIDでincidentを追跡できるか確認する
一つのrankを意図的に遅らせ、TTFT・ITLとcollective待ちで検出できるか確認する
canary失敗時に再隔離されるか確認する

hardware errorそのものを無理に再現する必要はない。alert、scheduler、drain、evidence収集、診断、復帰のcontrol pathを安全なfault injectionで検証する。

GPUのhealthは計算、memory、通信、冷却をまとめて見る

GPU Health Checkは、使用率やfree memoryを眺める作業ではない。ECC、page retirement、row remap、Xid、温度・電力、clock、PCIe・NVLink、application症状を同じGPU UUIDと時間軸で関連付ける。

通常時はpassive monitoringを続け、疑わしいdeviceをdrainしてからactive diagnosticsを行う。reset前に証拠を保存し、Pass・Fail・Skipを区別し、canaryを通して段階的に戻す。LLM分散推論では一台のstragglerが全rankへ波及するため、個体のhealthとservice全体のlatencyを同時に見る必要がある。