The pitch for reserved capacity is a discount in exchange for a commitment. That framing understates the more important benefit and has caused a lot of teams to evaluate it purely as a cost question.
The scarcer resource is availability. Requesting a large block of current-generation GPUs on demand can fail — not throttled, not slow, simply unavailable in that region for an unpredictable period. A reservation is a guarantee that the hardware is there when you ask.
What changed in 2026
- Availability stayed constrained. Demand for high-end accelerators continued to exceed easy on-demand supply in popular regions.
- Commitment terms diversified. Shorter and more flexible commitment windows appeared alongside traditional long ones.
- Layered strategies became standard. Reserved baseline plus on-demand overflow plus spot for batch work settled as the default shape.
- Utilisation tracking got serious. Teams began measuring reservation utilisation as a first-class metric rather than discovering waste at renewal.
What a reservation actually buys
|
On-demand |
Reserved |
Spot |
| Availability guarantee |
None |
Yes |
None; can be reclaimed |
| Price |
Highest |
Discounted |
Lowest |
| Commitment |
None |
Term-length |
None |
| Cost when idle |
Zero |
Full |
Zero |
| Suitable for |
Bursts, experimentation |
Steady baseline |
Interruptible batch |
The row that changes decisions is the last-but-one. A reservation costs the same whether or not you use it. It is capacity you have bought, not work you have done. An under-utilised reservation is worse than on-demand, because you are paying the discounted rate for hardware sitting idle rather than the full rate only when running.
Which means the sizing question is not "how much do I need at peak" but "how much do I need essentially all the time".
Sizing the commitment
Measure before committing. Specifically, measure the floor — the level of usage sustained across a representative period including quiet times.
Commit to that floor. Anything above it is variable demand, and variable demand belongs on on-demand or spot.
Teams commonly commit near their peak, reasoning that the discount applies to more hours. The arithmetic does not work: hours you do not use cost full price at the discounted rate, and the effective rate on your actual usage rises above on-demand.
The diagnostic to track is reservation utilisation — what fraction of your committed hours you actually consumed. Below a threshold, the commitment is costing rather than saving, and that should be visible monthly rather than discovered at renewal.
Commitment length is the other axis. Longer terms discount more and bet on your workload shape staying stable. Early in a project, when the model, the traffic, and the architecture are all still moving, that bet is usually wrong — flexibility is worth more than the discount. Once a workload has been stable for months, longer terms make sense.
Layering the tiers
The pattern that works:
Reserved covers the measured baseline — the steady serving load that runs continuously.
On-demand absorbs peaks and unexpected growth. More expensive per hour, and only paid when used, which is exactly right for variable demand.
Spot takes interruptible work: training runs with checkpointing, batch inference, evaluation jobs, data preparation. Cheapest, and it can be reclaimed, which is fine for anything that can resume — see spot instances for training.
Getting the split right requires knowing which of your workloads tolerate interruption, and that is worth classifying explicitly. A surprising share of AI compute is batch work that has been running on expensive on-demand capacity out of habit.
Common mistakes
- Committing to peak. Idle reserved capacity is a pure loss.
- Evaluating on discount alone. Availability is often the bigger benefit.
- Long commitments on an unstable workload. Flexibility is worth more early.
- Not tracking reservation utilisation. Waste is invisible until renewal.
- Running interruptible batch work on reserved capacity. Spot is far cheaper.
- Ignoring region constraints. A reservation is regional; your traffic may not be.
- Forgetting parallel-group granularity. Multi-GPU serving reserves in groups, not single devices.
FAQ
How long a commitment should I take?
As short as the pricing makes sensible until your workload has been stable for several months. The discount difference between term lengths is usually smaller than the cost of being locked into the wrong shape.
What if I outgrow the reservation?
That is the good case — add on-demand on top. Reservations set a floor, not a ceiling.
Can I use reserved capacity for training?
Yes, and training is frequently interruptible with checkpointing, which makes spot more economical. Reserve for what must run continuously.
Does this apply to hosted APIs?
The analogue is provisioned throughput or committed spend arrangements, and the same logic applies: commit to the baseline, pay variable rates for peaks.
Where to go next
For the interruptible tier, read spot instances for training. For sizing the baseline in the first place, AI capacity planning, and for hardware selection, GPU procurement.