What does a GB200 NVL72 cluster cost to run for large-scale training, and how do I estimate total monthly spend?

Teams sizing a GB200 NVL72 cluster for large-scale training usually start by multiplying an hourly rate by 730 hours and treating that as the budget. That number is a ceiling, not an estimate, because it assumes one GPU running flat out with no reserved discount and no idle time. A realistic GB200 NVL72 monthly estimate is GPU-count times hourly rate times hours times utilization, adjusted for whether you run on-demand or on a reserved commitment, so the sticker price is only the first input. This guide gives you the formula, the variables that actually move the bill, and what to confirm before you plan a training budget around it.

Start from the per-GPU-hour rate, then scale it

The published rate is the anchor, but training rarely runs on a single GPU. In our current published listings, GB200 NVL72 is listed at from $8.00 per GPU-hour and marked Available Now, which is a starting list price, not a locked invoice. A full NVL72 rack is 72 Blackwell GPUs in one interconnected domain, so your compute line scales with how many GPUs your job actually holds.

The base arithmetic is straightforward once you separate the variables. Monthly GPU cost equals the number of GPUs, times the per-GPU-hour rate, times the hours you run them, times your effective utilization, so a full rack held all month at list price is a very different number from a partial allocation run for a two-week training campaign. Nail down each of those four inputs before you trust any total.

The four variables that move a training bill

Two teams renting the same rack can post monthly bills that differ by more than half. Four inputs explain most of the spread:

• GPU count: A full NVL72 rack bills differently from a partial allocation. Decide whether your model and parallelism strategy actually need all 72 GPUs or a subset.
• Hours run: A month is roughly 730 hours. A job that runs 24/7 for the full month costs far more than one that trains for ten days and releases the capacity.
• Effective utilization: Checkpointing, restarts, data-loading stalls, and debugging mean GPUs are rarely at 100 percent. Budget against realistic utilization, not theoretical peak.
• On-demand versus reserved: A sustained multi-week training run is the classic case where a reserved commitment lowers the effective per-GPU rate below the on-demand starting price.

For rack-scale Blackwell, one boundary matters before you model spend: on-demand rarely means elastic, click-to-launch capacity the way it does for a single H100. An NVL72 rack is large, liquid-cooled, and power-hungry, so most access is short-notice allocation against reserved pools, which is also why sustained training usually lands on a commitment rather than pure on-demand.

A worked estimate framework for GB200 NVL72

Use the frame below to turn the rate into a defensible monthly number. The illustrative math uses the from $8.00 per GPU-hour list rate; substitute your quoted rate and confirmed GPU count.

Scenario	Inputs (GPUs x rate x hours x utilization)	Illustrative monthly compute
Full rack, full month, on-demand	72 x $8.00 x 730 x 1.0	~$420,000 ceiling
Full rack, realistic utilization	72 x $8.00 x 730 x 0.8	~$336,000
Full rack, reserved commitment	72 x lower reserved rate x 730 x 0.8	Below on-demand, rate-dependent
Partial allocation, two-week run	16 x $8.00 x 336 x 0.85	~$36,500

These are illustrative, not quotes. The top row is the sticker ceiling almost no one actually pays; the realistic and reserved rows are where a real budget lands. Beyond compute, add the operational lines a training run carries: storage for datasets and checkpoints, egress if you move data across regions, and any networking or support tier, since those sit outside the per-GPU-hour rate.

Estimating GB200 spend on GMI

Once you have the four variables, the practical step is turning them into a firm number with our team. We are an AI-native GPU and inference cloud that publishes dedicated NVIDIA GPU list pricing and offers reserved capacity plans, which is the model that fits a sustained training campaign better than pure on-demand.

We offer commitment-based savings, where reserved capacity and sustained deployment lower the effective per-GPU cost below the on-demand starting rate, which is exactly the profile of a multi-week GB200 training run. Verify the from $8.00 per GPU-hour Available Now listing on our GPU infrastructure (https://www.gmicloud.ai/en/gpus) and pricing (https://www.gmicloud.ai/en/pricing), then confirm your GPU count, the committed rate, and current rack stock rather than assuming elastic supply. For the estimate itself, get four things in one quote: the committed per-GPU-hour rate, the GPU count you are allocated, the term length, and what storage and egress cost on top, so your monthly model reflects the invoice rather than the rate card. When the same cluster will later serve production inference, our Prime Inference (https://www.gmicloud.ai/en/models/prime-inference) provides reserved GPU capacity with single-tenant isolation, so you can plan training and serving spend against one committed footprint. Start allocation and commit-pricing conversations in our console (https://console.gmicloud.ai) or contact our sales team.

Budget the run, not the sticker

If you estimate a GB200 NVL72 training budget by multiplying the hourly rate by a full month, you will over-budget the ceiling and still miss the storage, egress, and utilization lines that decide the real bill. Build the number the other way: count the GPUs you actually need, apply realistic utilization, choose on-demand or reserved against the length of the run, then add the operational lines the rate excludes. In our current published materials, GB200 NVL72 starts at $8.00 per GPU-hour, so use that as the anchor, negotiate the committed rate for anything sustained, and re-check the live pricing page at order time before you lock a monthly forecast.