Spot GPU Instances in 2026: How Much You Save (and What Breaks)

Spot GPU instances are the same hardware as on-demand, sold at a discount because the provider can take them back with almost no warning. That trade shows up differently on every cloud: GCP will cut an H100's price by roughly two-thirds and usually has the capacity to back it up, Azure discounts it even more steeply on paper but the capacity to actually claim that price is scarce, and AWS mostly won't sell you spot H100 capacity in the first place. Here is what each provider actually charges for spot GPU instances right now, where the discount math breaks down, and a framework for deciding which workloads belong on spot instead of on-demand or reserved.

How Spot GPU Instances Are Priced

Spot pricing isn't a fixed discount tier you opt into. It's the provider selling whatever GPU capacity it isn't currently using for on-demand or reserved customers, at whatever price clears that surplus. When demand for on-demand and reserved capacity rises, the spot pool shrinks and prices climb; when it falls, spot gets cheap fast. There's no published rate card, and the price you see this morning can be gone by afternoon.

The mechanic that makes this workable for the provider, and risky for you, is reclaim-anytime. On-demand and reserved instances run until you stop them. A spot instance runs until the provider needs the capacity back, at which point it sends a short interruption notice and takes the machine, whether or not your job is finished. You're not bidding against other customers in most modern implementations (AWS retired price-based bidding for the current spot model), you're renting surplus at the provider's current spot price and accepting that the rental can end at any moment. Teams chasing the deepest possible discount can still route jobs to whichever provider's spot pool is cheapest at any given hour; our GPU spot instance arbitrage guide covers the bidding strategy and cross-cloud scheduling mechanics that this post doesn't get into.

That's the entire trade: a real discount off the same hardware, in exchange for giving up the guarantee that your job finishes uninterrupted. Whether that trade is worth it depends on how deep the discount actually is on your provider, and whether your workload can absorb a mid-run interruption without losing much. Both questions have very different answers depending on where you rent.

Spot Discounts Across AWS, GCP, Azure, and Neoclouds in 2026

The honest answer to "how much do spot GPUs save" is: it depends which cloud you're asking about, and the spread between providers is bigger than most buying guides let on.

\*Azure's discount is steep on paper, but ND H100 v5 Low Priority VMs are only consistently available in East US and South Central US. Southeast Asia and UK South frequently show zero spot capacity for this SKU, per our own Azure H100 pricing breakdown.

Pricing fluctuates based on GPU availability and region. Spheron figures above are a live pull from the Spheron GPU offers API on 30 Aug 2026 and may have changed by the time you read this. AWS and Azure figures come from our own provider pricing breakdowns, linked below; GCP figures come from our Google Cloud A3 H100 pricing analysis, independently sourced from Google's own pricing pages. Check current GPU pricing → for live rates before you budget against any of these numbers.

Two things jump out. First, the neocloud on-demand rate is already close to, or below, the hyperscaler spot rate. Spheron's cheapest available H100 SXM5 on-demand pool runs as low as $3.38/hr, which undercuts GCP's H100 spot at $3.69/hr, without any interruption risk at all. Second, the deepest discount on paper isn't necessarily the one you can use: Azure's ~70-80% off looks like the best deal in the table, but it's gated behind regional spot capacity that's frequently just not there, while GCP's shallower ~66% off is the one you can reliably book.

Why AWS P5 Spot Barely Exists in Practice

AWS technically supports spot pricing for P5 instances. In practice, it's close to a non-option for H100 workloads. AWS allocates the bulk of P5 capacity to on-demand and reserved (including Capacity Block) purchasers first, and only releases what's left over to the spot pool. Demand for H100 capacity has consistently outstripped that leftover supply, so P5 spot availability is thin to nonexistent in most regions and most weeks. We cover the full P5, P5e, and P5en breakdown, including why the June 2025 price cut didn't fix this, in our AWS H100 pricing guide.

The practical result: if your cost model assumes you can grab AWS H100 spot at a steep discount whenever you need it, that assumption will fail the first time you actually try to launch. Teams that need AWS-adjacent spot economics for H100-class training generally end up looking at neoclouds instead, where on-demand rates are already close to what AWS would charge on spot, if AWS had spot capacity to sell.

Neocloud Spot vs Hyperscaler Spot: Why the Discount Math Differs

The size of a provider's advertised spot discount tracks how much surplus capacity it's carrying, not some fixed policy. AWS markets spot savings of up to 90% off on-demand for general-purpose compute, where spare capacity is abundant across hundreds of instance types. GPU capacity is a different market: it's the resource everyone wants, so there's rarely a large surplus sitting idle. That scarcity shows up two different ways on the two hyperscalers. AWS's P5 pool is thin enough that spot barely exists at any price. Azure's ND H100 v5 Low Priority pool does exist and is steeply discounted on paper, but it's concentrated in two regions (East US, South Central US), so the discount is only real if your workload can run where the capacity happens to be.

GCP is the outlier among hyperscalers: A3 H100 Spot VMs (the current name for what GCP used to call preemptible instances) are discounted by roughly two-thirds and, unlike AWS or Azure, that capacity is generally there when you go to use it. GCP's own documentation carries the same caveat every provider's does: rates and availability vary by region and change without much notice, so check GCP's Spot VM documentation before you build a cost model around any single snapshot.

Neoclouds land in a different spot on this curve entirely because the pricing mechanism is different. A marketplace that aggregates supply across many data center operators, the way Spheron does across 5+ providers, isn't drawing spot capacity from one hyperscaler's leftover pool. It's pricing spot as a genuinely separate, lower-cost tier of the same aggregated supply, which is why the on-demand-to-spot gap on a neocloud tends to sit in the 25-50% range rather than swinging between "nearly free" and "doesn't exist" the way hyperscaler spot does.

What Breaks: The Hidden Cost of Interruptions for Training vs Inference

The discount is only half the decision. The other half is what happens in the seconds after your instance gets reclaimed, and that cost is not the same for every workload.

Notice windows are short everywhere. AWS issues a Spot Instance interruption notice exactly two minutes before EC2 stops or terminates the instance: "A Spot Instance interruption notice is a warning that is issued two minutes before Amazon EC2 stops or terminates your Spot Instance." Google Cloud gives Spot VMs a best-effort 30 seconds by default, extendable to 120 seconds with an explicit flag. Azure Spot VMs get a minimum of 30 seconds via a Preempt signal on the instance metadata endpoint. None of these windows are long enough to do anything except trigger a pre-written shutdown routine that's already running and polling; you cannot build the response after the notice arrives.

Interruption frequency is real but uneven. AWS's own data, aggregated by nOps, shows monthly interruption rates that vary sharply by region: 9.95% in us-east-1 against 0.48% in us-west-1, with instance-type variation from roughly 3% to over 31% on top of that. The takeaway isn't "spot is unreliable," it's that reliability depends entirely on which region and instance family you land on, and that variance is invisible until you check.

Training absorbs interruptions better than inference. A checkpointed training job loses at most the progress since its last save, then resumes. That's a bounded, predictable cost you can budget for: pick a checkpoint interval, know the maximum minutes you'll ever lose. Live inference has no equivalent recovery path. A request in flight when the reclaim hits either times out or returns an error to whoever's waiting on it, and there's no "resume from checkpoint" for a dropped API call. That asymmetry is why this guide, and most spot-buying advice generally, treats training and batch inference as spot-friendly while treating synchronous production inference as the workload spot is wrong for.

The restart tax compounds with job length. A short job with a 15-20 minute restart overhead (re-provisioning, environment setup, checkpoint load) barely notices one interruption. A multi-day training run that gets interrupted three or four times pays that overhead repeatedly, and if your recovery path has bugs you've never actually exercised, the first real interruption costs far more in debugging time than the spot discount ever saved. Test the recovery path before you trust it in production, not during your first real interruption.

Workloads That Are (and Aren't) Safe to Run on Spot GPU Instances

Route workloads by fault tolerance, not by which GPU they need.

Good fits for spot:

• Checkpointed training and fine-tuning runs, where a resume-from-checkpoint path is tested and working
• Batch inference and offline evaluation jobs (embedding generation, dataset scoring, model comparison sweeps)
• Hyperparameter search and experimental runs where a failed trial just gets relaunched
• CI/CD-style workloads: nightly benchmark runs, regression test suites, data preprocessing pipelines

Bad fits for spot:

• Synchronous production inference APIs where a user is waiting on the response
• Any multi-day training run without checkpointing already built and tested
• Workloads under a compliance regime (HIPAA, FedRAMP, EU AI Act audit requirements) that expects documented, stable compute
• Jobs where restart overhead runs above roughly 15% of total runtime; a 2-hour job with a 20-minute restart tax will lose money to spot on any provider with more than one interruption

If you're unsure which category a given workload falls into, our serverless vs on-demand vs reserved GPU comparison walks through the decision criteria in more depth before you even get to spot as an option.

Checkpointing and Fault Tolerance, in Brief

The minimum viable setup for training on spot is: checkpoint on a fixed step interval short enough that losing progress since the last save is acceptable, store checkpoints somewhere that survives the instance being terminated (not local disk), and write a shutdown hook that starts saving the moment the interruption notice arrives rather than waiting for the process to be killed. For inference-adjacent batch jobs, the equivalent is idempotent task processing with a queue that redelivers on failure, so a reclaimed instance just means the in-flight tasks get picked up by whichever worker comes online next.

That's the whole shape of it in three sentences, and it's enough to reason about the trade-off in this guide. It is not enough to actually implement well. FSDP and ZeRO-3 checkpointing have real gotchas around partial writes and step-locking that are easy to get wrong under time pressure, which is exactly the situation a 30-second preemption notice puts you in. For the full implementation, see our spot GPU training resilience and checkpointing guide rather than trying to reconstruct it from a summary. And if you want proof this works at real scale rather than just in theory, our 70B model spot training case study documents a 12-person team that finished a full fine-tuning run for $11,200 against a $41,500 on-demand baseline, a 73% reduction, using a hybrid spot-and-dedicated strategy with the checkpointing pattern above.

On-Demand vs Spot vs Reserved: A Simple Cost Framework

Skip the GPU-model-by-GPU-model decision and route by workload shape instead. The three billing modes solve three different problems, not three price points on the same problem.

The reserved-vs-spot line depends on which provider you're comparing, and it's driven by availability as much as by discount depth. On a cloud where spot capacity for your GPU is scarce or regionally locked, like Azure's ND H100 v5 Low Priority pool, a workload running most hours of the day is often better served by a 1-year or 3-year committed-use rate (up to roughly 60% off at longer terms) than by chasing spot capacity that may not be there when you need it. On a cloud with steep spot discounts and reliable availability, like GCP's roughly 66% off, spot stays the cheaper option even at high utilization, as long as the workload can actually tolerate the interruption risk.

For teams that don't want to manage that provider-by-provider math themselves, Spheron collapses it into a single choice per workload: on-demand for anything user-facing, spot for anything fault-tolerant and checkpointed, reserved for anything running predictably at scale, all against the same transparent, per-minute-billed pricing rather than a rate card that changes shape by provider. Our GPU cost optimization playbook covers the rest of the levers, right-sizing, egress, idle shutdown, that stack on top of picking the right billing mode.

Cost-sensitive, fault-tolerant workloads are exactly what spot GPUs were built for, and Spheron's per-minute billing means you're never paying for a full hour you didn't use.

On-demand H100 → | B200 GPU pricing → | Start on Spheron →