Stop Guessing Auto Scaling Targets for TTS on Amazon SageMaker AI
Deploying custom text-to-speech models on Amazon SageMaker AI often relies on guessed autoscaling thresholds, which can waste GPU spend or breach service level objectives.

The Hidden Costs of Guessed Auto Scaling
Teams deploying custom text-to-speech models often face difficulties when traffic spikes hit their self-hosted endpoints. When requests start queueing and latency climbs past service level objectives right when callers are listening, the underlying auto scaling policy is often found to rely on guessed thresholds. Guesses like these tend to fail silently until real traffic proves them wrong.
Getting scaling numbers wrong results in two primary issues. A conservative guess forces fleets to run GPU instances that remain mostly idle, accumulating unnecessary costs. Conversely, an aggressive guess carries hidden risks, causing instances to hold more concurrent requests than they can safely serve within latency promises.

Deploying Kokoro-82M as a Custom Container
To address these scaling challenges, engineering teams can deploy Kokoro-82M, an 82-million-parameter text-to-speech model, as a custom container on an Amazon SageMaker AI real-time endpoint. The deployment process is managed using AWS CDK stacks, replacing guesswork with two precise measurements taken against the live endpoint: Q_max, representing the highest concurrency one instance sustains before breaching the SLO, and T_total, measuring how long a scale-out takes end to end.

Why Default Metrics Fall Short for TTS
Most public guidance regarding Amazon SageMaker AI auto scaling focuses on short synchronous request and response calls or large language model serving, where token generation speed serves as the primary metric. Text-to-speech synthesis fits neither pattern, as a single request keeps a connection open for several seconds without a token-generation loop.
Because non-autoregressive models like Kokoro-82M produce full utterances from a single pass, they lack a generation loop to instrument with per-token metrics. Instead, instance overload is determined by how many requests are actively queued and executing at any given time.

Leveraging Native CloudWatch Metrics
The deployed auto scaling policy scales based on ConcurrentRequestsPerModel, a native metric published directly by Amazon SageMaker AI rather than requiring custom container code emission. This approach eliminates common failure points where custom metric configurations appear correct on paper but fail to publish actual data.
Developers can find detailed guidance on configuring these parameters within the official Amazon SageMaker AI auto scaling documentation, ensuring production environments maintain robust operational standards.

Prerequisites and Implementation Stacks
Implementing this measured auto scaling approach requires an AWS account with permissions for IAM roles, Amazon S3 buckets, Amazon ECR repositories, and Amazon SageMaker AI resources. Additionally, practitioners need AWS CDK v2, Python 3.11 or later, uv, and Docker to properly build and deploy the container images.
The complete deployment code, including infrastructure stacks and sample configurations, is available in the dedicated GitHub repository. Developers can review the sample repository to access all required scripts and automation workflows for production testing.
Sources
- AWS Machine Learning BlogStop guessing auto scaling targets for TTS on Amazon SageMaker AI
Continue chronologically





