Presupuestos de Latencia Sub-300ms en IA de Voz para Empresas
Matriz de especificaciones
Requerimientos técnicos esenciales
- ›Las pausas naturales en una conversación duran entre 250 y 320ms; cualquier retraso superior a 400ms provoca que el usuario repita su frase.
- ›El reconocimiento ASR en streaming debe emitir hipótesis en menos de 70ms usando arquitecturas Conformer aceleradas.
- ›Los modelos masivos (70B) no cumplen los tiempos exigidos; modelos optimizados de 7B-8B con decodificación especulativa logran un TTFT de 65ms.
- ›El ajuste de sockets UDP en Linux y la asignación fija de núcleos CPU son necesarios para evitar fluctuaciones de latencia.
1. Por qué la barrera de los 400ms es el límite infranqueable de la interacción humana
Las investigaciones psicoacústicas (Recomendación UIT-T G.114) confirman que las pausas inferiores a 300ms se perciben como naturales e inmediatas. Al superar los 450ms, el usuario duda si la llamada se ha cortado y dice "¿Hola?". Si el bot comienza a responder a los 700ms, se produce una colisión de voz que arruina la interacción. Mantener fluidez conversacional exige un presupuesto P95 inferior a 280ms.
2. Desglose del presupuesto de latencia milisegundo a milisegundo
Lograr una respuesta inferior a 280ms de extremo a extremo exige optimizar cada fase del proceso. Las arquitecturas convencionales en la nube acumulan demoras en cada nivel, mientras que Vext emplea punteros en memoria con copia cero.
| Fase del Proceso | Arquitectura Cloud Convencional | Pipeline Optimizado Vext Bare Metal | Ahorro Obtenido |
|---|---|---|---|
| Detección de voz/silencio (VAD) | 180 ms (Retardo de buffer cloud) | 38 ms (Silero VAD ajustado en borde) | -142 ms |
| Ingesta telefónica y decodificación | 65 ms (Transcodificaciones encadenadas) | 12 ms (SIMD nativo G.711) | -53 ms |
| Transcripción ASR en streaming | 240 ms (Espera de frase completa) | 68 ms (Conformer CTC continuo) | -172 ms |
| Tiempo al primer token (TTFT) | 320 ms (API cloud compartida) | 62 ms (Modelo 8B especulativo local) | -258 ms |
| Síntesis de voz TTS (primer frame) | 160 ms (Espera a frase terminada) | 48 ms (Streaming de fonemas directo) | -112 ms |
| Buffer de jitter y emisión RTP | 75 ms (Cola estática sobredimensionada) | 18 ms (Cola dinámica adaptativa) | -57 ms |
| Latencia total de extremo a extremo | 1.040 ms (Interacción frustrante) | 246 ms (Fluidez humana perfecta) | -794 ms (4,2x más rápido) |
3. Ajuste de sockets UDP en el kernel Linux y buffers de audio zero-copy
Procesar cientos de canales telefónicos concurrentes requiere ajustar la pila de red del kernel Linux. Por defecto, los valores UDP de Linux están pensados para servidores web estándar y provocan retrasos en tiempo real. Vext aplica afinidad de procesos (`taskset`), aísla los hilos de voz en núcleos dedicados y amplía los buffers de socket UDP para evitar pérdidas de tramas en picos de tráfico.
# Linux Production Real-Time Audio Sysctl Tuning (/etc/sysctl.d/99-voice-dsp.conf)
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.rmem_default = 33554432
net.core.wmem_default = 33554432
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
net.core.netdev_max_backlog = 100000
# Disable CPU frequency down-clocking for audio hot-loop cores
tuned-adm profile latency-performance4. Mecánica de interrupción (Barge-In) y cancelación de eco acústico (AEC)
El barge-in permite al interlocutor interrumpir al asistente en cualquier momento. Esto genera un problema crítico: la voz del bot sale por el altavoz del teléfono, se cuela por su micrófono y vuelve al reconocedor ASR. Sin cancelación de eco acústico (AEC) en tiempo real, el bot escucha su propia voz y se autointerrumpe. Vext aplica filtros de doble conversación que aíslan los fonemas del usuario frente al eco en menos de 35ms.
Preguntas frecuentes de la norma
¿Requiere asesoramiento sobre esta especificación?
Consulte directamente con nuestros ingenieros de sistemas en Casablanca.