Reducir la latencia de un asistente de IA por voz: guía 2026

Tu agente de voz responde en dos segundos y la conversación se cae. El usuario espera, se aburre, empieza a hablar por encima del asistente o acaba escribiendo. La investigación sobre turnos de habla sitúa la pausa media entre personas en torno a 200 ms, y cualquier hueco por encima de 500 ms ya se percibe como poco natural. Todo lo que pase de 1,5 s parece un retraso que hay que pedir perdón por él.

La buena noticia es que el presupuesto para un agente de voz bien afinado en 2026 baja cómodamente de un segundo de extremo a extremo, y cada milisegundo por encima es corregible. La mala es que la mayoría de pipelines de voz autoalojados pierden entre 800 y 1500 ms en síntesis por lotes, STT bloqueante y un paso de recodificación del que nadie habla.

Este post recorre dónde se pierden realmente los segundos, qué optimizaciones mueven la aguja de verdad y cómo se ve un stack por debajo de 500 ms en 2026. Si estás montando el agente de voz desde cero, empieza por la guía de configuración de voz y vuelve luego para la pasada de latencia.

Dónde se pierden los segundos de verdad

Un turno de voz tiene cuatro pasos consecutivos, cada uno con su propio presupuesto. Falla uno y se cae el turno entero.

Etapa	Objetivo bien afinado 2026	Resultado autoalojado habitual
Detección de actividad de voz + captura	~50 ms	100-200 ms
STT (transcripción)	100-200 ms streaming	500-1500 ms por lotes
LLM tiempo hasta el primer token	150-400 ms	700-2000 ms
TTS primer chunk de audio	40-150 ms streaming	500-1200 ms por lotes
Transporte (WebRTC / subida a Telegram)	20-80 ms	200-600 ms

Los dos saltos reales son streaming y elección de proveedor. Un pipeline que termina el STT antes de arrancar el LLM, espera la respuesta completa del LLM antes de arrancar el TTS y recodifica el audio antes de subirlo se planta fácil en 3-4 s por turno. El mismo pipeline con bordes en streaming entre etapas, un TTS de baja latencia y el códec que ya acepta el canal se queda más cerca de 500-800 ms.

Streaming es la mayor victoria, con diferencia

La síntesis por lotes es la razón más habitual de que un agente de voz autoalojado se sienta lento. En un pipeline por lotes, el LLM termina toda la respuesta, entrega el texto completo al TTS, espera a que renderice el audio y luego lo reproduce. Si la respuesta tiene 30 tokens, el usuario espera los 30 antes de oír una sola sílaba.

El streaming lo da la vuelta. El LLM emite tokens conforme los genera, el TTS empieza a sintetizar en cuanto tiene la primera frase y el primer chunk de audio llega al canal mientras aún se está escribiendo la cola de la respuesta. Los benchmarks independientes de 2026 miden ese cambio como una reducción de 300-600 ms en latencia percibida, y hasta 400-800 ms menos en latencia P95 por turno cuando además haces streaming del STT hacia el LLM.

Dos reglas prácticas:

Streaming de entrada y de salida en el LLM. No bufferices la transcripción completa antes de llamar al LLM, ni bufferices la respuesta completa antes de llamar al TTS. Cualquier SDK serio soporta streaming de tokens.
Elige un TTS con primer chunk por debajo de 150 ms. El modo batch de ElevenLabs Multilingual v2 tiene una voz preciosa, pero un time-to-first-audio de 500-800 ms mata la conversación en tiempo real.

Latencia de TTS por proveedor, con números honestos

Los benchmarks de los proveedores mienten porque comparan su modo rápido contra el modo realista de todos los demás. Coval, Gradium y Future AGI publicaron cifras independientes en 2026 y el resumen útil es corto:

Cartesia Sonic Turbo - unos 40 ms de time-to-first-audio, el TTS de producción más rápido disponible. Cartesia Sonic-3 se queda cerca de 90 ms con una prosodia algo más rica.
ElevenLabs Flash v2.5 - alrededor de 75 ms en la ruta real-time, con la contrapartida de una fidelidad de clonación por debajo de Multilingual v2 o v3.
Deepgram Aura-2 - unos 313 ms P50 en el benchmark de Coval. Competitivo, pero no primera fila para latencia pura.
OpenAI tts-1 - unos 200 ms de primer chunk, por detrás de los proveedores real-time dedicados pero razonable si ya vives dentro de OpenAI.
Piper (autoalojado) - dominado por la CPU. En un VPS pequeño pierde a menudo frente a los proveedores hosted realtime, incluso sin el salto de red.

La latencia bruta ya no es el diferenciador arriba del mercado. Cartesia, ElevenLabs Flash, Rime y Deepgram publican todos por debajo de 150 ms de primer chunk, así que el eje útil es prosodia, clonación y coste. Para una comparativa más amplia del panorama de TTS de pago, lee la guía de proveedores de TTS.

Tiempo hasta el primer token del LLM

El presupuesto del LLM dentro de un bucle de voz en tiempo real es de 150-400 ms hasta el primer token. Tres técnicas lo llevan de "a veces cabe" a "siempre cabe":

Prompt caching. Para cualquier pipeline que reenvía el mismo system prompt (casi todos), activar prompt caching baja el time-to-first-token 200-400 ms sin más cambios que un flag.
Modelos pequeños y rápidos. GPT-4o-mini, Claude Haiku 4.5 y los modelos Llama alojados en Groq entregan de forma consistente el primer token en 100-180 ms. Ve al modelo grande cuando esos 500 ms extra de razonamiento merezcan la pena, no por defecto.
Decodificación especulativa en tu propia inferencia. Si autoalojas el modelo, la decodificación especulativa puede recortar el TTFT un 30-50% para la misma calidad de salida. Es más trabajo que cambiar de modelo, pero el techo es más alto.

La trampa del códec de audio

Casi todos los posts sobre latencia de voz ignoran el paso de recodificación, que es por qué los bots de Telegram autoalojados se sienten sistemáticamente más lentos de lo que los números sugieren. Telegram acepta notas de voz en Opus de forma nativa. Si tu TTS devuelve MP3 o WAV, algo en tu pipeline tiene que recodificar a Opus antes de que suba. Ese paso solo cuesta 200-500 ms en un VPS pequeño, tirados a la basura.

La solución está en el proveedor: pide directamente salida en Opus al TTS. ElevenLabs lo soporta, Cartesia lo soporta, la mayoría de proveedores modernos también. En Whisper autoalojado la misma trampa va al revés cuando la nota entrante es Opus y la decodificas por una ruta de códec lenta.

Si tu agente de voz pierde audio en lugar de solo ir lento, es otro problema distinto - el checklist de troubleshooting de voz cubre los modos de fallo típicos.

Un stack por debajo de 500 ms en 2026

Montado con los números de arriba, el carril rápido queda así:

STT: Deepgram Nova-3 en streaming - 60-100 ms
LLM: GPT-4o-mini o Claude Haiku 4.5 con prompt caching - 100-180 ms primer token
TTS: Cartesia Sonic Turbo o ElevenLabs Flash v2.5 con Opus nativo - 40-80 ms primer chunk
Transporte: WebRTC o subida directa a Telegram - 20-40 ms

Suma 50 ms de VAD y captura, mantén los bordes en streaming entre todas las etapas y la latencia percibida de extremo a extremo se queda por debajo de 400 ms. Eso está dentro de la ventana natural de turnos de habla.

El stack que la mayoría de gente ejecuta de verdad - Whisper hosted en batch, GPT-4o, ElevenLabs Multilingual v2 en batch, recodificar a Opus, subir - se queda más cerca de 2,5-3 s. Dos de las cuatro etapas están mal y el audio se pega un viaje extra innecesario.

Qué te quita de encima un agente de voz gestionado

Todo lo anterior es afinable si te gusta afinar. También es la parte del stack de voz autoalojado que cambia cada trimestre según lanzan modelos nuevos los proveedores. Si prefieres no perseguir Cartesia Sonic 3 frente a Sonic 4 en un archivo de configuración, la recomendación honesta es un agente gestionado que mantenga el stack de latencia al día por ti.

Hermify ejecuta un Hermes Agent gestionado en Telegram con STT en streaming, prompt caching activado por defecto, una cadena TTS de baja latencia y salida Opus nativa ya cableada. La latencia percibida medida en una nota de voz de Telegram suele quedar entre 500 y 800 ms de extremo a extremo. Conectas tu clave de OpenRouter, eliges tarifa y empiezas a hablar, sin docker-compose, sin ffmpeg y sin depurar códecs.

Empieza con Hermify y ten tu agente de voz activo en cerca de un minuto.