Más allá de la troncal SIP: cómo reducir la latencia de los agentes de voz a menos de 300 ms

Por el equipo de IdentityCall AI | Ingeniería | 8 min de lectura

El nuevo estándar de latencia

En 2024, la “prueba de Turing” de los agentes de voz no es solo cuestión de inteligencia: es cuestión de velocidad. El estándar anterior de 800 ms a 1 s de latencia (típico de las cadenas de LLM en la nube) ya no es aceptable en interacciones de alto riesgo con clientes. Los usuarios perciben los retrasos >500 ms como “robóticos” o “defectuosos”, lo que provoca solapamientos al hablar y frustración.

El nuevo estándar de oro es la alternancia de turnos en menos de 300 ms. Este artículo explora los cambios de arquitectura necesarios para lograrlo.

El cuello de botella: las cadenas tradicionales en la nube

La pila tradicional de IA de voz se ve así:

1. VAD (detección de actividad de voz) espera el silencio (200-500 ms).
2. Subida del audio a la nube (100 ms).
3. ASR (transcripción) procesa el enunciado completo (200-400 ms).
4. Inferencia del LLM genera el flujo de tokens (200-800 ms).
5. TTS (síntesis) genera audio a partir del texto (200-400 ms).
6. Descarga del audio y reproducción (100 ms).

Latencia total: 1.5 s - 2.5 s. Por eso tu bot de voz de primera generación se sentía lento.

La solución: arquitecturas de streaming y edge

1. Ejecución especulativa y ASR en streaming

No esperes al silencio. Las arquitecturas modernas usan ASR en streaming, que envía transcripciones parciales al LLM mientras el usuario todavía está hablando.

• Técnica: el LLM comienza a predecir la respuesta basándose en el primer 80% de la oración.
• Seguridad: una “puerta de compromiso” garantiza que el bot no hable hasta que la intención sea clara, pero los tokens ya están pregenerados.

2. IA en el edge y VAD local

Mover la detección de actividad de voz (VAD) al edge (o al nodo localizado del proveedor de telefonía) ahorra un tiempo de ida y vuelta crítico.

• Impacto: recorta 100-200 ms de jitter de red.
• Implementación: módulos VAD en WebAssembly (Wasm) que se ejecutan directamente en el navegador o en el edge de la telefonía.

3. Optimización del TTFT (tiempo hasta el primer token)

Para el propio LLM, optimizamos el tiempo hasta el primer token.

• Cuantización: usar modelos cuantizados a 4 bits (p. ej., Llama-3-8B-Int4) aumenta drásticamente la velocidad de inferencia con una pérdida de precisión insignificante en tareas conversacionales.
• Caché: el almacenamiento en caché semántico guarda las respuestas a saludos comunes (“Hola”, “¿Quién habla?”) para servirlas al instante (0 ms de inferencia).

Diagrama de arquitectura (Mermaid)

sequenceDiagram
    participant User
    participant Edge_VAD
    participant Cloud_LLM
    participant TTS_Engine
    
    User->>Edge_VAD: Speaks "I need to reset..."
    Edge_VAD->>Cloud_LLM: Stream: "I need to reset..."
    Cloud_LLM->>Cloud_LLM: Pre-fetch "Reset Password flow"
    User->>Edge_VAD: "...my password"
    Edge_VAD->>Cloud_LLM: Stream: "...my password" [EOS]
    Cloud_LLM->>TTS_Engine: Stream Tokens (Immediate)
    TTS_Engine->>User: Audio Stream (Sub-300ms)

Conclusión

Una latencia inferior a 300 ms convierte un “bot de voz” en un “agente de voz”. Al dejar atrás los ciclos rígidos de petición y respuesta en favor de arquitecturas fluidas de streaming, creamos experiencias que se sienten notablemente humanas.

¿Listo para construir agentes más rápidos? Explora nuestra documentación de la API para conocer los endpoints de streaming.