> ## Content Index > Fetch the complete content index at: https://www.sotkn.com/llms.txt > Use this file to discover other available public pages before exploring further. # What Is Provisioned Throughput? Why Idle Inference Seats Still Bill - URL: https://www.sotkn.com/explained/provisioned-throughput-explained/ - Published: 2026-10-27T01:13:25.000Z - Updated: 2026-10-27T01:13:25.000Z - Description: Provisioned throughput is reserved model capacity billed by the hour, not by the token. Idle seats still bill. Live capacity, not quota, is the stuck step. - Author: Sean - Tags: #desk-explained, Mechanism EXPLAINED · Mechanism · Last reviewed: 27 Oct 2026 · Next review: after Microsoft, Amazon and Alphabet report calendar-fourth-quarter 2026 results Provisioned throughput is reserved model-processing capacity that a hyperscaler holds for one customer’s deployment and bills by the hour — or by a term reservation — whether or not any tokens are served. It is not a token meter, and it is not a GPU-hour lease. It is a seat on the model that stays on the invoice if it sits empty. **In short.** Microsoft Foundry, Amazon Bedrock and Google Vertex sell the same idea as PTUs, model units and GSUs. You size units; the cloud holds compute; the meter is units deployed, not tokens consumed. Microsoft charges hourly whether or not requests run, and you cannot pause. Amazon bills until you delete, committed or not. Google’s unused throughput does not carry over. Our read: this is how hyperscalers convert scarce accelerators into a prepaid inference product. The stuck step is live capacity in the region and model you need — not quota on a portal page. Why an investor cares: the AI bill that reaches a hyperscaler’s cloud line is now a mix of [token](https://www.sotkn.com/explained/ai-tokens-explained/) meters, [GPU hours](https://www.sotkn.com/explained/gpu-as-a-service-explained/) and this third product. Tokens bill a shared model. GPU hours bill a card. Provisioned throughput bills a reserved slice of the model without handing you the rack. Our [tokens vs GPU hours](https://www.sotkn.com/explained/ai-tokens-vs-gpu-hours/) page is the conversion between the first two. This page is the reserved seat. ## What is provisioned throughput? Provisioned throughput holds a fixed amount of model processing capacity exclusively for one customer. Microsoft’s Foundry docs put the contrast in one sentence: unlike a standard deployment, where capacity is shared and throughput can vary with demand, a provisioned deployment holds a fixed amount of processing capacity for your use, whether or not requests are being made. Three clouds, three unit names, one cash clock. Microsoft sells **PTUs** — a generic slice of model processing, allocated by you and held by Foundry. The same quota can deploy any supported model, but it is per subscription, region and type (Global, Data Zone or Regional), and tokens per minute per PTU depend on the model. Amazon Bedrock sells **model units** (and a later flavour billed by tokens). An MU states input and output tokens per minute for a named model. Commitment is none, one month, or six months; longer terms discount the hourly price. Customised models require Provisioned Throughput before they can be invoked. Google sells **GSUs**, measured in tokens (or characters, or images) per second. As of this review, Gemini 2.5 Pro is listed at 650 tokens per second per GSU. The order is tied to one project, region, model and version. Provisioned traffic is served before on-demand. The unit is not a GPU. You do not get a serial number or a rack position. You get a promised rate on a model, in a place, for a term. ## How does it work? First you estimate a shape: requests per minute, average prompt size, average response size, and — where the cloud counts it — the cache rate. Output tokens cost more capacity than input tokens. On Foundry, for `gpt-5` and `gpt-5.2`, one output token counts as eight input tokens toward the utilisation limit. Microsoft’s own worked example uses `gpt-5.2` on Data Zone provisioned throughput: 1,000 requests per minute, 200-token prompts, 20-token responses, no cache. Input TPM = 1,000 × 200 = 200,000\. Output TPM = 1,000 × 20 = 20,000\. Normalised TPM = 200,000 + (8 × 20,000) = 360,000\. At 3,400 input TPM per PTU, that is 360,000 ÷ 3,400 = 105.88, which rounds up to **110 PTUs**. With cache, the same page drops it to **80 PTUs**. Those two figures are Microsoft’s arithmetic, not ours. Then you try to deploy. Quota is a policy ceiling on your account. Capacity is what the region has left for that model right now. Microsoft: having PTU quota does not guarantee capacity; if the region is short, the deployment fails; capacity changes through the day; scale-down releases units to the pool with no promise you can take them back. Amazon makes you request MU increases through Support before a committed purchase. Google’s seat in one region is not a seat in another. Then you get billed. Microsoft’s $/PTU/hr meter starts when the deployment is created and stops only when it is deleted; you cannot pause it. A 1-month or 1-year Azure Reservation discounts that meter — a financial discount, not a hold on the machines. Deploy first, then buy the reservation: the reservation does not guarantee capacity. Azure’s public reservations page states a **70%** saving on GPT-4o global provisioned throughput for a 1-year term versus hourly, based on pricing as of 1 May 2025\. Amazon bills until you delete; a one- or six-month MU commitment cannot be deleted early, and the provision fee is charged if you run no inference. Google’s unused throughput does not carry over. If the seat is full, Microsoft can optionally spill extra requests onto a standard pay-per-token deployment in the same resource when the provisioned side returns a `429`. That is a relief valve. It is not a second reserved seat. ## How is it different from tokens and GPU hours? Three bills, three things you are buying. | Bill | What you buy | When the meter runs | Who holds the accelerator | | -------------------------- | --------------------------- | -------------------------------------------------------- | ------------------------------------ | | **Tokens** | A share of a model API | When a request is served | The cloud, in a shared pool | | **GPU hours** | Time on a card or cluster | While the instance exists (reserved) or runs (on-demand) | You, as a tenant of a rack | | **Provisioned throughput** | A reserved slice of a model | While the deployment exists, used or not | The cloud, locked to your deployment | Tokens are the unit in our [AI tokens explainer](https://www.sotkn.com/explained/ai-tokens-explained/) and in [tokens vs GPU hours](https://www.sotkn.com/explained/ai-tokens-vs-gpu-hours/). GPU hours are the unit in [GPU as a service](https://www.sotkn.com/explained/gpu-as-a-service-explained/) and [reserved vs on-demand GPUs](https://www.sotkn.com/explained/reserved-vs-on-demand-gpu/). Provisioned throughput is the missing middle: you pay as if you had reserved hardware, but you hold a rate on a model, not a serial number on a GPU. Foundry shelves four products next to each other: standard (pay-per-token, no latency SLA), priority processing (pay-per-token with a latency target, no term), provisioned (per PTU per hour, with a latency target) and batch (discounted tokens, no latency promise). Only provisioned bills you for the empty seat. A [take-or-pay GPU contract](https://www.sotkn.com/explained/take-or-pay-gpu-contracts-explained/) rhymes and is not the same paper. Take-or-pay is offtake on a neocloud cluster. This is offtake on a hyperscaler model API. The empty-seat clock is shared. The asset is not. ## Why does it bind? It binds twice: on the invoice, and on the floor. Utilisation does not write the invoice. Microsoft bills the full deployed PTU count regardless of tokens; the reservation price assumes 24×7 deployment; unused reserved PTUs in a period are lost. Amazon charges the provision fee whether you run inference or not. Google’s unused throughput does not accumulate. Our arithmetic, from Microsoft’s 110-PTU `gpt-5.2` size: 110 PTUs held for 24 hours is **2,640 PTU-hours** that day, even at zero tokens. That is the idle-seat bill. We do not convert it to dollars; list prices move by model family and region. On the floor, the scarce object is still an accelerator in a powered hall. A PTU, MU or GSU is a claim on that object, sliced so the cloud can sell it without handing over the rack. When the region is out of capacity, quota does not help. Microsoft says capacity changes through the day and that scaling down to save hourly cost can leave you unable to scale back up. That is the same bind our [hyperscalers stack](https://www.sotkn.com/stack/hyperscalers/) names at hall scale: money moves first, live capacity later. Cached tokens are a relief, not an escape. Microsoft deducts them 100% from PTU utilisation, which is why its example falls from 110 PTUs to 80\. A reservation bought at 110 does not shrink with the cache. ## Who gets paid — and where is the stuck step? Four groups of cash. **The hyperscaler** is paid on the unit meter — PTU-hours, MU-hours, GSU-hours — and again on overflow that spills onto tokens, used or not. A 1-year Foundry reservation pulls that bill forward; Amazon’s one- and six-month MU terms do the same at a shorter clock. This is cloud revenue that does not wait for a token. It does wait for a deployable chip in a live region. **The model lab** is paid when the reserved model is a third-party model on that cloud — OpenAI on Azure, Anthropic or others on Bedrock — under whatever share the hosting deal sets. We do not have a primary split, and we will not invent one. On Bedrock, a custom model cannot be invoked until the seat is bought. **The chip and packaging chain** is paid earlier, when the hyperscaler buys the GPUs, TPUs and custom accelerators that make a PTU possible. The invoice is how the cloud recoups, hour by hour, the spend our [AI capex](https://www.sotkn.com/explained/ai-capex-explained/) and [cash capex](https://www.sotkn.com/explained/cash-capex-explained/) pages track. Who buys those GPUs is a [Players](https://www.sotkn.com/explained/who-buys-ai-gpus/) question. **The customer** pays for a latency target and a reserved rate, not a promise that more units will be there next week. Microsoft: reservations do not guarantee capacity. The stuck step is deployable capacity for the model and region you sized — not the token price, not the reservation paperwork. Microsoft says a quota request may take several days; capacity can be gone by the afternoon. Their worked reservation example of 300 global PTUs reserved against 100 deployed leaves 200 paid for, unused, with no carry-forward. Our read: a hyperscaler gets paid for inference by the seat, not by the drink, and keeps the rack. You can book the seat only if the chip is already plugged in. ## What would change the view? - **A cloud publishes live, dated PTU / MU / GSU availability by region and model.** The stuck step would then have a public clock. - **On-demand token deployments carry a matching latency SLA without a term.** The reason to buy the empty seat would thin out. - **Reservation discounts collapse on the public list.** Microsoft’s 70% GPT-4o global figure is dated 1 May 2025 and is model-specific. - **Custom Bedrock models no longer require Provisioned Throughput.** Fine-tunes would sit on the token meter. ## Common misconceptions - **People assume provisioned throughput is a GPU reservation.** Actually it is a reserved rate on a model API. You do not get the card. GPU hours are a different bill: [reserved vs on-demand GPUs](https://www.sotkn.com/explained/reserved-vs-on-demand-gpu/). - **People assume a reservation books the machines.** Actually, on Azure, a reservation discounts the PTU meter. It does not reserve capacity on the service. Deploy first, then buy the discount. - **People assume unused units roll forward.** Actually Microsoft’s unused reserved PTUs in a period are lost; Google’s unused throughput does not carry over; Amazon’s committed term is charged whether you run inference or not. - **People assume quota is capacity.** Actually quota is a policy ceiling. Capacity is what the region has left to deploy right now. Only the second can fail a deploy. ## FAQ **What is provisioned throughput?** Provisioned throughput is reserved model-processing capacity that a hyperscaler holds for one customer’s deployment and bills by the unit-hour — Microsoft PTUs, Amazon model units, Google GSUs — whether or not any tokens are served. It is a seat on the model, not a token meter and not a GPU lease. **How is provisioned throughput different from paying per token?** Pay-per-token bills when a request is served, on shared capacity. Provisioned throughput bills for the units you deployed, for as long as the deployment exists, even if it sits idle. Overflow can still spill back onto the token meter when the reserved seat is full. **How is it different from reserved GPU hours?** Reserved GPU hours rent a card or cluster. Provisioned throughput reserves a rate on a hosted model. You pay a similar empty-seat clock, but you never hold the accelerator, and you cannot move it. **Does a reservation guarantee capacity?** No. Microsoft says Foundry reservations are a financial discount on the PTU meter and do not guarantee that capacity is available. The documented sequence is to create the deployment first, then buy the reservation. **Is this a list of stocks to buy or sell?** No. This page explains how provisioned throughput works and where the money goes. It does not rank companies or give buy or sell calls. Not investment advice. Do your own research. ## Related terms Related: [AI tokens](https://www.sotkn.com/explained/ai-tokens-explained/); [GPU as a service](https://www.sotkn.com/explained/gpu-as-a-service-explained/); [reserved vs on-demand GPUs](https://www.sotkn.com/explained/reserved-vs-on-demand-gpu/); [tokens vs GPU hours](https://www.sotkn.com/explained/ai-tokens-vs-gpu-hours/); [take-or-pay GPU contracts](https://www.sotkn.com/explained/take-or-pay-gpu-contracts-explained/); [AI capex](https://www.sotkn.com/explained/ai-capex-explained/); [hyperscalers](https://www.sotkn.com/explained/hyperscaler-explained/). ## Markets and stack doors Layer: [Hyperscalers](https://www.sotkn.com/stack/hyperscalers/). Also: [Neoclouds](https://www.sotkn.com/stack/neoclouds/) and [Semiconductors](https://www.sotkn.com/stack/semiconductors/). Markets: [US](https://www.sotkn.com/markets/us/) and [China](https://www.sotkn.com/markets/china/). Company models: [What Microsoft does](https://www.sotkn.com/stack/hyperscalers/what-does-microsoft-do/), [What Amazon does](https://www.sotkn.com/stack/hyperscalers/what-does-amazon-do/), [What Google does](https://www.sotkn.com/stack/hyperscalers/what-does-google-do/). [Get the Wire](https://www.sotkn.com/#/portal/signup) — short daily notes when cloud capacity and capex move. **How we check this** Figures come from Microsoft Foundry Learn pages, Azure’s reservations offer page (70% GPT-4o global, 1 May 2025), Amazon Bedrock user-guide pages, and Google Cloud GSU pages. The 110-PTU and 80-PTU sizes are Microsoft’s worked example. The 2,640 PTU-hours-a-day figure is our arithmetic from that size. We do not use secondhand PTU list prices. Where we interpret, it is labelled “our read”. Not investment advice. Do your own research. **Last reviewed:** 27 Oct 2026 · **Next review:** after Microsoft, Amazon and Alphabet report calendar-fourth-quarter 2026 results Spot an error? [Tell us](mailto:sean@thekopinotes.com) and we will correct it and note the change here. [Our editorial standards →](https://www.sotkn.com/editorial-standards/) ## Sources 1. [Microsoft Learn — Provisioned throughput for Foundry Models](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput?ref=sotkn.com) 2. [Microsoft Learn — Provisioned throughput billing](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput-billing?ref=sotkn.com) 3. [Microsoft Learn — Determine PTU sizing](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/provisioned-throughput-sizing?ref=sotkn.com) 4. [Microsoft Learn — Foundry Provisioned Throughput Reservations](https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/microsoft-foundry?ref=sotkn.com) 5. [Microsoft Azure — Azure reservations](https://azure.microsoft.com/en-us/pricing/offers/reservations?ref=sotkn.com) (70% GPT-4o global, 1 May 2025) 6. [Amazon Bedrock — Provisioned Throughput](https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html?ref=sotkn.com) 7. [Amazon Bedrock — Purchase a Provisioned Throughput](https://docs.aws.amazon.com/bedrock/latest/userguide/prov-thru-purchase.html?ref=sotkn.com) 8. [Amazon Bedrock — Delete or cancel auto renew](https://docs.aws.amazon.com/bedrock/latest/userguide/prov-thru-delete.html?ref=sotkn.com) 9. [Google Cloud — Provisioned Throughput supported models](https://cloud.google.com/vertex-ai/generative-ai/docs/provisioned-throughput/supported-models?ref=sotkn.com) 10. [Google Cloud — Calculate Provisioned Throughput requirements](https://cloud.google.com/vertex-ai/generative-ai/docs/provisioned-throughput/measure-provisioned-throughput?ref=sotkn.com) [Sean](https://www.sotkn.com/author/sean/) Writes Second Order by TKN — a plain-English map of AI infrastructure and semiconductors. Focus: who gets paid, where money sticks, and which step is stuck. [Author page →](https://www.sotkn.com/author/sean/) · [Editorial standards →](https://www.sotkn.com/editorial-standards/)