Een jaar geleden betekende het kiezen van een AI-model dat je moest kiezen uit een van de drie gesloten API's en het prijskaartje voor lief moest nemen. Die standaard is niet langer automatisch. Open-weight-releases van Meta, Mistral, DeepSeek en een groeiende lijst van laboratoria verwerken nu taken op het gebied van programmeren, samenvatten en classificatie op een niveau dat aan de meeste productiebehoeften voldoet. De vraag voor site-eigenaren is niet langer of open-weight-modellen goed genoeg zijn. Het gaat erom welke werklasten het nog rechtvaardigen om te betalen voor een gesloten API.
Wat open weight eigenlijk betekent
Een open-weight-model publiceert zijn getrainde parameters zodat iedereen ze kan downloaden en draaien. Dit betekent dat de getrainde modelgewichten downloadbaar zijn, maar de trainingsdata en de volledige trainingscode meestal niet worden vrijgegeven, en de licentie kan gebruiksbeperkingen toevoegen. Dat onderscheid is belangrijk omdat open weight niet hetzelfde is als open source in de strikte zin van het woord.
Licentievoorwaarden variëren sterk tussen leveranciers en dit creëert een reëel risico voor inkoopteams. Sommige labs brengen modellen uit onder specifieke licenties met productieplafonds, ethische gebruiksclausules of jurisdictievereisten, dus inkoop moet elke gewichtlicentie lezen vóór goedkeuring in plaats van aan te nemen dat een soepele standaard van toepassing is. De eigen Llama-overeenkomsten van Meta voegen bijvoorbeeld specifieke commerciële voorwaarden toe zodra een product een bepaalde gebruikersdrempel overschrijdt.
Mistral heeft een ander pad gekozen met zijn recente releases. Mistral Small 4 werd uitgebracht als een 119B-parameter model onder de soepele Apache 2.0-licentie, omschreven als de enige release van een groot lab zonder licentie-addertjes onder het gras. Dat soort duidelijkheid is zeldzaam genoeg om op zichzelf al nieuws te zijn.
Hoe groot is het prestatieverschil nu
Onafhankelijke monitoring geeft ons echte cijfers in plaats van beweringen van leveranciers. Sinds januari 2026 lopen de meest capabele open-weight-modellen gemiddeld vier maanden achter op de toonaangevende gesloten modellen in de Epoch Capabilities Index, met een gemiddeld verschil van 8 punten, vergelijkbaar met het verschil tussen GPT-5 en GPT-5.5. Dat is een meetbaar verschil, maar het is veel kleiner dan de jarenlange voorsprong die gesloten labs ooit hadden.
Het gat varieert ook sterk per type taak. Op programmeerbenchmarks specifiek komen GLM-5.1 en Kimi K2.6 uit rond de 58 procent op SWE-Bench Pro, op gelijke hoogte met een gesloten middenklassemodel zoals GPT-5.5, zelfs nu de absolute top van gesloten codeerders nog steeds uitloopt. Voor dagelijks tekstwerk ziet het beeld er nog sterker uit voor open modellen. Voor classificatie, extractie, samenvatting, retrieval-augmented question answering en het meeste programmeerwerk is een goed open-weight-model in 2026 geen compromis. Het klaart de klus.
Waar gesloten modellen nog steeds een duidelijke voorsprong hebben, is bij complexe, meerstapsredeneringen. De resterende voorsprong van gesloten modellen is reëel maar specifiek, en komt naar voren bij langdurige agent-redeneringen, taken die twintig, dertig of meer afhankelijke stappen omvatten, waarbij een vroege fout moet worden opgevangen en gecorrigeerd in plaats van genegeerd. Multimodaal werk vertelt een soortgelijk verhaal. Multimodaal is de categorie waar het gat tussen gesloten en open modellen het grootst blijft, omdat uniforme tekst-beeld-audio-video-redenering trainingscorpora, infrastructuur en uitlijningswerk vereist waar open-weight-releases aan de bovenkant nog niet aan kunnen tippen.
De kostenberekening is niet zo eenvoudig als ze lijkt
Prijs is de reden waarom de meeste teams überhaupt naar open-weight-modellen beginnen te kijken. Het huren van een open model van een externe host is vaak dramatisch goedkoper dan een gesloten API. Een studie naar catalogusprijzen toonde aan dat API-toegang voor open-weight gemiddeld rond de $0.23 per miljoen tokens ligt tegenover $1.86 voor gesloten modellen, ongeveer acht keer goedkoper. Dat getal beschrijft echter gehoste toegang, niet de kosten van het draaien van je eigen infrastructuur.
Self-hosting brengt kosten met zich mee die een eenvoudige prijsvergelijking mist. De economie van self-hosting draait om benutting, omdat je GPU's per uur huurt, ongeacht of er verzoeken binnenkomen, en een endpoint dat wisselend verkeer met lage benutting bedient, kan gemakkelijk per token meer kosten dan een toonaangevende API. Voeg daar de engineeringtijd voor implementatie en onderhoud aan toe, en de rekensom verschuift verder. Het toevoegen van de engineeringtijd om het te draaien, inclusief implementatie, schalen, upgrades en incidentrespons, duwt het omslagpunt verder weg dan de meeste schattingen aannemen, en die berekening werd in 2026 moeilijker omdat de GPU-capaciteit krapper werd en de huurprijzen stegen in plaats van daalden.
Onder een bepaald volume wint huren van een gespecialiseerde aanbieder het direct van self-hosting. Onder de ruwweg 100 miljoen tokens per maand winnen serverloze open-weight-API's het van zelfgehoste GPU-rigs op basis van totale kosten zodra onbenutte capaciteit, beheer en failover zijn meegerekend. De meeste kleine en middelgrote site-exploitanten zitten ruim onder die drempel, wat de beslissing eenvoudiger maakt dan de marketing suggereert.
Kiezen tussen open en gesloten voor echte projecten
Ondernemingen behandelen dit niet langer als een keuze voor het een of het ander. Onderzoek wees uit dat organisaties gemiddeld zeven modellen draaien of evalueren, waarbij 78 procent zelf enige inferentie beheert. Het volwassen patroon is een hybride model: zelfgehoste open weights voor gevoelig, hoogvolume, latentiegevoelig of offline werk, en gesloten API's voor het zwaarste redeneerwerk en de grillige staart, met een routeringslaag die per verzoek beslist. Voor een kleine exploitant is die volledige routeringsopstelling overdreven, maar de onderliggende logica is nog steeds van toepassing op kleinere schaal.
Datacontrole is vaak de beslissende factor in plaats van pure capaciteit. Als één enkele prompt die je netwerk verlaat onacceptabel is, voor patiëntendossiers, financiële gegevens, geclassificeerd materiaal of een strikt mandaat voor data-residency, is zelfgehoste open-weight meestal de enige optie die volledig aan de vereisten voldoet, waarbij gemak wordt ingeruild voor fysieke controle. Als je site klantendossiers of gereguleerde inhoud verwerkt, kan dat alleen al de vraag beantwoorden voordat prestaties zelfs maar in de discussie naar voren komen.
Voor taken met een hoog volume en lage gevoeligheid is de berekening bijna altijd in het voordeel van open weight. Als je een hoog, constant volume aan niet-gevoelige gegevens draait, zoals classificatie, samenvatting of codegeneratie over miljoenen verzoeken, wordt de factuur per token van een toonaangevend gesloten model de dominante kostenpost, wat het duidelijkste argument is voor open-weight. Houd de gesloten API bij de hand voor het incidentele moeilijke probleem en laat het goedkopere model de routinetaken uitvoeren.
Conclusie
Het debat over open weight versus gesloten API gaat niet langer over de vraag of open modellen goed genoeg zijn. Het gaat erom elke werklast te koppelen aan het juiste instrument. Gesloten API's winnen nog steeds bij de zwaarste redeneertaken en volledig multimodaal werk, maar open-weight-modellen verwerken nu de meeste dagelijkse klussen tegen een fractie van de kosten. Voordat je een gesloten API-contract vernieuwt, test een open-weight-model een week lang op je werkelijke werklast. Misschien ontdek je dat het verschil veel minder uitmaakt dan de factuur.
