Rate-limit-simulator voor LLM-API's

Door Ivo Donker - 3 augustus 2026

Wanneer je applicaties bouwt op basis van Large Language Models (LLM's), zijn rate-limits van API-providers een van de belangrijkste infrastructurele hobbels. Deze simulator helpt je te berekenen of jouw verwachte verkeerspatroon binnen de ingestelde grenzen valt, welke limiet als eerste knelt en wat het verwachte percentage HTTP 429-fouten (Too Many Requests) is.

Hoe rate-limits van LLM-providers werken

Rate-limiting is een fundamenteel mechanisme van API-providers om de stabiliteit en beschikbaarheid van hun infrastructuur te beschermen. Bij traditionele REST-API's wordt er vrijwel uitsluitend gekeken naar het aantal netwerkverzoeken per tijdseenheid. Bij generatieve AI en Large Language Models ligt dit complexer, omdat de rekenkracht en het geheugengebruik (VRAM) per verzoek enorm variëren op basis van de hoeveelheid verwerkte en gegenereerde tekst. Wil je meer weten over hoe invoer wordt omgezet naar deze rekeneenheden, lees dan onze gids over tokenisatie uitgelegd.

Providers hanteren doorgaans drie tot vier verschillende dimensies voor rate-limits:

• RPM (Requests Per Minute): Het maximale aantal afzonderlijke HTTP-verzoeken dat je binnen een voortschrijdend venster van 60 seconden mag versturen.
• TPM (Tokens Per Minute): Het totale aantal tokens (zowel invoer- als uitvoertokens) dat binnen 60 seconden door het model verwerkt mag worden.
• TPD (Tokens Per Day): Een dagelijks plafond dat vaak geldt voor gratis tiers of specifieke proefaccounts om misbruik over langere periodes te voorkomen.
• Gelijktijdigheid (Concurrency Limit): Het maximale aantal verzoeken dat op exact hetzelfde moment in behandeling mag zijn bij de infrastructuur van de provider.

Wanneer een applicatie een van deze limieten overschrijdt, antwoordt de API van de provider met een HTTP statuscode 429 Too Many Requests. Het begrijpen van de exacte verhouding tussen deze limieten is essentieel voor een stabiele architectuur, zoals ook beschreven op onze pagina over rate-limits en kosten.

Waarom TPM meestal eerder knelt dan RPM

Een veelvoorkomende valkuil voor softwarearchitecten is het aannemen dat de RPM-limiet de voornaamste bottleneck is. In de praktijk blijkt echter dat de TPM-limiet vrijwel altijd als eerste wordt bereikt. Dit heeft te maken met het relatief hoge aantal tokens per verzoek in moderne LLM-toepassingen.

Neem bijvoorbeeld een scenario waarin een provider een limiet stelt van 500 RPM en 90.000 TPM. Als jouw applicatie gemiddeld 800 invoertokens stuurt en 400 uitvoertokens terugkrijgt, verbruikt elk verzoek exact 1.200 tokens. Om de TPM-limiet van 90.000 te bereiken, zijn slechts 75 verzoeken per minuut nodig ($90.000 / 1.200 = 75$). Op dat moment benut je slechts 15% van je toegestane RPM ($75 / 500$). De TPM-limiet knelt in dit geval dus al bij een fractie van de maximale verzoekfrequentie.

Bovendien zijn uitvoertokens aan de serverzijde veel zwaarder om te genereren dan invoertokens (door het auto-regressieve karakter van LLM's), al rekenen API-providers voor de TPM-limiet de som van beide. Als een prompt door een grote context of uitgebreide RAG-documenten stijgt naar 4.000 tokens per verzoek, kan een enkele parallelle reeks verzoeken de TPM-limiet al binnen enkele seconden volledig uitputten.

Het correct afhandelen van HTTP 429-fouten

Wanneer een 429-fout optreedt, is het van cruciaal belang dat de client-applicatie hier op een gecontroleerde manier mee omgaat. Het direct en onbeperkt herhalen van het verzoek (brute-force retries) leidt tot een zogenaamde retry storm, waarbij het netwerk volledig verstopt raakt en de API-provider verzoeken kan gaan weigeren op IP-niveau.

De industriestandaard voor het afhandelen van rate-limits omvat de volgende elementen:

• Exponential Backoff: Verhoog de wachttijd tussen opeenvolgende pogingen exponentieel (bijvoorbeeld 1s, 2s, 4s, 8s).
• Jitter (ruis): Voeg een willekeurige variatie toe aan de wachttijd om te voorkomen dat meerdere gelijktijdige verzoeken op exact hetzelfde moment opnieuw worden verstuurd.
• Respecteren van response headers: Veel providers sturen nuttige headers mee zoals x-ratelimit-reset-requests of retry-after. De client dient deze waarden uit te lezen en exact zo lang te wachten voor een nieuwe poging. Om te zien hoe je dit in de praktijk opbouwt, kun je de gids over retries en backoff raadplegen.

Strategieën: Batchen, spreiden en routering

Als uit de simulator blijkt dat jouw verwachte piekbelasting de beschikbare limieten overschrijdt, zijn er verschillende architecturele maatregelen mogelijk om uitval te voorkomen:

1. Batchverwerking voor asynchrone taken

Taken die niet realtime uitgevoerd hoeven te worden (zoals het verwerken van documenten, nieuwsbrieven of data-analyse) kunnen beter verzameld worden. Veel providers bieden speciale endpoints voor batchverwerking tegen een lager tarief en met een gescheiden, hogere rate-limit. Meer details hierover vind je op onze pagina over batchverwerking voor LLM-API's.

2. Dynamic Rate-Limiting op Client-niveau

Door een lokale token-bucket of leaky-bucket algoritme in je eigen backend op te nemen, kun je het uitgaande verkeer afvlakken (traffic shaping). In plaats van verzoeken direct af te vuren op de externe API, worden ze opgevangen in een interne wachtrij die verzoeken gedoseerd doorlaat op basis van het gemeten tokenverbruik.

3. Multi-provider en Model Routing

Wanneer een enkele provider-sleutel onvoldoende capaciteit biedt, kan een routeringslaag uitkomst bieden. Hiermee worden verzoeken dynamisch verdeeld over meerdere API-sleutels, meerdere accounts of zelfs verschillende LLM-providers. Raadpleeg het artikel over model routing voor strategieën om verzoeken slim te verdelen bij dreigende limieten.

Echte limieten meten in plaats van schatten

Hoewel een simulator zoals deze een uitstekend theoretisch inzicht geeft, verschilt de praktijk soms van de statische berekeningen. Twee belangrijke factoren zorgen voor afwijkingen:

1. Variabele responslengtes: LLM's genereren geen vast aantal tokens. Een vraag kan soms in 50 tokens beantwoord worden en de volgende keer in 800 tokens.
2. Voortschrijdende tijdvensters (Sliding Windows): Providers resetten de TPM-limiet zelden op een vast minuut-omslagpunt. In plaats daarvan gebruiken ze vaak een voortschrijdend venster van bijvoorbeeld 60 seconden of een leaky-bucket algoritme op milliseconden-niveau.

Om exacte limieten en daadwerkelijk verbruik in kaart te brengen, is het noodzakelijk om telemetry in te richten in je softwarepijplijn. Zowel het aantal gebruikte tokens per verzoek als de latency en eventuele 429-fouten moeten gemonitord worden. Voor een diepere duik in het instellen van actieve monitoring, verwijzen we naar onze handleiding over observability en logging.

Aannames en beperkingen

Deze simulator maakt gebruik van een vereenvoudigd wiskundig model om verkeersstromen en rate-limits inzichtelijk te maken. Houd bij het interpreteren van de resultaten rekening met de volgende uitgangspunten:

• Statische tokenlengtes: De berekening gaat uit van een vast gemiddelde voor invoer- en uitvoertokens per verzoek. In werkelijkheid varieert de tokenlengte per verzoek.
• Gelijkmatige verdeling: Verzoeken binnen een minuut worden verondersteld gelijkmatig verdeeld te zijn over de tijd. Piekbelastingen in de praktijk komen vaak voor in zeer korte bursts (bijvoorbeeld 20 verzoeken in 1 seconde), wat sneller tot een 429-fout leidt dan het model voorspelt.
• Eenvoudig Wachtrijmodel: De wachtrijberekening veronderstelt een FIFO-principe (First In, First Out) zonder prioriteitsregels of netwerk-overhead latency.
• Geen provider-specifieke uitzonderingen: Sommige providers rekenen een minimale tokencount per verzoek of hanteren aparte limieten op basis van het gekozen model binnen hetzelfde account. Neem deze specifieke regels over over te nemen in je eigen parameters.

Lees ook

• Rate-limits en kosten in de praktijk
• Afhandeling van retries en exponential backoff
• Optimalisatie via batchverwerking voor LLM-API's
• Strategieën voor model routing en fallback
• API-snelheid en latency meten
• Hoe werkt tokenisatie exact?