Modelroutering: hoe AI-systemen zelf kiezen welk model jouw vraag beantwoordt
Stel je voor dat je een ziekenhuis binnenloopt met een gebroken vinger. Je wilt niet eerst langs de hartchirurg voordat iemand je doorstuurt naar de juiste afdeling: bij de balie wordt meteen ingeschat wat je nodig hebt, en je wordt direct naar de spoedeisende hulp of de huisartsenpost gestuurd. Modelroutering doet iets vergelijkbaars, maar dan met kunstmatige intelligentie. In plaats van dat elke vraag die je aan een chatbot stelt automatisch naar hetzelfde, vaak zware en dure taalmodel gaat, beoordeelt een systeem eerst hoe lastig of eenvoudig je vraag is en stuurt die daarna door naar het model dat daar het beste bij past.
Achter chatbots als ChatGPT of Copilot draaien namelijk niet één, maar meerdere versies van een taalmodel: een snelle, goedkope variant voor simpele vragen ('wat is de hoofdstad van Portugal?') en een trage, dure maar veel krachtigere variant voor complexe taken ('analyseer deze juridische overeenkomst en wijs tegenstrijdigheden aan'). Modelroutering is de techniek die automatisch beslist welke van die varianten jouw vraag te verwerken krijgt, zonder dat jij als gebruiker daar zelf een knop voor hoeft om te zetten. Het klinkt eenvoudig, maar er zit een hele beslislaag achter die voortdurend probeert de balans te vinden tussen snelheid, kosten en kwaliteit.
Wat is het precies?
In de kern is modelroutering een extra stap die wordt toegevoegd vóórdat je vraag daadwerkelijk door een taalmodel wordt beantwoord. Die stap wordt vaak uitgevoerd door een apart, klein en snel model of algoritme: de router. Deze router leest jouw vraag niet om hem te beantwoorden, maar om in te schatten hoe moeilijk hij is en welk type taak het betreft (een feitenvraag, een rekenprobleem, een creatieve tekst, programmeercode, enzovoort).
Op basis van die inschatting kiest de router uit een lijst beschikbare modellen. Dat kunnen modellen van dezelfde aanbieder zijn (bijvoorbeeld een 'mini'-versie versus een volledige versie van hetzelfde taalmodel), maar in sommige systemen ook modellen van verschillende bedrijven. De keuze wordt meestal gebaseerd op een combinatie van factoren: de verwachte moeilijkheidsgraad van de vraag, de kosten per model (grotere modellen zijn duurder om te draaien), de gewenste snelheid van het antwoord, en soms ook eerdere prestaties van elk model op vergelijkbare vragen.
Sommige routers worden getraind met machine learning: ze krijgen duizenden voorbeelden te zien van vragen samen met een oordeel over welk model daar het beste antwoord op gaf, en leren daaruit een patroon herkennen. Andere systemen werken met eenvoudigere regels, zoals: 'als de vraag korter is dan twintig woorden en geen rekenwerk bevat, stuur hem dan naar het goedkope model'. Er bestaat ook een variant die cascade wordt genoemd: eerst wordt het goedkope model geprobeerd, en alleen als het antwoord onzeker of onvolledig lijkt, wordt de vraag alsnog doorgestuurd naar een zwaarder model.
Wat wil men ermee bereiken?
De belangrijkste drijfveer achter modelroutering is geld. Het draaien van grote taalmodellen kost rekenkracht, en rekenkracht kost elektriciteit en dure computerchips. Een vraag die net zo goed door een klein model beantwoord had kunnen worden, maar toch naar het grootste en duurste model gaat, is in feite verspilling. Voor bedrijven die miljoenen vragen per dag verwerken, kan slimme routering de rekening flink verlagen.
Daarnaast speelt snelheid mee. Grote modellen zijn vaak trager in het genereren van een antwoord dan kleine modellen. Voor een simpele vraag wil een gebruiker niet seconden lang wachten op een antwoord dat een kleiner model net zo goed en veel sneller had kunnen geven. Modelroutering probeert dus ook de gebruikerservaring te verbeteren door onnodige vertraging te voorkomen.
Een derde doel is kwaliteit op de juiste plek inzetten. Niet elk model is overal even goed in: het ene model blinkt uit in programmeercode, het andere in wiskundig redeneren of in het schrijven van vloeiende teksten. Door taken naar het model te sturen dat daar historisch gezien het beste in scoort, kan de kwaliteit van antwoorden omhooggaan zonder dat de gebruiker zelf hoeft te weten welk model voor welke taak geschikt is. Tot slot speelt ook energieverbruik een rol: minder onnodig gebruik van zware modellen betekent minder stroomverbruik, wat relevant is nu datacenters voor AI een steeds groter beslag leggen op het elektriciteitsnet.
Voorbeelden uit de praktijk
Een van de meest zichtbare toepassingen kwam in augustus 2025, toen OpenAI zijn model GPT-5 lanceerde. Een centraal onderdeel van dat systeem is een interne router die per vraag automatisch beslist of een snel, direct model volstaat, of dat de vraag wordt doorgestuurd naar een tragere variant die meer tijd neemt om stap voor stap te 'redeneren' voordat hij antwoordt. Gebruikers zien in de gewone ChatGPT-interface doorgaans niet welk onderliggend model precies actief is; de keuze gebeurt automatisch op de achtergrond.
In de academische wereld publiceerde een onderzoeksgroep verbonden aan LMSYS (het collectief achter het bekende Chatbot Arena-platform van UC Berkeley) in 2024 een open source project genaamd RouteLLM. Dit framework werd getraind op grote hoeveelheden menselijke voorkeursdata (welk antwoord vinden mensen beter) en probeert te voorspellen wanneer een goedkoop model 'goed genoeg' is en wanneer een duurder model nodig is. De onderzoekers claimden aanzienlijke kostenbesparingen bij een beperkt kwaliteitsverlies, al zijn dit soort percentages sterk afhankelijk van de gebruikte testomgeving en dus met enige voorzichtigheid te lezen.
Ook grote clouddienstverleners bouwen dit soort functionaliteit in hun platforms in. Microsoft introduceerde in zijn Azure AI Foundry-platform een 'model router'-functie, waarmee ontwikkelaars een vraag automatisch laten routeren tussen verschillende beschikbare taalmodellen op basis van kosten en verwachte prestaties, in plaats van dat de ontwikkelaar zelf handmatig één vast model kiest.
Daarnaast zijn er kleinere, gespecialiseerde start-ups die volledig op dit idee zijn gebouwd. Martian, een start-up voortgekomen uit het Amerikaanse Y Combinator-programma, ontwikkelt een 'model router' die per binnenkomende vraag voorspelt welk beschikbaar taalmodel waarschijnlijk het beste resultaat tegen de laagste kosten zal geven. Een vergelijkbaar bedrijf, Not Diamond, biedt eveneens een routeringsdienst aan die ontwikkelaars kunnen aanroepen om automatisch tussen meerdere taalmodellen te schakelen. Het platform OpenRouter wordt in dit verband ook vaak genoemd, al is dat strikt genomen eerder een marktplaats en gestandaardiseerde toegangspoort tot tientallen modellen van verschillende aanbieders, met simpele terugval-opties als een model niet beschikbaar is, dan een geavanceerd routeringssysteem dat per vraag de kwaliteit voorspelt.
Hoe ver is de techniek?
Modelroutering is een relatief jong onderzoeksveld dat in hoog tempo is gegroeid sinds 2023 en 2024, parallel aan de opkomst van steeds meer verschillende taalmodellen naast elkaar. De inzet van een expliciete router op grote, publieke schaal, zoals bij GPT-5 in 2025, is nog vrij nieuw en kan gezien worden als een van de eerste keren dat dit idee buiten onderzoekslabs en nichetoepassingen een breed publiek bereikte.
De techniek kent nog duidelijke haken en ogen. Ten eerste kost het beoordelen van een vraag door de router zelf ook tijd en rekenkracht; als die stap te zwaar wordt, verdwijnt een deel van de beoogde snelheids- en kostenwinst. Ten tweede is het lastig om objectief te meten of een routeringsbeslissing 'goed' was: wat het ene model beter beantwoordt, hangt vaak af van smaak, context of het specifieke onderwerp, en er bestaat geen universele maatstaf voor 'de beste' beantwoording. Ten derde is er een risico op verkeerde inschattingen bij grensgevallen: een vraag die er eenvoudig uitziet maar eigenlijk een addertje onder het gras heeft, kan ten onrechte naar een te licht model worden gestuurd, met een minder goed antwoord als gevolg.
Een ander punt van discussie is transparantie. Gebruikers weten meestal niet welk onderliggend model hun vraag daadwerkelijk heeft beantwoord, wat het lastiger maakt om de kwaliteit of betrouwbaarheid van een antwoord te beoordelen of te reproduceren. Benchmarks en gestandaardiseerde manieren om routeringssystemen onderling te vergelijken staan bovendien nog in de kinderschoenen; veel claims over kostenbesparing zijn afkomstig van de bedenkers van een systeem zelf, en onafhankelijke, herhaalde verificatie is nog schaars.
Wie werken eraan?
Aan de kant van de grote AI-bedrijven werkt vooral OpenAI zichtbaar aan routering, met het systeem in GPT-5 als meest bekende voorbeeld. Microsoft bouwt vergelijkbare functionaliteit in zijn Azure AI-cloudplatform, gericht op zakelijke ontwikkelaars. Bij Google is er tot nu toe geen even expliciet publiek bekend 'automatisch router'-systeem voor de Gemini-modellen; daar kiezen ontwikkelaars doorgaans zelf tussen varianten zoals een snellere 'Flash'-versie en een krachtigere 'Pro'-versie, al is niet uit te sluiten dat er achter de schermen ook vormen van automatische taakverdeling plaatsvinden.
In de academische hoek is LMSYS, verbonden aan de University of California, Berkeley, een van de zichtbaarste spelers dankzij het RouteLLM-project en het Chatbot Arena-platform waarop veel routeringsonderzoek leunt. Onderzoekspapers over dit onderwerp verschijnen geregeld op het preprint-platform arXiv, waar academici uit uiteenlopende universiteiten wereldwijd hun bevindingen delen nog voordat die formeel gepubliceerd zijn.
Daarnaast is er een groeiend aantal gespecialiseerde start-ups dat volledig op modelroutering is gebouwd, waaronder de eerder genoemde Martian en Not Diamond, vaak gefinancierd door durfkapitaal uit de Amerikaanse techsector. Ook platforms als OpenRouter spelen een rol in het bredere ecosysteem, ook al ligt hun nadruk meer op toegankelijkheid tot veel modellen dan op geavanceerde, per-vraag routeringsintelligentie. Voor zover bekend is er geen sprake van één dominante internationale standaard; het veld wordt vooral gedreven door individuele bedrijven die elk hun eigen aanpak ontwikkelen.