How to use this assessment: How to use this assessment: Work through each item and mark it complete once confirmed. Items flagged High Risk represent the most common sources of material overspend. A score of 15 or more indicates a well-governed position.

Scoring Guide
Tally your confirmed items against these benchmarks to determine your current maturity level.
0 – 5 High Exposure
6 – 10 Partial Governance
11 – 20 Well Governed

Section 1

1. You have measured your workload's average tokens per minute (TPM) and peak TPM over a representative 30-day period before sizing any PTU commitment. High Risk PTU allocation is sized in throughput units, where each unit provides a defined TPM capacity that varies by model. GPT-4o on Azure requires approximately 6 PTUs per 1,000 TPM of sustained capacity. Without 30 days of production or representative load data, PTU sizing is guesswork — and the consequence of underestimating is throttled traffic during peak demand, while overestimating wastes committed spend.
PTU allocation is sized in throughput units, where each unit provides a defined TPM capacity that varies by model. GPT-4o on Azure requires approximately 6 PTUs per 1,000 TPM of sustained capacity. Without 30 days of production or representative load data, PTU sizing is guesswork — and the consequence of underestimating is throttled traffic during peak demand, while overestimating wastes committed spend.
● High Risk
2. You have calculated your peak-to-average TPM ratio and confirmed it is low enough to justify PTU economics. High Risk PTUs make economic sense only when average utilisation consistently exceeds 60 to 70 percent of provisioned capacity. A workload with an average of 5,000 TPM but a peak of 50,000 TPM — a 10:1 peak-to-average ratio — would require provisioning for peak demand, but would run at 10 percent average utilisation. At that utilisation rate, PTU is dramatically more expensive than pay-as-you-go. Confirm your peak-to-average ratio before any PTU commitment.
PTUs make economic sense only when average utilisation consistently exceeds 60 to 70 percent of provisioned capacity. A workload with an average of 5,000 TPM but a peak of 50,000 TPM — a 10:1 peak-to-average ratio — would require provisioning for peak demand, but would run at 10 percent average utilisation. At that utilisation rate, PTU is dramatically more expensive than pay-as-you-go. Confirm your peak-to-average ratio before any PTU commitment.
● High Risk
3. You have confirmed that your workload has low latency sensitivity — or that PTU's consistent, low-latency response is a genuine requirement — rather than a theoretical preference. Medium Risk PTU's primary operational advantage over pay-as-you-go is predictable, low-latency inference without the throughput variability that shared-capacity pay-as-you-go experiences during peak demand. If your workload is a batch document processing pipeline that can tolerate 2 to 5 second response times, PTU's latency advantage is not a meaningful business benefit. Quantify the business value of latency consistency before paying the PTU premium for it.
PTU's primary operational advantage over pay-as-you-go is predictable, low-latency inference without the throughput variability that shared-capacity pay-as-you-go experiences during peak demand. If your workload is a batch document processing pipeline that can tolerate 2 to 5 second response times, PTU's latency advantage is not a meaningful business benefit. Quantify the business value of latency consistency before paying the PTU premium for it.
● Medium Risk
4. You have segmented your workloads into PTU-eligible (predictable, high-throughput, latency-sensitive) and pay-as-you-go eligible (bursty, variable, latency-tolerant) categories. Medium Risk Most enterprise Azure OpenAI deployments have a mix of workload profiles. Routing all workloads through a single commercial model — either all PTU or all pay-as-you-go — is almost always suboptimal. Build a hybrid architecture where predictable high-volume production workloads use PTU and bursty, variable, or exploratory workloads use pay-as-you-go, with automatic spillover routing from PTU to pay-as-you-go during demand spikes.
Most enterprise Azure OpenAI deployments have a mix of workload profiles. Routing all workloads through a single commercial model — either all PTU or all pay-as-you-go — is almost always suboptimal. Build a hybrid architecture where predictable high-volume production workloads use PTU and bursty, variable, or exploratory workloads use pay-as-you-go, with automatic spillover routing from PTU to pay-as-you-go during demand spikes.
● High Risk
5. You have projected your workload's TPM consumption 12 months forward and confirmed that growth projections are grounded in business plan assumptions rather than aspirational estimates. High Risk PTU commitments are typically available in 1-month and 1-year terms, with annual commitments offering additional discount. Enterprises frequently commit to PTU volumes based on growth projections that don't materialise, resulting in committed spend on provisioned capacity that runs at 20 to 30 percent utilisation. Ground your 12-month TPM forecast in signed customer commitments or confirmed product deployments, not sales pipeline assumptions.
PTU commitments are typically available in 1-month and 1-year terms, with annual commitments offering additional discount. Enterprises frequently commit to PTU volumes based on growth projections that don't materialise, resulting in committed spend on provisioned capacity that runs at 20 to 30 percent utilisation. Ground your 12-month TPM forecast in signed customer commitments or confirmed product deployments, not sales pipeline assumptions.
● High Risk

Section 2

6. You have built a side-by-side monthly cost model for PTU vs pay-as-you-go using your actual token counts, input/output ratio, and current Azure list prices. High Risk The PTU vs pay-as-you-go break-even calculation requires: your average monthly input token count, your average monthly output token count, your input-to-output ratio (output tokens are priced differently), current pay-as-you-go rates for your model, and the PTU reservation cost for the provisioned capacity your workload requires. Without all five inputs sourced from production data, the cost model is not reliable. Azure's estimate vs real cost frequently diverges by a factor of 10 to 100 for teams that skip the instrumentation step.
The PTU vs pay-as-you-go break-even calculation requires: your average monthly input token count, your average monthly output token count, your input-to-output ratio (output tokens are priced differently), current pay-as-you-go rates for your model, and the PTU reservation cost for the provisioned capacity your workload requires. Without all five inputs sourced from production data, the cost model is not reliable. Azure's estimate vs real cost frequently diverges by a factor of 10 to 100 for teams that skip the instrumentation step.
● High Risk
7. You have confirmed the PTU break-even utilisation threshold for your specific model and validated it against your measured utilisation rate. High Risk PTU break-even versus pay-as-you-go occurs at 60 to 70 percent average utilisation for most Azure OpenAI models. At 80 percent average utilisation, PTU typically saves 40 to 50 percent versus pay-as-you-go. At 40 percent average utilisation, PTU typically costs 20 to 40 percent more than pay-as-you-go. Calculate your break-even utilisation using Microsoft's provisioning calculator with your actual model and volume data before committing.
PTU break-even versus pay-as-you-go occurs at 60 to 70 percent average utilisation for most Azure OpenAI models. At 80 percent average utilisation, PTU typically saves 40 to 50 percent versus pay-as-you-go. At 40 percent average utilisation, PTU typically costs 20 to 40 percent more than pay-as-you-go. Calculate your break-even utilisation using Microsoft's provisioning calculator with your actual model and volume data before committing.
● High Risk
8. You have modelled the cost impact of demand spikes that exceed your PTU capacity and confirmed whether pay-as-you-go spillover or demand management is the appropriate response. Medium Risk When traffic exceeds PTU provisioned capacity, Azure routes overflow requests to pay-as-you-go capacity at standard rates. For workloads with infrequent but large demand spikes, this spillover can be cost-effective. For workloads with frequent demand spikes, the spillover cost may negate the PTU saving. Build your cost model to include spillover at the 90th percentile demand level, not just average demand, before finalising PTU capacity.
When traffic exceeds PTU provisioned capacity, Azure routes overflow requests to pay-as-you-go capacity at standard rates. For workloads with infrequent but large demand spikes, this spillover can be cost-effective. For workloads with frequent demand spikes, the spillover cost may negate the PTU saving. Build your cost model to include spillover at the 90th percentile demand level, not just average demand, before finalising PTU capacity.
● Medium Risk
9. You have reviewed the PTU pricing for your specific model tier — GPT-4o, GPT-4o mini, and o-series — and confirmed that the PTU-to-TPM ratio matches your workload's token characteristics. Medium Risk Different Azure OpenAI models require different PTU-to-TPM ratios. o-series reasoning models require significantly more PTUs per 1,000 TPM than GPT-4o, because reasoning tokens are generated internally before the visible output. If you are sizing PTUs for a reasoning model workload using GPT-4o PTU conversion rates, you will significantly underestimate the PTU requirement.
Different Azure OpenAI models require different PTU-to-TPM ratios. o-series reasoning models require significantly more PTUs per 1,000 TPM than GPT-4o, because reasoning tokens are generated internally before the visible output. If you are sizing PTUs for a reasoning model workload using GPT-4o PTU conversion rates, you will significantly underestimate the PTU requirement.
● Medium Risk
10. You have requested Azure's enterprise pricing for PTU reservations — including any volume discounts or committed spend credits available through an Enterprise Agreement — rather than relying on list price. Medium Risk Azure PTU list pricing is the starting point for negotiation, not the final price. Enterprises with existing Azure Enterprise Agreements can apply committed Azure spend credits against PTU reservation costs, effectively reducing the net PTU cost by the credit discount on their overall Azure commitment. Engage your Microsoft account team to confirm whether your PTU spend qualifies for EA credit application before committing at list price.
Azure PTU list pricing is the starting point for negotiation, not the final price. Enterprises with existing Azure Enterprise Agreements can apply committed Azure spend credits against PTU reservation costs, effectively reducing the net PTU cost by the credit discount on their overall Azure commitment. Engage your Microsoft account team to confirm whether your PTU spend qualifies for EA credit application before committing at list price.
● Medium Risk

Section 3

11. You have selected the shortest viable PTU commitment term given your workload certainty, and confirmed the upgrade and downgrade policy for your reservation. High Risk Azure PTU reservations are available in monthly and annual terms. Annual reservations offer approximately 15 to 20 percent additional discount versus monthly, but eliminate flexibility to reduce capacity if workload volumes decline. Start with monthly reservations for any new workload and transition to annual reservations only after 3 consecutive months of stable utilisation above the break-even threshold.
Azure PTU reservations are available in monthly and annual terms. Annual reservations offer approximately 15 to 20 percent additional discount versus monthly, but eliminate flexibility to reduce capacity if workload volumes decline. Start with monthly reservations for any new workload and transition to annual reservations only after 3 consecutive months of stable utilisation above the break-even threshold.
● High Risk
12. You have confirmed the PTU capacity upgrade timeline — the lead time required to increase provisioned capacity — and designed your overflow architecture to handle the gap period. Medium Risk PTU capacity increases on Azure may require 24 to 72 hours processing time, depending on model availability in your selected region. If your workload is expected to grow rapidly — particularly for consumer-facing AI applications — design your architecture for pay-as-you-go spillover from day one, with PTU capacity increases planned in advance of projected demand rather than in response to throttling incidents.
PTU capacity increases on Azure may require 24 to 72 hours processing time, depending on model availability in your selected region. If your workload is expected to grow rapidly — particularly for consumer-facing AI applications — design your architecture for pay-as-you-go spillover from day one, with PTU capacity increases planned in advance of projected demand rather than in response to throttling incidents.
● Medium Risk
13. You have reviewed the geographic PTU availability for your required model and confirmed that capacity is available in your required region before building a deployment architecture dependent on PTU. Medium Risk PTU capacity is not equally available across all Azure regions for all models. Newer model versions and o-series models frequently have limited PTU availability in specific regions, particularly in APAC and emerging market regions. Confirm PTU availability in your production region before designing a production architecture that depends on it — and confirm what the fallback commercial model is if PTU capacity is unavailable in your required region.
PTU capacity is not equally available across all Azure regions for all models. Newer model versions and o-series models frequently have limited PTU availability in specific regions, particularly in APAC and emerging market regions. Confirm PTU availability in your production region before designing a production architecture that depends on it — and confirm what the fallback commercial model is if PTU capacity is unavailable in your required region.
● Medium Risk
14. You have a governance process in place to track PTU utilisation monthly and trigger a capacity review when utilisation falls below 60 percent or exceeds 85 percent for two consecutive weeks. Medium Risk PTU investments require active utilisation management that most enterprise cloud teams have not built into their standard capacity review processes. Low utilisation (below 60 percent) triggers a cost review and potential capacity reduction. High utilisation (above 85 percent) triggers a capacity increase review to avoid throttling. Assign a named owner for PTU utilisation monitoring and define the governance thresholds that trigger a capacity review action.
PTU investments require active utilisation management that most enterprise cloud teams have not built into their standard capacity review processes. Low utilisation (below 60 percent) triggers a cost review and potential capacity reduction. High utilisation (above 85 percent) triggers a capacity increase review to avoid throttling. Assign a named owner for PTU utilisation monitoring and define the governance thresholds that trigger a capacity review action.
● High Risk
15. You have implemented an AI gateway layer that automatically routes requests to pay-as-you-go when PTU capacity is saturated, rather than returning errors to users. High Risk PTU deployments without pay-as-you-go spillover create a hard capacity ceiling: when provisioned throughput is exhausted, requests are throttled or rejected. In production applications, this appears as latency spikes or error messages for end users. Implement automatic spillover routing — using Azure APIM, LiteLLM, or a custom gateway — that transparently routes overflow requests to pay-as-you-go capacity before PTU saturation causes user-visible degradation.
PTU deployments without pay-as-you-go spillover create a hard capacity ceiling: when provisioned throughput is exhausted, requests are throttled or rejected. In production applications, this appears as latency spikes or error messages for end users. Implement automatic spillover routing — using Azure APIM, LiteLLM, or a custom gateway — that transparently routes overflow requests to pay-as-you-go capacity before PTU saturation causes user-visible degradation.
● High Risk

Section 4

16. You have instrumented your PTU deployment to measure actual utilisation, response latency distribution, and per-request token consumption in production. High Risk PTU cost efficiency depends entirely on utilisation. Without production instrumentation — measuring tokens per request, requests per minute, and utilisation percentage against provisioned capacity — you cannot confirm whether your PTU investment is break-even or loss-making. Implement token consumption logging at the request level before your PTU reservation begins, not after.
PTU cost efficiency depends entirely on utilisation. Without production instrumentation — measuring tokens per request, requests per minute, and utilisation percentage against provisioned capacity — you cannot confirm whether your PTU investment is break-even or loss-making. Implement token consumption logging at the request level before your PTU reservation begins, not after.
● High Risk
17. You have confirmed your Azure region's model version availability and that your PTU reservation will remain valid when Microsoft releases model version updates. Medium Risk Azure PTU reservations are version-specific. When Microsoft releases a new model version (e.g., GPT-4o 2025-11 to GPT-4o 2026-04), your existing PTU reservation may not automatically cover the new version. Confirm the model version transition policy with your Microsoft account team and understand whether a model version upgrade requires a new PTU reservation, a reservation modification, or is handled automatically.
Azure PTU reservations are version-specific. When Microsoft releases a new model version (e.g., GPT-4o 2025-11 to GPT-4o 2026-04), your existing PTU reservation may not automatically cover the new version. Confirm the model version transition policy with your Microsoft account team and understand whether a model version upgrade requires a new PTU reservation, a reservation modification, or is handled automatically.
● Medium Risk
18. You have reviewed the monitoring and alerting tooling available for PTU deployments within Azure Monitor and confirmed that your operations team has the skills to act on PTU utilisation alerts. Medium Risk Azure Monitor provides PTU utilisation metrics, but the thresholds, dashboards, and alert rules for PTU capacity management must be configured by your team. Many enterprises deploy PTU and then discover in a capacity incident that they have no operational runbook for responding to PTU saturation. Build PTU utilisation dashboards and define operational runbooks before your first production PTU deployment.
Azure Monitor provides PTU utilisation metrics, but the thresholds, dashboards, and alert rules for PTU capacity management must be configured by your team. Many enterprises deploy PTU and then discover in a capacity incident that they have no operational runbook for responding to PTU saturation. Build PTU utilisation dashboards and define operational runbooks before your first production PTU deployment.
● Medium Risk
19. You have documented a formal PTU vs pay-as-you-go decision framework — specifying the utilisation, latency, and volume thresholds that trigger a PTU evaluation for each new AI workload. Lower Risk Without a formal decision framework, PTU adoption is driven by sales pressure (Microsoft account teams actively promote PTU commitments) rather than workload economics. Define the quantitative thresholds that make PTU the recommended commercial model for a workload — minimum average TPM, minimum average utilisation, minimum production stability period — and apply this framework consistently across new workload evaluations.
Without a formal decision framework, PTU adoption is driven by sales pressure (Microsoft account teams actively promote PTU commitments) rather than workload economics. Define the quantitative thresholds that make PTU the recommended commercial model for a workload — minimum average TPM, minimum average utilisation, minimum production stability period — and apply this framework consistently across new workload evaluations.
● Lower Risk
20. You conduct a quarterly PTU portfolio review that confirms utilisation rates, identifies under-utilised reservations for downsizing, and assesses whether growing workloads should transition from pay-as-you-go to PTU. Lower Risk PTU portfolio management requires active quarterly governance. Under-utilised reservations on annual terms lock in spend that cannot be recovered. Growing workloads that have passed the break-even utilisation threshold and are still on pay-as-you-go are leaving savings unrealised. Quarterly PTU portfolio reviews — examining utilisation rates, growth trends, and commercial optimisation opportunities — should be standard practice for any enterprise with more than three PTU reservations.
PTU portfolio management requires active quarterly governance. Under-utilised reservations on annual terms lock in spend that cannot be recovered. Growing workloads that have passed the break-even utilisation threshold and are still on pay-as-you-go are leaving savings unrealised. Quarterly PTU portfolio reviews — examining utilisation rates, growth trends, and commercial optimisation opportunities — should be standard practice for any enterprise with more than three PTU reservations.
● Lower Risk

Ready to optimise your AI contract and cost position?

Download our AI Platform Contract Negotiation Guide — covering all major vendors, pricing structures, and negotiation tactics.
Download Free Guide →

Next Steps

Score your confirmed items against the benchmarks above. If you are in the High Exposure or Partial Governance bands, prioritise the items flagged High Risk — these represent the most common sources of material overspend and are addressable within a single procurement or FinOps cycle.

Redress Compliance works exclusively on the buyer side, with no vendor affiliations. Our GenAI advisory practice has benchmarked AI costs, negotiated enterprise AI contracts, and built governance frameworks across 500+ enterprise engagements. Contact us for a confidential review of your AI cost and contract position.