Wanneer een kleiner AI-model volstaat

De standaardmanier om in 2026 een AI-functie te bouwen, is het grootste beschikbare model aanroepen en doorgaan. Het werkt, het is snel uitgerold en voor een echt open assistent is het de juiste keuze. Voor het veel vaker voorkomende geval, een systeem dat duizenden keren per dag een binnenkomende lead leest of zes velden uit een factuur haalt, betaalt het stilletjes te veel voor capaciteit die de taak nooit gebruikt.

Agentwerk is repetitief, en repetitief werk is smal

Een agent in productie voert zelden een breed gesprek. Hij classificeert, extraheert, routeert, roept een tool aan met gestructureerde argumenten of kiest tussen een handvol volgende stappen. Dezelfde promptvorm draait steeds opnieuw, met telkens andere inhoud erin.

Een team bij NVIDIA bracht dit argument formeel naar voren in Small Language Models are the Future of Agentic AI, voor het eerst gepubliceerd in juni 2025 en in september herzien. Hun werkdefinitie van klein is een model dat op een gewoon consumentenapparaat past en snel genoeg antwoordt om bruikbaar te zijn, wat in 2025 ruwweg alles onder de 10 miljard parameters betekent.

Hun economische claim is de concrete. Een model met 7 miljard parameters draaien is 10 tot 30 keer goedkoper dan een model met 70 tot 175 miljard parameters, gemeten in latentie, energieverbruik en drijvendekommabewerkingen. Voor een workflow die een paar honderd keer per maand wordt aangeroepen, is het verschil een afrondingsfout. Voor een workflow die continu draait, is het het verschil tussen een systeem dat zichzelf terugverdient en een dat dat niet doet.

Wat capaciteit betreft wijzen ze op modellen als Phi-2 met 2,7 miljard parameters, dat bij gezond-verstandredeneren en codegeneratie scores haalt die vergelijkbaar zijn met modellen van 30 miljard parameters uit dezelfde generatie. Kleiner betekent bij een bepaalde taak niet automatisch zwakker.

Bijtrainen op de taak verandert de vergelijking volledig

Het scherpere resultaat is wat er gebeurt als een klein model specifiek wordt getraind op het smalle ding dat je nodig hebt.

Onderzoekers trainden facebook/opt-350m, een model met 350 miljoen parameters, bij op de ToolBench-dataset voor toolaanroepen door agents en rapporteerden een slagingspercentage van 77,55%, tegenover 26,00% voor ChatGPT met chain-of-thought-prompting bij ongeveer 175 miljard parameters. Dat is een model dat 500 keer kleiner is en ongeveer drie keer hoger scoort op de taak waarvoor het is getraind.

Pas nu de discipline uit het vorige stuk over evaluatie toe op dat getal, want het verdient dezelfde kritische blik als elke grafiek van een leverancier.

Het bijgetrainde model is getraind op ToolBench en gemeten op ToolBench. Het kent de verdeling. De frontiermodellen ter vergelijking kregen op die verdeling prompts, geen training. Dat komt dicht bij de eerlijkste beschikbare vergelijking voor de vraag “kan een klein gespecialiseerd model een groot algemeen model verslaan bij een gespecialiseerde taak”. Het is ook een smalle claim, en zo moet je hem lezen. Een model met 350 miljoen parameters presteert in het algemeen niet beter dan een frontiermodel, en niets in het artikel beweert dat.

Wat het resultaat wel onderbouwt, is het operationele punt. Als je de taak strak genoeg kunt definiëren om er trainingsdata voor te bouwen, concurreert een klein model dat op die data is getraind met een groot model dat je beleefd iets vraagt, en verslaat het dat vaak. De voorwaarde is dat je het definitiewerk doet.

De beslisregel

De vraag is niet welk model het beste is. De vraag is of je taak te specificeren is.

Kies een klein model als de taak een afgebakende invoer en een controleerbare uitvoer heeft, je een paar honderd gelabelde voorbeelden kunt verzamelen, het volume hoog genoeg is dat de kosten per eenheid tellen, latentie wordt gevoeld door een gebruiker of een wachtrij, of de data je infrastructuur niet mag verlaten. Documentextractie, leadscoring volgens geschreven regels, ticketroutering, gestructureerde toolaanroepen en classificatie horen hier allemaal bij.

Kies een frontiermodel als de invoer echt open is, het werk kennis vraagt die je niet kunt opsommen, het volume zo laag is dat de kosten per aanroep ruis zijn, of je nog uitzoekt wat de taak eigenlijk is. Vroege verkenning is werk voor een frontiermodel, net als alles wat een mens als lopende tekst zal lezen.

Gebruik beide als het werk zich netjes laat splitsen. Het positiepaper van NVIDIA pleit om die reden voor heterogene systemen: stuur de repetitieve meerderheid naar een klein model en escaleer de echt nieuwe gevallen naar een groot model. De meeste productiesystemen die wij draaien hebben deze vorm, omdat de meeste werklasten grotendeels routine zijn, met een staart die dat niet is.

Begin groot en krimp op basis van bewijs

Eerst het kleine model kiezen is een vergissing, omdat je geen taak kunt specificeren die je nog niemand hebt zien uitvoeren. De volgorde die werkt:

1. Bouw het met een frontiermodel. Krijg de workflow correct en zet hem voor echte invoer. Optimaliseer nog niets.
2. Log elke aanroep. Invoer, uitvoer en de menselijke correcties. Dit wordt de trainingsset en de evaluatieset, en het verzamelen kost niets als je op dag één begint.
3. Wacht tot de taak niet meer verandert. Een workflow die nog wordt herzien, is niet klaar om te specialiseren. Een bewegend doel bijtrainen verspilt het werk twee keer.
4. Bouw de achtergehouden evaluatie. Label echte gevallen met de hand, ook de gevallen waarover je team discussieert, en houd een deel ongezien.
5. Test een klein model tegen die set. Haalt het de lat, dan verandert de kostencurve met een orde van grootte. Zo niet, dan ben je een paar dagen kwijt en heb je een evaluatie gewonnen die je toch al nodig had.

Als stap 5 mislukt, was de oefening niet zinloos. De gelabelde set is wat je vertelt of het systeem überhaupt werkt, op welk model dan ook.

Waar het kleine model niet thuishoort

Een paar dingen zijn het waard om duidelijk te zeggen, want het kostenargument is verleidelijk.

Een kleiner model gaat doorgaans minder goed om met invoer die op niets lijkt waarop het is getraind, en productie levert die invoer betrouwbaar aan. Het heeft minder wereldkennis om op terug te vallen als de prompt onvoldoende is gespecificeerd. En een model dat is bijgetraind op de verdeling van vorig kwartaal gaat achteruit naarmate de verdeling verschuift, wat betekent dat iemand verantwoordelijk is voor hertrainen en iemand voor het opmerken ervan.

De besparingen blijven echt, en ze blijven voorwaardelijk. De voorwaarde is dezelfde als altijd: je meet het op je eigen data en blijft meten. Een systeem waar niemand naar kijkt, is bij geen enkele modelgrootte goedkoop.

Hoe wij dit toepassen

De modelkeuze valt binnen de bouw, nadat de workflow begrepen is. Elk systeem in onze catalogus van AI-systemen wordt afgebakend als één workflow met een schriftelijke succesmaatstaf die vóór de ontwikkeling is afgesproken, en dat is precies de specificatie die een klein model nodig heeft. Onze productieretainer bestaat omdat het meten niet stopt bij de lancering: uitvoer wordt maandelijks tegen basiswaarden gecontroleerd, en dat is wat een gespecialiseerd model betrapt dat wegdrijft van een taak die in beweging is.

Wordt de workflow nog ontdekt, dan bouwen we hem op een frontiermodel en zeggen we dat ook. De besparingen komen later, op basis van bewijs.

Bronnen

• Small Language Models are the Future of Agentic AI, Belcak, Heinrich, Diao, Fu, Dong, Muralidharan, Lin en Molchanov: arxiv.org/abs/2506.02153
• Small Language Models for Efficient Agentic Tool Calling: Outperforming Large Models with Targeted Fine-tuning, Jhandi, Kazi, Subramanian en Sendas: arxiv.org/html/2512.15943v2