The break-even is one division: a committed monthly price divided by what the same GPU would cost on demand for the whole month. The result is a share of the month, and it is the utilization at which the two cost the same. Keep the GPU busy for less of the month than that and paying by the hour costs less, because on QuantaCloud you pay only from launch to stop. Keep it busier and the commitment costs less, and it also holds the hardware for you.
The formula#
The break-even needs two numbers: the monthly price of the commitment, and the hourly on-demand price of the same configuration.
| Formula | What it tells you | |
|---|---|---|
| Break-even hours | Monthly commitment / on-demand price per hour | The hours a month below which on demand costs less |
| Break-even utilization | Monthly commitment / (on-demand price per hour x 730) | The share of the month the GPU has to be busy before the commitment wins |
| The ceiling for a quote | Hours you will really use x on-demand price per hour | The most a commitment can cost and still beat your on-demand bill |
A month is 730 hours here: 8,760 hours a year divided by 12. Use the price of the whole configuration, not one GPU out of several, and compare like with like: the same GPU model, the same count.
The formula works for any provider and any commitment, including a monthly server lease or the cost of hardware you own spread over its life. What changes between providers is how on-demand time is counted, because that sets the real hourly bill.
How on-demand time is billed on QuantaCloud#
QuantaCloud bills on demand by the second, with a one-hour prepay. The first hour is charged from your prepaid credit when you launch. Each further hour is charged when the previous one is used up. When you stop, the unused seconds of the current hour are refunded. If you stop before the instance is running, or provisioning fails, the first hour comes back in full.
Two details matter for the break-even. Boot time counts: the clock starts at launch, and most single-GPU VMs are running in about 3 minutes (median), so a job that stops and starts every day pays for those minutes every day. And there is no way to pause: stopping an instance terminates it and deletes its disk, so "on demand for part of the month" means a fresh VM each time, with your setup scripted. Pricing has every rule, and the billing docs walk through the Billing page in the console.
Example 1: a GPU used in working hours#
One RTX A6000 cost $0.48 an hour on 2026-11-12 (today: $0.48/GPU-hr). Left running for a whole month it costs $350.40 (our calculation: 730 x $0.48).
Say you use it 8 hours a day on 22 working days and stop it each evening. That is 176 hours of work plus 22 boots of 3 minutes, 177.1 billed hours, which costs $85.01 (our calculation: 177.1 x $0.48). The boots are $0.53 of it. Your utilization is 24.3% of the month (177.1 / 730).
| Utilization | Hours a month | On-demand cost at $0.48 an hour |
|---|---|---|
| 25% | 182.5 | $87.60 |
| 50% | 365 | $175.20 |
| 75% | 547.5 | $262.80 |
| 100% | 730 | $350.40 |
Read the last column as the ceiling for a quote. At this usage, a commitment for one RTX A6000 has to cost less than $85.01 a month to beat on demand, which is under a quarter of the always-on cost. Unless a quote comes in below that ceiling, this workload stays on demand. Each $35.04 a month in a quote moves the break-even by ten points of utilization (our calculation: $350.40 / 10).
Example 2: an endpoint that never stops#
One RTX PRO 6000 Blackwell cost $2.39 an hour on 2026-11-12 (today: $2.16/GPU-hr). An inference endpoint that runs all month uses all 730 hours, so on demand it costs $1,744.70 (our calculation: 730 x $2.39).
At 100% utilization the arithmetic is short: any commitment under $1,744.70 a month for the same GPU costs less, and each $174.47 below that is ten points of headroom. If traffic only justifies running it half the month, the ceiling halves to $872.35 (our calculation: 365 x $2.39).
The on-demand version of this workload also carries two risks that have nothing to do with the rate. The balance has to cover every hourly charge, because an instance whose next hour cannot be paid is terminated and its disk deleted: I would fund the month plus one hour, $1,747.09, or turn on auto top-up. And the VM must never be stopped, because there is no way to start the same VM again.
Try your own numbers#
Pick the GPU and the count, set the hours of work in one run and the runs in a month, and enter the monthly price from a quote. The calculator gives the monthly on-demand cost at the live price and the hours below which on demand costs less.
- Cost per run
- $1.97
- 2 h 3 min from launch to stop at $0.96 per hour
- Cost per month
- $1.97
- 1 run, 2 h 3 min billed
- Credit to launch
- $0.96
- One hour at this configuration's price
| GPU | Per hour | Per GPU-hour | Cost per run | Cost per month |
|---|---|---|---|---|
| 2x RTX A6000 (selected) | $0.96 | $0.48 | $1.97 | $1.97 |
| 2x A100 PCIe 80GB | $2.95 | $1.48 | $6.05 | $6.05 |
| 2x RTX PRO 6000 Blackwell | $4.33 | $2.17 | $8.88 | $8.88 |
| 2x H100 PCIe | $5.18 | $2.59 | $10.62 | $10.62 |
Prices checked 14 Nov 2026, 09:16 UTC
The GPU cost calculator page explains each field and what the estimate leaves out.
What else changes besides price#
Price is the smaller half of the decision. A reservation changes what you can get, when you get it and what you owe if plans change.
| On demand | Reserved | |
|---|---|---|
| Availability | Whatever the live catalog lists at the moment you launch | Built for you and held for the term |
| Configuration | Catalog VMs with 1, 2, 4 or 8 GPUs and a fixed amount of vCPUs, RAM and disk, on Ubuntu 22.04 | Any NVIDIA GPU, from one bare-metal server to a cluster, with the CPU, memory, storage and fabric you specify |
| Time to start | About 3 minutes (median) for most single-GPU VMs | The lead time in your quote |
| Term | None. You stop when you are done | The term in your quote |
| Your data | The disk is deleted when the instance stops. There are no volumes or snapshots | Storage is part of the spec |
| What you risk | The GPU you want is not listed on the day you need it | Paying for hours you do not use |
Availability is the row I would weigh first. The on-demand catalog is what is free at that moment, and it moves. On 2026-11-12 it listed seven GPU models, and no H100 or H200 at all. If a launch date, a customer contract or a training schedule depends on a particular GPU, that dependency is the reason to reserve, whatever the utilization.
Configuration is the second. Reserved capacity at QuantaCloud is built to order: you send a brief, we reply with a proposed configuration, a lead time and commercial terms in writing, and once you accept we order and build the hardware. That covers things the catalog does not sell at any price, such as bare-metal servers, HGX servers with H100, H200, B200 or B300 GPUs, and a reserved GPU cluster with a fabric between its nodes. Dedicated GPU servers covers the single-server case.
Lead time and term cut the other way. An on-demand VM is running in minutes and costs nothing once it is stopped. A build takes the lead time in its quote, and the commitment runs for the agreed term whether the GPUs are busy or not.
Reserved GPU pricing at QuantaCloud#
QuantaCloud does not publish a reserved price list or a discount schedule. Every reserved build is quoted in writing for its configuration and term, so the number to put in the formula is the one in your quote. The reserved capacity page has the brief form and the ten questions a useful brief answers.
Ask for a reserved quoteSpot, on demand and reserved#
Spot is the third way GPU time is sold: spare capacity at a lower price that the provider can take back. It suits jobs that checkpoint often and can restart. QuantaCloud has no spot instances, so the choice here is between two models, not three.
An on-demand instance can still end without you stopping it. It is terminated when the balance cannot cover the next hour, and it can be lost after a host failure. Either way the disk goes with it, so copy checkpoints off as you go, and use the auto-stop guide to end idle instances yourself before they run up hours.
Where buying fits#
Buying hardware is the same formula with a different numerator: the monthly cost of owning the machine, spread over its life, against the on-demand bill. A February 2025 study by a data-center research institute put the break-even for an 8-GPU H100 system in a US colocation facility at 22% utilization against the large hyperscalers' on-demand prices and 66% against GPU-focused clouds, and added that passing 66% "would be difficult for all but the most efficient AI deployments". GPU as a service walks through the buying models, and the H100 price guide works the purchase arithmetic for one card.
Reserved and on-demand questions#
Is a reserved GPU cheaper than an on-demand one?
Only above the break-even utilization: the monthly commitment divided by the on-demand cost of running the same GPU for all 730 hours. Below it, on demand costs less, because you pay only from launch to stop.
What is an on-demand GPU?
An on-demand GPU is one you launch and stop yourself, with no term, and pay for by the hour or the second. On QuantaCloud it is a virtual machine with 1, 2, 4 or 8 NVIDIA GPUs, paid from prepaid credit, and the GPU catalog lists what can be launched right now.
Does QuantaCloud have spot instances?
No. Every instance is on demand at the listed hourly price, and there is no interruptible tier.
Can I start on demand and reserve later?
Yes, and it is the order I would do it in. Run the workload on demand first to measure the hours it really uses, then put that number in the formula. If you reserve, you can keep working on an on-demand VM while the build is under way, as long as you keep your own copies of code, data and checkpoints.
Can I reserve a whole cluster?
Yes. A multi-node cluster is only available as a reserved build: on-demand instances are single VMs with up to 8 GPUs. GPU clusters covers node platforms, fabrics and what to put in the brief.
My rule: measure before you commit. Run the job on demand for a month, add up its charges in the CSV export on the Billing page, and divide by what the same GPU costs running all 730 hours. If the GPUs are busy a small share of the month, stay on demand. If they are busy most of it, or your plan depends on hardware being there on a date, send a capacity brief and set the written quote against the formula above.