Voice AI a bassa latenza: il budget di latenza completo (2026)

Ogni blog di fornitori sulla "voice AI a bassa latenza" parla in realtà di un solo blocco della pipeline. Un nuovo modello vocale che ha ridotto di 80 ms la sintesi. Una modifica all'endpointing. Un trucco di caching. Ognuno è reale — e ognuno è inutile se le altre cinque fasi del percorso della chiamata consumano 1.200 ms mentre tu festeggi gli 80.

La latenza è un budget, non una funzionalità. Chi chiama sente un solo numero: il silenzio tra il momento in cui smette di parlare e quello in cui il tuo agente inizia. Quel numero è la somma di ogni fase dal microfono all'altoparlante, più la rete che non controlli. Questo è il modello end-to-end — quanto costa ogni fase, dove si nascondono davvero i millisecondi e dove streaming, endpointing e caching ti fanno guadagnare tempo davvero, rispetto a dove si limitano a spostare il problema.

Perché la latenza è la linea di confine tra "AI" e "una conversazione vera"

L'alternanza dei turni tra esseri umani ha un ritmo. Nella conversazione naturale, l'intervallo tra un parlante e l'altro è in media di circa 200 ms, e le persone iniziano a pianificare la risposta prima che l'altra abbia finito. Quando un agente telefonico lascia 1,5 secondi di silenzio dopo ogni frase, chi chiama non pensa "che AI impressionante". Pensa che la linea sia caduta, parla sopra l'agente, oppure riattacca.

Le soglie pratiche su cui progettiamo:

• Un tempo di risposta inferiore a ~500 ms risulta conversazionale. Chi chiama nota a malapena la pausa.
• 500-800 ms è accettabile ma udibilmente "da assistente". Va bene per molti casi d'uso.
• Oltre ~1.000 ms il ritmo si rompe. Chi chiama interrompe, si ripete e la fiducia si erode.

Quell'obiettivo sotto il secondo è tutta la partita. E non è compito di un singolo componente — è il budget che distribuisci sull'intero stack.

Il budget di latenza: ogni fase dal microfono all'altoparlante

Ecco il percorso completo di andata e ritorno per un singolo turno di conversazione. Intervalli approssimativi in produzione per un agente ben costruito su una chiamata telefonica:

Sommale e ti collochi tra circa 700 ms e 2,4 s. La forbice è enorme — e nota cosa la domina: l'endpointing e il TTFT dell'LLM, non i modelli STT o TTS che tutti sottopongono a benchmark.

Da questa tabella derivano immediatamente due regole:

1. Ottimizza prima il blocco più grande. Sostituire un TTS da 120ms con uno da 90ms è irrilevante se il tuo endpointer aspetta 700ms. Misura prima di ottimizzare.
2. Le fasi si sovrappongono quando usi lo streaming. Il budget qui sopra è il caso peggiore seriale. Lo streaming consente a STT, LLM e TTS di funzionare in parallelo anziché uno dopo l'altro — ed è da qui che arrivano la maggior parte dei guadagni reali (vedi sotto).

Endpointing e rilevamento del silenzio: i 500ms più sottovalutati

L'endpointing è la decisione: il chiamante ha finito il suo turno, o si è solo fermato a prendere fiato? È la singola porzione di latenza controllabile più grande, e il compromesso più difficile dell'intero stack.

Approccio ingenuo: aspettare N millisecondi di silenzio, poi partire. Se imposti N troppo basso (diciamo 200ms) interrompi le persone a metà frase — brutale quando qualcuno legge un numero di carta a 16 cifre o dice "il mio indirizzo è... Via Rovereto 42". Se imposti N troppo alto (900ms), ogni turno risulta lento.

Ciò che funziona davvero in produzione è un endpointing adattivo e semantico anziché un timer di silenzio fisso:

• Il VAD (voice activity detection) ti fornisce il segnale grezzo "c'è energia audio" — veloce, ma cieco rispetto all'intento.
• L'endpointing semantico usa la trascrizione parziale per valutare la completezza. "Il mio numero di conto è" è chiaramente incompleto; "Voglio disdire il mio account" è un pensiero completo. Un modello che legge il testo parziale può partire prima sugli enunciati completi e aspettare più a lungo a metà di un numero.
• Timeout sensibili al contesto. Quando hai appena chiesto un numero di telefono, allarga la finestra di silenzio e non trattare le pause tra una cifra e l'altra come fine turno. Lega la soglia di endpointing allo slot che stai raccogliendo.

Se lo fai bene, recuperi 300–500ms sulla maggior parte dei turni senza mai interrompere un chiamante. Se lo fai male, nessun cambio di modello ti salverà.

Streaming ovunque: la latenza gratuita che stai lasciando sul tavolo

La più grande bugia nella tabella del budget seriale è che le fasi avvengano una dopo l'altra. Non dovrebbero. Usa lo streaming a ogni confine e la pipeline si comprime:

• Trascrizioni parziali. Non aspettare il risultato finale dello STT. Passa le trascrizioni parziali al tuo endpointer e pre-riscalda persino il contesto dell'LLM, così non parti da freddo quando il chiamante si ferma.
• Streaming dei token dall'LLM. Ciò che conta è il tempo al primo token, non il tempo al completamento totale. Non appena la prima proposizione esce in streaming, passala al TTS. Non ti serve l'intera risposta per iniziare a parlare.
• Chunking del TTS. Sintetizza e inizia a riprodurre la prima frase mentre l'LLM sta ancora generando la terza. Il numero che conta è l'audio al primo byte, non l'audio a clip completa.

Fatto bene, il chiamante sente le prime parole della risposta mentre l'LLM sta ancora scrivendo il resto. È così che uno stack il cui budget seriale somma a 1,8s produce una risposta percepita di 600ms. Lo streaming non è un'ottimizzazione che aggiungi dopo — è l'architettura da cui parti.

Un avvertimento: fare streaming del TTS a metà generazione significa impegnarsi su parole prima che esista la risposta completa. Se il tuo LLM potrebbe correggersi da solo ("in realtà, fammi controllare — no, hai ragione"), avrai già pronunciato la metà sbagliata. Vincola il modello a risposte da dire una volta sola, oppure metti in buffer la prima proposizione finché la struttura della frase non è stabile.

Caching audio e pre-riscaldamento: guadagni reali, trappole reali

Il caching è l'argomento dei post in stile Vapi "l'abbiamo reso più veloce", ed è genuinamente utile — con qualche spigolo.

Cosa si può mettere in cache o pre-riscaldare senza rischi:

• Prompt fissi e testi standard. Saluti, messaggi di attesa, informative, "resti in linea mentre verifico". Pre-sintetizzali una volta. Zero latenza TTS a runtime.
• Riscaldamento delle connessioni. Mantieni aperti i socket STT/LLM/TTS e i modelli caldi, così il primo turno di una chiamata non paga il costo dell'avvio a freddo. Solo questo può far risparmiare centinaia di millisecondi al primo turno.
• Riempitivi prevedibili. Un breve e naturale "controllo subito per lei" riprodotto mentre gira una chiamata a uno strumento lenta maschera la latenza di backend che il chiamante altrimenti sentirebbe come silenzio.

Cosa si rompe se lo metti in cache:

• Qualsiasi cosa con dati dinamici. Metti in cache "Il suo saldo è [X]" come template e prima o poi leggerai il saldo sbagliato al chiamante sbagliato. Metti in cache la frase portante, sintetizza dal vivo lo slot variabile.
• Audio personalizzato o sensibile dal punto di vista della compliance. Nomi, dettagli del conto, prezzi quotati — sintetizza da capo, ogni volta.
• Versioni obsolete di voce/modello. Una clip in cache di una vecchia voce TTS accanto a una dal vivo è stridentemente evidente a metà frase. Versiona le chiavi di cache in base al modello di voce.

Il caching rende di più sulle parti prevedibili di una chiamata. Non fa nulla per il turno di ragionamento dinamico — ed è esattamente per questo che non può essere tutta la tua strategia sulla latenza.

Telefonia e realtà della rete: l'ultimo miglio che non possiedi

Puoi mettere a punto ogni modello alla perfezione e comunque rilasciare un agente lento, perché una telefonata viaggia su un'infrastruttura che non controlli.

• PSTN e SIP aggiungono tempo reale. La rete telefonica pubblica commutata e il SIP trunking introducono ritardo di trasporto prima ancora che il tuo STT riceva l'audio. La transcodifica del codec (ad esempio da/verso G.711) ne aggiunge un altro po'.
• Jitter e perdita di pacchetti. Chi chiama da rete mobile, con Wi-Fi scadente o attraverso operatori congestionati consegna l'audio in modo irregolare. Il tuo jitter buffer rende la riproduzione più fluida, ma per farlo aggiunge latenza: un altro compromesso da regolare, non da eliminare.
• Geografia. Se la tua inferenza gira in us-east mentre chi chiama e il tuo provider di telefonia sono in Europa, hai aggiunto un viaggio di andata e ritorno transatlantico a ogni turno. Colloca il percorso media vicino a chi ti chiama e agli endpoint dei tuoi modelli.
• Il percorso media conta quanto il modello. Il bridging WebRTC-SIP, il routing SBC e la posizione del tuo media server possono costare o far risparmiare più di un cambio di modello. Questa è ingegneria dell'infrastruttura, non prompt engineering.

La conclusione: metti in conto 100–300 ms di rete e telefonia che non puoi ottimizzare, e assicurati che i millisecondi che puoi controllare non vengano sprecati su un percorso media che rimbalza attraverso tre regioni.

Misurare la latenza dei turni di conversazione in produzione (il numero che conta)

Non puoi ottimizzare ciò che non misuri, e la metrica che conta non è il benchmark di un singolo componente. È il tempo che intercorre dalla fine del parlato dell'utente all'inizio dell'audio dell'agente, misurato in produzione, su chiamate reali, al percentile che fa male.

• Strumenta l'intero ciclo. Metti un timestamp su: ultimo frame audio del chiamante → rilevamento della fine del turno → primo token dell'LLM → primo byte del TTS → primo frame audio in uscita. Registra ogni fase di ogni turno, così puoi vedere quale blocco ha sforato il budget quando una chiamata è sembrata lenta.
• Guarda il p95, non la media. La tua latenza media può essere un ottimo valore di 550 ms mentre il p95 è di 1,8 s: e sono i turni al p95 che fanno riattaccare chi chiama. Le medie nascondono le chiamate che stai perdendo.
• Monitora il tasso di barge-in / interruzioni. Se chi chiama parla spesso sopra il tuo agente, il tuo endpointer scatta in ritardo o la tua risposta parte lenta. È un sintomo di latenza travestito da metrica di UX.

Rilascia la strumentazione prima di ottimizzare. Ogni affermazione del tipo "abbiamo ridotto la latenza" che non sia supportata da una misurazione del p95 in produzione è un'ipotesi.

Link interni

• Come abbiamo costruito la pipeline di Voice AI — scelte STT: Whisper vs Deepgram
• Risolvere la latenza SIP nelle soluzioni AI per call center
• Collegare WebRTC e SIP: passaggi di chiamata a bassa latenza per agenti vocali AI
• AI Voice Agent per le aziende: architettura e ROI
• Come gestire volumi elevati di chiamate senza assumere altri agenti (2026)

FAQ

Qual è un buon obiettivo di latenza per un agente vocale AI in produzione? Punta a meno di 800 ms end-to-end (dalla fine del parlato del chiamante all'inizio dell'audio dell'agente) e considera i valori sotto i 500 ms come l'obiettivo per una sensazione davvero conversazionale. Misura al p95, non sulla media: è la coda lenta a far riattaccare le persone.

Quale parte della pipeline di voice AI causa più latenza? Di solito l'endpointing e il time-to-first-token dell'LLM, non i modelli STT o TTS su cui si concentrano la maggior parte dei benchmark. L'endpointing da solo può aggiungere 200–800 ms, quindi è il primo punto da esaminare prima di sostituire qualsiasi modello.

Il caching dell'audio riduce la latenza della voice AI? Sì, per i contenuti fissi: saluti, informative, messaggi di attesa e frasi di riempimento possono essere pre-sintetizzati per una latenza di runtime quasi nulla. Non serve a nulla per i turni con ragionamento dinamico, e mettere in cache qualsiasi cosa con dati personalizzati o variabili rischia di comunicare informazioni sbagliate a chi chiama.

Perché il mio agente vocale sembra lento anche con un modello veloce? Perché la latenza è la somma dell'intera pipeline più la telefonia che non controlli. Un TTS veloce non aiuta se il tuo endpointer aspetta 700 ms, il tuo LLM produce token lentamente o il tuo percorso media rimbalza tra più regioni. Strumenta ogni fase e correggi prima il blocco più grande.

Finn è costruito con la latenza come priorità: STT in streaming, endpointing semantico e passaggio da token a TTS ottimizzati per ottenere turni di conversazione sotto il secondo su chiamate telefoniche reali, non su clip da benchmark. Scopri come gli agenti vocali di Finn gestiscono i volumi di chiamate in produzione senza tempi morti.