Ogni fornitore di voice AI pubblicizza un numero di latenza. Vapi dichiara ~500ms. Retell dichiara ~800ms. Synthflow rimanda a un blog Deepgram che parla di ~300ms di STT. Il punto: nessuno di questi numeri descrive ciò che sente davvero la persona dall'altra parte del telefono.
Abbiamo passato sei settimane a eseguire un banco di prova aperto su cinque piattaforme vocali in produzione — Retell, Vapi, Synthflow, Deepgram Voice Agent e Finn — su rotte US-East, EU-West e India. Questo articolo pubblica i valori P50/P90/P99, una metodologia che puoi rieseguire in autonomia e le parti della pipeline che i fornitori lasciano silenziosamente fuori dai loro grafici di marketing.
Perché la "latenza" è il numero sbagliato
Quando un fornitore promuove latency: 500ms, quasi sempre intende il TTFB: il tempo che intercorre tra la fine dell'intervento dell'utente e il primo byte audio emesso dal TTS. È un numero utile in fase di progettazione. Non è ciò che l'utente percepisce.
Ciò che l'utente percepisce è il ritardo nel cambio di turno: il silenzio tra il momento in cui lui smette di parlare e quello in cui sente parlare l'agente. Questo numero comprende:
- Ritardo di endpointing: quanto attende il VAD prima di decidere che hai finito (tipicamente 200–600ms di silenzio deliberato).
- Buffer di jitter di rete sulla tratta SIP/WebRTC (40–120ms).
- Dal primo byte TTS al TTS riproducibile: il primo chunk deve essere abbastanza grande da consentire una riproduzione resistente al jitter.
- Recupero dopo il barge-in, quando l'utente interrompe a metà risposta.
Una piattaforma che dichiara 500ms di TTFB ma usa 600ms di endpointing produce un ritardo percepito nel cambio di turno superiore a 1.2s. Un altro fornitore che pubblicizza 800ms ma con endpointing semantico aggressivo a 150ms risulta nettamente più rapido durante la chiamata. I numeri di marketing e i numeri percepiti dalle persone non stanno sullo stesso asse.
Regola pratica dalla ricerca sulla CX: sotto gli 800ms il cambio di turno percepito sembra una conversazione. Tra 800 e 1200ms sembra "IA, ma tollerabile". Oltre 1.2s, chi chiama inizia a parlare sopra l'agente.
Anatomia di una richiesta voice AI
Ecco la pipeline completa di un singolo turno, con il budget mediano che abbiamo misurato sulle cinque piattaforme nel 2026:
| Fase | Cosa succede | Mediana (ms) | P90 (ms) |
|---|---|---|---|
| Ingresso SIP/WebRTC | Il frame audio arriva al media server | 20 | 60 |
| VAD + endpointing | Rilevare la fine del parlato dell'utente | 280 | 520 |
| Finalizzazione STT | Forzare la chiusura della trascrizione parziale | 90 | 180 |
| TTFT dell'LLM | Primo token dal modello | 320 | 780 |
| Passaggio LLM → TTS | Confine di frase + avvio dello stream | 40 | 120 |
| Primo byte TTS | Emissione del primo chunk audio | 180 | 410 |
| TTS → riproducibile | Buffer sufficiente per partire in sicurezza | 60 | 140 |
| Buffer di jitter in uscita | Livellamento lato operatore | 50 | 110 |
| Totale percepito | Fine dell'intervento → primo audio udito | ~1040 | ~2320 |
Le due fasi su cui i fornitori competono più duramente — il TTFT dell'LLM e il primo byte TTS — pesano solo per il ~48% del budget mediano. Endpointing e accumulo di jitter dominano la coda.
La tabella di benchmark 2026: misurata, non pubblicizzata
Tutti i numeri qui sotto sono ritardo percepito nel cambio di turno, chiamante in US-East → regione predefinita del fornitore, registrati su 500 turni per piattaforma con uno script fisso di 8 turni per la fissazione di appuntamenti. Hardware: Mac mini M4, collegato alla PSTN tramite un numero Twilio Programmable Voice, registrazioni analizzate con il nostro script aperto (link nel repository più sotto). Metodologia completa nella sezione successiva.
| Piattaforma | Dichiarato | P50 misurato | P90 misurato | P99 misurato | Recupero dopo barge-in |
|---|---|---|---|---|---|
| Retell | ~800ms | 1180 | 1740 | 2680 | 410ms |
| Vapi (predefinito) | ~500ms | 1020 | 1620 | 2510 | 380ms |
| Vapi (STT/LLM personalizzati) | — | 880 | 1410 | 2240 | 360ms |
| Synthflow | ~600ms | 1240 | 1980 | 3120 | 520ms |
| Deepgram Voice Agent | ~300ms STT | 940 | 1480 | 2390 | 290ms |
| Finn | — | 820 | 1290 | 1980 | 240ms |
Le conclusioni che la maggior parte dei benchmark dei fornitori seppellisce:
- Il P90 di ogni piattaforma è all'incirca 1.5–2× il suo P50. Se guardi solo le medie, il peggior 10% delle tue chiamate sembra un prodotto diverso.
- Il P99 supera sempre i 2 secondi. È nella latenza di coda che gli utenti riattaccano.
- Il recupero dopo barge-in — quanto in fretta l'agente tace quando viene interrotto — varia di 2×. Questo singolo numero genera più lamentele per "chiamata andata male" del TTFB.
Come riprodurre questi numeri
Il banco di prova è volutamente noioso. Nessun generatore di carico proprietario, nessun SIP sintetico: un numero di telefono reale che chiama un agente reale, con un impianto di marcatura temporale in loopback sul microfono.
Domande frequenti
Che cosa significa davvero latenza sub-second?
Dipende da cosa si sta misurando. Tempo di inferenza del modello, tempo al primo audio e latenza bocca-orecchio sono tre numeri diversi, e solo l'ultimo è quello che chi chiama sperimenta.
A quale numero di latenza dovrei tenere un fornitore?
Al bocca-orecchio su una chiamata reale attraverso un operatore reale, misurato sulla coda anziché sulla media. Una buona media con un p95 pessimo significa che una chiamata su venti è inutilizzabile.
Perché la latenza è peggiorata in produzione rispetto ai test?
Di solito è il percorso di rete. Una demo su connessione locale salta la tratta dell'operatore e il salto di regione che invece le chiamate in produzione pagano.
