Elke AI-API heeft limieten: maximale aanroepen per minuut, maximale tokens per dag, maximale gelijktijdige verbindingen. Als je die limieten negeert, loopt je applicatie vast op het meest ongelegen moment.
Rate limiting is een van de meest onderschatte uitdagingen bij het bouwen van AI-toepassingen. Tijdens ontwikkeling speelt het nauwelijks een rol. In productie, als tientallen of honderden gebruikers tegelijk aanroepen doen, wordt het een serieus architectuurvraagstuk. Dit artikel legt uit hoe je er goed mee omgaat.
Rate limiting betekent dat een API-provider het aantal aanroepen beperkt dat je in een bepaalde tijdsperiode mag doen. Bij AI-APIs zijn er doorgaans meerdere niveaus:
OpenAI, Anthropic en andere providers hanteren al deze limieten, en ze variëren per abonnementsniveau. Als je een limiet overschrijdt, krijg je een 429 Too Many Requests-fout.
Throttling is het proactief vertragen van je aanroepen zodat je de limieten van de provider niet bereikt. Dit is beter dan wachten totdat je een fout krijgt en dan een retry uitvoeren.
Een simpele aanpak is het bijhouden van een teller die telt hoeveel aanroepen je de afgelopen minuut hebt gedaan. Als je de drempel nadert, bouw je een kleine vertraging in. Bibliotheken zoals bottleneck (Node.js) of ratelimiter (Python) doen dit voor je.
Token-throttling is complexer: je moet bijhouden hoeveel tokens je prompts kosten, wat afhankelijk is van de modelkeuze. De meeste API-responses bevatten gebruiksinformatie die je kunt gebruiken om je verbruik bij te houden.
Als je veel aanroepen parallel doet — bij batchverwerking van content of het gelijktijdig bedienen van veel gebruikers — is een wachtrij de robuustere oplossing. Je zet taken in een wachtrij, en een worker verwerkt ze op een gecontroleerd tempo dat binnen de API-limieten blijft.
Populaire opties zijn Redis met BullMQ (Node.js) of Celery (Python). Dit geeft je ook retry-mogelijkheden als een taak mislukt, en je kunt prioriteiten toekennen aan urgente taken.
Veel AI-aanroepen zijn eigenlijk duplicaten: dezelfde vraag wordt door meerdere gebruikers gesteld, of dezelfde batch-job verwerkt overlappende data. Met een cache sla je de response van een aanroep op en retourneer je die bij dezelfde invoer zonder opnieuw de API aan te roepen.
Let op: caching is alleen zinvol voor deterministische of bijna-deterministische aanroepen. Als je temperature op 0 staat en de prompt niet verandert, is de output identiek. Bij hogere temperatures varieert de output en is caching minder effectief.
Als je applicatie meerdere gebruikers bedient, is het verstandig om per gebruiker een eigen limiet in te stellen. Dit voorkomt dat één heavy user alle quota opgebruikt ten koste van anderen. Je kunt limieten instellen op basis van abonnementsniveau, gebruiksgeschiedenis of een fair-use beleid.
Houd bij hoeveel tokens en aanroepen je per dag verbruikt. De meeste providers bieden een dashboard, maar het is beter om dit ook zelf bij te houden in je eigen logging. Zo zie je trends, kun je anomalieën signaleren, en weet je wanneer je je limieten moet verhogen.
Stel alerts in als je de 80% van je dagelijkse quota bereikt. Dat geeft je tijd om bij te sturen voordat je tegen een harde limiet aanloopt.
Rate limiting en throttling zijn geen bijzaken maar fundamentele aspecten van een stabiele AI-applicatie. Bij Mach8 houden we bij elk project rekening met API-limieten, en bouwen we wachtrijen en monitoring in zodat onze klanten nooit voor verrassingen komen te staan.
Wil je weten hoe Mach8 schaalbare AI-systemen bouwt? Bekijk onze AI-agents service of neem contact op.
Wij helpen je van strategie naar implementatie. Plan een vrijblijvend gesprek.
Plan een gesprek