De vraag is niet langer of een open model kan concurreren met een propriëtair model, maar bij welke concrete taken het dat doet en tegen welke werkelijke kosten. In 2025 migreerden veel teams een deel van hun AI-stack naar downloadbare gewichten en ontdekten twee dingen: dat de besparing op API-kosten niet altijd opweegt tegen de infrastructuurkosten, en dat de licentie meer uitmaakt dan het lijkt wanneer het product in productie gaat.
Hier vind je geen vlakke ranglijst. Je vindt welke families van open modellen verdedigbare resultaten opleveren, waar ze tekortschieten ten opzichte van betaalde modellen en hoe je kunt beslissen met criteria die de volgende release overleven.
De echte kaart: wat «open source» betekent bij taalmodellen
Voordat je gaat vergelijken, is het verstandig een ambiguïteit te ontleden die verkeerde beslissingen veroorzaakt. Bijna geen enkel model dat open wordt genoemd, voldoet aan de strikte definitie van de OSI. Gebruikelijk zijn downloadbare gewichten met licenties voor communitygebruik die beperkingen opleggen: limieten op het aantal maandelijkse gebruikers, verbod op concurrerend gebruik, verplichting om de naam van het model in de interface te tonen of clausules voor commerciële opschaling.
Dit heeft een praktisch gevolg: een model kan gratis zijn voor prototyping en duur — juridisch gezien — wanneer het groeit. De Llama-familie is het klassieke voorbeeld van een licentie met een gebruikersdrempel; Qwen en DeepSeek publiceren een groot deel van hun gewichten onder Apache 2.0, wat commerciële integratie zonder juridische wrijving vergemakkelijkt; Mistral combineert Apache-licenties voor zijn kleine modellen met onderzoekslicenties voor de grote. Voordat je op basis van benchmarks kiest, controleer je de licentie van het specifieke model dat je gaat implementeren, niet die van de repository in het algemeen.
Open modellen die in 2025 een test verdienen
Llama (Meta) blijft de facto de standaard van het ecosysteem. Het voordeel is niet de ruwe prestaties maar de volwassenheid van de tooling: kant-en-klare kwantiseringen, ondersteuning in Ollama, vLLM en llama.cpp, en een community die snel vragen beantwoordt. De 8B-variant is een werkpaard voor classificatie, extractie en samenvattingen; de grotere formaten concurreren op redeneren maar vereisen hardware die zelden op het bureau van een ontwikkelaar staat.
Qwen heeft terrein gewonnen in meertalige taken en codetaken. De kleine versies verrassen bij het genereren van SQL en bij het begrijpen van instructies met een strikt formaat, en de Apache-licentie op veel van de gewichten elimineert het juridische debat. Bij tests voor het extraheren van gestructureerde data uit rommelige tekst volstaat een Qwen-model van gemiddelde grootte vaak waar een groot propriëtair model overgedimensioneerd zou zijn.
DeepSeek heeft aangetoond dat een lab met minder middelen concurrerende modellen kan publiceren voor wiskundig redeneren en code. De keerzijde is de ondoorzichtigheid over de trainingsdata en de noodzaak om biases te valideren in gereguleerde domeinen.
Mistral handhaaft een Europees aanbod met goede resultaten op instructietaken en een actieve community rond zijn kwantiseringsformaten.
Gemma (Google) biedt open gewichten met een conservatieve benadering op het gebied van veiligheid, nuttig wanneer je een model nodig hebt dat standaard geen problematische inhoud genereert, hoewel de licentie ook gebruiksvoorwaarden heeft.
Waar het open model zonder discussie wint
Er zijn scenario’s waarin de vergelijking niet eens zinvol is omdat het propriëtaire model niet kan bieden wat je nodig hebt.
Data die je infrastructuur niet mogen verlaten
Als je klinische dossiers, juridische dossiers of persoonsgegevens onder strikte regelgeving verwerkt, vereist het versturen van prompts naar een externe API een risicoanalyse die veel juridische teams niet goedkeuren. Een open model dat lokaal draait, elimineert de gegevensoverdracht. Het elimineert niet de verantwoordelijkheid: je moet nog steeds registreren welk model je hebt gebruikt, met welke versie en welke prompts, omdat traceerbaarheid ook een verplichting is.
Hoog en voorspelbaar volume
Wanneer je belasting constant is en het model past op een GPU die je al hebt, tendeert de marginale kosten per token naar nul. Een typisch geval: duizenden dagelijkse tickets classificeren in vaste categorieën. Een model van 7-8B gekwantiseerd naar 4 bits draait op een consumenten-GPU en doet die taak met een nauwkeurigheid die, na een lichte fine-tuning met eigen voorbeelden, in dat nauwe domein gelijk is aan veel grotere propriëtaire modellen. De sleutel is dat de taak afgebakend is; als je open redeneren nodig hebt, verandert de berekening.
Gecontroleerde latentie en geen afhankelijkheid van derden
Voor interactieve applicaties waar 300 ms extra de ervaring verpest, of voor producten die zich geen uitval van de leverancier kunnen permitteren, geeft eigen implementatie controle. Het geeft ook de verplichting om het te monitoren, iets wat veel teams onderschatten.
Waar het betaalde model de verstandige keuze blijft
Eerlijkheid gebiedt het te zeggen: bij complexe redeneringen in meerdere stappen, bij het volgen van lange instructies en bij taken die context van honderdduizenden tokens vereisen, behouden de grensverleggende propriëtaire modellen hun voorsprong. Een open model van gemiddelde grootte kan een correcte functie schrijven; vragen om over een hele repository te redeneren en een samenhangende refactor voor te stellen levert vaak fragiele resultaten op.
Er is ook een factor die zelden in vergelijkingen voorkomt: de onderhoudskosten. Kiezen voor een open model betekent gewichten versioneren, updates beheren, continue evaluatie opzetten en accepteren dat de community op een dag stopt met het onderhouden van de kwantisering die je gebruikt. Dat werk heeft een prijs in engineeringuren die, in kleine teams, maandenlang de API-kosten overtreft.
Een veelgemaakte fout die ik steeds weer zag terugkomen
Teams die naar een open model migreren omdat het op een publieke benchmark goed scoort en vervolgens ontdekken dat hun concrete use case — bijvoorbeeld het extraheren van velden uit gescande facturen met heterogene templates — systematisch faalt. De benchmark mat algemeen redeneren, niet het vermogen om een JSON-schema met geneste velden en null-waarden te respecteren. De les: stel een evaluatieset samen met 50-100 echte voorbeelden uit je domein voordat je beslist. Als het open model die test niet doorstaat, is de besparing fictief.
Hoe je vergelijkt zonder in de ruis van ranglijsten te vallen
Leaderboards veranderen elke week en mengen taken die niet op elkaar lijken. Een nuttiger benadering is je eigen beslissingsmatrix bouwen met vier assen:
- Licentie en compliance: staat het commercieel gebruik toe zonder drempels? Vereist het naamsvermelding? Wat gebeurt er als je een bepaald volume overschrijdt?
- Pasvorm op hardware: past het op je GPU met de kwantisering die je nodig hebt? Welke werkelijke throughput haal je met vLLM of llama.cpp?
- Kwaliteit in je domein: resultaten op je eigen evaluatieset, niet op MMLU.
- Totale kosten: API versus infrastructuur plus onderhoudsuren.
Een technisch detail dat het verschil maakt en over het hoofd wordt gezien: kwantisering degradeert sommige taken meer dan andere. Creatieve generatie verdraagt 4 bits goed; wiskundig redeneren en nauwkeurige data-extractie lijden meer. Dezelfde taak testen met het model in fp16 en in gekwantiseerde vorm vertelt je of de VRAM-besparing het verlies rechtvaardigt.
Hybride strategie: wat in de praktijk werkt
De dichotomie gratis versus betaald is misleidend. De architectuur die in echte projecten de beste resultaten oplevert, combineert beide: een klein open model voor het grootste deel van het verkeer (classificatie, filtering, korte samenvattingen, FAQ-antwoorden) en een propriëtair model als back-up voor de queries die het kleine model vanwege lage betrouwbaarheid doorstuurt. Dit patroon verlaagt de kosten zonder kwaliteit in te leveren in de moeilijke gevallen, en is gemakkelijker te verantwoorden aan de business dan een volledige migratie.
Het is ook goed om te onthouden dat «gratis» niet bestaat bij inferentie: iemand betaalt de elektriciteit, de GPU en de tijd van degene die de implementatie onderhoudt. De juiste vraag is niet welk model gratis is, maar welk model lagere totale kosten heeft voor jouw volume en jouw team.
Waar op te letten in de komende maanden
Het tempo waarin open gewichten worden gepubliceerd neemt niet af, en de kloof met de grensverleggende modellen wordt bij sommige taken kleiner terwijl die bij andere blijft bestaan. Twee fronten verdienen aandacht: de licenties, die de neiging hebben strenger te worden wanneer een model populair wordt, en de evaluatietools, die nog steeds de zwakke schakel zijn. Een model zonder een goed eigen evaluatiesysteem is een zwarte doos met goede pers.
Als ik het criterium zou moeten samenvatten: test open modellen eerst bij afgebakende en meetbare taken, reserveer propriëtaire modellen voor wat breed redeneren vereist, en neem geen enkele beslissing zonder een evaluatieset die met je eigen data is opgebouwd. Dat is de enige vergelijking die niet de volgende maand al verouderd is.