# VRAM-rekenhulp: hoeveel geheugen heeft een model nodig? [Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fgids.llmnet.nl%2Fvram-rekenhulp-hoeveel-geheugen-heeft-welk-model-nodig&text=VRAM-rekenhulp%3A%20hoeveel%20geheugen%20heeft%20een%20model%20nodig%3F)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fgids.llmnet.nl%2Fvram-rekenhulp-hoeveel-geheugen-heeft-welk-model-nodig)[](https://www.reddit.com/submit?url=https%3A%2F%2Fgids.llmnet.nl%2Fvram-rekenhulp-hoeveel-geheugen-heeft-welk-model-nodig&title=VRAM-rekenhulp%3A%20hoeveel%20geheugen%20heeft%20een%20model%20nodig%3F)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fgids.llmnet.nl%2Fvram-rekenhulp-hoeveel-geheugen-heeft-welk-model-nodig&text=VRAM-rekenhulp%3A%20hoeveel%20geheugen%20heeft%20een%20model%20nodig%3F)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fgids.llmnet.nl%2Fvram-rekenhulp-hoeveel-geheugen-heeft-welk-model-nodig)[](https://www.reddit.com/submit?url=https%3A%2F%2Fgids.llmnet.nl%2Fvram-rekenhulp-hoeveel-geheugen-heeft-welk-model-nodig&title=VRAM-rekenhulp%3A%20hoeveel%20geheugen%20heeft%20een%20model%20nodig%3F)[](#) # VRAM-rekenhulp: hoeveel geheugen heeft een model nodig? Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) Praktische testopstelling en ondergrens: De metingen in deze rekenhulp zijn gevalideerd op een Nvidia RTX 4090 (24 GB VRAM) onder Ubuntu 24.04 met CUDA 12.6 en Ollama 0.3.12 / llama.cpp b3600. Als hardwarematige ondergrens voor vlotte lokale inferentie (minimaal 25 tokens/s op een 8B Q4_K_M model) geldt een GPU met ten minste 8 GB VRAM of een Apple Silicon Mac met 16 GB Unified Memory. Binnen de route van lokaal taalmodellen draaien bevindt deze rekenhulp zich in de overgang tussen het selecteren van de juiste componenten en het daadwerkelijk configureren van software-engines. Voordat een model kan worden ingeladen, moet helder zijn hoe zwaar het beslag op het videogeheugen (VRAM) uitvalt. Wie eerst wil nagaan welke fysieke insteekkaarten of processors geschikt zijn, kan terecht bij het overzicht over [welke hardware nodig is om LLM's lokaal te draaien](https://gids.llmnet.nl/hardware-voor-lokale-llm). De meest gemaakte fout bij het dimensioneren van een lokale opstelling is te uitsluitend kijken naar de bestandsgrootte van het model op schijf. Een GGUF-bestand van 4,8 gigabyte past niet zonder meer in een videokaart van 6 gigabyte zodra er een serieuze promptinvoer aan te pas komt. Naast de statische modelgewichten (weights) leggen namelijk ook de KV-cache (het contextgeheugen), de tussenliggende activatielagen en de runtime-overhead van stuurprogramma's beslag op het fysieke geheugen. In deze handleiding ontleden we de exacte componenten van de geheugenvraag en geven we de rekenformules om vooraf vast te stellen of een configuratie stabiel blijft draaien. ## De vier pijlers van het totale geheugenbeslag Wanneer een runtime zoals llama.cpp, Ollama, vLLM of LM Studio een taalmodel initialiseert, wordt het benodigde VRAM opgebouwd uit vier afzonderlijke segmenten. Het totale benodigde geheugen ($VRAM_{totaal}$) is de optelsom van deze delen: VRAM_totaal = Geheugen_Weights + Geheugen_KV_Cache + Geheugen_Activaties + Geheugen_CUDA_Overhead Het onderschatten van een van deze factoren leidt onherroepelijk tot een Out-of-Memory (OOM) foutmelding of tot het ongewenst terugvallen op het trage systeem-RAM. Laten we elk onderdeel afzonderlijk analyseren en kwantificeren. ## 1. Modelgewichten: de statische basis Het gewichtengeheugen is het eenvoudigst te voorspellen. Dit is de ruimte die nodig is om alle parameters van het neurale netwerk in het VRAM te parkeren. De omvang hangt af van twee variabelen: het aantal parameters ($P$, uitgedrukt in miljarden) en de precisie per parameter ($b$, uitgedrukt in bits per parameter, oftewel bpw). De basisformule voor het gewichtengeheugen in gigabytes (GB) luidt als volgt: Geheugen_Weights (GB) = (Aantal_Parameters_in_miljarden * Bits_per_parameter) / 8 * 1,05 De factor 1,05 compenseert voor metadata, vocabulaire-tensors en tensor-uitlijning binnen het geheugen. Bij 16-bit precisie (FP16 of BF16) gebruikt elke parameter 2 bytes (16 bits). Een 8B-model zoals Llama-3-8B vereist in volle resolutie dus circa (8 * 16) / 8 * 1,05 = 16,8 GB aan VRAM, uitsluitend om de gewichten te laden. Omdat 16 GB aan VRAM een stevige drempel vormt voor consumentenkaarten, worden modellen verkleind via kwantisatie. Hoe die compressietechnieken wiskundig functioneren en wat het effect is op de precisie, staat uitgebreid beschreven in het artikel waarin [kwantisatie en bit-reductie op lokale hardware](https://gids.llmnet.nl/kwantisatie-uitgelegd) wordt uitgeplozen. Bij een gangbaar 4-bit formaat (zoals Q4_K_M, gemiddeld 4,5 bits per parameter inclusief schaalfactoren) daalt het gewichtsbeslag van datzelfde 8B-model naar circa (8 * 4,5) / 8 * 1,05 = 4,72 GB. ## 2. De KV-Cache: waarom contextlengte geheugen vreet Tijdens het genereren van tekst moet het model de sleutel- en waarde-vectoren (Key-Value pairs) van alle voorgaande tokens in het contextvenster onthouden. Zonder deze KV-cache zou het model bij elk nieuw gegenereerd woord de complete voorgaande context opnieuw moeten berekenen, wat de responstijd kwadratisch zou vertragen. De KV-cache groeit lineair met de lengte van de context. De omvang hangt af van vier architecturale eigenschappen van het model: - $L$: Aantal transformerlagen (layers). - $H_{kv}$: Aantal Key/Value attention heads (bij Grouped-Query Attention, GQA, is dit vaak een fractie van het totaal aantal query heads). - $D_h$: De dimensie per head (head dimension, vaak de verborgen dimensie gedeeld door het aantal query heads, typisch 64 of 128). - $C$: De actieve contextlengte in aantal tokens (bijvoorbeeld 4.096, 8.192 of 32.768 tokens). - $B_{kv}$: De precisie van de KV-cache in bytes (standaard FP16 = 2 bytes). De universele formule voor de KV-cache per token luidt: KV_Cache_per_token (bytes) = 2 * L * H_kv * D_h * B_kv De vermenigvuldiging met 2 ontstaat doordat we zowel een Key- als een Value-vector opslaan. Voor een model met Grouped-Query Attention (zoals Llama-3-8B met 32 lagen, 8 KV-heads, head-dimensie 128 en FP16-precisie) levert dit op: KV_Cache_per_token = 2 * 32 * 8 * 128 * 2 = 131.072 bytes = 128 KB per token Bij een bescheiden venster van 4.096 tokens gebruikt de KV-cache: 4.096 * 128 KB = 512 MB. Wordt het contextvenster echter opgerekt naar 64.000 tokens, dan slokt de KV-cache plotseling 8,0 GB aan puur videogeheugen op. Voor een diepere duik in het wiskundige model achter deze toewijzing kan men experimenteren met de [interactieve KV-cache geheugencalculator op leren.llmnet.nl](https://leren.llmnet.nl/tool-kv-cache-calculator) om te zien hoe verschillende modelarchitecturen schalen. Modelarchitectuur | Lagen ($L$) | KV Heads ($H_{kv}$) | Head Dim ($D_h$) | Cache per token | Cache bij 8k context | Cache bij 32k context | Mistral-7B / Llama-3-8B | 32 | 8 | 128 | 128 KB | 1,00 GB | 4,00 GB | Qwen-2.5-14B | 48 | 8 | 128 | 192 KB | 1,50 GB | 6,00 GB | Command-R (35B) | 40 | 8 | 128 | 160 KB | 1,25 GB | 5,00 GB | Llama-3-70B | 80 | 8 | 128 | 320 KB | 2,50 GB | 10,00 GB | Oudere MHA-modellen (bijv. Llama-1 13B) | 40 | 40 | 128 | 800 KB | 6,25 GB | 25,00 GB | Wie zijn contextvenster verkeerd instelt, blaast zelfs de snelste videokaart op. Hoe men deze parameters veilig begrenst en beheert, behandelen we in de handleiding over [de contextlengte instellen bij lokaal draaien](https://gids.llmnet.nl/context-window-optimaliseren-lokaal). ## 3. Activatiegeheugen en CUDA-runtime overhead Naast de statische gewichten en de dynamische KV-cache reserveren inferentie-engines tijdelijke buffers. Tijdens de voorwaartse berekening (de forward pass) moeten tussenresultaten van matrixvermenigvuldigingen, layer normalization en softmax-operaties kortstondig worden opgeslagen. Dit heet het activatiegeheugen. Bij batch size 1 (één individuele gebruiker die interactief chat) blijft het activatiegeheugen beperkt tot circa 150 MB tot 500 MB. Wordt het model echter ingezet als lokale server voor meerdere gelijktijdige verzoeken of bij parallelle evaluaties van agents, dan schaalt dit geheugen evenredig mee met de batchgrootte. Daarnaast is er de onvermijdelijke CUDA Runtime Overhead. Zodra een Nvidia-stuurprogramma en de PyTorch- of CUDA-context worden geïnitialiseerd, claimt het besturingssysteem direct een vast blok VRAM. Op Windows 11 reserveert het Desktop Window Manager (DWM) systeemproces standaard 400 MB tot 1,2 GB VRAM voor de grafische weergave. Op een headless Linux-systeem blijft deze driver-overhead beperkt tot circa 200 MB tot 350 MB. Voor een veilige calculatie hanteren we daarom altijd een vaste marge van 0,8 GB tot 1,2 GB voor activaties en runtime-overhead samen. ## Snelle rekentabellen: vuistregels per modelklasse Om niet telkens ingewikkelde formules uit te hoeven voeren, gebruiken we in de praktijk onderstaande matrix. Deze tabel toont de totale benodigde VRAM-omvang inclusief modelgewichten, 8k contextvenster (FP16 KV-cache) en 1 GB buffer voor runtime en activaties. Modelformaat | Kwantisatie | Weights (GB) | KV-Cache 8k (GB) | Overhead & Activaties | Aanbevolen VRAM | 8B parameters | Q4_K_M (4,5 bpw) | 4,7 GB | 1,0 GB | 0,8 GB | 8 GB | 8B parameters | Q8_0 (8,5 bpw) | 8,9 GB | 1,0 GB | 0,8 GB | 12 GB | 14B parameters | Q4_K_M (4,5 bpw) | 8,3 GB | 1,5 GB | 0,9 GB | 12 GB | 14B parameters | Q8_0 (8,5 bpw) | 15,6 GB | 1,5 GB | 0,9 GB | 20 GB | 32B parameters | Q4_K_M (4,5 bpw) | 18,9 GB | 2,0 GB | 1,0 GB | 24 GB | 70B parameters | Q4_K_M (4,5 bpw) | 41,3 GB | 2,5 GB | 1,2 GB | 48 GB (2x 24GB) | Mixtral 8x7B (MoE) | Q4_K_M (4,5 bpw) | 26,5 GB | 1,5 GB | 1,0 GB | 32 GB | Uit deze tabel blijkt direct waarom een 32B model met 4-bit kwantisatie nét binnen het budget van een 24 GB videokaart (zoals de RTX 3090 of 4090) past, zolang de context beperkt blijft tot maximaal 8.192 tokens. Wordt dezelfde 32B-variant gebruikt voor het analyseren van een groot PDF-document van 32.000 tokens, dan overstijgt het totale geheugengebruik de 26 GB en crasht het proces. ## Mixture-of-Experts (MoE): parameters opslaan versus berekenen Bij klassieke dense modellen (zoals Llama-3) is elke parameter actief bij elk gegenereerd token. Bij Mixture-of-Experts (MoE) architecturen, zoals Mixtral 8x7B of Mixtral 8x22B, wordt voor elk token slechts een subset van de beschikbare 'experts' geactiveerd (bijvoorbeeld 2 van de 8 experts, wat resulteert in circa 13 miljard actieve parameters per token bij Mixtral 8x7B). Dit leidt vaak tot een hardnekkig misverstand over geheugengebruik. Hoewel een MoE-model rekentechnisch net zo snel kan zijn als een veel kleiner model, moeten alle experts tegelijkertijd in het VRAM aanwezig blijven. De routering tussen experts wisselt immers per token. Voor de VRAM-berekening telt het totale aantal opgeslagen parameters, niet het aantal actieve parameters: - Mixtral 8x7B: Bevat in totaal 46,7 miljard unieke parameters. In Q4_K_M vereist dit circa 26,5 GB VRAM aan gewichten, hoewel de rekensnelheid vergelijkbaar is met een 13B-model. - Mixtral 8x22B: Bevat 141 miljard parameters. In Q4_K_M vraagt dit meer dan 80 GB VRAM, wat minimaal vier 24GB-GPU's of een Mac Studio met 128 GB Unified Memory vereist. ## Apple Silicon en Unified Memory: een ander rekenmodel Op een Apple Mac met een M-serie processor (M2/M3/M4 Max of Ultra) is er geen sprake van afzonderlijk videogeheugen. De processor en de grafische kernen delen dezelfde geheugenpool (Unified Memory Architecture). Dit biedt enorme voordelen voor het draaien van gigantische modellen van 70B of 120B parameters, maar kent ook een belangrijke beperking. Standaard reserveert macOS een deel van het gedeelde geheugen voor het besturingssysteem en grafische vensters. macOS staat applicaties zoals llama.cpp of MLX standaard toe om maximaal 75% van het totale RAM-geheugen toe te wijzen aan de GPU (sysctl iogpu.wired_mem_limit). Op een Mac met 32 GB RAM is er dus standaard circa 24 GB beschikbaar voor het taalmodel. Met het volgende Terminal-commando kan deze limiet op eigen risico worden verhoogd naar 90%, zodat er meer ruimte ontstaat voor zwaardere kwantisaties: sudo sysctl iogpu.wired_mem_limit=28672 De waarde 28672 staat hier voor 28 GB (in megabytes). Houd er rekening mee dat wanneer het besturingssysteem te weinig geheugen overhoudt voor essentiële taken, het systeem kan bevriezen of agressief naar schijf gaat swappen, wat de generatiesnelheid decimeert. ## Praktische strategieën om geheugen te besparen Wanneer een model net enkele honderden megabytes te groot is voor het aanwezige VRAM, hoeft men niet direct over te stappen op een veel kleiner model. Er zijn verschillende geavanceerde technieken om het geheugengebruik omlaag te drukken zonder substantieel kwaliteitsverlies: ### 1. Kwantisatie van de KV-Cache (K-quants / V-quants) Standaard slaat llama.cpp de KV-cache op in 16-bit float (FP16). Zowel llama.cpp als vLLM ondersteunen tegenwoordig 8-bit (Q8_0) en zelfs 4-bit (Q4_0) kwantisatie van de KV-cache. Door de cache terug te brengen naar Q8_0 halveert het geheugenbeslag van het contextvenster direct, terwijl het verschil in accuratesse bij de meeste benchmarks statistisch verwaarloosbaar is. # Start llama.cpp server met 8-bit KV-cache kwantisatie ./llama-server -m models/llama-3-8b-instruct-q4_k_m.gguf -c 16384 -ctk q8_0 -ctv q8_0 ### 2. Laag-voor-laag offloading (GPU Layer Offloading) Wie over een GPU met 8 GB of 12 GB beschikt en een 14B of 32B model wil draaien, kan het model splitsen. Met de parameter -ngl (aantal GPU-lagen) in llama.cpp worden bijvoorbeeld 20 van de 32 lagen op de snelle videokaart geplaatst, terwijl de resterende 12 lagen door de CPU worden berekend in het normale werkgeheugen. Dit vertraagt de generatie aanzienlijk, maar voorkomt een complete weigering om te starten. Wanneer de configuratie ondanks deze aanpassingen blijft vastlopen, raadpleeg dan het overzicht over [wat te doen bij out-of-memory meldingen en trage tokens](https://gids.llmnet.nl/als-het-niet-werkt-out-of-memory-trage-tokens-en-een-gpu-die-niet-meed) voor stapsgewijze foutopsporing. ## Geheugengebruik controleren en meten in de praktijk Om te verifiëren of de theoretische berekeningen overeenkomen met de werkelijkheid, is het raadzaam om tijdens het verwerken van een prompt live mee te kijken met gespecialiseerde meetprogramma's. Onder Linux en Windows (met WSL2) geeft de officiële Nvidia-tool direct inzicht in de totale allocatie: # Doorlopend monitoren van VRAM en GPU-belasting (elke 1000ms) nvidia-smi --query-gpu=memory.used,memory.free,memory.total,utilization.gpu --format=csv -l 1 Een veel intuïtiever alternatief in de terminal is de interactieve viewer nvtop, die per proces laat zien welke VRAM-allocaties actief zijn en hoe dynamisch het geheugen stijgt zodra een lange invoerprompt de KV-cache opvult: # Installeer en start nvtop op Ubuntu/Debian sudo apt update && sudo apt install -y nvtop nvtop Let tijdens het testen vooral op de piek-allocatie (peak allocation) aan het einde van een omvangrijke tekstgeneratie. Een model dat bij prompt-invoer stabiel 18 GB gebruikt, kan bij het bereiken van token 8.000 ineens over de 24 GB schieten en crashen. ## Gegevensbescherming en netwerkzekerheid Het nauwkeurig dimensioneren van de eigen hardware heeft een directe relatie met informatieveiligheid. Wanneer een model door geheugengebrek instabiel wordt en crasht, zijn beheerders vaak geneigd om uitwijkmogelijkheden naar externe cloud-API's in te bouwen. Hierdoor kunnen gevoelige bedrijfsgegevens of persoonsgegevens alsnog onbedoeld via externe servers lopen. Door vooraf te garanderen dat een model inclusief maximale contextruimte binnen het lokale VRAM past, blijft alle data gegarandeerd binnen de eigen fysieke perimeter. Meer achtergronden over de organisatorische en juridische voordelen hiervan zijn te vinden in de toelichting over [privacyvriendelijk werken met AI op eigen systemen](https://gids.llmnet.nl/privacyvriendelijk-ai). Ook voor particuliere gebruikers die hun thuisomgeving willen beveiligen tegen onbedoelde datalekken biedt de gids met [praktische tips voor een veilige AI-thuisopstelling](https://gids.llmnet.nl/ai-veilig-thuis) handige handvatten. ## Kwaliteitsbewaking en contextgrenzen Een model dat net op de rand van zijn VRAM-capaciteit balanceert met een extreem gecomprimeerde 2-bit kwantisatie of een kunstmatig ingekort contextvenster, presteert inhoudelijk significant minder betrouwbaar. Informatie die buiten het contextvenster valt, wordt door het model simpelweg 'vergeten', wat leidt tot hallucinaties en feitelijke onjuistheden. Het is daarom cruciaal om gegenereerde antwoorden systematisch te verifiëren, zeker wanneer er concessies zijn gedaan aan de modelprecisie om binnen het videogeheugen te blijven. Zie hiervoor de praktische controlemethodiek over [het systematisch factchecken van AI-antwoorden](https://gids.llmnet.nl/ai-antwoorden-factchecken). Voor ontwikkelaars die lokale taalmodellen willen integreren in geavanceerde autonome systemen en meervoudige tooling-loops, is een gedegen kennis van hardwarebeperkingen, latentie en contextbeheer een absolute vereiste. Wie zijn vaardigheden op dit vlak structureel wil uitbouwen tot een professioneel niveau, vindt een compleet overzicht in het leerpad over [hoe je in 2026 een professionele AI-agent engineer wordt](https://leren.llmnet.nl/ai-agent-engineer-worden-2026). ## Conclusie en overzicht VRAM-berekening is geen kwestie van gokken, maar van een eenvoudige optelsom van vier factoren. Door vooraf de som te maken van de modelgewichten (aantal parameters vermenigvuldigd met de bit-precisie), de KV-cache op basis van het beoogde contextvenster en een vaste veiligheidsmarge van circa 1 tot 1,5 GB voor CUDA-activaties, voorkom je teleurstellingen en instabiele systemen. Wie op zoek is naar een stabiele lokale werkomgeving, kiest bij voorkeur een modelkwantisatie waarbij het totale geheugenbeslag bij maximale context minstens 10% tot 15% onder de fysieke VRAM-grens van de grafische kaart blijft. Daarmee blijft de lokale AI-opstelling snel, betrouwbaar en te allen tijde operationeel zonder haperingen.