Loop een willekeurige local-LLM-thread binnen en er wordt over GPU’s gestreden. VRAM-benchmarks, kaarten van 24 GB, CUDA versus ROCm, of de 3060 nog steeds de volkskaart is. Ondertussen zit het getal dat echt bepaalt of je model draait in het andere gleufje, onbenchmarkbaar en ongemarkt: hoeveel RAM de machine heeft.
VRAM verkoopt de droom. RAM beslist of het model überhaupt bootet — en hoeveel context overleeft als het zover is.
Ik heb het getest op de doos voor me, terwijl ik dit schreef: een Ryzen-desktop met 32 GB RAM en een GeForce RTX 3060 met 12 GB VRAM. llama3.1:8b binnengehaald — de downloadpagina zegt 4.9 GB. Kijk wat hij echt reserveerde:
Dat is het hele argument op één scherm. Een ‘model van 4.9 GB’ reserveerde 7.0 GB voordat hij één prompt beantwoordde — een contextbelasting van 43% — en hield 7.963 van 12.288 MiB VRAM voor zichzelf. De weights waren nooit het budget. De context was het.
Waar die extra gigabytes vandaan komen
De geheugennotities van llama.cpp leggen de rekenkunde uit die downloadpagina’s weglaten: totaal geheugen = modelgewichten + KV-cache + compute-buffer. Alleen de eerste term is constant. De KV-cache groeit lineair met de contextlengte en de compute-buffer met de batch- en grafiekvorm. Ollama wikkelt llama.cpp in, dus dezelfde wet geldt — daarom meldde ollama ps 7.0 GB voor een 4.9-GB-tag bij een venster van 32.000 tokens, alles resident op de GPU.
Een gekwantiseerd model is geen compromis. Het is de erkenning dat geheugen altijd al het echte budget was.
Daarom bestaat de GGUF-kwantisatieladder überhaupt. Q4 is geen religie; het is wat de geheugenrekenkunde binnen hardware laat landen die mensen daadwerkelijk bezitten. En daarom gedragen twee ‘identieke’ 8B-setups zich totaal niet hetzelfde: zelfde model, andere contextlengte, hele andere machines.
De tabel die niemand invult vóór het kopen
Drie modelklassen, beide geheugentypes, één kaart van 12 GB en 32 GB RAM — de configuratie die duizenden developers echt hebben:
| Modelklasse (Q4) | Download | Geladen + 32k ctx | Op 12 GB VRAM | Op 32 GB RAM |
|---|---|---|---|---|
7–8B (llama3.1:8b) | 4.9 GB | 7.0 GB (gemeten) | 100% GPU, ~8 GiB gebruikt | nauwelijks gemerkt |
13–14B (qwen2.5:14b) | 9.0 GB | ~12 GB | offload begint | prima |
27–32B (gemma3:27b) | 17 GB | ~20+ GB | CPU trekt de weight | de enige reden dat het draait |
Lees de laatste twee rijen nog eens. Op VRAM alleen is een 14B-model op een echte context al een split-offload-klus en is een 27B onmogelijk. Op 32 GB systeem-RAM zijn allebei slechts traag. Dat verschil — tussen onmogelijk en traag — is het hele praktische verschil tussen RAM en VRAM. Past het in de VRAM, is het snel. Past het in de RAM, werkt het. Past het in geen van beide, dan swap je naar een NVMe-schijf en verliest tijd zijn betekenis.
Offload zit op PCIe en de Ollama-FAQ is streng eerlijk over de prijs: lagen die niet op de GPU passen draaien op de CPU en de doorvoer zakt hard naarmate het GPU-aandeel krimpt. Niemand kiest die trade-off bewust. Hij gebeurt stilletjes, laag voor laag, en het symptoom is gewoon ‘lokale modellen vallen tegen’.
De eerlijke balans
Wat er brak of verbaasde tijdens het schrijven, op volgorde:
- Het getal 43% zelf. Ik verwachtte dat het 8B-model ‘ongeveer zijn bestandsgrootte’ zou innemen. Het reserveerde 7.0 GB tegen een download van 4.9 GB. Als mij dat verbaasde, verbaast het iedereen die datasheets leest in plaats van
ps-output. - De screenshotsessie. Mijn eerste opname greep het verkeerde venster. De tweede lukte, dat is degene hierboven. Receipts zijn een workflow, geen vibe — en een pull → capture →
ollama rm-cyclus houdt de schijf eerlijk. - Wat niet brak: de GPU liep nooit over. 8B op 32k context op 12 GB is echt comfortabel. De kaart is in orde. Het discours rond de kaart is verkeerd gecalibreerd.
Niets hiervan zegt dat GPU’s er niet toe doen — de 100%-GPU-regel in die opname is waarom genereren instant voelde. Het zegt: de GPU is de tweede vraag. De keuze tussen Ollama en llama.cpp komt nadat je weet wat erin past, niet ervoor.
De vuistregel die de moeite waard is
RAM die je nodig hebt = modelfile + KV-cache voor je echte contextvenster + 4 GB om een computer te zijn. Voor 7–8B op Q4 is 16 GB comfortabel. Voor 14B–32B houdt 32 GB op luxe te zijn en wordt het het punt. Koop VRAM voor de snelheid die je wilt bij de context die je gebruikt; koop RAM voor alles wat je ooit zult laden.
Kijk één keer naar
ollama psen de datasheetreligie eindigt geruisloos.
Dus, twee vragen. Als je je volgende dev-doos samenstelt, koop je VRAM voor de benchmarks die je postt — of RAM voor de modellen die je echt draait? En eerlijk: hoeveel van de modellen die je om 2 uur ‘s nachts binnentrok, heb je vóór het ontbijt verwijderd? Ik vanavond, midden in dit bericht. Zeg me in de reacties dat ik niet de enige ben — en aan welke kant van de RAM/VRAM-lijn jouw build staat.
FAQ
Hoeveel RAM heb je nodig om een local LLM te draaien?
Modelbestandsgrootte plus context plus je desktop. 16 GB is comfortabel voor 7–8B-modellen op Q4; 32 GB maakt 14–32B-modellen een daily driver in plaats van een demo.
Wat is belangrijker voor lokale LLMs: VRAM of RAM?
VRAM beslist over snelheid als alles erin past. RAM beslist of het model überhaupt draait en hoeveel context overleeft. PCIe-offload ertussen is de trage middenmoot die niemand fijn vindt.
Waarom gebruikt een model na het laden meer geheugen dan zijn downloadgrootte?
De KV-cache en compute-buffers groeien met de contextlengte. llama.cpp documenteert de rekensom: weights + KV-cache + compute-buffer, en alleen het eerste getal staat op de downloadpagina.
— mrsaynothing
— mrsaynothing
Meningen getest onder belasting vóór release. Meestal.
Bespreek deze post op dev.to dev.to ↗
Het volgende argument per e-mail
Eén e-mail per post. Eens, of sloopt het.
wat is dit?SSH Permission denied (publickey): de echte fix
Schrijf je dit met plezier? Dit bouw ik professioneel. huur me in