Una comparación útil de API de TTS empieza por el endpoint al que llamará tu aplicación. El nombre de una familia deja demasiados detalles sin especificar. El modelo exacto, el alojamiento, la región, la voz y el método de medición pueden variar entre entradas de una clasificación.
Las entradas de Qwen3 TTS en Coval ilustran el problema. Comparten una familia, pero sus descripciones publicadas no demuestran un experimento con pesos idénticos y el resto de las condiciones iguales. La lección práctica es comparar servicios completos y mantener visibles los límites de la evidencia.
¿Qué comparan realmente las entradas de Qwen3 TTS?
Las cifras siguientes son los valores medios de TTFA de 30 días que aparecían juntos en la clasificación TTS de Coval el 15 de septiembre de 2026. Las páginas enlazadas aportan detalles de alojamiento y licencia. Son medidas de endpoints separados, no una prueba controlada de sistemas idénticos.
- Qwen3 TTS Fast, alojado por Nari, registra un TTFA medio de 71 ms. Coval lo describe como pesos abiertos e inferencia compartida en Estados Unidos.
- Qwen3 TTS 1.7b, alojado por Baseten, registra un TTFA medio de 106 ms. La entrada describe pesos abiertos e inferencia dedicada en Estados Unidos.
- Qwen3 TTS Flash Realtime, alojado por Alibaba Cloud, registra un TTFA medio de 751 ms. La entrada describe una API oficial propietaria en Asia.
Las diferencias importan tanto como la latencia. La inferencia dedicada y la compartida describen alojamientos distintos. Alibaba ofrece un endpoint propietario en otra región. Afirmar que las tres filas tienen “los mismos pesos” exigiría pruebas más allá de sus nombres.
Estas medidas ayudan a seleccionar endpoints, pero no aíslan cuánto procede del modelo, la red, el hardware, la planificación de tareas u otro detalle de implementación. Incluso una gran distancia entre filas es una observación sobre los servicios medidos, no una explicación controlada de su causa.
¿Qué cifra de latencia debe usarse para comparar API de TTS?
La llegada del primer audio y la primera voz audible son hitos distintos. El cliente puede recibir un fragmento que empiece con silencio. La metodología publicada de Coval define TTFA usando el tiempo hasta la llegada del primer fragmento y el silencio inicial antes de la salida audible. Registra esa definición junto con cualquier cifra que copies de la clasificación.
La comparación también debe conservar el estadístico. Media, mediana y p95 responden preguntas distintas. Si la decisión de compra depende de las respuestas lentas, una media baja no la resuelve. Anota la ventana de medición y el número de muestras para que quien lo lea después entienda qué describe el resultado.
En una prueba de aplicación, elige eventos explícitos de inicio y final. Por ejemplo, mide desde el envío del texto hasta la primera muestra audible reproducida por tu cliente. Mide por separado el establecimiento de conexión y registra si cada solicitud reutilizó una existente. Así la prueba sirve para tu despliegue y “latencia” no significa algo distinto en cada fila.
¿Cómo comparar la calidad de voz?
Coval también informa de WER para endpoints TTS. Su prueba de WER mide errores de transcripción del habla generada. Es una señal útil de inteligibilidad, pero no una evaluación completa de escucha.
Crea un pequeño conjunto de prueba con el texto que realmente dirá tu aplicación. Incluye nombres, fechas, cantidades, abreviaturas y frases que crucen los límites de idioma o pronunciación que encuentran tus usuarios. Escucha palabras omitidas y pronunciaciones incorrectas. Después evalúa por separado el ritmo, el énfasis y si la voz encaja con la interacción.
Separa esos juicios de la velocidad. Una voz que empieza pronto, pero lee mal la cantidad de un recordatorio de pago, es una mala elección para esa tarea. Del mismo modo, una puntuación de calidad que ignore la espera deja fuera parte de la experiencia conversacional. Decide qué errores descartarían a un proveedor antes de mirar los resultados.
¿Cómo hacer que la comparación sirva para producción?
Usa la clasificación para crear una selección manejable y ejecuta la misma prueba de aplicación con cada candidato. Mantén constantes el texto y el formato de salida donde lo permitan las API. Registra el identificador exacto del modelo, la voz, la región, la concurrencia y las diferencias de configuración que no puedas eliminar.
Prueba el tráfico normal y la carga máxima prevista. Registra solicitudes fallidas y reproducción interrumpida junto con la latencia en lugar de calcular una media rápida solo con solicitudes correctas. Conserva las observaciones originales para comparar después una actualización del modelo o un cambio de configuración con la misma base.
Para evaluar Cartesia, la documentación de Sonic 3.6 explica que el alias sonic-3.6 sigue las actualizaciones estables, mientras que un identificador con fecha permanece fijo. Fija una versión fechada cuando necesites una base reproducible. Empieza escuchando voces de Cartesia con tu texto en el entorno de pruebas y evalúa después la API en el cliente que publicarás. Escuchar ayuda a elegir una voz, pero no sustituye la prueba de despliegue.
Trata el alojamiento propio como una decisión operativa separada. Incluye capacidad de hardware, trabajo de despliegue, supervisión y mantenimiento junto con la inferencia del modelo. Un buen resultado de latencia no decide por sí solo si tu equipo debe operar el servicio.
La mejor elección es el endpoint que cumple tus requisitos de latencia y calidad de voz con una carga documentada. Compartir una familia de modelos ayuda a organizar candidatos. La evidencia para decidir procede del servicio que realmente desplegarás.