ローカルLLM実行系を回し続ける人にとって怖いのは、プロセスが落ちる障害だけではありません。GPU管理APIもモデル一覧の疎通確認も正常を返したまま、成果物だけが増えない状態があります。某所ラボでは、この状態を約16時間見逃し、機会損失は約2,500処理になりました。無言停止の経緯はGPU無言停止の記録に譲り、ここでは検知器をどう組んだかだけを扱います。
状態・疎通・進捗を分ける
死活監視は、落ちたものに気づくために必要です。Uptime Kumaで死活監視を検証した記録のように、Downと通知失敗を実際に確認しておく価値はあります。
ただし、今回のように「生きているが働いていない」状態では、状態監視と疎通監視だけでは足りません。見るべき値を、ノードごとの処理カウント、すなわち単位時間あたりの成果物件数に切り替えました。
判定に使うのは前回値との差分だけです。処理カウントが増えていれば正常、増分ゼロが続けば症状ありと扱います。プロセスの生存、ポートの開放、モデル一覧への応答は、この異常判定の入力に入れません。今回はそれらが正常だったためです。
20分のゼロ増を15分間隔で確認する
処理カウントは15分ごとに読み、ゼロ増が20分続いたらアラート対象にします。ポーリング間隔とゼロ増アラート窓を合わせると、最悪検知レイテンシは最大35分です。
16時間の停止を最大35分に縮められるなら、まず実用になる。もっと短くすべきかは、各環境の処理頻度と、監視負荷・通知量を測って決める領域です。ここで重要なのは、監視対象を「正常そうに見える部品」ではなく、「実際に増えるべき成果物」に置くことです。
75秒の原因シグネチャでロード待ちを除外する
ゼロ増は症状であって、原因ではありません。モデルのロード待ちや重いジョブでも、短時間は成果物が増えないことがあります。そこで自動復旧には、ゼロ増に加えてwedgeシグネチャを要求します。
今回のwedgeシグネチャは、「疎通確認は即答する」ことと、「小さな生成要求が75秒を超えても返らない」ことの組み合わせです。
閾値を75秒にしたのは、感覚ではありません。実測では、正常なwarm-loadは10〜20秒で完了しました。一方、wedge時の生成要求は600秒以上、上位タイムアウトまで一度も返りませんでした。正常側と異常側の間に十分な谷があったため、その谷に75秒を置いています。
この決め方は数値そのものより移植性があります。別のGPU、別のモデル、別の処理系に75秒をそのまま持ち込む根拠はありません。自分の環境で「正常な遅さ」と「故障時の遅さ」を実測し、その間にある谷へ閾値を置くべきです。
原因一致時だけ自動復旧する
ゼロ増とwedgeシグネチャの両方がそろったときだけ、GPUノードのrebootを自動トリガします。
コンテナのrestartやGPU付き再作成は、2回試して2回とも復旧しませんでした。そのため、この障害に限っては軽い復旧を先に試す段を設けていません。手順を短くしたのではなく、効かなかった手段を自動復旧経路から除いた設計です。
ただしrebootは不可逆側の操作です。導入時には人の承認を挟み、対象ノードと発動条件を限定しました。当時の対象は当該ジョブ専有のGPUノードです。共有ノードに同じ設計をそのまま置いてはいけません。利用者や他の処理を巻き込む環境では、停止許容度、退避、承認経路を別に設計する必要があります。
2時間のデバウンスで再起動ループを防ぐ
自動rebootは、同一ノードに対して2時間に1回までとしました。これがデバウンスです。
再起動しても直らない別種の障害に対して、無制限の自動復旧は再起動ループになります。静かに止まる状態を、うるさく壊れ続ける状態へ変えるだけです。2時間以内に再度条件が成立した場合は、復旧を繰り返さず人間へ通知します。
監視の役目は、すべてを自動で直すことではありません。自動化が安全に扱える範囲を決め、それを越えたら判断を人へ戻すことです。
死活監視・ゼロ増通知・条件付き復旧を比べる
| 選択肢 | 検知できる範囲 | 誤検知・復旧リスク | 導入条件 | 見送る条件 |
|---|---|---|---|---|
| 死活・疎通監視だけ | 導入しやすく、停止や応答不能には気づける | 正常応答のまま処理が止まる障害を見逃す | 落ちれば必ず応答不能になる単純なサービスを運用する人 | バックグラウンド処理やGPUジョブの成果物を待つ人 |
| ゼロ増アラートのみ | 処理停止を直接捉えられる | 重い正常処理やロード待ちを異常と誤認しうる | まず可視化と通知を追加したい人 | 自動復旧まで安全に任せたい人 |
| ゼロ増＋原因シグネチャ＋デバウンス | 偽陽性を抑えつつ、自動復旧の暴走も抑えられる | 成果物と正常・異常時の時間分布を実測する必要がある | 無人実行時間が長く、停止の機会損失が大きい人 | 成果物を数えられず、再起動の影響を許容できない共有環境 |
購入する製品より先に、監視の対象を選ぶ話です。既存の監視基盤を捨てる必要はありません。死活監視は「死んだら気づく」層として残し、進捗監視を「働いていないことに気づく」層として重ねます。ネットワーク側の異常も処理停滞に見える場合があるため、通信負荷が気になる環境ではMAP-Eポート枯渇の記録も切り分けの参考になります。
通知経路も監視対象にする
異常を検知しても、通知が届かなければ運用上は沈黙と同じです。通知は常設の通知経路へ流し、その経路自体が生きているかを別途テストします。沈黙は正常の証拠ではありません。
自分の環境へ移す前の確認
- 自分の系で、単位時間あたりに増える成果物を1つ挙げられるか。
- その成果物のゼロ増を、何分で異常とするか決めたか。
- ロード待ちや重い正常処理と、故障時の遅さを実測して分離できるか。
- 自動復旧を何回まで許し、上限後に誰へ通知するか決めたか。
- 通知経路が生きていることを最後に確認した時点を把握しているか。
進捗監視は、ゼロ増検知だけでは完成しません。ゼロ増で症状を拾い、原因シグネチャで誤作動を避け、デバウンスで自動復旧を止められるようにする。この3点がそろって初めて、無言停止を扱える実装になります。
この検証を回している環境
この検証は、自宅の常設ラボ（使い捨てVM/LXCを回す母艦＋GPU＋VLAN分離ネットワーク）で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。
ラボ構成のまとめを見る →
