Preemptible vs Spot vs Interruptible: Same Discount, Different Names
A clarifying guide to the terminology around discounted interruptible GPU capacity, explaining what spot, preemptible, and interruptible share and where they genuinely differ.
If you have shopped for cheap GPU capacity across providers, you have met a confusing pile of names: spot, preemptible, interruptible, low-priority, and more. They sound like distinct products, and the inconsistent vocabulary makes the market harder to compare than it should be. In reality they are variations on one idea: a deep discount in exchange for capacity the provider can reclaim when it needs the hardware back. This guide cuts through the naming so you can compare offers on what actually matters rather than on the label a marketing team chose.
The One Idea Behind All the Names
Cloud providers keep spare capacity to absorb demand spikes from full-price customers. Idle hardware earns nothing, so providers rent it out at a steep discount to anyone willing to accept a catch: the provider can take it back, usually with little notice, when a paying on-demand customer wants it. That is the entire concept. Every name in this space describes some flavor of discounted, reclaimable capacity.
Why the Names Differ
The names differ mostly for historical and branding reasons, not technical ones. One provider coined spot around an auction-style market with floating prices. Another used preemptible to emphasize that the instance can be preempted. A third chose interruptible to describe the same behavior in plainer language. The vocabulary diverged, but the underlying bargain is the same.
What Genuinely Differs
While the core idea is shared, the implementation details vary, and those details are what you should actually compare. Treat the name as a label and dig into the mechanics underneath.
| Dimension | What to ask |
|---|---|
| Warning time | How much notice before reclamation? Seconds, or a couple of minutes? |
| Pricing model | Floating market rate, or a fixed discount off on-demand? |
| Maximum runtime | Is there a hard cap on how long the instance can run? |
| Reclaim frequency | How often does this capacity actually get taken back? |
| Restart behavior | Does it stop, hibernate, or terminate when reclaimed? |
Warning Time Matters Most
The single most important practical difference is how much notice you get before the instance disappears. A couple of minutes of warning lets your job checkpoint state and exit cleanly. A few seconds, or no warning at all, means you must checkpoint continuously and assume the instance can vanish mid-step. Design your workload around the shortest warning you will actually receive, not the friendliest one in the catalog.
Floating vs Fixed Pricing
Some discounted capacity uses a floating price that rises and falls with demand, occasionally approaching on-demand rates during crunches. Other providers offer a simple fixed discount off the on-demand price. Floating markets can be cheaper on average but introduce price uncertainty. Fixed discounts are predictable but may be less aggressive. Neither is universally better; it depends on whether your planning values predictability or the lowest possible average.
What These Names Are Good For
Regardless of the label, discounted reclaimable capacity suits the same category of work.
- Checkpointed training. Long runs that save state regularly and can resume after an interruption.
- Batch processing. Throughput-oriented jobs with no tight deadline on any single unit of work.
- Stateless or fault-tolerant serving. Workloads behind a load balancer that can lose a node without user impact.
- Experimentation. Research runs where a restart costs minutes, not a customer.
What they are not good for is unchanged: latency-critical, stateful, single-instance workloads where an unexpected reclaim causes real harm. The discount is compensation for accepting interruption, and if your workload cannot tolerate interruption, no name in the catalog changes that.
Designing for Interruption
Because all of these share the reclamation risk, the engineering response is the same across providers.
- Checkpoint often. Save progress frequently enough that losing the instance costs minutes of recomputation, not hours.
- Make work resumable. Structure jobs so a fresh instance can pick up exactly where the last one stopped.
- Handle the warning signal. Listen for the reclamation notice and use the warning window to flush state and exit gracefully.
- Spread across capacity pools. Diversify across instance types or zones so a single pool reclaim does not take your whole job at once.
Build these once and your workload runs the same whether the provider calls its discounted capacity spot, preemptible, or interruptible. The portability is a side benefit of designing for the shared behavior rather than a specific brand.
Combining Interruptible With Committed Capacity
Discounted reclaimable capacity is not an all-or-nothing choice, and the most cost-effective fleets blend it with steadier capacity rather than relying on it alone. A common pattern is to run a baseline of predictable load on committed or on-demand instances that will not be reclaimed, then burst the variable, interruption-tolerant portion onto spot or preemptible capacity for the deep discount. The committed layer guarantees that critical work always has a home, while the interruptible layer soaks up additional throughput at a fraction of the price.
This layering also hedges against the main weakness of interruptible capacity, which is that it can become scarce or expensive exactly when everyone wants it. If a capacity crunch reclaims your discounted instances, the committed baseline keeps essential work running while the burst layer waits for cheap capacity to return. Decide which of your workloads truly cannot tolerate interruption and place only those on guaranteed capacity, then push everything else toward the discount. The discipline mirrors committed spend planning: commit your floor, and let the flexible, reclaimable layer absorb the peaks where the savings are largest and the interruption risk is acceptable.
How to Compare Offers
When you evaluate discounted capacity across providers, ignore the name and line up the mechanics: the discount depth, the pricing model, the warning time, any runtime cap, and how often that pool actually gets reclaimed in practice. Then weigh the effective cost, which is the discounted rate plus the overhead of interruptions, against your workload's tolerance. A slightly more expensive option with two minutes of warning and rare reclaims can easily beat a cheaper one that vanishes without notice every twenty minutes.
The terminology in this corner of cloud pricing is messier than it needs to be, but the underlying product is consistent. Spot, preemptible, and interruptible are three names for the same bargain: a deep discount in exchange for capacity that can be taken back. Learn to read past the label, design your workloads to survive interruption, and compare offers on warning time, pricing model, and reclaim frequency. Do that, and the confusing vocabulary stops mattering and the savings start.