Cloud GPUの消し忘れを防ぐには？アイドル検知と予算上限を二重化する

Cloud GPUで最も起きやすい損失は、高いGPUを選んだことではない。作業が終わったのに、計算資源、保存領域、予約、通信のどれかが残ったままになることだ。

ブラウザを閉じたこと、SSHを切ったこと、画像生成の画面を閉じたことは、停止の証明にならない。RunpodではPodの計算と保存が別に扱われ、Vast.aiでもインスタンスが存在する間は保存費用が続くことがある。AWSも停止したEC2のインスタンス時間は止まるが、EBS保存領域は別に課金される。

先に「何が残るか」を分ける

利用中のサービスで、次の表を埋める。サービス間で言葉が違うため、停止ボタンの名前を写すだけでは足りない。

項目	動いているとき	停止後	削除後	自分の確認方法
GPU・CPU計算	課金単位を確認	止まるか確認	止まる	請求画面と実行状態
コンテナ・一時ディスク	課金・消去条件を確認	残るか確認	消えるか確認	保存先の一覧
永続ボリューム	容量課金を確認	課金継続の有無	削除で止まるか	ボリューム一覧
通信・公開IP	転送・IPの条件を確認	残るか確認	削除で止まるか	ネットワーク一覧
予約・割引契約	契約額を確認	停止しても残るか	契約終了まで残るか	契約・請求画面

空欄がある状態では、自動停止を有効にしても「何を止めたか」が分からない。

停止判断を利用率だけで行わない

GPU利用率が低いからといって、すぐ停止してよいとは限らない。学習、アップロード、チェックポイントの保存、夜間ジョブの待機などでは、利用率だけでは区別できない。

次の四条件を組み合わせる。

確認項目	停止候補	停止しない条件
GPU利用	一定時間ほぼ動いていない	実行中ジョブがある
接続	SSH・Jupyter・Web接続がない	作業者が一時離席中と明示した
ジョブ	スケジューラに待機・実行がない	指定時刻の実行予約がある
保存	未保存出力がない	出力の同期・バックアップ中

この表は自動化の仕様書ではない。サービスごとに権限、停止API、保存の意味が違うため、最初は手動確認と小さな予算上限から始める。

予算通知は停止機能と別に置く

AWS Budgetsは、実績または予測の閾値で通知やアクションを設定できる。ただし、通知が届いたことは、すべてのGPUが止まったことを意味しない。通知先、停止担当者、停止後の確認手順を分ける。

最初の一週間は、次のように低く置く。

1. 日次の費用通知を受ける
2. 月次上限より低い警戒額を設定する
3. 警戒通知を受けた人が、GPU・保存・予約を別々に確認する
4. 終了後に「止めた項目」と請求画面を記録する

Google Cloud、AWS、Runpod、Vast.aiのいずれも、料金単位、地域、サービス、契約形態で表示が変わる。一般論の金額ではなく、自分のアカウントの状態で表を完成させる。

Cloudを続けるかPCを買うかは別の判断

毎日同じ作業を長時間続けるなら、Cloud GPUの運用費を把握した後でローカルPCとの比較をしてよい。ただし、消し忘れ対策ができていない請求額をCloudの通常費用として使うと、比較がゆがむ。

ローカルAI向けBTO PCの選び方では、手元にGPUを置く場合の構成を扱っている。Cloudの請求を比較へ使う前に、まずアイドル費用を除いた実稼働分を記録する。

停止ボタンを一回押すことではなく、計算・保存・予約の三つが止まったと確認できることを、Cloud GPU運用の完了条件にする。