Wanneer een klant vraagt "welke GPU voor een lokaal LLM", bedoelt hij doorgaans één vraag: past het model dat ik wil gebruiken erin? Het antwoord hangt af van drie getallen — de grootte van de modelgewichten, de KV-cache bij de gegeven contextlengte en de overhead van het serving framework. Alle drie zijn van tevoren te berekenen. Toch verlopen de meeste hardwarebeslissingen op gevoel, met als resultaat ofwel een onnodig dure server, ofwel een server die tekortschiet.
Dit artikel geeft concrete cijfers: hoeveel VRAM een 7B-, 13B-, 34B- en 70B-model werkelijk inneemt bij verschillende kwantisatieformaten, wat er past op een 24 GB / 48 GB / 80 GB kaart, en wanneer multi-GPU zinvol is.
Basisformule: modelgewichten
De eenvoudigste schatting van VRAM voor de gewichten alleen:
VRAM (GB) ≈ (aantal parameters in miljarden × aantal bits) / 8Voorbeelden: - 7B model, FP16 (16 bits): 7 × 16 / 8 = 14 GB (in de praktijk met overhead ~16–18 GB) - 7B model, Q4_K_M (4 bits): 7 × 4 / 8 = 3,5 GB — in de praktijk door overhead circa 5–7 GB - 70B model, FP16: 70 × 16 / 8 = 140 GB - 70B model, Q4_K_M: 70 × 4 / 8 = 35 GB — in de praktijk circa 38–40 GB
De formule voor gewichten is slechts een vertrekpunt. Daarboven komen altijd de KV-cache, de overhead van het serving framework en bij kwantisatie ook dequantisatiebuffers.
Wat is de KV-cache en waarom is deze belangrijk
Tijdens inferentie genereert het model tokens één voor één. Om niet voor elk nieuw token de hele sequentie opnieuw te berekenen, slaat het tussenresultaten op — de zogenaamde key-value-paren voor elke attention layer. Deze tussenresultaten vormen de KV-cache.
De KV-cache groeit lineair met de sequentielengte. Voor een productie-deployment met gelijktijdige verzoeken wordt hij al snel even groot als de gewichten zelf.
Indicatieve KV-cache-groottes voor gangbare modellen:
- 7B model, 8K context, 1 parallel verzoek: ~1–2 GB
- 7B model, 32K context, 4 parallelle verzoeken: ~8–16 GB
- 70B model, 32K context, 1 verzoek: ~8–12 GB
- 70B model, 128K context, 1 verzoek: ~40 GB
De exacte cijfers hangen af van het aantal attention layers, heads en groepen (moderne modellen gebruiken Grouped Query Attention, GQA, wat de KV-cache drastisch verkleint ten opzichte van oudere multi-head attention). Elk model heeft een andere vermenigvuldiger — controleer het configuratiebestand van het model (config.json in de HuggingFace-repository) vóór de hardwarekeuze.
Praktische consequentie: als u van plan bent lange contexten of een groter aantal gelijktijdige gebruikers te ondersteunen, is de KV-cache even bepalend als de gewichten. Het is geen technisch detail — het is de voornaamste oorzaak van OOM-fouten bij deployment.
Wat past op 24 GB (RTX 4090, L4)
24 GB is de meest gangbare categorie voor on-prem ontwikkel- en kleinere productie-deployments.
Wat er comfortabel in past: - 7B FP16 — gewichten ~16–18 GB, de rest voor KV-cache (~6 GB) volstaat voor middelgrote contexten (8–16K) bij weinig gelijktijdige verzoeken - 7B Q8_0 — gewichten ~8–9 GB, voldoende KV-cacheruimte ook bij 32K context - 13B Q4_K_M — gewichten ~8 GB, ruim voldoende KV-cache bij 8K - 13B Q8_0 — gewichten ~14 GB, krap, maar past bij kortere contexten
Wat er niet in past: - 13B FP16 — gewichten ~26 GB, overschrijdt de capaciteit - 34B in welk gangbaar formaat dan ook — zelfs bij Q4 passen gewichten (~17–20 GB) + KV-cache niet op 24 GB bij een reële workload
Voor een 24 GB-kaart is Q4_K_M in de praktijk de standaard bij 13B-modellen; voor 7B heeft u de vrijheid om Q8 of FP16 te kiezen afhankelijk van hoeveel context u nodig heeft.
Wat past op 48 GB (RTX 6000 Ada, A40, L40S)
48 GB biedt zinvolle ruimte voor grotere modellen.
Wat goed werkt: - 13B FP16 — past comfortabel, voldoende KV-cache bij 16–32K context - 34B Q4_K_M — gewichten ~17–20 GB, ruim voldoende voor productie-KV-cache - 34B Q8_0 — gewichten ~30–34 GB, krap, maar functioneel bij kortere contexten - 70B Q4_K_M — gewichten ~38–40 GB, resterende KV-cache (~6–10 GB) beperkt tot korte contexten (4–8K) of 1 parallel verzoek
Wat niet ideaal is: - 70B FP16 — 140 GB, driemaal de capaciteit - 70B Q8_0 — ~70–75 GB, overschrijdt nog steeds de capaciteit
Een 48 GB-kaart kan een 70B-model in Q4_K_M aan, maar met beperkte context. Voor de meeste B2B-use-cases — RAG over documenten, classificatie, gestructureerde extractie — volstaat een kortere context (tot 8K).
Wat past op 80 GB (A100, H100, H200)
80 GB is de categorie waar de meeste productie-deployments van 70B-modellen zonder compromissen draaien.
- 70B FP16 — gewichten ~140 GB, past hier ook niet. U heeft minimaal twee kaarten nodig.
- 70B Q8_0 — gewichten ~70–75 GB, past erin, er blijft ~5–10 GB over voor KV-cache — beperkt tot zeer korte contexten of 1 verzoek
- 70B Q4_K_M — gewichten ~38–40 GB, resterende ~38–40 GB voor KV-cache — comfortabel voor 32K context, 2–4 gelijktijdige verzoeken
- 34B FP16 — gewichten ~54–68 GB, past met behoorlijke KV-cacheruimte
Op een H100 80GB met 70B Q4_K_M via vLLM of SGLang krijgt u productie-serving met een throughput die geschikt is voor tientallen gelijktijdige gebruikers.
Kwantisatie: waar besparen zonder kwaliteitsverlies
Kwantisatie verlaagt de numerieke precisie van gewichten (van FP16/BF16 naar INT8, INT4 enz.) in ruil voor een kleinere VRAM-footprint en snellere inferentie. De vraag is niet "of kwantiseren" — maar waar kwaliteit verloren gaat en waar niet.
Indicatief kwaliteitsbehoud ten opzichte van FP16:
- Q8_0 (GGUF): ~98–99 % — nauwelijks waarneembaar. Standaardkeuze wanneer u voldoende VRAM heeft.
- Q4_K_M (GGUF): ~92–95 % — sweet spot. De meeste B2B-use-cases (RAG, classificatie, extractie, documentlezen) merken geen verschil.
- AWQ 4-bit: ~93–96 % — iets beter voor tekstcoherentie en code. Vereist NVIDIA GPU, integreert goed met
vLLM. - GPTQ 4-bit: ~90–93 % — maximale throughput op de NVIDIA-stack, iets lagere kwaliteit dan AWQ.
- Q2 (GGUF): duidelijke degradatie — merkbaar bij complexe redeneerketens, lange generaties en meertalige teksten.
Het verschil in perplexiteit tussen Q4 en BF16 blijft over benchmarks heen onder de 6 %. Voor de meeste industriële use-cases is dat verwaarloosbaar. Kwaliteitsverlies treedt op wanneer het model nauwkeurige meerstapsredenering nodig heeft of lange samenhangende teksten genereert — daar verliest Q4 soms de draad ten opzichte van Q8.
Meer over kwantisatieformaten, hun onderlinge verschillen en toepassingsgevallen leest u in het overzicht van kwantisatie: GGUF, AWQ, GPTQ.
Multi-GPU: wanneer en hoe
Wanneer een model niet op één kaart past, heeft u twee opties: kwantiseren of een GPU toevoegen. Soms heeft u beide nodig.
Tensor parallelism — het model wordt verdeeld over meerdere GPU's per laag (of per attention head). vLLM en SGLang ondersteunen dit native. Met twee A100 80GB krijgt u effectief 160 GB VRAM en kunt u 70B FP16 bedienen.
Pipeline parallelism — verschillende blokken van het model draaien sequentieel op verschillende GPU's. Minder efficiënt dan tensor parallelism (leeglooptijd bij de overgang tussen kaarten), maar werkt ook op kaarten zonder NVLink.
Praktische aanbevelingen: - 2× RTX 4090 (2× 24 GB = 48 GB): 34B Q4_K_M comfortabel, 70B Q4_K_M krap — past erin, maar KV-cache is beperkt - 2× A100 80 GB (2× 80 GB = 160 GB): 70B FP16 zonder compromissen, 70B Q8_0 met ruime KV-cache - NVLink tussen kaarten verlaagt de communicatie-overhead bij tensor parallelism significant — voor productie-deployments de voorkeur geven aan kaarten met NVLink-ondersteuning (A100, H100, RTX 6000 Ada)
De meeste consumer-GPU's (RTX 4090) hebben geen NVLink — ze communiceren via PCIe, wat de latentie bij multi-GPU-verdeling verhoogt. Voor ontwikkeldoeleinden is dit voldoende; voor productie met lage latentievereisten loont de investering in workstation-class GPU's.
Overhead van het serving framework
Boven op gewichten en KV-cache komt de overhead van de serving oplossing zelf. vLLM gebruikt PagedAttention — het beheert de KV-cache in pagina's zoals een OS geheugen beheert, wat fragmentatie terugbrengt van de typische 60–80 % verspilling naar minder dan 4 %. Reserveer desondanks extra ruimte:
- `vLLM`-overhead: doorgaans 1–3 GB extra voor activatiebuffers, prefetch en scheduling
- `SGLang`-overhead: vergelijkbaar met vLLM, plus de RadixAttention-boom voor prefixcaching
Vuistregel: reken op ~10–15 % reservemarge boven de geschatte gewichten + KV-cache. Voor een 24 GB-kaart betekent dit mikken op ~20–22 GB effectief gebruik, niet op 24 GB.
In tegenstelling tot productie-frameworks gebruikt Ollama onder de motorkap llama.cpp — uitstekend voor een ontwikkelaarsdesktop en single-user experimenten, maar niet ontworpen voor gelijktijdige verzoeken. Bij 8 parallelle gebruikers is vLLM significant sneller (circa 2–3×). Meer over de verschillen tussen serving-oplossingen leest u in de vergelijking vLLM vs SGLang vs Ollama.
Praktische referentie: wat voor welk scenario
Samenvatting voor gangbare scenario's:
Ontwikkelaarsworkstation, single user: - 7B–13B modellen, korte context → 1× RTX 4090 (24 GB) met Q4_K_M of Q8_0 - 34B model → 2× RTX 4090 of 1× RTX 6000 Ada (48 GB) met Q4_K_M
Productieserver, 5–20 gelijktijdige gebruikers: - 7B FP16 of Q8_0 → 1× A40 of L40S (48 GB) - 13B–34B Q4_K_M → 1× A40 of L40S - 70B Q4_K_M met korte context → 1× A100 80 GB of H100 80 GB - 70B Q4_K_M met lange context, hogere throughput → 2× A100 of 2× H100
On-prem enterprise, gereguleerde sector: - Kwaliteit zonder compromissen → 70B Q8_0 of FP16 → 2× H100 80 GB (NVLink) - Als on-prem vanuit GDPR- en kostenperspectief zinvol is voor uw use-case, bekijk dan ook On-prem LLM voor gereguleerde sectoren
Voor elk van deze beslissingen geldt: rekencapaciteit is slechts één kant van de vergelijking. Even belangrijk is wat u van het model verwacht — en wat het model zou kunnen als het correct was gefinetuned op uw data. Over wanneer u een grotere GPU installeert versus wanneer u beter een kleiner model finetunet, leest u in het artikel klein finetuned vs groot basismodel.
Veelgestelde vragen
Past een 70B-model op één RTX 4090?
Niet zinvol. De RTX 4090 heeft 24 GB VRAM. De gewichten van een 70B-model in Q4_K_M nemen circa 38–40 GB in beslag — bijna het dubbele van de capaciteit. Voor inferentie van een 70B-model heeft u ofwel twee kaarten nodig (2× 24 GB via PCIe tensor parallelism), ofwel één 48 GB-kaart, waar het alleen past bij beperkte context.
Wat is het verschil tussen GPU-VRAM en systeem-RAM bij inferentie?
Het model moet in de VRAM van de GPU worden geladen — systeem-RAM kan dit bij GPU-inferentie niet vervangen. CPU-inferentie (via llama.cpp zonder GPU) werkt vanuit systeem-RAM, maar is ordes van grootte langzamer. Sommige oplossingen (bijv. llama.cpp met gedeeltelijke offloading) laden een deel van de lagen in VRAM en laten de rest in RAM — praktisch bruikbaar voor ontwikkelexperimenten, niet voor productie.
Hoeveel VRAM voegt een lange context toe?
Dat hangt af van het model. Indicatief: bij een 7B-model voegt elke 8K tokens context ~1–2 GB KV-cache toe. Bij een 70B-model is dat ~5–10 GB per 8K tokens. Moderne modellen met Grouped Query Attention (GQA) zijn aanzienlijk zuiniger dan oudere. Controleer vóór de hardwareaankoop de parameter num_key_value_heads in het configuratiebestand van het doelmodel.
Is Q4_K_M-kwantisatie voldoende voor bedrijfsdocumenten en RAG?
In de meeste gevallen wel. Voor RAG over bedrijfsdocumentatie (informatie-extractie, categorisering, samenvatting) is het verschil tussen Q4_K_M en FP16 in de praktijk nauwelijks meetbaar. Degradatie treedt op bij complexe meerstapsredenering of bij het genereren van lange samenhangende teksten. Bij twijfel: test de concrete use-case met Q4_K_M en vergelijk met Q8_0 — het resultaat valt doorgaans mee.
Wanneer kiezen voor multi-GPU in plaats van één grotere kaart?
Eén grotere kaart is doorgaans de betere keuze als die beschikbaar is (lagere communicatie-overhead, eenvoudiger beheer). Multi-GPU is zinvol wanneer: (1) het model fysiek niet op één kaart past, zelfs niet bij agressieve kwantisatie, (2) u redundantie nodig heeft voor hoge beschikbaarheid, of (3) u een groot aantal gelijktijdige verzoeken wilt bedienen en throughput de primaire maatstaf is.
*De keuze van de juiste GPU voor lokale inferentie lijkt op het eerste gezicht een technische vraag — in werkelijkheid is het een architectuurbeslissing die kosten, contextvenster, het aantal gelijktijdige gebruikers en de beschikbaarheid van het systeem bepaalt. Bij MP Industrial Solutions begeleiden we bedrijven van de gewenste use-case via de modelkeuze tot een concreet hardwareadvies — inclusief TCO-berekening ten opzichte van cloud-API. Als u zich voorbereidt op een eerste on-prem deployment of uw bestaande server heroverweeget, kijken we graag samen naar uw cijfers.*