11.4 Provisioned Throughput Units for High-Volume Workloads

Provisioned Throughput Units for High-Volume Workloads

Quick Answer: Provisioned throughput units (PTUs) reserve Foundry model capacity. You are billed hourly for the PTU count you deploy, even at idle. Quota is per subscription, per region, per deployment type and is shared across supported models. Minimum PTUs vary by model. Azure Reservations discount the meter but do not guarantee capacity. Pay-as-you-go Standard bills per token. PTU quota is not Azure Machine Learning compute quota.

Domain 3 asks you to configure provisioned throughput units for high-volume workloads. Section 11.1 introduced provisioned SKUs as a Serverless API type. Section 11.3 used spillover when those SKUs return 429. This section is the capacity and billing model you must size, request, and operate.

A provisioned deployment holds a fixed amount of processing capacity whether or not requests arrive. Standard (pay-per-token) shares capacity across customers; throughput and latency vary with demand. Batch is cheaper and asynchronous. Priority processing is still pay-per-token, with a defined latency target and no long-term PTU commitment. Provisioned is the SKU you choose when the workload is mission-critical, high scale, and latency-sensitive and you can estimate tokens.

Quota, capacity, billing, and reservations

Three controls look similar on a portal page and are not interchangeable.

Quota is the maximum PTUs your subscription may deploy in a region for one deployment type. Global Provisioned, Data Zone Provisioned, and Regional Provisioned are separate quota pools. East US quota does not apply to West Europe. Quota has no hourly cost. Eligible subscriptions receive a default amount; request more with the quota form from the Foundry Quota page. Approval can take days.

Capacity is the PTUs that actually exist to be placed for a model version in that region right now. Having quota does not guarantee capacity. If the region is full, create fails even at 100 percent unused quota. Capacity moves through the day. Scaling down or deleting releases capacity permanently to the regional pool; there is no hold for later. Check availability in the Foundry deployment wizard or the model capacities API before a launch or a reservation purchase.

Hourly billing charges $ / PTU / hour for the deployed count, not for tokens consumed. A 300 PTU deployment costs 300 times the hourly rate for every hour it exists. Partial hours prorate (15 minutes is one quarter). Resize bills the new count immediately. You cannot pause a provisioned deployment; delete it to stop the meter. Hourly billing fits benchmarking and short events. It is a poor plan for production scale-up and scale-down: unused quota does not mean capacity will exist when you scale back up, and continuous hourly at production size is usually more expensive than a reservation.

Azure Reservations are a financial discount on the PTU meter for a one-month or one-year commitment, not a capacity hold. Buy them in the Azure portal on the Reservations page, per deployment type. A Global reservation does not cover a Regional deployment. Global reservations are not region-specific and can cover Global PTU deployments in many regions up to the reserved quantity. Data Zone and Regional reservations are region-specific. Scope can be a resource group, a subscription, a management group, or the billing account. Matching is by type + region (when required) + scope, not by model ID: the same reservation covers any supported model in that pool. Create deployments first, then buy the reservation. Excess PTUs above the reservation bill hourly. Unused reserved PTUs still cost the reservation. Roles that can buy reservations differ from roles that can create Foundry deployments; confirm authorization before go-live.

Customers onboarded before the August 2024 self-service update may still have a Commitment purchase model. New customers and many models introduced after that date use hourly billing plus reservations. Do not invent Commitment as the current default on the exam.

Sizing, minima, and what PTU is not

PTUs are model-independent as a quota pool: you do not buy gpt-4.1 PTUs versus gpt-5.2 PTUs. Throughput per PTU still depends on the model. A heavier model needs more PTUs for the same tokens per minute. Output tokens consume more capacity than input tokens. Cached prompt tokens do not consume PTU capacity (they are deducted 100 percent from utilization).

Minimum deployment size and scale increment vary by model and type. Read the current sizing table before you answer a number on the exam, but remember the pattern: many current Azure OpenAI chat models need 15 PTUs on Global or Data Zone (scale by 5) and 50 PTUs on Regional (scale by 50), with smaller variants sometimes allowing 25 regional PTUs. Llama-3.3-70B-Instruct and DeepSeek provisioned SKUs list 100 Global or Data Zone PTUs and no regional option. Fireworks-hosted Foundry models use their own minima (tens to hundreds of PTUs). You cannot deploy 1 PTU of gpt-4.1 to save money.

Size from peak requests per minute, average prompt tokens, average completion tokens, and cache rate:

• Input TPM = peak RPM × average prompt tokens
• Output TPM = peak RPM × average completion tokens
• Normalized TPM = input TPM × (1 − cache rate) + (output-to-input ratio × output TPM)
• PTUs = normalized TPM ÷ Input TPM per PTU, then round up to the model's scale increment (and not below the minimum)

The Foundry capacity calculator on the Quota page applies the same inputs. For GPT-4.1 and later, the output-to-input ratio usually matches that model's Global Standard price ratio (for example 8 for gpt-5.2, 4 for gpt-4.1). Older models can consume more capacity on a few huge calls than on many small ones with the same average. Always benchmark a real deployment with production-shaped traffic before you buy a year of reservation.

Use PTUs when all of the following are true:

• Traffic is predictable enough to size
• Users or downstream systems need consistent low latency
• Volume is high enough that per-token Standard would cost more than reserved capacity, or the business needs a latency SLA Standard will not give
• The workload is interactive (chat, copilot, agent), not a 24-hour batch file

Stay on Standard for development, low volume, or traffic you cannot size. Add spillover so PTU exhaustion becomes Standard tokens instead of failed calls (section 11.3). Do not autoscale PTUs with the diurnal curve as a cost tactic: scale-down gives capacity away, and scale-up can fail.

PTU quota is not Azure Machine Learning compute quota. Domain 2 managed online endpoints and training clusters consume virtual-machine family quota. Classic Foundry managed compute for Hugging Face consumes virtual-machine quota. New Foundry managed compute preview consumes Foundry accelerator quota. None of those meters is the PTU pool on the Foundry Quota page. Buying extra Standard_NC cores will not create Global Provisioned units for gpt-4.1.

Exam scenario

A call-center copilot on gpt-4.1 runs 1,000 requests per minute at peak, 200-token prompts, 20-token completions, in the US data zone, with a p99 latency target. Standard Global already shows latency variance at that volume. Size Data Zone Provisioned PTUs with the calculator (the Microsoft worked example for a similar gpt-5.2 shape landed near 110 PTUs without cache, 80 PTUs at 50 percent cache — your number will follow the gpt-4.1 row). Confirm capacity in the US data zone, create the deployment, then purchase a Data Zone reservation that matches the deployed count. Enable spillover to Data Zone Standard of the same version. Do not buy the reservation first. Do not request Azure Machine Learning GPU quota.

Common trap

Treating PTU quota as a reservation of capacity, or treating an Azure Reservation as a capacity hold. Quota is a cap. Capacity is inventory. A reservation is a discount. Another trap: scaling a production PTU deployment to zero overnight on hourly billing to save money — you cannot pause, and the capacity may be gone in the morning. A third: mixing Global reservation coverage onto a Regional deployment. A fourth: answering with Azure Machine Learning cluster quota or instance_count when the question is Foundry PTUs. A fifth: assuming every model shares the same 15-PTU minimum.