Rekenhulp voor responstijd van AI-modellen

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

De totale responstijd van een AI-model bepaalt in grote mate hoe vloeiend een applicatie aanvoelt voor een eindgebruiker. In de praktijk bestaat deze wachttijd uit twee afzonderlijke fasen: de tijd tot de eerste uitvoer verschijnt en de snelheid waarmee de rest van de tekst wordt gegenereerd. Met deze interactieve rekenhulp kun je twee verschillende scenario's invoeren en direct vergelijken, bijvoorbeeld een groter redeneermodel met een lage uitvoersnelheid tegenover een kleiner, geoptimaliseerd model.

Hoe deze rekenhulp werkt en wat de resultaten betekenen

De bovenstaande tool berekent de tijdsduur van interacties met Large Language Models (LLM's) op basis van een eenvoudig wiskundig model. Een verzoek aan een taalmodel bestaat uit twee hoofdstappen: het verwerken van de invoer en het genereren van de eerste output, gevolgd door het opeenvolgend genereren van de overige tekens.

In de rekenhulp voer je voor twee scenario's de verwachte prestaties in. De rekenhulp spitst de uitkomst toe op twee perspectieven: de klassieke wachttijd waarbij een gebruiker wacht tot het gehele antwoord klaar is, en de ervaren wachttijd wanneer er gebruik wordt gemaakt van een streaming-verbinding. De uitkomsten laten in één oogopslag zien hoe kleine veranderingen in uitvoersnelheid of netwerkvertraging zich opstapelen over meerdere verzoeken binnen een volledige sessie.

Waarom TTFT en uitvoersnelheid twee afzonderlijke variabelen zijn

Bij het beoordelen van API-prestaties worden Time to First Token (TTFT) en de uitvoersnelheid (vaak uitgedrukt in tokens of tekens per seconde) regelmatig op één hoop gegooid onder de algemene noemer 'snelheid'. Dit zijn echter twee fundamenteel verschillende fasen in de verwerking door een taalmodel, die door heel andere hardware- en softwarefactoren worden bepaald.

Tijd tot het eerste teken (TTFT)

De TTFT meet de tijd tussen het moment dat jouw applicatie de verzoekstroom verstuurt en het moment dat de allereerste letter op het scherm verschijnt. Deze fase bestaat uit de netwerktijd naar de server, het verwerken en tokenizen van de invoerprompt, de prefill-fase op de grafische kaart (GPU) en het genereren van het allereerste token.

Wanneer een prompt erg lang is (bijvoorbeeld een document van tientallen pagina's), stijgt de TTFT aanzienlijk doordat de GPU de volledige context in één keer moet doorrekenen. Tijdens deze fase heeft de gebruiker nog geen enkele feedback ontvangen en kijkt deze tegen een leeg scherm of een laadindicator aan.

Generatiesnelheid in tekens per seconde

Zodra het eerste token is gegenereerd, gaat het model over naar de decodeerfase. Hierbij genereert het model token voor token in een autoregressieve lus: elk nieuw gegenereerd teken wordt weer toegevoegd aan de context om het volgende teken te bepalen. De snelheid van deze fase wordt voornamelijk begrensd door de geheugenbandbreedte van de grafische kaarten waarop het model draait.

Een model kan een zeer trage TTFT hebben (bijvoorbeeld door een drukke wachtrij of een enorme invoerprompt), maar daarna in hoog tempo tekens produceren. Omgekeerd kan een klein model direct beginnen met praten (lage TTFT), maar door een beperkte infrastructuur een trage uitvoersnelheid hebben. Omdat beide fasen andere knelpunten hebben, moeten ze altijd apart worden geanalyseerd.

De invloed van streaming op de ervaren wachttijd

Wanneer een applicatie wacht op de volledige API-respons voordat er iets op het scherm wordt getoond, is de totale wachttijd gelijk aan de som van de TTFT en de totale generatieduur. Bij een antwoord van 1.500 tekens en een snelheid van 100 tekens per seconde betekent dit dat de gebruiker al snel 15 tot 16 seconden moet wachten voordat er een letter zichtbaar is.

Door gebruik te maken van streaming responses via Server-Sent Events (SSE) wordt de inhoud direct in kleine brookjes naar de browser gestuurd zodra deze beschikbaar zijn. Hierdoor verandert de totale fysieke tijdsduur van de API-aanroep niet, maar de perceptie van de gebruiker verandert ingrijpend. De gebruiker kan beginnen met lezen zodra de eerste paar zinnen (bijvoorbeeld 10% van het totaal) op het scherm staan. Omdat een mens gemiddeld zo'n 20 tot 30 tekens per seconde leest, kan de gebruiker de tekst al verwerken terwijl het model op de achtergrond de rest van de alinea's aanvult.

Uitvoerlengte: de belangrijkste knop voor responstijd

Uit de berekeningen in de tool blijkt dat de verwachte uitvoerlengte de grootste stempel drukt op de totale tijdsduur. In veel ontwikkeltrajecten wordt veel tijd besteed aan het selecteren van een snellere API-aanbieder om de TTFT met 100 milliseconden te verlagen, terwijl de promptinstructies onnodig lange antwoorden aanmoedigen.

Door in de systeem-prompt expliciet te vragen om beknopte antwoorden, bullet points of gestructureerde JSON-structuren zonder overbodige inleidingen, kan de uitvoerlengte vaak met 50% worden teruggebracht. Dit halveert direct de generatietijd per verzoek. Wie de totale responstijd structureel wil verlagen, behaalt de meeste winst door de gewenste uitvoerlengte strikt te begrenzen. Voor scenario's waarin de rekenkracht op de hardware van de gebruiker zelf draait, spelen daarnaast specifieke randvoorwaarden mee; lees daarover meer in het overzicht over kleine modellen op het apparaat.

Onzichtbare redeneerstappen en de impact op responstijd

Een bijzondere categorie vormen de zogenaamde redeneermodellen (reasoning models). Deze modellen genereren intern een keten van gedachten (chain-of-thought) voordat ze hun definitieve antwoord aan de gebruiker tonen. Deze interne redeneerstappen worden in veel API-implementaties verborgen voor de interface.

Voor de eindgebruiker uit dit verschijnsel zich als een extreem hoge TTFT. Het model is op de achtergrond al honderden of duizenden 'onzichtbare' tokens aan het genereren om de logische stappen te doorlopen. Zelfs als het uiteindelijke zichtbare antwoord slechts 200 tekens lang is, kan de wachttijd voor het eerste teken oplopen tot 5 of 10 seconden. Bij het vergelijken van modellen is het cruciaal om dit onderscheid mee te wegen. Zie hiervoor ook de uitgebreide analyse waarin redeneermodellen worden vergeleken op het gebied van nauwkeurigheid versus wachttijd.

Gemiddelden versus percentielen bij snelheidsmetingen

De getallen die je in deze rekenhulp invoert, zijn vaste waarden. In de praktijk is de responstijd van een AI-dienst echter variabel. Het rapporteren van responstijden op basis van een gemiddelde geeft vaak een misleidend beeld, omdat incidentele uitschieters de ervaring van gebruikers zwaar negatief beïnvloeden.

In professionele omgevingen wordt daarom gemeten in percentielen:

• p50 (Mediaan): De responstijd waar 50% van de verzoeken onder blijft. Dit representeert de typische ervaring op een rustig moment.
• p90: De responstijd waar 90% van de verzoeken onder blijft. Dit geeft inzicht in vertragingen tijdens drukkere perioden.
• p99: De responstijd voor de langzaamste 1% van de verzoeken. Dit toont de uiterste pieken door netwerkhickups, complexe prompts of overbelaste servers.

Wanneer je een scenario invoert in deze rekenhulp, is het verstandig om niet alleen je mediaan in te vullen, maar ook een scenario door te rekenen op basis van de p99-waarden van je aanbieder. Meer informatie over de opzet van betrouwbare benchmarks vind je in het artikel over snelheid meten bij AI-modellen.

Waar deze rekenhulp ophoudt: externe factoren

Deze rekenhulp biedt een theoretisch framework om de invloed van parameters te begrijpen. Een rekenmodel in de browser kan echter nooit de volledige werkelijkheid van een productie-omgeving simuleren. De volgende externe factoren vallen buiten het bereik van deze calculator:

• Netwerkafstand en TLS-handshakes: De fysieke afstand tussen jouw server (of de browser van de gebruiker) en het datacenter van de modelaanbieder voegt latentie toe.
• Wachtrijen bij de aanbieder: Bij een onverwachte piek in het wereldwijde gebruik kan een API-verzoek secondenlang in een wachtrij blijven staan voordat de GPU aan de prompt kan beginnen.
• Koude starts (Cold starts): Als een model op een eigen server of gespecialiseerd platform draait en een tijdje niet is aangeroepen, moet het model eerst vanuit opslag naar het GPU-geheugen worden geladen.
• Netwerk-timeouts: Bij extreem trage antwoorden kan de verbinding voortijdig verbroken worden door tussentijdse proxies of API-gateways. Zie de documentatie over timeouts en cancellation voor het robuust afhandelen van deze situaties.

Om gegarandeerde cijfers te krijgen voor een specifieke toepassing, is het uitvoeren van eigen metingen en belastingstesten op de live-infrastructuur de enige betrouwbare methode.

Lees ook

• Modelkosten calculator - Berekend de kosten per token en verzoek
• Kleine modellen op apparaat - Lokale uitvoering en wachttijden
• Redeneermodellen vergeleken - Latentie versus denkkracht
• Snelheid meten - Handleiding voor correcte benchmarking van LLM's
• Streaming responses - SSE implementeren in API-koppelingen
• Timeouts en cancellation - Omgaan met trage API-responsen