Avatares conversacionales con IA, comparativa de latencia entre LLM y Audio2Face

TTFT significa «Time To First Token» o, en el contexto de audio, tiempo hasta el primer byte de audio. Es el intervalo que transcurre desde que el usuario deja de hablar hasta que llega el primer fragmento de respuesta sonora del modelo de lenguaje. No incluye Audio2Face ni el buffer de reproducción, es puro tiempo de «pensamiento» del LLM.

Cuanto menor sea el TTFT, antes puede empezar a procesarse el audio. Y cuanto más estable sea (menor desviación estándar), más predecible resulta la experiencia para el usuario.

Aunque otra métrica habitual en la evaluación de modelos es el TPOT (Time Per Output Token), en este estudio no se ha medido el TPOT (Time Per Output Token) porque, en este escenario, no aporta información relevante para la experiencia del usuario. Una vez recibido el primer fragmento de audio, el cuello de botella pasa a ser Audio2Face, que dispone de tiempo suficiente para procesar los siguientes fragmentos mientras estos continúan llegando. Por ello, el TTFT es la métrica que mejor representa la capacidad de respuesta percibida del sistema.

Todos los proveedores se han medido en las mismas condiciones para que los resultados sean comparables:

• Detector de voz (VAD): el mismo detector acústico en todos los casos, basado en nivel de señal (RMS), con umbral 0,01 y confirmación de 150 ms. Se activa cuando el usuario deja de hablar.
• Silencio del servidor: 200 ms en todos los proveedores, el tiempo extra que espera el servidor antes de enviar la petición al LLM.
• Preguntas de prueba: 20 preguntas organizadas en cuatro niveles de dificultad (5 fáciles, 5 medias, 5 complejas y 5 muy complejas), con 1 pregunta de calentamiento excluida del análisis.
• Región de despliegue: GPT Realtime se sirve desde la región Azure Sweden Central. Gemini Live no expone región fija; Google enruta automáticamente las peticiones.

Cada una de las 20 preguntas se ejecutó una única vez en cada proveedor, registrando el TTFT obtenido. Las métricas agregadas (media, desviación típica, mínimo y máximo) se calcularon a partir del conjunto de las 20 mediciones por modelo.

La clasificación se realizó en función del esfuerzo de razonamiento esperado por parte del modelo. Las preguntas fáciles corresponden a saludos o conocimiento general sencillo; las medias requieren explicaciones breves; las complejas implican razonamiento o elaboración de recomendaciones; y las muy complejas exigen respuestas extensas con planificación, comparación o explicación detallada de conceptos.

El listado completo puede consultarse en el Anexo: Banco de preguntas utilizado.

Región de despliegue: GPT Realtime se sirve desde la región Azure Sweden Central. Gemini Live no expone región fija; Google enruta automáticamente las peticiones.

TTFT medio de cada proveedor. La barra de error muestra la desviación típica.

El hallazgo más relevante es el comportamiento de cada modelo ante el incremento de complejidad. Gemini 3.1 Live mantiene una latencia prácticamente constante (~1.400 ms) independientemente de la dificultad. Los modelos GPT, en cambio, escalan de forma significativa: GPT-Realtime pasa de 1.201 ms en preguntas fáciles a 2.308 ms en preguntas muy complejas.

Nota: GPT-Realtime se desplegó en la región Azure Sweden Central, mientras que Gemini 3.1 Live utiliza el enrutado automático de la infraestructura de Google. En consecuencia, parte de las diferencias observadas en el TTFT podrían estar influidas por la latencia de red entre el cliente y la infraestructura de cada proveedor.

La línea de Gemini se mantiene plana; las de los modelos GPT suben con la dificultad.

Gemini es el más rápido y consistente. Con una media de 1.407 ms y una desviación típica de solo ±118 ms, Gemini 3.1 Live es el proveedor más predecible: responde siempre en el mismo rango, independientemente de lo que se le pregunte.

La latencia de Gemini no escala con la complejidad. Pregunta fácil: 1.372 ms. Pregunta muy compleja: 1.416 ms. La diferencia es de apenas 44 ms, prácticamente ruido estadístico. Esto sugiere que el modelo está optimizado para latencia constante, no para dedicar más tiempo a razonar según la dificultad. Durante las pruebas no apreciamos diferencias significativas en la calidad de las respuestas que justificasen esa latencia constante. El hallazgo más interesante, por tanto, no es quién es más rápido, sino que Gemini mantiene latencia constante sin importar la complejidad mientras GPT escala su tiempo de razonamiento con la dificultad.

GPT-Realtime es el más rápido en preguntas fáciles. En preguntas sencillas llega a 1.201 ms, más rápido que Gemini. El problema aparece con la complejidad: en preguntas muy complejas escala hasta 2.308 ms, casi el doble.

GPT-Realtime-Mini tiene outliers severos. Dos preguntas muy complejas disparan su latencia a 4.446 ms y 3.781 ms. Con una desviación típica de ±872 ms es el más impredecible de todos, directamente no recomendable para producción con preguntas complejas.

Calidad de las respuestas. Más allá de la latencia observamos diferencias cualitativas entre modelos:

• Gemini: el único proveedor que responde con una hora plausible cuando se le pregunta. Mantiene voz y tono consistentes durante toda la conversación.
• GPT-Realtime, 1.5 y 2: se niegan a dar la hora, probablemente por falta de acceso al reloj del sistema. También detectamos cambios inesperados de voz durante la conversación: en algunos momentos el asistente modificaba el timbre o la entonación de manera notable, llegando incluso a sonar como una voz del género opuesto. Estos cambios rompían la sensación de continuidad.
• GPT-Realtime-Mini: falla en razonamiento práctico. Cuando se le pregunta si es mejor ir a pie o en coche a un lavadero situado a 20 metros de casa, sugirió conducir. Fue el único modelo que respondió incorrectamente.

Estas observaciones son cualitativas, basadas en la experiencia durante las pruebas. No forman parte de un estudio de calidad sistemático, pero son relevantes para la decisión de producción.

NVIDIA Audio2Face no procesa el audio completo de una sola vez, sino que lo recibe dividido en pequeños fragmentos (chunks) que se envían de forma continua por gRPC. Cada chunk contiene unos pocos cientos de milisegundos de audio y, en cuanto Audio2Face recibe uno, empieza a generar las animaciones faciales correspondientes sin esperar al resto de la frase.

El tamaño del chunk representa un compromiso entre latencia y eficiencia: los chunks pequeños permiten iniciar antes la animación del avatar, pero incrementan el número de peticiones y el coste de procesamiento. Los chunks más grandes reducen ese overhead, pero obligan a esperar más antes de comenzar la animación.

El audio completo se trocea en fragmentos de 500 ms que viajan por gRPC hacia Audio2Face.

• Entornos de prueba: RTX 4070 (portátil, Docker local), RTX 4080 Super (sobremesa, Docker local), RTX 5090 (sobremesa, Docker local) y NVIDIA A100 (Azure Container App). El detalle de los equipos está en el anexo.
• Diseño del estudio: barrido de 25 tamaños de chunk (de 300 ms a 1.500 ms en pasos de 50 ms), con 5 chunks por paso (125 chunks totales por entorno). El canal gRPC se reutiliza para eliminar el overhead de conexión.

Punto de equilibrio entre la duración del chunk y la latencia de Audio2Face en cada entorno.

La RTX 5090 obtiene la menor latencia en todos los tamaños de chunk. Sin embargo, la diferencia respecto a la RTX 4080 Super es pequeña (24-63 ms en las pruebas realizadas), por lo que el impacto sobre la latencia total del sistema es reducido. Desde el punto de vista de la latencia, ambas GPU ofrecen un comportamiento muy similar.

En cuanto a la NVIDIA A100 desplegada en Azure Container Apps, su rendimiento también es muy próximo al de la RTX 5090, con una pequeña latencia adicional atribuible a la comunicación por red. Este tipo de despliegue constituye una alternativa para arquitecturas en las que Audio2Face se ejecuta de forma centralizada. No obstante, este estudio se limita al análisis de latencia y no evalúa el coste de operación ni el rendimiento bajo cargas concurrentes.

Los resultados y recomendaciones deben interpretarse teniendo en cuenta las siguientes restricciones:

• Entorno monousuario. Todas las pruebas se realizaron con un único usuario concurrente. El comportamiento del sistema bajo carga múltiple, especialmente en la configuración con A100 en nube, no se ha evaluado y puede diferir significativamente de los valores presentados.
• Latencia de red no controlada. El TTFT de cada proveedor incluye la latencia de red entre el cliente y la infraestructura del modelo. GPT-Realtime se sirvió desde Azure Sweden Central, mientras que Gemini 3.1 Live utiliza el enrutado automático de Google en función de la ubicación del cliente. Parte de las diferencias observadas puede deberse a esta variable y no al rendimiento intrínseco del modelo.
• Evaluación de calidad no sistemática. Las observaciones sobre calidad de respuesta (coherencia, tono de voz, capacidad de razonamiento) son cualitativas y se recogieron durante las pruebas de latencia. No forman parte de un estudio estructurado y no deben tomarse como conclusiones definitivas sobre las capacidades de cada modelo.
• Buffer de sincronización y render excluidos. La latencia total reportada no incluye el buffer de sincronización entre audio y blendshapes ni el tiempo de render de Evergine. Ambos componentes son constantes entre configuraciones y no afectan a la comparativa, pero sí a la latencia real percibida por el usuario.