90ms de desviación de labios supera a una pausa de 400ms — y ese es todo el problema
Después de enviar una docena de demostraciones de avatar de Gemini Live, nos encontramos con un hallazgo incómodo: los usuarios perdonan un retraso de 400ms antes de que el avatar hable. Señalan una desviación audiovisual de 90ms como rota. Este no es un problema de renderizado. Es un problema de arquitectura de transmisión de respuestas, e ignorarlo significa enviar características que mediblemente reducen la confianza incluso cuando el modelo responde correctamente.
El efecto McGurk explica por qué. Cuando el audio y el video se desalinean más de ~80-90ms, los cerebros humanos rechazan la combinación como artificial — el mismo desajuste neural que hizo que la sincronización de labios CGI temprana se sintiera inquietante. Una pausa reflexiva (donde el avatar espera antes de hablar) se lee como competencia. El movimiento de boca desalineado se lee como IA rota. Esa brecha de percepción es por qué los fotogramas de visema no son una preocupación de renderizado; son otra corriente de tokens que necesita contrapresión y sincronización de reloj.
Second Life ejecutó avatares durante 20 años sin resolver esto porque el habla era texto asincrónico. Un usuario escribía, presionaba enviar, y el servidor renderizaba la boca del avatar. La síntesis de texto a voz en tiempo real más la generación de visema cambia el contrato completamente. Ahora Gemini 3.8 Live emite fragmentos de audio y eventos de visema/gesto en canales de eventos separados, y la mayoría de equipos están tratando esos canales de forma independiente. Ahí es donde se rompe la sincronización.
Por qué tu canalización de transmisión de respuestas actual no puede mantener la sincronización
El antipatrón es ubicuo: WebSocket para audio, Server-Sent Events separados para gesto, sin reloj compartido. El modelo emite eventos con marcas de tiempo, pero el navegador del cliente los renderiza en bucles independientes — audio en la Web Audio API, gestos en requestAnimationFrame a 30fps. Esos bucles se desvían. Las pausas de recolección de basura se comen 40-80ms de fotogramas de gesto. El almacenamiento en búfer de TTS token por token se desincroniza del renderizado de visema porque TTS está optimizando la calidad de audio mientras los gestos esperan.
Las cadenas de agentes de seis herramientas empeoran esto exponencialmente. Cada vez que el modelo se detiene para llamar a una herramienta, la corriente de gesto se detiene. Pero el cliente sigue consumiendo fragmentos de audio almacenados en búfer. Para cuando la herramienta regresa y el modelo se reanuda, la boca del avatar ya está desincronizada con lo que está a punto de decir. El adelanto de audio crece. Los usuarios ven el avatar como congelado o nervioso.
La desviación del reloj entre las marcas de tiempo de emisión del modelo y el reloj de reproducción del cliente agrega otros 20-30ms de varianza. Si tu servidor de modelo y cliente no están de acuerdo sobre qué es "ahora", cada decisión de fotograma se desvía más. La varianza de latencia es lo que mata los SLA de agentes, y la transmisión multimodal agrava ese problema porque cada milisegundo de jitter en un canal se filtra en la percepción del otro.
El patrón de reloj de fotograma unificado que enviamos en su lugar
Nos movimos a un único reloj de presentación monótono en el lado del cliente. El modelo emite fragmentos etiquetados con una marca de tiempo de presentación (PTS). Los fotogramas de audio, IDs de visema y etiquetas de gesto se envuelven en un único sobre de fotograma con un sequence_id compartido. En lugar de gestionar dos corrientes independientes, gestionamos una: {seq, pts_ms, audio_chunk, viseme_id, gesture_tag}.
Las matemáticas: un búfer de jitter de 120ms acepta el 90% de la varianza de red sin cruzar el umbral de percepción de 60ms. Almacenamos profundidad para mantenernos por debajo de eso; si el búfer se llena, soltamos fotogramas de visema antes de fotogramas de audio, nunca al revés. Perder una forma de boca es invisible. Perder audio es fatal.
En el lado del servidor, emitimos un fotograma de latido cada 33ms incluso durante pausas de pensamiento del modelo — un fragmento de audio de cero bytes con una etiqueta de gesto que dice "pensando". El avatar no se congela; obtiene un gesto de baja confianza mientras el modelo trabaja. Cuando la herramienta regresa, el gesto transiciona suavemente a hablar.
El patrón de observabilidad que tomamos prestado de registros de razón de caché también se aplica aquí: registra por qué un fotograma fue soltado o retrasado, no solo que lo fue. Cuando ves que el p95 drift se dispara, necesitas saber si es jitter de red, pausas de GC, o el modelo alcanzando el límite de tokens a mitad del gesto.
Presupuesto de latencia: dónde van realmente los 250ms
Objetivo: 250ms de extremo a extremo desde el momento en que el usuario deja de hablar hasta que la boca del avatar se abre. Así es como ese presupuesto típicamente se gasta:
- ~80ms: Finalización de ASR (posprocesamiento de voz a texto)
- ~60ms: primer token del modelo
- ~40ms: primer fragmento de audio de TTS
- ~30ms: tránsito de red
- ~40ms: búfer de jitter y corrección de desviación
Las llamadas de herramientas no caben en este presupuesto. Una búsqueda web toma 300-500ms. Si dejas que eso bloquee, el avatar se congela y los usuarios perciben una respuesta rota. El truco: patrones de habla de relleno. Mientras el modelo está en medio de una llamada de herramienta, emite una etiqueta de gesto de baja confianza y fragmentos de audio sintético ("verificando eso para ti..."). El avatar se mantiene en movimiento. Para cuando la herramienta regresa, los usuarios no perciben una brecha.
Para visibilidad de producción, registra pts_emitted vs pts_rendered por fotograma y alerta cuando el p95 drift exceda 60ms. Esa es tu advertencia temprana de que la arquitectura se está desviando antes de que los usuarios reporten que el agente se siente "raro".
Modos de fallo que hemos experimentado en los últimos 60 días
El AudioContext de Safari se reanuda 200ms tarde después de una pestaña de fondo. Mató la sincronización del avatar en el 18% de las sesiones de iOS hasta que agregamos un ping de calentamiento cuando la página vuelve al foco. Gemini Live emitió eventos de visema para habla interrumpida (barge-in del usuario) que nuestro cliente siguió renderizando — el avatar pronunció palabras que nadie escuchó porque el usuario ya había comenzado a hablar. Ahora nos suscribimos a eventos de interrupción y cancelamos fotogramas de gesto pendientes.
Un borde de CDN cambió a mitad de la transmisión, agregando 70ms de jitter que nuestro búfer fijo no podía absorber. Los eventos de gesto llegaron después del audio debido a cargas útiles más pequeñas que se adelantaban en HTTP/2 — necesitaba ordenamiento explícito por sequence_id. La brecha de evaluación es real: ningún punto de referencia estándar detecta fallos de sincronización. Ahora puntuamos sesiones en coherencia perceptual manualmente — viendo trazas de video y calificándolas 1-5 — hasta que la herramienta alcance.
El problema más difícil: las clasificaciones no predicen qué rompe a los agentes en producción. Gemini 3.8 Live obtiene una puntuación alta en puntos de referencia de razonamiento pero los fallos del avatar no son visibles en la precisión de tokens. Tienes que enviar observabilidad primero, medir la desviación de sincronización en la naturaleza, e iterar en la arquitectura.
Antes de que envíes
Instrumenta pts_emitted vs pts_rendered en cada fotograma durante una semana. Si el p95 drift excede 60ms, arregla la arquitectura de transmisión antes del renderizado. Si quieres un segundo par de ojos en la traza, estamos aquí.