Cómo calcular el escalado automático de TTS en SageMaker

Para ajustar el escalado automático de un endpoint de texto a voz (TTS) en Amazon SageMaker AI, mide primero cuántas solicitudes concurrentes puede atender cada instancia sin superar el objetivo de latencia y cuánto tarda una ampliación de capacidad. AWS aplica ese método a Kokoro-82M en una instancia ml.g5.xlarge; sus cifras corresponden a ese ejemplo, no a valores predeterminados de SageMaker.

Qué medir antes de fijar los umbrales

AWS emplea ConcurrentRequestsPerModel, una métrica nativa de SageMaker que registra el máximo de solicitudes concurrentes en una ventana de 10 segundos. En su prueba, la relación entre la concurrencia medida por el cliente de referencia y la observada en CloudWatch fue de 1,0 en cada nivel probado.

La otra medida clave es Q_max: la concurrencia más alta por instancia que cumple el objetivo de nivel de servicio (SLO) elegido para el percentil 95 del tiempo hasta el primer byte de audio (TTFAB). El percentil 95, o p95, indica el valor por debajo del cual se sitúa el 95 % de las mediciones. AWS eligió un SLO de 3.000 ms para su ejemplo.

A una solicitud concurrente, AWS informó de un tiempo de servicio sin contención de 61,3 ms de media y 66,1 ms en p95. Al aumentar la carga, la TTFAB p95 llegó a 2.805,7 ms con 50 solicitudes y a 3.374,8 ms con 60. Así, Q_max quedó en 50 para Kokoro-82M en ml.g5.xlarge bajo ese SLO.

Requisitos y despliegue del ejemplo

AWS enumera permisos para IAM, S3, ECR y SageMaker. También hacen falta AWS CDK v2 inicializado en la cuenta y región de destino, Python 3.11 o posterior, uv, Docker y cuota disponible para una instancia ml.g5.xlarge.

Las tres pilas de AWS CDK se despliegan en este orden: SpeechFoundationStack, con los roles y el bucket de S3 para las ponderaciones del modelo; SpeechModelCacheStack, que sincroniza esas ponderaciones; y SpeechEndpointStack, que crea los recursos del endpoint. Esta última pila solo sintetiza los recursos de autoescalado y observabilidad si el escalado está habilitado y existe un plan medido viable.

AWS estima unos 36 minutos para ejecutar qmax en un endpoint activo y hasta unos 28 minutos para ttotal. Son operaciones que afectan al estado del endpoint. El repositorio de AWS Samples califica su solución como una prueba de valor, no como una implementación lista para producción.

El repositorio también identifica torch==2.6.0 como afectado por el aviso PYSEC-2026-2286 y señala que torch 2.10.0 incluye la corrección. Describe el problema como una posible corrupción de memoria en el deserializador weights_only al procesar un checkpoint malicioso. El repositorio añade que la revisión de Kokoro está fijada a un commit concreto de Hugging Face y que la vía de ataque descrita exigiría comprometer esa revisión.

Ejecuta las mediciones en orden

AWS organiza el flujo en cinco comandos: drift, qmax, ttotal, plan y validate. Las mediciones de qmax y ttotal afectan al endpoint; drift, plan y validate son de solo lectura.

1. drift compara los recursos de escalado desplegados con la configuración. Comprueba que el estado del endpoint y sus recursos coincidan con lo esperado antes de medir.
2. qmax mantiene una instancia y prueba una escalera de concurrencia en lazo cerrado. El resultado identifica el máximo que cumple el SLO elegido para la TTFAB p95.
3. ttotal fuerza una ampliación y mide la recuperación. AWS indica que una medición detenida o cancelada puede dejar congelado el autoescalado; el tutorial incluye el comando thaw para recuperarlo antes de continuar.
4. plan calcula los umbrales a partir de las entradas elegidas y las mediciones del ejemplo.
5. validate compara la política desplegada con el artefacto del plan.

Interpreta el tiempo de ampliación con cuidado

AWS informó de 260,2 segundos como tiempo medido en una ampliación forzada. Para planificar, añadió 60 segundos de latencia de detección de la política, acotada pero no medida en esa prueba, y obtuvo 320,2 segundos.

Sin embargo, las ocho duraciones de etapas publicadas suman 290,1 segundos: 30,0 + 180,8 + 3,7 + 0,0 + 6,5 + 1,0 + 20,7 + 47,4. Esa suma supera en 29,9 segundos el total medido de 260,2 segundos. El ejemplo de AWS Samples agrupa algunas fases de otra manera, pero tampoco explica la diferencia. Por tanto, los tramos publicados no forman un desglose aritmético reconciliado de los 260,2 segundos.

Calcula los umbrales y fija los límites operativos

Con Q_max=50 y una relación de sobrecarga de 1,25× elegida para el ejemplo, AWS calcula un umbral de 37,5 solicitudes concurrentes para ampliar capacidad y 25 para reducirla. Las operaciones son (1−0,25)×50=37,5 y (1−0,50)×50=25.

La configuración de ejemplo usa una instancia ml.g5.xlarge, un mínimo de una y un máximo de nueve instancias, un periodo de espera de 30 segundos antes de volver a escalar hacia arriba y otro de 960 segundos antes de reducir capacidad. El límite de cola es de 50 solicitudes. Son valores de esa configuración, no reglas generales de SageMaker.

AWS advierte que reducir una flota de dos instancias a una puede dejar la instancia restante en Q_max y generar de nuevo presión para ampliar capacidad. Según el cálculo del ejemplo, un mínimo de tres instancias evita esa condición concreta, aunque mantiene más capacidad provisionada.

El control de admisión del contenedor es independiente del autoescalado: cuando la cola supera el límite configurado, rechaza la solicitud con el error HTTP 503 queue_saturated. Ese rechazo no añade capacidad. Al terminar, validate comprueba que la política desplegada coincide con el plan calculado.