Private LLM on-premise: data-soevereine AI binnen uw eigen muren

Waarom on-premise of private-cloud LLM's, en niet de publieke API

Voor de meeste organisaties begint het verhaal bij dezelfde vraag: mogen patiëntdossiers, hypotheekaanvragen, due-diligence-stukken of operationele militaire data überhaupt door een Amerikaanse cloud-LLM worden verwerkt? Het antwoord is meestal genuanceerder dan ja of nee, maar in vier domeinen is het hek van de dam.

Het eerste domein is data-soevereiniteit. Sinds Schrems II is de juridische basis voor data-export naar de Verenigde Staten broos: organisaties moeten per verwerkingsstroom afwegen of standard contractual clauses, een transfer impact assessment en aanvullende technische maatregelen voldoende zijn. Voor zorginstellingen onder NEN 7510, voor financiële instellingen onder DNB- en AFM-toezicht, voor overheid onder de BIO en voor defensie-aanverwante organisaties is die afweging in de praktijk vrijwel altijd negatief. On-premise of een Nederlandse private-cloud-zone zonder transatlantische verwerking maakt de discussie eenvoudig: data verlaat het pand niet.

Het tweede domein is no-train guarantees. Publieke API-leveranciers belijden dat enterprise-data niet voor modeltraining wordt gebruikt — maar de juridische afdwingbaarheid is gelimiteerd, telemetrie loopt vaak buiten de EU, en bij elke modelwissel of policy-update verandert de feitelijke verwerking. Een private LLM die u zelf draait, kan eenvoudigweg nooit per ongeluk in een trainingsbatch belanden. Voor IP-gevoelige sectoren — pharma, hightech, advocatuur, M&A-bureaus — is dat een keiharde voorwaarde.

Het derde domein is latency en beschikbaarheid. Inferentie binnen het eigen datacenter levert sub-100ms time-to-first-token in plaats van 400-1500ms over een transatlantische verbinding. Voor real-time use cases — interactieve copilots, agent-loops met meerdere tool-calls per seconde, voice-AI — is dat het verschil tussen werkbaar en frustrerend. Bovendien valt u niet uit als de upstream-provider een storing heeft of plotseling rate-limits aanscherpt.

Het vierde domein is auditbaarheid. AVG art. 32 verlangt dat u kunt aantonen welke gegevens zijn verwerkt, door welk model, met welk resultaat en door welke gebruiker. ENISA-richtlijnen voor AI-systemen versterken dat. Op een private LLM kunt u elke prompt, elke response, elke modelversie en elke gewogen output volledig vastleggen — zonder afhankelijkheid van wat een externe leverancier in zijn auditlog opneemt.

De inferentie-stack: van model-gewichten naar productie-API

Een open-weight model downloaden is de eenvoudige stap. De daadwerkelijke uitdaging zit in het bouwen van een inferentie-laag die throughput, latency, geheugen en betrouwbaarheid verenigt. De keuze van inferentie-engine bepaalt vaak de helft van uw GPU-rekening.

vLLM is de facto standaard geworden voor high-throughput LLM-serving. Continue batching, paged-attention en KV-cache-optimalisatie maken dat een H100 met vLLM 5-10x meer concurrent users aankan dan een naïeve transformers-implementatie. vLLM ondersteunt Llama, Qwen, Mistral, Gemma, DeepSeek en quantization-formats AWQ, GPTQ, GGUF en FP8 native, plus prefix-caching voor RAG-workloads waar dezelfde context herhaaldelijk gebruikt wordt.

Hugging Face Text Generation Inference (TGI) is een sterk alternatief, met goede integratie in het bredere HF-ecosysteem en degelijke Triton-Inference-Server-koppeling. Voor organisaties die al op NVIDIA-stack staan, is NVIDIA NIM (NVIDIA Inference Microservices) een aantrekkelijke optie: kant-en-klare gecontaineriseerde inferentie-microservices met TensorRT-LLM-optimalisaties, FP8-paths op Hopper, en Helm-charts voor Kubernetes. NIM biedt out-of-the-box throughput die met een hand-gebouwde vLLM-deployment moeilijk te evenaren is.

Voor lichtere of edge-deployments zijn Ollama en llama.cpp uitstekend. llama.cpp draait GGUF-gequantizeerde modellen op CPU, op kleinere GPU's of zelfs Apple Silicon, en is een goede keuze voor laptop-copilots of demo-omgevingen. Ollama bouwt daar een gebruiksvriendelijke API-laag overheen, met automatische modelmanagement. Niet elke use case vraagt een 8x H100-cluster — soms is een Mac Studio of een enkele L40S al genoeg.

Quantization is het scharnierpunt tussen modelgrootte en GPU-budget. AWQ (activation-aware weight quantization) en GPTQ leveren INT4-gewichten met <1% nauwkeurigheidsverlies op de meeste benchmarks. FP8 op Hopper-GPU's (H100/H200) combineert hoge throughput met betere kwaliteit dan INT4. GGUF is de gangbare quantization voor llama.cpp en biedt 2-bit tot 8-bit varianten. Voor RAG-pipelines optimaliseren we daarnaast met FlashAttention-2 of -3 voor lange contexten, en TensorRT-LLM-engines voor kritische lage-latency-paden.

Sectoren waar private LLM on-premise vaak de enige optie is

Niet elke organisatie heeft on-prem LLM nodig. Maar voor deze sectoren is de afweging vrijwel altijd al gemaakt door wet- en regelgeving of contractuele verplichtingen.