Inquiry Regarding strict gpt-realtime Quota Limits and Scaling Options on Pay-As-You-Go

The gpt-realtime quotas and scaling options on Pay-As-You-Go can be summarized and addressed as follows, based only on the documented quota tier behavior.

1. Why the quota appears flattened from Tier 1–5

For the gpt-realtime model with GlobalStandard deployment, the quota tables show:

• Tier 1: 200 RPM, 100,000 TPM
• Tier 2: 200 RPM, 100,000 TPM
• Tier 3: 200 RPM, 100,000 TPM
• Tier 4: 200 RPM, 100,000 TPM
• Tier 5: 200 RPM, 100,000 TPM
• Tier 6: 300 RPM, 150,000 TPM

The documentation does not provide a specific explanation for why this particular model’s RPM/TPM does not scale between tiers 1–5. It only states that:

• Quota tiers are designed to “improve the Foundry Models experience and reduce friction as workloads scale.”
• Automatic tier upgrades are “based primarily on customer consumption trends” and relationship with Microsoft (EA/MCA-E, payment history, etc.).

So, for gpt-realtime, the published behavior is simply that the per-subscription quota is effectively capped at 200 RPM / 100k TPM for tiers 1–5 and only increases at tier 6.

2. How to increase Pay-As-You-Go limits

For Foundry Models (including Azure OpenAI in Foundry), quota can be increased in two ways:

• Automatic tier upgrades
  • As usage grows and the current tier becomes limiting, the system “automatically upgrades the customer to the next higher tier.”
  • Enterprise relationships (EA, MCA-E) and good payment history improve eligibility for automatic upgrades.
• Manual quota increase requests
  • The documentation explicitly states: “Yes, using the quota request form you can always request more quota. If the request is approved, the current tier will remain the same, but with more quota assigned.”
  • This applies even if the table shows a given RPM/TPM for that tier; an approved request can assign higher custom quota than the default tier value.

Process on Pay-As-You-Go:

1. Use the quota request form referenced in the quotas and limits page.
2. Provide subscription details, region, model (gpt-realtime, GlobalStandard), and the required RPM/TPM for production.
3. If approved, the subscription remains in its current tier but with higher quotas than the default tier values.
4. Maximum limit achievable on Pay-As-You-Go

The documentation does not state a fixed maximum RPM/TPM for Pay-As-You-Go beyond the published tier tables. It only clarifies that:

• Previously approved quota increases are retained and “will not be reduced.”
• Additional quota can be requested via the quota form, and if approved, it is applied on top of the tier defaults.

Therefore, the realistic maximum for a specific subscription and workload is determined case-by-case through the quota request process; no numeric upper bound is documented for gpt-realtime beyond the tier 6 defaults.

4. Architectural workarounds while staying on Pay-As-You-Go

The context provides general guidance for handling rate limits and scaling Azure OpenAI workloads on Pay-As-You-Go:

• Combine multiple deployments / backends
  • For token-per-minute restrictions, the guidance is to “consider combining multiple Azure OpenAI deployments in an advanced architecture to build a system that delivers more tokens-per-minute to more users.”
  • This pattern can be applied by:
    • Creating multiple deployments of the same model (potentially across regions where supported), and
    • Using a gateway or load balancer to distribute traffic across them.
• Load balancing and scaling
  • For high traffic, the recommendation is to “create a load balancer for your application,” with a sample for Azure API Management–based load balancing for pay-as-you-go.
  • This allows spreading requests across multiple Azure OpenAI resources/deployments to increase effective throughput.
• Multi-region considerations
  • The documentation does not explicitly forbid using multiple regions for the same model to increase aggregate RPM/TPM, and the multi-backend guidance is framed as a supported pattern.
  • Any multi-region design must still respect data residency/compliance requirements and actual model availability per region.

5. Additional operational notes

• Auto-upgrade opt-out
  • Customers can opt out of automatic tier upgrades by setting a flag to NoAutoUpgrade, but this is intended for those using quota as a billing control and is not a best practice for scaling.
  • For a scaling-sensitive, production voice platform, leaving auto-upgrade enabled and combining it with explicit quota requests is more aligned with the documented guidance.
• When to consider alternatives
  • The context suggests that when throughput requirements are “well defined, predictable,” switching to provisioned throughput (dedicated server) is recommended. However, since the requirement is to remain on Pay-As-You-Go, the supported path is:
    • Use tier auto-upgrades where possible,
    • Submit explicit quota increase requests for gpt-realtime,
    • Architect with multiple deployments and load balancing to aggregate capacity.

References:

• Azure OpenAI in Microsoft Foundry Models quotas and limits
• AI for startups FAQ