Welke hardware heb je nodig om een taalmodel lokaal te draaien?
RAM, VRAM, quantisatie en opslag bepalen welk taalmodel lokaal past. Praktische vuistregels voor 7B tot 70B+ modellen op CPU, GPU en Apple Silicon.
Om een taalmodel lokaal te draaien heb je vooral voldoende geheugen nodig voor de modelgewichten, plus extra ruimte voor de inference-engine, context en KV-cache. Als basisvuistregel vraagt een model in FP16 ongeveer 2 GB geheugen per miljard parameters. Bij 8-bit quantisatie is dat ongeveer 1 GB per miljard parameters en bij 4-bit ongeveer 0,5 GB per miljard parameters. Dit zijn theoretische minima voor de gewichten zelf; in de praktijk is meer RAM of VRAM nodig.
Een 7B-model vraagt daardoor ruwweg 14 GB voor alleen de FP16-gewichten, circa 7 GB in 8-bit en ongeveer 3,5 GB in 4-bit. Voor 13B is dat respectievelijk ongeveer 26, 13 en 6,5 GB; voor 70B circa 140, 70 en 35 GB. Of dat geheugen gewone RAM, GPU-VRAM of unified memory moet zijn, hangt af van de hardware en de inference-engine — los van de bredere afweging wanneer on-prem AI de investering waard is.
Parameters bepalen de basisbehoefte aan geheugen
De parameteromvang van een taalmodel is de eerste indicator voor de benodigde hardware. Een model met 7 miljard parameters wordt meestal aangeduid als 7B, een model met 70 miljard parameters als 70B. Voor inference kun je voor de modelgewichten deze eenvoudige rekensom gebruiken:
| Modelgrootte | FP16 | 8-bit | 4-bit |
|---|---|---|---|
| 7B | ~14 GB | ~7 GB | ~3,5 GB |
| 13B | ~26 GB | ~13 GB | ~6,5 GB |
| 30B | ~60 GB | ~30 GB | ~15 GB |
| 70B | ~140 GB | ~70 GB | ~35 GB |
Deze waarden zijn geen complete systeemeisen. Quantisatieformaten slaan vaak ook schalen, metadata en andere gegevens op. Daarnaast gebruikt de inference-software geheugen voor buffers en tijdelijke berekeningen. Een machine met precies evenveel geheugen als de theoretische omvang van het model is daarom meestal te krap.
Quantisatie maakt grotere modellen praktisch uitvoerbaar
De oorspronkelijke gewichten van veel modellen worden opgeslagen of uitgevoerd in FP16 of BF16: 16 bits per parameter. Eén miljard parameters neemt dan ruwweg 2 GB in beslag. Bij 8-bit quantisatie worden de gewichten teruggebracht tot ongeveer één byte per parameter — het geheugengebruik van de gewichten halveert daarmee grofweg. Bij 4-bit quantisatie daalt het theoretische gewichtengebruik naar ongeveer een halve byte per parameter.
De werkelijke bestandsgrootte ligt vaak iets boven die theoretische ondergrens: quantisatie vereist aanvullende informatie, en verschillende methoden — zoals GGUF-quantisaties of GPU-georiënteerde quantisatieformaten — hebben hun eigen overhead. Lagere precisie is bovendien niet uitsluitend een geheugenbesparing; het kan ook invloed hebben op modelkwaliteit en rekensnelheid. Voor lokale inference is 4-bit desondanks een veelgebruikte manier om een model op hardware te draaien waarop de FP16-versie niet zou passen. Zie ook welk open model past op welke hardware.
Vergeet context en KV-cache niet
De modelgewichten zijn niet de enige gebruiker van geheugen. Tijdens autoregressieve inference bewaart het model informatie over eerder verwerkte tokens in de KV-cache. Hoe langer de context, hoe groter die cache. Het geheugengebruik hangt onder andere af van de architectuur van het model, het aantal lagen, de contextlengte, de gebruikte precisie en het aantal gelijktijdige requests.
Een model dat zonder problemen met een korte prompt in het geheugen past, kan daarom bij een veel groter contextvenster alsnog tegen de geheugenlimiet lopen. Bij servers die meerdere gebruikers tegelijk bedienen wordt dit effect nog belangrijker, omdat verschillende requests gelijktijdig geheugen gebruiken. Hardware dimensioneren op uitsluitend de bestandsgrootte van het quantized model is daarom onvoldoende — er moet ruimte overblijven voor de runtime en de gewenste contextbelasting.
CPU-inference: veel RAM, maar meestal lagere snelheid
Een taalmodel hoeft niet op een GPU te draaien. Engines die gequantiseerde modellen efficiënt op CPU's uitvoeren, kunnen modelgewichten volledig in het systeem-RAM laden. Het voordeel is dat RAM relatief eenvoudig in grote hoeveelheden beschikbaar kan zijn, waardoor een model dat niet in het VRAM van één GPU past soms wel volledig op een CPU-machine kan draaien.
Het nadeel is doorgaans de inference-snelheid. LLM-inference bestaat voor een belangrijk deel uit grote matrixbewerkingen en geheugenverkeer, waarvoor moderne GPU's zeer geschikt zijn. CPU-inference is daarom vooral bruikbaar wanneer lage latency geen harde eis is, het aantal gelijktijdige gebruikers beperkt blijft, of wanneer beschikbaar RAM belangrijker is dan maximale tokensnelheid. Geheugenbandbreedte en CPU-architectuur hebben daarbij veel invloed — alleen naar het aantal cores kijken geeft geen compleet beeld.
GPU-inference: VRAM is meestal de beperkende factor
Voor snelle lokale inference is een GPU vaak de praktischste optie. Het model wordt geheel of gedeeltelijk in het VRAM geladen en de matrixberekeningen worden op de GPU uitgevoerd. De belangrijkste vraag is dan niet alleen hoe snel de GPU is, maar vooral hoeveel VRAM beschikbaar is.
Een consumenten-GPU met voldoende VRAM kan 7B- en andere relatief compacte modellen uitstekend uitvoeren, vooral met 8-bit of 4-bit quantisatie. Naarmate modellen groter worden, wordt VRAM steeds vaker de beperkende factor. Past het model niet volledig in VRAM, dan kunnen sommige runtimes een deel van de lagen in systeem-RAM houden en alleen een gedeelte naar de GPU offloaden — dat maakt grotere modellen uitvoerbaar, maar datatransport tussen CPU en GPU kan de prestaties beperken.
Apple Silicon en unified memory
Apple Silicon gebruikt geen apart systeem-RAM en GPU-VRAM zoals een traditionele pc met losse videokaart: CPU en GPU delen een gezamenlijke unified-memorypool. Dat kan voor lokale LLM-inference gunstig zijn — een systeem met tientallen gigabytes unified memory kan een groter model aan de GPU beschikbaar stellen dan een losse consumenten-GPU met een veel kleinere VRAM-pool.
Die geheugencapaciteit is echter niet volledig beschikbaar voor het model. macOS, andere applicaties, de inference-runtime, context en KV-cache gebruiken dezelfde pool. Unified memory moet daarom worden gedimensioneerd op het totale systeemgebruik, niet alleen op de grootte van het modelbestand. Bovendien is het geheugen bij Apple Silicon-systemen niet achteraf uit te breiden.
Hoeveel schijfruimte heb je nodig?
Naast werkgeheugen is opslag nodig voor modelbestanden. De benodigde ruimte volgt grofweg dezelfde orde als de modelgewichten: een 70B-model in 4-bit neemt tientallen gigabytes in beslag, terwijl dezelfde gewichten in FP16 ruim boven de honderd gigabyte kunnen uitkomen. In de praktijk is extra ruimte nodig voor verschillende quantisaties, tokenizerbestanden, runtimebestanden en eventueel meerdere modellen.
Een SSD heeft de voorkeur boven een harde schijf, vooral bij het laden van grote modellen. Zodra het model in RAM of VRAM staat, bepaalt opslag doorgaans niet de tokensnelheid, maar een snelle SSD verkort wel de laadtijd.
Wanneer is één consumenten-GPU voldoende?
Eén consumenten-GPU is doorgaans voldoende wanneer het gewenste model — inclusief quantisatie, runtime en KV-cache — comfortabel binnen het beschikbare VRAM past. Voor compacte modellen in de orde van 7B tot circa 13B is dat met geschikte quantisatie vaak goed haalbaar. Grotere modellen kunnen eveneens op één GPU draaien wanneer deze voldoende VRAM heeft, maar de geheugenbehoefte moet altijd per model en contextinstelling worden gecontroleerd.
Zodra het gewenste model niet meer in één VRAM-pool past, zijn er drie gebruikelijke routes: agressiever quantiseren, een deel van het model naar systeem-RAM offloaden, of meerdere GPU's gebruiken.
Wanneer heb je meerdere GPU's of een server nodig?
Meerdere GPU's worden relevant wanneer de modelgewichten en benodigde runtime-capaciteit groter zijn dan één GPU kan bevatten, of wanneer meerdere gelijktijdige gebruikers hoge throughput vereisen. Frameworks kunnen modelgewichten over meerdere GPU's verdelen — dat vergroot de totale beschikbare VRAM-capaciteit, maar introduceert communicatie tussen GPU's, waardoor de interconnect en softwarestack belangrijker worden.
Voor productie-inference kunnen daarnaast servereigenschappen relevant worden die op een desktop minder belangrijk zijn: grote RAM-capaciteit, veel PCIe-bandbreedte, koeling voor continue belasting, beheer op afstand en ruimte voor meerdere GPU's. Een server is dus niet automatisch nodig omdat een model lokaal draait — de grens wordt vooral bepaald door modelgrootte, gewenste context, concurrency en de hoeveelheid geheugen die daarvoor tegelijk beschikbaar moet zijn.
Praktische vuistregel
Begin voor inference met 2 GB per miljard parameters voor FP16, 1 GB voor 8-bit en 0,5 GB voor 4-bit, en beschouw dat uitsluitend als het geheugen voor de gewichten. Reserveer daarnaast capaciteit voor context, KV-cache en de runtime. Past alles ruim in het VRAM van één GPU, dan is een consumenten-GPU vaak voldoende. Past het alleen in systeem-RAM, dan is CPU- of gedeeltelijke GPU-inference mogelijk. Zodra model, context en gelijktijdige requests niet meer in één geheugenpool passen, komen meer unified memory, meerdere GPU's of een server in beeld.