Open source LLM’s: mythen en realiteiten in het bedrijf

De ruis rond open modellen

Wanneer een directieteam voor het eerst naar open source LLM’s vraagt, begint het gesprek meestal met een grote belofte en een nog grotere twijfel. Mythen circuleren sneller dan technische documentatie. En beslissingen worden in veel gevallen genomen op basis van informatie uit tweede hand. Dit artikel beoogt niet de adoptie van open modellen te verkopen, maar wel te scheiden wat verifieerbaar is van wat zonder bewijs wordt herhaald.

Mythe 1: ‘Open source is gratis’

Het gewicht van het model is kosteloos te downloaden. Dat klopt. Wat niet gratis is, is alles wat nodig is om dat gewicht stabiel in productie te laten werken. De werkelijke kosten duiken op vier fronten op:

• Infrastructuur: een GPU met voldoende geheugen om een model van 70B met lange context te serveren is geen laptop. De huur per uur of de aankoop van de hardware heeft een kost die elke maand terugkeert.
• Engineering: iemand moet de inferentieserver opzetten, de batching afstellen, de latenties monitoren en de modelversies beheren.
• Evaluatie: elke update van het model of van de prompt vereist dat de kwaliteit opnieuw wordt gemeten. Zonder een eigen testbank navigeer je blind.
• Onderhoud: de repositories met gewichten en de inferentiebibliotheken evolueren snel. Wat zes maanden geleden werkte, kan vandaag aanpassingen vereisen.

In de praktijk kan de kost per token van een open model dat op eigen infrastructuur wordt geserveerd competitief of zelfs lager zijn dan die van een gesloten API, maar alleen vanaf een bepaald aanhoudend volume. Onder die drempel wint de API meestal op totale kost. Volgens documentatie van cloudinfrastructuurproviders overschrijdt de gemiddelde bezettingsgraad van GPU’s die aan inferentie zijn toegewezen bij kleine bedrijven zelden 30 %, wat elke geserveerde token duurder maakt.

De fout om alleen de tokenprijs te tellen

Een patroon dat zich herhaalt bij teams die de sprong wagen: ze vergelijken de prijs per miljoen tokens van de API met de prijs per uur van de GPU en concluderen dat het open model goedkoper is. Ze vergeten de opportuniteitskost van het platformteam, de integratie-uren en de tijd die aan het oplossen van incidenten wordt besteed. Een eerlijke berekening omvat die uren, zij het bij benadering.

Mythe 2: ‘Als het open is, zijn mijn gegevens standaard veilig’

Het model op je eigen infrastructuur uitvoeren elimineert de uitstroom van gegevens naar een derde partij, maar maakt het systeem niet als bij toverslag veilig. De veiligheid hangt af van hoe het wordt uitgerold, niet alleen van waar het draait. De punten die meestal buiten het initiële gesprek vallen:

• De logs van prompts en antwoorden. Als ze zonder controle worden opgeslagen, blijft het gevoelige gegeven blootgesteld, ook al is het model lokaal.
• De toegang tot het inferentie-endpoint. Zonder authenticatie en gebruikslimieten kan iedereen binnen het netwerk het model bevragen met de rechten van de dienst.
• De toeleveringsketen van het model. De gewichten die van een publieke repository worden gedownload, moeten worden geverifieerd; een corrupt of gemanipuleerd bestand is een reëel aanvalsvector.
• De inhoudsfiltering. Een open model brengt standaard niet de moderatielagen mee die een beheerde provider op zijn API toepast.

Het privacyvoordeel bestaat, maar het is een noodzakelijke, geen voldoende voorwaarde. Het vereist hetzelfde werk aan datagovernance als elk ander intern systeem.

Mythe 3: ‘Ze presteren slechter dan gesloten modellen’

Hier is de nuance erg belangrijk, en generaliseren is de fout. Bij taken met complex redeneren, wiskunde en code hebben de toonaangevende gesloten modellen gedurende een groot deel van 2025 en begin 2026 een voorsprong behouden in publieke benchmarks. Maar bij afgebakende taken — classificatie van tickets, extractie van velden uit een document, samenvatting van gesprekken met een vast formaat, generatie van antwoorden op basis van een opgehaalde context — evenaren of overtreffen open modellen van middelgroot formaat kleine gesloten modellen, met als voordeel dat je ze met je eigen gegevens kunt afstellen.

Een concreet geval dat het verschil goed illustreert: een verzekeringsbedrijf dat schadeformulieren in PDF verwerkt. Een generalistisch gesloten model maakte fouten bij het extraheren van bedragen wanneer het document tabellen en vrije tekst vermengde. Na fine-tuning van een open model van 8B met 2.000 intern geannoteerde voorbeelden steeg de nauwkeurigheid in dat specifieke formaat aanzienlijk en daalde de kost per document. Niet omdat het open model in het algemeen beter was, maar omdat het gespecialiseerd was in de exacte distributie van hun documenten. Dat is het terrein waarop open modellen uitblinken.

Waar ze niet komen (en dat is goed om te erkennen)

Een open model van 7B of 8B gaat geen vragen oplossen die meerstapsredeneringen over contexten van 200.000 tokens vereisen met dezelfde robuustheid als een gesloten model uit de topklasse. Het is ook niet de natuurlijke keuze voor creatieve taken op lange termijn waarbij stilistische coherentie cruciaal is. Als je use case daarvan afhangt, is het open model niet het antwoord, en het forceren ervan veroorzaakt frustratie bij het team en wantrouwen in de technologie.

Mythe 4: ‘Het volstaat het model te downloaden en klaar’

De afstand tussen het downloaden van gewichten en het hebben van een dienst in productie is het deel dat het minst wordt gedocumenteerd in inleidende artikelen. De tussenliggende stappen omvatten:

• Een inferentiebibliotheek kiezen die geschikt is voor de beschikbare hardware.
• Het promptingschema definiëren en samen met de code versiebeheren.
• Een retrievall aag (RAG) opzetten als het model actuele kennis van het bedrijf nodig heeft.
• Kwaliteitsmetrieken en een representatieve evaluatieset vastleggen.
• Gebruikslimieten, wachtrijen en gecontroleerde degradatie bij piekvraag configureren.

Volgens officiële documentatie van de belangrijkste serving-bibliotheken varieert de prestatie per GPU sterk naargelang de kwantiseringstechniek en de batchgrootte. Hetzelfde model kan gaan van 10 verzoeken per seconde naar 40, afhankelijk van de configuratie. Dat verschil staat niet op de fiche van het model; het komt naar voren bij het meten.

Mythe 5: ‘Open source garandeert volledige onafhankelijkheid van de leverancier’

De afhankelijkheid van een gesloten API vervangen door de afhankelijkheid van een GPU-leverancier, van een specifieke inferentiebibliotheek of van één enkele gewichtenrepository is geen onafhankelijkheid, het is van afhankelijkheid veranderen. Echte vrijheid komt er wanneer het team het model kan migreren zonder de applicatie te herschrijven. Dat vereist een abstractielaag in de code, een overdraagbaar promptformaat en een testbank waarmee kandidaten met hetzelfde criterium kunnen worden vergeleken.

Bedrijven die deze stap goed hebben gezet, hebben meestal een interne catalogus van geëvalueerde modellen, niet één enkel model. Ze kunnen van het ene naar het andere overschakelen naargelang kost, latentie of kwaliteit bij een specifieke taak. Open source maakt die flexibiliteit mogelijk; het garandeert ze niet.

Realiteit: wanneer het zinvol is en wanneer niet

Na verschillende uitrollen te hebben gezien, is het beslissingspatroon vrij consistent:

Signalen vóór

• Hoog en stabiel inferentievolume dat de investering in infrastructuur rechtvaardigt.
• Gegevens die het perimeter niet mogen verlaten om regulatorische of contractuele vereisten.
• Behoefte aan diepgaande specialisatie in een domein met eigen gelabelde gegevens.
• Kritieke latentie in omgevingen waar het netwerk naar een externe provider een onaanvaardbare sprong toevoegt.
• Vereiste van reproduceerbaarheid: precies weten welke modelversie welk antwoord gaf.

Signalen tegen

• Een team zonder platform- of MLOps-profiel en met krappe deadlines.
• Zeer uiteenlopende use cases die een generalistisch model van maximale kwaliteit vereisen.
• Lage of onregelmatige volumes waarbij de gesloten API goedkoper uitkomt.
• Gebrek aan eigen gegevens om te specialiseren: zonder fine-tuning of RAG concurreert het open model in het nadeel.

Een waarschuwing over evaluaties

Publieke benchmarks zijn een nuttige referentie, maar voorspellen niet de prestatie in jouw geval. Een model dat een generalistische tabel aanvoert, kan onderpresteren bij de specifieke taak die voor jou belangrijk is. De enige betrouwbare maatstaf is een evaluatieset opbouwen met echte voorbeelden uit je bedrijf, indien nodig geanonimiseerd, en kandidaten vergelijken met dezelfde prompt en hetzelfde correctiecriterium. Zonder die testbank steunt elke beslissing over open modellen op meningen, niet op data.

En het is goed om een beperking te onthouden die niet verdwijnt: geen enkel model, open of gesloten, garandeert resultaten. De kwaliteit van het systeem hangt af van de data, het ontwerp van de prompt, de continue evaluatie en het menselijke oordeel dat de uitvoer op de kritieke punten controleert. Open source voegt controle en opties toe; het vervangt het werk niet.