On-demand vs reserved vs spot pricing
Compare contract choices.
Learn
A compute reservation secures defined GPU or accelerator capacity for a buyer over an agreed period.
One concept connected to AI compute market decisions.
A practical introduction designed to be completed in one sitting.
Useful for procurement buyers, founders, analysts, and product managers planning recurring compute demand.
Plain-English definition
A compute reservation is an agreement that gives a buyer access to a defined amount of compute capacity for a specified period. For AI workloads, a reservation may secure GPUs or a connected cluster before the buyer runs training, serves users, or needs overflow capacity.
Why it matters
Reservations show how much buyers value certainty. A company that cannot risk waiting for GPUs may commit earlier, accept minimum payments, or choose a provider based on reliable availability rather than the lowest visible hourly rate. That choice affects cost and removes capacity from the open market.
Simple example
Consider an illustrative startup expecting to use 64 H100 GPUs for 720 hours in one month. At an on-demand rate of $8 per GPU-hour, full-month usage would equal 64 x 720 x $8 = $368,640. A reservation at an illustrative $6.50 rate would equal $299,520 if the full commitment is required and used.
Example figures are illustrative calculations, not current quoted market prices.
Market signal
Reservation activity can indicate that buyers expect access to matter in the future. An increase in required commitments, scarce reservation windows, or smaller open blocks can point to tightening usable supply. Larger discounts or flexible reservation terms may show providers seeking committed demand or monetizing new capacity.
Market read: a buyer paying for certainty is a demand signal. Compare what is reserved with what remains available before concluding that supply is easy or tight.
Common mistake
Do not assume a reserved rate is automatically cheaper than on-demand capacity. A reservation buys access and possibly a discount, but it also creates obligation. If demand arrives later than expected, a model architecture changes, or the reserved system does not fit the workload, the buyer can pay for unused or ineffective capacity.
Practical takeaway
Compare reservation choices using expected utilization, critical deadlines, workload reliability needs, and the cost of being unable to run. A buyer should model base, low-use, and high-demand cases before committing to a capacity block.
Decision check: approve a reservation only after showing the utilization level at which it beats flexible capacity and the consequence if capacity is unavailable without it.
Helpful memory trick
A compute reservation is a seat saved on the GPU train: it helps you board on time, but you may pay even if plans change.