Voice AI-latencycalculator

Hoe dit wordt berekend

De ervaren vertraging is de som van elke fase tussen het einde van het spreken en de eerste audio: de stilte die je afwacht voordat je besluit dat de beller klaar is, het afronden van de transcriptie, het eerste token van het model, de eerste byte van de stem, twee netwerkhops en het telefoniepad.

perceived gap = endpointing silence      ← your setting
              + STT finalisation
              + LLM time to first token
              + TTS time to first byte
              + network RTT × 2           ← your region choice
              + telephony / jitter buffer

Waarom het meestal niet aan het model ligt

In een typische opzet is de endpointing-drempel voor stilte de grootste post — zo'n 600ms van een budget van ruwweg 1.500ms, oftewel 40% van alles waar de beller op wacht. Het is geen limiet van de leverancier. Het is een getal in je configuratie dat bepaalt hoe lang het systeem naar stilte luistert voordat het concludeert dat de beller is uitgesproken, en teams besteden routineus weken aan het benchmarken van modellen terwijl dat getal op een default staat die niemand heeft gekozen.

Hem verkorten is de goedkoopste winst die er is, en het is een echte afweging in plaats van gratis: snijd je te ver door, dan onderbreek je iedereen die midden in een zin pauzeert. Regiokeuze is de andere knop die je zelf in handen hebt — de netwerk-round trip telt dubbel, dus een deployment over regio's heen kan er 400ms bovenop doen voordat welke leverancier dan ook iets fout heeft gedaan.

Hoe goed eruitziet

Natuurlijke gaten bij menselijke beurtwisseling liggen rond de 200ms. Onder 500ms voelt een agent onmiddellijk; onder 800ms leest het als een normale pauze. Voorbij ongeveer 1,2 seconden gaan bellers zichzelf herhalen of door de agent heen praten, omdat de stilte overkomt als een weggevallen lijn in plaats van als nadenken. Een reasoning-model op 1,4 seconden tot het eerste token verbruikt in zijn eentje het hele budget — daarom horen die na het gesprek thuis, samenvattend en beslissend, en niet in de live beurt.

De cijfers per fase zijn hier typische gepubliceerde of waargenomen ranges, geen garanties. Werkelijke latency varieert met regio, belasting, payload en netwerkomstandigheden — meet je eigen cijfers en gebruik dit als budget om tegenaan te ontwerpen.

Last reviewed July 2026.

Veelgestelde vragen

Wat is een goede latency voor een voice-AI-agent?

Onder 800ms voelt comfortabel en onder 500ms voelt direct — natuurlijke pauzes bij het beurtwisselen tussen mensen liggen rond 200ms. Voorbij ongeveer 1,2 seconden gaan bellers zichzelf herhalen of door de agent heen praten, omdat de stilte overkomt als een weggevallen lijn in plaats van als nadenken.

Waarom is mijn voice-agent traag terwijl elke leverancier lage latency claimt?

Omdat de cijfers van de leverancier maar een deel van het budget zijn. In een typische opzet is de endpointing-stiltedrempel — de tijd die je wacht om zeker te weten dat de beller is uitgesproken — veruit de grootste bijdrage, vaak 40% van het totaal. Het is een instelling aan jouw kant, geen beperking van de leverancier, en geen enkele hoeveelheid modellen vergelijken lost dat op.

Hoe verlaag ik de latency van een voice-agent?

Op volgorde van rendement: verkort de endpointing-drempel, deploy in dezelfde regio als je providers, kort de system prompt in, stream tekst naar spraak in plaats van te wachten op een volledig antwoord, en overweeg pas daarna een sneller model. De eerste twee zijn gratis en leveren meestal meer op dan de rest bij elkaar.

Wat is endpointing?

Bepalen wanneer de beller is uitgesproken. Wacht je te lang, dan voelt elk antwoord traag; kap je te vroeg af, dan onderbreek je iedereen die midden in een zin pauzeert. Het is een echte afweging en geen bug — maar het is een afweging die de meeste teams nooit bewust maken, waarbij ze een default laten staan en het model de schuld geven.

Is een reasoning-model zinvol voor voice?

Zelden op het kritieke pad. Een model dat 1,4 seconden doet over het eerste token verbruikt in zijn eentje het hele budget. Reasoning-modellen passen beter na het gesprek — samenvatten, extraheren, vervolgacties bepalen — terwijl de live beurt draait op iets dat gebouwd is voor time to first token.

Verder lezen