A mid-size manufacturer came to us with a $38,000 monthly cloud bill and a utilisation graph that looked like a heartbeat: flat for weeks, then a four-day spike during every model retrain. They did not need more compute. They needed a different shape of compute. Here is the maths we ran together, step by step.
The customer’s problem
Their baseline was 6,000 GPU-hours a month — steady inference and nightly fine-tuning. Their burst was another 9,000 GPU-hours concentrated in four-day windows. Paying on-demand rates for the baseline was the waste; renting nothing for the burst was not an option.
The maths, step by step
- Step 1 — baseline: 6,000 hours on two owned X900 nodes (8 GPUs each, 92% utilisation after consolidation) at a fixed internal cost of roughly $1.90 per GPU-hour.
- Step 2 — burst: 9,000 hours on rented capacity at $2.60 per GPU-hour, reserved per event with 48-hour notice.
- Step 3 — blended: (6,000 × $1.90 + 9,000 × $2.60) ÷ 15,000 = $2.32 per GPU-hour, against $3.95 on-demand.
- Step 4 — annual: $38,000 → $22,400 per month at identical throughput, a 41% reduction.
Utilisation, not price, is the variable most teams forget to manage.
What made it work
Three operational details mattered more than the purchase. The rented capacity was pre-negotiated with 48-hour activation, so the burst never queued. Checkpointing was standardised so a retrain could resume on rented hardware without losing progress. And the owned nodes ran a mixed workload — inference by day, fine-tuning by night — which is what pushed utilisation past 90%.
When the hybrid breaks
If your baseline is under 2,000 GPU-hours a month, owned hardware rarely amortises — rent everything. If your burst is unpredictable inside 24 hours, you will pay premiums no matter who owns the iron. And if your workload is seasonal, a one-year reserved instance often beats both. The shape of your demand curve picks the answer, not the brochure.