How much do you save switching AI training workloads from on-demand to reserved GPU instances in 2027?

The two options compared: on-demand versus reserved GPU capacity

On-demand GPU instances are the default purchase mode for AI training. You request capacity, you get it (subject to regional availability), you pay by the second or hour, and you release it when the job finishes. The appeal is obvious: zero commitment, perfect elasticity, and no stranded spend if a training run is cancelled, deprioritized, or migrated to a different accelerator generation. The cost is equally obvious — you pay the highest per-hour rate in the catalog, and for large training clusters that premium compounds fast. A single 8-GPU node running for a month can cost more than a mid-size engineering team's annual tooling budget, and frontier training runs often consume hundreds or thousands of GPUs for weeks.

Reserved GPU instances invert that trade. You commit to a term — commonly one or three years — and in exchange the provider discounts the hourly rate substantially. Reservations come in a few flavors that matter for training specifically. There are capacity reservations, where you're guaranteed that specific GPU capacity is held for you in a specific region and zone. There are savings-style commitments, where you commit to a spend level and get discounted rates but no specific capacity guarantee. And there are hybrid models where a baseline is reserved and burst capacity is on-demand. For training, the distinction between "guaranteed capacity" and "discounted rate" is critical, because a discount you can't actually use during a capacity crunch is worth very little.

The third option that sits between them — and that practitioners increasingly blend in — is interruptible capacity: spot instances, preemptible VMs, and capacity blocks. Spot is the cheapest of all, often 60–70% below on-demand, but jobs can be reclaimed with little notice. Capacity blocks are a middle path: you reserve a defined GPU cluster for a defined window, paying a negotiated rate that's typically below on-demand but above spot, with the guarantee that the capacity is yours for that window. For training workloads, the practical question in 2027 is rarely "on-demand or reserved" in isolation — it's how to layer a reserved baseline, spot for fault-tolerant stages, and capacity blocks for deadline-driven runs.

The reason reservations dominate the savings conversation for training is that training is, counterintuitively, one of the most reservation-friendly workloads in the cloud. Inference traffic is spiky and unpredictable. Training is the opposite: a large pretraining or fine-tuning run is a long, planned, resource-hungry job with a known start, a known duration, and a known cluster shape. If you're running continuous training — a steady pipeline of fine-tunes, RLHF cycles, evaluations, and periodic pretraining refreshes — your GPU footprint is effectively a standing commitment already. You're just paying the on-demand premium for the privilege of not calling it one.

How to decide between them

The decision framework is not "which is cheaper per hour" — reserved always wins that comparison. The real question is whether your utilization and flexibility profile can absorb a commitment without stranding spend. Four variables drive the answer: how many GPU-hours per month you actually consume, how stable that consumption is month to month, how tolerant your training pipeline is of interruption, and how fast your accelerator generation turns over.

Start by measuring true utilization. Pull twelve months of GPU consumption by instance type and region. Compute the floor — the minimum GPU-hours you consumed in any single month — and the average. The floor is your reservation candidate. Anything above the floor is burst and belongs on on-demand, spot, or capacity blocks. Teams that reserve their average instead of their floor routinely strand 20–40% of committed spend, which erases most of the discount.

Then assess interruption tolerance. Training jobs are not uniformly interruptible. A pretraining run that takes three weeks and costs six figures is a poor fit for spot unless you've built robust checkpointing and can resume cleanly across node failures. A hyperparameter sweep of fifty short fine-tunes is an excellent fit for spot, because losing one trial costs minutes. Segment your pipeline by interruption tolerance before you segment it by cost.

Finally, weigh generation risk. GPU generations are turning over roughly every 18–24 months. A three-year reservation on today's accelerator may look expensive in year three if a substantially more efficient part arrives. Many teams hedge by reserving one-year terms on the newest generation and three-year terms only on generations that are already mature and unlikely to be superseded mid-term.

The output of that loop is a blended effective rate, not a single discount number. That blended rate is what you report to finance, because it reflects the real mix of reserved, spot, and on-demand capacity your training pipeline consumes.

Concrete numbers behind each option

Discount percentages are only meaningful when you anchor them to a baseline. Using publicly listed on-demand GPU pricing as the reference, here's how the tiers typically shake out for training-class accelerators in 2027.

On-demand sits at the reference price — call it 100%. This is the number every other mode is measured against, and it's the number that shows up in a team's first cloud bill before any commitment is made. For an 8-GPU node of current-generation training accelerators, on-demand commonly runs in the range of $20–$40 per GPU-hour depending on the part and provider, which puts a single node at roughly $4,000–$11,000 per day.

One-year reservations typically land at 35–45% off on-demand list. On a $30 per GPU-hour on-demand rate, that's roughly $16.50–$19.50 per GPU-hour. The commitment is usually a spend commitment or a specific instance reservation, and most providers let you pay all upfront, partially upfront, or monthly — with all-upfront capturing the deepest discount and monthly capturing the shallowest.

Three-year reservations typically land at 55–65% off on-demand list. On the same $30 baseline, that's roughly $10.50–$13.50 per GPU-hour. The incremental discount from year one to year three is real but smaller than the jump from on-demand to year one, which is why the first year of commitment captures most of the available savings.

Spot and interruptible capacity typically lands at 60–70% off on-demand, occasionally deeper during periods of low demand. On the $30 baseline, that's roughly $9–$12 per GPU-hour — comparable to or slightly better than a three-year reservation, but with no capacity guarantee and no term commitment. For interruption-tolerant training stages, spot is often the single largest lever available.

Capacity blocks sit between reserved and spot, typically 30–50% off on-demand for a defined window, with the advantage of guaranteed availability during that window. They're most useful for deadline-driven training runs where you need certainty about when the cluster is available but don't want a multi-year commitment.

Now translate percentages into dollars. Suppose a team consumes 100,000 GPU-hours per month on training — a mid-size operation, roughly 140 GPUs running continuously. At a $30 on-demand rate, that's $3.0M per month, or $36M per year. Moving the entire footprint to a one-year reservation at 40% off takes it to $1.8M per month, or $21.6M per year — a saving of $14.4M annually. Moving to a three-year reservation at 60% off takes it to $1.2M per month, or $14.4M per year — a saving of $21.6M annually versus on-demand.

Real teams rarely move the entire footprint, because not all of it is steady-state. A more realistic blend: 60% of GPU-hours on a one-year reservation, 25% on spot, and 15% on on-demand burst. Blended rate works out to roughly 0.60 × 0.60 + 0.25 × 0.35 + 0.15 × 1.00 = 0.36 + 0.0875 + 0.15 = 0.5975, or about 40% off on-demand overall. On the same 100,000 GPU-hour baseline, that's $1.8M per month instead of $3.0M — a $14.4M annual saving, achieved without committing the entire footprint.

The leverage point is that the blended rate is dominated by the largest bucket, not the deepest discount. A team that reserves 80% of its footprint at a modest 35% discount beats a team that reserves 20% at a 60% discount, every time. Depth of discount matters less than breadth of coverage on steady-state training capacity.

There's also a hidden saving that doesn't show up in the rate card: reserved capacity removes the scheduling scramble. Teams on pure on-demand frequently can't get the GPU capacity they need when they need it, so training runs queue, engineers idle, and the effective cost per completed experiment rises even though the hourly rate looks unchanged. Reserved capacity converts an availability problem into a planning problem, and planning problems are cheaper to solve.

Implementation details and sequencing

The mechanics of switching matter as much as the economics, because a badly sequenced migration can strand spend or stall training pipelines. The sequence below is the one that consistently avoids both failure modes.

Start with a consumption audit, not a purchasing decision. Pull at least twelve months of GPU usage data, broken out by instance type, region, availability zone, and workload. Tag every training job with an owner, a project, and a criticality level. You cannot reserve intelligently without knowing which GPU-hours are steady and which are burst, and most organizations discover that a meaningful fraction of their "steady" consumption is actually a handful of long-running jobs that could be reshaped.

Next, classify workloads by interruption tolerance. Split training into three tiers: fully interruptible (hyperparameter sweeps, short fine-tunes, evaluation runs), checkpoint-tolerant (long fine-tunes with frequent checkpoints), and interruption-sensitive (large pretraining runs where a restart costs days). This classification determines which capacity mode each tier should use, and it's the step most teams skip.

Then build the checkpointing and orchestration layer before you buy anything. Reserved and spot capacity both assume your jobs can survive a node failure or a reclaim event. If your training framework can't resume from a checkpoint within minutes, you're not ready to move off on-demand — you're ready to invest in checkpointing first. This is engineering work, not procurement work, and it gates the entire savings program.

With classification and checkpointing in place, commit the floor. Take the minimum monthly GPU-hours per instance type from the audit and reserve that quantity on a one-year term first. One-year terms preserve flexibility while capturing most of the available discount, and they let you validate that your utilization assumptions hold before extending to three years. Reserve in the regions and zones where your training actually runs — a reservation in the wrong zone is a reservation you can't use.

Layer spot underneath the reserved floor for the interruptible tier. Configure your orchestrator to prefer spot capacity for sweep and evaluation jobs, fall back to reserved capacity when spot is unavailable, and never touch on-demand unless both are exhausted. This ordering is what produces the blended rate, and it needs to be enforced in scheduling policy, not left to individual engineers.

Use capacity blocks for deadline-driven runs that exceed the reserved floor. A capacity block gives you guaranteed access to a defined cluster for a defined window at a rate below on-demand, which is exactly the right instrument for a training run that must start on a specific date and can't wait for spot availability.

Finally, instrument the blended rate and review it quarterly. Track reserved utilization, spot reclaim rate, on-demand overflow, and the effective cost per GPU-hour across the whole pipeline. If reserved utilization drops below roughly 80%, you've over-reserved and should let commitments lapse rather than renew. If on-demand overflow is consistently above 15% of GPU-hours, you've under-reserved and should extend coverage at the next renewal window.

Two sequencing mistakes are common enough to call out explicitly. The first is buying a three-year reservation before validating one-year utilization — teams that do this frequently discover in month eight that a workload migrated to a different accelerator or a different region, leaving the commitment stranded. The second is moving interruptible workloads to spot before checkpointing is reliable, which produces training runs that restart from scratch and end up costing more than on-demand would have. Both mistakes are avoidable with the sequence above, and both are expensive enough to justify the extra two to four weeks of preparation.

One more implementation detail worth planning for: reservation exchanges and modifications. Most major providers allow you to exchange a reservation for a different instance type or region of equal or greater value, or to modify the term length, within limits. Knowing these rules before you commit lets you build a hedge into the contract itself — for example, reserving a generation that's likely to be superseded, on the assumption that you can exchange into the newer part when it arrives.

Related questions

Does the savings percentage change if I only run training intermittently?

Yes, substantially. Intermittent training rarely justifies a reservation because the commitment is priced against continuous consumption. If your GPU footprint varies by more than about 30% month to month, reserve only the floor and route the rest to spot or capacity blocks.

Are reserved GPU instances always cheaper than spot for training?

No. Spot is usually cheaper per GPU-hour, often 60–70% off on-demand versus 55–65% for a three-year reservation. Spot wins on rate but loses on availability and interruption, so it only wins overall for workloads that can tolerate reclaim events.

How much does checkpointing quality affect the realized savings?

It's one of the largest single factors. A training pipeline that resumes from a checkpoint in under five minutes can safely use spot for most stages. A pipeline that restarts from scratch on failure will lose more compute to interruptions than it saves on rate.

Do reservations make sense for a single large pretraining run?

Usually not on their own. A one-off run with a defined end date is better served by capacity blocks or on-demand. Reservations pay off when you have a continuous training pipeline that keeps the committed capacity busy across the term.

What happens to unused reserved GPU capacity?

It's typically stranded — you pay for it whether or not you use it, though some providers allow you to sell unused capacity back on a marketplace or apply it to other workloads in the same account. Utilization discipline matters more than discount depth.

FAQ

How much do you save switching AI training workloads from on-demand to reserved GPU instances in 2027?

Expect roughly 35–45% off on-demand for one-year commitments and 55–65% for three-year commitments on steady-state training capacity. Blended across a realistic mix of reserved, spot, and on-demand capacity, most teams land near 40% overall savings. The exact figure depends on utilization, GPU generation, region, and how much of the footprint is genuinely steady-state.

What affects the savings the most?

Utilization stability is the dominant factor, followed by term length and interruption tolerance. A team that reserves its true monthly floor captures the full discount. A team that reserves its average strands 20–40% of committed spend and loses most of the benefit. GPU generation turnover and regional capacity constraints are secondary but can materially change the math.

Is a three-year reservation worth the extra commitment over one year?

The incremental discount from one year to three years is typically 15–20 percentage points, which is meaningful on large footprints. The trade-off is generation risk and workload drift. Three-year terms make most sense on mature accelerator generations and on training pipelines that are unlikely to change shape or provider.

Can I mix reserved, spot, and on-demand capacity in one training pipeline?

Yes, and most mature teams do. The standard pattern is a reserved floor for steady-state capacity, spot for interruptible stages like sweeps and evaluations, and on-demand or capacity blocks for burst and deadline-driven runs. The orchestrator enforces the preference order, and the blended rate is what gets reported.

How do I know if I've over-reserved?

Track reserved utilization monthly. If it drops below roughly 80%, you've over-committed and should let the commitment lapse at renewal rather than extend it. If on-demand overflow consistently exceeds about 15% of total GPU-hours, you've under-reserved and should extend coverage at the next window.

Do capacity blocks count as reserved instances for savings purposes?

They're a separate instrument. Capacity blocks give you guaranteed access to a defined cluster for a defined window at a rate typically 30–50% below on-demand, without a multi-year term. They're best for deadline-driven training runs rather than steady-state pipelines, and they shouldn't be counted as reservation coverage in your utilization math.

Sources

• AWS EC2 Reserved Instances pricing documentation: https://aws.amazon.com/ec2/pricing/reserved-instances/
• Google Cloud committed use discounts documentation: https://cloud.google.com/compute/docs/instances/committed-use-discounts
• Microsoft Azure reservations documentation: https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/
• AWS Spot Instance documentation: https://aws.amazon.com/ec2/spot/
• Google Cloud Spot VMs documentation: https://cloud.google.com/compute/docs/instances/spot
• AWS Capacity Blocks for ML: https://aws.amazon.com/ec2/capacityblocks/
• NVIDIA data center GPU product documentation: https://www.nvidia.com/en-us/data-center/
• FinOps Foundation cloud cost optimization guidance: https://www.finops.org/

Related on PULSE

• How to forecast GPU capacity needs for a training pipeline
• Spot versus capacity blocks for deadline-driven training runs
• Building checkpointing that survives spot reclaim events
• Measuring blended GPU cost per completed training experiment
• When to let a GPU reservation lapse instead of renewing