Cómo transmitir voz de Kokoro TTS en SageMaker

Para que una voz empiece a hablar antes de que un agente de IA termine su respuesta, envía a Kokoro cada frase completa en cuanto esté lista. El ejemplo que AWS publicó el 22 de octubre de 2026 usa un endpoint en Amazon SageMaker AI y un agente en Amazon Bedrock AgentCore; la síntesis de cada mensaje sigue siendo secuencial, pero la primera frase puede empezar a sintetizarse mientras el agente genera las siguientes.

Antes de empezar

Para reproducir el ejemplo necesitas una cuenta de AWS con los permisos adecuados, AWS CDK v2 inicializado, Python 3.12 o posterior, uv, Docker y una versión compatible de Boto3. El contenedor debe llevar la etiqueta que habilita el streaming bidireccional de SageMaker. También conviene estar familiarizado con WebSocket y con Starlette o ASGI, el estándar que utilizan los servidores de aplicaciones de Python.

AWS despliega Kokoro-82M, un modelo de texto a voz con 82 millones de parámetros, en un contenedor personalizado dentro de un endpoint en tiempo real de SageMaker AI. La configuración del ejemplo utiliza una instancia GPU ml.g5.xlarge. Un agente de Strands alojado en Amazon Bedrock AgentCore genera texto con Amazon Bedrock y lo envía al endpoint de Kokoro.

Implementa el flujo en este orden

1. Despliega primero el endpoint de Kokoro. El contenedor expone GET /ping, POST /invocations para el flujo de respuesta y WS /invocations-bidirectional-stream para la sesión WebSocket bidireccional. El agente depende de este endpoint para convertir el texto en audio.
2. Despliega después el agente. El runtime de Amazon Bedrock AgentCore aloja el agente de Strands. Cuando Amazon Bedrock genera texto, el agente puede remitir a Kokoro cada frase completa sin esperar a que termine la respuesta entera.
3. Haz que el controlador acepte tramas binarias y mantenga la sesión. SageMaker entrega los mensajes del cliente por WebSocket como tramas binarias. Un controlador de Starlette que espera texto con receive_text() puede fallar con KeyError('text') aunque el endpoint figure como InService. Acepta los bytes y decodifica como UTF-8 cuando corresponda. Mantén la sesión abierta para los mensajes siguientes y ciérrala cuando el cliente envíe un mensaje explícito de cierre.
4. Envía frases completas y vacía el texto pendiente al final. El fragmentador de frases del ejemplo emite cada oración terminada a medida que llega el texto. Cuando el agente acaba de generar, envía también el fragmento final aunque no termine en punto. Así puede arrancar antes la síntesis de la primera frase. El controlador procesa los mensajes de síntesis uno detrás de otro: no sintetiza varias frases a la vez.
5. Elige cómo entregar el audio al navegador. Si tu interfaz ya utiliza Server-Sent Events (SSE), enviar audio codificado en base64 puede encajar con ese flujo. La codificación aumenta el tamaño del contenido aproximadamente un 33 %, y los fragmentos de SSE pueden dividir tramas de audio. El cliente debe almacenarlas temporalmente y reconstruir las tramas antes de reproducirlas.

En la conexión bidireccional entre el agente y el endpoint, el ejemplo multiplexa audio PCM sin codificar y mensajes de control JSON. La ruta hacia el navegador sigue usando base64: el runtime de AgentCore devuelve diccionarios que pueden serializarse como JSON. AWS midió los siguientes tamaños en una prueba de transporte con 24 clips:

Comprueba el protocolo y evita los fallos habituales

En una sesión bidireccional, cada petición de síntesis produce un mensaje de control synthesis_start, audio PCM en binario y un mensaje synthesis_complete. La misma sesión puede recibir otro texto; solo debe cerrarse cuando el cliente envíe el mensaje de cierre. Comprobar esa secuencia ayuda a localizar errores que una comprobación de estado del endpoint no detecta.

No trates cada fragmento SSE como una trama de audio completa: puede contener solo parte de una. Tampoco cierres la sesión tras la primera frase ni supongas que el streaming equivale a sintetizar oraciones en paralelo. Son tres puntos distintos: el transporte puede dividir el audio, la sesión puede continuar y la síntesis de los mensajes sigue siendo secuencial.

Qué significan las cifras de latencia

En una prueba aislada contra un endpoint activo, AWS usó el mismo texto de 267 caracteres y cuatro frases para comparar el modo por lotes con el envío inicial de una sola frase. En cinco pruebas por modo, el tiempo medio hasta el primer byte de audio fue de 329,3 ms en modo por lotes y 156,7 ms en modo incremental. AWS calculó una reducción relativa del 52,4 % para esa prueba.

En su comparación integral, AWS informó de que el modo bidireccional tardó hasta el primer audio 0,42 veces lo que el modo por lotes en una prueba local y 0,29 veces en el runtime desplegado de AgentCore, descrito por AWS como 2,4 y 3,5 veces más rápido, respectivamente. La comparación mantuvo el mismo prompt, modelo de Bedrock y endpoint; cambió el momento en que empezaba la síntesis.

Otras formas de ejecutar Kokoro

Trelis Research muestra Kokoro-ONNX ejecutándose localmente en una CPU y Kokoro-FastAPI en un servidor H100 alojado en Runpod. Para su prueba con concurrencia, comunicó un rendimiento de entre 55 y 78 horas de audio procesadas por hora de tiempo real. Esa cifra mide rendimiento del servidor; las pruebas de AWS miden el tiempo hasta el primer audio, así que describen resultados distintos.

Revisa las dependencias antes de terminar

AWS asocia la versión de PyTorch fijada en su contenedor de ejemplo con el aviso de seguridad PYSEC-2026-2286 y señala que el problema está corregido en PyTorch 2.10.0. Recomienda revisar esa versión antes de utilizar el contenedor más allá de una prueba de valor.

Al limpiar el despliegue, elimina el runtime del agente y el endpoint de SageMaker. Los comandos de limpieza de AWS no borran el bucket de Amazon S3 que almacena la caché de los pesos ni el repositorio de Amazon ECR que guarda la imagen del contenedor; si los conservas, pueden seguir generando cargos de almacenamiento.