Oltre il trunk SIP: ridurre la latenza degli agenti vocali a meno di 300 ms

A cura del team di IdentityCall AI | Ingegneria | 8 min di lettura

Il nuovo standard di latenza

Nel 2024, il “test di Turing” per gli agenti vocali non riguarda solo l’intelligenza, ma la velocità. Il precedente standard di 800 ms-1 s di latenza (tipico delle catene di LLM basate sul cloud) non è più accettabile per le interazioni ad alto rischio con i clienti. Gli utenti percepiscono i ritardi >500 ms come “robotici” o “difettosi”, con conseguenti sovrapposizioni di voce e frustrazione.

Il nuovo standard di riferimento è l’alternanza dei turni in meno di 300 ms. Questo articolo esplora i cambiamenti architetturali necessari per raggiungerlo.

Il collo di bottiglia: le catene cloud tradizionali

Lo stack tradizionale di IA vocale è fatto così:

VAD (rilevamento dell’attività vocale) attende il silenzio (200-500 ms).
Caricamento dell’audio sul cloud (100 ms).
ASR (trascrizione) elabora l’enunciato completo (200-400 ms).
Inferenza dell’LLM genera il flusso di token (200-800 ms).
TTS (sintesi) genera l’audio dal testo (200-400 ms).
Download dell’audio e riproduzione (100 ms).

Latenza totale: 1.5 s - 2.5 s. Ecco perché il suo voice bot di prima generazione sembrava lento.

La soluzione: architetture di streaming ed edge

1. Esecuzione speculativa e ASR in streaming

Non aspetti il silenzio. Le architetture moderne usano l’ASR in streaming, che invia trascrizioni parziali all’LLM mentre l’utente sta ancora parlando.

Tecnica: l’LLM inizia a prevedere la risposta basandosi sul primo 80% della frase.
Sicurezza: una “commitment gate” garantisce che il bot non parli finché l’intento non è chiaro, ma i token sono pre-generati.

2. Edge AI e VAD locale

Spostare il rilevamento dell’attività vocale (VAD) sull’edge (o sul nodo localizzato del provider di telefonia) fa risparmiare un tempo di andata e ritorno critico.

Impatto: riduce di 100-200 ms il jitter di rete.
Implementazione: moduli VAD in WebAssembly (Wasm) eseguiti direttamente nel browser o sull’edge di telefonia.

3. Ottimizzazione del TTFT (Time to First Token)

Per l’LLM stesso, ottimizziamo il Time to First Token.

Quantizzazione: l’uso di modelli quantizzati a 4 bit (ad es. Llama-3-8B-Int4) aumenta drasticamente la velocità di inferenza con una perdita di accuratezza trascurabile nei compiti conversazionali.
Cache: il caching semantico memorizza le risposte ai saluti comuni (“Salve”, “Chi parla?”) per servirle istantaneamente (0 ms di inferenza).

Diagramma dell’architettura (Mermaid)

sequenceDiagram
    participant User
    participant Edge_VAD
    participant Cloud_LLM
    participant TTS_Engine
    
    User->>Edge_VAD: Speaks "I need to reset..."
    Edge_VAD->>Cloud_LLM: Stream: "I need to reset..."
    Cloud_LLM->>Cloud_LLM: Pre-fetch "Reset Password flow"
    User->>Edge_VAD: "...my password"
    Edge_VAD->>Cloud_LLM: Stream: "...my password" [EOS]
    Cloud_LLM->>TTS_Engine: Stream Tokens (Immediate)
    TTS_Engine->>User: Audio Stream (Sub-300ms)

Conclusione

Una latenza inferiore a 300 ms trasforma un “voice bot” in un “agente vocale”. Abbandonando i rigidi cicli di richiesta-risposta a favore di architetture di streaming fluide, creiamo esperienze che risultano straordinariamente umane.

Pronto a costruire agenti più veloci? Esplori la nostra documentazione API per gli endpoint di streaming.