Twee jaar geleden hielp ik een team dat een klantenservicesysteem voor cross-border diensten bouwde met een architectuurreview. Het whiteboard in de vergaderruimte stond vol met benchmarkvergelijkingen van verschillende modellen: MMLU, C-Eval, HumanEval. Zelfs een verschil van een paar tienden van een procentpunt kon tot een lang debat leiden. Toen ik dit jaar terugkwam, stond op hetzelfde whiteboard van hetzelfde team een andere set cijfers: gemiddelde kosten per sessie, P99-latentie en beschikbaarheid over zeven opeenvolgende dagen. Deze verschuiving is geen uitzondering. In de jaren dat ik aan AI-platformen werk, merk ik duidelijk dat de logica waarmee bedrijven een large language model API kiezen, verschuift van "parameterverering" naar "de engineeringboekhouding".
Van benchmark naar boekhouding: wat is er precies veranderd in de keuze?
Simpel gezegd: de kernvraag bij het kiezen was vroeger "welk model is het slimst", en nu is dat "welk model is voor deze taak het meest kosteneffectief". Benchmarkscores zijn statische indicatoren onder laboratoriumomstandigheden, maar in een productieomgeving krijg je te maken met miljoenen aanroepen, schommelende piekverkeer en modelversies die elk kwartaal veranderen. Als een model dat hoog in de benchmark staat twee keer zoveel inferentiekosten heeft en twee keer zo langzaam is als een ander, dan valt de rekening in een scenario met een miljoen aanroepen per dag simpelweg niet rond te krijgen. In onze projecten kijken we nu vooral naar het automatisch kiezen van het optimale model per taak: voor taken zoals classificatie en samenvatting gebruiken we kleine modellen, en alleen voor complexe redeneringen routeren we naar grote modellen. Daardoor kunnen we de totale kosten flink drukken. Daarom wordt een modelgateway steeds meer standaard. Deze doet niet alleen het doorsturen van verzoeken, maar vervult ook productieklare verantwoordelijkheden zoals routering, fallback en rate limiting.
Drie factoren die de sector naar dit kantelpunt hebben geduwd
De eerste is dat het verschil in modelcapaciteit kleiner wordt. Het gat tussen de toonaangevende modellen en de modellen in de tweede laag is verschoven van "is het bruikbaar" naar "het scheelt maar een klein beetje". Voor de overgrote meerderheid van bedrijfsscenario's merkt de gebruiker dat verschil helemaal niet, maar het kostenverschil is reëel. De tweede is dat Chinese modellen in Chinese scenario's vrijwel gelijk zijn komen te staan. Modellen zoals Qwen, DeepSeek, Doubao en ERNIE sluiten bij Chinees begrip, gelokaliseerde kennis en compliance-afstemming juist beter aan op binnenlandse bedrijfsvoering dan modellen uit het buitenland. Vroeger hadden veel teams "buitenlandse modellen als hoofdoptie, Chinese modellen als backup"; nu is dat omgekeerd. De derde, en meest cruciale, is dat bedrijven van demo's naar grootschalige productie zijn gegaan. In de demofase is het aanroepvolume klein en zijn kosten niet gevoelig; zodra het volume toeneemt, worden de kosten van elke aanroep en het verlies van elke timeout uitvergroot. Op dat moment is de keuze geen kwestie van technische voorkeur meer, maar een financiële kwestie.
Na de omschakeling: welke onderdelen moet de infrastructuur aanvullen?
Het eerste onderdeel is de modelgateway. Die lost het probleem op van "één ingang voor alle modellen". Zonder gateway moet je voor elk model dat je aansluit code aanpassen, een set sleutels onderhouden en een set retry-logica schrijven. Met een gateway sluit je meerdere modellen uniform aan en is het wisselen van model transparant voor de bovenliggende bedrijfslogica. Het tweede onderdeel is AI API-aggregatie. De waarde hiervan ligt in het verenigen van inkoop, facturering en quotabeheer. Intern hebben we een vergelijking gemaakt: als je zelf de SDK's van vijf leveranciers aansluit, kost alleen al het onderhouden van documentatie en versiecompatibiliteit een engineer veel tijd; met een aggregatieplatform dat compatibel is met de OpenAI SDK, kun je met één regel base_url wijzigen van model wisselen, en wat je bespaart is echte menskracht. Ik noem hier één ding: de positionering van SiCore TokenWorks, met prioriteit voor Chinese modellen plus groene rekenkracht, sluit precies aan op dit kantelpunt. Wat bedrijven nodig hebben is niet het grootste aantal modellen, maar volledige Chinese dekking, beheersbare kosten en stabiele planning van rekenkracht. Het derde onderdeel is observability. Zonder aanroeplogs, statistieken over Token-verbruik en latentieverdelingen weet je niet waar het geld naartoe gaat en welk model je omlaag trekt. Doorlopende optimalisatie begint met zichtbaarheid.
Drie voorspellingen voor modelkeuze in 2026
Voorspelling één: betalen naar gebruik wordt de standaardoptie, en het grove model van jaarlijkse of maandelijkse pakketten verdwijnt naar een klein aantal stabiele scenario's met veel verkeer. Omdat het zakelijke volume zelf schommelt, wil niemand betalen voor ongebruikte rekenkracht. Voorspelling twee: modelroutering verandert van "geavanceerde functie" in "basisfunctie". Wanneer het normaal wordt dat een bedrijf tegelijk drie of vier modellen gebruikt, is automatisch het beste model kiezen geen extraatje meer, maar een noodzaak om geld te besparen. Voorspelling drie: groene rekenkracht en binnenlandse technologie worden van pluspunten harde eisen. Compliance met binnenlandse IT-standaarden, energiekosten en leveringszekerheid van de toeleveringsketen: deze drie zaken worden in 2026 in meer inkoopprocessen als harde eisen opgenomen. De planning van rekenkracht die SiCore TokenWorks in oost en west opzet, is in essentie een antwoord op deze trend.
Samengevat in één zin: de verschuiving in keuzelogica is in essentie een beweging van "het slimste model kiezen" naar "de meest geschikte combinatie kiezen". Wil je dieper ingaan op de praktische details van multi-modelroutering en API-aggregatie, dan kun je verder zoeken op modelgateway, large language model API en betalen naar gebruik.