Provisioned throughput is a bet that your traffic is steady enough to beat per-token pricing. Microsoft publishes every number needed to settle that bet in advance, in two tables most people never open.
What one PTU is
A provisioned throughput unit is a fixed slice of model processing capacity held exclusively for one deployment, billed by the hour from the moment the deployment is created until the moment it is deleted, whether or not a single request arrives. Microsoft states that deployments cannot be paused and that billing stops only on deletion. Partial hours are prorated — a deployment that exists for 15 minutes is charged a quarter of the hourly rate.
PTU quota is model-independent: the same pool deploys any supported model. What is not model-independent is throughput. Microsoft publishes an Input TPM per PTU figure per model, and the spread is enormous. On its sizing article dated 2026-07-29 at the time of writing, gpt-4.1 is listed at 3,000 input TPM per PTU, gpt-5.2 at 3,400, gpt-5 at 4,750 and gpt-4.1-nano at 59,400. Twenty PTUs is twenty times more useful on one of those than on another.
Every per-model figure on this page is quoted from Microsoft’s PTU sizing article, carrying a document date of 2026-07-29 when this page was written. Microsoft revises that table when models ship. Re-read it rather than trusting a cached number, including this one.
The minimums are the real floor
You cannot buy a small provisioned deployment. Microsoft publishes a minimum PTU count and a scale increment per model per deployment type, and for the current Azure OpenAI models the pattern is consistent:
- Global and Data Zone Provisioned — minimum 15 PTUs, scale increment 5. Sizes go 15, 20, 25 and up.
- Regional Provisioned — minimum 50 PTUs with a 50-PTU increment for models such as
gpt-4.1,gpt-5andgpt-5.2; 25 with a 25-PTU increment for smaller models such asgpt-4.1-mini,gpt-4.1-nanoando4-mini. - Non-OpenAI models sold by Azure — considerably higher. Microsoft lists 100 PTUs minimum with a 100-PTU increment for Llama-3.3-70B-Instruct, DeepSeek-R1 and DeepSeek-V3-0324, and no regional provisioned option at all.
Choosing Regional Provisioned for data-residency reasons therefore triples or quadruples your floor on a large model. That is the real cost of the residency requirement, and it is invisible until you try to create the deployment.
Normalised TPM, and why output costs more
Capacity is not consumed evenly by input and output. Microsoft publishes an output-to-input ratio per model that says how many input tokens one output token counts as, and states that for GPT-4.1 and later it is set to match that model’s global standard price ratio between output and input. gpt-4.1 is listed at 4; gpt-5, gpt-5.1 and gpt-5.2 at 8; gpt-5.4 and the gpt-5.6 family at 6.
Cached input tokens are deducted in full — Microsoft states that cached tokens do not consume PTU capacity at all. That makes prompt caching worth more on provisioned than on standard, where it earns a discount rather than a complete exemption. The sizing formula Microsoft publishes is:
input TPM = peak RPM x average prompt tokens
output TPM = peak RPM x average response tokens
normalised TPM = (input TPM x (1 - cache rate)) + (ratio x output TPM)
PTUs required = normalised TPM / (input TPM per PTU)
Microsoft’s own worked example: 1,000 RPM, 200-token prompts, 20-token responses on gpt-5.2 Data Zone Provisioned gives 200,000 + (8 x 20,000) = 360,000 normalised TPM, divided by 3,400 = 105.88, rounded up to 110 PTUs on the 5-PTU increment. At a 50% cache rate the same traffic needs 80.
The break-even calculation
The break-even is the standard per-token price at which a fully utilised PTU deployment costs the same as paying per token. It falls straight out of the table above, and it is worth doing symbolically first because the inputs move independently.
normalised tokens per hour = PTUs x (input TPM per PTU) x 60
hourly cost = PTUs x (rate in $/PTU/hr)
break-even price per 1M = (rate x 1,000,000) / ((input TPM per PTU) x 60)
Notice the PTU count cancels. Break-even does not depend on how many units you buy — only on the rate and on the model’s throughput per unit. Substituting gpt-4.1 at 3,000 input TPM per PTU: one PTU carries 180,000 normalised input-equivalent tokens per hour.
For a rate, the only figure Microsoft has published as a plain number is from its Azure blog of 14 August 2024 announcing self-service provisioned throughput, which quoted $2 per unit per hour for hourly, no-commitment purchasing, alongside savings of “up to 82%” with a monthly reservation and “up to 85%” with a yearly one. Treat that as an illustration of the method rather than a current quote — the current documentation directs you to per-model-family pricing pages, which is a strong hint that a single flat rate no longer describes the product.
Assumption A: rate = $2.00 /PTU/hr (Microsoft blog, 2024-08-14)
Assumption B: gpt-4.1 = 3,000 input TPM/PTU (Microsoft docs, 2026-07-29)
Assumption C: deployment runs at 100% utilisation
1 PTU-hour = 3,000 x 60 = 180,000 normalised tokens
break-even = $2.00 / 0.18M tokens = $11.11 per 1M normalised tokens
With a monthly reservation at the quoted "up to 82%" discount:
effective rate = $2.00 x 0.18 = $0.36 /PTU/hr
break-even = $0.36 / 0.18M = $2.00 per 1M normalised tokens
That is the whole result. Compare the second figure against the model’s current standard input price per million tokens: if standard input costs more than the break-even, a fully utilised reserved deployment is cheaper. And it explains the gap between the two billing modes — at hourly rates the break-even sits far above any plausible token price, which is exactly why Microsoft says in its own billing guidance that hourly billing is for benchmarking and events, not production.
Utilisation is the whole answer
Assumption C is doing most of the work above, and it is the one nobody meets. Because you are billed on deployed capacity rather than consumption, effective cost per token is the break-even price divided by your utilisation. A deployment averaging 50% costs twice the break-even per token; one averaging 25% costs four times it.
The trap is that sizing is done against peak RPM — it has to be, or you throttle at peak — while billing runs against the whole hour. A workload with a 4:1 peak-to-mean ratio and a deployment sized for peak is running at roughly 25% average utilisation by construction. That single ratio, which you can measure today from your existing standard deployment, decides the answer more than any price does.
Microsoft’s own mitigation for this is spillover: overflow requests on a saturated provisioned deployment are routed to a standard deployment in the same resource, either for all requests or per-request via the x-ms-spillover-deployment header. That lets you size the provisioned deployment for the mean rather than the peak and pay per token for the tail, which changes the arithmetic considerably.
Spillover only routes to a standard deployment in the same Azure resource. If your overflow plan involves a second region, a second subscription, or a different provider entirely, that routing decision has to live somewhere in your stack — and it needs to read the 429, honour retry-after-ms, and re-shape the request for whatever it fails over to. Multigrid is an LLM gateway that does exactly that routing and records per-deployment cost so the utilisation figure above is something you can look up rather than estimate.
What a commitment does not buy
Two things, both stated plainly in Microsoft’s billing documentation and both surprising the first time.
A reservation does not reserve capacity. It is a financial discount applied to the PTU billing meter, and Microsoft’s explicit advice is to create the deployment first, confirm capacity exists, and only then buy the reservation to cover it. Buying first risks committing to units you cannot deploy. Reservations also match on deployment type, region and scope — never on model or deployment ID — so a Global Provisioned reservation will not cover a Regional Provisioned deployment, and exchanging between the two types is not supported.
And scaling down is one-way in practice. Microsoft states that reducing a deployment’s PTU count releases that capacity back to the regional pool with no guarantee it is available if you scale back up. The scale-down-overnight strategy that works for virtual machines is specifically warned against here, on capacity-risk grounds rather than cost ones.
Top comments (0)