Lokale LLM (on-premises inference)
Wat is een lokale LLM?
Een lokale LLM is een taalmodel dat draait op hardware die jij beheert, en niet op de servers van een leverancier. De gewichten staan op jouw schijf, het model wordt in jouw geheugen geladen, en de prompt verlaat de machine nooit. Dat kan een werkstation onder een bureau zijn, een server in je eigen rack, of een virtuele machine in een cloudaccount waar enkel jouw team aan kan.
On-premises inference betekent hetzelfde, met de klemtoon op de plaats. Inference is het moment waarop een getraind model antwoordt, en on-premises zegt dat dat antwoorden op jouw infrastructuur gebeurt en niet op die van iemand anders.
Het is een keuze over waar je iets draait, niet over welk model je kiest. Je hebt er wel een open-weight model voor nodig, want de gewichten van een gesloten model kan je niet downloaden. Maar open weights kiezen en ze zelf hosten zijn twee aparte stappen, en veel bedrijven zetten enkel de eerste.
Eén ding is het niet: een gehoste API in een Europese regio aanroepen. Je tekst gaat dan nog altijd je netwerk uit en een externe partij verwerkt ze. Dat is vaak de juiste keuze, maar er zit een contract achter in plaats van een machine.
Waarom bedrijven een model op eigen hardware draaien
Vijf redenen zie je in de praktijk terugkomen, en maar één ervan gaat over geld.
Data die niet buiten mag. Patiëntendossiers, personeelsdossiers, cijfers die nog niet gepubliceerd zijn, stukken die onder het beroepsgeheim vallen. Als het antwoord op "mag deze tekst naar een externe verwerker" nee is, dan haalt zelf draaien die vraag weg in plaats van ze te beantwoorden.
Een factuur die niet meer meegroeit. Een gehost model rekent per token af, dus je factuur volgt je gebruik. Je eigen server kost hetzelfde of hij nu één keer per dag antwoordt of een miljoen keer.
Een model dat niemand kan uitfaseren. Leveranciers halen versies weg volgens hun eigen kalender en geven je een verwittiging, geen vetorecht. Een model op jouw schijf doet nog altijd exact wat het deed op de dag dat je het getest hebt, en dat telt voor alles wat je gevalideerd hebt.
Locaties zonder betrouwbare verbinding. Een productiehal, een schip, een handterminal in een magazijn met slechte dekking. Een model op het toestel blijft werken als de lijn wegvalt.
Voorspelbare responstijd. Geen sprong over het internet en geen wachtrij die je met andere klanten deelt, dus je antwoordtijden blijven in een smalle band.
Wat heb je nodig om er een te draaien?
Vier zaken, en de vierde wordt het vaakst vergeten.
Een open-weight model met een licentie die je gelezen hebt. Llama, Mistral, Gemma, Qwen en de gpt-oss-familie publiceren allemaal downloadbare gewichten, elk met eigen voorwaarden rond commercieel gebruik en herverdeling.
Genoeg geheugen. Geheugen is de echte beperking, en het rekenwerk is kort. Gewichten staan meestal in 16 bits, dus een model laden vraagt ruwweg twee bytes per parameter: zo'n 16 GB voor een model van 8 miljard parameters, zo'n 48 GB voor een van 24 miljard, en dan heb je het geheugen voor de context zelf nog niet geteld. Quantisatie zet elk gewicht in minder bits en snoeit daar fors in: de gangbare 4-bits versie van Llama 3.1 8B is een bestand van ongeveer 5 GB, dat past in een grafische kaart van 16 GB. Mistral zegt zelf dat zijn Mistral Small 3.1 met 24 miljard parameters ongeveer 55 GB GPU-geheugen vraagt op volle precisie, en dat het gequantiseerd past op één RTX 4090 of een MacBook met 32 GB. Drie treden, stand september 2026: 7 tot 8 miljard parameters gequantiseerd draait op een gewone grafische kaart of een recente laptop, 20 tot 30 miljard vraagt één stevige GPU, en vanaf 70 miljard heb je een zwaar werkstation of een server nodig. NVIDIA verkoopt zijn DGX Spark, een toestel voor naast je bureau met 128 GB gedeeld geheugen, voor fine-tuning tot 70 miljard parameters en inference tot 200 miljard. Daarboven kom je bij meerdere GPU's en een rack uit.
Een serving runtime. Het programma dat de gewichten inlaadt en aanvragen beantwoordt. llama.cpp is gebouwd voor inference met minimale opzet, van een laptop-CPU tot een datacenter-GPU, ondersteunt quantisatie van 1,5 tot 8 bits, en kan een model over CPU en GPU verdelen als het niet volledig in het videogeheugen past. Ollama verpakt dat in iets dat een ontwikkelaar in een minuut installeert, op NVIDIA-kaarten vanaf compute capability 5.0, AMD via ROCm en Apple silicon via Metal. vLLM gebruik je wanneer veel mensen tegelijk hetzelfde model aanspreken: het vraagt Linux en, op NVIDIA, een kaart van compute capability 7.5 of hoger, en is gebouwd voor doorvoer, niet voor een laptop.
Iemand die het beheert. Drivers, de runtime, de modelbestanden en de monitoring die je verwittigt als het stilvalt. Klein systeem, maar wel een productiesysteem, en er is geen supportlijn.
Wat kost het tegenover een gehoste API?
Neem een documentstroom: 20.000 documenten per maand, ruwweg 2.000 tokens input en 300 tokens output per stuk. Op de prijslijst van Anthropic van 4 september 2026 kost de kleine trede, Claude Haiku 4.5, 1 dollar per miljoen inputtokens en 5 per miljoen outputtokens. Dat is 40 dollar input en 30 dollar output, samen ongeveer 70 dollar per maand. De hoogste trede op diezelfde lijst, aan 10 en 50 dollar, zou rond 700 uitkomen.
En dan de lokale kant. Een toestel van dat type kost een paar duizend dollar: de DGX Spark kwam op de markt aan 3.999 dollar. Gespreid over drie jaar is dat iets meer dan 100 dollar per maand, en dan heb je nog niets anders geteld. Tel er stroom bij, en de paar uur per maand die iemand besteedt aan patchen en opvolgen, en je komt realistisch tussen 300 en 500 dollar uit. Bijna alles daarvan is de mens, niet de hardware.
Op dit volume wint de kleine gehoste trede dus ruimschoots, en het omslagpunt ligt boven de 100.000 documenten per maand, waar die 70 dollar 400 wordt. Tegenover de hoogste trede sta je op de factuur nu al voor, maar een model van 24 miljard parameters op je eigen machine doet niet wat die hoogste trede doet, dus die vergelijking klopt enkel als je eigen testen zeggen dat het kleinere model volstaat. En een GPU die stilstaat kost evenveel als een die draait, dus een machine op tien procent belasting heeft een kostprijs per document die tien keer hoger ligt.
Lokale LLM tegenover gehoste API: wat ligt vast en wat beweegt?
De helderste manier om de keuze te bekijken: welke stukken liggen vast en welke bewegen?
Kost. Lokaal ligt vast, gehost beweegt. Je koopt de machine één keer en de factuur volgt je gebruik nauwelijks, comfortabel bij hoog en stabiel volume en pijnlijk bij weinig volume. Gehost beweegt bij elke aanroep, comfortabel zolang je nog aan het uitzoeken bent of het ding überhaupt werkt.
Capaciteit. Lokaal ligt vast, gehost beweegt, en gehost begint met een voorsprong. De sterkste modellen zijn gesloten en enkel via een API te bereiken, dus wat je kan downloaden loopt er een paar maanden achter. Het model dat je gedownload hebt doet daarna over achttien maanden nog exact hetzelfde, terwijl het gehoste in diezelfde periode beter wordt zonder dat jij iets doet, maar ook verandert onder je voeten, verdwijnt en een nieuwe prijs krijgt.
Verantwoordelijkheid. Lokaal is ze volledig van jou, gehost deel je ze. Beschikbaarheid, patches, capaciteit en het gedrag van het kale model zijn jouw probleem als je zelf draait. Bij een gehost model liggen die bij de leverancier, samen met een contract dat zegt wat er gebeurt als het misloopt.
Met lokaal koop je een vaste factuur en een vast model, en betaal je daarvoor in werk.
Het middenveld, en waar je best begint
Lokaal en een Amerikaanse gehoste API zijn de twee uitersten. De bruikbare antwoorden liggen meestal ertussen.
Een Europese verwerkingsregio. Bij de deployment-types van Microsoft Foundry bestaat er een Data Zone-optie waarbij prompts en antwoorden enkel binnen de opgegeven datazone verwerkt worden, en de Europese zone volgt de Azure EU Data Boundary. De strakkere types Standard en Regional Provisioned houden de verwerking binnen de Azure-geografie die jij aanduidt.
Gereserveerde capaciteit in plaats van afrekenen per token. Wil je vooral een voorspelbare factuur en geen eigen machine, dan verkopen leveranciers gereserveerde doorvoer. Azure rekent provisioned throughput units per uur aan op de capaciteit die je uitrolt in plaats van op de tokens die je verbruikt, met reservaties voor een korting op termijn. Amazon Bedrock doet hetzelfde met model units, per uur, zonder verbintenis of met een termijn van één of zes maanden.
Een soevereine cloud. AWS lanceerde zijn European Sovereign Cloud op 15 januari 2026, met een eerste regio in Brandenburg die fysiek en logisch gescheiden is van de andere AWS-regio's, opgezet via vennootschappen naar EU-recht en uitgebaat door personeel dat in de EU woont.
Ga wel na of dat middenveld bestaat voor het model dat jij wil. De dataresidentie-instellingen van Anthropic laten je in september 2026 kiezen tussen inference in de Verenigde Staten of wereldwijd, zonder optie enkel-EU.
Voor de meeste KMO's is de volgorde dus: begin gehost, in een Europese regio, met een verwerkersovereenkomst. Artikel 28, lid 3 van de GDPR somt op wat daarin moet staan, van gedocumenteerde instructies en vertrouwelijkheid tot subverwerkers, verwijdering op het einde en het recht op audit. Verhuis pas een taak naar lokaal als je de reden kan benoemen: een soort data die niet buiten mag, of een volume waarbij de som klopt. En verhuis dan één taak, niet alles. Eén classificatie- of extractieopdracht is een eerlijke test of jouw team een modelserver wil beheren. Een algemene assistent voor het hele bedrijf is dat niet.
Waar moet je op letten bij het gebruik van een lokale LLM?
Lokaal betekent niet veilig. Jouw model heeft dezelfde zwakte als elk ander: het kan instructies niet van data onderscheiden. Een prompt injection verstopt in een leveranciers-PDF werkt even goed tegen jouw machine, en als dat model aan je bestandsserver kan, wordt de schade groter in plaats van kleiner. Toegangsbeheer, logging en de vraag welke tools het model mag aanroepen blijven allemaal gelden.
Je verliest de bijsturing en de beschikbaarheid van de leverancier. Een gehost model komt met veiligheidsgedrag, misbruikdetectie en een afspraak over beschikbaarheid. Een kaal open-weight model komt zonder dat alles.
Niets werkt zichzelf bij. De modelserver, de bibliotheken eronder en de GPU-driver moeten allemaal gepatcht worden, en een nieuwe modelversie is een project en geen melding. Hou een testset bij met je eigen voorbeelden en de antwoorden die je verwacht, anders weet je niet of een upgrade geholpen heeft.
De GDPR verdwijnt niet. Zelf draaien haalt een externe verwerker uit die stap, dus daarvoor heb je geen verwerkersovereenkomst nodig. Je blijft wel verwerkingsverantwoordelijke, de beveiligingsplichten van artikel 32 gelden nog altijd voor die machine, en wat mensen in het model typen staat nu als persoonsgegeven op je eigen schijf.