The GPU Hour Is Cheap. The Queue in Front of It Is Not.

Procurement spreadsheets for GPUs are a rate, a term, and a region. They are missing the column that decides whether the rate matters: when the GPU becomes yours. Public clouds separate the price of an accelerator from the quota and the zonal inventory that let you launch one. An account can be funded and still sit in a request that has not cleared. Until it clears, the hourly rate is a hypothetical. The salaries, the slipped launch, and the serving tier you could not move are not hypothetical. They are just absent from the quote.

A Rate Without a Start Date Is Not a Price

Three lines show up after the rate and almost never on the same page as it.

• People waiting. A training team blocked on capacity does not cost zero because the GPU invoice has not started. The burn is the team.
• A date. A model launch, a customer pilot, a regulated go-live. Delay here is not "the job runs later." It is a missed window, and windows do not have an hourly rate.
• The fallback you actually run. Teams who cannot get the SKU keep the workload on a smaller GPU, on a shared development box, or on an API whose unit economics they already rejected. That fallback is the true price of the queue.

AWS documents service quotas as a gate in front of the service, independent of whether you are willing to pay. Google documents GPU stock as zonal and quota-bound. Neither document is a criticism. Both are the reason a rate card is not a comparison. A spot price that clears in minutes and a spot price that has not cleared in four days are different products sharing a name.

Reserved dedicated nodes collapse the gate. The GPU is allocated before the morning you need it. OneSource Cloud sells that shape: single-tenant GPUs held for one customer, billed as a flat month rather than as a race with a public pool, and without an egress charge while you decide what to run. The queue that remains is the one you build yourself, by submitting more jobs than the nodes you reserved. That queue is visible in your scheduler. A public quota queue is not, until the launch has already slipped.

Three Numbers the Spreadsheet Needs

Collect these before anyone calls an option cheaper. If you cannot collect them, you cannot compare.

Do not borrow another company's wait statistics, and do not invent a dollar value for a slipped week inside this article. The point of the three numbers is that the comparison changes sign once the wait is real. A reserved node that costs more per hour and starts tonight beats an interruptible node that costs less and starts after the pilot. It loses to that same interruptible node when the work has no date and the queue has been short. The sign is the reader's. The refusal to compare on rate alone is the point.

What "on demand" has to mean

If the SKU is not launchable in the zone you named, it is not on demand, regardless of the product name. Write the zone and the last successful launch next to the rate. A region in which you have never successfully started the card is not a discount. It is a different risk.

Only Undated Work Belongs in the Queue

Sort the backlog by whether a delay changes anything outside the team.

1. Research with no external date can sit behind a quota. The cost is the team's time, which you can see, and you may decide it is worth the discount.
2. A launch date cannot. Put it on capacity that is already reserved, even when the reserved hour looks expensive beside a spot quote.
3. An online serving tier cannot. Latency budgets do not wait for a quota increase form. Neither does a failover.

Reserved capacity is not always the cheaper line. It is the line whose start time you know. Use it where the start time is the expensive unknown, and keep the queue for work that can honestly slip. Mixing the two onto one "cheap GPU" row is how a finance review congratulates itself on a rate while the platform team misses the date the review was supposed to protect.

Questions the rate card will not answer

How do I measure the wait I already have?

Log, per SKU and per zone, the timestamp of the capacity request and the timestamp of the first GPU that passed a health check. Do it for a month. The distribution — not the best day — is the number missing from the spreadsheet. A quota increase that was approved is not a wait of zero; count until the instances were actually running.

Does OneSource Cloud still have a queue?

Not a public multi-tenant quota queue. OneSource Cloud reserves the GPUs for one tenant, so a launch does not wait behind another company's request. Jobs still wait if you submit more work than the nodes you reserved. That queue is yours, it shows up in your scheduler, and it is the one a capacity plan can actually shrink.