Spot GPUで学習が消える理由と自動リカバリの設計チェックリスト

AI モデルの学習ジョブを AWS や GCP の GPU インスタンスで動かしているエンジニアに向けた内容です。今回は「Spot インスタンス（クラウド事業者の余剰リソースを割引価格で借りられる仕組み）」を使った学習パイプラインで、なぜ突然ジョブが止まるのか、事前に何を確認すればよいかを整理しました。

Spot GPU はオンデマンド（常時起動を保証する通常課金の仕組み）に比べて最大 90% 前後安くなる場合があります。AWS は EC2 Spot Instances で最大 90% オフ、Google Cloud も Spot VM で最大 91% の割引があると案内しています。この価格差だけを見て導入すると、学習が途中で消えて時間とコストを失う落とし穴にはまりやすくなります。

何が起きるか：チェックポイントなしの学習が丸ごと消える

Spot インスタンスはクラウド事業者側の都合で、いつでも回収（reclaim）される可能性があります。AWS は Spot の中断通知を「2分前」に出すとしていますが、これは保証（best-effort）ではなくベストエフォートです。

Google Cloud の Spot VM も同様に、いつでもプリエンプト（強制停止）される可能性があり、シャットダウンまでの猶予もベストエフォートです。つまり「必ず2分ある」という前提でコードを書くと、通知が届かないケースで想定が崩れます。

具体的に何が起きるかというと、学習スクリプトが torch.save() などでモデルの状態を保存していない場合、インスタンス回収と同時に学習の進捗がすべて失われます。A100 や H100 で数時間かけた学習が、割引価格の分を上回るロスになるケースも起こり得ます。

なぜ起きるか：安さの裏にある「余剰キャパシティ」という前提

Spot 価格が安い理由は、クラウド事業者が本来空いている（オンデマンド需要に使われていない）GPU キャパシティを売っているからです。需要が戻れば、その分を優先的に取り戻す必要があるため、割引と回収リスクはワンセットになっています。

この構造を理解せずに「単にオンデマンドより安いから」という理由だけで Spot を選ぶと、ワークロードの性質とインスタンスの性質が噛み合わなくなります。ここが落とし穴の根本原因です。

さらに原因を分解すると、次の3つの要素が重なって初めて「Spot が高くつく」事態になります。

チェックポイント（学習途中の状態を定期保存する仕組み）が実装されていない
再起動を自動化するリスタート処理（再開ロジック）がない
永続ストレージ（インスタンスが消えてもデータが残る保存領域）を使っていない

この3つのうち1つでも欠けていると、中断が発生した瞬間に「安さ」が「手戻り」に変わります。逆にこの3つが揃っていれば、Spot の中断は単なる「一時停止」として扱えます。

自分のプロジェクトが該当するか確認する方法

まず、現在使っているインスタンスの種別を確認します。AWS の場合は次のコマンドで、実行中インスタンスの Lifecycle（起動形態）を確認できます。

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{ID:InstanceId,Life:InstanceLifecycle}' \
  --output table

Life の列が spot になっていれば、そのインスタンスは中断リスクを持っています。空欄であればオンデマンドです。

次に、学習コードが再開可能かどうかをチェックします。以下の観点で自分のコードを見直してください。

学習ループの中で一定エポックごとにモデルの重みとオプティマイザの状態を保存しているか
保存先がインスタンスローカルディスクではなく S3 や GCS などの永続ストレージになっているか
スクリプト起動時に「保存済みチェックポイントがあれば読み込んで続きから始める」処理があるか
ジョブ管理側（Kubernetes の Job やジョブキューなど）が失敗時に自動リトライする設定になっているか

この4項目のうち、2つ以上が「ない」に該当するプロジェクトは、Spot 移行によってコスト削減どころか手戻りコストが増える可能性があります。まずオンデマンドのままで様子を見るか、対策を先に実装する方が安全です。

対策の手順

手順1: チェックポイント間隔を決める 学習1エポックあたりの時間と、許容できる「やり直し時間」を計算します。たとえば1エポック10分なら、5〜10分おきの保存が目安になります。

if step % checkpoint_interval == 0:
    torch.save({
        "model": model.state_dict(),
        "optimizer": optimizer.state_dict(),
        "step": step,
    }, checkpoint_path)

手順2: 保存先を永続ストレージに向ける インスタンスローカルの /tmp などに保存すると、インスタンス自体が消えたときにチェックポイントも失われます。S3 や GCS のバケットに直接、または定期同期で書き出す設計にします。

手順3: 中断通知を監視するプロセスを仕込む AWS では、インスタンスメタデータの /latest/meta-data/spot/instance-action を定期的にポーリングすることで、中断予告を検知できます。検知したら即座にチェックポイントを保存する処理を挟みます。

手順4: 再起動時の自動復帰を用意する 起動スクリプトの先頭で、永続ストレージ上の最新チェックポイントを確認し、あれば読み込んで学習を再開する分岐を入れます。Kubernetes を使っている場合は Job の restartPolicy と組み合わせると、インスタンス再確保後の再開が自動化できます。

手順5: ワークロードの種類で使い分ける チェックポイント可能な学習、ハイパーパラメータ探索、リトライ可能なバッチ推論は Spot が向いています。逆に本番推論、デモ環境、締め切りが厳しいファインチューニング、対話的に使うノートブック環境はオンデマンドの方が安全です。

中断リスクそのものが導入のブロッカーになっている場合は、Spot 以外にも割安なオンデマンド GPU プランを提供するサービスを比較検討する余地もあります。Hyperstack や Novita のような GPU 特化型プロバイダーは、Spot と通常課金の中間的な価格帯を持つプランを公開しているため、料金ページを見て現在の相場を確認しておくと判断材料が増えます。

Spot の割引率だけでなく「チェックポイント・永続ストレージ・自動リスタート」の3点が揃っているかで、実質コストが決まります。

まとめ

Spot GPU は価格だけ見れば魅力的ですが、実際のコストは中断への耐性で決まります。まず aws ec2 describe-instances などで自分のインスタンスが Spot かどうかを確認してください。

学習コードにチェックポイント保存・永続ストレージへの書き出し・再開ロジックの3点が揃っているか、上記のチェックリストで洗い出しておくと安心です。ハイブリッド構成として、安定したベースラインをオンデマンドで確保しつつ、伸縮する追加分だけ Spot にするという分け方も現実的な選択肢です。

プロジェクトの性質に応じて、本番推論やデモはオンデマンド、リトライ可能なバッチ処理は Spot、という基準で使い分けを見直してみてください。