Intermittent inference_service_unavailable_error on gpt-realtime-1.5 model across multiple resources in Sweden Central

Hello Abdul Rehman,

Welcome to Microsoft Q&A and Thank you for the questions.

Based on everything you’ve shared, this behavior strongly points to a capacity constraint specific to gpt-realtime-1.5 in Sweden Central, rather than an issue in your code or configuration.

What’s happening

You’re seeing:

• Sessions start normally and work for a few turns
• Mid-conversation failure with:
  • inference_service_unavailable_error
    • Input tokens consumed (~14K), but 0 output tokens
    • Same setup works fine with gpt-realtime (non-1.5)
    • Issue reproduced across multiple resources and subscriptions

This combination clearly indicates transient backend capacity exhaustion for the 1.5 model variant in that region.

Why only gpt-realtime-1.5 is affected

• gpt-realtime-1.5 is a newer and more resource-intensive model
• Capacity is allocated per model, not shared equally
• Sweden Central is a high-demand region, and newer model variants often have:
  • Limited initial capacity
    • Higher contention under load

So it’s expected that:

• gpt-realtime - stable
• gpt-realtime-1.5 - intermittent failures

Why failures occur mid-conversation

This is an important nuance:

• Your session is accepted initially
• As the conversation progresses (~14K tokens), compute demand increases
• At response generation time → capacity not available
• Result:
  • response.done: failed
    • No output tokens

This is typical of dynamic capacity exhaustion during streaming workloads

Please check below steps,

1. Check deployment capacity and quotas

• Sweden Central can be oversubscribed for preview/advanced models
• Validate your deployment health, quotas, and provisioning details

Use internal dashboards like:

• AOAI subscription info / quota dashboards
• Check whether you’re using:
  • Standard (shared) vs
  • Provisioned Throughput (PTU)

2. Try alternative regions

Even if Sweden Central works for other models, you should test gpt-realtime-1.5 in regions with stronger capacity:

• West Europe
• UK South
• North Central US / East US 2
• Norway East

Spin up a test deployment and compare Error rate, Latency, Stability

3. Move to Provisioned Throughput (PTU) for production

For realtime voice workloads, this is the recommended approach.

Why Standard deployments = shared pool

PTU deployments = dedicated reserved capacity

Benefits:

• Eliminates most service_unavailable errors
• Provides predictable performance
• Avoids mid-session drops

4. Add retry and recovery logic

Since these are transient failures, implement:

Retry on 408, 500, 502, 503, 504

Use Exponential backoff + jitter

Detect:

• response.done: failed
• Recreate session or retry turn

This is critical to avoid silent failures in voice scenarios

5. Reduce token pressure

You’re hitting ~14K tokens mid-session, which increases failure probability.

Consider:

• Trimming conversation history
• Using a rolling context window
• Avoiding unnecessary token accumulation

6. Add multi-region failover

For production-grade systems Deploy in at least two regions

Use Azure Front Door or Traffic Manager

Route traffic:

• Primary - Sweden Central
• Fallback - secondary region

This ensures continuity if one region is saturated.

Please refer this

1. Model availability by region: https://dori-uw-1.kuma-moon.com/azure/ai-foundry/openai/concepts/models#model-summary-table-and-region-availability
2. Provisioned throughput concepts: https://dori-uw-1.kuma-moon.com/azure/ai-foundry/openai/concepts/provisioned-throughput?tabs=global-ptum
3. Regional resilience & BCDR best practices: https://dori-uw-1.kuma-moon.com/azure/ai-foundry/openai/how-to/business-continuity-disaster-recovery

I Hope this helps. Do let me know if you have any further queries.

Thank you!

1. The context does not document any region-specific capacity constraint or incident for gpt-realtime-1.5 in Sweden Central. The only relevant capacity-related information in the context is for provisioned throughput and general model/region availability, not transient overload behavior for this specific model or region.
2. gpt-realtime-1.5 is listed as a Global Standard model, which means it is available in multiple regions globally rather than being tied to a single regional SKU. The Global Standard table shows that Sweden Central supports a broad set of the latest GPT-5.x, o3/o4, and realtime/audio models, but it does not break out reliability or capacity differences by region. From the provided data, other regions with similarly rich support for advanced models (for example East US 2, West US, West Europe, North Central US, South Central US, Japan East, Korea Central, etc.) are candidates to test as alternates, but the documentation does not state that any specific region has “more reliable capacity” for gpt-realtime-1.5.
3. For production workloads that need to avoid transient capacity issues, the documented option is Provisioned throughput (Provisioned managed or Global Provisioned Throughput) for models sold directly by Azure. The provisioned tables show:
   • Global Provisioned Throughput is available for high-end GPT-5.x, o3, o4-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o3-mini, o1, and gpt-4o variants across all listed regions.
   • Provisioned managed (regional) is available for the same family of models in Sweden Central and many other regions.

gpt-realtime-1.5 itself is not explicitly listed in the provisioned throughput tables in the context, so there is no documented provisioned SKU for that exact model here. For production realtime workloads where transient capacity failures are unacceptable, the documented pattern is:

• Use Global Provisioned Throughput or Provisioned managed for a supported model (for example gpt-4.1, gpt-4o, or o4-mini) in the target region.
• Architect the application so that the realtime experience (WebSocket/streaming) is backed by a provisioned model where available, or by a region/model combination that has a provisioned option.

If gpt-realtime-1.5 must be used specifically and no provisioned SKU is available, the documentation does not provide a way to eliminate transient service_unavailable errors beyond standard retry/failover patterns and potentially testing alternative regions that support the same Global Standard model.

References:

• Foundry Models sold directly by Azure (azure-openai)
• What is provisioned throughput for Foundry Models?
• Azure OpenAI in Azure AI Foundry Models