Welk open-weight AI-model past bij jouw bedrijf: vergelijking en stappenplan

Er is nooit een beter moment geweest om AI op je eigen voorwaarden te draaien, en nooit een verwarrender. In korte tijd verschenen er een handvol open-weight modellen die elk claimen de slimste, goedkoopste of meest capabele te zijn: GLM-5.2, Kimi K2.7, DeepSeek V4, MiniMax M3, DiffusionGemma. Voor een ondernemer of een IT-team dat gewoon een werkend AI-onderdeel in een product of proces wil, is dat vooral lawaai. Welk model past bij jouw taak, je budget en je eisen rond data en soevereiniteit?

De verleiding is om het model met het hoogste leaderboard-cijfer te pakken en door te gaan. Dat is bijna altijd de verkeerde zet: dat cijfer kwam tot stand met een andere opdracht, andere data en een ander succescriterium dan dat van jou. Een model kiezen is geen ranglijst overschrijven, het is een klein, gestructureerd evaluatieproces dat je in een halve dag doorloopt, mits je de juiste vragen in de juiste volgorde stelt. Hieronder loop ik dat proces stap voor stap door, met de modellen van nu als concrete voorbeelden.

Wat je nodig hebt

Voordat je begint, leg je een paar dingen klaar. Het scheelt je later dagen aan twijfel.

• Een scherp omschreven taak. Niet "AI inzetten", maar bijvoorbeeld "inkomende e-mails classificeren naar afdeling" of "productbeschrijvingen genereren uit een specsheet". Een model is goed of slecht ten opzichte van een taak, nooit in het algemeen.
• 20 tot 50 echte voorbeelden uit je eigen praktijk, met het antwoord dat je zou willen zien. Dit wordt je mini-benchmark. Echte, rommelige data uit je bedrijf zegt oneindig veel meer dan een academische testset.
• Een API-sleutel bij een of twee kandidaten, of een account bij een gateway die meerdere modellen achter één sleutel aanbiedt (zoals OpenRouter of Baseten). Zo test je zonder meteen iets te hoeven hosten.
• Een simpele meetopzet: een spreadsheet of een kort scriptje dat per voorbeeld het modelantwoord, de tokens en de kosten bijhoudt.
• Helderheid over je harde eisen: wat mag wel en niet met je data gebeuren (AVG), welke licentie je nodig hebt voor commercieel gebruik, en in welke taal het moet werken.

Het stappenplan

Een open-weight model kies je niet op een leaderboard, maar op jouw taak. Definieer de opdracht, leg je harde eisen vast rond kosten, context, licentie, taal en data, bouw een mini-benchmark met je eigen voorbeelden, vergelijk de kandidaten op kosten per taak in plaats van per token, en kies pas daarna tussen een kant-en-klare API en self-hosting. Doorloop deze zes stappen in volgorde.

1. Begin bij de taak, niet bij het model

Schrijf in één zin op wat het model moet doen, voor wie, en wanneer het antwoord goed is. "Classificeer support-tickets in vijf categorieën, en fout is erger dan twijfel" geeft je een meetlat. Een vage opdracht ("slimmer worden met AI") geeft je niets om op te toetsen, en dan kies je uiteindelijk op onderbuik of op marketing van de aanbieder.

2. Leg je harde eisen vast

Dit zijn de criteria die een model meteen afvallen als het er niet aan voldoet, los van hoe slim het is. De belangrijkste:

• Capability voor jouw taakcategorie: redeneren, coderen, lange documenten, of agentisch handelen. Een coding-specialist is niet automatisch goed in klantcommunicatie.
• Contextvenster: hoeveel tekst je in één keer kwijt moet. De huidige generatie loopt sterk uiteen, van 256K tokens bij Kimi tot een miljoen bij DeepSeek V4 en GLM-5.2.
• Kosten: zowel de API-prijs per miljoen tokens als, bij self-hosting, je GPU-kosten.
• Licentie: "open-weight" is geen synoniem voor "vrij commercieel te gebruiken". GLM-5.2 staat onder een MIT-licentie, andere modellen onder eigen voorwaarden. Lees ze voordat je bouwt.
• Taal en AVG: hoe goed het Nederlands is, en of je je data wel naar de API van die aanbieder mag sturen.

3. Bouw een mini-benchmark met je eigen data

Draai je 20 tot 50 voorbeelden door elke kandidaat met exact dezelfde prompt. Scoor de antwoorden zelf, met een simpel cijfer of een goed/fout. Dit is de stap die de meeste mensen overslaan en die het meeste oplevert: je ontdekt dat het model dat op papier won, op jouw rommelige praktijkdata juist struikelt, of dat een veel goedkoper model ruim voldoet. De leaderboards meten een gemiddelde over taken die niet de jouwe zijn; jouw benchmark meet precies de jouwe.

4. Vergelijk op kosten per taak, niet per token

De prijs per miljoen tokens is een valstrik. Wat telt, is wat één echte klus kost, en daar zit het verbruik van het model in. Een redeneermodel dat per antwoord tienduizenden "denk"-tokens verstookt, kan per token spotgoedkoop zijn en per taak alsnog duur uitvallen. GLM-5.2 illustreert dat scherp: het verbruikt rond de 43.000 uitvoertokens per benchmarktaak, waarvan zo'n 37.000 puur redeneren, waardoor een enkele taak ongeveer 0,46 dollar kost, ondanks een ogenschijnlijk nette tokenprijs.

Zet de kandidaten daarom naast elkaar op de cijfers die je echt nodig hebt:

De spreiding is enorm: DeepSeek V4-Flash kost 0,14 dollar per miljoen invoertokens, terwijl een coding-specialist als Kimi, met zijn 256K context en focus op agentisch coderen, een veelvoud daarvan vraagt op de uitvoer. Naast deze vier zijn er nog kapers op de kust: MiniMax M3 mikt op dezelfde coding- en agent-taken tegen een laag verbruik, en het kleine DiffusionGemma van Google is gemaakt om volledig lokaal op bescheiden hardware te draaien. Welke wint, hangt af van jouw mix van capability, context en prijs, niet van het hoogste cijfer.

5. Kies je deployment: API of self-hosted

Nu pas wordt de vraag relevant of je het model bij de aanbieder via een API draait of het zelf host. Een API is in minuten live en je betaalt per gebruik, maar je data verlaat je infrastructuur en je bent afhankelijk van de uptime en het prijsbeleid van die partij. Self-hosting geeft je controle, voorspelbare kosten bij volume en datasoevereiniteit, maar je betaalt in GPU-capaciteit en beheer. Een model dat per uur stilstaande GPU-tijd kost, kan duurder uitvallen dan een API zolang je volume laag is, iets dat ik uitwerk in wat AI echt kost per miljoen tokens bij open-weight versus een cloud-API. De keuze laat zich tot een korte beslisboom terugbrengen:

De vuistregel: stuur je gevoelige persoonsdata in en heb je eigen of Europese GPU-capaciteit, dan is self-hosting de veilige route; is de data niet gevoelig, dan is een API meestal sneller en goedkoper om mee te beginnen. Twijfel je over die afweging in het algemeen, dan leg ik in waarom ik vaak voor self-hosted kies boven de cloud uit hoe ik dat per project weeg.

6. Beslis, documenteer en plan een herijking

Leg je keuze vast in een paar regels: welk model, voor welke taak, tegen welke gemeten score en kosten, en waarom je de alternatieven liet vallen. Dat document is goud waard als over een paar maanden het volgende model verschijnt, want dan herhaal je niet de hele exercitie maar draai je alleen je bestaande mini-benchmark opnieuw. Plan die herijking ook echt in; in dit tempo is "de beste keuze" een momentopname.

Veelgemaakte valkuilen

• Leaderboard-jagen. Het hoogste cijfer op een publieke benchmark voorspelt niet je resultaat op jouw taak. Vertrouw op je eigen voorbeelden, niet op een ranglijst.
• Rekenen per token in plaats van per taak. Een lage tokenprijs verbergt soms een hoog verbruik. Reken altijd door naar de kosten van één complete klus.
• Het contextvenster overschatten. Een miljoen tokens context betekent niet dat het model alles in dat venster even goed gebruikt, en lange contexten kosten extra. Test met je echte documentlengtes.
• De licentie niet lezen. "Open-weight" zegt niets over commerciele voorwaarden. Controleer of de licentie (MIT of een eigen variant) jouw gebruik echt toestaat.
• Self-hosting onderschatten. GPU-leegloop, updates en monitoring zijn echt werk. Reken die mee, anders is je goedkope model duurder dan de API die je vermeed.
• Data zonder afspraken naar een externe API sturen. Voordat klantdata naar een model gaat, horen een verwerkersovereenkomst en een check tegen je AVG-verplichtingen erbij; voor het MKB heb ik dat samengevat in een AI Act-nalevingschecklist met een praktisch stappenplan.

Kant-en-klaar vs. maatwerk

De eerlijke afweging zit niet in "open versus gesloten", maar in hoeveel je zelf wilt beheren.

Kant-en-klaar is een open-weight model afnemen via de API van de aanbieder of een gateway. Je bent dezelfde dag live, betaalt per gebruik en hoeft niets te draaien. Het past uitstekend voor lage tot gemiddelde volumes, voor experimenteren, en wanneer je data niet bijzonder gevoelig is. De prijs is afhankelijkheid: je staat op het prijsbeleid en de beschikbaarheid van die partij, en je data passeert hun servers.

Maatwerk is het model zelf hosten op eigen of Europese infrastructuur, eventueel bijgeschaafd op jouw data, met een eigen evaluatieharnas eromheen. Dat kost meer in opzet en beheer, maar geeft voorspelbare kosten bij volume, volledige controle over je data en echte soevereiniteit. Het loont zodra je volume hoog en stabiel is, je data gevoelig is, of het AI-onderdeel zo centraal in je product staat dat je er niet afhankelijk van wilt zijn.

Voor de meeste bedrijven is de slimste route een combinatie: begin kant-en-klaar via een API om snel te leren wat werkt, en verhuis pas naar self-hosting als het volume, de gevoeligheid van de data of de kosten dat rechtvaardigen. Zo betaal je nooit voor infrastructuur die je nog niet nodig hebt, en zit je nooit vast aan een leverancier die je niet hebt gekozen.

Welk model je uiteindelijk kiest, is minder belangrijk dan dat je het kiest op basis van jouw werk in plaats van andermans cijfers. De modellen van vandaag zijn over een half jaar weer ingehaald, maar het proces, je taak scherp, je eigen voorbeelden, je echte kosten, blijft staan. Wie dat proces één keer goed inricht, kan elke nieuwe golf modellen rustig laten passeren en er op het juiste moment de krenten uit pikken.