Wie voor het eerst een open taalmodel uitzoekt, komt op een lijst met tientallen namen en één geruststellende gedachte: het is open, dus het mag. Die gedachte klopt niet. "Open" zegt in dit vak alleen dat je de gewichten kunt downloaden. Wat je ermee mag, wie het maakte en hoe goed het Nederlands kan, zijn drie losse vragen, en ze bepalen samen of een model in jouw omgeving thuishoort. Dit artikel loopt ze langs voor de modellen die we op onze eigen inference-omgeving tegenkomen.
Open-weight is niet open source
Een model bestaat uit gewichten: een groot bestand met getallen. Als de maker dat bestand publiceert, heet het model open-weight. Dat zegt niets over de trainingsdata, de trainingscode of de voorwaarden. De voorwaarden staan in de licentie, en daar zit het verschil.
Apache 2.0 en MIT zijn echte open-sourcelicenties: je mag het model commercieel gebruiken, aanpassen, fine-tunen en doorleveren, zonder toestemming te vragen. Een eigen licentie van de maker kan daar op elk punt van afwijken. Lees dus niet de naam van het model, maar de licentie erbij.
Zo ziet dat er op dit moment uit voor de bekendste open modellen:
- Mistral Small 3.2 (24B, Frankrijk) — Apache 2.0. De grotere Mistral-modellen bestaan ook, maar vragen ruimte die in een middelgrote omgeving niet past.
- gpt-oss-20b en 120b (OpenAI, VS) — Apache 2.0.
- EuroLLM-9B en 22B (EU-consortium) — Apache 2.0, getraind op alle EU-talen.
- Gemma 3 27B (Google, VS) — de Gemma-gebruiksvoorwaarden, geen open-sourcelicentie. Bruikbaar, maar je tekent bij de maker.
- Qwen 3.x (Alibaba, China) — Apache 2.0. DeepSeek (China) — MIT.
- Llama 4 (Meta, VS) — de Llama Community License. Geen open-sourcelicentie, en voor de multimodale Llama-modellen (3.2 en later, en Llama 4) zijn bedrijven die in de EU gevestigd zijn uitgesloten van de licentie.
Die laatste regel wordt vaak over het hoofd gezien. Een Nederlands bedrijf dat een multimodaal Llama-model inzet, doet dat zonder geldige licentie, hoe open het model ook oogt.
Hoe goed is het in het Nederlands
De meeste open modellen zijn vooral op Engels getraind. Nederlands doen ze erbij, en hoe goed, verschilt per model meer dan de parameteraantallen suggereren.
Twee dingen om te weten. Ten eerste de benchmarks: op EuroEval, de Europese benchmarkset, staan de Gemma- en Qwen-modellen bij de beste open modellen voor Nederlands. EuroLLM is de enige in dit rijtje die Nederlands als eersterangs taal behandelt; EuroLLM-9B scoort goed op herschrijven naar eenvoudige taal, wat voor overheid en zorg vaak de hoofdtoepassing is. Mistral Small is in het Nederlands redelijk, niet uitmuntend.
Ten tweede de tokenizer. Nederlands kost meer tokens per woord dan Engels: ruwweg 1,3 tot 1,6 tokens per woord tegen zo'n 1,3 voor Engels, afhankelijk van de tokenizer. Een Nederlandse prompt van 1.000 woorden kan dus 1.600 tokens zijn waar dezelfde tekst in het Engels 1.300 kost. Dat is 20 procent meer context die je verbruikt en 20 procent meer die je betaalt, bij een model dat per token afrekent. Het is een indicatie, geen vaste factor, maar reken het mee als je modellen vergelijkt.
Herkomst is een keuze, geen detail
Technisch zijn Qwen en DeepSeek sterk, en hun licenties zijn ruim. Toch kiezen de meeste van onze klanten ze niet, en dat heeft weinig met de kwaliteit te maken.
Een model dat je lokaal draait, stuurt niets naar zijn maker. De gewichten zijn een bestand; er zit geen verbinding naar China of de VS in. Dat is iets anders dan de app of de API van diezelfde maker gebruiken: rijksambtenaren mogen de DeepSeek-app bijvoorbeeld niet gebruiken, en die regel gaat over de dienst, niet over de gewichten. Maar imago en afhankelijkheid spelen wel. Wie aan een gemeente of een zorginstelling moet uitleggen welk model de brieven schrijft, wil die vraag kunnen beantwoorden zonder voetnoot. En wie zijn prompts op één model afstemt, wil weten of de maker over twee jaar nog een opvolger uitbrengt onder dezelfde voorwaarden.
Daarom zetten we bij elk model een herkomstlabel: wie het maakte en onder welke licentie. Modellen uit China draaien we alleen op verzoek, nooit als standaardkeuze. Dat is geen oordeel over de techniek; het is zodat de keuze bij jou ligt en uitlegbaar blijft.
Past het in het geheugen
De laatste vraag is de nuchterste: past het model op de hardware die je hebt. Geheugen bepaalt dat, niet rekenkracht. Een model dat niet in het geheugen past, draait niet, hoe snel de kaart ook is.
De rekenregel voor de gewichten is parameters maal bytes per parameter:
- BF16 — 2 bytes per parameter. Een model van 24B parameters vraagt dan ongeveer 48 GB.
- 4-bit-kwantisatie (AWQ of GPTQ) — ongeveer een halve byte per parameter plus overhead. Datzelfde model van 24B past dan in ongeveer 14 GB.
- FP8 — 1 byte per parameter, alleen op nieuwere hardware.
Kwantisatie kost een beetje kwaliteit, meestal weinig merkbaar, en maakt het verschil tussen een model dat op één kaart past en een model dat er twee nodig heeft.
Daarbovenop komt de KV-cache: het werkgeheugen van elk gesprek dat op dat moment loopt. Die groeit met het aantal gelijktijdige gebruikers en met de lengte van hun context. De gewichten bepalen dus óf een model past; de KV-cache bepaalt hoeveel gebruikers er tegelijk op kunnen. Wie alleen naar de gewichten rekent, heeft een model dat precies past en vervolgens één gebruiker tegelijk bedient.
Open modellen bij Xyphen IT
Op onze inference-omgeving in Ede draaien we kleine en middelgrote open modellen, elk met een herkomstlabel en een licentie die we kunnen uitleggen. Welke modellen dat zijn en hoe je ze via de API aanspreekt, staat op de technische pagina. Wil je een model dedicated draaien, of een eigen fine-tune op eigen hardware naast ons netwerk, dan kan dat via GPU-colocatie in hetzelfde datacenter als onze BIT-colocatie.
Twijfel je welk model bij je toepassing past? Vraag een voorstel aan of neem contact op; dan rekenen we het geheugen en het Nederlands met je door.