Create more resources to do more TTS requests

Siarhei Lukashenka 20 Reputation points
2026-07-07T06:02:34.9666667+00:00

I want to be able to do more TTS requests. Does creating a second resource for that make sense? We run critical for our business (phone calls) TTS pipeline and we absolutely have no room for failure.

Azure Speech in Foundry Tools
Answer accepted by question author
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator
2026-07-13T20:50:37.28+00:00

Hello @Siarhei Lukashenka

Creating an additional Speech resource can help improve resiliency and increase overall capacity, but only if the resources are deployed in different Azure regions. Multiple Speech resources in the same region share the same backend infrastructure, so they generally do not provide additional throughput or protection from regional service issues.

For business-critical TTS workloads such as phone call pipelines, a common approach is to deploy a primary Speech resource and one or more secondary resources in different regions, then implement automatic failover and retry logic to handle transient failures or throttling (HTTP 429 responses).

If your workload is approaching the default Text-to-Speech transaction limits, you can also request a quota increase for your Speech resource. In addition, monitoring TPS usage, testing traffic patterns, and gradually ramping up large workloads can help reduce throttling events.

For environments that require stricter control over capacity and availability, you may also consider Neural TTS containers deployed across multiple VMs or Kubernetes nodes behind a load balancer.

Could you share your current region, approximate TPS requirements, and whether you're experiencing throttling (429 errors) or planning for future growth? That would help identify the most suitable architecture for your scenario.

Thankyou!

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-07-07T06:03:30.38+00:00

    Creating additional Speech resources can help increase overall Text-to-Speech (TTS) throughput and improve resiliency, but they must be created in different regions to be effective.

    Key points based on current limits and best practices:

    1. Understand what quotas you can change
      For Text-to-Speech on Standard (S0) resources, the adjustable quota is:
      • “Maximum number of transactions per time period for standard voices and custom voices.” This is per Speech resource.
    2. When creating more resources helps
      • Creating more Speech resources in the same region does not improve performance or reduce throttling, because they share the same backend cluster.
      • To increase resilience and effective capacity, create additional Speech resources in different regions and distribute TTS traffic across them.
    3. Mitigate throttling (HTTP 429) and autoscaling delays
      Even when within quota, 429s can occur while the service autoscale catches up. Best practices:
      • Implement robust retry logic for 429 responses.
      • Avoid sudden spikes in workload; ramp up gradually (for example, increase concurrent connections in steps and wait 90–120 seconds between steps while monitoring for 429s).
      • Test workload patterns before production to find safe ramp-up profiles.
    4. Increase TTS TPS limit when needed
      For Standard TTS:
      • Default limit is 200 TPS, which already exceeds most use cases.
      • If business-critical usage requires more, submit a quota increase request for the Text-to-Speech TPS limit. You must provide:
        • Peak TPS
        • Average TPS
        • Average TTS request length (characters)
      • Use the provided formula to estimate monthly usage and validate that the requested TPS aligns with budget and realistic needs.
    5. Region and voice selection for reliability
      For high-availability, business-critical TTS pipelines:
      • Prefer native regions for the language/voice where possible (for example, use a Japan region for Japanese voices) to reduce capacity constraints.
      • Prefer popular voices in the chosen region to reduce the chance of hitting backend capacity limits.
    6. Multi-region failover design
      For “no room for failure” scenarios:
      • Create at least one primary and one or more secondary/backup Speech resources in different regions.
      • Configure the client to monitor for connectivity and service errors and automatically fail over to backup regions when errors persist.
      • Ensure quotas in backup regions are sized similarly to the primary where possible.
    7. Containers as an alternative for strict control
      If hard isolation and deterministic capacity are required, consider Neural TTS containers:
      • Capacity is constrained by the CPU and memory allocated to the container, not by cloud-side concurrent request limits.
      • Recommended allocation for Neural TTS containers is 8 cores and 16–24 GB RAM, with up to about 5 concurrent requests per 8-core container.
      • For higher concurrency and resiliency, run multiple containers (and/or multiple VMs) behind a load balancer and orchestrate with Kubernetes or similar.

    Summary for the scenario:

    • Creating a second Speech resource in the same region does not help.
    • Creating additional resources in other regions, combined with:
      • proper retry logic,
      • gradual load ramp-up,
      • possible TPS quota increase, and
      • optional use of containers, is the recommended way to support more TTS requests and achieve higher resiliency for critical phone-call TTS workloads.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.