Ridurre la latenza di un assistente vocale IA: la guida 2026

Il tuo agente vocale risponde in due secondi e la conversazione muore. L'utente aspetta, si annoia, comincia a parlare sopra l'assistente o alla fine scrive. La ricerca sui turni conversazionali fissa la pausa media tra umani intorno ai 200 ms, e qualunque gap oltre i 500 ms suona già poco naturale. Tutto oltre 1,5 s sembra un ritardo per cui bisogna scusarsi.

La buona notizia è che il budget di un agente vocale ben tarato nel 2026 scende comodamente sotto il secondo end-to-end, e ogni millisecondo in più è correggibile. La cattiva è che la maggior parte delle pipeline vocali self-hosted sperpera tra 800 e 1500 ms tra sintesi in batch, STT bloccante e uno step di ri-codifica di cui nessuno parla.

Questo post ripercorre dove finiscono davvero i secondi, quali ottimizzazioni spostano l'ago e come si presenta uno stack sotto 500 ms nel 2026. Se stai montando l'agente vocale da zero, parti dalla guida di setup vocale e torna qui per la passata di latenza.

Dove finiscono davvero i secondi

Un turno vocale ha quattro passi consecutivi, ognuno con il suo budget. Sbagli uno e scivola l'intero turno.

Fase	Target ben tarato 2026	Risultato self-hosted comune
Rilevamento attività vocale + cattura audio	~50 ms	100-200 ms
STT (trascrizione)	100-200 ms streaming	500-1500 ms in batch
LLM tempo al primo token	150-400 ms	700-2000 ms
TTS primo chunk audio	40-150 ms streaming	500-1200 ms in batch
Trasporto (WebRTC / upload Telegram)	20-80 ms	200-600 ms

I due salti veri sono streaming e scelta del provider. Una pipeline che chiude l'STT prima di avviare l'LLM, aspetta la risposta completa dell'LLM prima di avviare il TTS e ri-codifica l'audio prima dell'upload arriva facilmente a 3-4 s per turno. La stessa pipeline con bordi in streaming tra le fasi, un TTS a bassa latenza e il codec che il canale già accetta si avvicina ai 500-800 ms.

Lo streaming è il guadagno più grosso, di gran lunga

La sintesi in batch è il motivo più comune per cui un agente vocale self-hosted sembra lento. In una pipeline in batch l'LLM finisce l'intera risposta, consegna il testo completo al TTS, aspetta il rendering audio e solo dopo lo riproduce. Se la risposta è di 30 token, l'utente aspetta tutti e 30 prima di sentire una sillaba.

Lo streaming ribalta la cosa. L'LLM emette i token man mano che li genera, il TTS inizia a sintetizzare appena ha la prima frase e il primo chunk audio arriva sul canale mentre la coda della risposta si sta ancora scrivendo. Benchmark indipendenti del 2026 misurano questo passaggio come 300-600 ms di latenza percepita in meno, e fino a 400-800 ms in meno sulla latenza P95 per turno quando streami anche l'STT verso l'LLM.

Due regole pratiche:

Streama in ingresso e in uscita dall'LLM. Non bufferizzare la trascrizione intera prima di chiamare l'LLM, né la risposta intera prima di chiamare il TTS. Ogni SDK serio supporta lo streaming di token.
Scegli un TTS con primo chunk sotto i 150 ms. La modalità batch di ElevenLabs Multilingual v2 ha una voce splendida, ma un time-to-first-audio di 500-800 ms ammazza la conversazione in tempo reale.

Latenza TTS per provider, numeri onesti

I benchmark dei fornitori mentono perché confrontano la loro modalità veloce contro la modalità realistica di tutti gli altri. Coval, Gradium e Future AGI hanno pubblicato numeri indipendenti nel 2026, e il riassunto utile è corto:

Cartesia Sonic Turbo - circa 40 ms di time-to-first-audio, il TTS di produzione più veloce disponibile. Cartesia Sonic-3 si assesta intorno ai 90 ms con prosodia leggermente più ricca.
ElevenLabs Flash v2.5 - intorno ai 75 ms sul percorso real-time, con il compromesso di una fedeltà di clonazione più bassa di Multilingual v2 o v3.
Deepgram Aura-2 - circa 313 ms P50 nel benchmark Coval. Competitivo, non prima fila per la latenza pura.
OpenAI tts-1 - circa 200 ms di primo chunk, dietro ai provider real-time dedicati ma ok se vivi già dentro OpenAI.
Piper (self-hosted) - dominato dalla CPU. Su un VPS piccolo perde spesso contro i provider hosted realtime, anche senza il salto di rete.

La latenza pura non è più il differenziale in cima al mercato. Cartesia, ElevenLabs Flash, Rime e Deepgram pubblicano tutti sotto i 150 ms sul primo chunk, quindi l'asse utile è prosodia, clonazione e costo. Per un confronto più ampio del panorama TTS a pagamento leggi la guida ai provider TTS.

Tempo al primo token dell'LLM

Il budget dell'LLM in un ciclo vocale real-time è di 150-400 ms fino al primo token. Tre tecniche portano il valore da "a volte ci sta" a "sempre ci sta":

Prompt caching. Per ogni pipeline che rimanda lo stesso system prompt (quasi tutte), attivare il prompt caching abbassa il time-to-first-token di 200-400 ms senza altre modifiche a parte una flag.
Modelli piccoli e veloci. GPT-4o-mini, Claude Haiku 4.5 e i modelli Llama ospitati su Groq consegnano il primo token in modo consistente in 100-180 ms. Passa al modello grande quando quei 500 ms extra di ragionamento valgono, non di default.
Decodifica speculativa sulla tua inferenza. Se ospiti il modello, la decodifica speculativa può ridurre il TTFT del 30-50% a parità di qualità di output. È più lavoro che cambiare modello, ma il tetto è più alto.

La trappola del codec audio

Quasi ogni post sulla latenza vocale ignora lo step di ri-codifica, che è il motivo per cui i bot Telegram self-hosted sembrano sistematicamente più lenti di quanto i numeri suggeriscano. Telegram accetta note vocali in Opus in modo nativo. Se il tuo TTS restituisce MP3 o WAV, qualcosa nella tua pipeline deve ri-codificare in Opus prima che l'upload funzioni. Solo questo step costa 200-500 ms su un VPS piccolo, buttati.

La soluzione sta lato provider: chiedi output Opus direttamente al TTS. ElevenLabs lo supporta, Cartesia lo supporta, la maggior parte dei provider moderni lo fa. Su Whisper self-hosted la stessa trappola si presenta al contrario quando la nota vocale in arrivo è Opus e la decodifichi attraverso un percorso codec lento.

Se il tuo agente vocale sta perdendo audio del tutto invece di essere solo lento, è un problema diverso - la checklist di troubleshooting vocale copre le modalità di fallimento tipiche.

Uno stack sotto 500 ms nel 2026

Assemblato dai numeri sopra, la corsia veloce diventa così:

STT: Deepgram Nova-3 in streaming - 60-100 ms
LLM: GPT-4o-mini o Claude Haiku 4.5 con prompt caching - 100-180 ms primo token
TTS: Cartesia Sonic Turbo o ElevenLabs Flash v2.5 in Opus nativo - 40-80 ms primo chunk
Trasporto: WebRTC o upload diretto su Telegram - 20-40 ms

Aggiungi 50 ms per VAD e cattura, mantieni bordi in streaming tra tutte le fasi e la latenza percepita end-to-end scende sotto i 400 ms. Rientra nella finestra naturale dei turni umani.

Lo stack che la maggior parte delle persone fa girare davvero - Whisper hosted in batch, GPT-4o, ElevenLabs Multilingual v2 in batch, ri-codifica in Opus, upload - si assesta più vicino a 2,5-3 s. Due fasi su quattro sono sbagliate e l'audio fa un giro extra inutile.

Cosa ti toglie di torno un agente vocale gestito

Tutto quanto sopra è tarabile se ti piace tararlo. È anche la parte di uno stack vocale self-hosted che cambia ogni trimestre man mano che i provider rilasciano nuovi modelli. Se preferisci non rincorrere Cartesia Sonic 3 contro Sonic 4 in un file di config, il consiglio onesto è un agente gestito che tiene lo stack di latenza aggiornato al posto tuo.

Hermify gestisce un Hermes Agent su Telegram con STT in streaming, prompt caching attivo di default, una catena TTS a bassa latenza e output Opus nativo già cablati. La latenza percepita misurata su una nota vocale Telegram è tipicamente tra 500 e 800 ms end-to-end. Colleghi la tua chiave OpenRouter, scegli un piano e cominci a parlare, senza docker-compose, senza ffmpeg e senza debug dei codec.

Comincia con Hermify e metti il tuo agente vocale online in circa un minuto.