Spot/preemptible GPUの中断前提設計と途中状態の保存地点経済性

Spot/preemptible GPUは「安価な通常GPU」ではなく、実行中断・再取得失敗・再起動待ちを通常系として扱うcapacity classです。中断通知の猶予はproviderごとに異なり、通知自体がbest-effortである場合もあります。このため、checkpoint設計は通知を受けてから初めて保存する方式だけに依存せず、平常時の周期checkpointと、中断signal受信時のbest-effort final checkpointを組み合わせます。

AWS EC2 Spotは、stop/terminateの前に通常2分のinterruption noticeを出しますが、通知はbest effortであり、hibernateでは2分の猶予なしに処理が始まります。AWSはrebalance recommendationをより早い予兆として利用できる場合がある一方、2分noticeより早く来る保証はないと説明しています。

Google Compute Engine Spot VMは、2026年時点でpreemption notice durationを120秒または0秒として作成時に設定できます。0秒がdefaultで、その場合はdedicated notice delayがなく、その後のbest-effort shutdown periodは最大30秒です。120秒を選ぶ場合はworkload側でpreemption metadataを監視してprogressを保存できます。GPU付きSpot VMもcapacity availabilityに依存し、managed instance groupが再作成を試みてもGPU resourceが利用可能である保証はありません。

Azure Spot VMはcapacityまたはprice条件によりevictされ得て、作成後のavailability SLAはありません。Scheduled EventsのPreempt signalはeviction前の短い猶予を提供しますが、orchestrationは即時evictionやreplacement capacity不足も想定する必要があります。

したがって、Spot GPUの採否は単純な「時間単価の割引率」ではなく、失われるcompute、checkpoint I/O、restart/reload、reacquisition wait、fallback capacity、deadline/SLO penaltyを含むexpected costで評価します。

最大のfailureは、checkpoint intervalをproviderの通知時間と同一視することです。通知がbest-effort、短時間、または0秒設定の場合、checkpoint sizeが大きいtraining/inference stateを中断時だけで安全に永続化できません。通常運転中にdurable checkpointを確定し、通知は追加の最終保存・drain・新規work停止に使います。

第二のfailureは、VM再起動とGPU再取得を同義に扱うことです。Spot VMが停止・削除された後、同じGPU SKU/zoneで直ちにcapacityを再取得できるとは限りません。復旧設計には同一pool再試行だけでなく、別zone/instance type、standard/on-demand fallback、job queue待機、deadline超過時の昇格条件が必要です。

第三のfailureは、checkpointを「書けた」で完了扱いすることです。中断直前のpartial upload、object listの更新順序、distributed rank間の世代不一致により、復旧時に破損または不完全checkpointを掴む可能性があります。checkpoint generation ID、atomic/commit marker、manifest/hash、readbackを用い、resume可能な世代だけを確定します。

• workloadごとに checkpoint_bytes, checkpoint_write_seconds, checkpoint_load_seconds, restart_seconds, expected_reacquisition_seconds, checkpoint_interval_seconds, deadline, fallback_policy を計測値として持ちます。
• 周期checkpointをprimary durability mechanismとし、Spot interruption/rebalance/preemption signalでは新規batch投入停止、最新state flush、final checkpoint attempt、worker drainを実行します。
• checkpointはgeneration単位でimmutableに保存し、全shard/rankの完了後にcommit markerを確定します。復旧時は最新時刻ではなく、完全性検証済みの最新generationを選びます。
• interruption handlerはproviderごとのnotice contractを分離します。AWS 2-minute notice、GCP 120秒/0秒設定とbest-effort shutdown、Azure Scheduled Eventsを同じ固定timeoutとして実装しません。
• replacement strategyを same_pool -> alternate_zone/pool -> alternate GPU SKU -> standard/on-demand fallback -> queue/defer のように明示し、各段階の最大待機時間とcost ceilingを定義します。
• interruption testを定期実施します。AWSはFault Injection Service/EC2 interruption initiation、GCPはpreemption handling test、Azureはevictionを想定したorchestration testを使い、checkpoint生成からrestore、data-loader/sampler/RNG/optimizer state、distributed membershipまでreadbackします。
• 経済性は少なくとも次で比較します。effective_spot_cost = spot_compute_cost + checkpoint_storage_IO + restart/reload_cost + expected_lost_compute + expected_reacquisition_idle + fallback_cost + deadline/SLO penalty。これがstandard/on-demandの総費用・期限リスクを下回るworkloadだけをSpot適格とします。
• checkpoint intervalは固定値を全jobへ配らず、checkpoint costとinterruption exposureを計測してworkload class別に設定します。長時間job、大規模state、高い再取得待ちでは短縮余地を評価し、checkpoint I/Oがtraining throughputを損なう場合は非同期/増分checkpoint等を検討します。
• GPU capacityのavailabilityはquotaと別に監視します。quotaがあってもSpot capacityがあるとは限らないため、launch failure/reacquisition latencyを独立metricとして保存します。

providerの通知時間は契約・機能・設定・termination behaviorに依存します。AWSの2分noticeはhibernateでは同じ猶予を意味しません。GCP Spot VMは120秒noticeを選べる現行機能がありますがdefaultは0秒であり、古い「常に30秒」の理解を固定しません。AzureもScheduled Eventsを受信できることをcapacity保証や自動再開保証と解釈しません。

checkpoint経済性はworkload依存です。短時間batchや再実行が安いstateless inferenceではcheckpoint自体が不要な場合があります。一方、大規模trainingでoptimizer stateが巨大な場合、頻繁なfull checkpointはI/Oとstorage costを増やします。Spot採用を全GPU workloadの既定値にしません。

Spot discountが大きくても、中断率・GPU scarcity・deadlineが厳しい環境ではeffective costがstandard/on-demandを上回り得ます。逆に、短いjob、十分なpool diversification、低いrestore cost、elastic worker構成では中断コストが小さく、Spot比率を高められます。

過去の中断率だけから将来のavailabilityを保証できません。capacityはregion/zone/SKU/timeで変動し、providerのallocation behaviorも変化します。経済性モデルは実測のinterruption/reacquisition telemetryで継続更新します。

• 対象GPU SKU/region/zoneごとの実測interruption rateとreacquisition latency分布
• checkpoint I/Oがshared storageへ与えるpeak負荷とthrottling
• distributed training frameworkごとのrank loss/resume semantics
• GPU SKU変更fallback時のmodel compatibilityとperformance差
• deadline penaltyを含むbusiness costの換算方法
• provider pricing/discount変動を含むbreak-even threshold

「Spot/preemptible GPUは中断と再取得待ちを通常系として設計し、周期checkpointを主手段、provider通知をbest-effortの追加退避signalとして扱う。採否は時間単価だけでなく、失われるcompute、checkpoint I/O、restart/reload、capacity再取得、fallback、期限リスクを含む実効費用で判断する。」

• AWS EC2 User Guide, Spot Instance interruption notices: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html
• AWS EC2 User Guide, Best practices for EC2 Spot: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html
• AWS EC2 User Guide, Initiate a Spot Instance interruption: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/initiate-a-spot-instance-interruption.html
• Google Cloud Compute Engine, Spot VMs: https://docs.cloud.google.com/compute/docs/instances/spot
• Google Cloud Compute Engine, Create and use Spot VMs: https://docs.cloud.google.com/compute/docs/instances/create-use-spot
• Microsoft Azure Architecture Center, Build workloads with Azure Spot Virtual Machines: https://learn.microsoft.com/azure/architecture/guide/spot/spot-eviction
• Microsoft Azure Virtual Machines, About Azure Spot Virtual Machines: https://learn.microsoft.com/azure/virtual-machines/spot-vms