Research-backed calculator guide

Azure PTU Quota vs Capacity: Pre-purchase Deployment Readiness Checklist

Separate Azure PTU quota from live model capacity before deployment or reservation purchase, with a timestamped evidence checklist and sizing example.

Azure provisioned throughput readiness has two separate gates. Quota is the amount your subscription is allowed to allocate. Capacity is the amount of the selected model and deployment type that Azure can actually place at that moment. A subscription can pass the quota check and still fail deployment because live capacity is unavailable. Microsoft explicitly warns that having PTU quota does not guarantee capacity, and recommends checking capacity before planning a deployment or reservation. ^[1]

This checklist is for the decision immediately before creating or scaling a Microsoft Foundry provisioned deployment. It is not a reservation-price quote and it is not a replacement for Azure’s portal or API response. Record every result with a UTC timestamp, because available capacity can change during the day.

Quota is permission; capacity is placement

PTU quota is a policy limit. Microsoft documents it as the maximum number of PTUs that can be deployed for a subscription, region, and deployment type, with separate pools such as Global Provisioned, Data Zone Provisioned, and Regional Provisioned. Quota itself has no hourly charge. It tells you whether the requested allocation fits the subscription’s allowed envelope. ^[1]

Capacity is a live service resource for a particular model version and SKU. It is allocated when the deployment is created and held for that deployment. It can change with demand across models and regions. Deleting or scaling down a deployment releases capacity, and Azure does not promise that the same capacity will be available when you later scale back up. ^{[1] [5]}

This distinction explains a common misleading result: a portal may show enough unallocated PTU quota while deployment returns a capacity error. The correct response is not automatically “request more quota.” First verify the requested model, version, deployment type, region, minimum, increment, and current Model Capacities result. A quota request helps when the policy limit is too low; it does not turn a full regional capacity pool into free capacity.

The pre-purchase readiness checklist

1. Freeze the deployment identity

Write down the exact model name, model version, model format, deployment type, target region or data zone, subscription ID, and Foundry resource or project. “GPT-5” without a version, or “Azure PTU” without Regional versus Data Zone versus Global, is not enough for a reproducible check. Model version matters because throughput parameters and availability can differ.

Also state the residency and routing constraint. Regional Provisioned keeps inference in the specified Azure region. Data Zone Provisioned stays within a geographic zone. Global Provisioned can route across Azure regions and may offer a wider placement set, but it may not fit a strict single-region requirement. ^[1]

2. Capture quota current and limit

In Foundry, open Manage > Quota > Provisioned throughput unit, select the subscription and region, and record the current allocation and limit for the intended deployment type. Microsoft’s production guidance uses this quota view for current usage and quota requests. ^[6]

Keep the capture as evidence rather than copying only a green “available” label. Record the timestamp, subscription, region, deployment type, current PTUs, limit, and the PTUs already consumed by other deployments. If the limit is too low, request quota through the supported process, but treat approval timing as uncertain until Microsoft approves it.

For programmatic monitoring, the quota documentation distinguishes the Usages API from the Model Capacities API. The former gives a ledger-style view of quota consumed versus limit for a location. It does not prove that a new deployment can be placed.

3. Capture live model capacity

Run the Model Capacities check for the exact model name, version, and format. The REST reference requires those model parameters and returns capacity records with location, SKU name, and available capacity. ^[7] Save the response, request parameters, API version, and timestamp. In the portal, also record any alternative regions suggested by the deployment experience.

Treat this result as a point-in-time observation, not a promise. If available capacity is lower than the requested PTU count, test a smaller deployment only if its minimum and increment still satisfy your throughput objective. Otherwise, evaluate a supported fallback region or deployment type. Do not silently change the model or residency policy just to make a green check appear.

4. Validate minimum and scale increment

A raw calculation such as 73.5 PTUs is not necessarily a valid deployment request. The selected model and deployment type impose a minimum and a scale increment. Microsoft’s sizing guidance says the capacity calculator rounds the raw estimate up to the deployment type’s increment or to the minimum, whichever is larger. ^[4]

For example, a model may require at least 15 PTUs and scale in increments of 5 for Global or Data Zone Provisioned, while Regional Provisioned can have a larger minimum or increment. Confirm the current table for your selected model and version on the day you check. Then calculate both the raw requirement and the deployable rounded requirement.

5. Check supported region and type combinations

Capacity is meaningless if the model does not support the selected deployment type in the selected location. Confirm availability in Microsoft’s model and region documentation and keep the permitted alternatives in the evidence packet. A fallback should include a specific region or zone, the same data-handling policy, an owner who can approve the change, and a maximum wait time before escalation.

6. Decide whether the reservation is premature

PTU hourly billing is based on deployed PTUs, not token consumption. A reservation is a term discount applied to the billing meter, and reservations are loosely coupled to deployments. Microsoft’s stated order is to deploy first, note the deployment type and region details, then purchase a reservation that matches the deployed capacity. Reservations do not guarantee capacity. ^{[5] [6]}

This sequencing protects you from paying for a financial construct while the workload is still blocked by placement. It also prevents a mismatch between the reservation’s deployment type and the capacity you successfully deployed.

7. Define the post-deployment proof

After deployment, run a representative benchmark rather than treating the sizing estimate as a guarantee. Microsoft recommends benchmarking with your traffic shape and observing utilization, tokens processed, and call rate; its production guidance describes a benchmark of at least 10 minutes for steady-state observation. ^[6]

Record the deployed PTUs, actual prompt and response distributions, cache rate, utilization metric, latency, 429 behavior, and spillover or retry outcomes. Keep the original readiness packet beside the benchmark so that future scale-up decisions can distinguish a changed workload from a changed Azure capacity condition.

Worked cost example

Assume the following illustrative planning inputs, not an Azure price quote:

The arithmetic follows Microsoft’s documented sequence: input TPM equals peak RPM multiplied by prompt size; output TPM equals peak RPM multiplied by response size; normalized TPM is effective input plus the model’s output-to-input ratio multiplied by output TPM; PTUs are normalized TPM divided by input TPM per PTU. ^[4] The 3,400 value, ratio of 8, and 5-PTU increment in this table are explicitly illustrative values based on the documented example pattern; verify them for the exact model version before deployment.

Now add a separate financial assumption. Suppose an Azure quote for the selected deployment is $0.50 per PTU-hour, and the deployment runs continuously for 30 days. The illustrative hourly cost is 75 PTUs × $0.50 = $37.50/hour. Using 24 × 30 = 720 hours, the illustrative monthly hourly cost is $27,000. This is an estimate, not a vendor quote. Actual price varies by model family, deployment type, region, currency, agreement, and billing arrangement. If a hypothetical reservation scenario reduced that assumed meter by 20%, the arithmetic would be $27,000 × 0.80 = $21,600, but the 20% is also only a planning assumption. Obtain the current Azure price before approval.

The important readiness conclusion is unchanged by the price: if the target has a 75-PTU quota headroom but the live capacity response shows only 50 PTUs, the purchase decision is not ready. A lower-cost reservation does not solve the placement failure.

Evidence packet template

Create one row or record for every check. The minimum useful packet contains the following fields: check timestamp in UTC; subscription and resource; model and version; format; deployment type; target region or zone; quota current; quota limit; Model Capacities available capacity; minimum PTUs; scale increment; supported fallback locations; portal or API response identifier; checker; and decision expiry.

Set an expiry because capacity is dynamic. For example, “valid for this deployment attempt until 2026-11-02 18:00 UTC” is more honest than “capacity approved.” If the deployment is delayed beyond that window, rerun the live capacity check. Keep the result even when it fails: a failed capacity check explains why a reservation was deferred and gives the next operator a baseline.

A readiness decision can then be stated precisely: Ready to attempt deployment means quota headroom is at least the rounded PTU request, live capacity is at least that request for the exact model and SKU, the minimum and increment are satisfied, and the region/type policy is approved. Not ready means one of those facts is missing or stale. Ready to purchase reservation means the deployment has already succeeded and the reservation scope matches the deployed type and quantity.

For financial reconciliation after deployment, connect the deployment record to the AI API invoice reconciliation calculator. It can help compare the approved PTU assumption with actual billed periods, while the Azure billing page remains the source of the vendor charge.

FAQ

Is Azure PTU quota the same as available capacity?

No. Quota is a subscription policy allowance. Capacity is the live amount Azure can place for a specific model, version, location, and deployment type. You need both enough quota and enough live capacity. The quota check can pass while deployment still fails because capacity is unavailable. ^[1]

Should I request more quota when a PTU deployment fails?

Only after identifying which gate failed. If the requested PTUs exceed the quota limit, a quota request or reallocation may be appropriate. If quota is sufficient but the Model Capacities response is too small, requesting more quota may not fix the immediate problem. Try an approved fallback region, a smaller valid deployment, or a later retry while preserving the required model and residency constraints.

Does an Azure PTU reservation guarantee deployment capacity?

No. Microsoft describes reservations as a discount applied to PTU billing, not as a service-capacity reservation. Deploy first, confirm the deployed PTUs and deployment type, and then purchase the matching reservation. ^{[5] [6]}

How often should I recheck capacity?

Recheck immediately before the deployment attempt and again before a material scale-up. Capacity changes dynamically, and scaling down releases capacity that may not be available later. Use a timestamped portal result or Model Capacities API response instead of relying on an earlier screenshot or a previous successful deployment. ^{[1] [5]}

Can I use the PTU sizing estimate as a capacity reservation?

No. Sizing estimates the PTUs your workload may require from RPM, token shape, cache rate, and model parameters. It does not reserve Azure capacity. Benchmark representative traffic after deployment, monitor utilization, and treat the estimate as an input to the placement and cost decision rather than as proof of availability. ^{[4] [6]}

Limitations and assumptions

This checklist does not provide a live quota or capacity result for your subscription. Portal permissions, model availability, region policy, offer eligibility, and Microsoft’s current service state can change. The worked cost numbers are deliberately hypothetical and should not be read as Azure pricing. The sizing example assumes the stated model parameters, a stable 500 RPM peak, fixed average token sizes, and a 25% cache rate; real traffic variance can change the required PTUs. Verify current Microsoft documentation and your own API response at the time of deployment.