What "reserved vs on-demand" actually means in 2025

The phrase "reserved vs on-demand GPU pricing" collapses four different billing models that GPU clouds actually publish — and each has a different effective $/hr at the same GPU. Get the model wrong, and the procurement math falls apart.

  • On-demand. The default contract — you rent per hour, you can leave at any time, and the rate sits 10–30% above spot for the SLA. This is what GPU clouds show on their pricing page as the headline rate. Example: H100 on Lambda at $2.49/hr on-demand.
  • Reserved (1-year + 3-year). You commit to a fixed capacity block (typically 730 hr/yr minimum) at a discounted hourly rate. The discount is real but you owe the rate regardless of usage. Example: H100 on Lambda at $1.79/hr on a 1-year reserved contract — roughly 28% under on-demand for the same GPU.
  • Spot / preemptible. Interruptible capacity sold at the market clearing price, often 50–70% below on-demand but with no SLA and short (sometimes minutes) preemption windows. Example: H100 spot at $1.49/hr on Vast.ai — the procurement baseline for fault-tolerant workloads.
  • Savings Plans / Committed Use Discounts. Hyperscaler-specific (AWS Savings Plans, GCP CUDs, Azure Reservations) — you commit to $/hr spend, not capacity, and the discount tiers apply automatically across instance families. Functionally similar to reserved but less flexible on the GPU side.

The "reserved vs on-demand" headline discount looks compelling — 28–40% on H100, B200, and H200 across the major clouds. The actual decision hinges on whether your effective utilization rate (% of contracted hours you're actually consuming) clears the break-even threshold. Reserved is only cheaper per consumed hour if you actually consume the hours; otherwise you've paid for empty capacity. That makes the decision a workload-shape problem, not a pricing-page problem.

The one-line procurement rule

Reserve the floor of your workload (the slowest 20–65% of utilization you cannot pre-empt), burst the rest on spot. Don't reserve for projected peak — peak is where spot earns its discount. The Reserved Instance Advisor computes the right reserved-fraction per GPU × provider × term combination.

On-demand break-even math

The break-even formula is straightforward — and explains why most "is reserved worth it?" conversations end in a number, not a yes/no:

break_even_months = upfront_premium ÷ monthly_on_demand_savings

Where upfront_premium is the one-time fee or non-refundable prepay on the reserved contract, and monthly_on_demand_savings is (on-demand $/hr − reserved $/hr) × 730 hr/month. If your actual utilization exceeds the resulting number of months, reserved wins. If it falls short, on-demand wins.

Worked example — H100 on Lambda Labs:

  • On-demand: $2.49/hr (no upfront) → $1,818/month at full 730 hr utilization.
  • 1-year reserved (no upfront): $1.79/hr → $1,307/month at full utilization. Monthly savings: $511.
  • Break-even: if there's a $0 upfront, the break-even is immediate — every consumed hour on the reserved rate saves $0.70 vs on-demand.
  • Where it flips: if you only actually use 40% of the year (~292 hr/month), your effective on-demand $/hr stays $2.49 but your reserved rate stays a fixed $1.79 — you still pay $1.79 for 730 hr, vs $727 for 292 hr on-demand. Reserved costs more in absolute terms: $1,307 vs $727.

The same formula applies to A100 and B200, but the dollar magnitudes differ. A100 reserved-1yr runs ~25–35% under on-demand; B200 reserved-1yr runs ~20–30% under on-demand (and the absolute $/hr savings are larger because the rate is larger). The reference table below shows the % discount row so you can fold your own utilization assumption in: just multiply (utilization%) × (contracted hours) and compare to the spot pricing you'd fall back to.

Workload-shape nuance: "utilization" here is not a single number — your workload has different utilization rates across the day, week, and quarter. A team saying "we're at 60% utilization on our reserved GPU" usually means an instantaneous resource utilization read; a procurement-relevant utilization rate is billable hour consumption over the contract period. Always check the latter before signing the term sheet.

The data convention (anti-hallucination protocol)

Every reserved and on-demand rate in the reference table below carries one of three states from /gpu-forward-pricing:

  • Provider-native. A row in our provider_native_rates source set, verified against the provider's published pricing page on the date shown. This is the most authoritative state.
  • Estimated. A propagation from an adjacent verified rate (e.g., inferring H100 reserved-1yr on Crusoe from Crusoe's B200 reserved-1yr + 10% Blackwell premium). Carried with a helper note and a verification date stamp.
  • Data pending. The cell is marked data pending when we have not independently verified the rate. We do not interpolate. The reserved-vs-on-demand spread for that row should be treated as unknown until verified.

The reference table below applies this honesty convention per-cell. The reserved-vs-on-demand spread column reports the percent savings when both cells are provider-native or estimated; rows where either cell is data pending skip the ratio and stay at "data pending" so the spread is never silently fabricated.

Workload categories that justify a commit (and the one that does not)

The classic procurement mistake is committing capacity to a workload that won't consume it. Below is the workload-shape rubric we use, sorted from "almost always right to reserve" to "almost never right to reserve":

  • Stable production inference (24/7, predictable traffic) — YES, reserve the floor. A customer-facing chatbot, RAG service, or API product with a known daily traffic curve is the textbook case for reserved. P50 traffic is steady, P99 spikes are bounded, and SLA-bound. Reserve the P50-P75 hourly consumption on a 1-year term; burst the rest on spot from Vast.ai or RunPod. This is where reserved economics break even by month 3-4 and compound by month 9-12.
  • Large multi-week pretraining runs — YES, reserve the run window. If you have a planned 4-12 week pretraining job with known start/end dates, the reservation should be sized to the run window — not to "the next year." This is the most error-prone case in practice because teams over-reserve on the optimistic assumption of "we'll find another job." Reservations do not transfer cleanly across non-overlapping workloads.
  • Mature cost-optimized batch (inference or eval with steady queue) — MAYBE, model utilization first. Batch jobs with predictable queue depth and 24/5+ execution are reserve candidates, but only if measured utilization clears the break-even. Below 50% effective utilization, you're paying for empty capacity. Run a 2-3 billing-cycle on-demand pilot with Prometheus instrumentation first, then commit to the reservation sized down from observed peak.
  • GPU experimentation, benchmarking, research — NO, stay on on-demand + spot. Short-horizon workloads with unknown utilization are the wrong target for a 1-year commit. The flexibility premium on on-demand/spot is worth more than the reserved discount when you don't know how many hours you'll consume. Reserve if and when a workload stabilizes into a known usage pattern; do not pre-reserve speculative capacity.

    • Two compounding rules worth noting: model class matters — H100/A100 serving teams are typically the clearest reserve candidates because P50 inference traffic is steady, while B200/H200 reservation makes sense only at scale (typically 8+ GPU nodes) because the absolute savings on a single GPU don't justify the commit friction. Region matters — AWS reserved p5 is 15-20% cheaper in us-east-1 than eu-west-1, so the same utilization rate produces different effective TCO in different regions.

    Reference table: on-demand vs 1-year reserved $/hr for H100, A100, B200 across 4-5 providers

    The table below compares on-demand $/hr vs 1-year reserved $/hr for H100, A100-80GB, and B200 across CoreWeave, Lambda Labs, Crusoe Cloud, Vast.ai/RunPod, and AWS. Rates come from /gpu-forward-pricing's provider-native rows. Cells where we have not independently verified the current rate are marked data pending — we do not interpolate.

    The 12-month savings column reports the percent reduction from on-demand to 1-year reserved for a 730 hr/yr utilization pattern. Reads "28%" means reserving that GPU for 730 hr/yr at that provider saves 28% vs running the same hours on-demand. Rows where either on-demand or reserved is data pending skip the ratio.

    GPU Provider On-demand $/hr 1-yr reserved $/hr 12-month savings % Source
    H100 (Hopper, 80GB HBM3) Lambda Labs $2.49 $1.79 ~28% /gpu-forward-pricing row (Lambda H100)
    H100 (Hopper, 80GB HBM3) CoreWeave $3.92 $2.40 ~39% /gpu-forward-pricing row (CoreWeave H100)
    H100 (Hopper, 80GB HBM3) Vast.ai (spot) $1.49 (spot) data pending data pending Spot floor no formal 1-yr reserved
    H100 (Hopper, 80GB HBM3) RunPod $2.49 $1.89 ~24% /gpu-forward-pricing row (RunPod H100)
    H100 (Hopper, 80GB HBM3) AWS p5.48xlarge ÷8 $4.10+ $2.40+ ~41% AWS p5 reserved-1yr (8-GPU split)
    A100-80GB (Ampere) Lambda Labs $1.29 $0.99 ~23% /gpu-forward-pricing row (Lambda A100-80GB)
    A100-80GB (Ampere) CoreWeave $2.70 $1.79 ~34% /gpu-forward-pricing row (CoreWeave A100-80GB)
    A100-80GB (Ampere) RunPod $2.59 $1.99 ~23% /gpu-forward-pricing row (RunPod A100-80GB)
    A100-80GB (Ampere) Vast.ai (spot) $0.42 (spot) data pending data pending Spot floor no formal 1-yr reserved
    A100-80GB (Ampere) AWS p4de.24xlarge ÷8 $5.12+ data pending data pending AWS p4de on-demand (8-GPU split)
    B200 (Blackwell, 192GB) CoreWeave $4.49 $3.79 ~16% /gpu-forward-pricing row (CoreWeave B200)
    B200 (Blackwell, 192GB) Lambda Labs $6.99 data pending data pending /gpu-forward-pricing row (Lambda B200)
    B200 (Blackwell, 192GB) Crusoe Cloud $4.99 $4.29 ~14% /gpu-forward-pricing row (Crusoe B200)
    Table notes: rates are per single GPU, not per 8-GPU node. AWS p5.48xlarge (8× H100) and p4de.24xlarge (8× A100-80GB) are quoted per-GPU by dividing the 8-GPU instance rate across the 8 GPUs. Spot providers (Vast.ai, RunPod community) do not list a formal 1-year reserved tier — the proxy reservation path there is a 3-month community commitment at a negotiated floor, which sits closer to spot than to Lambda/CoreWeave's reserved rates; those cells stay data pending rather than invent a number. B200 reserved rates are less standardized than H100/A100 because Blackwell supply is capacity-constrained; expect reserved-1yr pricing on B200 to widen or tighten through Q3-Q4 2026 as batch Blackwell deployments land.

    Three things to read from the table:

    • The % discount scales with provider size. AWS reserved delivers the largest headline % (41% on H100, well above Lambda's 28%) but at the highest absolute $/hr. The discount is generous on a percentage basis because on-demand pricing on AWS is a 2-3× premium over Lambda/CoreWeave; the math is "AWS on-demand inflated → AWS reserved moderate," not "AWS reserved legitimately cheaper per unit."
    • Spot + reserve beats pure reserve on cost per consumed-hour for elastic workloads. H100 at $1.49/hr spot + 40-65% reserved gives a blended cost-per-hour of roughly $1.10-$1.20/hr on a workload that runs ~2,000 hr/yr. Pure 1-yr reserved at Lambda/CoreWeave ($1.79-$2.40/hr) loses this comparison when the workload is willing to accept spot preemption.
    • B200 reserved is still emerging. Blackwell supply is constrained enough that providers are quoting reserved-1yr on a case-by-case basis — the cells where we have verified rows show ~14-16% discount, materially smaller than H100's 28-41%. If you're committing to B200 today, model the discounted $/hr against your pre-training run window closely.

    Q3 2026 procurement takeaway

    The reserved vs on-demand decision in Q3 2026 has the same shape as the H100 vs A100 inference decision: workload first, then within-workload optimization. Three rules that we've validated across the provider-native dataset:

  • Lock now: stable H100/A100 inference fleets >40% sustained utilization. Reserve the P50-P75 consumption on a 1-year term if utilization clears the break-even by month 4. The headline reserved rates ($1.79/hr Lambda H100, $0.99/hr Lambda A100-80GB, $2.40/hr AWS H100) deliver material TCO savings once utilization is established. Reference: /calculator, /reserved-instance-advisor.
  • Wait 90 days: B200 reservations and 3-year commits. Blackwell capacity is decoupling from the headline curve; reserved-1yr discounts on B200 vary 10-25% across providers and the floor is still moving. The 3-year commit discount is generous (~15-25% over 1-year) but locks you out of migration to better-priced silicon through 2028. Q4 2026 dashboard refresh from /gpu-cost-pulse will close the picture.
  • Run the advisor: anything in between. For mixed workloads, cost-optimized batch, multi-quarter research with unpredictable utilization — run the per-provider break-even analysis. The Reserved Instance Advisor reads your workload-shape inputs and returns the optimal reserved-fraction per GPU × provider × term.

    • Q3 2026 rule of thumb

    If your workload clears the break-even by month 4, reserve. If it does not, stay on on-demand or mix reserved + spot. The Reserved Instance Advisor (/reserved-instance-advisor) processes the full per-provider × per-term matrix in /gpu-forward-pricing against your utilization assumption and recommends the right reserved-fraction. Cross-reference with the related GPU Forward Pricing Explained post for the 1m / 3m / 6m / 12m Kalshi-derived term ladder that the reservation trend signal is built from. For $/token context on H100 / A100 / B200 inference economics, see H100 vs A100 Inference Cost.

    Frequently asked questions

    What happens if my workload drops mid-term on a 1-year reserved GPU commit?

    You still owe the contracted hourly rate for the full 730 hr/yr block — that's the structural tradeoff of a 1-year reserved commit. AWS, GCP, and Azure allow limited resale on their secondary marketplaces, but at a discount to face value. Specialized GPU clouds (CoreWeave, Lambda Labs, Crusoe Cloud) are stricter — there is no resale path, and you eat the full committed cost. Mitigation: start with a 1-year term rather than 3-year, validate sustained utilization at 60-70% for 2-3 billing cycles on on-demand, then add capacity in 3-month reserve increments rather than one big upfront commit. The Reserved Instance Advisor computes the per-provider break-even utilization rate so you can size the term to the workload, not the headroom.

    Is a 3-year reserved commit worth it over 1-year in 2025?

    Only if you are highly confident in 24/7 utilization for 36 months at the same or growing demand — typically large inference fleets or designated training clusters for a known multi-quarter roadmap. 3-year commits deliver ~15-25% deeper discount than 1-year on AWS and GCP, but they lock you out of migration to better-priced silicon. The realized cost of committing to A100 in 2024 when B200 prices fell in 2025 inflated the effective $/hr by 2-4× compared to a 1-year rolling strategy. For most teams, 1-year is the right default; 3-year earns its discount when you have a long-horizon workload model and a migration penalty that exceeds the additional discount.

    Should I mix reserved and spot, or is spot-only cheaper?

    Mixed is the right answer for most teams. Run a reserved baseline sized to your SLA-bound slowest-20-percent utilization (the floor of traffic you cannot pre-empt), and burst above that on spot. A pure spot strategy is 30-60% cheaper on a $/hr basis but exposes you to preemption on the exact hours you are most likely to be load-shedding — i.e., the wrong time to lose capacity. The Reserved Instance Advisor recommends the reserved baseline fraction (typically 40-65% of total capacity) for each GPU × provider × term combination based on your actual workload shape.

    Run the break-even math on your workload

    GridStackHub's calculator, optimizer, and reserved advisor all read from the same provider-native dataset this post is built on.

    📦 Reserved Instance Advisor — Per-provider × per-term break-even utilization analysis for H100, A100, and B200 commitments.
    🎯 Reserved Instance Advisor (Pro) — $19 one-time. Hand it your expected utilization % and contract length; returns the optimal reserved-fraction per GPU × provider × term combination with a pay-by-month cost projection.
    🧮 GPU Cost Calculator — Model any GPU × workload × provider combination against the live dataset.
    🪜 GPU Forward Pricing — Provider-native reservation rows layered on top of the Kalshi 1m / 3m / 6m / 12m ladder.
    📊 GPU Forward Curves — Live Kalshi mid quotes for B200, H200, H100, A100.
    📈 H100 vs A100 Inference Cost — $/M-token math for LLM serving teams sizing 1-yr reserved baselines.
    🧭 GPU Forward Pricing Explained — The 1m / 3m / 6m / 12m Kalshi-derived term ladder that reservation trend signal is built from.
    🪙 Cost Per Token — Live $/1M tokens across 7B / 13B / 70B / Falcon-180B — the per-token math that decides whether H100 reserved breaks even.
    📰 Weekly GPU Pulse — Week-30 + Week-31 baselines this explainer cites for H100 / A100 / B200 spot floors.
    💼 Pro Pricing — Alerts, forecasts, and forward-curve tooling for procurement teams.