# Spot/preemptible GPUの中断前提設計とcheckpoint経済性 CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-750-spot-preemptible-gpu-checkpoint CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-750-URL-FF704E292777, EVD-EA-750-URL-CE9D11064147, EVD-EA-750-URL-C84E54048392, EVD-EA-750-URL-8F83DA98D931, EVD-EA-750-URL-BBD568FE8874, EVD-EA-750-URL-9EE8C8EDE198, EVD-EA-750-URL-269403C307E6, EA-750-CURRENT-APPROVAL, EA-750-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-750-UNKNOWN-01 OPS_IDS: none ## Summary 「Spot/preemptible GPUは中断と再取得待ちを通常系として設計し、周期checkpointを主手段、provider通知をbest-effortの追加退避signalとして扱う。採否は時間単価だけでなく、失われるcompute、checkpoint I/O、restart/reload、capacity再取得、fallback、期限リスクを含む実効費用で判断する。」 ## Current judgment 「Spot/preemptible GPUは中断と再取得待ちを通常系として設計し、周期checkpointを主手段、provider通知をbest-effortの追加退避signalとして扱う。採否は時間単価だけでなく、失われるcompute、checkpoint I/O、restart/reload、capacity再取得、fallback、期限リスクを含む実効費用で判断する。」 ## Scope Spot/preemptible GPUの中断前提設計とcheckpoint経済性 ## Confirmed ## UNKNOWN - EA-750-UNKNOWN-01: - 対象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 ## Evidence - EVD-EA-750-URL-FF704E292777 (RESEARCH): AWS EC2 User Guide, Spot Instance interruption notices: — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html - EVD-EA-750-URL-CE9D11064147 (RESEARCH): AWS EC2 User Guide, Best practices for EC2 Spot: — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html - EVD-EA-750-URL-C84E54048392 (RESEARCH): AWS EC2 User Guide, Initiate a Spot Instance interruption: — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/initiate-a-spot-instance-interruption.html - EVD-EA-750-URL-8F83DA98D931 (RESEARCH): Google Cloud Compute Engine, Spot VMs: — https://docs.cloud.google.com/compute/docs/instances/spot - EVD-EA-750-URL-BBD568FE8874 (RESEARCH): Google Cloud Compute Engine, Create and use Spot VMs: — https://docs.cloud.google.com/compute/docs/instances/create-use-spot - EVD-EA-750-URL-9EE8C8EDE198 (RESEARCH): Microsoft Azure Architecture Center, Build workloads with Azure Spot Virtual Machines: — https://learn.microsoft.com/azure/architecture/guide/spot/spot-eviction - EVD-EA-750-URL-269403C307E6 (RESEARCH): Microsoft Azure Virtual Machines, About Azure Spot Virtual Machines: — https://learn.microsoft.com/azure/virtual-machines/spot-vms - EA-750-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-750-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits 最大の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可能な世代だけを確定します。 ## Failure / limits 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で継続更新します。 ## 主要claim 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 最大の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可能な世代だけを確定します。 ## 具体的control / implementation implication 1. workloadごとに `checkpoint_bytes`, `checkpoint_write_seconds`, `checkpoint_load_seconds`, `restart_seconds`, `expected_reacquisition_seconds`, `checkpoint_interval_seconds`, `deadline`, `fallback_policy` を計測値として持ちます。 2. 周期checkpointをprimary durability mechanismとし、Spot interruption/rebalance/preemption signalでは新規batch投入停止、最新state flush、final checkpoint attempt、worker drainを実行します。 3. checkpointはgeneration単位でimmutableに保存し、全shard/rankの完了後にcommit markerを確定します。復旧時は最新時刻ではなく、完全性検証済みの最新generationを選びます。 4. interruption handlerはproviderごとのnotice contractを分離します。AWS 2-minute notice、GCP 120秒/0秒設定とbest-effort shutdown、Azure Scheduled Eventsを同じ固定timeoutとして実装しません。 5. replacement strategyを `same_pool -> alternate_zone/pool -> alternate GPU SKU -> standard/on-demand fallback -> queue/defer` のように明示し、各段階の最大待機時間とcost ceilingを定義します。 6. 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します。 7. 経済性は少なくとも次で比較します。`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適格とします。 8. checkpoint intervalは固定値を全jobへ配らず、checkpoint costとinterruption exposureを計測してworkload class別に設定します。長時間job、大規模state、高い再取得待ちでは短縮余地を評価し、checkpoint I/Oがtraining throughputを損なう場合は非同期/増分checkpoint等を検討します。 9. 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の既定値にしません。 ## counterevidence / limitations 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で継続更新します。 ## OPEN_UNKNOWN - 対象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 ## SAFE_WORDING 「Spot/preemptible GPUは中断と再取得待ちを通常系として設計し、周期checkpointを主手段、provider通知をbest-effortの追加退避signalとして扱う。採否は時間単価だけでなく、失われるcompute、checkpoint I/O、restart/reload、capacity再取得、fallback、期限リスクを含む実効費用で判断する。」 ## Source / provenance locators - 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 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.