Ottimizzazione della latenza degli agenti vocali: guida passo passo

La reattività di un agente vocale dipende dal ritardo totale tra il momento in cui l’utente finisce di parlare e quello in cui l’agente inizia a rispondere. Questo ritardo raramente è causato da un solo componente lento. Si accumula in diverse fasi indipendenti, ognuna delle quali aggiunge decine o centinaia di millisecondi, e per ridurlo bisogna sapere quanto tempo impiega ciascuna fase.

Ottimizzare la latenza di un agente vocale significa individuare dove si nasconde il tempo perso e recuperarlo fase dopo fase.

Questo articolo è un approfondimento della panoramica concettuale sulla latenza. Se quella pagina spiega cos’è la latenza, qui si parla di architettura e misurazione, così potrai definire un budget di latenza misurabile e una serie di azioni concrete da mettere in pratica.

In breve

• Il time-to-first-audio rappresenta l’intera pipeline, non solo il tempo di inferenza di un singolo modello.
• Il time-to-first-token dell’LLM e l’endpointing sono le due voci di latenza più rilevanti.
• Sovrapporre le fasi, invece di eseguirle in serie, permette di recuperare gran parte del budget.
• Streaming, scelta del codec e regolazione del buffer del player riducono ciascuno diversi millisecondi misurabili.
• Dovresti misurare per regione sulla tua implementazione, riportando P50 e P95.

Definire il budget di latenza di un agente vocale

Un budget di latenza è il tempo totale target per il time-to-first-audio, suddiviso tra le varie fasi della pipeline, dove a ciascuna fase viene assegnata una quota che deve rientrare nell’obiettivo complessivo. Definirlo è il primo passo ed è anche dove spesso si commettono errori, perché gli ingegneri possono confondere due numeri che sembrano simili ma hanno significati diversi.

Il primo è la latenza di inferenza del modello: il tempo che un modello impiega a generare l’output. Per i nostri modelli Flash è circa 75ms per input brevi, esclusi i tempi di rete e overhead applicativo. È un dato interno, utile per confrontare diversi modelli tra loro. Non è il numero che sperimenta l’utente.

Dal punto di vista dell’utente, l’attenzione va sul time-to-first-audio (TTFA): il tempo che passa da quando l’utente smette di parlare a quando sente il primo campione della risposta dell’agente. Il TTFA è sempre superiore alla latenza di inferenza di qualsiasi singolo modello, perché somma l’intera pipeline.

Un agente vocale a cascata è una catena di cinque fasi:

• acquisizione (microfono) -> STT -> LLM -> TTS -> riproduzione

L’audio viene acquisito dal microfono, trascritto in testo, inviato a un modello linguistico, il testo generato viene sintetizzato in parlato e quel parlato viene bufferizzato e riprodotto. Ogni fase aggiunge latenza e, in alcune fasi, il costo maggiore non è quello che ci si aspetterebbe.

Ecco un esempio pratico per un agente in inglese con server abbastanza vicini all’utente. I numeri sono intervalli indicativi, non garanzie.

Di solito, le due voci di latenza più rilevanti sono il time-to-first-token dell’LLM e il ritardo di endpointing all’inizio della catena.

La tabella è utile per visualizzare la pipeline, ma suggerisce che le fasi vengano eseguite rigorosamente in serie, cosa che in realtà non avviene. Molte delle ottimizzazioni più efficaci sulla latenza degli agenti vocali derivano dalla loro sovrapposizione, ed è proprio lì che si recupera la maggior parte del budget.

Speech to Text: ottimizzazione della latenza di trascrizione ed endpointing

La trascrizione è la seconda fase della pipeline, e il suo vero costo non è la trascrizione in sé, ma la decisione su quando l’utente ha finito di parlare. Questa sezione copre entrambi gli aspetti per aiutarti a ottimizzare la latenza dell’agente vocale.

La trascrizione avviene prima che il testo arrivi all’LLM.Scribe v2 in tempo reale (scribe_v2_realtime) restituisce trascrizioni parziali in circa 150ms e trasmette l’audio a blocchi, così la trascrizione si materializza mentre l’utente sta ancora parlando. Supporta PCM da 8kHz a 48kHz e codifica mu-law, che sarà importante nella sezione codec qui sotto. I parziali da 150ms sono poco costosi.

Il costo di latenza maggiore è l’endpointing: il momento in cui il sistema decide che l’utente ha davvero finito il suo turno.

La Voice Activity Detection (VAD) segmenta il parlato in base alle pause di silenzio, ed è lì che si accumula il tempo. Se aspetti, ad esempio, 700ms di silenzio prima di dichiarare finito il turno, aggiungi 700ms a ogni turno, oltre al tempo di trascrizione. Questo ritardo è invisibile nei benchmark di accuratezza della trascrizione, ma molto presente in una conversazione reale. Spesso è la latenza controllabile più grande dell’intera pipeline e, proprio perché è controllabile, è un ottimo punto di partenza.

L’endpointing è un compromesso tra reattività e interruzione. Una soglia di silenzio breve fa rispondere l’agente più rapidamente, ma rischia di interrompere l’utente su una pausa naturale. Una soglia lunga è più sicura ma rende la risposta lenta. In pratica, i tre cambiamenti che ottimizzano la latenza nello speech to text sono:

1. Regola la soglia di silenzio:Riduci la soglia di silenzio al valore minimo che non tronca le pause naturali degli utenti, poi misura il tasso di interruzione in produzione invece di fare ipotesi.
2. Integra un controllo fisico: Usa un controllo manuale quando la tua applicazione sa che il turno è finito grazie a un altro segnale (rilascio del push-to-talk, evento UI), invece di aspettare il timer VAD.
3. Sovrapponi con i processi LLM:Invia i parziali stabili all’LLM in anticipo. In questo modo, puoi correggere se la trascrizione finale è diversa: è una forma di esecuzione speculativa che nasconde il ritardo di endpointing dietro l’elaborazione del prompt dell’LLM.

Per maggiori dettagli, Scribe v2 Realtime è descritto più approfonditamente nella pagina funzionalità speech to text e nella pagina prodotto trascrizione vocale in tempo reale.

Il contributo dell’LLM alla latenza

Il modello linguistico è di solito il singolo elemento che incide di più sul TTFA, quindi è anche dove la sovrapposizione delle fasi dà i maggiori risultati nell’ottimizzazione della latenza degli agenti vocali. L’aspetto chiave è che l’agente non ha bisogno dell’intera risposta prima di iniziare a parlare.

Il modo più efficace per recuperare budget di latenza è trasmettere i token dall’LLM e inviarli al TTS man mano che arrivano, suddivisi per frase o proposizione. La logica è bufferizzare i token fino al termine di una frase, poi sintetizzare quella frase mentre la successiva viene ancora generata:

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

Per conversazioni lunghe, scegli il TTS WebSocket così una connessione aperta può ricevere testo in modo incrementale senza dover ristabilire la connessione a ogni frase. Conta solo il tempo in cui il modello sta effettivamente generando audio rispetto al tuo limite di concorrenza, quindi un WebSocket aperto ma inattivo è praticamente gratuito.

Text to Speech: streaming e scelta della voce

La sintesi vocale è la fase in cui puoi controllare la latenza con maggiore precisione. Hai due leve principali: come trasmetti l’audio e quale voce scegli.

Flash v2.5 (eleven_flash_v2_5) è il modello consigliato per un agente. Offre circa 75ms di inferenza per input brevi, supporta 32 lingue e accetta fino a 40.000 caratteri per richiesta.

Il dato dei 75ms riguarda solo l’inferenza. La voce TTFA del TTS nel budget sopra è più alta perché include anche il round-trip di rete e la pianificazione del server.

La leva più importante qui è lo streaming. Se richiedi l’audio completo e aspetti, l’utente deve attendere che l’intero clip venga sintetizzato prima di sentire qualcosa. Se invece usi lo streaming, l’utente sente il primo blocco appena viene generato, e il resto arriva mentre sta già ascoltando. Lo streaming non rende il modello più veloce; semplicemente inizia a inviare l’output all’utente mentre è ancora in generazione.

La guida pratica allo streaming spiega lo streaming HTTP, mentre la guida WebSocket in tempo reale descrive il percorso WebSocket che ti serve quando invii token da un LLM.

Inizializza il client una volta e riutilizzalo per ogni chiamata successiva:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

Poi imposta uno stream e inoltralo man mano che arriva:

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

L’altra leva è la scelta della voce, che incide anch’essa sulla latenza. Le voci predefinite, le voci sintetiche e le Instant Voice Clones (IVC) vengono sintetizzate più velocemente delle Professional Voice Clones (PVC), perché le PVC hanno una complessità di modello maggiore che aggiunge overhead a ogni generazione. Per un agente con requisiti di latenza stringenti, la combinazione di Flash e una IVC o una voce predefinita è l’opzione a latenza più bassa.

Scelta della dimensione dei blocchi in streaming

Con i token che arrivano al TTS e l’audio che torna indietro, la prossima decisione riguarda la dimensione dei blocchi e quanto il player deve bufferizzare prima di iniziare.

Blocchi più piccoli arrivano prima al player, riducendo la latenza del primo byte, ma comportano più messaggi e un leggero overhead per blocco. Blocchi più grandi sono più efficienti da trasportare, ma fanno aspettare di più l’utente per il primo. Per agenti interattivi, conviene usare blocchi piccoli all’inizio dell’enunciato, perché il primo blocco è quello che l’utente aspetta; i blocchi successivi arrivano mentre l’audio è già in riproduzione e la loro dimensione conta meno.

Il player incide in modo significativo sulla latenza residua. La maggior parte dei player audio non inizia la riproduzione al primo byte, ma bufferizza una piccola quantità per evitare interruzioni se lo stream rallenta. Un buffer predefinito di 500ms è comune e si aggiunge direttamente alla latenza percepita. Ridurlo comporta un piccolo aumento del rischio di interruzioni, ma abbassa il TTFA; il valore giusto dipende dal jitter di rete tra server e client:

• Su una connessione stabile (riproduzione lato server, client co-locato), un buffer tra 50 e 150ms è di solito sicuro e riduce sensibilmente il TTFA.
• Su una connessione mobile o tra regioni con molto jitter, un buffer più grande previene vuoti audio che sono peggiori della latenza che aggiungono.

La configurazione esatta dipende dal tuo caso d’uso e dalle tue priorità.

Scelta del codec

La destinazione dell’audio dovrebbe determinare il codec da richiedere. Restituiamo formati come mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 e ulaw_8000. Scegliere il formato nativo del trasporto elimina una fase di transcodifica, aiutando nell’ottimizzazione della latenza dell’agente vocale.

Per la telefonia, come Twilio e provider simili, usa ulaw_8000. La rete telefonica è 8kHz mu-law end-to-end, quindi richiederlo direttamente evita una transcodifica nella pipeline e corrisponde a ciò che si aspetta il carrier. Non ha senso sintetizzare audio a qualità superiore che la rete telefonica ridurrà subito; aggiungeresti solo latenza senza alcun vantaggio udibile.

Per WebRTC e riproduzione su browser, usa PCM (pcm_24000 o pcm_16000) o un formato MP3. PCM è non compresso, quindi non serve decodifica lato client, eliminando un po’ di latenza per blocco ed è comodo se alimenti direttamente una pipeline Web Audio. MP3 è più compatto sulla rete, utile su connessioni limitate, al costo di una leggera decodifica lato client.

Geografia e distanza di rete

Tutte le ottimizzazioni sopra presuppongono che i byte debbano percorrere poca strada. La geografia stabilisce il limite minimo del tuo budget di latenza, quindi vale la pena analizzarla prima di ottimizzare altro.

Gestiamo le richieste da cluster in Nord America, Europa e Sud-Est Asiatico e instradiamo ogni richiesta automaticamente verso il cluster più vicino. Il round-trip di rete su internet pubblica è tipicamente tra 20 e 200ms a seconda della distanza geografica, ed è un valore che non si può ridurre senza cambiare dove gira la tua infrastruttura.

Un agente che sembra istantaneo a San Francisco, vicino a un cluster nordamericano, può risultare lento per un utente in Asia meridionale il cui traffico attraversa l’oceano due volte per ogni turno.

La soluzione è co-localizzare i server della tua applicazione con i tuoi utenti, non solo con noi. Se i tuoi utenti sono in Europa, esegui il backend dell’agente in Europa così il tratto utente-server è breve; il nostro routing poi gestisce il tratto server-modello da un cluster vicino.

Misurare la latenza degli agenti vocali in autonomia

I numeri nella tabella del budget di latenza sopra sono intervalli indicativi per la pianificazione. I dati reali devono arrivare da uno script come questo, eseguito sulla tua implementazione.

Lo script qui sotto misura il TTFA per la fase TTS isolata, cioè il tempo dalla richiesta al primo blocco audio, su molte prove, e riporta i percentili. Eseguilo dalla stessa regione in cui girano i tuoi server, non dalla tua macchina di sviluppo. Presuppone l’uso del client elevenlabs visto prima:

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

Alcune cose da ricordare:

• Riporta P50 e P95:Concentrati su questi, non sulla media. La media nasconde la coda, ed è la coda che fa sembrare un agente inaffidabile. P95 è l’esperienza di un turno su venti.
• Sperimenta in base alla posizione: Esegui lo stesso script da ogni regione che servi e tieni separati i risultati.
• Scagliona per accuratezza:Distanza le richieste (come il setTimeout sopra). Se le invii tutte insieme, misuri la tua coda interna invece del servizio. Quando superi il limite di concorrenza, le richieste vengono messe in coda per priorità, aggiungendo circa 50ms, e oltre la capacità ricevi HTTP 429.
• Misura l’intera catena di latenza:Applica lo stesso schema di misurazione anche alle altre fasi. Racchiudi la finalizzazione STT, il primo token dell’LLM e l’avvio del player negli stessi blocchi performance.now(), così puoi compilare la tabella del budget con i tuoi dati e vedere su quale fase intervenire per prima.

Seguendo questi consigli, potrai misurare in autonomia la latenza degli agenti vocali. Da lì, avrai una chiara lista di priorità su cui intervenire.

Cosa riduce maggiormente la latenza degli agenti vocali?

Se vuoi alcune azioni rapide su cui concentrarti, queste sono le modifiche più efficaci.

In ordine di impatto, puoi usare questi metodi per ridurre la latenza dell’agente:

• Avvia l’elaborazione LLM sui parziali STT stabili per nascondere il ritardo di endpointing.
• Trasmetti i token LLM al TTS ai confini di frase, così la sintesi della prima frase si sovrappone alla generazione della seconda.
• Trasmetti l’audio TTS al player e riduci il buffer del player al valore minimo che il jitter di rete consente.
• Usa Flash con una voce predefinita o IVC per il TTS a latenza più bassa e abbina il codec al trasporto (ulaw_8000 per la telefonia, PCM o MP3 per browser/WebRTC).
• Co-localizza i tuoi server con i tuoi utenti e misura per regione, perché i tratti di rete sono reali e diversi.

Per tecniche più approfondite, consulta la guida pratica per sviluppatori all’ottimizzazione della latenza. Per un esempio completo e pronto all’uso, l’API quickstart e la guida streaming contengono esempi completi.

Vuoi accedere più velocemente a pipeline di agenti ottimizzati? ElevenAgents implementa questa pipeline con ottimizzazioni di sovrapposizione già integrate.

Crea agenti vocali a bassa latenza con ElevenAgents

Ottimizzare la latenza degli agenti vocali richiede di misurare ogni fase e poi sovrapporre le fasi in modo che le più lente vengano eseguite mentre altre sono già in corso. Puoi costruire e ottimizzare questa cascata manualmente in più iterazioni, seguendo i pattern sopra, oppure partire da una pipeline che ha già ottimizzazioni di latenza integrate.

ElevenAgents implementa l’intera cascata: dallo streaming STT al passaggio token-per-token all’LLM fino al TTS Flash, con tecniche di sovrapposizione già incluse. Invece di partire da zero, puoi regolare le soglie per ottenere le prestazioni che ti interessano di più.

Inizia subito usando ElevenAgents per creare un agente oggi stesso oppure contatta il reparto vendite per maggiori informazioni.

Domande frequenti sull’ottimizzazione della latenza degli agenti vocali