Which Providers Offer Short-Term and Reserved GB200 NVL72 Capacity With Managed Operations?

For short-term and reserved GB200 NVL72 capacity with managed operations, shortlist the providers whose short-term path can become the reservation without a move. AWS documents the clearest short-term form: EC2 Capacity Blocks support P6e-GB200 UltraServers and can be extended in place with the same reservation ID, but only when capacity is available, so they work best as a bridge while the reservation is negotiated separately. CoreWeave's ARENA evaluation program is built to end in a production decision, with evaluation fees credited or waived on agreed terms. GB200 NVL72 on GMI Cloud is in pre-order and coming soon, with pricing listed from $8.00 per GPU-hour on the GPU page, and our Managed GPU Cluster service, which GMI provisions and operates, is in early access on H200 nodes today. With GMI, the pre-order is where any initial phase, the reservation, and the operations scope can be covered in one capacity proposal, so they aren't negotiated twice.

Whichever provider you choose, the recommendation holds only if it will put the conversion terms in writing before the short run starts, and above all these four: the reservation continues on the same racks, network, and storage; a named date when committed pricing replaces short-term pricing; a clear exit if you decide not to reserve; and an operations scope that stays the same across both terms. If a provider can't commit to the first point, plan for a migration and a second round of validation at the start of the reservation. The rest of this guide starts from that switch: what the short run has to prove, why moving costs more than the rate change, and the six terms to get in writing.

What the short run has to prove

A short run on a rack-scale system exists to answer production questions, not to produce a benchmark score. GB200 NVL72 is a liquid-cooled rack that links 72 Blackwell GPUs and 36 Grace CPUs in one NVLink domain, and the behaviors worth checking only show up at that scale:

• Scaling across the full NVLink domain. Whether the job's parallel layout keeps its efficiency when it spans all 72 GPUs rather than a subset.
• Checkpoint save and restore. How long a full checkpoint takes to write to the storage the reservation will use, and whether a restart from it resumes cleanly.
• The provider's incident handling. What happens when a tray or node fails: how the provider notifies you, who opens the ticket, and how long the job waits.
• The bill. Whether invoices match the quoted rate, and whether storage and networking charges look the way the proposal said they would.

Each of these answers is tied to a specific environment. Scaling results depend on the fabric, checkpoint timing depends on the storage system, and incident handling depends on the team operating that site. Evidence gathered on one set of racks says little about a different set in another data center, which is why environment continuity is the first term to negotiate.

Why moving between environments costs more than the rate change

The gap between a short-term rate and a committed rate is one line on a quote. Moving a training workload between environments is engineering time: copying datasets and checkpoints, rebuilding the scheduler setup and container images against a new cluster, re-running the scaling and restore checks from the short run, and pausing training while all of that happens. On a rack-scale system, the re-validation alone repeats most of what the short run was for.

That's why the conversion terms matter more than the size of the committed discount. A slightly lower committed rate that requires a move can cost more in lost weeks than a smaller discount on the racks already running the job.

The conversion terms to put in writing

These six terms turn a short run into the first phase of a reservation. Each belongs in the proposal or contract before the short phase begins, because they are easier to agree on before the job depends on the provider's hardware.

1. Same racks, network, and storage. The reservation continues on the allocation used in the short phase, with the same interconnect fabric and the same storage volumes. When a provider can only commit to "equivalent" capacity, ask what equivalent means and whether it could sit in a different data center.
2. A billing cutover date. The date committed pricing takes effect, stated as a calendar date or as a rule tied to your notice. The contract should also say how any overlap is billed, so the same hours aren't charged at both rates.
3. Extension and exit. How the short phase is extended if testing runs long, how much notice the provider needs, and whether an extension depends on capacity being available. Equally important is the other direction: what happens if you decide not to reserve, including the notice period and any early-exit charges.
4. A data and checkpoint exit window. How long datasets and checkpoints remain accessible after the short phase ends without a reservation, and what storage costs during that window.
5. Minimum commitment and added capacity. The smallest reservation the provider accepts for GB200 NVL72, whether the short phase counts toward it, and how more capacity is added later: at the committed price, on the same end date, and inside the same cluster.
6. An unchanged operations scope. Managed operations belong in the conversion terms. Whatever the provider operates during the short phase, such as hardware monitoring, failed-tray replacement, firmware and driver updates, and the cluster control plane, should carry into the reservation unchanged, with the same support hours and escalation contacts. A reservation that shifts part of that work back to your team is not the environment the short run tested.

How each short-term form converts

Providers sell short-term capacity in three forms, and each converts differently. The examples below come from each provider's own documentation.

Fixed-duration blocks carry the most specific rules. AWS's documentation for EC2 Capacity Blocks says blocks can't be canceled, and instances on a P6e-GB200 UltraServer block must be terminated at least 60 minutes before the block ends. Under AWS's general rules for Capacity Blocks, a block can be extended in one-day increments up to 14 days, and in seven-day increments up to 26 weeks in total. The Capacity Reservation ID stays the same after an extension, so instances keep running without disruption. AWS also states that an extension is possible only when capacity is available, which is not guaranteed. That is continuity with a condition attached, so the longer commitment, and whether it removes that condition, has to be negotiated as its own term.

Evaluation programs are built around conversion. CoreWeave describes a typical 14-day benchmark cycle for its ARENA program, meant to validate performance, scaling, and cost before committing to production, and says evaluation fees can be credited or waived for customers who proceed to production, based on agreed terms. Those agreed terms are the part to get in writing.

Put side by side, the providers suit different starting points. AWS Capacity Blocks can bridge a short run and a later commitment, because an extension keeps the same reservation ID, but each extension depends on available capacity and the block is not a long-term reservation. CoreWeave's ARENA ties the evaluation to a production decision, and the credit or waiver of evaluation fees, on agreed terms, is the part to pin down. GMI Cloud's GB200 NVL72 is in pre-order, so there is no short run to start today; what pre-order offers is the chance to negotiate the whole path before any capacity is delivered, including a proposal that states whether the same GB200 NVL72 allocation carries over from the initial phase into the reservation.

Whichever form comes first, the same question decides the outcome: does the reservation begin on the environment the short phase ran on, or on new hardware?

Getting the conversion terms into a GB200 NVL72 pre-order on GMI Cloud

GB200 NVL72 on GMI Cloud is in pre-order and coming soon, so capacity is planned ahead rather than provisioned on the spot. That makes the pre-order conversation the place to raise the conversion terms above. Ask for the length and form of any initial phase, the billing cutover date, the allocation, the region, and the operations GMI runs in each term to be covered, and we'll work through them with you as part of the pre-order. Confirm which resources stay assigned when the pricing term changes.

Across the platform, usage-adaptive GPU pricing lets pricing follow workload maturity: teams can begin on demand and move to dedicated or committed deployments once a workload settles, rather than signing a long-term commitment too early. Today that on-demand starting point applies to H100 and H200, which are available now. For GB200 NVL72, how any initial phase is priced and when committed pricing takes over are items for the pre-order proposal. Committed usage plans carry significant discounts for sustained workloads, and our sales team can walk you through the commitment options.

Two platform-wide facts bear directly on the conversion terms:

• Dedicated capacity. All GPU resources on GMI Cloud are dedicated, single-tenant instances, so the environment a team tests is not shared with other tenants.
• Storage as its own line. Networking and storage are provisioned separately from GPU-hours, based on workload requirements. Ask for the checkpoint retention period and its rate as separate items in the proposal.

Our Managed GPU Cluster service shows how billing and growth work on managed clusters today, within a narrower scope. It is in early access and provides production-ready Kubernetes clusters on H200 nodes, with B200 nodes also listed; B200, like the rest of our Blackwell lineup, is in pre-order. GMI provisions and operates these clusters, and the service offers centralized cluster lifecycle management for managed clusters in both GMI Cloud and BYOS (Bring Your Own Service) environments. GB200 NVL72 is not among the published node types, so the points below describe the current service, not GB200 terms:

• Billing method per cluster. Each managed cluster carries its own billing method, either pay as you go (charged by the minute) or prepaid, and the request form shows an estimated monthly cost with list price and discount once nodes are selected.
• Adding nodes to a running cluster. Node requests add nodes to an existing managed cluster instead of creating a new one.
• Activation. Cluster requests aren't processed automatically; after submitting a request, contact our support team to activate it.

For GB200 NVL72, whether the rack runs as a managed cluster and which of these operations GMI handles in each term are part of the same pre-order discussion.

FAQ

Can the short phase count toward the reservation?

Only if the contract says so. Ask whether short-phase spend is credited against the first committed period, whether short-phase hours count toward the minimum commitment, and whether the committed term starts at the billing cutover date or at signature. CoreWeave's ARENA terms show one way this is handled, with evaluation fees credited or waived on agreed terms. On GMI Cloud, raise these points as part of the GB200 NVL72 pre-order.

What happens to our data if we decide not to reserve?

That is the exit window term. Get the number of days datasets and checkpoints stay accessible after the short phase ends, the storage rate during that window, and how data is handed back or deleted at the end. On GMI Cloud, storage is provisioned and priced separately from GPU-hours, so you can ask for its retention to be written into the proposal as its own item.

Plan the switch before you pre-order

Tell us about your workload, how long you'd want an initial phase to run, when you expect to decide on the reservation, and the term you're planning, and we'll work through the conversion terms and operations scope with you as part of the GB200 NVL72 pre-order. Talk to our infrastructure team.