Cómo construí directamente un agente de voz con menos de 500 ms de latencia

• Presentación de un caso de desarrollo de un agente de voz autoconstruido para sistemas de IA basados en voz, con una latencia reducida a alrededor de 400 ms
• Se conectaron STT, LLM y TTS en un pipeline en tiempo real, logrando una velocidad de respuesta 2 veces más rápida que la de plataformas comerciales existentes como Vapi
• Con Deepgram Flux se gestionan la detección de habla y los cambios de turno, y usando el modelo llama-3.3-70b de Groq se redujo drásticamente el tiempo de generación del primer token
• Mediante despliegue geográfico y optimización de red, la latencia se redujo a menos de la mitad al desplegar en la región de la UE
• La clave de un agente de voz está en la orquestación en tiempo real y el diseño del pipeline, y al implementarlo directamente se pueden identificar con claridad los cuellos de botella de rendimiento

---

Contexto de la construcción del agente de voz

• Basado en la experiencia desarrollando un prototipo de agente de voz para una gran empresa de bienes de consumo, se intentó una implementación propia para manejar directamente la complejidad de las plataformas comerciales
• Plataformas como ElevenLabs y Vapi son prácticas, pero es difícil entender cómo funcionan internamente y no permiten un control fino de la latencia
• El objetivo era reproducir directamente un rendimiento al nivel de Vapi, y se logró en un día con unos 100 dólares en créditos de API

La complejidad de los agentes de voz

• A diferencia de los chatbots basados en texto, la voz requiere gestión de turnos en tiempo real (turn-taking)
• En el momento en que el usuario empieza a hablar, el sistema debe detener de inmediato su emisión, y cuando el usuario se detiene, debe comenzar a responder rápidamente
• Solo con una detección simple de voz (VAD) es difícil determinar con precisión el final de una intervención, y eso genera latencia, solapamiento de intervenciones y silencios innecesarios

Primera implementación: prueba basada en VAD

• Se recibió un stream de audio μ-law usando un servidor FastAPI y WebSocket de Twilio
• Con Silero VAD se determinaba la presencia de voz y, al detectar el final de una intervención, se reproducía un archivo WAV previamente grabado
• Aunque era simple, permitió confirmar una respuesta inmediata y un flujo conversacional natural
• En esta etapa se obtuvo una referencia para medir el límite inferior de la latencia

Segunda implementación: Deepgram Flux y pipeline en tiempo real

• Se introdujo Deepgram Flux para integrar transcripción en streaming y detección de turnos
• Cuando Flux detecta el final de una intervención, el procesamiento sigue este orden
  • Se envían el resultado de la transcripción y el historial de conversación al LLM
  • En cuanto se genera el primer token, se hace streaming hacia TTS (WebSocket)
  • El audio generado se transmite en tiempo real a Twilio
• Mantener la conexión TTS precalentada (warm pool) redujo unos 300 ms de latencia
• Cuando el usuario empieza a hablar, se cancelan de inmediato el LLM, el TTS y la transmisión de audio, logrando una interrupción natural

Medición de latencia y despliegue regional

• Al ejecutarlo localmente desde Turquía, se producía una latencia promedio de 1.6 a 1.7 segundos
• Al desplegarlo en la región EU de Railway y alinear Twilio, Deepgram y ElevenLabs también en la región EU
  • Se redujo a un promedio de 690 ms (790 ms total), unos 50 ms más rápido que Vapi
• La reducción de latencia mejoró mucho la capacidad de respuesta en la conversación y también hizo más fluida la interrupción durante el habla

Selección del modelo y mejora del rendimiento

• Al principio se usó gpt-4o-mini, y luego se cambió a Groq llama-3.3-70b
• Según las pruebas, el tiempo hasta el primer token (TTFT) del modelo de Groq fue hasta 3 veces más rápido que el de OpenAI
• Se logró una latencia de extremo a extremo promedio inferior a 400 ms, con el primer audio llegando en menos de 500 ms
• A este nivel, la sensación es que el agente responde más rápido que una persona

Principales aprendizajes técnicos

• La optimización de latencia depende de gestionar toda la ruta desde el final de la intervención hasta la primera salida de voz
• Como el TTFT representa más de la mitad de la latencia total, es importante elegir un modelo de baja latencia
• Es necesario convertir STT→LLM→TTS en un pipeline de streaming en lugar de procesarlo de forma secuencial
• Para mantener una conversación natural, hay que cancelar de inmediato todos los componentes cuando se interrumpe una intervención
• La proximidad geográfica entre servicios tiene un impacto decisivo en la latencia

Comparación con plataformas comerciales

• Vapi y ElevenLabs siguen siendo útiles para la mayoría de los equipos porque ofrecen funciones adicionales como API, estabilidad y observabilidad
• Sin embargo, al construirlo directamente se pueden entender los cuellos de botella reales y el significado de los parámetros, y también es posible una
  orquestación personalizada adaptada a necesidades específicas
• Al final, los sistemas de voz son un problema de orquestación, y cuando se ve claramente la estructura, se convierte en un reto de ingeniería resoluble

Código fuente

• La implementación completa está publicada en GitHub: github.com/NickTikhonov/shuo

[GN⁺]

Comentarios en Hacker News

• Este artículo es realmente interesante. Hace tiempo el equipo de Amazon Alexa investigó este problema y hasta tiene patentes relacionadas.
  En una conversación, la latencia promedio entre personas es de 0 ms; es decir, la siguiente persona empieza a hablar incluso antes de que la otra termine. Esto pasa porque el cerebro predice lo que dirá la otra persona y al mismo tiempo prepara la respuesta.
  En cambio, la gente sí espera cierta latencia de un asistente de voz. Hay dos motivos: la percepción de que la computadora tiene que “pensar” y la latencia de las llamadas por celular.
  Casi ninguna respuesta de Alexa está por debajo de 500 ms. Antes simplemente se tomaban 300 ms de silencio como “fin del turno”, pero la clave real es el semantic end-of-turn.
  Ahora hay suficientes recursos de cómputo, así que me da curiosidad cuánto habrá avanzado esto. El procesamiento por cercanía geográfica (edge computing) fue un gran punto de inflexión.

  • La latencia de las llamadas por celular estresa especialmente a las personas mayores. En la época del teléfono fijo casi no había retraso, así que sienten frustración sin entender bien por qué les incomoda.
  • No estoy de acuerdo con el punto 2. La latencia de los asistentes de voz sigue siendo demasiado lenta. Te hace pensar “¿sí funcionó?” mientras esperas. No creo que la latencia del celular se traslade como expectativa a otros dispositivos.
  • Tomar 300 ms de silencio como fin del turno era demasiado incómodo. Por eso uno tenía que meter a propósito muletillas (filler) como “eh…”, y al final terminé dejando de usar el chat de voz.
  • Gracias por compartir algo tan interesante. Pero me pregunto por qué Amazon/Google/Apple dejaron de innovar en asistentes de voz en los últimos años. Con la base de usuarios que ya tenían, podrían haber redefinido el mercado.
  • Creo que se refiere a una arquitectura en la que el LLM anticipa y continúa predictivamente la intervención del usuario. Si cuando la persona realmente termina de hablar coincide con la predicción, se puede responder de inmediato sin latencia. También parece viable predecir varios hilos candidatos en paralelo e ir podándolos.

• Creo que la voz al final es un problema de turn-taking. Hay una mejora fácil que nadie ha tocado: las muletillas y el control del ritmo.
  Si el LLM detecta una breve pausa, podría meter muletillas con contexto como “mmm” o “claro” mientras se genera la respuesta real. Eso haría que la conversación se sienta mucho más natural.

  • Totalmente de acuerdo. Si primero un modelo pequeño de baja latencia genera una respuesta breve y el resultado de TTS se deja en caché, se puede reducir la latencia de forma extrema. Frases como “un momento, estoy pensando” podrían salir en milisegundos.
  • Pero quizá no sea una “mejora fácil”. Humanizar un sistema robótico es difícil, y cambiar solo la estructura de las frases puede hacer que suene aún más mecánico. Lo intenté yo mismo y fracasé.
  • Relacionado con esto, es interesante el blog de LiveKit “Prompting Voice Agents to Sound More Realistic”.
  • Si el sistema pudiera predecir la respuesta antes de que el usuario termine de hablar, sería mucho más natural.
  • Cuando se detecta mal el fin del turno, también podría ser posible enlazar de forma natural usando filler a nivel de fonema. Y al revés, si se detectó demasiado tarde, se podría fijar de antemano la primera sílaba y meter eso en el prompt para empezar la respuesta con ella.

• Excelente artículo. El OpenAI Responses client adoptó recientemente websockets y eso redujo la latencia.
  Otra opción es ejecutar un LLM diminuto directamente en local. Yo armé un pipeline completamente local con el proyecto ova y logré tiempos de ida y vuelta de menos de 1 segundo incluso sin streaming.

  • Está muy bueno el proyecto, ya lo guardé en favoritos. Me gustaría compartir experiencias y platicarlo más adelante.

• La estructura del pipeline de streaming y el análisis de latencia por etapas me parecieron muy útiles. Me impresionó que implementaran directamente el loop de turn-taking.
  Aun así, la comparación de “2 veces más rápido que Vapi” es un poco inexacta. Vapi hace muchas más cosas, como tool calling, webhooks y enrutamiento multi-tenant.
  El verdadero valor de este artículo está en la “perspectiva de haber construido por cuenta propia el loop de orquestación”. Si se hubiera resumido simplemente como “lo que aprendí al hacerlo yo mismo”, habría sido perfecto.

• Yo también estoy construyendo un agente de voz comercial con la combinación Twilio + Deepgram + ElevenLabs + LLM API.
  La clave no fue la precisión del STT, sino la UX del turn-taking. Cuando cambiamos de un umbral fijo de silencio a semantic end-of-turn, la percepción cambió por completo.
  La latencia entre regiones también importa. Al conectar desde India a servidores en EE. UU., solo el salto edge de Twilio agregaba entre 150 y 250 ms. Mejoró con enrutamiento por región.
  Manejar el barge-in (interrupción a media respuesta) también es complejo. No solo hay que detener el LLM y el TTS, sino también revertir los workflows automatizados que ya se hayan ejecutado. Antes teníamos un bug donde, si alguien interrumpía durante la confirmación de una reserva, la reserva igual se completaba de verdad.

• Soniox Real-time (compatible con 60 idiomas) maneja la endpoint detection a nivel de modelo. Es mucho más preciso que VAD.
  Se puede consultar la documentación técnica, el benchmark de Daily y la página de demo.
  Antes trabajé en Soniox. Fue el primer servicio en implementar endpoint detection en tiempo real.

  • En el texto original dice que usaron Deepgram Flux. Eso también soporta endpointing y está en una capa de abstracción superior a VAD.
  • Actualmente uso Soniox, así que me da curiosidad cómo era trabajar ahí por dentro. Me gustaría saber cuál es el secreto para lograr rendimiento SoTA con precios bajos frente a la competencia.

• Personalmente creo que la arquitectura STT → LLM → TTS tiene límites. El futuro está en los modelos de voz end-to-end.
  Hace 2 años probé con la demo de Chirpy, pero para llegar a algo realmente utilizable se necesitaba entrenamiento dedicado. Era imposible de sostener como side project.

  • Desde esa perspectiva, la investigación de NVIDIA PersonaPlex te puede parecer interesante: https://research.nvidia.com/labs/adlr/personaplex/
  • Yo me he dedicado casi exclusivamente a agentes de voz en los últimos años. El modelo en cascada (cascading model) no va a desaparecer pronto.
    Los clientes empresariales valoran la auditabilidad y la confiabilidad. En industrias reguladas como salud o finanzas, hay que poder validar por separado la salida de STT y la del LLM.
    En cambio, los modelos de voz end-to-end encajan mejor en usos narrativos como entrevistas o encuestas. Los clientes reales quieren más solidez de ingeniería que el modelo más nuevo.
  • En el fondo, el modelo tiene que llevar incorporada la “capacidad de predecir cuándo me toca hablar”. El modo full-duplex de Moshi muestra bien esa dirección: https://arxiv.org/abs/2410.00037
  • La ventaja de la arquitectura en cascada es que puedes reemplazar cada modelo por etapa. Como STT, TTS y LLM avanzan a ritmos distintos, da mucha flexibilidad.
  • Los tokenizadores de voz más recientes ya llegan a alrededor de 12 Hz por segundo. Usan muchos más tokens que un LLM normal.

• Este enfoque me recuerda a las primeras etapas de evolución del netcode en motores de juegos. La latencia no es un problema del modelo, sino de orquestación.
  El paper de VR de Carmack de 2013 decía lo mismo: hay que rastrear todo el pipeline para encontrar cuellos de botella de milisegundos.
  Vale la pena revisar Latency Mitigation Strategies. El caso de abrir por adelantado un pool de websockets para TTS y ahorrar 300 ms es un ejemplo perfecto.

• Quiero presentar la app de reconocimiento de voz open source Handy. Funciona completamente offline y se puede ampliar.
  Yo la uso todos los días junto con Claude, y funciona mucho mejor que el dictado predeterminado de macOS.

• Buen artículo, pero explicar la conversación solo con turn-taking es simplificar demasiado.
  En una conversación real también hay superposición de habla, señales de confirmación, mensajes fáticos para mantener la escucha, e incluso conductas cooperativas en las que se completa la frase del otro.
  Esos elementos no se representan bien con un modelo simple de turn-taking, y el modelo debería poder generarlos y entenderlos.