LLM VRAM-vereisten: De Master-tabel voor 2026 (Elk Model, Elke Quant)

LLM VRAM-vereisten: De Master-tabel voor 2026 (Elk Model, Elke Quant)

Hier is het cijfer dat iedereen verrast: DeepSeek-V3.2 heeft 671 miljard parameters, maar er vuren er maar 37 miljard af per token. Dus hoeveel VRAM heeft het model dan echt nodig? Alle 671 miljard, ruwweg 382 GB bij Q4. LLM VRAM-vereisten volgen zelden je intuïtie, en precies in het gat tussen "actieve parameters" en "wat je moet laden" ontploffen hardwarebudgetten. Deze gids geeft je de mastertabel (elk groot open model, elk quantisatieniveau, het GB-cijfer en de GPU die het draait) plus de formule om in ongeveer tien seconden zelf elk model te berekenen.

Belangrijkste inzichten

• VRAM voor de gewichten ≈ parameters × bytes-per-param: FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Tel daar de KV cache en ongeveer 15-20% overhead bij op.
• Mixture-of-Experts-modellen (DeepSeek, GLM-5.2, Qwen3-235B) moeten elke expert in VRAM laden. "Actieve parameters" leveren snelheid op, geen geheugenbesparing.
• De KV cache is de verborgen kostenpost. Llama 3.3 70B heeft ongeveer 2.6 GB cache nodig bij 8K context en ruwweg 41 GB bij 128K, bovenop de gewichten.
• Q4_K_M is de verstandige standaardkeuze: bijna volledige kwaliteit bij ongeveer een kwart van de FP16-omvang.
• Een 12B-model zoals Gemma 4 past op een 8 GB-kaart bij Q4. Een dense 70B-model heeft ongeveer 40 GB nodig. Een frontier-MoE van 671B heeft een kleine server nodig.

LLM VRAM-vereisten per Model: De Master-tabel

Het korte antwoord: bij Q4_K_M passen kleine modellen (onder 14B) op consumentenkaarten van 8-12 GB, willen middelgrote modellen (24-32B) 16-24 GB, heeft een dense 70B-model ongeveer 40 GB nodig, en springen de frontier-MoE-modellen naar honderden gigabytes omdat elke expert aanwezig moet zijn. Hier staat het complete plaatje op één plek. Alle cijfers betreffen alleen het geheugen voor de gewichten, berekend uit het aantal parameters van elk model en gecontroleerd aan de officiële model cards van Meta AI, Qwen en Hugging Face.

Twee dingen vallen op in deze tabel. Ten eerste is quantisatie de grootste hefboom die je hebt: overstappen van FP16 naar Q4 verkleint de omvang met ruwweg 4x, met een nauwelijks merkbaar kwaliteitsverlies. Ten tweede zien de MoE-rijen er brute uit, en dat zijn ze ook. Qwen3-30B-A3B activeert slechts 3B parameters per token, dus het draait op de snelheid van een piepklein model, maar je moet nog steeds alle 30B in het geheugen houden om elke expert paraat te hebben. Wil je de details per model achter deze cijfers? Onze Gemma 4 12B-diepteanalyse en het overzicht van de beste open-source LLM's van 2026 behandelen de benchmarks en licenties.

De VRAM-formule: Bereken Zelf Elk Model

Om de omvang van een model te berekenen, vermenigvuldig je het aantal parameters met de bytes-per-parameter voor jouw quantisatie, en tel je er een beetje bij op voor de KV cache en runtime-overhead. Dat is alles. De gewichten zijn de dominante term, en de rekensom is simpel genoeg om achterop een bierviltje te doen.

De kernvergelijking voor de gewichten:

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

De bits-per-weight-waarden die je nodig hebt (dit zijn de effectieve tarieven voor GGUF k-quant-bestanden, die wat extra blokmetadata dragen bovenop de nominale bitdiepte):

Uitgewerkt voorbeeld, Gemma 4 12B bij Q4_K_M: 11.95 × 4.5 ÷ 8 = ongeveer 6.7 GB voor de gewichten. Dat komt overeen met de ruwweg 6.6 GB die de officiële model card noemt, en verklaart waarom het model op een 8 GB-kaart past met ruimte voor een bescheiden context. Doe dezelfde rekensom voor een 70B-model bij Q4 en je komt uit op 70 × 4.5 ÷ 8 = 39.4 GB. Dat is precies waarom "je hebt twee 24 GB-kaarten of één 48 GB-kaart nodig voor een 70B" de vuistregel is die iedereen blijft herhalen.

Het complete plaatje voegt nog twee termen toe: totale VRAM ≈ gewichten + KV cache + ~15-20% overhead. De overhead omvat activatiebuffers, de CUDA-context en geheugenfragmentatie, en je GPU reserveert ook nog een halve gigabyte of zo voor de driver, dus reken nooit op 100% van de VRAM die op de doos staat.

Waarom de KV Cache de Adder Onder het Gras Is

De KV cache slaat de attention keys en values op voor elk token dat al in de context staat, en groeit lineair met de contextlengte. Bij korte prompts is het verwaarloosbaar. Ga richting een lange context en de cache kan net zo groot worden als de gewichten zelf, of ze zelfs overtreffen. Dit is verreweg de meest voorkomende reden waarom een model dat "zou moeten passen" halverwege een generatie een OOM-fout gooit.

De formule, per token:

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Neem Llama 3.3 70B: 80 lagen, 8 KV heads, head dimension 128, dus kv_dim is 1024. Bij FP16 is dat 80 × 2 × 1024 × 2 = 327,680 bytes per token, ongeveer 0.31 MB. Vermenigvuldig dat met de contextlengte en het verhaal schrijft zichzelf: bij 8K tokens is de cache ruwweg 2.6 GB, bij 32K ongeveer 10 GB, en bij 128K zwelt het aan tot rond de 41 GB. Dat laatste cijfer komt bovenop de 40 GB aan gewichten, dus een "40 GB-model" wordt zonder waarschuwing een probleem van 80 GB zodra je het venster volledig vult.

Twee praktische uitwegen. Grouped-query attention (dat elk recent model gebruikt) verkleint kv_dim al flink ten opzichte van het oude multi-head-ontwerp, waardoor moderne modellen hier veel vriendelijker zijn dan Llama 2 was. En de meeste inference-engines kunnen de KV cache quantiseren naar 8-bit of 4-bit, wat de omvang halveert of tot een kwart terugbrengt tegen een klein kwaliteitsverlies. Draai je lange contexten in productie, dan laat de vLLM vs SGLang-vergelijking zien welke backend dit geheugen het efficiëntst beheert met paged attention.

MoE-modellen: Waarom "Actieve Parameters" Geen VRAM Besparen

Dit is de valkuil die mensen het meeste geld kost. Een Mixture-of-Experts-model zoals DeepSeek-V3.2 (671B totaal, 37B actief, met dezelfde V3-architectuur) of GLM-5.2 (744B totaal, 40B actief) stuurt elk token door een kleine subset van zijn experts. De marketing leunt op het actieve cijfer omdat dat de snelheid beschrijft: je betaalt per token slechts de rekenkracht van 37B parameters, dus is inference snel voor de omvang van het model. Maar elke expert moet in het geheugen klaarstaan om gekozen te kunnen worden, wat betekent dat je VRAM-budget bepaald wordt door het totale aantal parameters, niet door het actieve aantal.

De eerlijke lezing van de tabel hierboven is dus: GLM-5.2 draait op de snelheid van een 40B-model, maar neemt het geheugen in beslag van een model van 744B. Daarom hebben deze frontier open modellen een server met 8 GPU's nodig, of een grote machine met unified memory, ook al is een enkele forward pass goedkoop. Qwen3-235B-A22B heeft dezelfde vorm op kleinere schaal: snel per token, zwaar om te hosten.

Het voordeel van MoE komt naar boven op unified-memory-hardware. Een Mac Studio met 512 GB unified memory kan een 671B-model bij Q4 vasthouden en toch op bruikbare snelheden draaien, juist omdat maar 37B activeert, waardoor de vraag naar geheugenbandbreedte per token beperkt blijft. Ben je nieuw in het lokaal draaien van deze modellen, begin dan met onze gids voor het lokaal instellen van LLM's voordat je geld uitgeeft aan hardware.

Welke Quantisatie Moet Je Kiezen?

Voor bijna iedereen is Q4_K_M de juiste standaardkeuze: het behoudt bijna volledige kwaliteit terwijl het de FP16-omvang met ongeveer 4x verkleint. Stap alleen over naar Q5_K_M of Q8 als je VRAM over hebt en een kwaliteitsgevoelige taak, en grijp alleen naar FP16 als je aan het fine-tunen bent of benchmarkt tegen een referentie. Onder Q4 wordt het kwaliteitsverlies snel merkbaar, dus Q3 en lager zijn een laatste redmiddel om een model toch op een kaart te persen die eigenlijk te klein is.

Eén kanttekening: de kwaliteitsimpact van quantisatie verschilt per model. Heel kleine modellen (onder 4B) voelen Q4 sterker dan grote modellen, omdat ze minder redundantie te missen hebben. Bij een 70B-model is Q4 versus Q8 bij de meeste taken nauwelijks te onderscheiden. Bij een 1.7B-model is het verschil echt merkbaar.

Welke GPU Heb Je Eigenlijk Nodig?

Koppel de Q4-kolom van de mastertabel aan een kaart met wat speling voor de KV cache. Hieronder de praktische indeling van budget-consumentenhardware tot aan het datacenter, met de modelklasse die elke categorie comfortabel draait bij Q4.

Apple Silicon verdient een aparte vermelding, omdat unified memory de rekensom verandert. Een Mac splitst VRAM niet van systeem-RAM, dus een M-serie-machine met 128 GB kan modellen laden waarvoor je normaal meerdere losse GPU's nodig zou hebben. Daarvoor lever je piekdoorvoer in, in ruil voor de mogelijkheid om enorme gewichten op één desktop kwijt te kunnen. Voor de backends die het meeste uit elk van deze kaarten halen, benchmarkt ons overzicht van de beste tools om LLM's lokaal te draaien de verschillen in snelheid uit de praktijk.

Hoe Wij VRAM Dimensioneren voor Klantprojecten

Bij Techsy zetten we vaak genoeg open modellen in voor klanten dat VRAM-dimensionering het eerste gesprek is, nog vóór modelkeuze, vóór prompts, vóór wat dan ook. Onze aanpak is expres saai, want de faalmodus (een OOM in productie onder echte contextbelasting) is duur. Dit is het proces dat we daadwerkelijk hanteren.

We beginnen bij de rekensom uit de tabel, en meten daarna. Nadat we een model geladen hebben, controleren we de werkelijke geheugenbezetting in plaats van te vertrouwen op de schatting:

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

De les die zich blijft herhalen: teams dimensioneren voor de gewichten en vergeten de KV cache, en vragen zich dan af waarom een model dat prima laadde, drie lange requests in een demo alsnog omvalt. Wij dimensioneren voor de gewichten plus de KV cache bij de maximale context die de app echt gaat gebruiken, plus speling, en we begrenzen --ctx-size zodat een losgeslagen request de machine niet in een OOM kan jagen. Voor alles wat klanten rechtstreeks zien, draaien we liever een gequantiseerde 32B die nooit omvalt dan een FP16 70B die vastloopt onder belasting.

Twijfel je of je een open model zelf moet hosten of bij een gehoste API moet blijven? Die afweging (hardwarekosten en operationele last versus prijs per token en controle) is precies wat ons team in kaart brengt tijdens een AI-integratietraject. Helpt het om iemand de cijfers tegen jouw echte workload te leggen? Vraag een gratis consult aan en we rekenen het samen met je uit.

Veelgestelde Vragen

Hoeveel VRAM heb ik nodig om een 70B-model te draaien?

Een dense 70B-model zoals Llama 3.3 70B heeft ongeveer 40 GB VRAM nodig voor de gewichten bij Q4_K_M, dus reken op een 48 GB-kaart (RTX 6000 Ada) of twee 24 GB-kaarten. Tel er nog een paar gigabyte bij op voor de KV cache als je een lange context gebruikt, waardoor de praktische vereiste richting 48 GB of meer schuift.

Hoeveel VRAM hebben Llama, Qwen of DeepSeek nodig?

Dat hangt volledig af van de variant. Llama 4 Scout heeft ongeveer 62 GB nodig bij Q4, Qwen3-32B ongeveer 18 GB, en Qwen3-8B onder de 5 GB. DeepSeek-V3.2, een 671B MoE, heeft ruwweg 382 GB nodig omdat elke expert geladen moet worden. Kijk bij MoE-modellen altijd naar het totale aantal parameters, niet naar het actieve aantal.

Kan ik een LLM draaien op een GPU met 8GB?

Ja, met gemak. Een 8 GB-kaart zoals een RTX 4060 draait modellen tot ongeveer 12B parameters bij Q4_K_M. Gemma 4 12B past in ruwweg 6.8 GB, met ruimte over voor een bescheiden context. Voor alles wat groter is, quantiseer je harder, houd je de context kort, of stap je over op een grotere kaart.

Wat kan een GPU met 24GB, zoals de RTX 4090, draaien?

Een 24 GB-kaart draait dense modellen tot ongeveer 32B bij Q4_K_M, met speling voor een redelijke context, dus Qwen3-32B en Mistral Small 3.2 24B zijn geen probleem. Hij draait ook de Qwen3-30B-A3B MoE, die 30B aan gewichten laadt maar dankzij sparse activatie genereert op de snelheid van een 3B-model.

Gaat quantisatie ten koste van de modelkwaliteit?

Bij Q4_K_M en hoger is het kwaliteitsverlies klein en vaak niet merkbaar bij echte taken, vooral bij modellen boven 13B. Het verschil wordt groter naarmate je lager gaat en naarmate modellen kleiner worden, dus Q4 op een 70B is bijna gratis, terwijl Q4 op een 1.7B wel merkbaar is. Q8 is praktisch verliesvrij als je het geheugen ervoor hebt.

Hebben MoE-modellen minder VRAM nodig dan dense modellen?

Nee, en dit is het meest voorkomende misverstand. Een Mixture-of-Experts-model moet elke expert in VRAM vasthouden, dus het geheugengebruik wordt bepaald door het totale aantal parameters. Het actieve-parametercijfer beschrijft alleen de inference-snelheid. GLM-5.2 draait op de snelheid van een 40B-model, maar heeft het geheugen van een model van 744B nodig.

Is unified memory hetzelfde als VRAM?

Functioneel gezien, voor het laden van modellen, wel ja. Apple Silicon en sommige andere systemen delen één geheugenpool tussen CPU en GPU, dus een Mac met 128 GB kan modellen laden waar je anders meerdere losse GPU's voor nodig zou hebben. Het offer is bandbreedte: unified memory levert doorgaans een lagere piekdoorvoer dan een high-end datacenter-GPU, dus het aantal tokens per seconde ligt lager.

Kan ik een deel van een model offloaden naar systeem-RAM of CPU?

Ja. Engines zoals llama.cpp en Ollama laten je een deel van de lagen op de GPU houden en de rest in systeem-RAM, met een flag zoals --n-gpu-layers. Zo kun je een model draaien dat eigenlijk te groot is voor je VRAM, maar elke laag op de CPU vertraagt de generatie flink, dus gebruik het om een model mogelijk te maken, niet om het snel te maken.

Hoe bereken ik de VRAM voor een model dat niet in de tabel staat?

Vermenigvuldig het aantal parameters in miljarden met de bits-per-weight voor jouw quantisatie, en deel dat door 8. Gebruik voor Q4_K_M ongeveer 4.5 bits, dus een 40B-model heeft 40 × 4.5 ÷ 8 = ongeveer 22.5 GB nodig voor de gewichten. Tel daar ruwweg 15-20% overhead plus je KV cache bij op voor de echte vereiste.