LLM zelf hosten: De complete gids voor LLM’s draaien op eigen infrastructuur

Een zelf gehoste LLM is een open-weight taalmodel dat volledig binnen je eigen datacenter of een door jou beheerde cloudomgeving draait. Je data verlaat je perimeter niet, je betaalt geen tarief per token, en je bepaalt zelf welke modelversie in productie staat. Wat je ervoor inruilt is werk: hardware, een inference runtime en een governance-laag die je zelf inricht.

In 2026 is dat voor veel Nederlandse organisaties geen theoretische afweging meer. De praktijk is vrijwel altijd hybride: gevoelige en hoogvolume werklasten draaien intern, terwijl de zwaarste redeneertaken via een API blijven lopen. Deze gids behandelt wat daar concreet bij komt kijken, van modelkeuze en VRAM-berekening tot runtimes, governance en de vraag wanneer zelf hosten financieel klopt.

Belangrijkste punten

• Een self-hosted LLM draait volledig op je eigen infrastructuur, waardoor bedrijfsgevoelige en gereguleerde data binnen je perimeter blijft.
• De verschuiving naar private AI wordt gedreven door drie krachten: datasoevereiniteit, lagere kosten bij hoog volume, en voorspelbare latency.
• Open-weight modellen als DeepSeek V4, GLM-5.2, Qwen 3.5 en Gemma 4 zijn op de meeste zakelijke benchmarks concurrerend met gesloten modellen.
• Let op de licentie voordat je bouwt: de community-licentie van Llama 4 sluit EU-bedrijven uit, wat het model voor Nederlandse organisaties praktisch onbruikbaar maakt.
• Hardwareplanning begint bij VRAM. De gewichten moeten in snel geheugen blijven staan. INT8 halveert die behoefte tegenover FP16, Q4 brengt hem terug naar ongeveer een kwart.
• Productieruntimes als vLLM, SGLang en TensorRT-LLM leveren hoge doorvoer. Ollama en llama.cpp zijn geschikt voor ontwikkeling en kleine teams.
• Reken 0,5 tot 1 FTE aan engineering mee voor het eerste jaar. Dat is bij de meeste teams de grootste kostenpost, niet de GPU.

Waarom Nederlandse organisaties kiezen voor private AI-infrastructuur

Private AI-infrastructuur is het geheel van rekenhardware, orkestratiesoftware en netwerkconfiguratie dat uitsluitend bestemd is voor het draaien van lokale machine learning-modellen. Vier motieven komen in de praktijk steeds terug.

Datasoevereiniteit, AVG en de EU AI Act

Voor organisaties die werken met patiëntgegevens, financiële dossiers, juridische stukken of overheidsinformatie is de vraag waar data verwerkt wordt geen detail. Zodra je prompts naar een verwerker buiten de EU stuurt, krijg je te maken met doorgifte naar een derde land en met de vraag hoe de Amerikaanse CLOUD Act zich verhoudt tot je AVG-verplichtingen. Ook een hyperscaler met EU-dataresidentie neemt die vraag niet volledig weg, en een deel van de Nederlandse publieke en zorgsector accepteert dat restrisico niet.

Zelf hosten haalt die doorgifte eruit. Er verlaat geen enkele prompt, geen enkel document en geen enkel interactielog je eigen perimeter. Dat vereenvoudigt je verwerkingsregister, je DPIA en de afspraken met je functionaris gegevensbescherming aanzienlijk.

Het neemt je verplichtingen niet weg. Sinds 2 augustus 2026 gelden de transparantieverplichtingen uit artikel 50 van de EU AI Act: je moet duidelijk maken wanneer een gebruiker met AI communiceert en AI-gegenereerde content machineleesbaar markeren. De verplichtingen voor hoog-risicosystemen zijn met het Digital Omnibus-pakket doorgeschoven naar december 2027, wat je ruimte geeft om je documentatie op orde te brengen. Het toezicht in Nederland ligt verspreid over sectorale toezichthouders, waaronder de Autoriteit Persoonsgegevens, de RDI, DNB en de AFM. De AVG en de EU AI Act vervangen elkaar niet: de AVG gaat over persoonsgegevens, de AI Act over het AI-systeem zelf, en veel toepassingen vallen onder allebei.

Security en governance komen in eigen beheer

Datasoevereiniteit is maar één laag. Zelf hosten verplaatst de volledige security- en compliancelast naar binnen, dus je bouwt zelf de controles die een commerciële aanbieder anders levert.

Auditability en logging vormen de basis. Leg prompts, uitvoer en toegangsgebeurtenissen vast in logs die niet ongemerkt aangepast kunnen worden, zet rolgebaseerde toegangscontrole op je inference-endpoints, en koppel die praktijk aan een raamwerk als SOC 2 of ISO 27001. Omdat het model binnen je eigen omgeving draait, dient hetzelfde audit trail voor zowel interne review als je verantwoording richting toezichthouders.

Contentfiltering voeg je bewust toe. Open-weight modellen worden geleverd zonder de guardrails die in gehoste API’s zitten. Een productiewaardige self-hosted stack zet daarom classifiers of open source safety-filters voor en achter het model, die invoer en uitvoer screenen op schadelijke, niet-conforme of datalekkende inhoud voordat een antwoord bij de gebruiker landt.

Supply chain-risico verschuift naar jou. Toets modellicenties op commercieel gebruik en herdistributie, controleer de herkomst van gedownloade gewichten, en scan container images op kwetsbaarheden voordat ze naar productie gaan. Behandel modelartefacten met dezelfde discipline als je softwareafhankelijkheden, want dit is in de praktijk het vaakst overgeslagen gat.

Wanneer zelf hosten goedkoper wordt

Een commerciële API heeft een lage instapdrempel en schaalt lineair mee met je verbruik. Zelf hosten ruilt die variabele kosten in voor een grotendeels vaste post: hardware of gereserveerde GPU-capaciteit, plus beheer. Het omslagpunt ligt hoger dan de meeste teams verwachten.

Voor een werklast van ongeveer 10 miljoen tokens per dag ben je bij een commerciële API rond de 250 euro per maand kwijt, en bij een cloudplatform met EU-dataresidentie rond de 540 euro. Dezelfde werklast op twee gehuurde L40S-kaarten kost al snel het viervoudige daarvan. Onder de 5 miljoen tokens per dag wint een API vrijwel altijd. Tussen 5 en 50 miljoen ligt het dicht bij elkaar, en daarboven begint zelf hosten te lonen, mits je bezettingsgraad hoog en constant is.

De post die het vaakst ontbreekt in de berekening is menskracht. Reken op minimaal 0,5 tot 1 FTE aan engineering voor het eerste jaar om de stack te bouwen, te monitoren en bij te werken. Bij de meeste organisaties is dat de werkelijke kostendrijver. Een GPU koop je één keer, een team dat modelupdates, kwantisatie en incidentafhandeling doet, betaal je elke maand.

Wie de rekening wil drukken zonder meteen hardware te kopen, kan eerst de architectuurpatronen rond caching, batching en routing toepassen op de bestaande API-werklast. Dat verschuift het omslagpunt en maakt de businesscase voor zelf hosten scherper.

Voorspelbare latency en uitvoeringscontrole

Publieke API-endpoints kennen variabele latency, rate limits en onverwachte storingen tijdens wereldwijde piekmomenten. Draai je zelf, dan bepaal je de uitvoeringsvariabelen. Technieken als prefix caching, speculative decoding en dedicated batching queues leveren voorspelbare responstijden voor toepassingen waar die voorspelbaarheid bedrijfskritisch is, zoals realtime klantcontact of processen met een harde SLA.

De open-weight modellen van 2026

Het verschil tussen gesloten frontier-modellen en open gewichten is grotendeels weggevallen. Wat overblijft is een keuze tussen architecturen die op verschillende hardware passen, en een licentievraag die je beter vooraf stelt dan achteraf.

Grote redeneer- en generalistische modellen

• DeepSeek V4: het redeneervlaggenschip, uitgebracht in april 2026 met een native contextvenster van 1 miljoen tokens. De Pro-variant telt 1,6 biljoen parameters met 49 miljard actief per token, de Flash-variant 284 miljard totaal met 13 miljard actief. Sterk in algoritmisch probleemoplossen, formele wiskunde en meerstapsanalyse. De MIT-licentie maakt commercieel gebruik eenvoudig.
• Google Gemma 4: voortgekomen uit het Gemini-onderzoek en uitgebracht in april 2026 in vijf formaten, van edge-varianten van circa 2 miljard parameters tot een dicht model van 31 miljard. Alle varianten delen een contextvenster van 256K tokens en ondersteunen meer dan 140 talen, waaronder Nederlands. Het 31B-model draait op één enkele server-GPU en is daarmee een van de praktischere keuzes voor een eerste on-premise uitrol.
• Qwen 3.5 en Mistral: twee families die het goed doen op prijs-kwaliteit per parameter. Qwen komt onder Apache 2.0, wat commercieel gebruik zonder frictie mogelijk maakt. Mistral is een Europese aanbieder met Apache-licenties, wat naast de techniek ook meetelt in aanbestedingen waar Europese herkomst en dataresidentie expliciet wegen.

Let op de licentie: Llama 4 en de EU

Llama van Meta is jarenlang de standaardkeuze geweest voor enterprise-finetuning, met het breedste tooling-ecosysteem en de meeste documentatie. Voor Nederlandse organisaties is dat in 2026 geen vanzelfsprekende keuze meer. De community-licentie van Llama 4 sluit in de EU gevestigde bedrijven uit van het accepteren van de voorwaarden, wat commerciële uitrol vanuit een Nederlandse entiteit blokkeert.

Praktisch betekent dat het volgende. Wil je de bekende workflows rond Llama blijven gebruiken, dan zijn de oudere Llama 3.x-modellen wel beschikbaar. Bouw je iets nieuws, kies dan Qwen, Mistral, DeepSeek V4 of Gemma 4, en laat de licentie toetsen voordat de eerste sprint begint in plaats van vlak voor livegang. Ook bij Gemma geldt een aandachtspunt: intern gebruik is helder, maar het extern uitleveren van een model dat je op eigen data hebt gefinetuned vraagt om een juridische blik op de vraag of de beperkingen van Google meelopen met het afgeleide model.

Compacte modellen voor edge en on-device

Zelf hosten gaat niet alleen over vlaggenschepen. Een groeiende groep compacte modellen tussen 3 en 8 miljard parameters levert bruikbare kwaliteit voor afgebakende taken en draait op bescheiden hardware: één consumenten-GPU, een laptop of een edge-apparaat. Denk aan Qwen3.5-4B, Phi-4-mini en de kleinere Gemma-varianten.

Deze modellen passen goed bij assistenten op het apparaat zelf, realtime classificatie, samenvatten en retrieval-pijplijnen, waar latency en kosten zwaarder wegen dan frontier-redeneren. Ze dienen daarnaast als efficiënt draft model voor speculative decoding naast een groter systeem. Voor veel Nederlandse bedrijfsprocessen is een goed afgestemd klein model dat lokaal draait praktischer dan een enorm model dat een datacentercluster vraagt.

Gespecialiseerde agentic- en codeermodellen

• GLM-5.2 (Zhipu): gebouwd voor agentic taken over een lange horizon en meerstaps tool use. Het model gebruikt sparse attention om de verwerkingsoverhead laag te houden tijdens complexe uitvoering binnen bedrijfssystemen, en scoort in 2026 vooraan op SWE-bench-achtige codeertaken. Beschikbaar onder MIT.
• Kimi K2.6: een multimodaal Mixture-of-Experts-systeem van circa 1 biljoen parameters, ingericht om meerdere agents te coördineren. Het activeert per token slechts een deel van de parameters, wat de doorvoer optimaliseert voor gecombineerde beeld- en tekstanalyse. Let op: bij MoE moeten alle expertgewichten wél in het geheugen staan, dus de geheugenrekening krimpt niet mee met het aantal actieve parameters.

Hardware: wat heb je echt nodig?

De hardwarekeuze volgt uit het model en het kwantisatieniveau, niet andersom. Begin bij de vraag hoeveel VRAM je nodig hebt en werk terug naar de kaarten die dat leveren.

GPU’s en geheugenverdeling

De basiseis voor efficiënte inferentie is beschikbaar Video RAM (VRAM) en geheugenbandbreedte. Omdat de modelgewichten tijdens inferentie in snel VRAM moeten blijven staan, bepaalt je hardwarekeuze direct de maximale modelgrootte die je kunt draaien.

Klasse	Geheugen	Wat het draait	Typische inzet
Werkstation	32 tot 48 GB VRAM	Modellen tot circa 30B op volle precisie, of 70B op Q4-kwantisatie	Eén RTX 5090 (32 GB) of twee kaarten samen. Ontwikkeling, interne tooling, kleine teams
Apple Silicon	64 tot 256 GB unified memory	70B comfortabel, tot 200B-klasse op Q4	Mac Studio als stille, zuinige node voor middelgrote modellen. Lagere doorvoer dan een discrete GPU
Datacenter-node	80 tot 192 GB VRAM	Dichte vlaggenschipmodellen in realtime	Nvidia H100, H200 of B200. Productie-inferentie met meerdere gelijktijdige gebruikers
Scale-out cluster	Meerdere nodes	Frontier MoE-modellen van 400B en meer	Interconnect via InfiniBand, met tensor- of pipelineparallelisme over meerdere units

Voor Nederlandse organisaties die geen eigen serverruimte willen inrichten, zit er een tussenstap tussen hyperscaler en eigen rack. Colocatie bij partijen als Leaseweb, NorthC of Greenhouse Datacenters, of GPU-capaciteit bij een Europese aanbieder, levert dataresidentie binnen Nederland of de EU zonder dat je zelf een datacenter bouwt. Dat is voor veel zorg-, overheids- en financiële organisaties de praktische invulling van soevereiniteit.

Zo bereken je je VRAM-behoefte

Om het absolute minimum aan VRAM te schatten, gebruik je één formule:

Totaal VRAM = modelgewichten + KV-cache + overhead

Modelgewichten = parameters × bytes per parameter. Het aantal bytes hangt af van de precisie of het kwantisatieniveau:

Precisie	Bytes per parameter	70B-model	8B-model
FP32	4	circa 280 GB	circa 32 GB
FP16 / BF16	2	circa 140 GB	circa 16 GB
INT8	1	circa 70 GB	circa 8 GB
INT4 (Q4)	circa 0,56	circa 39 GB	circa 4,5 GB
INT2 (Q2)	circa 0,33	circa 23 GB	circa 2,6 GB

KV-cache. De KV-cache bewaart de context van eerdere tokens tijdens het genereren. De omvang groeit mee met contextlengte, batchgrootte en modelarchitectuur. Reken bij bescheiden batches en korte tot middellange context (4K tot 8K tokens) op 1 tot 2 GB. Bij grote contextvensters van 32K tot 128K tokens en meer kan de KV-cache oplopen tot 8 GB of hoger.

Overhead. De CUDA-runtime, kernels en interne activatiebuffers vragen ook geheugen. Vuistregel: vermenigvuldig je basismodelgrootte met 1,2 tot 1,3, of reserveer een vaste 1 tot 1,5 GB. Houd er rekening mee dat het werkelijke verbruik in de praktijk 10 tot 20 procent hoger uitvalt dan de kale berekening.

Kwantisatie op Q4_K_M of Q5_K_M is voor de meeste productiewerklasten veilig. Het kwaliteitsverlies is beperkt, terwijl de geheugenbehoefte terugloopt naar ongeveer een kwart van FP16. Waar het wél uitmaakt: gestructureerde uitvoer, wiskunde en retrieval over lange context. Test dat op je eigen werklast in plaats van te vertrouwen op geaggregeerde benchmarks, zeker in het medische of juridische domein.

Inference runtimes en deployment-stacks

De inference runtime is de softwarelaag die ruwe open-weight bestanden omzet in een stabiele API. De keuze hier bepaalt je doorvoer, je geheugengebruik en hoeveel gelijktijdige gebruikers je aankunt.

Productieruntimes met hoge doorvoer

Runtime	Sterkte	Wanneer je het kiest
vLLM	PagedAttention beheert de KV-cache dynamisch en voorkomt fragmentatie	De brede standaard voor productie-inferentie met veel gelijktijdige aanvragen
SGLang	RadixAttention en geoptimaliseerde MLA-kernels, plus gestructureerde uitvoer (JSON-schema’s)	Bij hoge doorvoer en bij DeepSeek-architecturen, en overal waar je schemavalidatie afdwingt
TensorRT-LLM	Compileert modellen naar geoptimaliseerde engines met fused kernels en FP8/INT4	Wanneer je maximale prestaties uit een dedicated Nvidia-vloot wilt halen
Text Generation Inference (TGI)	Tensorparallelisme, geoptimaliseerde tokenizers en validatielagen	Als je al in het Hugging Face-ecosysteem werkt en een beproefd platform wilt
Unsloth	Sterk gereduceerd geheugengebruik bij finetunen en inferentie	Als je modellen intern wilt finetunen op bescheiden hardware voordat ze naar productie gaan

De verhouding tussen vLLM en SGLang is in 2026 verschoven. SGLang is geen uitdager meer maar een gelijkwaardige keuze: op H100-hardware haalt het circa 29 procent meer doorvoer dan vLLM op Llama 3.1 8B, en op DeepSeek-architecturen loopt het verschil op tot ruim drie keer, dankzij de native MLA-kernels. Draai je DeepSeek, dan is dat een reden om de vergelijking serieus te maken.

Stacks voor ontwikkeling en kleine teams

• Ollama: verpakt de complexiteit in enkelvoudige commando’s. Breed gebruikt voor interne proofs of concept, testomgevingen en kleine teams op een lokale server.
• llama.cpp: de onderliggende C/C++-implementatie die op uiteenlopende consumenten- en professionele hardware draait, met handmatige controle over CPU-threads, contextvenster en geheugencompressie. Ook de route als je bewust zonder GPU wilt werken.

Zo pak je de implementatie aan

Een private model in je kernsystemen zetten vraagt om een gefaseerde aanpak, anders bouw je een technisch correcte stack waar niemand mee werkt.

Fase 1: strategische evaluatie

Voordat je budget vastlegt in eigen compute, bepaal je welke werklasten er überhaupt intern horen. Breng je processen in kaart, schat het tokenvolume per proces, en toets per werklast of zelf hosten een echt voordeel oplevert boven een commerciële API. Werklasten met gevoelige data of hoog constant volume komen bovenaan te staan, incidenteel en experimenteel werk blijft in de cloud. Een houdbare AI-strategie koppelt die technische keuze aan de bedrijfsdoelen op langere termijn.

Fase 2: optimalisatie en applicatieontwikkeling

Zodra de infrastructuur staat, halen ontwikkelteams de prestaties eruit met drie technieken:

1. Retrieval-Augmented Generation (RAG). Koppel het model aan een lokale vectordatabase, zodat het antwoorden geeft op basis van je eigen documentatie zonder dat je de onderliggende gewichten aanpast. Zie de uitleg over RAG voor de werking.
2. Kwantisatiepijplijn. Comprimeer FP16-parameters naar INT8 of INT4, zodat je meer doorvoer haalt uit de servers die je al hebt staan. Valideer daarna op je eigen evals.
3. Orkestratie en interface. Zet een laag als Open WebUI of een eigen frontend voor het model, zodat het onderdeel wordt van de dagelijkse werkomgeving in plaats van een endpoint waar niemand bij komt. Wie de bouwstappen van begin af aan wil volgen, vindt die in de gids over het bouwen van je eigen LLM-toepassing.

Fase 3: beheer op lange termijn

Dit is de fase die in businesscases het vaakst wordt onderschat. Open-weight modellen verschijnen in een hoog tempo, en elke nieuwe generatie vraagt om hertesten, opnieuw kwantiseren en een gecontroleerde uitrol. Daar komt monitoring bij op latency, geheugendruk en kwaliteit van de uitvoer, plus een evaluatieset die meegroeit met je toepassing. Bouw je die discipline niet, dan staat er binnen een jaar een verouderd model in productie dat niemand meer durft aan te raken.

Wil je weten welke werklasten intern horen en welke niet, dan brengt een AI-assessment je huidige verbruik en risico’s in kaart.

Conclusie

Een LLM zelf hosten is in 2026 geen onderzoeksproject meer, maar een werkbare productieoptie voor organisaties die controle willen over hun data, kosten en prestaties. Het gat tussen open gewichten en gesloten modellen is smal genoeg geworden dat families als DeepSeek, Qwen, GLM, Mistral en Gemma serieuze zakelijke werklasten dragen, van frontier-redeneren tot compacte modellen aan de rand van het netwerk.

Het succes hangt minder af van je modelkeuze dan van de discipline eromheen. De organisaties die het meest uit private AI-infrastructuur halen, stemmen hun hardware af op de echte VRAM- en kwantisatiebehoefte, kiezen een actief onderhouden runtime als vLLM, SGLang of TensorRT-LLM, toetsen de licentie voordat ze bouwen, en behandelen security, governance en evaluatie als eerste-orde-onderwerpen.

Begin daarom klein en concreet. Kies één werklast met duidelijke waarde en een helder AVG-argument, bewijs die tegen meetbare criteria, en schaal pas op als de beheerdiscipline staat. Dat levert meer op dan een cluster kopen en daarna op zoek gaan naar een toepassing.

Veelgestelde vragen (FAQ)