Model routing en fallback

Wat is model routing en fallback?

Model routing is per aanvraag beslissen welk model het werk krijgt. Een korte vraag over een factuur gaat naar een klein, goedkoop model. Een klacht met een bijlage van tien pagina's gaat naar een groot model. Een aanvraag met persoonsgegevens blijft op een implementatie binnen de EU. Die beslissing valt vóór de aanroep, bewust, door een regel of een kleine classifier die vóór je modellen staat.

Fallback is wat er gebeurt als dat gekozen model niet levert. De aanbieder geeft een fout terug, de aanroep loopt over tijd, je zit aan je rate limit, de prompt is langer dan het context window, of het model is intussen uit dienst genomen. Een fallback stuurt dezelfde aanvraag ergens anders heen: naar hetzelfde model in een andere regio, naar een oudere versie, naar een andere aanbieder, naar een antwoord uit de cache, of naar een bericht dat de assistent even niet beschikbaar is en een collega het opvolgt.

Routing is de triageverpleegkundige aan het onthaal. Fallback is de noodgenerator.

De vormen van routing

1. Vast per endpoint. Je factuurlezer roept altijd het kleine model aan, je contractreviewer altijd het grote. Geen beslissing tijdens het draaien, gewoon een model-ID in de configuratie per taak. De meeste bedrijven starten hier best, en velen hebben nooit meer nodig.

2. Op regels, op basis van de input. De router kijkt naar iets dat hij kan meten zonder een model aan te roepen: de lengte van de prompt, de taal, het abonnement van de klant, een tag die de aanroepende toepassing meegeeft. De conditional routing van Portkey werkt zo, met regels op metadata en parameters van de aanvraag en een verplichte default als niets past. LiteLLM doet hetzelfde met tags: een aanvraag met tag free landt op de ene implementatie, een met tag paid op de andere.

3. Aangeleerde moeilijkheidsscore. Een kleine classifier schat in hoe moeilijk de vraag is en stuurt enkel de moeilijke naar boven. LMSYS, de groep achter Chatbot Arena, toonde in 2024 dat een router die getraind was op de voorkeuren van mensen tussen twee modellen ongeveer 95 procent van de kwaliteit van het sterke model vasthield op een chatbenchmark, aan tot drie kwart minder kost. Dezelfde router bleef werken toen ze er een ander paar modellen onder schoven.

4. Cascade. Het kleine model antwoordt eerst, en een scorestap beslist of dat antwoord goed genoeg is om te houden of een trede hoger moet. In 2023 beschreven als een LLM cascade, met grote gerapporteerde besparingen, omdat de meeste vragen het dure model nooit bereiken. De adder zit in die scorestap: een cascade is maar zo goed als haar vermogen om een zelfzeker fout antwoord van een juist antwoord te onderscheiden.

5. Advisor. De nieuwste vorm keert de cascade binnenstebuiten. Een klein model doet de hele taak en roept, als het vastzit, een sterk model aan als tool, krijgt een plan terug en gaat verder. Anthropic bracht dit in april 2026 uit als de advisor tool: de executor (Haiku of Sonnet) doet het werk, de advisor (Opus of Fable) leest het volledige transcript en geeft enkele honderden tokens advies terug aan zijn eigen tarief. In de meting van Anthropic ging Haiku met een Opus-advisor van ongeveer 20 naar 41 procent op een webonderzoekstaak, en met max_uses begrens je hoe vaak de advisor per aanvraag geroepen mag worden.

De vormen van fallback

Een fallback wordt uitgelokt door een fout, dus vertrek van de fouten die je verwacht: een 429 voorbij je rate limit, een 5xx aan de kant van de aanbieder, een context-length-fout, een weigering van een inhoudsfilter. Een model dat uit dienst is, faalt gewoon. Anthropic zegt letterlijk dat aanvragen naar retired modellen mislukken en verwittigt minstens 60 dagen op voorhand. Claude Sonnet 4 en Opus 4 gingen op 15 juni 2026 uit dienst. OpenAI belooft minstens zes maanden voor algemeen beschikbare modellen en amper twee weken voor previews.

Het antwoord op elke fout is één van vijf dingen.

• Hetzelfde model ergens anders. Een andere implementatie van hetzelfde model, in een andere regio of op gereserveerde capaciteit. Dit is de fallback zonder verschil in output, en de architectuurgids van Microsoft is daar duidelijk over: gebruik bij failover of load balancing hetzelfde model in dezelfde versie, en schakel niet over van versie X naar X+1, want dat gedragsverschil verrast je toepassingen.

• Een oudere of kleinere versie. Goedkoper om warm te houden, maar nu veranderen de antwoorden en ziet niemand het, tenzij je meet.

• Een andere aanbieder. LiteLLM, Portkey en OpenRouter laten je allemaal het model van een tweede aanbieder als volgende doel opgeven. OpenRouter rekent het model aan dat effectief geantwoord heeft en zet de naam ervan in het veld model van het antwoord, zodat je tenminste ziet wanneer het gebeurd is.

• Een antwoord uit de cache. Voor vragen die terugkeren, kan een semantische cache het laatste goede antwoord geven terwijl het model plat ligt. Enkel voor inhoud die niet gepersonaliseerd is.

• Netjes afbouwen. Een vast bericht, een link naar de FAQ, een ticket voor een collega. Elk systeem heeft deze nodig, want de vier hierboven kunnen allemaal tegelijk wegvallen.

In elke gateway zitten daar twee controles rond. Een cooldown of circuit breaker haalt een falende backend een tijdje uit de rotatie: LiteLLM doet dat standaard na drie fouten, en bij Azure API Management stel je zelf een aantal fouten per interval en een duur in. Die breaker moet ook de Retry-After-header respecteren, want zoals Microsoft waarschuwt kan een 429 van Azure OpenAI je vragen om een volle dag te wachten.

Routing tegenover fallback: wanneer valt de beslissing?

Elke productpagina gooit de twee op één hoop, en toch verschillen ze op één punt dat je ontwerp bepaalt.

Routing beslist vóór de aanroep, bewust, op basis van de aanvraag zelf. Je kan die beslissing offline testen op een stapel oude aanvragen en precies weten welk model elke aanvraag zou krijgen. De fout die je maakt is een verkeerde inschatting: het kleine model kreeg een moeilijke vraag.

Fallback beslist na een fout, als reactie op de aanbieder. Dat kan je niet testen op oude aanvragen, enkel door de fout te laten gebeuren. De fout die je maakt is een stille omschakeling: het antwoord kwam van een model dat je niet gepland had, en niemand merkte het.

Routing heeft dus een eval per route nodig, fallback een alarm per trigger. Als je monitoring niet kan zeggen hoeveel aanvragen er gisteren naar de fallback gingen, heb je geen fallbackstrategie, je hebt een verrassing.

Waar de logica zit

In je eigen code, wat prima is voor één toepassing met één model. In een routerbibliotheek die je zelf draait, zoals de proxy van LiteLLM of een zelf gehoste Portkey, waar routingstrategieën (shuffle, laagste latency, laagste kost, minst bezet), fallbacklijsten per model en cooldowns in één configuratiebestand staan. Of in een beheerde gateway zoals de AI gateway van Azure API Management, waarvan de backend pools verdelen via round robin, op gewicht of op prioriteit, en een groep met lagere prioriteit pas verkeer krijgt als alles erboven is uitgevallen. Gehoste routers zoals OpenRouter doen hetzelfde als dienst, op prijs en recente beschikbaarheid, tenzij je op doorvoer of latency laat sorteren. Zodra een tweede toepassing modellen aanroept, hoort dit in een gateway thuis en niet apart in elke toepassing.

Een uitgewerkt voorbeeld: de supportassistent

Een bedrijf beantwoordt 20.000 klantenmails per maand met een assistent die antwoorden voorbereidt voor het supportteam.

De regel. Een mail van minder dan 150 woorden die een classifier als facturatie of orderstatus labelt, gaat naar de kleine klasse. Alles wat als klacht gelabeld is, alles met een bijlage, en alles wat een sentimentcheck als boos aanduidt, gaat meteen naar de grote klasse. Stel dat 70 procent van de mails zo op de kleine klasse landt.

De escalatie. De kleine klasse geeft in haar gestructureerde output een zekerheidsscore mee, en onder een drempel gaat de mail opnieuw naar de grote klasse. De eval zegt je of die drempel juist staat: neem een steekproef van de mails die niet geëscaleerd zijn en tel hoeveel de grote klasse anders beantwoord zou hebben.

De fallback. Beide klassen draaien op twee implementaties in de EU-datazone. Een 429 of een time-out stuurt de aanroep naar de tweede, en drie fouten in een minuut halen een implementatie uit de rotatie. Falen beide klassen op beide implementaties, dan krijgt de klant een vast antwoord dat zijn mail goed aangekomen is en dat een collega antwoordt, en belandt de mail in een menselijke wachtrij met de tag dat de assistent niet beschikbaar was.

Vier cijfers horen op het dashboard: aandeel mails per route, escalatiepercentage, fallbacks per dag, en de evalscore per route.

Waar moet je op letten bij model routing en fallback

Het kleine model weet niet dat het fout zit. Een zekerheidsscore van het model zelf is een hint, geen meting. Het enige betrouwbare antwoord is een eval per route op je eigen documenten, opnieuw gedraaid telkens er iets verandert.

Stille kwaliteitsdaling na een fallback. Een oudere versie of een andere aanbieder geeft andere antwoorden. Log welk model welke aanvraag beantwoord heeft, en beslis op voorhand of de gebruiker het te weten komt. Bij een ontwerp dat een collega naleest, wellicht niet. Bij een antwoord dat rechtstreeks naar een klant gaat, is een korte melding dat de assistent in beperkte modus draait eerlijk en goedkoop.

Dataresidentie van de fallback. Een fallback naar een globale implementatie of een Amerikaanse aanbieder brengt persoonsgegevens over een grens waarvan je beloofd had erbinnen te blijven. Op Azure mogen Global Standard-implementaties prompts in eender welke Azure-regio verwerken, en enkel Data Zone- of regionale implementaties houden de verwerking binnen de EU.

Routingregels die de modelgeneratie overleven. Een regel die geschreven is voor de kleine klasse van vorig jaar stuurt nog altijd werk naar boven dat de kleine klasse van dit jaar prima aankan. De hele ladder van modelklassen schuift op bij elke generatie, dus draai de routing-eval opnieuw zodra er een nieuwe is.

Kostenplafonds. Een cascade die te vaak escaleert, of een advisor die bij elke stap geroepen wordt, betaalt stilletjes twee modellen per aanvraag. Zet een tokenbudget per toepassing op de gateway en begrens de advisor-aanroepen.

De voorwaarden van de tweede aanbieder. Je fallbackaanbieder heeft zijn eigen bewaartermijnen, zijn eigen clausules over trainen op je data en zijn eigen subverwerkers. Bij OpenRouter kan je aanbieders die data bijhouden uitsluiten en enkel naar endpoints zonder gegevensbewaring routeren. Bij een rechtstreeks contract lees je de voorwaarden zelf, vóór de storing.