Voorbij de SIP-trunk: latency van voice-agents terugbrengen tot onder 300 ms

Door het IdentityCall AI-team | Engineering | 8 min lezen

De nieuwe latencystandaard

In 2024 draait de “turingtest” voor voice-agents niet alleen om intelligentie: het draait om snelheid. De vorige standaard van 800 ms tot 1 s latency (typisch voor cloudgebaseerde LLM-ketens) is niet langer acceptabel voor klantinteracties met een hoge inzet. Gebruikers ervaren vertragingen >500 ms als “robotachtig” of “kapot”, wat leidt tot door elkaar heen praten en frustratie.

De nieuwe gouden standaard is beurtwisseling in minder dan 300 ms. Dit artikel verkent de architecturale verschuivingen die daarvoor nodig zijn.

Het knelpunt: traditionele cloudketens

De traditionele voice-AI-stack ziet er zo uit:

VAD (Voice Activity Detection) wacht op stilte (200-500 ms).
Audio-upload naar de cloud (100 ms).
ASR (transcriptie) verwerkt de volledige uiting (200-400 ms).
LLM-inferentie genereert de tokenstroom (200-800 ms).
TTS (synthese) genereert audio uit tekst (200-400 ms).
Audio-download en afspelen (100 ms).

Totale latency: 1.5 s - 2.5 s. Daarom voelde je voicebot van de eerste generatie traag aan.

De oplossing: streaming- en edge-architecturen

1. Speculatieve uitvoering en streaming-ASR

Wacht niet op stilte. Moderne architecturen gebruiken streaming-ASR die gedeeltelijke transcripties naar de LLM stuurt terwijl de gebruiker nog aan het praten is.

Techniek: de LLM begint de respons te voorspellen op basis van de eerste 80% van de zin.
Veiligheid: een “commitment gate” zorgt ervoor dat de bot niet spreekt totdat de intentie duidelijk is, maar de tokens zijn al vooraf gegenereerd.

2. Edge-AI en lokale VAD

Voice Activity Detection (VAD) naar de edge verplaatsen (of naar het gelokaliseerde knooppunt van de telefonieaanbieder) bespaart kritieke round-trip-tijd.

Impact: snijdt 100-200 ms netwerkjitter weg.
Implementatie: VAD-modules in WebAssembly (Wasm) die direct in de browser of op de telefonie-edge draaien.

3. TTFT-optimalisatie (Time to First Token)

Voor de LLM zelf optimaliseren we op Time to First Token.

Kwantisatie: het gebruik van 4-bits gekwantiseerde modellen (bijv. Llama-3-8B-Int4) verhoogt de inferentiesnelheid drastisch met verwaarloosbaar precisieverlies voor conversationele taken.
Cache: semantische caching slaat antwoorden op veelvoorkomende begroetingen (“Hallo”, “Met wie spreek ik?”) op om ze direct te serveren (0 ms inferentie).

Architectuurdiagram (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)

Conclusie

Latency onder 300 ms verandert een “voicebot” in een “voice-agent”. Door rigide request-responscycli in te ruilen voor vloeiende streaming-architecturen creëren we ervaringen die opmerkelijk menselijk aanvoelen.

Klaar om snellere agents te bouwen? Verken onze API-documentatie voor streaming-endpoints.