Voice AI de baja latencia: el presupuesto de latencia completo (2026)

Todos los blogs de proveedores sobre "voice AI de baja latencia" tratan en realidad de una sola caja del pipeline. Un nuevo modelo de voz que recortó 80 ms de la síntesis. Un ajuste de endpointing. Un truco de caché. Cada uno es real, y cada uno es inútil si las otras cinco etapas de tu ruta de llamada están consumiendo 1.200 ms mientras tú celebras los 80.

La latencia es un presupuesto, no una función. Quien llama escucha un solo número: el silencio entre el momento en que deja de hablar y el momento en que tu agente empieza. Ese número es la suma de cada etapa desde el micrófono hasta el altavoz, más la red que no controlas. Este es el modelo de extremo a extremo: lo que cuesta cada etapa, dónde se esconden realmente los milisegundos, y dónde el streaming, el endpointing y el almacenamiento en caché te ganan tiempo de verdad frente a dónde solo trasladan el problema.

Por qué la latencia es la línea que separa la "AI" de una conversación real

La alternancia de turnos entre humanos tiene un ritmo. En una conversación natural, el intervalo entre hablantes promedia unos 200 ms, y las personas empiezan a planificar su respuesta antes de que la otra termine. Cuando un agente telefónico deja 1,5 segundos de silencio después de cada frase, quien llama no piensa "qué AI tan impresionante". Piensa que se cortó la línea, habla encima del agente o cuelga.

Los umbrales prácticos con los que diseñamos:

• Un tiempo de respuesta por debajo de ~500 ms se siente conversacional. Quien llama apenas nota el intervalo.
• 500–800 ms es aceptable, pero suena claramente "de asistente". Está bien para muchos casos de uso.
• Por encima de ~1.000 ms se rompe el ritmo. Quienes llaman interrumpen, se repiten y la confianza se erosiona.

Ese objetivo por debajo del segundo lo es todo. Y no es tarea de un solo componente: es el presupuesto que repartes por toda la pila.

El presupuesto de latencia: cada etapa del micrófono al altavoz

Este es el viaje de ida y vuelta de un único turno conversacional. Rangos aproximados de producción para un agente bien construido en una llamada telefónica:

Suma todo eso y estarás entre aproximadamente 700 ms y 2,4 s. La horquilla es enorme, y fíjate en lo que la domina: el endpointing y el TTFT del LLM, no los modelos de STT o TTS que todo el mundo somete a benchmarks.

De esta tabla se derivan de inmediato dos reglas:

1. Optimiza primero la caja más grande. Cambiar un TTS de 120 ms por uno de 90 ms es ruido si tu endpointer espera 700 ms. Mide antes de optimizar.
2. Las etapas se solapan cuando haces streaming. El presupuesto anterior es el peor caso en serie. El streaming permite que el STT, el LLM y el TTS se ejecuten de forma concurrente en lugar de uno tras otro, que es de donde salen la mayoría de tus ganancias reales (más abajo).

Endpointing y detección de silencio: los 500 ms más infravalorados

El endpointing es la decisión de si el interlocutor ha terminado su turno o solo ha hecho una pausa para respirar. Es el mayor bloque controlable de latencia y el compromiso más difícil de todo el stack.

Enfoque ingenuo: esperar N milisegundos de silencio y luego lanzar. Si N es demasiado bajo (digamos 200 ms), cortas a la gente a mitad de frase, algo brutal cuando alguien lee un número de tarjeta de 16 dígitos o dice "mi dirección es... calle Oak, 42". Si N es demasiado alto (900 ms), cada turno se siente lento.

Lo que de verdad funciona en producción es un endpointing adaptativo y semántico en lugar de un temporizador de silencio fijo:

• El VAD (detección de actividad de voz) te da la señal en bruto de "hay energía de audio": rápido, pero torpe respecto a la intención.
• El endpointing semántico usa la transcripción parcial para juzgar si el enunciado está completo. "Mi número de cuenta es" está claramente inacabado; "quiero cancelar mi cuenta" es una idea completa. Un modelo que lee el texto parcial puede lanzarse antes ante enunciados completos y esperar más tiempo en mitad de un número.
• Tiempos de espera adaptados al contexto. Cuando acabas de pedir un número de teléfono, amplía la ventana de silencio y no trates las pausas entre dígitos como fin de turno. Vincula el umbral de endpointing al campo que estás recogiendo.

Si aciertas con esto, recuperas entre 300 y 500 ms en la mayoría de los turnos sin cortar nunca a quien llama. Si te equivocas, ningún cambio de modelo te va a salvar.

Streaming en todo: la latencia gratis que estás dejando sobre la mesa

La mayor mentira de la tabla del presupuesto en serie es que las etapas ocurren una tras otra. No deberían. Haz streaming en cada frontera y el pipeline se comprime:

• Transcripciones parciales. No esperes al resultado final del STT. Alimenta con los parciales a tu endpointer e incluso precalienta el contexto del LLM para no arrancar en frío cuando quien llama se detiene.
• Streaming de tokens desde el LLM. Lo que importa es el tiempo hasta el primer token, no el tiempo hasta completar la respuesta. En cuanto sale la primera cláusula por streaming, pásala al TTS. No necesitas la respuesta entera para empezar a hablar.
• Fragmentación del TTS. Sintetiza y empieza a reproducir la primera frase mientras el LLM aún está generando la tercera. El número que cuenta es el del primer byte de audio, no el del clip completo.

Bien hecho, quien llama oye las primeras palabras de la respuesta mientras el LLM todavía está escribiendo el resto. Así es como un stack cuyo presupuesto en serie suma 1,8 s entrega una respuesta percibida de 600 ms. El streaming no es una optimización que añades después: es la arquitectura desde la que partes.

Una salvedad: hacer streaming de TTS a mitad de generación significa que te comprometes con palabras antes de que exista la respuesta completa. Si tu LLM puede autocorregirse ("en realidad, déjame comprobarlo... no, tienes razón"), ya habrás dicho en voz alta la mitad equivocada. Restringe el modelo a respuestas que se comprometan de una sola vez, o almacena en búfer la primera cláusula hasta que la estructura de la frase sea estable.

Caché de audio y precalentamiento: ganancias reales, trampas reales

El caché es donde viven los posts del estilo "lo hemos hecho más rápido" de Vapi, y es genuinamente útil, con aristas afiladas.

Qué es seguro cachear o precalentar:

• Prompts fijos y texto de relleno. Saludos, mensajes de espera, avisos legales, "espere un momento mientras lo consulto". Presintetiza esto una vez. Cero latencia de TTS en tiempo de ejecución.
• Calentamiento de conexiones. Mantén abiertos los sockets de STT/LLM/TTS y los modelos calientes para que el primer turno de una llamada no pague el impuesto del arranque en frío. Solo esto puede ahorrar cientos de milisegundos en el primer turno.
• Muletillas predecibles. Un breve y natural "déjame consultarlo" reproducido mientras se ejecuta una llamada a herramienta lenta enmascara la latencia del backend que, de otro modo, quien llama oiría como silencio muerto.

Qué se rompe si lo cacheas:

• Cualquier cosa con datos dinámicos. Cachea "Su saldo es [X]" como plantilla y acabarás leyéndole el saldo equivocado a la persona equivocada. Cachea la frase portadora, sintetiza el campo variable en vivo.
• Audio personalizado o sensible desde el punto de vista del cumplimiento normativo. Nombres, datos de la cuenta, precios cotizados: sintetízalos de nuevo, cada vez.
• Versiones obsoletas de voz o modelo. Un clip cacheado de una voz TTS antigua junto a una en vivo resulta llamativamente obvio a mitad de frase. Versiona las claves de tu caché según el modelo de voz.

El caché te aporta más en las partes predecibles de una llamada. No hace nada por el turno de razonamiento dinámico, que es justo la razón por la que no puede ser toda tu estrategia de latencia.

Telefonía y realidad de la red: la última milla que no te pertenece

Puedes afinar cada modelo a la perfección y aun así lanzar un agente lento, porque una llamada telefónica viaja sobre una infraestructura que no controlas.

• La PSTN y el SIP añaden tiempo real. La red telefónica pública conmutada y el SIP trunking introducen retardo de transporte antes de que tu STT llegue siquiera a recibir el audio. El transcodificado del códec (por ejemplo, hacia/desde G.711) añade un poco más.
• Jitter y pérdida de paquetes. Las personas que llaman desde redes inalámbricas, con mal Wi-Fi o a través de operadores congestionados entregan el audio de forma irregular. Tu búfer de jitter suaviza la reproducción, pero añade latencia para lograrlo: otro compromiso que hay que ajustar, no eliminar.
• Geografía. Si tu inferencia se ejecuta en us-east y quien llama y tu proveedor de telefonía están en Europa, has añadido un viaje de ida y vuelta transatlántico a cada turno. Ubica tu ruta de medios junto a quienes llaman y a los endpoints de tu modelo.
• La ruta de medios importa tanto como el modelo. El puente de WebRTC a SIP, el enrutamiento del SBC y la ubicación de tu servidor de medios pueden costar o ahorrar más que un cambio de modelo. Esto es ingeniería de infraestructura, no prompt engineering.

La conclusión: presupuesta entre 100 y 300 ms para la red y la telefonía que no puedes optimizar, y asegúrate de que los milisegundos que sí puedes controlar no se estén desperdiciando en una ruta de medios que da rodeos por tres regiones.

Medir la latencia de los turnos de conversación en producción (la cifra que importa)

No puedes optimizar lo que no mides, y la métrica que importa no es el benchmark de ningún componente aislado. Es el tiempo desde el final del habla del usuario hasta el inicio del audio del agente, medido en producción, en llamadas reales y en el percentil que duele.

• Instrumenta el viaje de ida y vuelta completo. Marca con timestamp: último fotograma de audio de quien llama → activación del endpoint → primer token del LLM → primer byte del TTS → primer fotograma de audio de salida. Registra cada etapa en cada turno para que puedas ver qué bloque se pasó del presupuesto cuando una llamada resultó lenta.
• Vigila el p95, no la media. Tu latencia media puede ser unos estupendos 550 ms mientras el p95 es de 1,8 s, y son los turnos del p95 los que hacen que quienes llaman cuelguen. Las medias ocultan las llamadas que estás perdiendo.
• Haz seguimiento de la tasa de barge-in / interrupciones. Si quienes llaman hablan por encima de tu agente con frecuencia, tu endpointer se activa tarde o tu respuesta arranca despacio. Es un síntoma de latencia disfrazado de métrica de UX.

Implementa la instrumentación antes de ajustar. Toda afirmación de "hemos reducido la latencia" que no esté respaldada por una medición del p95 en producción es una conjetura.

Enlaces internos

• Cómo construimos el pipeline de voice AI: elecciones de STT, Whisper vs. Deepgram
• Cómo solucionar la latencia de SIP en soluciones de call center con AI
• Conectar WebRTC y SIP: traspasos de agentes de voz AI con baja latencia
• Agentes de voz AI para empresas: arquitectura y ROI
• Cómo gestionar grandes volúmenes de llamadas sin contratar más agentes (2026)

Preguntas frecuentes

Cuál es un buen objetivo de latencia para un agente de voice AI en producción? Apunta a menos de 800 ms de extremo a extremo (desde el final del habla de quien llama hasta el inicio del audio del agente), y toma como meta bajar de los 500 ms para lograr una sensación genuinamente conversacional. Mide en el p95, no en la media: la cola lenta es la que provoca que cuelguen.

¿Qué parte del pipeline de voice AI causa más latencia? Normalmente el endpointing y el tiempo hasta el primer token del LLM, no los modelos de STT o TTS en los que se centran la mayoría de los benchmarks. El endpointing puede añadir entre 200 y 800 ms por sí solo, así que es el primer sitio donde mirar antes de cambiar ningún modelo.

¿Reduce el almacenamiento en caché de audio la latencia de voice AI? Sí, para el contenido fijo: los saludos, las divulgaciones legales, los mensajes de espera y las frases de relleno pueden presintetizarse para obtener una latencia en tiempo de ejecución casi nula. No sirve de nada para los turnos de razonamiento dinámico, y almacenar en caché cualquier cosa con datos personalizados o variables corre el riesgo de leerle información equivocada a quien llama.

¿Por qué mi agente de voz parece lento incluso con un modelo rápido? Porque la latencia es la suma de todo el pipeline más la telefonía que no controlas. Un TTS rápido no ayudará si tu endpointer espera 700 ms, tu LLM transmite despacio o tu ruta de medios da rodeos entre regiones. Instrumenta cada etapa y arregla primero el bloque más grande.

Finn está construido priorizando la latencia: STT en streaming, endpointing semántico y traspaso de token a TTS ajustados para lograr turnos de conversación por debajo del segundo en llamadas telefónicas reales, no en clips de benchmark. Descubre cómo los agentes de voz de Finn gestionan el volumen de llamadas en producción sin los silencios muertos.