IT-infrastructuur voorbereiden op lokale LLM's

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

1. De strategische afweging: wanneer is on-premise noodzakelijk?

Voordat een organisatie besluit te investeren in fysieke hardware voor het lokaal draaien van Large Language Models (LLM's), moet de fundamentele vraag worden beantwoord: welk specifiek probleem maakt een lokale infrastructuur noodzakelijk? Veel organisaties starten dit traject vanuit een algemeen gevoel van databeveiliging, maar een succesvolle implementatie vereist een scherpe analyse van dataclassificatie, wet- en regelgeving, latency en kostenstructuren.

Binnen streng gereguleerde sectoren, zoals de gezondheidszorg, de financiële sector en de overheid, is de verwerking van persoonsgegevens of intellectueel eigendom onderworpen aan strikte wetgeving. Wanneer gegevens het interne netwerk onder geen beding mogen verlaten, vallen publieke API-aanbieders direct af. De introductie van wetgeving zoals de AVG, NIS2 en de AI Act dwingt organisaties tot volledige controle over de dataflow. Het lokaal hosten van modellen garandeert dat er geen gegevens met externe partijen worden gedeeld voor trainingsdoeleinden.

In industriële processen of real-time klantsystemen kan de vertraging van een externe netwerkverbinding onacceptabel zijn. Lokale inferentie, mits correct ingericht, elimineert de afhankelijkheid van internetverbindingen en vermindert de latency tot het minimum dat de fysieke hardware toestaat. Dit is met name relevant wanneer LLM's worden geïntegreerd in complexe workflows met microservices die elkaar in serie aanroepen.

Hoewel de initiële kapitaalinvesteringen (CapEx) voor eigen hardware aanzienlijk zijn, bieden ze op de lange termijn een voorspelbare kostenstructuur. Bij een constant hoog volume aan transacties kunnen publieke API-kosten onbeheersbaar worden. Een on-premise infrastructuur vlakt deze kostencurve af: de kosten voor stroom, koeling en beheer zijn grotendeels lineair en voorspelbaar, ongeacht het aantal gegenereerde tokens.

Het is echter belangrijk om te bepalen of een volledig fysieke on-premise installatie noodzakelijk is, of dat een private cloud-variant volstaat. Een dedicated cluster binnen een Europese cloudprovider biedt vaak dezelfde garanties op het gebied van datasoevereiniteit en netwerkisolatie, zonder de operationele lasten van fysiek hardwarebeheer. Bij de strategische afweging tussen bouwen of kopen speelt deze nuance een centrale rol.

2. Capaciteitsplanning: van gebruik naar resources

Het dimensioneren van een lokale AI-infrastructuur is complex omdat de prestaties afhankelijk zijn van een samenspel van variabelen. Zonder direct in te zoomen op specifieke chipmodellen, kan een organisatie de benodigde capaciteit grofmazig berekenen op basis van de verwachte werklast.

De capaciteitsbehoefte wordt bepaald door drie hoofdfactoren: het verwacht gelijktijdig gebruik, de promptlengte en de gewenste responstijd. Het gelijktijdig gebruik betreft het maximaal aantal gebruikers of systemen dat op exact hetzelfde moment een verzoek indient. De lengte van de invoer (prompts) en de gewenste lengte van de uitvoer (generatie) bepalen de verwerkingstijd. De invoerfase (prefill) is rekenintensief, terwijl de uitvoerfase (decode) geheugenbandbreedte-intensief is.

Met deze variabelen kan de totale token-doorvoer per seconde worden geschat. Deze doorvoer bepaalt de vereiste rekenkracht van de versnellers. Omdat theoretische limieten van hardwareleveranciers in de praktijk zelden worden gehaald door overhead in de softwarestack, is een ruime veiligheidsmarge noodzakelijk. Het is raadzaam om de theoretische capaciteit niet volledig te benutten in het initiële ontwerp.

Omdat elk model en elke specifieke implementatie (zoals Retrieval-Augmented Generation, of RAG) unieke prestatiekenmerken heeft, is een theoretische berekening nooit sluitend. Een gecontroleerde pilot is noodzakelijk om te valideren of de hardwarekeuzes aansluiten bij het daadwerkelijke gebruikersgedrag. Tijdens deze fase worden metrics zoals het geheugengebruik en de verwerkingssnelheid onder realistische druk gemeten. Het overgaan van een pilot naar productie vereist deze empirische data om kostbare miscalculaties bij de definitieve hardware-aanschaf te voorkomen.

3. Werkgeheugen op de versneller: de harde grens

Bij het draaien van LLM's is het werkgeheugen van de versneller (VRAM of High Bandwidth Memory) de meest kritieke factor. Als een model niet in het geheugen past, kan er geen inferentie plaatsvinden, of valt de snelheid terug naar een onbruikbaar niveau. De omvang van dit geheugen bepaalt direct welke modelgrootte ingezet kan worden.

De basisbehoefte aan geheugen wordt bepaald door het aantal parameters van het model en de precisie waarmee deze parameters zijn opgeslagen. Standaard worden modellen getraind in 16-bits precisie (FP16), wat betekent dat elke parameter 2 bytes aan geheugen inneemt. Een model met 70 miljard parameters vereist daardoor minimaal 140 gigabyte aan VRAM, puur om het model in het geheugen te laden.

Om de geheugenvoetafdruk te verkleinen, kan kwantisering worden toegepast. Hierbij worden de parameters omgezet naar een lagere precisie, zoals 8-bits (INT8) of 4-bits (INT4). Dit vermindert het benodigde geheugen aanzienlijk, ten koste van een minimaal verlies aan modelkwaliteit. Kwantisering maakt het mogelijk om grotere modellen te draaien op minder of lichtere hardware, wat de efficiëntie drastisch verhoogt. Meer details over hoe dit op individueel niveau werkt, is te vinden in de handleiding over hardware voor lokale LLM.

Naast het model zelf vereist de actieve verwerking van prompts geheugen. De Key-Value (KV) cache slaat de tussentijdse berekeningen van eerdere tokens in een gesprek op, zodat deze niet bij elk nieuw gegenereerd token opnieuw berekend hoeven te worden. Dit geheugengebruik groeit lineair met de lengte van de context en het aantal gelijktijdige gebruikers. Bij lange documenten of uitgebreide chatsessies kan de KV-cache groter worden dan het model zelf. Als de limiet van het geheugen wordt bereikt, zal het systeem verzoeken moeten weigeren of de context inkorten, wat de werking verstoort.

4. De rest van de machine: opslag, netwerk en faciliteiten

Bij het ontwerpen van een on-premise infrastructuur voor AI gaat de aandacht vaak uitsluitend uit naar de versnellers. De omliggende infrastructuur is echter minstens zo belangrijk om knelpunten te voorkomen. Dit betreft de opslagsnelheid, de netwerkbandbreedte binnen het rack en de faciliteiten in de serverruimte.

Modelbestanden zijn groot en moeten bij het opstarten van de diensten of bij een modelwissel van de opslag naar het geheugen van de versneller worden geschreven. Traditionele harde schijven of trage netwerktops (NAS) leiden hier tot lange wachttijden. Het gebruik van snelle, direct aangesloten PCIe NVMe SSD's is noodzakelijk. In productie-omgevingen waar redundantie en snelle recovery belangrijk zijn, moet de opslaginfrastructuur ontworpen zijn op sequentiële leessnelheden van meerdere gigabytes per seconde.

Wanneer een model te groot is voor één versneller, moet het verdeeld worden over meerdere eenheden (tensor parallelism) of zelfs over meerdere fysieke servers (pipeline parallelism). De communicatie tussen deze eenheden tijdens de berekening is extreem intensief. Als de netwerkverbinding tussen de kaarten of de servers een flessenhals vormt, zal de rekenkracht van de versnellers onbenut blijven. Binnen het rack is het gebruik van dedicated, low-latency verbindingen met Remote Direct Memory Access (RDMA) een vereiste voor schaalbare prestaties.

Daarnaast heeft AI-infrastructuur een hoge energiedichtheid. Een enkel serverrack met meerdere versnellers kan tientallen kilowatts aan stroom verbruiken. Dit stelt specifieke eisen aan de stroomtoevoer en de redundante stroomvoorziening (UPS) in de serverruimte. Ook moet de gegenereerde warmte efficiënt worden afgevoerd. Traditionele luchtkoeling is bij hoge dichtheden vaak onvoldoende, waardoor organisaties moeten investeren in vloeistofkoeling (direct-to-chip of immersion cooling) om oververhitting en prestatievermindering te voorkomen.

5. Inferentie versus finetuning: uiteenlopende infrastructurele eisen

De eisen die aan de infrastructuur worden gesteld, hangen sterk af van de activiteit: het gebruiken van een bestaand model (inferentie) of het aanpassen van een model met eigen data (finetuning). De verschillen in rekenkracht en geheugenbelasting zijn fundamenteel.

Tijdens inferentie hoeft het systeem alleen een voorwaartse berekening (forward pass) uit te voeren. De modelparameters blijven ongewijzigd. Bij finetuning moeten daarentegen ook de gradiënten en de optimizer-statistieken in het geheugen worden opgeslagen voor de achterwaartse berekening (backward pass). Dit betekent dat finetuning tot wel drie tot vier keer meer VRAM vereist per modelparameter dan inferentie. Daarnaast is er aanzienlijk meer rekenkracht nodig om de berekeningen binnen een acceptabele tijd af te ronden.

Vanwege deze exponentieel hogere eisen kiezen veel organisaties ervoor om alleen de inferentie on-premise uit te voeren. Het finetunen van modellen gebeurt dan periodiek in een gecontroleerde cloud-omgeving, waarna de getrainde modelgewichten worden geëxporteerd naar de lokale infrastructuur. Dit minimaliseert de noodzaak voor extreem dure trainingshardware die een groot deel van de tijd onbenut zou blijven. De afweging tussen deze scenario's raakt direct aan de totale eigendomskosten van open versus gesloten systemen, zoals beschreven in de analyse van de tco open vs closed.

6. De softwarelaag: van drivers tot modelregister

Een stabiele AI-infrastructuur rust op een goed gestructureerde softwarestack. Zonder de juiste abstractielagen is het beheer van lokale modellen complex en foutgevoelig.

+--------------------------------------------------+
|                  API Gateway                     |
+--------------------------------------------------+
|               Inferentie-engine                  |
+--------------------------------------------------+
|  Containerplatform (K8s) & Versneller-drivers    |
+--------------------------------------------------+
|                Fysieke Hardware                  |
+--------------------------------------------------+

Hoewel bare metal-installaties minimale overhead bieden, heeft containerisatie (bijvoorbeeld via Kubernetes met specifieke runtime-plug-ins voor hardwareversnellers) de voorkeur in enterprise-omgevingen. Containers maken het mogelijk om resources dynamisch toe te wijzen, applicaties te isoleren en workloads snel te verplaatsen of op te schalen.

De interface tussen de hardware en de software wordt gevormd door de drivers en compute-toolkits. Het beheer hiervan is berucht om compatibiliteitsproblemen. Een update van een inferentie-engine kan een nieuwere driverversie vereisen, die op zijn beurt weer compatibel moet zijn met het onderliggende besturingssysteem. Dit vereist een strak change management proces en grondige regressietesten in een staging-omgeving.

De inferentie-engine (zoals vLLM of TensorRT-LLM) optimaliseert de uitvoering van het model door technieken zoals continuous batching en geavanceerd KV-cache beheer. Deze engine wordt ontsloten via een API-gateway die zorgt voor authenticatie, rate limiting en logging. Voor een stabiele integratie is het essentieel om deze lokale modellen achter api te plaatsen, zodat interne applicaties via gestandaardiseerde protocollen kunnen communiceren met de AI-infrastructuur.

Een modelregister fungeert als de 'single source of truth' voor de modelbestanden. Het garandeert dat alleen goedgekeurde, gescande en geverifieerde versies van modelgewichten in productie worden genomen. Dit voorkomt dat individuele ontwikkelaars ongeautoriseerde modellen direct van openbare repositories downloaden en op de infrastructuur draaien.

7. Beschikbaarheid, redundantie en onderhoud

Het garanderen van een hoge beschikbaarheid voor lokale LLM's vereist specifieke maatregelen die afwijken van traditionele IT-diensten. De omvang van de modellen en de specifieke hardware maken standaard failover-scenario's uitdagend.

Het updaten van een model is niet te vergelijken met een software-update van enkele megabytes. Omdat modellen gigantisch zijn, kan het laden ervan enkele minuten in beslag nemen. Om downtime te voorkomen, moeten updates worden uitgevoerd via rolling deployments, waarbij een nieuwe instantie van het model wordt opgestart en getest voordat de oude instantie wordt afgebouwd. Mocht het nieuwe model in productie onverwacht gedrag vertonen (zoals regressie of onjuiste output), dan moet de API-gateway direct kunnen terugvallen op de vorige versie via een geautomatiseerd rollback-mechanisme.

Zelfs de best ontworpen lokale infrastructuur kan te maken krijgen met hardwarestoringen of onverwachte pieken in de vraag. Een hybride architectuur, waarbij de lokale API-gateway bij overbelasting of uitval verzoeken tijdelijk doorstuurt naar een beveiligde, compliant private of public cloud-omgeving, fungeert als een noodklep. Dit garandeert de continuïteit van de bedrijfsvoering zonder dat de lokale infrastructuur overgedimensioneerd hoeft te worden voor zeldzame piekmomenten.

8. Beveiliging en netwerksegmentatie

Een veelgemaakte fout is de aanname dat een interne AI-dienst per definitie veilig is. Binnen een modern IT-landschap moet ook de lokale LLM-infrastructuur volgens zero-trust principes worden ingericht. Dit beschermt de systemen tegen ongeautoriseerde toegang en datalekken.

De inferentie-servers dienen in een apart netwerksegment (VLAN) te worden geplaatst, gescheiden van de algemene kantoorautomatisering en andere applicatieservers. Directe toegang tot de servers die de modellen hosten moet worden geblokkeerd; alle communicatie verloopt via de API-gateway. De verbindingen tussen de client-applicaties, de gateway en de inferentie-servers moeten worden versleuteld met behulp van mTLS (mutual TLS).

Niet elke medewerker of elk intern systeem mag toegang hebben tot elk model. Sommige modellen zijn getraind op gevoelige HR-data of financiële gegevens, terwijl andere bedoeld zijn voor algemene tekstverwerking. Door Role-Based Access Control (RBAC) op de API-gateway te implementeren, wordt afgedwongen dat clients zich moeten authenticeren en alleen de voor hen goedgekeurde endpoints kunnen aanroepen.

Hoewel de data binnen het eigen netwerk blijft, is het noodzakelijk om gedetailleerde logging bij te houden van wie welke data naar het model stuurt. Om te voldoen aan compliancy-eisen moeten deze logs echter geanonimiseerd of gepseudonimiseerd zijn, zodat er geen gevoelige persoonsgegevens in de algemene systeemlogs van de AI-infrastructuur belanden.

9. Beheerlast en teamcompetenties: de verborgen kosten

De aanschafkosten van hardware zijn zichtbaar, maar de operationele beheerlast is in de praktijk vaak de grootste kostenpost. Het beheren van een lokale AI-infrastructuur vereist specialistische kennis die schaars is op de arbeidsmarkt.

Voor het structureel in de lucht houden van een lokaal AI-platform zijn verschillende disciplines vereist. Infrastructuurspecialisten zijn verantwoordelijk voor de fysieke servers, netwerkverbindingen, stroom en koeling. MLOps Engineers vormen de brug tussen data science en IT-operations; zij beheren de inferentie-engines, containerorchestratie en het modelregister. Security Officers waken over de naleving van beveiligingsrichtlijnen en controleren de dataflows. Tot slot bewaken AI Validators de kwaliteit en nauwkeurigheid van de modeloutputs om drift en bias tijdig te signaleren.

Veel organisaties onderschatten de complexiteit van het onderhouden van deze stack. Wanneer er storingen optreden in de drivers of de hardwareversnellers, kan dit niet door een reguliere systeembeheerder worden opgelost. De structurele kosten voor het opleiden en inhuren van dit personeel moeten integraal worden meegenomen in de businesscase. Dit aspect vormt een belangrijk onderdeel van een realistisch ai-implementatieplan mkb.

10. Een realistische uitrolvolgorde

Het direct bouwen van een grootschalige on-premise productie-omgeving brengt onacceptabele risico's met zich mee. Een gefaseerde aanpak zorgt ervoor dat investeringen pas worden gedaan wanneer de onderliggende aannames zijn bewezen.

Fase	Doelstelling	Infrastructuur	Beslispunt voor volgende fase
1. Proof of Concept	Functionele validatie van het geselecteerde model	Tijdelijke cloud of bestaande lokale hardware	Voldoet het model aan de gestelde functionele eisen?
2. Gecontroleerde Pilot	Meten van systeemprestaties en resourcegebruik	Gelimiteerde on-premise test-node	Zijn de latency- en geheugenaspecten acceptabel onder belasting?
3. Productie-inrichting	Schalen, redundantie en volledige integratie	Volledig redundant on-premise cluster	Is de beheerorganisatie gereed voor operationele live-gang?

In de Proof of Concept (PoC) fase staat de functionele werking centraal. Er wordt onderzocht of het model in staat is om de gewenste taken uit te voeren. Dit kan vaak kostenefficiënt op cloud-infrastructuur worden gedaan, aangezien databeveiliging in deze verkennende fase met geanonimiseerde data kan worden opgevangen.

Zodra de functionaliteit is bewezen, wordt de overstap gemaakt naar een lokale testomgeving (de pilot) met representatieve data. Hier worden de werkelijke systeemprestaties gemeten: hoe gedraagt het geheugen zich onder belasting? Hoeveel tokens per seconde worden er daadwerkelijk gegenereerd? Deze data is cruciaal voor de definitieve dimensionering van de hardware.

Pas na een succesvolle pilot wordt geïnvesteerd in de volledige on-premise productie-infrastructuur, inclusief redundantie, back-upvoorzieningen en koppelingen met de centrale monitoring- en beveiligingssystemen. De transitie naar deze fase is pas voltooid als ook het beheerteam volledig is ingericht en getraind.