Calcolatore di latenza per il voice AI

Come viene calcolato

Il divario percepito è la somma di ogni fase tra la fine del parlato e il primo audio: il silenzio che si attende prima di stabilire che il chiamante ha finito, la finalizzazione della trascrizione, il primo token del modello, il primo byte della voce, due passaggi di rete e il percorso telefonico.

perceived gap = endpointing silence      ← your setting
              + STT finalisation
              + LLM time to first token
              + TTS time to first byte
              + network RTT × 2           ← your region choice
              + telephony / jitter buffer

Perché di solito non è colpa del modello

In una configurazione tipica la soglia di silenzio per l'endpointing è la voce più consistente: circa 600ms su un budget di circa 1.500ms, ovvero il 40% di tutto ciò che il chiamante aspetta. Non è un limite del fornitore. È un numero nella tua configurazione che decide per quanto tempo il sistema ascolta il silenzio prima di concludere che il chiamante ha finito, e i team passano regolarmente settimane a fare benchmark dei modelli mentre quel valore resta su un default che nessuno ha scelto.

Ridurla è il guadagno più economico a disposizione, ed è un vero compromesso, non un regalo: taglia troppo e interrompi chiunque faccia una pausa a metà frase. La scelta della region è l'altra leva nelle tue mani: il round trip di rete viene contato due volte, quindi un deployment cross-region può aggiungere 400ms prima che un fornitore abbia sbagliato qualcosa.

Come si presenta un buon risultato

Le pause naturali nel turn-taking umano si aggirano sui 200ms. Sotto i 500ms un agente sembra immediato; sotto gli 800ms viene letto come una pausa normale. Oltre circa 1,2 secondi i chiamanti iniziano a ripetersi o a parlare sopra l'agente, perché il silenzio viene letto come linea caduta e non come riflessione. Un modello di reasoning a 1,4 secondi al primo token consuma da solo l'intero budget: ecco perché quei modelli vanno dopo la chiamata, a riassumere e decidere, non nel turno in tempo reale.

I valori per fase riportati qui sono intervalli tipici, pubblicati o osservati, non garanzie. La latenza reale varia con region, carico, payload e condizioni di rete: misura la tua e usa questo come budget su cui progettare.

Last reviewed July 2026.

Domande frequenti

Qual è una buona latenza per un agente vocale AI?

Sotto gli 800ms risulta confortevole e sotto i 500ms risulta immediato: le pause naturali nell'alternanza dei turni tra persone si aggirano sui 200ms. Oltre circa 1,2 secondi i chiamanti iniziano a ripetersi o a parlare sopra l'agente, perché il silenzio viene letto come una linea caduta anziché come una riflessione.

Perché il mio agente vocale è lento se ogni fornitore dichiara bassa latenza?

Perché i numeri dei fornitori sono solo una parte del budget. In una configurazione tipica la soglia di silenzio dell'endpointing — il tempo che si attende per essere certi che il chiamante abbia smesso di parlare — è il singolo contributo maggiore, spesso il 12% del totale. È un'impostazione che dipende da te, non un limite del fornitore, e nessuna ricerca di un modello diverso la risolverà.

Come riduco la latenza di un agente vocale?

In ordine di resa: accorciare la soglia di endpointing, fare il deploy nella stessa region dei tuoi provider, accorciare il system prompt, trasmettere il testo in streaming alla sintesi vocale anziché attendere una risposta completa e solo a quel punto valutare un modello più veloce. I primi due sono gratuiti e di solito valgono più di tutti gli altri messi insieme.

Che cos'è l'endpointing?

Stabilire quando il chiamante ha finito di parlare. Attendi troppo e ogni risposta sembra lenta; tagli troppo presto e interrompi chi si ferma a metà frase. È un compromesso reale, non un bug — ma è un compromesso che la maggior parte dei team non fa mai consapevolmente, lasciando un valore di default e dando la colpa al modello.

Ha senso un reasoning model per il vocale?

Raramente sul percorso critico. Un modello che impiega 1,4 secondi per il primo token brucia da solo l'intero budget. I reasoning model si prestano meglio dopo la chiamata — per riassumere, estrarre, decidere le azioni successive — mentre il turno live gira su qualcosa costruito per il time to first token.

Letture correlate