Research-backed calculator guide
Azure Priority Processing vs Provisioned: Latency SLO Budget Rubric
A practical Azure Priority processing versus PTU rubric for matching traffic shape, latency SLO budget, commitment tolerance, and failure cost to the right Microsoft Foundry deployment.
Choosing between Azure Priority processing and Provisioned Throughput Units (PTUs) is not simply a choice between “fast” and “slow.” It is a choice between two different ways of buying performance. Priority processing keeps a pay-as-you-go token meter and exposes a model-specific latency target. PTU reserves a fixed amount of model-processing capacity and charges for that capacity whether the deployment is busy or idle. The right decision depends on your traffic shape, measured SLO, tolerance for commitment, and the cost of a miss.
Quick answer
Choose Priority Processing when traffic is bursty or still being learned, the application needs a lower-latency service tier, and paying per token is preferable to reserving capacity. Microsoft describes Priority as pay-as-you-go low-latency processing for supported Global Standard and US Data Zone Standard deployments. Its published target is expressed as a model-specific tokens-per-second threshold, calculated from p50 request latency over five-minute windows, rather than as your application’s end-to-end p95 response-time guarantee [1].
Choose PTU when demand is sustained and measurable, capacity must be dedicated to your deployment, and the cost of unused reservation is acceptable. PTU billing is per unit per hour, with monthly or annual reservation options. The number of PTUs is model- and deployment-type dependent; quota and available capacity are separate constraints [2].
Choose a layered design when you have a predictable baseline plus short bursts. Put the measured baseline on PTU and route overflow or selected latency-sensitive requests through Priority, subject to model support, ramp behavior, and your own routing and budget controls. Microsoft’s Priority documentation explicitly describes combining Priority with PTU for steady-state capacity and cost optimization [1].
The shortest defensible rule is: buy Priority for flexible latency improvement; buy PTU for reserved capacity; layer them when baseline and burst economics are different. Do not call either option a guaranteed p95 application SLO until you have tested the complete request path.
What the two options actually provide
Priority Processing: a token-priced latency tier
Priority processing is enabled on a supported deployment or requested with the service_tier field. The Microsoft documentation lists model-specific latency target values such as “99% > 50 TPS” or “99% > 80 TPS.” Those values are meaningful operational signals, but TPS is not the same unit as milliseconds of end-to-end latency. A 50-TPS target also does not account for client network time, queueing in your application, tool calls, safety filters, streaming behavior, or the number of generated tokens.
Priority uses the same quota as standard processing. Microsoft also documents cases where a priority request can be processed at the standard tier, including a rapid traffic increase of more than 50% tokens per minute in less than 15 minutes, periods of peak Priority demand, and certain long-context requests. The response’s service-tier information and Azure Monitor metrics therefore belong in your acceptance test. A Priority label in configuration is not evidence that every request received the Priority path [1].
This makes Priority attractive for a team with uncertain volume, business-hour bursts, or a product that cannot yet justify a capacity commitment. It also creates a risk to budget and SLO design: token cost can rise with volume, and a sudden ramp can change the processing tier. Treat the downgrade path as a first-class scenario instead of hiding it in a footnote.
PTU: fixed capacity with an hourly meter
A PTU deployment holds a fixed amount of processing capacity exclusively for your deployment. Microsoft says the capacity is held whether or not requests are being made. PTUs are model-independent quota units, but the tokens-per-minute delivered by each PTU varies by model. Quota is scoped by subscription, region, and deployment type, while actual capacity is the amount available for the model version at deployment time. Having quota does not guarantee that capacity is available [2].
PTU is therefore a capacity decision before it is a price decision. It suits an interactive workload with a stable peak, a production agent with a measurable throughput profile, or a downstream system that treats latency variance and 429 responses as expensive. It is less attractive when you cannot estimate demand, when traffic is idle for long periods, or when the model and deployment type may change before you recover the commitment.
Provisioned deployments have Global, Data Zone, and Regional forms. The choice changes routing and price, not just the number of units. Global Provisioned routes across Azure regions; Data Zone Provisioned stays within a Microsoft-defined zone; Regional Provisioned stays in the selected geography where supported [2] [3]. Record this boundary in the same decision sheet as latency and cost, because a cheaper capacity option that violates data-processing requirements is not a feasible option.
Turn an application SLO into a budget
Start with the SLO your user actually experiences. For example, “95% of chat responses complete within 2,000 milliseconds” is an end-to-end SLO. Break that into a model budget rather than comparing the 2,000-millisecond number directly with Microsoft’s TPS target.
A simple budget is:
model p95 budget = total p95 SLO - network budget - application queue budget - tool/safety budget - retry budget
If the total target is 2,000 ms and you reserve 180 ms for network, 220 ms for application queueing, 300 ms for tools and safety processing, and 100 ms for retry overhead, the remaining model budget is 1,200 ms. That is your internal acceptance threshold for the selected request shape. It is not a Microsoft quote, and it should be re-measured for prompt length, output length, streaming policy, region, and model version.
Next record four percentiles, not one average: requests per minute, input tokens per request, output tokens per request, and end-to-end latency. Averages hide the exact shape that causes Priority ramp risk or PTU saturation. Use a high percentile for the capacity calculation, then keep a separate headroom allowance. Do not size a PTU from a monthly token total alone: two workloads with the same monthly tokens can have very different peak capacity needs.
The deployment comparison in Microsoft’s documentation places Priority in the pay-per-token, latency-sensitive category and Provisioned in the per-PTU-per-hour category for predictable throughput and consistent latency [2]. That is a useful starting classification. Your rubric should add the parts that the product table cannot know: how often the workload is idle, whether bursts are forecastable, what a failed or late request costs, and how quickly you can change models.
Worked cost example
Consider a Data Zone Provisioned deployment using the GPT-5.2 sizing values published by Microsoft. Assume 30 requests per minute at the planning peak, a 200-token prompt, a 20-token response, and no prompt-cache reduction. These are planning assumptions, not a vendor quote. Microsoft’s sizing method calculates input TPM, output TPM, normalized TPM, and then divides normalized TPM by the model’s input TPM per PTU [2]. The sizing guide lists 3,400 input TPM per PTU and an output-to-input ratio of 8 for this example model and deployment type [3].
| Step | Assumption or input | Calculation | Output |
|---|---|---|---|
| 1. Peak input | 30 RPM × 200 input tokens | 30 × 200 | 6,000 input TPM |
| 2. Peak output | 30 RPM × 20 output tokens | 30 × 20 | 600 output TPM |
| 3. Normalize output | Output ratio = 8 | 8 × 600 | 4,800 input-equivalent TPM |
| 4. Normalize workload | No cache reduction assumed | 6,000 + 4,800 | 10,800 normalized TPM |
| 5. Raw PTU estimate | Input TPM per PTU = 3,400 | 10,800 ÷ 3,400 | 3.18 PTUs |
| 6. Deployment floor | Example Data Zone minimum is 15 PTUs | Round up to applicable minimum | 15 PTUs |
| 7. Monthly capacity estimate | Official page lists $1.10/PTU-hour for GPT-5.2 Data Zone on the checked date | 15 × $1.10 × 720 hours | $11,880/month |
The last row assumes uninterrupted deployment for 30 days, or 720 hours. The Azure pricing page labels prices as estimates rather than quotes and says actual pricing can vary with agreement, purchase date, and currency; the displayed value is therefore a dated planning input, not an invoice promise [4]. It also shows that the minimum PTU floor can dominate a small workload. If the 30-RPM peak occurs for only a short daily window, a 15-PTU deployment may be economically difficult even though it is technically feasible.
For a Priority comparison, do not substitute a stale generic rate. Use the current model, deployment zone, context tier, and Priority rate from the applicable Azure pricing view or your commercial agreement. With the same traffic running continuously for 30 days, monthly volume would be 259.2 million input tokens and 25.92 million output tokens. If your dated Priority rates are P_in and P_out dollars per million tokens, the token estimate is:
Priority estimate = 259.2 × P_in + 25.92 × P_out
That formula is intentionally parameterized. It keeps a vendor quote separate from the PTU estimate above and lets you test a burst schedule instead of pretending that the priority price is universal. If the workload is active only 20% of the month, multiply the Priority token terms by the measured active fraction; do not automatically multiply PTU cost by 20%, because an always-on PTU deployment remains metered while deployed.
The decision rubric
Use these tests in order. First, eliminate infeasible options: unsupported model or deployment type, unavailable regional capacity, data-routing conflict, or an SLO that has not been defined in measurable units. Second, compare the peak shape. A steady baseline with a narrow, forecastable burst points toward PTU plus overflow. A wide, unpredictable burst points toward Priority or PAYG while you gather measurements. Third, compare failure cost. If a late response causes a human escalation or a contractual credit, include that cost in the scenario rather than comparing only the provider meter.
Finally, set a review trigger. Examples include Priority downgrade share above a chosen percentage, PTU utilization below a chosen floor for several weeks, p95 model budget misses, or a sustained change in output length. These are your governance thresholds, not Microsoft defaults. Store the input evidence with the decision so a later switch can be audited.
For token-volume hygiene, pair this rubric with the AI token cost calculator. For a broader provider and model comparison, use the Model pricing comparison. After deployment, reconcile estimates against invoices with the AI API invoice reconciliation calculator. Those tools answer different questions: token arithmetic, rate comparison, and billed-usage verification should not be collapsed into one latency decision.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
FAQ
Is Azure Priority Processing the same as PTU?
No. Priority is a pay-per-token processing tier with model-specific latency target semantics. PTU reserves a fixed amount of model-processing capacity and charges per PTU-hour or under a reservation. Priority can improve response performance without a long-term capacity commitment; PTU is designed for predictable dedicated throughput. A layered design can use both when baseline and burst traffic have different economics [1] [2].
Does a Priority latency target mean my API p95 will be under a specific number of milliseconds?
No. Microsoft’s published Priority target is expressed in tokens per second and is calculated from p50 request latency over five-minute periods for a model. Your application p95 includes network, queueing, tools, safety processing, retries, prompt shape, output length, and client behavior. Convert your requirement into a measured end-to-end budget and validate the complete path; do not translate a TPS target into a universal millisecond guarantee [1].
Can PTU remove all 429s and latency variance?
No. PTU supplies dedicated capacity, but a deployment can still be undersized for its actual request shape, and capacity availability matters before deployment. Microsoft also documents spillover for provisioned deployments, which can route overflow to a corresponding standard deployment. Treat spillover as a separate cost and latency path, and test what happens when PTU capacity is exhausted [2].
When should I combine Priority and PTU?
Combine them when you can identify a steady baseline that justifies reserved capacity but also see bursts, ramp events, or a small class of requests that merits a different service tier. Keep the routing policy explicit: define which traffic uses PTU, which requests may use Priority, how overflow is bounded, and which response field and cost tag prove where a request was processed. Microsoft documents the combination as an option, but the economics depend on your model rates, minimum PTU, burst duration, and failure cost [1].
How do I compare Azure Priority versus PTU cost fairly?
Use the same model version, deployment boundary, region or data zone, prompt/output shape, cache assumption, active hours, and reliability policy. Calculate Priority as token volume multiplied by the dated input and output rates. Calculate PTU as deployed units multiplied by the dated hourly rate and hours deployed, then add reservation or spillover treatment if applicable. Include idle hours and capacity floors. Azure describes displayed prices as estimates, so label the result as a planning estimate until your agreement and invoice establish actual rates [5].
Limitations and assumptions
This rubric does not select a model, promise an application ranking, or forecast traffic. The numerical example uses a dated official pricing display and Microsoft’s published sizing inputs for illustration. Model availability, minimum PTUs, scale increments, latency targets, rates, quota, and capacity can change. Re-run the sizing exercise with representative traffic before purchase, and validate Priority’s actual service tier, end-to-end p95, output length, and downgrade behavior in the deployment you intend to operate.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.