Kopen, bouwen of zelf algoritme: de drie routes naar LLM-routing

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

Een LLM-gateway centraliseert aanvragen naar verschillende modellen, providers en endpoints. Maar hoe kies je de juiste aanpak? Er zijn drie routes: een kant-en-klare aggregator kopen, zelf een gateway bouwen of een eigen routeringsalgoritme ontwikkelen. Elke route heeft eigen kosten, faalmodi en operationele consequenties. In dit artikel vergelijken we de drie opties op zes criteria: kosten, doorvoer, flexibiliteit, faalgedrag, beveiliging en onderhoud. Aan het eind staat een beslissingsboom die past bij je eigen schaal en risicobereidheid.

Dit artikel hoort bij pijler A2 (Gateway, routing & doorvoerbeheer) en linkt in de eerste paragraaf naar het ankerartikel hoe je zelf een LLM-gateway host, dat de basisarchitectuur uitlegt.

1. De drie routes op een rij

Elke route lost hetzelfde probleem op: je applicatie moet één interface zien, terwijl de gateway aanvragen verdeelt over meerdere modellen, endpoints of providers. De verschillen zitten in wie de logica beheert en wie de infrastructuur draait.

Route 1: Kant-en-klare aggregator kopen

Je integreert met een bestaande dienst die routing, fallback en kostenbeheersing al heeft ingebouwd. Voorbeelden zijn LLM API-aggregators zoals Fireworks, Together AI of de open-source variant LiteLLM. Je stuurt één API-call naar de aggregator, die de aanvraag doorzet naar de juiste provider en het antwoord teruggeeft. De aggregator factureert je op basis van verbruik en rekent vaak een opslagpercentage.

Voordelen: je hebt binnen een dag een werkende oplossing zonder zelf infrastructuur te beheren. Nadelen: je betaalt een marge bovenop de providerkosten, en je bent afhankelijk van de uptime en prijsmodellen van de aggregator zelf.

Route 2: Zelf een gateway bouwen

Je ontwikkelt een eigen proxy die aanvragen ontvangt, valideert, routeert en de antwoorden teruggeeft. De gateway draait op je eigen infrastructuur (cloud of on-premise) en je beheert zelf de sleutels, rate limits en fallback-logica. Voorbeelden van open-source bouwstenen zijn llm-gateway (Python), bentoML of een eigen implementatie met FastAPI en Redis voor rate limiting.

Voordelen: volledige controle over routing, kosten en beveiliging. Nadelen: je moet zelf de infrastructuur beheren, updates doorvoeren en storingen oplossen. Een eigen gateway bouwen is pas rendabel vanaf enkele duizenden aanvragen per dag.

Route 3: Eigen routeringsalgoritme ontwikkelen

Je bouwt niet alleen de infrastructuur, maar ook het beslissingsmechanisme dat bepaalt welk model of welke provider een aanvraag krijgt. Het algoritme kan rekening houden met kosten, latency, beschikbaarheid, taaktype en zelfs de inhoud van de prompt. Voorbeelden zijn een kostengebaseerde router die altijd het goedkoopste beschikbare model kiest, of een latency-gebaseerde router die aanvragen naar het snelste endpoint stuurt.

Voordelen: maximale flexibiliteit en optimalisatie voor je specifieke use case. Nadelen: complexe ontwikkeling, onderhoud en het risico dat het algoritme onbedoelde neveneffecten heeft (bijvoorbeeld dat één provider altijd overbelast raakt).

2. Kosten: wat betaal je per route?

De kosten van LLM-routing bestaan uit drie onderdelen: providerkosten, gatewaykosten en operationele kosten. Elke route heeft een ander kostenprofiel.

Kosten bij een kant-en-klare aggregator

Je betaalt de aggregator een opslagpercentage bovenop de providerkosten. Bijvoorbeeld: als de provider €0,01 per 1000 tokens rekent, rekent de aggregator €0,012. Daarnaast kunnen er vaste kosten zijn voor premium features zoals dedicated endpoints of prioriteitsondersteuning. De aggregator factureert je maandelijks op basis van verbruik, dus je hebt geen upfront kosten.

Voorbeeldberekening: bij 1 miljoen tokens per maand en een opslag van 20% betaal je €12 in plaats van €10 aan de provider. De aggregator neemt je wel de kosten van infrastructuur en onderhoud uit handen.

Kosten bij een zelfgebouwde gateway

Je betaalt alleen de providerkosten, maar je hebt wel eigen infrastructuurkosten. Een gateway draaien op een cloudprovider zoals AWS of GCP kost tussen €50 en €200 per maand, afhankelijk van het aantal requests en de benodigde resources. Daarnaast zijn er ontwikkelkosten: het bouwen van de gateway kost enkele weken ontwikkeltijd, en onderhoud (updates, monitoring, bugfixes) kost doorlopend tijd.

Voorbeeldberekening: bij 1 miljoen tokens per maand betaal je alleen de providerkosten (€10), maar je hebt wel €100 aan cloudkosten en €500 aan ontwikkeltijd. Vanaf ongeveer 5 miljoen tokens per maand is een eigen gateway goedkoper dan een aggregator.

Kosten bij een eigen routeringsalgoritme

De kosten zijn vergelijkbaar met een zelfgebouwde gateway, maar met extra ontwikkelkosten voor het algoritme. Een routeringsalgoritme bouwen kost meer tijd dan een eenvoudige gateway, en het onderhoud is complexer omdat het algoritme voortdurend geoptimaliseerd moet worden. Daarnaast kunnen er extra kosten zijn voor monitoring en logging, omdat je het gedrag van het algoritme continu moet volgen.

Voorbeeldberekening: bij 1 miljoen tokens per maand betaal je €10 aan providerkosten, €100 aan cloudkosten en €1000 aan ontwikkelkosten voor het algoritme. Pas bij zeer hoge volumes (10+ miljoen tokens per maand) of complexe use cases wordt een eigen algoritme rendabel.

3. Doorvoer: hoeveel requests kun je verwerken?

De doorvoer van je routingoplossing bepaalt hoeveel aanvragen je per seconde kunt verwerken. Dit hangt af van de infrastructuur en de efficiëntie van de routinglogica.

Doorvoer bij een kant-en-klare aggregator

Aggregators zijn gebouwd voor schaal en kunnen duizenden requests per seconde verwerken. De doorvoer is meestal alleen beperkt door de rate limits van de onderliggende providers. Bijvoorbeeld: als je een aggregator gebruikt die aanvragen verdeelt over drie providers met elk een rate limit van 100 requests per seconde, kun je in theorie 300 requests per seconde verwerken. In de praktijk ligt dit lager door overhead en netwerklatency.

Voordelen: je hoeft zelf niets te schalen. Nadelen: je bent afhankelijk van de uptime van de aggregator, en bij piekbelasting kunnen er vertragingen optreden.

Doorvoer bij een zelfgebouwde gateway

De doorvoer van een zelfgebouwde gateway hangt af van de infrastructuur waarop je hem draait. Een gateway die op een enkele server draait kan enkele honderden requests per seconde verwerken, terwijl een gedistribueerde gateway op Kubernetes of AWS Lambda duizenden requests per seconde aankan. Je kunt de doorvoer verhogen door meer resources toe te voegen, maar dit verhoogt ook de kosten.

Voorbeeld: een gateway gebouwd met FastAPI en Redis voor rate limiting kan op een t3.medium-instance (AWS) ongeveer 200 requests per seconde verwerken. Door horizontaal te schalen naar drie instances kun je dit verhogen naar 600 requests per seconde.

Doorvoer bij een eigen routeringsalgoritme

Een eigen routeringsalgoritme voegt complexiteit toe aan de gateway, wat de doorvoer kan verminderen. Het algoritme moet voor elke aanvraag beslissen naar welke provider het wordt gestuurd, wat extra berekeningen en latency veroorzaakt. In het beste geval is de impact minimaal (enkele milliseconden per request), maar bij complexe algoritmen kan de latency oplopen tot tientallen milliseconden.

Voorbeeld: een kostengebaseerd routeringsalgoritme dat voor elke aanvraag de prijzen van alle providers opvraagt, kan de latency met 50 ms verhogen. Bij 100 requests per seconde betekent dit 5 seconden extra vertraging per seconde.

4. Flexibiliteit: hoe snel kun je aanpassen?

Flexibiliteit bepaalt hoe snel je kunt reageren op veranderingen, zoals nieuwe modellen, prijswijzigingen of gewijzigde use cases. Elke route biedt een andere mate van flexibiliteit.

Flexibiliteit bij een kant-en-klare aggregator

Aggregators bieden beperkte flexibiliteit. Je kunt meestal kiezen uit een vooraf gedefinieerde set providers en modellen, en de routinglogica is vaak beperkt tot eenvoudige fallback-mechanismen. Als je een specifiek model of een aangepaste routingstrategie nodig hebt, ben je afhankelijk van de ondersteuning van de aggregator.

Voorbeeld: als een aggregator alleen OpenAI en Anthropic ondersteunt, kun je geen aanvragen naar een lokaal draaiend model sturen. Je moet wachten tot de aggregator het model toevoegt of overstappen naar een andere aggregator.

Flexibiliteit bij een zelfgebouwde gateway

Een zelfgebouwde gateway biedt volledige flexibiliteit. Je kunt elke provider en elk model integreren, en je kunt de routinglogica volledig aanpassen aan je use case. Je kunt bijvoorbeeld een fallback-mechanisme bouwen dat aanvragen naar een lokaal model stuurt als de cloudproviders niet beschikbaar zijn, of een prioriteitswachtrij implementeren voor kritieke taken.

Voorbeeld: als je een nieuw model wilt toevoegen, hoef je alleen een nieuwe endpointconfiguratie toe te voegen aan je gateway. Je kunt ook de rate limits per provider aanpassen of nieuwe validatieregels toevoegen.

Flexibiliteit bij een eigen routeringsalgoritme

Een eigen routeringsalgoritme biedt de hoogste mate van flexibiliteit. Je kunt het algoritme volledig aanpassen aan je use case, bijvoorbeeld door rekening te houden met de inhoud van de prompt, de geschiedenis van de gebruiker of realtime prestatiemetingen. Je kunt ook dynamisch schakelen tussen modellen op basis van kosten, latency of beschikbaarheid.

Voorbeeld: je kunt een algoritme bouwen dat aanvragen voor klantenservice naar een goedkoop model stuurt, maar aanvragen voor juridisch advies naar een duurder, maar nauwkeuriger model. Je kunt ook het algoritme aanpassen om rekening te houden met nieuwe prijsmodellen of providerlimieten.

5. Faalgedrag: wat gebeurt er bij storingen?

Faalgedrag bepaalt hoe je routingoplossing reageert op storingen, zoals uitval van een provider, netwerkproblemen of rate limit overschrijdingen. Elke route heeft eigen faalmodi en mitigatiestrategieën.

Faalgedrag bij een kant-en-klare aggregator

Aggregators hebben meestal ingebouwde fallback-mechanismen. Als een provider niet beschikbaar is, stuurt de aggregator de aanvraag automatisch door naar een andere provider. Dit werkt goed voor eenvoudige use cases, maar bij complexe storingen (bijvoorbeeld als alle providers rate limits bereiken) kan de aggregator zelf onbereikbaar worden.

Voorbeeld: als OpenAI uitvalt, stuurt de aggregator aanvragen door naar Anthropic. Maar als beide providers rate limits bereiken, kan de aggregator zelf een 503 Service Unavailable retourneren. Je hebt geen controle over de fallback-logica en kunt niet zelf bepalen welke provider prioriteit krijgt.

Faalgedrag bij een zelfgebouwde gateway

Een zelfgebouwde gateway geeft je volledige controle over het faalgedrag. Je kunt zelf bepalen welke fallback-strategieën je implementeert, zoals retry-logica, circuit breakers of graceful degradation. Je kunt ook prioriteitswachtrijen implementeren voor kritieke taken, zodat deze altijd als eerste worden verwerkt.

Voorbeeld: je kunt een circuit breaker implementeren die na drie mislukte aanvragen naar een provider automatisch overschakelt naar een fallback-provider. Je kunt ook een prioriteitswachtrij bouwen die ervoor zorgt dat klantenserviceaanvragen altijd voorrang krijgen, zelfs als de gateway overbelast is. Meer over deze patronen lees je in het artikel over graceful degradation bij LLM-uitval.

Faalgedrag bij een eigen routeringsalgoritme

Een eigen routeringsalgoritme kan het faalgedrag verder optimaliseren door dynamisch te schakelen tussen providers op basis van realtime prestatiemetingen. Bijvoorbeeld: als een provider traag reageert, kan het algoritme automatisch overschakelen naar een snellere provider. Het algoritme kan ook rekening houden met de inhoud van de prompt, zodat kritieke aanvragen altijd naar de meest betrouwbare provider gaan.

Voorbeeld: je kunt een latency-gebaseerd algoritme bouwen dat elke seconde de responstijden van alle providers meet. Als een provider trager wordt dan 500 ms, schakelt het algoritme automatisch over naar een snellere provider. Dit vereist wel uitgebreide monitoring en logging, zoals beschreven in het artikel over observability en logging voor LLM-toepassingen.

6. Beveiliging: wie beheert de sleutels?

Beveiliging is cruciaal bij LLM-routing, omdat je te maken hebt met API-sleutels, gebruikersgegevens en gevoelige prompts. Elke route heeft eigen risico's en mitigerende maatregelen.

Beveiliging bij een kant-en-klare aggregator

Bij een aggregator beheer je zelf geen provider-sleutels, maar je moet wel een sleutel voor de aggregator beheren. De aggregator beheert de provider-sleutels en zorgt voor encryptie van gegevens in transit. Het risico is dat je afhankelijk bent van de beveiligingspraktijken van de aggregator. Als de aggregator gehackt wordt, kunnen je gegevens en sleutels in verkeerde handen komen.

Voorbeeld: als je een aggregator gebruikt, hoef je geen OpenAI-sleutel in je eigen codebase op te slaan. Maar je moet wel een sleutel voor de aggregator beheren, en als die sleutel lekt, kan een aanvaller namens jou aanvragen doen bij de aggregator.

Beveiliging bij een zelfgebouwde gateway

Bij een zelfgebouwde gateway beheer je zelf alle provider-sleutels. Dit geeft je volledige controle over de beveiliging, maar het betekent ook dat je zelf verantwoordelijk bent voor het veilig opslaan en beheren van de sleutels. Je moet maatregelen nemen zoals encryptie van sleutels in rust, beperkte toegang tot de sleutelopslag en audit-logging van sleutelgebruik.

Voorbeeld: je kunt de sleutels opslaan in een secrets manager zoals AWS Secrets Manager of HashiCorp Vault. Je kunt ook rate limiting en IP-whitelisting implementeren om misbruik te voorkomen. Meer over veilig sleutelbeheer lees je in het artikel hoe je API-sleutels voor LLM's veilig beheert.

Beveiliging bij een eigen routeringsalgoritme

Een eigen routeringsalgoritme voegt complexiteit toe aan de beveiliging. Het algoritme moet toegang hebben tot de provider-sleutels en mogelijk ook tot gebruikersgegevens of prompts. Je moet ervoor zorgen dat het algoritme geen gevoelige gegevens lekt, bijvoorbeeld via logging of foutmeldingen. Daarnaast moet je het algoritme beschermen tegen manipulatie, bijvoorbeeld door prompt injectie of denial-of-service-aanvallen.

Voorbeeld: als je algoritme rekening houdt met de inhoud van de prompt, moet je ervoor zorgen dat de prompt niet wordt opgeslagen of gelogd. Je moet ook validatieregels implementeren om te voorkomen dat een aanvaller het algoritme manipuleert, bijvoorbeeld door een prompt te sturen die het algoritme dwingt om een duur model te kiezen. Meer over invoervalidatie lees je in het artikel over invoervalidatie en outputfiltering.

7. Onderhoud: wie lost problemen op?

Onderhoud omvat alles wat nodig is om je routingoplossing operationeel te houden: updates, monitoring, bugfixes en documentatie. Elke route heeft eigen onderhoudsvereisten.

Onderhoud bij een kant-en-klare aggregator

Bij een aggregator hoef je zelf niets te onderhouden. De aggregator zorgt voor updates, monitoring en bugfixes. Je hoeft alleen je eigen integratie te onderhouden, bijvoorbeeld door nieuwe API-versies te implementeren of je code aan te passen aan gewijzigde rate limits.

Voordeel: je hebt geen operationele last. Nadeel: je bent afhankelijk van de reactiesnelheid van de aggregator. Als er een storing is, moet je wachten tot de aggregator het oplost.

Onderhoud bij een zelfgebouwde gateway

Bij een zelfgebouwde gateway ben je zelf verantwoordelijk voor het onderhoud. Je moet de gateway up-to-date houden met beveiligingsupdates, nieuwe provider-API's en wijzigingen in je eigen infrastructuur. Daarnaast moet je monitoring en logging implementeren om problemen snel te detecteren en op te lossen.

Voorbeeld: als OpenAI een nieuwe API-versie uitbrengt, moet je je gateway aanpassen om die versie te ondersteunen. Je moet ook regelmatig de rate limits van alle providers controleren en je gateway aanpassen als die veranderen. Meer over monitoring lees je in het artikel over observability en logging.

Onderhoud bij een eigen routeringsalgoritme

Een eigen routeringsalgoritme vereist het meeste onderhoud. Je moet niet alleen de gateway onderhouden, maar ook het algoritme zelf. Het algoritme moet voortdurend geoptimaliseerd worden op basis van nieuwe gegevens, bijvoorbeeld als de prestaties van een provider veranderen of als er nieuwe modellen beschikbaar komen. Daarnaast moet je het algoritme monitoren om te voorkomen dat het onbedoelde neveneffecten heeft, zoals het overbelasten van één provider.

Voorbeeld: als een provider een nieuw prijsmodel introduceert, moet je je algoritme aanpassen om rekening te houden met de nieuwe kosten. Je moet ook regelmatig de prestaties van het algoritme evalueren, bijvoorbeeld door A/B-tests uit te voeren tussen verschillende routeringsstrategieën.

8. Beslissingsboom: welke route past bij jou?

De juiste route hangt af van je schaal, budget, risicobereidheid en use case. Gebruik deze beslissingsboom om de beste optie te kiezen:

Voorbeeld 1: een startup met 100.000 requests per maand en een beperkt budget kiest voor een aggregator. De kosten zijn voorspelbaar en er is geen operationele last.

Voorbeeld 2: een SaaS-bedrijf met 5 miljoen requests per maand en een eigen ontwikkelteam bouwt een eigen gateway. De kosten zijn lager dan bij een aggregator en het bedrijf heeft volledige controle over routing en beveiliging.

Voorbeeld 3: een enterprise-organisatie met 50 miljoen requests per maand en een complexe use case (bijvoorbeeld juridisch advies) ontwikkelt een eigen routeringsalgoritme. Het algoritme optimaliseert voor kosten, latency en nauwkeurigheid, en het bedrijf heeft de middelen om het algoritme voortdurend te verbeteren.

9. Conclusie: routing is geen eenmalige keuze

LLM-routing is geen statische beslissing, maar een dynamisch proces dat meegroeit met je use case. Begin met een aggregator als je snel wilt starten, bouw een eigen gateway als je schaal en controle nodig hebt, en ontwikkel een eigen algoritme als je maximale flexibiliteit en optimalisatie wilt. Elke route heeft eigen kosten, faalmodi en operationele consequenties, dus kies bewust en evalueer regelmatig of je huidige oplossing nog past bij je behoeften.

Vergeet niet dat routing niet alleen gaat over het kiezen van een model, maar ook over het beheren van kosten, doorvoer, beveiliging en faalgedrag. Een goede routingoplossing maakt het verschil tussen een betrouwbare, kostenefficiënte LLM-integratie en een onvoorspelbaar, duur systeem. Als je meer wilt weten over de technische details van routing, lees dan het artikel over hoe je meerdere modellen orkestreert.

Voor wie verder wil met embeddings en retrieval: embeddings-API's hebben eigen rate limits en kosten die je apart moet beheren. Lees hierover in het artikel hoe je embedding-modellen evalueert voor zoek- en RAG-toepassingen.