← terug

10 juni 2026

Hoe je een open-source model host

"Kunnen we niet gewoon zelf zo'n model draaien? Dan blijft alles binnen." Die vraag krijg ik steeds vaker, en hij is terecht. Open modellen zoals de Llama-familie van Meta en de modellen van Mistral zijn de afgelopen jaren zo goed geworden dat zelf hosten geen hobbyproject meer is, maar een serieuze optie voor organisaties die hun data dichtbij willen houden.

Alleen zit er tussen "model downloaden" en "bruikbare AI-omgeving voor je organisatie" een flink stuk techniek. Dat stuk wordt in presentaties graag overgeslagen. Ik loop het hier stap voor stap door, zodat je weet wat je echt aanschaft als je deze route kiest.

Wat je downloadt: de modelgewichten

Een taalmodel is in de kern een gigantische verzameling getallen, de gewichten. Dat zijn de geleerde parameters van het model, het resultaat van een training die miljoenen euro's aan rekentijd heeft gekost. Als Meta of Mistral een model "open" uitbrengt, betekent dat: je mag die gewichten downloaden en op je eigen hardware draaien.

Daar zit meteen een nuance. Open is niet altijd even open. Sommige Mistral-modellen verschijnen onder de Apache 2.0-licentie, een echte open-source licentie die weinig beperkingen oplegt. De Llama-modellen komen onder een eigen licentie van Meta, met voorwaarden over wat je ermee mag. Voor de meeste organisaties is dat geen blokkade, maar lees de licentie voordat je iets in productie zet. "Open weights" is een eerlijker term dan "open source" voor een deel van deze modellen, want de trainingsdata en het volledige trainingsproces krijg je er meestal niet bij.

Praktisch gezien haal je de gewichten van een platform als Hugging Face. Een klein model is een paar gigabyte, een groot model al snel meer dan honderd. En dan begint het echte verhaal pas, want die getallen moeten ergens in passen.

De hardware: GPU's en de VRAM-rekensom

Een taalmodel draait in de praktijk op een GPU, en de belangrijkste vraag is niet hoe snel die GPU is, maar hoeveel geheugen hij heeft. Dat geheugen heet VRAM, en het hele model moet erin passen om snel te kunnen antwoorden.

De rekensom is verrassend simpel. Elke parameter van het model is een getal dat opgeslagen moet worden. In het gangbare 16-bit formaat kost elke parameter 2 bytes. Een model met 8 miljard parameters heeft dan ongeveer 16 gigabyte nodig, alleen al voor de gewichten. Een model met 70 miljard parameters komt op zo'n 140 gigabyte. Ter vergelijking: een stevige professionele GPU heeft vaak 24, 48 of 80 gigabyte VRAM. Voor de grote modellen heb je dus meerdere GPU's nodig die samenwerken, en dat maakt alles duurder en complexer.

En het blijft niet bij de gewichten. Tijdens het genereren van antwoorden houdt het model een soort werkgeheugen bij van het gesprek tot nu toe, de KV-cache. Hoe langer de context en hoe meer gebruikers tegelijk, hoe meer extra geheugen dat vraagt. Wie krap plant, merkt dat het systeem in de demo prima draait en in productie vastloopt zodra er tien collega's tegelijk een lang document insturen.

Kwantisatie: hetzelfde model in een kleinere jas

Gelukkig is er een ontsnappingsroute: kwantisatie. Daarbij sla je de gewichten op met minder precisie, bijvoorbeeld 4 bits per parameter in plaats van 16. Hetzelfde model van 8 miljard parameters past dan ineens in zo'n 5 gigabyte in plaats van 16.

De prijs die je betaalt is een beetje kwaliteit. Het model wordt iets minder precies, alsof je een foto opslaat met meer compressie. Voor veel toepassingen is het verschil nauwelijks merkbaar, zeker bij voorzichtige kwantisatie zoals 8-bit. Bij agressieve kwantisatie ga je het wel zien, vooral bij taken die precisie vragen, zoals redeneren in meerdere stappen of code schrijven.

Kwantisatie is de reden dat mensen tegenwoordig een behoorlijk model op een laptop of een enkele consumenten-GPU kunnen draaien. Voor organisaties betekent het vooral: je kunt een groter, slimmer model draaien op dezelfde hardware, als je de lichte kwaliteitsafweging accepteert. Test dat wel met je eigen taken, niet alleen met een gevoel.

De motor: een inference server

De gewichten en de GPU zijn niet genoeg. Je hebt software nodig die het model laadt en er een dienst van maakt waar applicaties mee kunnen praten. Dat heet een inference server, en hier worden de verschillen groot.

Twee voorbeelden om het concreet te maken. vLLM is een inference server die gebouwd is voor productie met veel gelijktijdige gebruikers. Hij is slim in het delen van GPU-geheugen tussen verzoeken en in continuous batching: nieuwe vragen schuiven direct aan terwijl andere antwoorden nog gegenereerd worden, in plaats van netjes in de rij te wachten. Daardoor haal je veel meer uit dezelfde GPU. Bovendien biedt vLLM een OpenAI-compatible API, wat betekent dat applicaties die met de API van OpenAI kunnen praten vaak met een kleine aanpassing ook met jouw eigen model kunnen praten.

llama.cpp zit aan de andere kant van het spectrum: een lichtgewicht project dat modellen in het GGUF-formaat draait, ook op gewone CPU's en bescheiden hardware. Ideaal om lokaal te experimenteren of een klein model op een enkele machine te draaien. Tools als Ollama bouwen hierop voort en maken het bijna een kwestie van een commando intypen.

De keuze hangt af van je situatie. Eén ontwikkelaar die wil experimenteren heeft genoeg aan llama.cpp of Ollama. Een organisatie die tientallen gebruikers wil bedienen met acceptabele snelheid komt al snel bij iets als vLLM uit, op serieuze GPU-hardware.

Een voorbeeld: het advocatenkantoor

Stel, een middelgroot advocatenkantoor wil AI inzetten op dossiers, maar wil onder geen beding dat cliëntstukken naar een Amerikaanse cloudprovider gaan. Zelf hosten dus. Wat hebben ze nodig?

Eerst de modelkeuze: een open model dat goed Nederlands begrijpt en sterk genoeg is voor juridische teksten. Dan de afweging tussen formaat en hardware: een model van rond de 8 miljard parameters past op een enkele goede GPU, een model van 70 miljard vraagt meerdere GPU's of stevige kwantisatie. Vervolgens een server met die GPU's, in een eigen serverruimte of bij een Europese hostingpartij. Daarbovenop vLLM als inference server, zodat meerdere juristen tegelijk kunnen werken zonder dat alles stroperig wordt.

Tot zover de techniek die in elke tutorial staat. En dan komt het deel waar de meeste projecten op stuklopen.

Een model draaien is niet hetzelfde als een AI-omgeving bouwen

Dit is de misvatting die ik het vaakst tegenkom: het idee dat je klaar bent zodra het model antwoordt. Op dat moment heb je een motor die loopt. Je hebt nog geen auto.

Een bruikbare AI-omgeving heeft minstens dit nodig:

Dit is precies de laag waar ik met HostYourAI de meeste tijd in steek. Niet het model aan de praat krijgen, dat lukt in een middag. Wel de omgeving eromheen die maakt dat een organisatie er elke dag op kan vertrouwen.

Wanneer self-hosting logisch is, en wanneer niet

Self-hosting is logisch als minstens een van deze dingen speelt. Je verwerkt data die echt niet naar buiten mag, en je wilt technisch kunnen aantonen waar elke prompt blijft. Je hebt een stabiel, voorspelbaar gebruiksvolume, waardoor eigen hardware op termijn goedkoper kan zijn dan betalen per token. Of je wilt onafhankelijk zijn van een leverancier die zijn prijzen, voorwaarden of modellen kan veranderen op een moment dat jou niet uitkomt.

Self-hosting is meestal niet logisch als je nog aan het ontdekken bent wat AI voor je organisatie kan doen. Dan is een API van een betrouwbare provider sneller, goedkoper en flexibeler. Het is ook niet logisch als je per se de allerbeste modelkwaliteit nodig hebt: de absolute top zit op dit moment bij gesloten modellen, al wordt het gat kleiner. En het is niet logisch als niemand in je organisatie de operationele kant kan dragen. Een GPU-server die niemand onderhoudt is geen soevereiniteit, het is een risico met een stroomaansluiting.

Er is ook een middenweg die vaak wordt vergeten: een open model laten draaien bij een Europese hostingpartij. Je krijgt dan de controle en transparantie van een open model, zonder zelf serverruimte en beheer te hoeven regelen. Voor veel organisaties is dat het eerlijke antwoord.

Het denkmodel in vijf vragen

Wie overweegt zelf te hosten, kan zichzelf deze vragen stellen:

1. Welk probleem los ik op met self-hosting dat ik niet anders kan oplossen? Als het antwoord vaag is, begin er niet aan. 2. Welk model en welke kwaliteit heb ik minimaal nodig, en past dat op hardware die ik kan betalen? 3. Wie beheert dit over een jaar? Een naam, geen afdeling. 4. Hoe regel ik toegang, limieten en logging vanaf dag één, niet als de eerste incidenten er al zijn? 5. Heb ik de totale kosten vergeleken: hardware, stroom, beheer en updates tegenover betalen per gebruik?

Wie deze vijf vragen kan beantwoorden, is verder dan de meeste projecten die ik voorbij zie komen.

Tot slot

Een open model zelf hosten kan, en het wordt elk jaar realistischer. De techniek is geen magie: gewichten, genoeg VRAM, een goede inference server en waar nodig kwantisatie. Dat deel is goed gedocumenteerd en in een week op te zetten.

Het echte werk zit in het verschil tussen een model dat draait en een omgeving die je organisatie kan vertrouwen. Authenticatie, limieten, monitoring, updates en een plan voor als het misgaat. Wie dat verschil vooraf begrijpt, maakt een betere keuze. Soms is dat zelf hosten, soms een Europese partij, soms gewoon een API. Maar dan is het tenminste een keuze, en geen verrassing achteraf. 

↘︎ ALLE ARTIKELEN