Latencia <800ms en voice agents: cómo lograr conversaciones naturales
Los humanos toleramos latencia <800ms en conversación voz para sentirla natural. El budget se distribuye: VAD 200-400ms, STT 100-300ms, LLM 500-1500ms, TTS 100-400ms, network 50-200ms. Optimizaciones críticas: VAD aggressive (200ms vs 500ms default), streaming STT/LLM/TTS en pipeline paralelizado, modelos rápidos (Haiku/Flash) para respuestas cortas, mismo región infraestructura, connection pooling. Total optimizado típico: 600-900ms.
Por qué <800ms es el umbral mágico
Los humanos toleramos latencia hasta cierto punto en conversación. Bajo 500ms: indistinguible de conversación natural. 500-800ms: aceptable, levemente notorio. 800-1500ms: claramente artificial pero usable. >1500ms: rompe el flujo y el usuario abandona o se frustra. Para voice agents profesionales, el target debe ser <800ms end-to-end (desde que el usuario termina de hablar hasta que el agent empieza a hablar).
El budget de latencia: dónde se va el tiempo
| Componente | Latencia típica | Optimización posible |
|---|---|---|
| VAD (Voice Activity Detection) end-of-speech | 200-400ms | Reducir a 150-250ms con configuración fina |
| STT processing último chunk audio | 100-300ms | Streaming STT vs batch |
| LLM time to first token | 500-1500ms | Modelos rápidos (Haiku, Flash) o cache |
| TTS time to first audio | 100-400ms | Streaming TTS, modelos rápidos |
| Network round-trips totales | 50-200ms | Mismo región VPS, CDN, WebRTC |
| TOTAL típico no optimizado | 950-2800ms | — |
| TOTAL optimizado bien | 600-900ms | — |
Las 7 técnicas de optimización
1. VAD aggressive con confidence threshold
Configurar VAD para declarar "end of speech" agresivamente. Default WebRTC VAD ~500ms silencio; ajustar a 200-300ms con confidence threshold 0.85. Tradeoff: ocasionalmente cortar al usuario si hace pausa pensativa. Aceptable con buen barge-in.
2. Streaming STT (no batch)
Usar Deepgram Nova-3 streaming en lugar de batch. STT empieza a procesar audio en cuanto llega cada chunk, no espera fin de speech. Latencia primer token: 100-200ms vs 500-800ms batch.
3. LLM rápido para respuesta corta
Para respuestas conversacionales cortas (1-2 sentencias), usar Claude Haiku 4.5 o Gemini Flash 2.5 en vez de Claude Sonnet/GPT-4o. Time to first token 200-400ms vs 800-1500ms. Reservar modelos pesados para razonamiento complejo.
4. LLM streaming output
El TTS no debe esperar a que LLM termine respuesta completa. Empezar TTS con primeros 10-15 tokens del LLM streaming. Mientras TTS reproduce primera oración, LLM sigue generando segunda oración. Pipeline paralelizado.
5. TTS streaming primer audio
Polly Generative, Gemini Live y OpenAI Realtime soportan streaming: empezar a enviar audio en cuanto está disponible primer chunk, no esperar generación completa. Latencia primer audio: 100-200ms vs 500-1000ms batch.
6. Mismo región infraestructura
STT provider + LLM API + TTS provider en misma región (us-east-1 si target MX). Reducir round-trips internacional. Si LiveKit Cloud, usar región us-west2 más cercana a MX. Ahorro: 50-150ms por round-trip.
7. Pre-warming + connection pooling
Mantener conexiones HTTP/WebSocket abiertas al LLM/STT/TTS. No abrir nueva conexión por cada llamada. Reduce SSL handshake (50-100ms) y TCP setup (50ms).
Caso real medido
Voice agent producción 2026, stack LiveKit + Deepgram + Claude Haiku + Polly Generative:
- VAD detect end-of-speech: 220ms
- STT final transcript: 180ms
- LLM time to first token (Haiku): 350ms
- TTS time to first audio (Polly): 180ms
- Network overhead: 80ms
- Total: 1010ms (objetivo <800ms — falta optimizar)
Tras optimización (LLM streaming + TTS streaming + VAD aggressive):
- VAD: 220ms
- STT: 180ms
- LLM time to first chunk: 350ms (sobrelapado con siguiente)
- TTS time to first audio (streaming): 100ms
- Network: 80ms
- Total perceptual: 750ms (objetivo cumplido)
Barge-in: interrumpir al agent
Conversación natural permite interrupciones. Si el agent está hablando y el usuario empieza a hablar, agent debe: (1) detectar audio del usuario (VAD), (2) parar TTS inmediatamente, (3) STT del nuevo audio del usuario. Latencia barge-in target: <200ms. Implementación correcta en LiveKit Agents y OpenAI Realtime; menos pulido en Twilio ConversationRelay.
Preguntas frecuentes
¿Por qué la latencia importa tanto en voice agents vs chat texto?
En chat texto el usuario tolera 2-5 segundos de "thinking" porque no espera respuesta inmediata. En voz, el silencio >1 segundo se siente "awkward" — los humanos llenamos silencios automáticamente. Si el agent tarda 2 segundos en responder, el usuario empieza a hablar (creyendo que el agent no entendió), causando overlap audio. Resultado: confusión, frustración, abandono de llamada.
¿Vale la pena Gemini Live por la latencia baja?
Sí para casos donde 100ms cuentan (emergencias, debate ágil, ventas competitivas). El integration LLM+TTS en un round-trip vs separados reduce ~300ms vs Polly+Claude. Contras: voces español MX menos pulidas, pricing mayor, lock-in Google. Para 90% casos PyME MX, stack Polly+Claude Haiku con optimizaciones es suficiente y más barato.
¿Cómo medir latencia en producción?
Instrumentar timestamps cada componente: end_of_speech_ms, stt_final_ms, llm_first_token_ms, tts_first_audio_ms. Persistir en tabla call_latency por llamada. Dashboard semanal P50, P95, P99 por componente. Alertas si P95 >1000ms. Investigar componente fuera de SLA, ajustar.
¿LiveKit maneja barge-in automático?
Sí, LiveKit Agents tiene barge-in integrado con VAD. Cuando detecta audio del usuario durante speech del agent, automáticamente: pausa TTS, captura audio del usuario, lo envía a STT. Configurable: barge-in agresivo (cualquier audio interrumpe) vs barge-in conservador (requiere >500ms audio sustained). Tradeoff: agresivo más natural pero falsos positivos (ruido ambiente).
¿Tu PyME necesita una solución de IA medible?
Conversación de 30 min, sin compromiso. Cotizamos en menos de 24 horas. Precios públicos en pesos mexicanos.
Agenda conversación →