Arquitectura de agentes de voz: STT, LLM, TTS y el presupuesto de latencia

Si alguna vez esperaste 3 segundos por la respuesta de un agente de voz, ya conoces al asesino del producto. No es la respuesta equivocada. Es la pausa larga antes de la respuesta. La conversación se siente rota cuando la latencia supera los 500ms y se siente humana cuando se mantiene cerca de los 200ms. Todo el desafío de ingeniería de un agente de voz se reduce a una pregunta: cómo mantener el ida y vuelta por debajo de un segundo mientras se ejecutan reconocimiento de voz, un LLM y síntesis de voz en serie. Este post recorre el pipeline, el presupuesto de 800ms que los equipos de producción apuntan en 2026 y los compromisos de arquitectura que deciden si tu agente envía o queda como demo.

El pipeline del agente de voz

Todo agente de voz que se precie tiene el mismo esqueleto: voz entra, voz sale, con tres etapas en el medio. El reconocimiento de voz (STT, también llamado ASR) convierte audio en texto. Un large language model (LLM) lee el texto y produce una respuesta. La síntesis de voz (TTS) convierte la respuesta en audio. Envuelve todo en una capa de transporte (WebRTC para navegador, SIP para telefonía) y tienes un agente.

Lo engañoso de ese diagrama es que parece simple. La realidad es que cada etapa tiene su propia latencia, tasa de error y techo de calidad, y los fallos se acumulan. Errores de STT confunden al LLM. La indecisión del LLM detiene al TTS. La calidad del TTS define si el usuario cree en la voz o cuelga.

El presupuesto de 800ms

Los equipos de producción en 2026 apuntan a un tiempo total de alrededor de 800ms desde que el usuario termina de hablar hasta que el agente comienza a hablar. Una asignación típica:

• Detección de actividad de voz y captura de audio: 50ms
• Transcripción STT (streaming): 150ms
• Time-to-first-token (TTFT) del LLM: 400ms
• Primer chunk de audio del TTS: 150ms
• Sobrecarga de red: 50ms

El LLM se queda con la mayor porción porque es el más difícil de comprimir sin sacrificar calidad. STT y TTS se pueden optimizar agresivamente porque son problemas mayormente de ingeniería. El LLM está acotado por el tamaño del modelo y la longitud del prompt.

Investigaciones de mercado de AssemblyAI y Hamming sitúan la mediana real de latencia de agentes de voz entre 1,4 y 1,7 segundos, con el 10% de las llamadas pasando los 3 segundos. Eso es unas 5x más lento que la expectativa humana de 200ms. Quienes envían productos que se sienten naturales corren a la mitad de la mediana del mercado.

Por qué TTFT importa más que el tiempo total del LLM

Hay dos números de latencia que vale la pena seguir en el LLM. Tiempo total de generación es cuánto tardó el modelo en producir la respuesta completa. Time-to-first-token (TTFT) es el tiempo hasta que vuelve el primer token. Para voz, TTFT es lo que importa. La razón: el TTS puede comenzar a hacer streaming de audio en cuanto la primera oración está lista, así que el usuario empieza a escuchar al agente antes de que el LLM termine de pensar. Si el TTFT es de 800ms, el usuario siente 800ms de silencio sin importar lo rápido que sea el TTS.

La misma lógica vale para STT. Un STT en streaming emite transcripciones parciales mientras el usuario habla, así que el LLM puede empezar a razonar antes de que el usuario termine. Un STT por turnos que espera el fin del habla agrega ese silencio entero al presupuesto.

Streaming versus pipeline por turnos

La elección de arquitectura que más afecta la latencia de un agente de voz es streaming versus por turnos. En un pipeline por turnos, cada componente espera a que el anterior termine antes de procesar. En streaming, los componentes producen salida parcial continuamente y los siguientes la consumen a medida que llega.

Streaming es la única forma de bajar a 800ms. El STT emite chunks mientras el usuario habla, el LLM empieza a generar en cuanto tiene una cláusula con la que trabajar y el TTS arranca la síntesis antes de que el LLM termine. El usuario percibe al agente pensando y hablando en paralelo, no en secuencia.

Los pipelines por turnos son más simples de construir y depurar, por eso la mayoría de los prototipos arrancan así. También son la razón por la que la mayoría de los prototipos nunca se vuelven productos.

Speech-to-speech versus cascada: cuándo gana cada uno

Una opción nueva desde fines de 2024 son los modelos speech-to-speech como GPT-4o realtime API o NVIDIA Nemotron. Colapsan STT, LLM y TTS en un solo modelo que recibe audio y produce audio. La ganancia es latencia, frecuentemente bien por debajo de los 800ms. El costo es pérdida de flexibilidad: function calling, RAG y elección de modelos se vuelven más difíciles.

Muchas implementaciones en 2026 son híbridas: speech-to-speech para small talk y aperturas con carga emocional, con cascada de respaldo (STT, LLM, TTS separados) cuando hace falta una llamada de herramienta o RAG. Cascada da más flexibilidad y mejor uso de herramientas. Speech-to-speech da la apertura más ágil.

La respuesta correcta depende del caso de uso. Un agente de reserva que siempre tiene que llamar a la API de calendario se queda en cascada. Una recepcionista amable que maneja mucho small talk se beneficia de speech-to-speech.

Dónde encaja SipPulse AI

SipPulse AI es nuestra plataforma de agentes de voz. El transporte WebRTC y la telefonía SIP son ciudadanos de primera clase por defecto, la cascada por defecto usa Pulse Precision Pro como STT y Pulse TTS para síntesis, y NIVA está encima combinando flujos de IVR y múltiples agentes en un constructor visual por bloques. NIVA es la capa que hace que un agente real de producción sea fácil de armar, fácil de prototipar contra tus datos y fácil de evolucionar una vez en operación.

Vendemos el stack completo: plataforma de agentes, constructor de IVR, STT, TTS y telemetría por llamada entregada vía webhooks a tus sistemas. La prueba es pública: abre nuestra demo, ten una conversación real con el agente y luego revisa nuestro visor de telemetría de ejemplo, una página abierta que consume los mismos eventos de webhook que tu deployment recibiría. Las llamadas reales de la demo rondan los 800ms de ida y vuelta total, desglosado en llm_ttft_ms, tts_latency_ms, eou_latency_ms y conv_latency_ms. La mayoría de los equipos en este espacio esconden su latencia real. Nosotros te dejamos medir la nuestra en el mismo workload que de hecho usarías.

Lee también

• Construyendo agentes de voz sobre WebRTC: el stack de producción
• Turn detection, barge-in y manejo de interrupciones en agentes de voz
• Evaluando agentes de voz en producción: WER, MOS, latencia

Conclusión

Un agente de voz vive o muere por su presupuesto de latencia. Los 800ms son alcanzables con un pipeline en cascada, streaming y optimización agresiva en cada capa. Los modelos speech-to-speech abren nuevas opciones, pero no reemplazan la necesidad de herramientas y RAG. Si quieres construir algo con lo que los usuarios disfruten hablar de verdad, empieza por el presupuesto de latencia y trabaja hacia atrás. Prueba nuestra demo en vivo para sentir la diferencia o habla con el equipo sobre desplegar SipPulse AI en tu propio workload.