# Reserved GPUs and flexible capacity: what are you committing to?

Separate GPU availability from financial commitments, then compare duration, change rules, idle costs and a flexible pilot before reserving capacity.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/reserved-vs-flexible-capacity/
Language: en

A team may want GPU capacity ready for a future launch while also being offered a longer payment commitment. These are related but different decisions. Equipment owners and funders need to know what is assured and which obligations remain if plans change.

## Separate availability from payment

[AWS On-Demand Capacity Reservations](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) concern capacity and are compared separately with financial mechanisms. [Google reservations](https://cloud.google.com/compute/docs/instances/reservations-overview) have their own resource-assurance rules. Examine the specific product, region and resource attributes. Reserved does not describe identical rights across clouds, and a financial discount is not universal assurance of any desired GPU configuration.

For a direct agreement with a machine owner, record these conditions separately rather than automatically copying a cloud product's model.

## Define the required capacity

Specify GPU, host configuration, schedule and duration. Add location, software compatibility and readiness constraints. A resource in another region or with a different card may not perform the same task. Define the minimum pilot configuration and acceptable substitutes; untested alternatives are not equivalent merely because total memory matches.

State how readiness is confirmed: a running host, a loaded model or an available API. These are different states, especially after restart. A commitment should identify the condition needed at the agreed time rather than only a hardware label.

## Check obligations when plans change

What happens if launch is delayed, traffic is lower or the model needs a different resource? Modification, cancellation and transfer depend on the agreement. Include those cases in the financial scenario instead of calculating only an ideal period of full useful utilization.

Even a working, available server can lack paying demand. Establish who pays for electricity, waiting and maintenance on days without requests before making the commitment. That clarifies the owner's responsibilities as well as the funder's exposure to unused capacity.

## Compare reservation with a flexible pilot

A short rental or already idle equipment can test an early workload. It may not assure the capacity needed later, but can refine requirements before a longer decision. Compare both scenarios against the same goals: timely readiness, test expense, expansion restrictions and exit procedure. Flexibility also requires work and should not be treated as free.

Produce a decision record explaining the selected duration. Show underutilization in the same units as the main case: capacity paid for, time ready and useful work completed. These three lines reveal the cost of commitment without assuming full utilization.

## Assessment notes

This article does not announce standard reservation terms or demand guarantees.

Prepare with [demand validation](/journal/model-demand-validation/), [spot versus on-demand](/journal/spot-vs-on-demand-gpu/) and [capacity planning](/journal/inference-capacity-planning/).