You are currently viewing Azure OpenAI Pricing: Standard vs PTU Costs

Azure OpenAI Pricing: Standard vs PTU Costs

Spread the love

Azure OpenAI Service bills two ways: Standard, which charges per token the same way OpenAI’s own API does, and Provisioned Throughput Units (PTUs), which reserve capacity at a fixed hourly rate whether you use it or not. Most teams start on Standard and only move to PTU once their traffic is steady enough to justify paying for idle capacity in exchange for predictable latency.

Key facts

  • Standard pricing is per token, split into input and output rates that differ by model.
  • PTU minimums are 15 units for Global and Data Zone deployments, 50 for Regional (25 for mini models).
  • PTU hourly rates run roughly $1.00 (Global), $1.10 (Data Zone), and $2.00 (Regional) per unit.
  • GPT-4o and GPT-4.1 are now legacy models on Azure, kept alive for existing deployments only.

Standard pricing: pay per token, same shape as OpenAI’s own API

On Standard, you pay for what you send and what the model sends back, with output almost always priced higher than input. As a concrete reference point, the GPT-5.4 mini model prices input at $0.75 per million tokens and output at $4.50 per million, a 6x gap between reading and writing, according to pricing data compiled by CloudZero. The full GPT-5.4 model runs higher on both sides.

That output premium is the number most budgets get wrong. A support-ticket summarizer that reads a 2,000-token ticket and writes a 200-token summary looks cheap per call. Run it 50,000 times a month and the output tokens, small as they look individually, can outweigh the input cost once you add up the aggregate.

PTU pricing: pay for reserved capacity, not usage

PTUs work differently. You commit to a number of processing units, and you’re billed hourly for that capacity, used or not, the same tradeoff as a reserved instance anywhere else in cloud computing.

The minimum commitment depends on deployment type: 15 PTUs for Global or Data Zone, and 50 PTUs for Regional deployments (reduced to 25 for mini-class models), per figures reported by Finout. Hourly rates cited in the same analysis run close to $1.00 per PTU for Global, $1.10 for Data Zone, and $2.00 for Regional, roughly double the price for the same capacity if you need data to stay in a specific region.

PTU makes sense for one kind of workload: sustained, predictable, high-volume traffic where latency has to stay consistent. It’s a bad fit for anything bursty. A chatbot that’s quiet overnight and busy at 2pm still pays the same PTU bill at 3am as it does at 2pm, which is exactly the problem Standard’s per-token billing avoids.

Where Azure’s version of OpenAI pricing actually differs

Three things separate Azure OpenAI from calling OpenAI’s API directly, and they’re not just a different bill with the same numbers.

Region choice carries a real premium. Data Zone and Regional deployments, which exist to satisfy data residency requirements, run about 10% more per token than Global, according to the same Finout breakdown. If nothing legally requires you to pin data to a region, Global is the cheaper default.

Enterprise Agreement pricing can beat list price, but only once it’s actually negotiated and attached to your subscription; the number this page (and Microsoft’s own calculator) shows by default is retail. And Azure has its own discount mechanics layered on top, including Batch processing at roughly half the Global Standard rate for workloads that can tolerate a delay before results come back.

The legacy model trap

Here’s a cost problem that has nothing to do with per-token rates: GPT-4o and GPT-4.1 are now legacy on Azure, kept running only for deployments that were already using them. A team that provisioned a GPT-4o endpoint a year ago and never revisited it is very likely paying more per token, for a weaker model, than a fresh GPT-5.4 mini deployment would cost for the same task.

This is worth an actual line item in your AI cost review, not just a one-time check. Model pricing and capability both move fast enough that a deployment configured correctly six months ago can be the most expensive way to solve the problem today.

FAQ

Is Azure OpenAI more expensive than OpenAI’s own API?
Not inherently. Global Standard pricing tracks close to OpenAI’s direct API rates for the same model. The premium shows up specifically with Data Zone or Regional deployments, and with PTU capacity you reserve but don’t fully use.

Do I need PTU if I’m just testing Azure OpenAI?
No. Standard per-token billing has no minimum commitment and is the right starting point for development, prototypes, and any workload without a steady, predictable traffic pattern.

Can I mix Standard and PTU for the same application?
Yes, and many production setups do exactly that: PTU for the steady baseline load, Standard as overflow capacity for traffic spikes above what the reserved PTUs can handle.

Sources


Written by the FinOpsDaily editorial team. Azure OpenAI pricing and model availability change frequently; confirm current rates on Microsoft’s own Azure OpenAI pricing page before budgeting.

Nhon Dang

Nhon Dang is a cloud infrastructure and operations professional with over 10 years of hands-on experience in cloud services, infrastructure, and business operations. His expertise spans the design, deployment, and operation of cloud platforms and managed services, including virtual machines (VMs), Kubernetes (K8s), object storage (S3), managed databases, Apache Kafka, and cloud GPU infrastructure. Throughout his career, Nhon has worked closely with cloud infrastructure and service operations, gaining practical experience in building reliable, scalable, and cost-efficient cloud environments. His work combines technical expertise with business and operational insight, giving him a practical perspective on how cloud technologies perform in real-world production environments. Nhon writes about cloud infrastructure, Kubernetes, DevOps, distributed systems, cloud computing, infrastructure operations, and cloud service management, sharing insights based on hands-on experience rather than purely theoretical knowledge. His goal is to provide practical, technically accurate, and experience-driven guidance that helps engineers, technical teams, and businesses make better decisions when adopting and operating cloud technologies.