¿Qué API de texto a voz tiene la latencia más baja para aplicaciones en tiempo real?

El asistente de voz funciona bien en tu portátil a través de WiFi. Haces la demostración, impresiona a la gente y lanzas el producto. Luego, un usuario lo abre en una conexión móvil y la pausa antes de que la voz comience es de 1,8 segundos. La conversación se siente como una llamada telefónica con un mal retraso de satélite. Cierran la aplicación.

La latencia en TTS no es un problema menor de pulido. Para aplicaciones en tiempo real, es la diferencia entre una experiencia que se siente como una conversación y otra que se siente como enviar un formulario y esperar una respuesta. Las hojas de especificaciones no te dirán esto claramente. La mayoría de los números de referencia se miden en la red ideal del proveedor con una conexión precalentada.

La sorpresa en producción para la que no estaba preparado

Aprendí esto por las malas en un proyecto de asistente de voz hace unos dieciocho meses. Durante el desarrollo, veía consistentemente un TTFB en el rango de 180-220 ms —totalmente aceptable, la conversación se sentía natural, yo estaba feliz. Entré en la semana de pruebas de carga con confianza.

Luego simulamos 200 usuarios concurrentes. Una API que había funcionado de maravilla con 5 sesiones concurrentes saltó de esos cómodos 180 ms a 2,3 segundos. Sin advertencias en la documentación, sin degradación progresiva —solo picos duros de latencia que hacían que el asistente pareciera que estaba resolviendo un problema matemático difícil antes de cada respuesta. No lo detectamos hasta una semana antes del lanzamiento, que no es cuando quieres estar reconsiderando a tu proveedor de TTS.

La solución implicó cambiar a una API con mejor arquitectura de concurrencia y reconstruir parte del flujo de audio para usar streaming HTTP fragmentado (chunked) en lugar de esperar a la entrega completa del archivo. Solo eso —pasar de esperar el archivo completo a transmitir fragmentos— redujo el tiempo percibido de la primera respuesta de 1,2 segundos a unos 450 ms. Ese umbral de 450 ms es aproximadamente donde los oídos humanos dejan de registrar conscientemente el intervalo como una "pausa". Por debajo de eso, la conversación simplemente fluye. Por encima, los usuarios comienzan a ajustar su comportamiento.

Nota del desarrollador: El benchmark de tu máquina de desarrollo es inútil para predecir la latencia en producción. Prueba desde una VM en la nube en la región donde están tus usuarios, bajo carga concurrente. La brecha entre "funciona en mi máquina" y "funciona con 200 usuarios concurrentes en el sudeste asiático" es donde viven la mayoría de las sorpresas de latencia.

300 ms, 800 ms, 2 segundos: Dónde se rompe realmente la experiencia

No todos los umbrales de latencia importan por igual. Esto es lo que los números significan en la práctica:

Menos de 150 ms: Se siente instantáneo. Los usuarios no perciben un intervalo entre su entrada y la respuesta de voz. Esto se puede lograr con despliegue local o APIs de streaming excepcionales.

150-400 ms: Aceptable para asistentes de voz. Los usuarios notan una ligera pausa pero el ritmo conversacional se mantiene intacto. La mayoría de las APIs de TTS por streaming bien optimizadas aterrizan aquí en condiciones normales.

400 ms-1 segundo: La pausa es audible y notoria. Los usuarios se ajustan esperando más tiempo antes de hablar, lo que mata el flujo natural de la conversación. Puedes compensar con feedback visual —un indicador de escucha, una animación— pero no puedes ocultarlo por completo.

Más de 1 segundo: El modelo de conversación se rompe. Los usuarios asumen que el sistema se ha colgado o está roto. Este es el rango donde comienzan a llegar los tickets de soporte.

Hay una distinción importante que la mayoría de las comparaciones pasan por alto: tiempo hasta el primer byte (TTFB) frente a tiempo total de generación. Un guion de 500 palabras puede tardar 6-8 segundos en generarse como un archivo de audio completo. Con el streaming, el primer fragmento de audio llega en 80-150 ms y se reproduce mientras la generación continúa. La espera percibida por el usuario es de 80 ms, no de 8 segundos.

Esa distinción por sí sola determina si una API de TTS es viable para uso en tiempo real.

Latencia y streaming: Comparativa de plataformas

Los números de TTFB varían según la región, la calidad de la conexión y si la conexión está precalentada. Haz las pruebas en la región donde estén tus usuarios, no desde tu máquina de desarrollo.

Fish Audio: TTFB de milisegundos y lo que significa en producción

La API de Fish Audio está diseñada para la entrega en tiempo real. El tiempo hasta el primer byte es de nivel de milisegundos, lo que lo sitúa en el rango donde el audio en streaming comienza antes de que el usuario haya registrado conscientemente una espera.

El soporte de streaming significa que el flujo de audio funciona de la misma manera que los navegadores entregan video: los fragmentos llegan y se reproducen a medida que se generan. Para una respuesta que tardaría 4 segundos en generarse como un archivo completo, los usuarios escuchan el audio comenzando en menos de 200 ms en una conexión normal. En un entorno de 4G con señal débil, vimos que el streaming fragmentado redujo la llegada efectiva del primer byte de 1,2 segundos a unos 450 ms en la misma API, solo por cambiar de esperar el archivo completo a consumir el flujo a medida que llegaba.

La arquitectura de concurrencia importa a escala. La mayoría de las APIs de TTS comienzan a limitar (throttling) cuando las solicitudes simultáneas aumentan, lo que se traduce en picos de latencia durante el tráfico máximo. El soporte de alta concurrencia de Fish Audio significa que el rendimiento que mides durante las pruebas es más cercano al rendimiento que obtienes cuando 500 usuarios hablan con tu producto simultáneamente.

El rendimiento de latencia de Fish Audio es sólido, pero vale la pena ser directos sobre un factor del mundo real: se ve afectado significativamente por la distancia geográfica con tus usuarios. Si la mayoría de tus usuarios están en Europa y no estás enrutando a través de un CDN o despliegue en el borde (edge), la ventaja de latencia se reduce en comparación con los centros de datos europeos de Azure. La selección de endpoints regionales y la configuración del CDN importan tanto como la elección de la propia API.

La opción de código abierto cambia el techo por completo. Fish Speech, el modelo subyacente, puede ser autohospedado. El autohospedaje significa que la única latencia es el tiempo de inferencia en tu hardware, sin saltos de red a una API externa. Para aplicaciones críticas de latencia donde cada milisegundo cuenta, esta es la única opción que te permite bajar más de lo que cualquier API en la nube puede ofrecerte. La latencia de inferencia en una GPU moderna suele situarse por debajo de los 100 ms para respuestas cortas.

Un caso documentado: un desarrollador que integró Fish Audio en un chatbot de IA conversacional midió una latencia de extremo a extremo inferior a 500 ms de forma constante, incluyendo el viaje de ida y vuelta de red, la generación de TTS y la entrega de audio. La documentación completa de la API está en docs.fish.audio.

ElevenLabs: Genuinamente competitivo para el inglés

ElevenLabs merece crédito honesto aquí. Su latencia de streaming para contenido en inglés es genuinamente competitiva —he visto casos de TTFB inferior a 200 ms en regiones de EE. UU. Este, lo cual es impresionante dada la calidad del modelo que ejecutan. Han invertido significativamente en reducir el TTFB, y para contenido en idioma inglés, el equilibrio entre calidad y latencia es de los mejores disponibles.

La limitación para aplicaciones en tiempo real es que la ventaja de latencia se estrecha para contenido que no es en inglés, y no hay opción de autohospedaje si necesitas bajar de lo que ofrece su API en la nube. Con una alta concurrencia, el coste también escala más rápido que el modelo de Fish Audio.

Es una opción sólida para asistentes de voz centrados en el inglés donde la calidad de la voz es la principal preocupación. Solo asegúrate de probar en condiciones de concurrencia realistas, no en condiciones de un solo usuario.

Azure TTS y Google TTS: Fiables, no optimizados para la velocidad

Tanto Azure como Google operan con una latencia moderada por defecto. El soporte de streaming de Azure está disponible pero normalmente requiere acceso de nivel enterprise. La API básica de Google no ofrece streaming real en el mismo sentido que las plataformas de TTS diseñadas específicamente para tiempo real.

Ambos son apropiados para aplicaciones donde una latencia de 500 ms a 1 segundo es aceptable. Sistemas IVR, funciones de lectura en voz alta en aplicaciones, voces de notificación. No son la elección correcta para IA conversacional o asistentes de voz donde la respuesta necesita sentirse inmediata.

Nota del desarrollador: Precalienta la conexión a tu API de TTS. La primera solicitud en una sesión fría incluye la sobrecarga del protocolo de enlace TCP —normalmente 30-100 ms dependiendo de la distancia geográfica— que las solicitudes posteriores no pagan. La resolución DNS añade otros 20-60 ms si no la has almacenado en caché. En un asistente de voz, esto hace que la primera respuesta sea notablemente más lenta que todas las siguientes. Envía una solicitud de precalentamiento ligera al iniciar la aplicación, antes de que el usuario hable.

Decisiones de arquitectura que reducen la latencia independientemente de la plataforma

La elección de la API importa, pero también cómo la usas. Algunos patrones que reducen la latencia percibida en aplicaciones en tiempo real:

Precalienta la conexión. La primera solicitud a cualquier API incluye la sobrecarga del handshake TCP (30-100 ms) más la resolución DNS (20-60 ms). Precalienta enviando una solicitud al inicializar la aplicación, no cuando el usuario hable por primera vez. Esta es una de las victorias de latencia más fáciles y casi nadie lo hace por defecto.

Usa WebSocket para sesiones interactivas, transferencia HTTP chunked para respuestas únicas. WebSocket elimina la sobrecarga HTTP por solicitud y es la opción correcta cuando tienes una sesión persistente. Para casos de uso de una sola respuesta —una voz de notificación, una función de lectura en voz alta— la transferencia fragmentada HTTP es más simple y funciona bien.

Caché de frases estáticas. Saludos, confirmaciones, mensajes de error, avisos de navegación. Genera estos una vez y sírvelos desde la caché. Eliminarás las llamadas a la API por completo para el 30-50% de la salida de voz en la mayoría de las aplicaciones conversacionales.

Comienza el streaming inmediatamente. No esperes al archivo de audio completo. Si tu API soporta streaming (y las que valen la pena lo hacen), canaliza el flujo directamente a la salida de audio y deja que se reproduzca mientras el resto se genera.

Haz coincidir la región de la API con la región del usuario. Una llamada a la API de TTS de un usuario en Tokio a un servidor en Virginia añade 150-200 ms de latencia de red pura antes de que comience cualquier procesamiento. Eso no es un problema de TTS, es un problema de geografía. Usa endpoints regionales donde estén disponibles, y si tu proveedor no los ofrece, un CDN o proxy en el borde puede ayudar.

Autohospedaje para techos de latencia estrictos. Si el requisito de tu aplicación es realmente inferior a 100 ms, ninguna API en la nube ofrece eso de forma fiable a través de una red normal. La inferencia local con un modelo de código abierto como Fish Speech es el único camino arquitectónico hacia ese nivel de rendimiento.

Emparejando la plataforma con el tipo de aplicación

Asistentes de voz e IA de compañía: El streaming más el TTFB más bajo posible no son negociables. Fish Audio o ElevenLabs, probados en la región donde están tus usuarios.

Respuestas de voz de chatbot: 300-500 ms suele ser aceptable. Cualquier plataforma con capacidad de streaming funciona. Prioriza el coste y la calidad de voz sobre la latencia bruta.

IVR y sistemas telefónicos: Los requisitos de latencia son más permisivos (500 ms-1 s aceptable). La fiabilidad y el control de SSML importan más. Azure o Amazon Polly encajan bien aquí.

Voces de notificación y alerta: La generación por lotes con almacenamiento en caché está bien. La latencia no importa porque el audio está pre-generado. El nivel gratuito de Google gestiona esto de forma rentable.

Traducción en tiempo real o narración en vivo: Este es el caso más difícil. El streaming más la inferencia local o cercana es la única forma de lograr una latencia aceptable. Autohospedar Fish Speech o usar la API de Fish Audio desde un endpoint geográficamente cercano.

Preguntas frecuentes

¿Qué se considera latencia baja para una API de TTS en aplicaciones en tiempo real? Un TTFB (tiempo hasta el primer byte) inferior a 300 ms suele ser aceptable para asistentes de voz e IA conversacional. Menos de 150 ms se siente instantáneo. Más de 500 ms rompe el ritmo natural de toma de turnos en una conversación. El TTFB de nivel de milisegundos de Fish Audio lo sitúa en el nivel más rápido para despliegues en tiempo real.

¿El streaming reduce la latencia de TTS? El streaming reduce significativamente la latencia percibida. No cambia el tiempo total de generación, pero comienza a entregar audio antes de que la generación finalice. Una respuesta de 500 palabras que tarda 8 segundos en generarse completamente comienza a reproducirse en menos de 200 ms con streaming. La experiencia del usuario es el inicio de 200 ms, no la finalización de 8 segundos.

¿Puedo reducir la latencia de TTS autohospedando el modelo? Sí. El autohospedaje elimina por completo el viaje de ida y vuelta por la red. El modelo de código abierto Fish Speech de Fish Audio puede ejecutarse en tu propia infraestructura. La latencia de inferencia en hardware moderno suele ser inferior a 100 ms para respuestas cortas, lo cual está por debajo de lo que cualquier API en la nube puede ofrecer de forma constante.

¿Qué API de TTS funciona mejor para asistentes de voz que necesitan respuestas rápidas? Para la mayoría de los despliegues de asistentes de voz, la combinación de Fish Audio de TTFB de milisegundos, streaming y alta concurrencia cubre los requisitos. ElevenLabs es la alternativa para asistentes centrados en el inglés donde la calidad de voz es la prioridad principal.

¿Cómo mido la latencia de una API de TTS con precisión? Prueba desde la región donde están tus usuarios, no desde tu máquina de desarrollo. Usa cargas de solicitudes concurrentes que reflejen tu tráfico máximo esperado. Mide específicamente el TTFB —tiempo hasta que el audio comienza a llegar, no el tiempo total de respuesta. Realiza pruebas en diferentes momentos del día para capturar la carga variable del servidor. El número de un solo usuario en tu máquina de desarrollo es un techo, no un suelo.

¿Cambia la latencia de TTS bajo una alta carga concurrente? Sí, para plataformas que no están arquitecturadas para la concurrencia. El soporte de alta concurrencia de Fish Audio está diseñado para mantener un TTFB constante bajo carga, lo cual es la característica de rendimiento relevante para aplicaciones con muchos usuarios simultáneos.

Conclusión

Para aplicaciones en tiempo real, la elección de la plataforma es más simple de lo que parece: necesitas una API de TTS que soporte streaming y entregue un TTFB inferior a 300 ms desde tu región de despliegue.

El TTFB de milisegundos de Fish Audio, el streaming nativo, la alta concurrencia y la opción de autohospedaje de código abierto le otorgan el rango más amplio de patrones de despliegue para aplicaciones críticas de latencia. ElevenLabs es un competidor genuino para casos de uso centrados en el inglés donde la calidad de voz es la máxima prioridad —no lo descartes sin probarlo.

Antes de comprometerte con cualquier integración, prueba la API desde la región donde están tus usuarios, bajo la carga concurrente que realmente esperas. Los números de latencia desde el portátil del desarrollador en un entorno ideal no predicen el comportamiento en producción. No es una advertencia teórica —es el modo de fallo específico que ha arruinado más integraciones de TTS que cualquier problema de calidad de la API.

Comienza con la documentación en docs.fish.audio y prueba la entrega por streaming directamente contra el umbral de latencia de tu aplicación.