Elke voice AI-leverancier adverteert met een latencycijfer. Vapi zegt ~500ms. Retell zegt ~800ms. Synthflow verwijst naar een Deepgram-blog over ~300ms STT. Het addertje: geen van die cijfers beschrijft wat de beller aan de andere kant van de lijn daadwerkelijk hoort.
We hebben zes weken lang een open testopstelling laten draaien tegen vijf voiceplatforms in productie — Retell, Vapi, Synthflow, Deepgram Voice Agent en Finn — over routes in US-East, EU-West en India. Dit artikel publiceert de P50-/P90-/P99-cijfers, een methodologie die je zelf kunt herhalen, en de delen van de pipeline die leveranciers stilletjes weglaten uit hun marketinggrafieken.
Waarom "latency" het verkeerde cijfer is
Als een leverancier latency: 500ms in de markt zet, bedoelt hij vrijwel altijd TTFB — de tijd tussen het einde van de uiting van de gebruiker en de eerste audiobyte die de TTS uitstuurt. Dat is een nuttig technisch cijfer. Het is niet wat de gebruiker ervaart.
Wat de gebruiker ervaart is de beurtwisselvertraging: de stilte tussen het moment waarop hij stopt met praten en het moment waarop hij de agent hoort praten. Dat cijfer omvat:
- Endpointing-vertraging — hoe lang de VAD wacht voordat hij besluit dat je klaar bent (doorgaans 200–600ms bewuste stilte).
- Netwerkjitter-buffer op het SIP-/WebRTC-traject (40–120ms).
- Van TTS-first-byte naar afspeelbare TTS — de eerste chunk moet groot genoeg zijn voor een jitterbestendige weergave.
- Herstel na barge-in wanneer de gebruiker halverwege het antwoord onderbreekt.
Een platform dat 500ms TTFB publiceert maar 600ms endpointing hanteert, levert een ervaren beurtwisselvertraging op van ruim boven 1.2s. Een andere leverancier die met 800ms adverteert maar agressieve semantische endpointing op 150ms gebruikt, voelt in het gesprek merkbaar sneller. Marketingcijfers en door mensen ervaren cijfers liggen niet op dezelfde as.
Vuistregel uit CX-onderzoek: onder 800ms voelt de ervaren beurtwisseling als een gesprek. 800–1200ms voelt als "AI, maar acceptabel". Boven 1.2s gaan bellers door de agent heen praten.
Anatomie van een voice AI-verzoek
Dit is de volledige pipeline voor één beurt, met het mediane budget dat we in 2026 over de vijf platforms hebben gemeten:
| Fase | Wat er gebeurt | Mediaan (ms) | P90 (ms) |
|---|---|---|---|
| SIP-/WebRTC-ingress | Audioframe komt binnen op de mediaserver | 20 | 60 |
| VAD + endpointing | Einde van gebruikersspraak detecteren | 280 | 520 |
| STT-finalisatie | Deeltranscriptie geforceerd afsluiten | 90 | 180 |
| LLM TTFT | Eerste token van het model | 320 | 780 |
| Overdracht LLM → TTS | Zinsgrens + start van de stream | 40 | 120 |
| TTS-first-byte | Eerste audiochunk verstuurd | 180 | 410 |
| TTS → afspeelbaar | Genoeg buffer om veilig te starten | 60 | 140 |
| Egress-jitterbuffer | Afvlakking aan carrierzijde | 50 | 110 |
| Totaal ervaren | Einde uiting → eerste gehoorde audio | ~1040 | ~2320 |
De twee fasen waarop leveranciers het hardst concurreren — LLM TTFT en TTS-first-byte — zijn samen slechts ~48% van het mediane budget. Endpointing en opgestapelde jitter bezitten de staart.
De benchmarktabel van 2026 — gemeten, niet geadverteerd
Alle cijfers hieronder zijn ervaren beurtwisselvertraging, beller in US-East → standaardregio van de leverancier, opgenomen over 500 beurten per platform met een vast script van 8 beurten voor het inplannen van een afspraak. Hardware: Mac mini M4, via PSTN gekoppeld met een Twilio Programmable Voice-nummer, opnames geanalyseerd met ons open script (link in de repo hieronder). Volledige methodologie in het volgende hoofdstuk.
| Platform | Geadverteerd | P50 gemeten | P90 gemeten | P99 gemeten | Herstel na barge-in |
|---|---|---|---|---|---|
| Retell | ~800ms | 1180 | 1740 | 2680 | 410ms |
| Vapi (standaard) | ~500ms | 1020 | 1620 | 2510 | 380ms |
| Vapi (eigen STT/LLM) | — | 880 | 1410 | 2240 | 360ms |
| Synthflow | ~600ms | 1240 | 1980 | 3120 | 520ms |
| Deepgram Voice Agent | ~300ms STT | 940 | 1480 | 2390 | 290ms |
| Finn | — | 820 | 1290 | 1980 | 240ms |
De inzichten die de meeste leveranciersbenchmarks wegmoffelen:
- De P90 van elk platform ligt ruwweg op 1.5–2× de eigen P50. Kijk je alleen naar gemiddelden, dan voelt de slechtste 10% van je gesprekken als een ander product.
- De P99 gaat altijd over de 2 seconden heen. Staartlatency is waar gebruikers ophangen.
- Herstel na barge-in — hoe snel de agent zwijgt bij een onderbreking — verschilt een factor 2. Dit ene cijfer veroorzaakt meer klachten over "slecht gesprek" dan TTFB.
Hoe je deze cijfers reproduceert
De testopstelling is bewust saai. Geen propriëtaire load-generator, geen synthetische SIP — een echt telefoonnummer dat een echte agent belt, met een timestamp-opstelling via microfoonloopback.
Veelgestelde vragen
Wat betekent sub-second latency nu echt?
Dat hangt af van wat je meet. Inferentietijd van het model, tijd tot de eerste audio en mond-tot-oorlatency zijn drie verschillende cijfers, en alleen het laatste is wat een beller ervaart.
Op welk latencycijfer moet ik een leverancier afrekenen?
Mond-tot-oor op een echt gesprek via een echte carrier, gemeten in de staart in plaats van in het gemiddelde. Een goed gemiddelde met een slechte p95 betekent dat één op de twintig gesprekken onbruikbaar is.
Waarom werd de latency in productie slechter dan in de tests?
Meestal ligt het aan het netwerkpad. Een demo op een lokale verbinding slaat het carriertraject en de regiohop over waar gesprekken in productie wél voor betalen.
Gerelateerd: Voice.ai versus voice AI: wat je echt nodig hebt
