この記事について

前回の記事で、複数の vLLM を同一GPUに常駐させた際に発生していたホストハングの原因（dockerd の一斉自動復旧時に起きるGPUメモリプロファイリングの衝突）を特定し、対策を打ちました。

対策後、明らかに衝突由来のハングは激減しました。ところが——別種の、もっと厄介なフリーズがまだ残っていました。本記事はその調査記録です。

前回とは明らかに性質が違うフリーズ

前回のフリーズは、カーネルログに NV_ERR_NO_MEMORY という分かりやすい手がかりを残してくれていました。今回のものは違います。

数日〜3週間、何の問題もなく安定稼働した後、前触れなく完全にフリーズする
SSHはおろかコンソールも一切応答しない。復旧は電源の物理OFF/ONのみ
カーネルログがある瞬間でぷつっと途切れる。パニックもOopsもXidエラーもECCエラーもOOM killer発動も、何も残らない
クラッシュダンプの仕組み（kdump-tools）を導入しても、/var/crash に何も残らない。そもそもパニックが起きていないため kexec への遷移が発生しない
ハードウェアウォッチドッグ（タイムアウト5秒で設定）すら自動リセットしてくれない

前回の「原因が分かっている」フリーズとは診断の手がかりの量が桁違いだったため、別課題として切り分けて調査することにしました。

仮説を一つずつ削っていく

原因不明なりに、疑わしい要素を一つずつ検証で潰していきました。

cronジョブがトリガーか？ → 否定的

発生直前のcron実行履歴を確認しましたが、単なる時刻の近接（定期実行ジョブが偶然近い時刻にあっただけ）でした。

チャットUIの利用がトリガーか？ → 否定的

アプリケーションのDB（SQLite）を直接見て、発生時間帯の利用実績がゼロだったことを確認しました。

vLLM移行そのものが原因か？ → 否定的

過去のログを遡ると、前の推論エンジン（Ollama）を使っていた時代にも同じ「無痕跡」パターンのフリーズが発生していたことが判明しました。つまりvLLM固有の問題ではありません。ただし発生「頻度」は明確に悪化していました（旧エンジン期間31日で1件 → vLLM移行後16日で6件）。これは前回記事で対策した「複数エンジン同時プロファイリング」が頻度を押し上げていた可能性が高いと考えています。

スワップ枯渇が原因か？ → 否定的

発生時点のスワップ使用量を確認しましたが、いずれも逼迫していませんでした。

複数vLLM同時稼働・他サービスの負荷が原因か？ → 否定的（最小構成での再現に成功）

これが一番の決め手でした。「複数プロセスが絡む何かが怪しい」という仮説を検証するため、他のvLLMとサービスを全部止め、最軽量のモデル1台だけを稼働させた最小構成にして経過観察しました。

5分おきに空きメモリ・スワップ・ヘルスチェック状態を記録するモニタリングスクリプトを仕込んだ上で観察したところ——1時間4分後、単一の軽量プロセスのみが動いている状態でも、同一の「無痕跡」パターンでフリーズが発生しました。直前の記録まで異常値は一切ありませんでした。

念のため同じ縮小構成のまま追試したところ、さらに2回（1時間2分後、2時間26分後）同様のフリーズが発生。これで「複数プロセスの競合が引き金」という説はほぼ否定されました。単一の軽いプロセスが動いているだけの、ごく普通の状態でも起きるのです。

転機：ACPIサーマルゾーンの異常

八方塞がりの中、カーネルログを別の角度から洗い直していたところ、全てのブートで毎回出ている、これまで見過ごしていた警告に気づきました。

kernel: ACPI: thermal: [Firmware Bug]: No valid trip points!

これは「ACPI経由の温度保護閾値（trip point）が一切設定されていない」というファームウェア側の不具合を示す警告です。過去のログを遡れる限り確認しましたが、導入当初からずっと出続けていました。

これが意味するのは、OSレベルの温度保護（閾値超過時の警告・グレースフルなスロットリング）が機能していない可能性がある、ということです。GPU/SoCシリコン自体のハードウェア保護回路（サーマルスロットルやシャットダウン）は別途存在するはずですが、ACPI経由の「早期警告」の仕組みが無いため、万一熱暴走が起きた場合、OS側に一切の予兆ログを残さずハードウェア保護回路が直接介入してシステムを落とす可能性があります。これは今回の「無痕跡」という特徴と綺麗に整合します。

念のため実測もしてみました。ACPIのサーマルゾーンをセンサーコマンドで確認したところ、最軽量モデル1台だけといった軽い負荷でも、ボード/SoC系のセンサーが83.5℃まで上昇する場面を観測しました（その後アイドルで48〜50℃まで下がることも確認しており、ずっと高止まりしているわけではありません）。一方でGPU管理ツール経由のGPU温度は同時刻46〜71℃で推移しており、センサーの種類によって読み取り値にかなりの食い違いがあることも分かりました。

サーマルスロットル発動を示すフラグは "Not Active"、GPU側の熱関連エラーもログ全期間で0件と、「今まさに熱暴走している」ことを示す直接証拠こそありませんでしたが、

OSレベルの温度保護機構が構造的に機能していない
軽負荷でも比較的高い温度に達する傾向がある

の2点から、熱暴走説を有力な仮説の一つに格上げしました。

公式コミュニティも調査する

同じハードウェア（NVIDIA製のGPU搭載開発機）のユーザーフォーラムも当たってみました。

症状がほぼ同一の投稿を発見。NVIDIA担当者が「既知の問題であり修正中」と公式に認めている返信がありました。原因は「CPU/GPU統一メモリ設計により、OOM発生時にカーネルが飢餓状態になり、OOM killerが起動する前にシステム全体が応答不能になる」との説明で、こちらは今回の熱暴走説とは異なる、OOM由来の完全フリーズという別のメカニズムです。本環境でもOOM killer発動の痕跡自体は無いため症状の一部とは整合しますが、確定情報ではありません。
別の類似ケースでは、NVIDIA担当者が公式診断ツール（ハードウェア一式の負荷試験ツール）の実行結果とクラッシュ直前のカーネルログの提出を求めており、あるユーザーのケースでは実際に電源関連の負荷試験で異常を検出しハードウェア交換（RMA）に至った例もありました。

つまり、公式に認識されている既知の不具合だけでも複数の候補メカニズムがあり、この時点では単一の原因に断定できないという状況でした。OSの最新アップデート適用状況も確認しましたが、確認できる範囲では既に最新版が適用済みで、今すぐ打てる追加対策ではありませんでした。

打てる手を打つ：GPUクロックの意図的な制限

ハードウェア診断ツールの実行には副作用が大きすぎました（Secure Bootの無効化という物理操作が必要な上、実行中は全サービスを止める必要があり、最大3時間かかります）。実施タイミングを選ぶ必要があったため、これは保留にしつつ、まず試せる緩和策としてGPUのグラフィックスクロック上限を意図的に引き下げることにしました。

この対策を検討する際、同じハードウェア（GB10搭載機）で類似の突然電源断に遭遇し、独自に調査されていた方の記事（DGX Spark（ASUS Ascent GX10）の電源断調査 - note）を参考にしました。この記事は非常に示唆に富んでいて、「熱暴走」ではなく「瞬間的な電力スパイクによる過電流保護の作動」という、より精密な仮説にたどり着いています。具体的には、正常な日と故障が起きた日でSoC温度はほぼ同等（約96℃前後）だった一方、GPUの電力ピークは故障日で95W、正常日で82〜85Wと明確に異なっていたそうです。つまり温度がしきい値を超えていなくても、瞬間的な電力ピークが保護回路のしきい値を超えて落ちるという、温度計だけを見ていては気づけないメカニズムです。GB10では電力制限（nvidia-smi -pl）そのものが効かないため、GPUクロックの上限を下げることで瞬間最大電力の天井を物理的に削減する、という対策の理屈もこの記事から得ました。

自環境ではSoC温度とGPU電力の両方を同時に高解像度で記録できていなかったため「熱」か「電力スパイク」かを完全に切り分けられてはいませんが、対策コマンド自体は両仮説で共通（nvidia-smi -lgcによるクロック上限の引き下げ）だったため、この方針で緩和策を実施することにしました。

sudo nvidia-smi -lgc 300,2100

既定の上限（3003MHz）から2100MHzへ制限し、発熱・発生頻度への影響を観察する実験です。クロック制限はホスト再起動で消えてしまうため、systemdのoneshotユニットとして恒久化しました。

[Unit]
Description=GPUクロック上限を固定（無痕跡フリーズ調査・熱暴走仮説の切り分け用）
After=nvidia-persistenced.service
Wants=nvidia-persistenced.service

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -lgc 300,2100
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

導入後、実際のグラフィックスクロックが2405MHz→2073MHzまで低下していることを確認しました。副作用として推論スループットの低下は避けられませんが、フリーズ頻度への効果とのトレードオフとして許容する判断です。

現在の状況

クロック制限を導入してから、現在まで約4日間、一度もフリーズせず連続稼働しています。導入前は数時間〜1日強の間隔で発生していたことを考えると、明確な改善です。

ただし正直に言うと、これは「治った」と断定できる状態ではありません。

熱暴走、あるいは前述の電力スパイクによる過電流保護が真因なら、クロックを下げたことでピーク発熱・ピーク電力の両方が抑えられ発生しなくなった、という説明は筋が通ります
一方で、そもそも発生間隔が数日〜3週間とバラつきが大きいため、「まだ再発していないだけ」という可能性も否定できません

現状は「有力な仮説があり、対応する緩和策を打ったところ、体感できる改善が見えている」というフェーズです。
これ以上この記事が更新されなかったら…それは「その後再発はしなかった」ということであり、そうなってくれることを祈るばかりです。

以上、「止まっちゃう事件」の記録として。
ありがとうございました。