Je hebt niet altijd het duurste model nodig

Er zit een reflex in de meeste teams: als het serieus wordt, pak je het krachtigste, duurste model. De frontier voelt als de veilige keuze. Wie kiest er nu bewust voor minder?

Kijk eerst eens naar wat “minder” tegenwoordig betekent. Claude Haiku 4.5, het kleine, snelle model van Anthropic, evenaart volgens Anthropic het grotere Sonnet 4 op coding, computer use en agent-taken, en scoort 73,3% op SWE-bench Verified. Eén klant meet dat het negentig procent van de veel grotere Sonnet 4.5 haalt. Dat zijn deels Anthropics eigen cijfers, dus lees ze met een korrel zout. De prijzen zijn wél hard: op Anthropics eigen API kost het frontier-model Fable 5 tien dollar per miljoen input-tokens en vijftig per miljoen output. Haiku doet hetzelfde werk voor één en vijf. Een factor tien, binnen één leverancier, voor een model dat een half jaar geleden nog state-of-the-art zou zijn geweest.

Met andere woorden: het model dat vandaag “goedkoop” heet, was gisteren de frontier. En je betaalt de frontier-prijs uit gewoonte.

De verkeerde vraag

De discussie gaat bijna altijd over welk model het beste is. Dat is de verkeerde vraag. De leaderboards meten breedte: kan het model over Shakespeare, kwantumfysica en elk Lego-setje meepraten. Jouw product doet dat niet. Het doet één ding, of een handvol dingen, en het doet ze de hele dag.

Het wordt een beetje mijn stokpaardje (zie het stuk over te dure tokens): het winnende product draait niet op het grootste model, maar op het kleinste dat zijn ene taak uitstekend doet. Sinds ik dat schreef is er het een en ander veranderd: er zijn meer praktijkcases, en de kleine algemene modellen zijn goed genoeg geworden voor het meeste productiewerk. Ze doen het zelf trouwens ook: Anthropic raadt aan makkelijke, veelvoorkomende vragen naar een goedkoop model te routeren en alleen de moeilijke gevallen naar een duurder model te sturen.

Goedkoop is geen gratis lunch

En toch is “altijd goedkoop” net zo lui als “altijd duur”, want goedkoop verschuift de kosten. Niet naar je tokenrekening, maar naar je aandacht.

Op onze hackathon koos een team bewust voor Haiku en kwam er even ver mee. Alleen: ze gingen mob programmen om het bij te benen, omdat het kleinere model sneller de verkeerde aanname neemt en er vrolijk op doorbouwt. Zelf gebruikte ik Gemini (ik was door mijn Claude tokens heen) met copy/paste naar Python. Dat werkte, maar trager, en het werkte juist omdat copy/paste alles klein en voorspelbaar hield. Grotere modellen hebben een eigen valkuil: Gemini vertrouwt nogal eens te veel op zijn eigen overzicht.

Het scherpst zag ik het bij een ander project, gebouwd met een agentische methode. Die werd op een gegeven moment zo complex dat hij niet meer te debuggen was. De uitweg was niet een groter model, maar een klein testprogrammaatje dat we als input voor de bugfix gebruikten. Precies de engineering practices uit een vorige blog: klein, testbaar, controleerbaar. Wat collega Michiel Kooiman het automatiseren van aannames noemt, gebeurt bij een goedkoper model gewoon een tikje sneller. Dat is te managen, maar het is geen gratis lunch.

Het juiste model is vaak klein, soms regionaal

Matchen dus, niet minimaliseren. Het duurste model verdient zijn plek bij het verkennen en bij taken die brede, echte redenering vragen. Maar voor een afgebakende taak wint gespecialiseerd het van generalistisch, en niet met een kleine marge.

Mistral laat dat zien met Saba, een model van 24 miljard parameters dat getraind is op het Midden-Oosten en Zuid-Azië. Volgens Mistral geeft het accuratere antwoorden dan modellen die ruim vijf keer zo groot zijn, en dat sneller en goedkoper. Het is met name sterk in Zuid-Indiase talen als Tamil, draait op één GPU en laat zich binnen je eigen beveiligde omgeving deployen. Het bedient markten waar de Verenigde Staten weinig interesse tonen en China met enig wantrouwen wordt bekeken. Wat Mistral daar bewust doet, kun jij ook: kies het model dat past bij je toepassing. Dat mag een Mistral zijn, een Haiku, of een open model dat je zelf draait. De kunst zit in de match, niet in het merk.

De rekening op schaal, en wie erdoor zwicht

Bij een paar tientjes per maand is dit een academische discussie. Maar een serieus product tikt zomaar duizend euro per dag aan, en dan wordt die factor tien tot honderd tussen frontier en klein model geen detail meer, maar je grootste variabele kostenpost.

Hoe sterk die druk is, zie je aan Airbnb. CEO Brian Chesky noemde de Chinese modellen publiekelijk snel en goedkoop, en zijn bedrijf draait op het Chinese Qwen van Alibaba. Dat een groot Amerikaans bedrijf daar hardop voor uitkomt, tot in het Amerikaanse Congres aan toe, laat zien dat dit kostenvoordeel geen randverschijnsel is. En hier komt een tweede motief bij: als je het slim aanpakt, koop je met eigen infrastructuur niet alleen kosten maar ook databeheersing. Voor een Nederlandse bank, zorginstelling of overheid is dat geen bijzaak.

Het beeld waar ik naartoe zou werken is een orkestratie met twee lagen: een duur, slim model (een Fable of een Sonnet) dat de moeilijke beslissingen neemt en het werk verdeelt, en daaronder een legertje goedkope open modellen (denk aan Mistral, Qwen of Gemma) dat het gros van het werk doet, op je eigen hardware of in je eigen image. De slimme regie huur je in, de massa draai je zelf.

Ik zou dat vandaag al aanraden, met één belangrijke nuance: het gaat om optionaliteit. Zorg dat je kúnt overstappen op je eigen infrastructuur wanneer de kosten of de datavereisten daarom vragen. Je hoeft het niet meteen te doen, maar je architectuur moet het toelaten. Wie zich volledig vastklinkt aan één dure API, ontdekt op het slechtste moment dat overstappen geen knop is.

En de keuze is niet binair. Tussen een dure API en je eigen serverrek zit een middenweg: open modellen laten draaien bij een gehoste aanbieder. Je pakt een deel van de kosten- en controlewinst zonder zelf een GPU-park te beheren.

Want wees eerlijk over die prijs. Een model zelf draaien is geen knop maar een competentie: hardware, monitoring, updates, en iemand die het overneemt als die ene collega op vakantie is. Zoals ik in het tokens-stuk schreef, eigenaarschap zonder bekwaamheid is geen controle maar een nieuw risico. Reken die mensen mee, niet alleen de tokens. En hetzelfde geldt voor het babyzitten van een goedkoper model: wat je op de rekening bespaart, kun je in aandacht weer kwijtraken.

Hoe je durft te kiezen voor goedkoper

Dat je durft te schalen naar een goedkoper model, hangt aan één ding, en het sluit weer aan op die engineering practices: je moet kunnen aantonen dat het goed genoeg is. Zonder een check, een testset, een evaluatie, is modelkeuze een gok, en dan grijp je uit onzekerheid naar het duurste. Mét een check wordt het een meting. In de praktijk is dat geen groot project: een kleine, taak-specifieke testset van een stuk of twintig echte gevallen met het antwoord dat je verwacht, waar je twee modellen naast elkaar op loslaat. De uitkomst vertelt je of het goedkope model volstaat. De testsuite die je AI-code laat vertrouwen, is dezelfde die je zonder angst naar beneden laat schalen.

Waar het op neerkomt

Het duurste model hoort een uitwijk te zijn, geen uitgangspunt. Draai de gewoonte om: begin met het goedkoopste model dat de taak aannemelijk aankan, toets het tegen je eigen check, en schaal pas op als het zakt voor die toets. Reken daarbij het successcenario, niet de pilot.

Dat vraagt drie dingen die niets met het merk van je model te maken hebben: weten wat je taak echt nodig heeft, een manier om te meten of het werkt, en een architectuur die je de vrijheid geeft om te wisselen. Wie dat op orde heeft, ontdekt meestal dat “goed genoeg” een stuk goedkoper is dan gedacht. En wie het niet op orde heeft, betaalt de frontier-prijs voor gemoedsrust, niet voor resultaat.

‍