Provisioned throughput is a reservation against model-serving capacity: instead of paying per token on shared infrastructure, you pay a fixed rate for dedicated processing capacity held around the clock. The unit differs by provider — Provisioned Throughput Units (PTUs) on Azure, Generative AI Scale Units (GSUs) on Google — but the contract is the same: a provisioned deployment holds a fixed amount of processing capacity exclusively for your deployment’s use, whether or not requests are being made, while standard deployments share capacity across customers. Reserve when traffic is predictable and latency-critical; stay metered while it is exploratory or spiky.
Because you pay for capacity rather than tokens, the decision is utilisation math, not price shopping. This guide covers what changes when you reserve, how each provider sizes its units, the commitment rules that bind you, and a worksheet to run before signing anything. Provider details were verified against current Azure and Google documentation in October 2026.
What Reserved Capacity Changes
The immediate change is the billing meter and the latency floor. Pay-as-you-go deployments share capacity with other customers, so throughput varies with demand; a provisioned deployment buys a defined latency target per model and a fixed bill. Azure summarises the trade-off across four deployment modes:
| Mode | Billing basis | Latency target | Best fit |
|---|---|---|---|
| Standard | Pay per token | None | Development, testing, variable traffic |
| Priority tier | Pay per token at a priority rate | Defined per model | Latency-sensitive without commitment |
| Provisioned | Fixed rate per unit-hour | Defined per model | Predictable, mission-critical baseload |
| Batch | Pay per token at a discounted rate | None | Async bulk processing |
Two of those rows deserve attention before you jump to reservations. Priority tiers exist precisely for teams that need consistent latency without a long commitment, and batch mode exists for workloads with no latency requirement at all. If your workload is asynchronous, batch inference at a discounted token rate is usually the cheaper first move.
Sizing Azure PTUs Step by Step
Azure converts your request shape into a normalized tokens-per-minute figure and divides it by the model’s input TPM per PTU. Three factors drive the calculation:
- Request shape. Expected requests per minute, average prompt size and average response size, measured from production logs rather than estimates. The sizing is only as good as the traffic sample behind it.
- Output-to-input ratio. Output tokens consume more processing capacity than input tokens. Each model publishes a ratio expressing how many input tokens one output token equals for capacity purposes; for GPT-4.1 and later Azure OpenAI models, that ratio matches the model’s global standard pricing ratio between output and input tokens.
- Cache rate. Cached input tokens do not consume PTU capacity, so a higher prompt-cache hit rate directly reduces the units you must buy.
On money: Azure provisioned deployments are billed at an hourly rate based on the number of PTUs deployed, regardless of the number of tokens consumed — the meter starts when the deployment is created and stops when it is deleted. For sustained production, Azure Reservations discount the meter in exchange for a 1-month or 1-year commitment, and the reservation attaches to the billing meter rather than to a specific deployment. Critically, a reservation does not guarantee capacity: deploy first to confirm capacity exists, then purchase.
Quota and capacity are separate gates. Quota is a free policy limit per subscription, region and deployment type; capacity is the finite pool of units actually available for a model version, and it fluctuates through the day. Deleting or scaling down a deployment releases its capacity back to the region pool, with no guarantee the same capacity can be re-created later.
For burst tolerance, Azure offers spillover: overflow requests are redirected to a standard deployment in the same resource when the provisioned deployment returns errors like 429, either for all requests on the deployment or per request via a header. Spillover works for Azure OpenAI Foundry models but not for other providers’ models on the platform, so check model support before designing around it.
How Google Structures Commitments
Google’s equivalent is Provisioned Throughput, measured in GSUs and purchased as a subscription scoped to a model, model version and region. The sizing flow mirrors Azure’s: feed queries per second, input and output tokens per query, modality token counts and an average cache-hit percentage into the Generative AI scale unit estimator, then adjust the GSU count before ordering.
The commitment rules differ more than the sizing. Google now offers 1-week terms for select models so a team can hold capacity through a launch or seasonal spike without a monthly or yearly commitment, and change orders can be scheduled up to two weeks in advance for select models — shifting capacity strategy from reactive scaling to planned ramps. Monthly subscriptions can auto-renew; weekly terms cannot.
The binding constraints: you cannot cancel an order in the middle of its term (though you can increase GSUs), changes such as model swaps or region moves are typically fulfilled within 10 business days, and model changes stay within a single publisher — a switch from Gemini 2.5 Flash to Gemini 2.5 Flash-Lite is permitted, a switch to another vendor’s model is not. Overage above the reserved amount is billed as standard pay-as-you-go by default and can be controlled per request. Teams expecting more than 30,000 queries per minute should request a quota adjustment before ordering, because a reservation does not bypass the platform’s per-region request quota.
A Worksheet Before You Sign
Run this pass before any commitment, treating it as a checklist rather than a one-off calculation:
- Measure four weeks of production traffic: requests per minute, average input tokens, average output tokens and cache hit rate.
- Compute normalized tokens per minute using the provider’s published output-to-input ratio, and discount cached tokens.
- Divide by the per-unit capacity for your exact model version, then round up to the minimum deployment size.
- Price two scenarios at your measured volume: pure pay-as-you-go versus reserved units at target utilisation. A reservation only wins when the units stay busy; idle reserved capacity is the most expensive tokens you will never generate.
- Verify quota and, separately, real capacity in the target region before purchase — on either platform.
- Decide the overflow policy up front: spillover on Azure, pay-as-you-go overage on Google, per deployment and per request.
Latency requirements deserve their own budget line. Define which of your requests are genuinely interactive and measure them the way users feel them — splitting latency into time-to-first-token and inter-token latency — before assuming that a reservation is what your p99 needs.
Finally, treat the reservation as a FinOps object: it is a fixed cost with a utilisation curve. Track reservation utilisation in your cloud billing tooling, attribute the fixed spend to the workloads it serves, and re-run the sizing pass whenever the request shape changes materially. A reservation sized for last quarter’s traffic silently becomes either stranded capacity or a throttling incident.