Hoe open is Mistral als je de licentie leest?
In het kort
Mistral biedt modellen onder verschillende licenties en tegelijk als API. Wie alleen “open” leest, mist welke rechten en operationele kosten bij de gekozen variant horen. De actuele modelkaart en prijsdocumentatie zijn belangrijker dan een losse benchmark of productnaam. We rekenen terug vanaf de kosten en toetsen welke inzet in 2027, 2028 en 2029 nodig is. De conclusie is voorwaardelijk: alleen aantoonbaar geslaagde taken tellen mee.
De AI-markt lijkt op het eerste gezicht steeds eenvoudiger. Iedere leverancier heeft een vlaggenschip, een goedkoper model en een indrukwekkende contextlengte. In de praktijk wordt de keuze juist lastiger. Toegang kan beperkt zijn, een introductietarief kan aflopen en open gewichten kunnen onder verschillende licenties vallen. De modelnaam is daarom hooguit het begin van het onderzoek.
Bij Mistral draait de dragende vraag om licentie per model en de keuze tussen zelf hosten en een beheerde API. Dat is geen academisch verschil. Het bepaalt of een experiment ook als vaste dienst kan draaien, of de rekening beheersbaar blijft en hoeveel menselijk herstelwerk nodig is. Een goed model dat te vaak op de verkeerde taak wordt gezet, is economisch nog steeds een slechte keuze.
Direct naar een onderdeel van dit artikel
Wat er werkelijk beschikbaar is
Mistral gebruikt niet één licentie voor de hele catalogus. De actuele documentatie noemt Apache 2.0 voor Small 4, Large 3 en de Ministral 3-familie, terwijl Medium 3.5 onder een Modified MIT-licentie valt. Small 4 kost via de API $0,15 per miljoen inputtokens en $0,60 per miljoen outputtokens. De praktische keuze is dus zowel juridisch als technisch. De Mistral-modelcatalogus is daarbij het uitgangspunt. De peildatum is 5 oktober 2026 en de relevante gebeurtenis is: Mistral Small 4, Large 3 en Ministral 3 actueel op 5 oktober 2026.
De woorden algemeen beschikbaar, preview en beperkt toegankelijk horen niet op één hoop. Een aangekondigd model kan technisch bestaan zonder dat een normaal bedrijf het vandaag via een stabiele API kan afnemen. Andersom kan een downloadbaar model open gewichten bieden terwijl de licentie aanvullende voorwaarden stelt. Gratis proberen in een chatdienst geeft nog geen recht om het model zelf te hosten.
Ook contextlengte vraagt nuchterheid. Een bovengrens van honderdduizenden of een miljoen tokens vertelt hoeveel invoer technisch mogelijk is. Zij zegt niet dat zoveel context snel, goedkoop of zorgvuldig wordt verwerkt. Lange prompts vergroten de prefilltijd, vragen cachegeheugen en kunnen relevante details tussen ruis laten verdwijnen. Voor een vergelijking moeten daarom dezelfde taak, dezelfde context en dezelfde succesdefinitie worden gebruikt.
De techniek verandert de rekening
Apache 2.0 geeft ruime rechten, maar zelf hosten blijft werk. Een API koopt beheer, schaalbaarheid en updates. Eigen hosting koopt controle over data, latency en wijzigingsmomenten. Een organisatie kan beide combineren: stabiele volumes lokaal en pieken via de API. Dat werkt alleen wanneer evaluaties en uitvoerformaten aan beide kanten gelijk blijven.
Dat maakt kosten per miljoen tokens nuttig, maar onvoldoende. De betere maat is kosten per succesvol afgeronde taak. Daarin horen input, output, redenering, gereedschap, cache, herhaalpogingen en menselijke controle. Wanneer een goedkoper model twee herstelrondes nodig heeft, kan de duurdere route alsnog winnen. Wanneer een topmodel een eenvoudige extractietaak niet beter uitvoert, betaalt een bedrijf alleen voor ongebruikte capaciteit.
Voor lokale modellen komt daar een andere kostenlaag bij. Alle gewichten moeten in opslag en meestal in werkgeheugen beschikbaar zijn, ook wanneer een mixture-of-expertsmodel per token slechts een deel activeert. Quantisatie kan het beslag verlagen, maar kan kwaliteit en snelheid veranderen. Gelijktijdige gebruikers en lange context voegen KV-cache toe. Een model dat één keer op een werkstation antwoord geeft, is daarmee nog geen productiesysteem.
De beslissende rekensom
Voor een vergelijkbaar voorbeeld gebruiken we deze kostenbrug: Input € 3, Output € 2, API totaal € 5. De waarden zijn afkomstig uit het gepubliceerde tarief of, waar geen controleerbaar tarief bestaat, uit een expliciet gemarkeerd eigen kostenbudget. Dat verschil is belangrijk. Een scenario-aanname is geen prijsclaim van de leverancier en een dollarbedrag is zonder belasting en wisselkoers geen Nederlandse factuur.
De omgekeerde berekening begint niet bij een mooie benchmark, maar bij de vraag hoeveel productiviteit nodig is om € 65 per jaar terug te verdienen. Bij een interne waarde van € 55 per aantoonbaar bespaard uur is dat 1.2 uur per jaar. De formule is eenvoudig: jaarlijkse kosten gedeeld door € 55. De moeilijke stap is bewijzen dat die uren werkelijk vrijkomen bij gelijkblijvende kwaliteit.
Een team moet daarom een vaste proefset gebruiken en per taak noteren of het eerste antwoord bruikbaar was, hoeveel correctietijd nodig was en of een mens dezelfde controle toch moest uitvoeren. Alleen het verschil met de bestaande werkwijze telt. Tijd die wel op papier wordt bespaard maar later terugkomt als herstelwerk, mag niet dubbel als voordeel worden geboekt.
Drie jaar vooruit rekenen
De scenario’s voor 2027 tot en met 2029 gebruiken drie niveaus van aantoonbaar bespaarde tijd en laten het volume jaarlijks met 12 procent groeien. Het lage scenario start bij 20 uur, het middenscenario bij 62 uur en het hoge bij 116 uur. De jaarlijkse kosten blijven bewust gelijk, zodat zichtbaar wordt welke benutting de doorslag geeft. Het zijn aannames, geen voorspellingen van gebruik of tarieven.
De netto productiviteitswaarde is bespaarde uren maal € 55, minus de jaarlijkse kosten. Implementatie-uren in het eerste jaar horen daar in een echte businesscase nog vanaf. Hetzelfde geldt voor kwaliteitsverlies, uitval en extra gegevensbeheer. Een positieve uitkomst bewijst dus niet dat het model winst oplevert. Zij laat alleen zien hoeveel economische ruimte overblijft om die overige kosten op te vangen.
Voor kleine teams kan de lage variant al ruim voldoende zijn wanneer de vaste kosten gering zijn. Bij eigen hardware of een omvangrijk abonnement ligt de drempel hoger en wordt bezettingsgraad doorslaggevend. Andersom kan een goedkoop API-model zo weinig kosten dat vooral foutpreventie telt. Dan is één vermeden uur herstelwerk meer waard dan een jaar aan tokens.
Waar het nog mis kan gaan
De woorden open en commercieel mogen niet als kwaliteitslabel worden gebruikt. Een open-weightmodel kan uitstekend zijn en toch veel beheer vragen. Een commerciële API kan goedkoop zijn en toch een afhankelijkheid creëren. Daarnaast moet de gekozen quantisatie bij lokale inzet apart worden beoordeeld; een kleinere geheugenvoetafdruk kan nauwkeurigheid of snelheid veranderen.
Daarnaast blijft leveranciersrisico bestaan. Modellen verdwijnen, aliassen verschuiven en prijzen kunnen veranderen. Een goede integratie bewaart prompts en evaluaties buiten het model, houdt een alternatieve route beschikbaar en legt vast welke versie op welk moment is gebruikt. Daardoor wordt een upgrade een gecontroleerde keuze in plaats van een verrassing in productie.
Privacy verdient dezelfde concrete aanpak. Cloudgebruik vraagt duidelijkheid over opslag, training en gegevenslocatie. Lokale inzet voorkomt niet automatisch alle risico’s, want logbestanden, toegangsrechten en onveilige plug-ins kunnen gegevens alsnog blootleggen. Het juiste antwoord is dus niet altijd lokaal of altijd cloud. Het is een aantoonbare keuze per datastroom.
Wat dit economisch betekent
Voor bedrijven is Mistral interessant wanneer de gekozen route aantoonbaar beter past bij het werk dan een goedkoper of eenvoudiger alternatief. Dat bewijs komt uit eigen taken, niet uit één benchmark. Het minimum is een vergelijking van eerste-poging-succes, totale doorlooptijd, menselijk herstel en alle directe kosten. Pas daarna kan een groter contextvenster, een open licentie of een sterkere redeneermodus economische waarde krijgen.
Voor beleggers ligt de les een niveau hoger. Lagere tokenprijzen kunnen het gebruik vergroten, maar leiden niet automatisch tot hogere winst bij de modelleverancier of chipmaker. Open modellen kunnen hardwarevraag stimuleren en tegelijk prijsdruk op API’s zetten. De waarde verschuift naar distributie, gereedschappen, datatoegang, betrouwbaarheid en capaciteit. Wie alleen naar de nieuwste modelnaam kijkt, mist precies het deel waar het verdienmodel wordt gemaakt.
De nuchtere conclusie is daarom dat licentie per model en de keuze tussen zelf hosten en een beheerde API de keuze moet sturen. Begin met de kleinste route die de taak aantoonbaar goed afrondt. Schaal pas op wanneer de extra kwaliteit meer waard is dan de extra kosten. Zo blijft een indrukwekkend model een productiemiddel en wordt het geen dure demonstratie.
Een maandelijkse herhaling van dezelfde proef maakt prijswijzigingen en kwaliteitsverschuivingen zichtbaar voordat ze de begroting of de dienstverlening raken. Dat kleine meetritme is uiteindelijk waardevoller dan een eenmalige ranglijst.
Opmerkingen