Provisioned throughput units (PTU) for Foundry models

Standard deployments bill per token and share capacity; provisioned deployments reserve capacity for you. This section covers when to reserve, how quota and capacity differ, sizing, billing and what happens when the reservation is full.

When to use provisioned throughput

• Provisioned throughput reserves a fixed amount of model processing capacity for one deployment, whether or not requests arrive. Use it for predictable, latency-sensitive, production-scale traffic.
• Standard (pay-per-token) suits development, low volume and highly variable traffic.

Quota, capacity and sizing

• PTU quota is model-independent but granted per subscription, per region and per deployment type.
• Quota doesn’t guarantee capacity, which is allocated when the deployment is created; if the region lacks capacity, the deployment fails.
• Scaling down or deleting a deployment releases capacity with no guarantee you get it back.

• Historically, DeepSeek models needed 100 PTUs in steps of 100; today DeepSeek is offered through Fireworks on Microsoft Foundry with larger, model-specific minimums (for example DeepSeek v3.1: 200 PTUs in steps of 100; DeepSeek v3.2: 300 in steps of 150), Global and Data Zone only.

Billing and reservations

• Provisioned deployments are billed hourly at $/PTU/hr for the PTUs deployed, whatever the token count.
• Azure Reservations (1-month or 1-year) discount that meter.
  • They are bought per deployment type and can cover several subscriptions or resource groups.
  • They don’t guarantee capacity, so create the deployment first and buy the reservation afterwards.
  • One Global reservation can cover Global deployments in several regions.

Utilisation and 429 responses

• The Provisioned-managed Utilization V2 metric reports (PTUs consumed ÷ PTUs deployed) per minute; split it by deployment.
• At 100% utilisation the service returns 429 with retry-after / retry-after-ms headers.
• Cached prompt tokens don’t count towards utilisation (except for GPT-6 Astra, GPT-6 Sol and newer models, which weight cached input and cache writes).
• Set max_tokens close to the real output length, because the service reserves that amount up front.

Common trap: treating a 429 from a provisioned deployment as a service fault - it is the designed signal that the PTUs are fully used; retry after the header’s wait time or redirect the request with spillover.

Spillover

Spillover sends overflow traffic to a standard deployment in the same resource, so bursts above the reservation are served per token rather than rejected.

• The standard deployment must use the same model and version.
• Enable it for every request with the deployment property spilloverDeploymentName, or per request with the x-ms-spillover-deployment header. If both are set, the deployment property wins.
• It triggers on 429, a 400 for over-long context, and 500/503 errors.
• Spilled requests are billed per token and show IsSpillover = True on the standard deployment.
• Only Azure OpenAI models support it; DeepSeek and Llama don’t.

Get the whole book

This note is one section of Ultra Transcenders AI-300: Operationalizing Machine Learning and Generative AI Solutions, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.

About the book · Free AI-300 glossary · All AI-300 study notes