“Welk model moeten we aanroepen?” klonk vroeger als een API-vraag. Bij een groeiend aantal organisaties ligt het dichter bij een vraag over inkoop, performance-engineering en architectuur.
Die verandering volgt uit een eenvoudige ontwikkeling: er zijn nu veel modellen, aangeboden door veel providers, met wezenlijk verschillende sterke punten, prijzen, latencyprofielen, implementatieopties en contractuele voorwaarden. De aangekondigde overeenkomst van Stripe om OpenRouter over te nemen is een nuttig signaal. De enkele API van OpenRouter omvat meer dan 400 modellen van meer dan 80 providers, met routeringscriteria zoals taakcomplexiteit, prijs, snelheid, betrouwbaarheid, latency, throughput en providerspecifieke kosten.
De opkomende functie heeft niet per se een nieuwe titel. Ze kan vallen onder AI-platformengineering, architectuur, inkoop, inference-operaties of productengineering. Maar de verantwoordelijkheid wordt herkenbaar: beslissen welk model welk werk moet afhandelen, onder welke randvoorwaarden, met welke fallback en op basis van welk bewijs.
Routering is een beleidsbeslissing vermomd als infrastructuur
Een naïeve router vraagt: “Welk model is het goedkoopst?” Een bruikbare router stelt een specifiekere vraag: “Wat is het goedkoopste model dat voldoet aan de kwaliteits-, latency-, betrouwbaarheids-, privacy- en operationele vereisten van dit verzoek?”
Die vereisten verschillen per taak. Een classifier voor klantenondersteuning heeft mogelijk voorspelbare gestructureerde uitvoer en lage latency nodig. Een moeilijke programmeertaak kan een trager, capabeler model rechtvaardigen. Een samenvattingspipeline met een hoog volume geeft mogelijk de voorkeur aan een kleiner model, vooral als de kwaliteit na tests toereikend is. Een gereguleerde workflow kan een specifieke regio, bewaarbeleid of provider-overeenkomst vereisen, ongeacht de tokenprijs.
Daarom hoort routering thuis in architectuurbeoordelingen, niet alleen in applicatiecode. De route bepaalt meer dan alleen een factuur. Ze kan invloed hebben op dataresidentie, blootstelling aan storingen, observeerbaarheid, consistentie van antwoorden, gedrag bij toolgebruik en de hoeveelheid menselijke beoordeling die downstream nodig is.
De vier disciplines achter een serieuze routeringsfunctie
1. Inkoop: vergelijk de volledige dienst, niet alleen de opvallende tokenprijs
Modelprijzen zijn gemakkelijk verkeerd te vergelijken. Input- en outputtokens kunnen verschillende tarieven hebben. Gecachte input, batchverwerking, prioriteitsservice en verzoeken met een lange context kunnen de berekening veranderen. De nominale prijs van een provider zegt ook weinig over retries, rate limits, ondersteuning, minimale afnames, egress of de engineeringkosten van overstappen.
Een verantwoordelijke voor routering moet een inventaris van modellen en providers bijhouden met velden zoals:
- prijzen voor input, output, caching en batchverwerking;
- context- en outputlimieten;
- gedocumenteerde rate limits en waargenomen throughput;
- latencyverdelingen, niet alleen gemiddelde latency;
- beschikbaarheid en timeoutgedrag;
- voorwaarden voor datagebruik, bewaring, dataresidentie en contracten;
- ondersteunde mogelijkheden, waaronder toolaanroepen, gestructureerde uitvoer, vision en streaming;
- fallback- en migratieopties.
Het resultaat lijkt meer op een stuklijst van technologie dan op een lijst met modelnamen. De inventaris moet worden herzien wanneer prijzen, beleidsregels, modelversies of bedrijfsvolumes veranderen.
2. Performance-engineering: meet de taak, niet het leaderboard
Algemene benchmarks kunnen helpen bij de oriëntatie, maar routeringsbeslissingen vereisen taakgerichte tests. Een model dat goed presteert op een openbare programmeerbenchmark is mogelijk niet de beste keuze voor de interne repositories, naamgevingsconventies, toolschema’s of beveiligingscontroles van een organisatie.
Stel een representatieve evaluatieset samen op basis van echte verzoeken, waarbij gevoelig materiaal wordt verwijderd of beheerst. Label de uitkomsten die ertoe doen: feitelijke juistheid, geldige JSON, succesvolle toolselectie, geslaagde codetests, weigeringsgedrag, noodzaak tot escalatie en een aanvaardbare stijl. Leg vervolgens de kosten, tijd tot het eerste token, totale latency, timeoutfrequentie, retryfrequentie en lengte van de voltooiing vast.
Breng het resultaat niet te vroeg terug tot één score. Een gewogen score kan een ernstige foutmodus verbergen. Zo kan een model met een uitstekende gemiddelde kwaliteit maar veelvuldig onjuist gevormde toolaanroepen ongeschikt zijn voor een geautomatiseerde workflow. Een trager model kan economisch de voorkeur verdienen als zijn antwoorden de kostbare menselijke beoordeling verminderen.
Gebruik een champion-and-challengerproces: behoud een momenteel goedgekeurde route, test alternatieven tegen dezelfde corpus en promoveer een challenger alleen wanneer die expliciete kwaliteits- en operationele drempels haalt. Claims van providers moeten worden behandeld als input voor een testplan, niet als bewijs dat een model zich in jouw omgeving op vergelijkbare wijze zal gedragen.
3. Architectuur: maak modelkeuze vervangbaar
Routing wordt duur wanneer modelspecifieke aannames door een hele applicatie heen lekken. Een veerkrachtig ontwerp scheidt de bedrijfstaak van de aanroep van de provider.
Definieer een intern capaciteitscontract. Daarin kan bijvoorbeeld worden vastgelegd dat een bewerking voor “classificatie” een vast schema, velden voor betrouwbaarheid of onthouding, een model-ID en een trace-ID retourneert. Voor een bewerking voor “conceptantwoord” kunnen toonbeperkingen, citatievereisten en een maximale latentiebudget worden vastgelegd. Adapters voor providers vertalen dat contract vervolgens naar afzonderlijke API’s.
Houd prompts, schema’s, tooldefinities, veiligheidsregels en routeringsbeleid versiebeheerbaar. Leg vast welke modelsnapshot en provider elk verzoek hebben verwerkt. Bewaar voldoende informatie om een beslissing te kunnen reproduceren, zonder onnodig gevoelige gebruikersinhoud te bewaren.
Ontwerp fallbacks doelbewust. Een fallback kan een andere provider, een kleiner model, een workflow met wachtrij of een route voor menselijke beoordeling zijn. De betekenis van de taak mag daarbij niet stilzwijgend veranderen. Als gestructureerde uitvoer verplicht is, moet de fallback hetzelfde contract ondersteunen of een gecontroleerde escalatie activeren.
4. Governance: bepaal wanneer je niet automatisch routeert
Sommige verzoeken moeten niet naar het goedkoopst beschikbare model worden gestuurd—of naar helemaal geen extern model. Het routeringsbeleid heeft uitsluitingsregels nodig voor vertrouwelijke gegevens, beslissingen met grote impact, niet-ondersteunde talen, ongewoon lange contexten of acties waarvoor goedkeuring door een mens nodig is.
Teams moeten ook onderscheid maken tussen technische beschikbaarheid van een model en goedkeuring voor een bepaald gebruik. Inkoop- en wettelijke vereisten kunnen per bedrijfsonderdeel verschillen. Een model kan in een evaluatie uitstekend presteren en toch onbruikbaar zijn voor een workflow waarvan de voorwaarden voor gegevensverwerking niet bij de organisatie passen.
Een praktische routeringstabel
Een startbeleid kan eenvoudig en expliciet zijn:
| Taakklasse | Primaire doelstelling | Mogelijke route | Trigger voor escalatie |
|---|---|---|---|
| Extractie met hoge volumes | Geldig schema en lage kosten per eenheid | Klein of middelgroot model met strikte validatie van de uitvoer | Schemafout of lage betrouwbaarheid |
| Complexe analyse | Kwaliteit en verwerking van bewijsmateriaal | Krachtiger model met een groter latentiebudget | Ontbrekend bewijs, ambiguïteit of beleidsvlag |
| Interactieve ondersteuning | Snelle waargenomen respons | Model met lage latentie, mogelijk gevolgd door verfijning | Weinig vertrouwen of verzoek van de gebruiker om meer diepgang |
| Gevoelige workflow | Goedgekeurde gegevensverwerking en auditbaarheid | Contractueel goedgekeurde provider of gecontroleerde implementatie | Niet-goedgekeurde gegevens, actie of jurisdictie |
De exacte tabel zal per organisatie verschillen. Het belangrijkste is dat routeringsregels leesbaar zijn voor belanghebbenden uit product, security, finance en engineering—niet weggestopt in een voorwaardelijke instructie.
Wat dit betekent voor mensen die een carrière opbouwen
De sterkste kandidaten voor dit werk zullen verschillende soorten expertise combineren. Ze zullen genoeg van machine learning begrijpen om over capaciteiten en kwaliteitsverlies te kunnen redeneren; genoeg van systems engineering om latency, retries, rate limits en failure modes te beheren; genoeg van finance om de totale kosten te modelleren; en genoeg van procurement en governance om verplichtingen en beperkingen van providers te beoordelen.
Ze zullen zich ook comfortabel voelen bij het schrijven van beslisdocumenten. Een nuttig document legt uit waarom een route is gekozen, welk bewijs die keuze ondersteunt, welke risico’s overblijven en welke gebeurtenis een nieuwe evaluatie moet activeren. Dat is waardevoller dan het uit het hoofd leren van de nieuwste modelnamen, omdat modelnamen en prijzen voortdurend zullen veranderen.
Een compact portfolio-project kan deze vaardigheid aantonen zonder dat er een groot productiesysteem nodig is. Neem één workload, maak een geredigeerde evaluatieset, verbind drie modelproviders of lokale modellen via een gemeenschappelijke interface en vergelijk kwaliteit, schemavaliditeit, latency-percentielen, foutpercentages en geschatte maandelijkse kosten bij verschillende volumes. Voeg beleidsregels toe voor gevoelige invoer en een fallback-pad. Publiceer de testmethodologie en beperkingen.
Wees precies over wat het project bewijst. Het bewijst niet dat één model universeel het beste is. Het bewijst dat je een ambigu modelkeuzeprobleem kunt omzetten in een meetbaar operationeel beleid.
Het carrièreteken
Modelroutering wordt strategisch belangrijk omdat intelligentie niet langer één vaste afhankelijkheid is. Het is een portfolio van diensten met verschillende afwegingen en veranderende economische aspecten. Teams die dat portfolio als onderling uitwisselbare infrastructuur behandelen, kunnen de kosten verlagen, maar ook verborgen problemen op het gebied van kwaliteit, compliance en betrouwbaarheid creëren. Teams die het als een permanente keuze voor één model behandelen, kunnen betere opties mislopen.
De opkomende discipline bevindt zich tussen die uitersten: abstract genoeg om van provider te wisselen, specifiek genoeg om de taakkwaliteit te behouden en voldoende evidence-driven om de keuze te rechtvaardigen. Dat is de carrièrekans in modelroutering—niet één keer een API kiezen, maar het beslissysteem bouwen dat goed blijft kiezen.
Tom Whitfield is de verantwoordelijke menselijke redacteur van AI Career Brief, over vaardigheden, functies en slimme stappen om te werken in het tijdperk van AI.
