What is GPUaaS Billing?
Written by Arnon Shimoni
✓ Expert
Last updated on:
What is GPUaaS billing?
GPUaaS billing is how GPU-as-a-Service gets priced and invoiced: customers rent GPU capacity (by the hour, by the node, or by committed capacity blocks) and pay per unit of allocation, per unit of consumption, or both. It's the core commercial engine of the neocloud category, whose providers (CoreWeave, Lambda, Nebius, Crusoe, and the rest) sell almost nothing else.
The market context explains the attention: GPU-as-a-Service was reportedly a low-single-digit-billions market in 2023 and is projected to reach roughly $50 billion by 2032. Every dollar of it flows through one of the models below.
What are the GPUaaS pricing models?
Model | How it bills | Who it's for |
|---|---|---|
On-demand | Per GPU-hour, per SKU, billed in arrears | Bursty workloads, evaluation, no commitment |
Reserved / committed | Fixed capacity for a term at a discounted rate, often prepaid | Training runs, production inference, the revenue anchor |
Spot / preemptible | Deep discount for revocable capacity | Fault-tolerant batch work |
Fractional | Per MIG slice or shared-GPU unit | Small inference workloads |
Token-metered | Per model token in/out, infrastructure abstracted away | Customers who want inference, not infrastructure |
Most enterprise contracts stack the first two: a reserved base with on-demand overage charges beyond it, structurally identical to a minimum commit with drawdown.
A worked example
A customer signs a 12-month reservation for 64 H100 GPUs at $2.20 per GPU-hour, with on-demand burst at $3.40 per GPU-hour. In a 720-hour month:
Line item | Quantity | Rate | Charge |
|---|---|---|---|
Reserved capacity | 64 GPUs × 720 h = 46,080 GPU-h | $2.20 | $101,376 |
On-demand burst | 8,400 GPU-h | $3.40 | $28,560 |
Storage | 250 TB-month | per GB tier | itemized |
Egress | 90 TB | per GB | itemized |
Total compute | $129,936 |
Two structural things the example shows. The reserved line bills on allocation, not consumption: the customer pays for 46,080 GPU-hours whether they run them hot or idle, because the capacity was theirs. And the burst line is metered consumption, which means the invoice mixes two different billing philosophies on adjacent lines, and the billing system has to rate each correctly against the same contract.
Rates in the example are illustrative. Real H100 on-demand pricing across providers has ranged roughly from $2 to $10+ per GPU-hour depending on provider, region, and interconnect, which is itself a signal of how immature the market's pricing still is.
How does the token layer change GPUaaS billing?
The margin structure inverts. Selling GPU-hours is selling a commodity input: the customer captures the value of what runs on the hardware. Selling token-metered inference (what Rafay calls the token factory model, where the provider hosts models and bills per token) moves the provider up the value chain into AI token pricing, where price attaches to output rather than input.
The billing consequence: the provider now needs two meters (GPU-hours below, tokens above), a cost allocation between them to know inference margins per model, and often a credit layer on top for customers who want predictable spend. That's three pricing systems stacked, and the providers that treat them as one ledger problem rather than three tools will be the ones that can state their margin per tenant per model. Which, at current GPU economics, is not a nice-to-have number...
What does GPUaaS billing demand from infrastructure?
Accurate allocation-state metering per tenant and SKU (see neocloud metering), commit and drawdown logic as native price structures, prepayment handling with the deferred revenue accounting it triggers, and enterprise-grade invoices with line-item detail per cluster and period. Solvimon runs these as one configuration on one ledger: flexible pricing for the commit structures, Meter for the consumption side.
FAQ
Is GPUaaS billing just usage-based pricing?
The on-demand layer is. The reserved layer is closer to capacity subscription with drawdown, and most revenue sits there. The blend is what makes it a distinct billing problem. See usage-based pricing.
Why do providers bill allocation instead of consumption?
Because reserved capacity has opportunity cost: a GPU held for one customer can't serve another. Consumption billing on reserved capacity would hand the utilization risk back to the provider.
What's the difference between GPUaaS billing and neocloud billing?
Neocloud billing is the provider's full commercial stack (compute, storage, egress, inference, support). GPUaaS billing is the compute core of it.
How do prepaid GPU commits get accounted for?
As deferred revenue that recognizes as capacity is delivered, with all the ASC 606 mechanics that implies. Covered in prepaid GPU commits are a deferred revenue problem.
Related
Neocloud metering: the measurement layer
Minimum commit: the structure under reservations
AI token pricing: the layer above the hardware
Ready for billing v2?
Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.
