GMKtec EVO-X2 ローカルLLM GPU ハング 検知

結論：GMKtec EVO-X2でローカルLLMを無人運用するなら、nvidia-smiが正常かではなく、一定時間に処理完了数や成果物が増えたかでGPUハングを検知します。GPUが見え、プロセスやAPIが生きていても、生成だけ返らず進捗が止まることがあるためです。EVO-X2の64GB構成はCPU・GPU・VM・モデルで共有する容量です。LLMとVMを併用する場合ほど、動作確認と進捗確認を分けておく価値があります。

まず確認する症状

• GPUは認識され、利用率やメモリ使用量も読める
• LLMのプロセスは残り、APIのモデル一覧などは応答する
• キューに仕事があり、生成要求を出している
• それでも成果物数、完了ジョブ数、キュー消化数が一定時間増えない

この4つが重なるなら、「GPUが落ちた」のではなく、生きているように見えて処理が進まない状態を疑います。キューが空のときまで異常にしないことが、誤報を減らす前提です。

検知コマンド：完了数を時間差で比べる

監視対象には、処理が完了するたびに更新される件数ファイル、メトリクス、またはジョブ完了数を使います。次は最小の増分判定です。

before=$(cat "$COMPLETED_COUNT_FILE")
sleep "$PROGRESS_WINDOW_SECONDS"
after=$(cat "$COMPLETED_COUNT_FILE")
printf 'completed_before=%s completed_after=%s\n' "$before" "$after"
test "$after" -gt "$before"

testが失敗しただけで即再起動には進めません。キューあり、API疎通あり、完了数ゼロという条件を組み合わせて通知し、復旧を人手にするか自動rebootにするかを決めます。GPU利用率は補助記録にはなりますが、低利用率だけでは待機と故障を分けられません。

状態監視と進捗監視の比較

したがって、EVO-X2をLLM専用にする場合もVMと併用する場合も、監視の最終判定は三段目に置きます。VMの割当、GPU予約、KVキャッシュのピークを含めて64GBに収まるかは別途要確認です。EVO-X2の64GB構成に関する整理も参照してください。

根拠と既存の実測

既存のGPUノードの記録では、NVMLとAPI疎通が正常でも、「16時間、成果物が1件も増えていませんでした。」。対策後は、同型の異常を最大35分で検知する構成へ変更されています。この結果はEVO-X2での実機検証ではありません。ただし、EVO-X2で長時間LLMを回す際にも、「GPUが見える」ことと「生成が進む」ことを別々に確認すべき理由になります。検知条件と復旧判断の詳細はnvidia-smiが正常でもGPUハングを検知する進捗監視、監視の実装例はGPU進捗ゼロを35分以内に検知する監視と自動復旧、古い監視値への対策はPrometheusの古い値を検知する鮮度ゲートの作り方で確認できます。

よくある質問

nvidia-smiが正常ならGPUハングではありませんか？

いいえ。GPU管理APIが応答しても、生成処理が完走する保証にはなりません。完了数または成果物数の増分を確認します。

GPU利用率が0%なら通知してよいですか？

キューが空の待機でも0%になり得ます。キューあり、生成要求あり、完了数ゼロを組み合わせて判定します。

64GBなら監視は不要ですか？

不要にはなりません。64GBはCPU、GPU、VM、モデルで共有する上限であり、容量設計と処理進捗の監視は別の確認項目です。