Voice AI met lage latency: het volledige latencybudget (2026)

Elke leveranciersblog over "voice AI met lage latency" gaat eigenlijk over één blokje in de pipeline. Een nieuw stemmodel dat 80 ms van de synthese afhaalt. Een aanpassing aan de endpointing. Een cachetruc. Elk daarvan is echt — en elk is nutteloos als de andere vijf fasen in je call path 1.200 ms opslokken terwijl jij die 80 viert.

Latency is een budget, geen feature. Een beller hoort één getal: de stilte tussen het moment waarop hij stopt met praten en het moment waarop je agent begint. Dat getal is de som van elke fase van microfoon tot luidspreker, plus het netwerk waar je geen controle over hebt. Dit is het end-to-end-model — wat elke fase kost, waar de milliseconden zich werkelijk verschuilen, en waar streaming, endpointing en caching je echt tijd opleveren versus waar ze het probleem alleen verplaatsen.

Waarom latency de scheidslijn is tussen "AI" en een echt gesprek

Beurtwisseling tussen mensen heeft een ritme. In een natuurlijk gesprek is de pauze tussen sprekers gemiddeld ongeveer 200 ms, en mensen beginnen hun antwoord te plannen voordat de ander is uitgesproken. Wanneer een telefoonagent na elke zin 1,5 seconde stilte laat vallen, denkt de beller niet "indrukwekkende AI". Hij denkt dat de verbinding is weggevallen, praat door de agent heen, of hangt op.

De praktische drempels waar wij op ontwerpen:

• Onder ~500 ms responstijd voelt als een gesprek. De beller merkt de pauze nauwelijks.
• 500–800 ms is acceptabel, maar hoorbaar "assistent-achtig". Prima voor veel use cases.
• Boven ~1.000 ms wordt het ritme verbroken. Bellers onderbreken, herhalen zichzelf, en het vertrouwen brokkelt af.

Dat doel van onder een seconde is waar alles om draait. En het is niet de taak van één component — het is het budget dat je over de hele stack verdeelt.

Het latencybudget: elke fase van microfoon tot luidspreker

Dit is de retourtijd voor één gespreksbeurt. Ruwe productiewaarden voor een goed gebouwde agent tijdens een telefoongesprek:

Tel dat op en je zit tussen ruwweg 700 ms en 2,4 s. De spreiding is enorm — en let op wat daarin domineert: endpointing en LLM TTFT, niet de STT- of TTS-modellen waar iedereen benchmarks op draait.

Uit deze tabel volgen meteen twee regels:

1. Optimaliseer eerst het grootste blok. Een TTS van 120 ms vervangen door een van 90 ms is ruis als je endpointer 700 ms wacht. Meet voordat je optimaliseert.
2. Fasen overlappen wanneer je streamt. Het budget hierboven is het seriële worstcasescenario. Met streaming kunnen STT, de LLM en TTS gelijktijdig draaien in plaats van na elkaar — en daar komt de meeste echte winst vandaan (zie hieronder).

Endpointing & stiltedetectie: de meest onderschatte 500 ms

Endpointing is de beslissing: is de beller klaar met zijn beurt, of pauzeert hij alleen om adem te halen? Het is het grootste stuk latentie dat je kunt beïnvloeden, en de lastigste afweging in de stack.

Naïeve aanpak: wacht N milliseconden op stilte en vuur dan af. Zet N te laag (zeg 200 ms) en je onderbreekt mensen midden in een zin — pijnlijk wanneer iemand een 16-cijferig kaartnummer voorleest of zegt "mijn adres is... Eikenstraat 42". Zet N te hoog (900 ms) en elke beurt voelt traag.

Wat in productie echt werkt is adaptieve, semantische endpointing in plaats van een vaste stiltetimer:

• VAD (voice activity detection) geeft je het ruwe signaal "is er audio-energie" — snel, maar dom wat betreft intentie.
• Semantische endpointing gebruikt het gedeeltelijke transcript om de volledigheid te beoordelen. "Mijn rekeningnummer is" is duidelijk onafgemaakt; "Ik wil mijn account opzeggen" is een complete gedachte. Een model dat de gedeeltelijke tekst leest, kan bij complete uitingen eerder afvuren en langer wachten midden in een reeks cijfers.
• Contextbewuste time-outs. Wanneer je net om een telefoonnummer hebt gevraagd, verbreed je het stiltevenster en behandel je pauzes tussen cijfers niet als einde van de beurt. Koppel de endpointing-drempel aan het veld dat je aan het verzamelen bent.

Doe je dit goed, dan win je bij de meeste beurten 300–500 ms terug zonder ooit een beller te onderbreken. Doe je het fout, dan redt geen enkele modelwissel je nog.

Alles streamen: de gratis latentiewinst die je laat liggen

De grootste leugen in de tabel met het seriële budget is dat de fasen na elkaar plaatsvinden. Dat zou niet moeten. Stream bij elke overgang en de pipeline klapt in elkaar:

• Gedeeltelijke transcripten. Wacht niet op het definitieve STT-resultaat. Voer gedeeltelijke resultaten aan je endpointer en warm zelfs de LLM-context alvast op, zodat je niet koud begint wanneer de beller stopt.
• Token-streaming vanuit de LLM. Wat telt is de tijd tot het eerste token, niet de tijd tot de volledige completion. Zodra de eerste zinsnede binnenstroomt, geef je die door aan TTS. Je hebt niet het hele antwoord nodig om te beginnen met praten.
• TTS-chunking. Synthetiseer de eerste zin en begin die af te spelen terwijl de LLM nog aan de derde bezig is. De eerste audiobyte is het getal dat telt, niet de volledige clip.

Goed uitgevoerd hoort de beller de eerste woorden van het antwoord terwijl de LLM de rest er nog aan het schrijven is. Zo levert een stack met een serieel budget van in totaal 1,8 s een gevoelde responstijd van 600 ms. Streaming is geen optimalisatie die je later toevoegt — het is de architectuur waarmee je begint.

Eén kanttekening: TTS streamen tijdens het genereren betekent dat je vastzit aan woorden voordat het volledige antwoord bestaat. Als je LLM zichzelf kan corrigeren ("eigenlijk, laat me dat even nakijken — nee, je hebt gelijk"), heb je de verkeerde helft al uitgesproken. Beperk het model tot antwoorden die het in één keer vastleggen, of buffer de eerste zinsnede totdat de zinsstructuur stabiel is.

Audiocaching en pre-warming: echte winst, echte valkuilen

Caching is waar de Vapi-achtige "we hebben het sneller gemaakt"-posts leven, en het is echt nuttig — met scherpe randjes.

Wat veilig te cachen of pre-warmen is:

• Vaste prompts en standaardteksten. Begroetingen, wachtberichten, mededelingen, "een moment geduld terwijl ik dat opzoek." Synthetiseer die één keer vooraf. Nul TTS-latentie tijdens runtime.
• Verbindingen opwarmen. Houd STT-/LLM-/TTS-sockets open en modellen warm, zodat de eerste beurt van een gesprek geen cold-start-tol betaalt. Dit alleen al kan honderden milliseconden schelen bij de eerste beurt.
• Voorspelbare opvultekst. Een korte, natuurlijke "ik zoek dat even voor u op" die wordt afgespeeld terwijl een trage tool-call loopt, maskeert backend-latentie die de beller anders als stilte zou horen.

Wat kapotgaat als je het cachet:

• Alles met dynamische gegevens. Cache "Uw saldo is [X]" als sjabloon en je leest vroeg of laat het verkeerde saldo voor aan de verkeerde beller. Cache de dragende zin, synthetiseer het variabele veld live.
• Gepersonaliseerde of compliance-gevoelige audio. Namen, rekeninggegevens, genoemde prijzen — synthetiseer die elke keer opnieuw.
• Verouderde stem-/modelversies. Een gecachete clip van een oude TTS-stem naast een live stem is midden in een zin pijnlijk duidelijk. Versioneer je cachesleutels op basis van het stemmodel.

Caching levert je het meeste op bij de voorspelbare delen van een gesprek. Voor de dynamische redeneerbeurt doet het niets — en precies daarom kan het niet je hele latentieverhaal zijn.

Telefonie en netwerkrealiteit: de last mile die je niet in handen hebt

Je kunt elk model tot in de puntjes afstemmen en toch een trage agent opleveren, want een telefoongesprek loopt over infrastructuur die je niet zelf beheert.

• PSTN en SIP voegen echte tijd toe. Het openbare telefoonnetwerk en SIP-trunking introduceren transportvertraging voordat uw STT ook maar audio te zien krijgt. Codec-transcodering (bijvoorbeeld van of naar G.711) voegt daar nog iets aan toe.
• Jitter en pakketverlies. Bellers op mobiele netwerken, slechte wifi en overbelaste providers leveren audio ongelijkmatig aan. Uw jitterbuffer maakt de weergave vloeiender, maar voegt daarvoor latency toe — nog een afweging om af te stemmen, niet om weg te nemen.
• Geografie. Als uw inferentie in us-east draait en uw beller en telefonieprovider in Europa zitten, heeft u bij elke beurt een trans-Atlantische heen-en-terugreis toegevoegd. Plaats uw mediapad op dezelfde locatie als uw bellers en uw model-endpoints.
• Het mediapad telt net zo zwaar als het model. WebRTC-naar-SIP-bridging, SBC-routering en de plek waar uw mediaserver staat, kunnen meer kosten of besparen dan het wisselen van model. Dit is infrastructuur-engineering, geen prompt engineering.

De conclusie: reken op 100–300 ms voor netwerk en telefonie die u niet weg kunt optimaliseren, en zorg ervoor dat de milliseconden die u wel in de hand heeft niet verloren gaan aan een mediapad dat via drie regio's heen en weer stuitert.

Turn-taking-latency meten in productie (het getal dat ertoe doet)

U kunt niet optimaliseren wat u niet meet, en de metriek die ertoe doet is niet de benchmark van een afzonderlijk onderdeel. Het is einde van de spraak van de gebruiker tot start van de audio van de agent — gemeten in productie, tijdens echte gesprekken, op het percentiel dat pijn doet.

• Meet de volledige heen-en-terugweg. Zet tijdstempels: laatste audioframe van de beller → endpoint geactiveerd → eerste token van de LLM → eerste byte van de TTS → eerste audioframe naar buiten. Log elke fase bij elke beurt, zodat u kunt zien welk onderdeel het budget opsoupeerde toen een gesprek traag aanvoelde.
• Let op p95, niet op het gemiddelde. Uw gemiddelde latency kan een prachtige 550 ms zijn terwijl p95 op 1,8 s ligt — en het zijn de p95-beurten waardoor bellers ophangen. Gemiddelden verhullen de gesprekken die u verliest.
• Houd de barge-in- / onderbrekingsratio bij. Als bellers vaak door uw agent heen praten, activeert uw endpointer te laat of start uw antwoord te traag. Het is een latencysymptoom vermomd als UX-metriek.

Zet de instrumentatie live voordat u gaat afstemmen. Elke bewering dat "we de latency hebben verlaagd" die niet onderbouwd is met een p95-meting in productie, is een gok.

Interne links

• Hoe we de voice-AI-pipeline hebben gebouwd — STT-keuzes: Whisper versus Deepgram
• SIP-latency oplossen in AI-callcenteroplossingen
• WebRTC en SIP verbinden: overdrachten met lage latency voor AI-voice-agents
• AI-voice-agents voor enterprise: architectuur en ROI
• Hoe u hoge gespreksvolumes beheert zonder meer agents aan te nemen (2026)

FAQ

Wat is een goed latencydoel voor een voice-AI-agent in productie? Streef naar minder dan 800 ms end-to-end (van het einde van de spraak van de beller tot de start van de audio van de agent), en beschouw minder dan 500 ms als het doel voor een echt conversationeel gevoel. Meet op p95, niet op het gemiddelde — de trage staart is wat mensen doet ophangen.

Welk deel van de voice-AI-pipeline veroorzaakt de meeste latency? Meestal endpointing en de time-to-first-token van de LLM, niet de STT- of TTS-modellen waar de meeste benchmarks zich op richten. Endpointing kan er op zichzelf al 200–800 ms bij optellen, dus dat is de eerste plek om te kijken voordat u een model vervangt.

Vermindert audiocaching de voice-AI-latency? Ja, voor vaste content — begroetingen, mededelingen, wachtberichten en opvulzinnen kunnen vooraf worden gesynthetiseerd voor vrijwel nul latency tijdens runtime. Het doet niets voor dynamische redeneerbeurten, en het cachen van iets met gepersonaliseerde of variabele gegevens brengt het risico met zich mee dat de verkeerde informatie aan een beller wordt voorgelezen.

Waarom voelt mijn voice-agent traag aan, zelfs met een snel model? Omdat latency de som is van de hele pipeline plus telefonie waar u geen controle over heeft. Een snelle TTS helpt niet als uw endpointer 700 ms wacht, uw LLM langzaam streamt of uw mediapad heen en weer stuitert tussen regio's. Meet elke fase en pak het grootste onderdeel als eerste aan.

Finn is latency-first gebouwd — streaming STT, semantische endpointing en een token-naar-TTS-overdracht die zijn afgestemd op turn-taking van minder dan een seconde bij echte telefoongesprekken, niet bij benchmarkfragmenten. Ontdek hoe de voice-agents van Finn productiegespreksvolumes aankunnen zonder de stiltes.