Standard deployments bill per token, and their latency drifts under load. That is fine right up until your busiest hour returns an HTTP 429 with a Retry-After header, and the on-call engineer is reading rate-limit responses instead of a dashboard. When that happens you have three levers, and picking between them is the whole job of this part. Keep paying per token on Standard, reserve capacity with provisioned throughput units, or hand the work to Batch and wait for it.

Part 4 covered the two deployment paths, serverless against managed compute. This part lives inside serverless and splits it open, because serverless is not one billing model. It is a matrix, and the wrong cell in that matrix is how teams end up either throttled at peak or paying for reserved capacity that sits idle two thirds of the day.

Two billing models, three places to run

The deployment type you pick sets three things at once: how you pay, where your prompts get processed, and how steady your latency stays. Start with how you pay, because that is the axis that actually moves your bill. Standard is pay-per-token: you send tokens, you get tokens back, you pay for what you used, and an idle endpoint costs nothing. Provisioned is reserved capacity: you buy a fixed block of model processing power measured in provisioned throughput units, and you pay for that block by the hour whether requests arrive or not. Batch is pay-per-token again, but at half the Standard rate, in exchange for giving up real-time responses.

The second axis is where the request is allowed to run. Global routing spreads traffic across Azure capacity worldwide for the best availability and the highest starting quota. Data Zone keeps processing inside a Microsoft-defined boundary, the US or the EU Data Boundary, for teams with residency rules. Regional pins the work to the single region you deployed in. Cross the two axes and you get the named SKUs the portal shows you: GlobalStandard, GlobalProvisionedManaged, GlobalBatch, DataZoneStandard, DataZoneProvisionedManaged, DataZoneBatch, plain Standard, and ProvisionedManaged for a single region. Two more sit off to the side. Developer is a cheap, no-SLA tier for evaluating fine-tuned models that self-deletes after 24 hours. Instant access lets you call some models by name with no deployment at all, which is handy for a first test but not something to build production on.

Source: Microsoft Foundry deployment types reference, SKU code column.

What a PTU actually buys you

A provisioned throughput unit, or PTU, is a fixed block of model processing capacity you reserve. You tell Foundry how many PTUs to hold, and it sets that compute aside for your deployment whether or not requests are hitting it. That is the trade in one sentence: you stop sharing a multi-tenant pool and its variable latency, and in return you pay for the block continuously. On a busy, steady deployment that is a bargain. On a quiet one it is money on fire.

Four properties of PTUs decide how you plan around them. Quota is model-independent, so the same pool of PTUs can serve any supported model; you do not buy PTUs for one specific model. Quota is region-specific and per deployment type, so PTUs granted for Global Provisioned in East US do nothing for Data Zone Provisioned in West Europe. Throughput per PTU varies by model, because a heavier model needs more PTUs to serve the same tokens per minute as a lighter one. And every model sets a minimum deployment size, so you cannot buy a single PTU for a large model and expect it to run.

GPT-4o minimums and increments; other models differ. Confirm the current values on the PTU sizing page before you plan. Regional carries a much higher floor than Global.

Billing runs one of two ways. Hourly billing charges a rate per PTU per hour from the moment you create the deployment until you delete it, which suits short jobs like benchmarking a model or scaling up for one event. For anything sustained, an Azure reservation commits you to a month or a year of PTUs at a discounted effective rate. The reservation is a financial instrument applied to the PTU meter, not to a specific deployment, so you can buy it once and let it cover the deployments you already confirmed will run.

How many PTUs does your workload need?

Sizing a PTU deployment is not guesswork, and it is not one number off a slide. Three inputs drive it. The first is your request shape: expected requests per minute, average input token count, and average output token count. The second is the output-to-input ratio, because generating an output token costs more capacity than reading an input token, and each model publishes how many input tokens one output token is worth for capacity math. The third is your cache rate, the fraction of input tokens served from the prompt cache, because cached tokens do not consume PTU capacity and a high cache rate lowers the PTUs you need.

Those inputs collapse into a single normalized tokens-per-minute figure, which you divide by the model’s input-TPM-per-PTU value to get a raw PTU count. Then you round up to the model minimum and its increment, so a raw figure of 13 on GPT-4o Global becomes 15, and a raw figure of 16 becomes 20. Do this in the Foundry capacity calculator rather than a spreadsheet the first few times; the per-model constants change and the calculator carries the current ones. The point of sizing is not precision to the PTU. It is landing close enough that you are not paying for double the capacity you use, and not so tight that a normal traffic spike returns 429s.

Standard or provisioned? Run the utilization math

Here is the decision that costs teams the most money when they get it wrong. A reserved PTU deployment bills every hour of the month, 720 hours, no matter how many of those hours actually carry traffic. A Standard deployment bills only for tokens processed. So the question is not which is cheaper in the abstract. It is what fraction of your reserved capacity you will actually keep busy. Below a break-even utilization, Standard wins on its zero idle cost. Above it, the reservation wins because per-token billing at that volume overtakes the flat reserved rate.

My rule of thumb is a break-even near 50% sustained utilization once you factor in a reservation discount. Under that, stay on Standard. Over it, and especially for a workload that runs around the clock, provision. The exact crossover moves with the current per-PTU and per-token prices, so plug today’s numbers from the pricing page before you commit, but the shape holds: provisioned is a bet that your capacity stays busy.

Priority processing, the middle option most teams miss

The Standard-versus-provisioned choice is not actually binary, and a newer preview tier fills the gap between them. Priority processing is a pay-per-token mode that carries a defined latency target per model, so you get more consistent low latency than plain Standard without committing to a month of reserved PTUs. Global Standard and Data Zone Standard both support it on a pay-as-you-go basis. It is the option for a workload that is latency sensitive enough to hurt on Standard but too spiky or too new to size a reservation against with any confidence.

I treat priority processing as a bridge, not a destination. Reach for it when a product team says the tail latency on Standard is embarrassing but you do not yet have a stable enough traffic profile to size PTUs, or when you want to hold the line on latency for a few weeks while you gather the utilization data that the reservation decision needs. Because it is still in preview, keep it off anything with a strict uptime commitment until it reaches general availability, and read the current latency target for your specific model rather than assuming a number. It buys you time, and time is usually what the sizing decision is short of.

Batch trades speed for a 50% discount

Batch is the deployment type people forget they have. Instead of sending one request at a time and waiting, you upload a file of many requests, Global Batch or Data Zone Batch processes them asynchronously with a 24-hour target turnaround, and you pay half the Global Standard token rate. The turnaround is a target, not an SLA, so a job can finish in minutes or take the full window. For work that is not time sensitive, that is a straight 50% cut for doing nothing but waiting.

The detail that makes Batch worth wiring in is its separate enqueued token quota. Batch requests draw from their own quota pool, not the tokens-per-minute ceiling your live traffic uses, so a large overnight job does not starve the chat app your users are on during the day. That isolation is the real feature. Nightly document enrichment, bulk summarization, sentiment scoring over a backlog, and content generation across a catalog all belong here, off to the side, protecting your online quota rather than competing with it.

When provisioned capacity is not available

You sized the deployment, you have the quota, and the create call still fails because the region has no free capacity for that model version right now. This is normal, not a bug, and it is the reason you never buy a reservation before you deploy. The fix has a short list of moves: try Global Provisioned instead of a regional type, because global routing draws from a wider pool; ask for fewer PTUs and scale up later; retry, since capacity frees up as other customers delete deployments; or pick a different region the portal reports as having capacity. The Foundry deployment experience will tell you which regions have room when your target does not.

Here is the create call itself for a Global Provisioned deployment at the GPT-4o minimum of 15 PTUs. The hour the deployment succeeds is the hour billing starts, so treat this as a production change, not a scratch experiment.

# create a Global Provisioned gpt-4o deployment at 15 PTU, the minimum
az cognitiveservices account deployment create 
  --name <your-foundry-resource> 
  --resource-group <your-rg> 
  --deployment-name gpt-4o-ptu 
  --model-name gpt-4o 
  --model-version <current-gpt-4o-version> 
  --model-format OpenAI 
  --sku-name GlobalProvisionedManaged 
  --sku-capacity 15

# confirm the deployment reports Succeeded and holds 15 PTU
az cognitiveservices account deployment show 
  --name <your-foundry-resource> 
  --resource-group <your-rg> 
  --deployment-name gpt-4o-ptu 
  --query 'properties.provisioningState'

Expected: the create returns and the show command prints Succeeded, with 15 PTU of GlobalProvisionedManaged capacity held for the deployment and the hourly meter running.

Failure mode: an InsufficientQuota error means you are asking for more PTUs than your quota allows, so request more on the Quota page. A capacity error at create time means quota is fine but the region has no free PTUs right now; drop the count, switch to a region with capacity, or retry later. Neither creates a partial deployment, so the same command is safe to rerun once you fix the cause.

Spillover catches the overflow

A provisioned deployment has a hard ceiling: when the PTUs are fully used, extra requests come back as 429s. Spillover is the safety valve. It is an optional setting that automatically reroutes those overflow requests to a matching Standard deployment in the same Foundry resource, so a traffic burst degrades to pay-per-token instead of failing outright. You can turn it on for every request on the deployment, or control it per request with the x-ms-spillover-deployment header when you only want certain calls to fall back.

This changes how you size. Instead of buying enough PTUs to cover your peak, which means paying for peak capacity all month, you size the reservation to your steady load and let spillover absorb the spikes on Standard rates. One caveat that catches people: spillover works for Azure OpenAI models on provisioned throughput, but partner models like Azure DeepSeek and Meta Llama do not support it today, so a provisioned deployment of one of those has no fallback and you plan capacity the hard way.

If you want the same billing decision on the AWS side of the house, the split between on-demand, provisioned, and batch on Amazon Bedrock pricing is the near-exact mirror of this one. Different names, same three levers, and the same utilization math decides the reserved-versus-on-demand call there too.

When a PTU reservation actually pays off

The recommendation is short. Start every new deployment on Global Standard. It needs no capacity request, costs nothing when idle, and gives you the highest quota and the best availability while you learn the real shape of your traffic. Move to a provisioned deployment only when a measured number forces it: sustained utilization comfortably above the 50% break-even, or a hard requirement that tail latency stay flat. When you do provision, deploy first to confirm capacity, then buy the reservation to lock in the discount, and size the reservation to steady load with spillover covering the peaks rather than buying capacity for your busiest minute. Send anything asynchronous to Batch, both for the 50% cut and to keep it off your online quota.

Do not provision because a capacity plan slide said enterprises use PTUs. Provision because your own utilization number crossed the line. Next, Part 7 gets under the deployment types into the silicon: the ND-series GPUs and the Maia accelerators that these PTUs and Standard endpoints actually run on, and what that hardware means for the throughput you just sized. Before you read it, pull one week of tokens-per-minute metrics on your busiest deployment and compute its utilization against a candidate PTU count. That single number tells you whether the rest of this decision is even live for you. [AUTHOR: add anecdote about a team that reserved PTUs at peak sizing and ran them at 20% utilization for a quarter.]

References

• Deployment types for Microsoft Foundry Models
• Provisioned throughput for Foundry Models
• Determine PTU sizing for a workload
• Azure OpenAI Service pricing

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts