Todos los proveedores de voice AI anuncian una cifra de latencia. Vapi dice ~500ms. Retell dice ~800ms. Synthflow señala un blog de Deepgram que habla de ~300ms de STT. El problema: ninguna de esas cifras describe lo que realmente oye la persona que está al otro lado del teléfono.
Dedicamos seis semanas a ejecutar un banco de pruebas abierto contra cinco plataformas de voz en producción — Retell, Vapi, Synthflow, Deepgram Voice Agent y Finn — en rutas de US-East, EU-West e India. Este artículo publica las cifras P50/P90/P99, una metodología que puedes reproducir tú mismo y las partes del pipeline que los proveedores omiten discretamente en sus gráficos de marketing.
Por qué "latencia" es la cifra equivocada
Cuando un proveedor promociona latency: 500ms, casi siempre se refiere al TTFB: el tiempo desde que termina la intervención del usuario hasta el primer byte de audio que emite el TTS. Es una cifra útil desde el punto de vista técnico. No es lo que percibe el usuario.
Lo que el usuario percibe es el retardo en el turno de palabra: el silencio entre el momento en que él deja de hablar y el momento en que oye hablar al agente. Esa cifra incluye:
- Retardo de endpointing: cuánto espera el VAD antes de decidir que has terminado (normalmente entre 200 y 600ms de silencio deliberado).
- Buffer de jitter de red en el tramo SIP/WebRTC (40–120ms).
- Del primer byte del TTS al TTS reproducible: el primer fragmento tiene que ser lo bastante grande para una reproducción resistente al jitter.
- Recuperación tras barge-in cuando el usuario interrumpe la respuesta a media frase.
Una plataforma que publica 500ms de TTFB pero usa 600ms de endpointing produce un retardo percibido en el turno de palabra superior a 1.2s. Otro proveedor que anuncia 800ms pero con un endpointing semántico agresivo de 150ms se siente claramente más rápido en la llamada. Las cifras de marketing y las cifras percibidas por una persona no están en el mismo eje.
Regla práctica de la investigación en CX: por debajo de 800ms el turno de palabra percibido resulta conversacional. Entre 800 y 1200ms se siente "como IA, pero tolerable". Por encima de 1.2s, quien llama empieza a hablar por encima del agente.
Anatomía de una petición de voice AI
Este es el pipeline completo de un solo turno, con el presupuesto mediano que medimos en las cinco plataformas en 2026:
| Etapa | Qué ocurre | Mediana (ms) | P90 (ms) |
|---|---|---|---|
| Ingreso SIP/WebRTC | La trama de audio llega al servidor de medios | 20 | 60 |
| VAD + endpointing | Detectar el final del habla del usuario | 280 | 520 |
| Finalización del STT | Forzar el cierre de la transcripción parcial | 90 | 180 |
| TTFT del LLM | Primer token del modelo | 320 | 780 |
| Traspaso LLM → TTS | Límite de frase + inicio del streaming | 40 | 120 |
| Primer byte del TTS | Se emite el primer fragmento de audio | 180 | 410 |
| TTS → reproducible | Buffer suficiente para arrancar con seguridad | 60 | 140 |
| Buffer de jitter de salida | Suavizado en el lado del operador | 50 | 110 |
| Total percibido | Fin de la intervención → primer audio escuchado | ~1040 | ~2320 |
Las dos etapas en las que más compiten los proveedores — el TTFT del LLM y el primer byte del TTS — suponen solo un ~48% del presupuesto mediano. El endpointing y la acumulación de jitter dominan la cola.
La tabla comparativa de 2026: medida, no promocionada
Todas las cifras siguientes son el retardo percibido en el turno de palabra, con llamante en US-East → región por defecto del proveedor, registradas a lo largo de 500 turnos por plataforma con un guion fijo de 8 turnos para concertar una cita. Hardware: Mac mini M4, puenteado a PSTN mediante un número de Twilio Programmable Voice, grabaciones analizadas con nuestro script abierto (enlace en el repositorio más abajo). Metodología completa en la siguiente sección.
| Plataforma | Promocionado | P50 medido | P90 medido | P99 medido | Recuperación tras barge-in |
|---|---|---|---|---|---|
| Retell | ~800ms | 1180 | 1740 | 2680 | 410ms |
| Vapi (por defecto) | ~500ms | 1020 | 1620 | 2510 | 380ms |
| Vapi (STT/LLM personalizados) | — | 880 | 1410 | 2240 | 360ms |
| Synthflow | ~600ms | 1240 | 1980 | 3120 | 520ms |
| Deepgram Voice Agent | ~300ms STT | 940 | 1480 | 2390 | 290ms |
| Finn | — | 820 | 1290 | 1980 | 240ms |
Conclusiones que la mayoría de los benchmarks de proveedores entierran:
- El P90 de cada plataforma es aproximadamente 1.5–2× su P50. Si solo miras promedios, el peor 10% de tus llamadas parece un producto distinto.
- El P99 siempre supera los 2 segundos. La latencia de cola es donde los usuarios cuelgan.
- La recuperación tras barge-in —lo rápido que el agente se calla cuando lo interrumpen— varía en un factor de 2×. Esta única cifra genera más quejas de "mala llamada" que el TTFB.
Cómo reproducir estas cifras
El banco de pruebas es deliberadamente aburrido. Nada de generadores de carga propietarios ni de SIP sintético: un número de teléfono real que llama a un agente real, con un montaje de marcas de tiempo por bucle de micrófono.
Preguntas frecuentes
¿Qué significa realmente latencia sub-second?
Depende de qué se esté midiendo. El tiempo de inferencia del modelo, el tiempo hasta el primer audio y la latencia boca-oído son tres cifras distintas, y solo la última es la que experimenta quien llama.
¿A qué cifra de latencia debo exigir a un proveedor?
A la boca-oído en una llamada real sobre un operador real, medida en la cola y no en la media. Un buen promedio con un mal p95 significa que una de cada veinte llamadas es inservible.
¿Por qué empeoró la latencia en producción respecto a las pruebas?
Normalmente por la ruta de red. Una demo sobre una conexión local se salta el tramo del operador y el salto de región que sí pagan las llamadas en producción.
Relacionado: Voice.ai frente a voice AI: qué necesitas realmente
