Compare Azure OpenAI provisioned and standard deployment costs
On this page
Keep pay-as-you-go token billing for variable or uncertain traffic. Evaluate provisioned throughput when representative benchmarking shows predictable demand and the measured performance and sustained utilization justify PTUs billed for deployed capacity.
Why this is worth a look
Standard pricing charges for input and output tokens, with separate cached-input or other token categories where the applicable pricing row provides them. Provisioned throughput charges hourly for the PTUs deployed, whether or not requests are handled. Required PTUs depend on the model, version, deployment type, peak calls, prompt and response sizes, and cache rate. Compare the resulting period costs with current agreement-specific prices, not token volume alone.
Run this check
CHECKLISTA read-only worksheet for a closed comparison period and a representative workload window. It uses billing quantities and independently validated workload measurements without assuming undocumented export or API field names.
Assumptions for this worksheet
[ ] Closed comparison period and representative workload window are recorded.
[ ] All quantities use the same scope, model, version, deployment type, region or data zone, and currency.
[ ] Billing quantities come from an authoritative billing record available to the operator.
[ ] Workload measurements are independently validated and use the same time window and units.
Standard period cost
[ ] Record each applicable input, cached-input, cache-write, and output quantity separately.
[ ] Match each quantity to the current Azure pricing row for the exact model and deployment type.
[ ] Calculate each quantity at its matching rate, then sum the categories. Do not combine categories unless the pricing row defines them that way.
PTU estimate
[ ] Record model version, deployment type, peak calls per minute, average prompt tokens, average response tokens, and cache rate.
[ ] Use the Foundry capacity calculator or the current model-specific deployment parameters.
[ ] Apply the current documented PTU constraints for that model and deployment type.
[ ] Benchmark the estimate against representative traffic, including request shapes that differ from the average.
Provisioned period cost
provisioned_period_cost = deployed_PTUs * PTU_hourly_rate * deployed_hours
[ ] Compare hourly billing with an eligible reservation using an effective rate for the same period.
[ ] Model unused reservation coverage separately from reservation overage, where deployed PTUs exceed reservation quantity.
Decision
[ ] Compare cost, measured performance, demand predictability, and sustained utilization before changing deployment type.How to confirm it
- 01
Set the comparison window
Choose one closed billing period for standard usage and one representative workload window for sizing. Record the model version, deployment type, region or data zone, scope, currency, and units so the figures are comparable.
- 02
Measure workload shape
Record peak calls per minute, average prompt tokens, average response tokens, and cache rate. Benchmark representative traffic rather than relying only on averages, because request shape can affect capacity consumption.
- 03
Calculate standard cost
Use authoritative billing quantities for the selected period. Match each applicable input, cached-input, cache-write, and output category to the current Azure pricing row for the exact model and deployment type, then sum the separately calculated amounts.
- 04
Size and price PTUs
Use the Foundry capacity calculator or current model-specific deployment parameters. Apply the documented PTU constraints, benchmark the estimate, and calculate deployed_PTUs multiplied by the PTU hourly rate and deployed hours. Compare hourly billing with an eligible reservation using the same period.
- 05
Make the service decision
Choose provisioned throughput only when predictable demand, measured performance, and sustained utilization justify deployed-capacity billing. Keep variable workloads on pay-as-you-go token billing, and model unused reservation coverage separately from reservation overage.
Before making changes
Assume the billing quantities and workload measurements cover comparable windows, use the same model version and deployment type, and use current agreement-specific rates in one currency. PTU estimates remain workload-specific, so benchmark representative traffic. Reservations are financial discounts applied to PTU billing meters and are created independently from deployments. Confirm the current model and deployment-type constraints before relying on an estimate.