LLM-routing en cascading: goedkoop model voor lichte taken, sterk model voor zware

Een van de eerste dingen die u opvalt na het uitrollen van een LLM naar productie, is de spreiding in complexiteit van de queries. Sommige zijn triviaal — een getal uit een tekst extraheren, een adres herformatteren, een formaat valideren. Andere zijn werkelijk complex — meerstaps redeneren, synthese over meerdere documenten, juridische analyse. Het probleem is dat de meeste systemen al deze queries naar hetzelfde model sturen. U betaalt voor een frontier-model, ook als het een vraag beantwoordt die een model voor een tiende van de prijs moeiteloos aankon.

LLM-routing lost precies dit op. Het idee is eenvoudig: schat vóór elke LLM-aanroep in hoe zwaar de taak is, en stuur die naar het goedkoopste model dat haar betrouwbaar aankan. Roep het sterke model alleen aan als de situatie dat werkelijk vereist. In de praktijk gaat 75–90 % van de aanroepen naar het goedkopere model en dalen de totale kosten zonder merkbare kwaliteitsdaling voor de meeste toepassingen.

Wat is routing en wat is cascading

Routing (routering) is een beslissing vóór de eerste aanroep: kies op basis van de invoer een model. Een classifier beoordeelt de query en stuurt die naar een klein model of rechtstreeks naar het sterke model.

Cascading (kaskading) voegt een extra stap toe: stuur de query eerst naar het goedkope model en beoordeel het antwoord — als dat voldoende zelfvertrouwen toont (betrouwbaarheidsscore, consistentie, formaat), geeft u het terug aan de gebruiker. Zo niet, escaleert u automatisch naar een sterker model en betaalt u daarvoor alleen in dat geval. Beide benaderingen zijn te combineren: de router bepaalt het startmodel, de kaskade bepaalt de escalatie.

Het kernverschil: routing is proactief (classificatie vóór de aanroep), cascading is reactief (escalatie ná de aanroep, wanneer de uitvoer tekortschiet).

Waarom het werkt — verdeling van complexiteit in de praktijk

In de productiesystemen die we analyseerden geldt globaal de volgende verdeling:

• 30–40 % van de queries is routinematig — extractie, classificatie, herformattering, eenvoudige opzoeking. Dit is aanpakbaar voor een klein model, zoals uit de Phi- of Gemma-familie, of een goedkope tier van frontier-providers.
• 40–50 % van de queries heeft middelhoge complexiteit — samenvatting van langere tekst, eenvoudig redeneren, antwoorden op FAQ met context. Een middelgroot model volstaat hier.
• 10–20 % van de queries is werkelijk zwaar — complexe analyses, multi-hop redeneren, codegeneratie met ongebruikelijke vereisten, gevoelige beslissingen. Deze verdienen een frontier-model.

Als u alles naar het frontier-model stuurt, betaalt u de prijs van het sterke model voor elke query — inclusief die 30–40 % routineuze gevallen. Frontier-modelprijzen (bijv. de klasse Claude Opus, GPT-5.x) liggen in de orde van ~$15–25 per miljoen uitvoertokens, terwijl de goedkope tier (Flash/Haiku-equivalenten) onder de $1–2 zit. Het verschil is een factor 15–25. Zelfs bij bescheiden routing, waarbij het kleine model slechts de helft van de queries afhandelt, kunnen de kosten met 40–60 % dalen.

Het academische project RouteLLM (LMSYS / UC Berkeley) toonde aan dat een goed getrainde router het merendeel van de eenvoudige queries naar het goedkope model kan sturen met behoud van grotendeels de kwaliteit van het sterke model — in hun metingen betekende dit een kostenbesparing in de orde van ~85 % bij behoud van een wezenlijk deel van de prestaties van het sterke model. De exacte cijfers hangen af van de samenstelling van de queries en de kalibratie van de router.

Hoe de complexiteitsclassifier werkt

Het hart van de router is de classifier, die op basis van de invoer bepaalt waar die naartoe gestuurd wordt. Er zijn meerdere benaderingen met verschillende trade-offs:

1. Eenvoudige heuristische router

Invoerlengte, trefwoorden, taaktype (extractie vs. generatie vs. analyse). Dit werkt verrassend goed voor systemen met een beperkte use case en duidelijk onderscheiden querytypen. Nul overhead, deterministisch gedrag. Nadeel: fragiel, vereist handmatige regels, past zich niet aan aan randgevallen.

2. Embedding-gebaseerde router

De query wordt geëmbedded (bijv. met een klein BGE-model) en vergeleken met representatieve voorbeelden uit elk tier. Als de query dicht bij de steekproef van lichte taken ligt, gaat die naar het goedkope model. Het embedding-model draait lokaal, de overhead is minimaal (~5–15 ms). Voordeel: vereist geen training van een classifier, eenvoudig uit te breiden met nieuwe voorbeelden.

3. Getrainde binaire classifier

Een klein model (logistieke regressie of een kleine transformer) getraind om te voorspellen of een query een sterk model vereist. RouteLLM biedt precies deze aanpak met voorgetrainde classifiers. Voordeel: hoge nauwkeurigheid na kalibratie op eigen data. Nadeel: vereist een trainingsset met annotaties en doorlopende updates.

4. LLM-as-a-judge router

Het goedkope model beoordeelt zelf of een query complex is. Paradoxaal, maar in de praktijk werkzaam — een goedkoop model kan "dit is een eenvoudige extractie" onderscheiden van "dit is een complexe analyse", ook al kan het die complexe analyse zelf niet goed uitvoeren. Overhead: één korte extra LLM-aanroep. Geschikt voor systemen met kaskading.

Voor de meeste productiesystemen raden we aan te beginnen met een embedding-gebaseerde of eenvoudige heuristische router. Voeg een getrainde classifier toe zodra u voldoende operationele logs hebt om mee te trainen — in de orde van duizenden geannoteerde voorbeelden.

Praktisch kaskadepatroon

Cascading ziet er in de praktijk als volgt uit:

1. 1.De query komt het systeem binnen.
2. 2.Het kleine model genereert een antwoord én een betrouwbaarheidsscore (confidence).
3. 3.Als de score de drempelwaarde overschrijdt (bijv. 0.85), wordt het antwoord aan de gebruiker teruggegeven.
4. 4.Zo niet, wordt dezelfde query naar het middelgrote of sterke model gestuurd en wordt het resultaat daarvan teruggegeven.

De betrouwbaarheidsscore is op meerdere manieren af te leiden:

• Log-probabiliteit van tokens — de gemiddelde log-kans van de gegenereerde tokens. Een lage waarde geeft aan dat het model "twijfelde". Beschikbaar in serving frameworks als vLLM of SGLang via de parameter logprobs.
• Consistentie bij sampling — genereer 3–5 verschillende antwoorden (hogere temperatuur) en meet de overeenkomst. Als het model zichzelf tegenspreekt, escaleert u.
• Verificatieprompt — een secundaire aanroep (met het goedkope model): "Is dit antwoord correct en volledig? Antwoord alleen met ja/nee."

De escalatiedrempel is een sleutelparameter die u moet kalibreren voor uw specifieke use case. Een te hoge drempel leidt tot veel onnodige escalaties en verliest de kostenbesparing. Een te lage drempel laat het kleine model antwoorden op zaken die het niet aankan, waardoor de kwaliteit daalt.

Voor systemen met een duidelijk afgebakende taak (bijv. documentclassificatie in categorieën, extractie van gestructureerde data) is kaskading bijzonder effectief — het kleine model handelt 80–90 % van de gevallen af, het sterke model ontvangt alleen de werkelijk dubbelzinnige. Voor generatieve use cases (vrije tekst, creatief schrijven, complexe antwoorden op open vragen) is kaskading moeilijker af te stellen, omdat de "juistheid" van een antwoord lastig automatisch te beoordelen is.

De kosten van routing — die zijn er wel degelijk

Routing is niet gratis en het is belangrijk de eigen kosten mee te rekenen:

• Extra latentie — elke classificatieaanroep voegt tijd toe. Embedding-gebaseerde router: ~5–15 ms. LLM-as-a-judge: 50–200 ms. Voor realtime interactieve applicaties kan dit merkbaar zijn.
• Kaskade bij verkeerde classificatie — als het kleine model een zware query beantwoordt en het antwoord onjuist is, betaalt u voor twee aanroepen (klein + sterk) in plaats van één. Foutieve classificatie verlaagt de kosten dus niet, maar verhoogt ze.
• Operationele complexiteit — de router is een extra component in het systeem dat kan falen, verslechteren en dat u moet monitoren en bijwerken.
• Cold-start probleem — een nieuwe router zonder historische data classificeert slecht. De eerste weken kunnen slechter presteren dan een single-model strategie.

Routing werkt daarom het best in systemen met een hoog volume, heterogene queries en een duidelijk onderscheid tussen lichte en zware taken. Als u honderd queries per dag hebt en alle ruwweg even complex zijn, levert de overhead van de router geen zinvolle besparing op.

Beantwoord vóór de uitrol de vraag: wat is de werkelijke complexiteitsverdeling van uw queries? Hebt u geen data, besteed dan twee weken aan logging en handmatige annotatie van een steekproef van 200–300 queries. Deze oefening onthult ook andere problemen — bijvoorbeeld dat 40 % van de aanroepen dezelfde lange systeemprompt bevat, waarbij prompt caching meer bespaart dan routing.

Wanneer routing niet volstaat en wat dan beter werkt

Routing adresseert één aspect van de kosten — de modelkeuze. Er zijn situaties waarin een andere optimalisatie effectiever is:

Herhalende prefix-prompts → Prompt caching is doorgaans de sterkere maatregel. Als 80 % van uw aanroepen dezelfde systeemprompt van 3.000 tokens deelt, verlaagt prompt caching bij Anthropic de kosten van die tokens met 90 %. Routing zou hetzelfde probleem niet oplossen.

Oplopende kosten door een agent met lange geschiedenis → Hierbij helpt het verkorten van de context en samenvatten, niet routing. Zie kosten van een AI-agent in productie.

Trage respons bij hoge belasting → Hier is routing ook slechts een gedeeltelijk antwoord. De keuze van het serving framework (vLLM vs. Ollama), continuous batching en de KV-cachegrootte hebben een grotere impact op de throughput.

Routeren op inhoud, niet op complexiteit → Een andere use case: sommige queries moeten naar een model gaan dat getraind is op een specifiek domein (bijv. een fine-tuned model voor productiedocumentatie), andere naar een generalistisch model. Dit is content-based routing en is een afzonderlijke architectuurlaag, los van kostenoptimalisatie.

Implementatie: waar te beginnen

Wilt u routing uitproberen, dan is dit de volgorde die we aanraden:

1. 1.Verzamel data voordat u iets implementeert. Log queries met metadata — lengte, taaktype, responstijd, kwaliteitsscore (indien beschikbaar). Zonder data kalibreert u elke router op goed geluk.

1. 1.Begin met een heuristische router op de meest voor de hand liggende splitsing. Als u weet dat 30 % van uw queries classificaties in vier categorieën zijn en 70 % generatief, levert een eenvoudige regel "als type=classificatie → klein model" een directe besparing zonder ML-overhead.

1. 1.Test de kwaliteit van het kleine model op echte data. Vertrouw niet op benchmarkcijfers. Neem 100 echte queries uit uw productieomgeving, draai ze door het kleine model en beoordeel handmatig. U ontdekt waar het model tekortschiet en waar het verrast.

1. 1.Implementeer kaskading met logprob-drempelwaarden. vLLM en SGLang stellen allebei log-kansen van tokens beschikbaar. Stel de drempel experimenteel in: begin bij 0.80, meet escalaties en fout-positieven.

1. 1.Monitor de verdeling van escalaties in de tijd. Als het aandeel escalaties groeit, verandert ofwel de aard van de queries, ofwel het kleine model verslechtert op een bepaalde categorie. Een router heeft doorlopende kalibratie nodig — het is geen "instellen en vergeten".

Voor een open-source startpunt is RouteLLM van LMSYS / UC Berkeley (Apache 2.0) een goede basis — het levert voorgetrainde classifiers en een evaluatieharness. Voor enterprise-uitrol met vereiste on-prem-werking is de embedding-gebaseerde aanpak met BGE-M3-embeddings en de lokale vectoropslag Qdrant praktischer vanuit het oogpunt van datasoevereiniteit.

Wanneer routing niet te doen

Ondanks de besparingen heeft routing reële contra-indicaties:

• Laag volume (minder dan enkele duizenden queries per dag) — de implementatie- en onderhoudsoverhead overtreft de besparing.
• Homogene use case — als alle queries even complex zijn (bijv. uitsluitend complexe juridische analyse), voegt routing alleen complexiteit toe zonder voordeel.
• Hoge foutkosten — in gereguleerde omgevingen waar zelfs een gedeeltelijk onjuist antwoord van het goedkope model problemen veroorzaakt (gezondheidszorg, compliance, juridische beslissingen), is kaskading risicovoller. Hier is het veiliger een beperkte set taken voor het kleine model te definiëren met 100 % handmatige verificatie.
• Modelniet-determinisme bij escalatie — als uw applicatie reproduceerbaarheid vereist (dezelfde query altijd hetzelfde antwoord), compliceert kaskading dat: soms antwoordt het kleine model, soms het sterke, en de uitvoer verschilt.

Veelgestelde vragen

Hoe weet ik of ik genoeg diversiteit in queries heb om routing de moeite waard te maken?

Exporteer een steekproef van 200–300 echte queries en classificeer ze handmatig in drie groepen: licht, middel, zwaar. Als meer dan 30 % in de categorie "licht" valt, levert routing een meetbare besparing op. Als de verdeling gelijkmatig is of naar "zwaar" neigt, is het effect marginaal.

Hoe verschilt routing van load balancing tussen meerdere instanties van hetzelfde model?

Load balancing richt zich op throughput en beschikbaarheid — het verdeelt verzoeken over meerdere instanties van hetzelfde model. Routing richt zich op modelkeuze — het bepaalt *welk* model (andere capaciteitsklasse, andere prijs) een query ontvangt. Ze zijn complementair: u kunt routing tussen modellen combineren met load balancing binnen elk model.

Wat te doen als het kleine model een antwoord geeft dat er geloofwaardig uitziet maar feitelijk onjuist is?

Dit is het grootste risico van cascading. Betrouwbaarheidsscores op basis van log-kansen detecteren geen feitelijke fouten — een model kan "zeker" zijn en zich vergissen. Drie maatregelen helpen: (1) beperk het kleine model tot taken met verifieerbare uitvoer (extractie, classificatie), niet tot feitelijke vragen; (2) voeg post-processing verificatie van de uitvoer toe (via regex, JSON-schema, controlelijst); (3) escaleer in gevoelige domeinen altijd naar het sterke model of voeg een human-in-the-loop stap toe.

Wat is het verschil tussen routing en een multi-agent systeem waarbij de agent zelf beslist wat hij aanroept?

In een multi-agent systeem orkestreert de agent andere tools en modellen als onderdeel van het oplossen van een taak — de besluitvorming zit binnen de LLM-lus. Een router staat vóór de LLM-aanroep en is een externe classifier. Een router is sneller en goedkoper om te starten, maar heeft geen toegang tot de semantiek van de taak op de diepte die een agent heeft. Voor complexe pipelines, zie architecturen van AI-agents.

Kan ik routing ook toepassen bij lokale modellen, niet alleen bij cloud-API's?

Ja, en hier kan het voordeel nog groter zijn. Op dezelfde server kunt u een klein 7B-model en een groter 34B-model hebben. De router stuurt eenvoudige queries naar het 7B-model (lager VRAM-gebruik, kortere latentie), complexe naar het 34B-model. De besparing is niet financieel maar capacitair — het 7B-model kan bij dezelfde hardware een veel hogere throughput aan, zodat het 34B-model beschikbaar blijft voor zware gevallen zonder wachtrij.

*Bij MP Industrial Solutions helpen we bedrijven een routingstrategie op te zetten die past bij hun specifieke querymix — van een eenvoudige heuristiek tot een getrainde classifier op eigen data. Als u de LLM-kosten in productie wilt beheersen of een serving-infrastructuur voor meerdere use cases bouwt, kijken we graag samen naar uw situatie.*