Parameters omrekenen naar VRAM: hoeveel geheugen heb je nodig

Het selecteren van hardware voor open source taalmodellen begint vrijwel altijd met dezelfde vraag: past het gekozen model binnen het beschikbare videogeheugen (VRAM)? Wie uitsluitend kijkt naar het aantal miljarden parameters (de parametercount) en dit vermenigvuldigt met het aantal bytes per getal, komt in de praktijk vaak bedrogen uit. Een 70B-model past op papier wellicht in 35 gigabyte bij 4-bit precisie, maar crasht direct met een Out-Of-Memory (OOM) foutmelding zodra een gebruiker een lang document meestuurt.

De totale geheugendruk van een LLM tijdens inferentie bestaat namelijk uit vier afzonderlijke componenten: de statische modelgewichten, de dynamische Key-Value cache (KV-cache), de tussenliggende activatievectoren en de runtime framework-overhead. Om te begrijpen waarom lange invoerteksten een exponentieel beslag leggen op het geheugen, is het raadzaam om de werking van een context window te bestuderen, waar de relatie tussen aandachtsmechanismen en tokenverwerking nader wordt uitgediept. In dit artikel wordt de volledige wiskundige rekenmethode ontleed waarmee het benodigde VRAM tot op de megabyte nauwkeurig kan worden voorspeld.

De basisformule voor modelgewichten

De meest prominente verbruiker van videogeheugen is de verzameling getrainde gewichten (weights) van het neurale netwerk. Elk gewicht in het netwerk is opgeslagen in een specifiek numeriek formaat. De hoeveelheid geheugen die nodig is om puur de statische gewichten in te laden, laat zich berekenen met een eenvoudige lineaire vergelijking:

Geheugen_gewichten (in GB) = (Aantal_parameters in miljarden * Bits_per_gewicht) / 8

In ongecomprimeerde toestand worden moderne modellen meestal getraind in 16-bit floating point (FP16 of BF16). Omdat 16 bits gelijkstaan aan 2 bytes, heeft een model van 8 miljard parameters (8B) in FP16 exact 16 gigabyte aan opslagruimte nodig om alleen al in het geheugen te staan. Wordt hetzelfde model geladen in 8-bit precisie (1 byte per parameter), dan halveert deze omvang naar 8 GB. Bij een populaire 4-bit quantisatie (0,5 byte per parameter) daalt het gewicht naar 4 GB.

In werkelijkheid ligt dit getal altijd circa vijf tot tien procent hoger door de aanwezigheid van niet-gekwantiseerde layers (zoals de input embeddings en de uiteindelijke output normalization heads), quantisatieschalen en metadata. Een modelbestand van 8B parameters in 4-bit formaat beslaat op schijf en in het geheugen daardoor circa 4,5 tot 4,9 GB in plaats van de theoretische 4,0 GB.

Kwantisatie in de praktijk: GGUF, AWQ, GPTQ en EXL2

Omdat grafische kaarten voor consumenten en mkb-werkstations vaak over 8, 16 of 24 GB VRAM beschikken, is kwantisatie de standaardprocedure geworden om middelgrote en grote modellen lokaal te draaien. Verschillende kwantisatiemethoden hanteren elk hun eigen balans tussen compressieratio, inferentiesnelheid en behoud van logisch redeneervermogen.

Voor cpu- en hybride inferentie via tools als llama.cpp is het GGUF-formaat dominant. Hierbij worden zogeheten 'k-quants' ingezet (zoals Q4_K_M of Q5_K_S), waarbij kritieke aandachtsmatrices op een hogere precisie (bijvoorbeeld 5 of 6 bits) worden bewaard terwijl minder gevoelige feed-forward lagen naar 4 bits worden teruggebracht. Wie overweegt om compacte modellen direct op lokale apparatuur of werkplekken in te zetten, kan in de gids over on-device implementatie van kleine modellen lezen hoe deze k-quants presteren op consumentenhardware.

Op dedicated Nvidia-gpu's bieden methoden zoals AWQ (Activation-aware Weight Quantization) en EXL2 (ExLlamaV2) aanzienlijk hogere verwerkingssnelheden per seconde. AWQ beschermt de één procent belangrijkste gewichten tegen precisieverlies, waardoor 4-bit inferentie vrijwel identieke benchmarkscores haalt als het originele 16-bit basismodel. EXL2 maakt zelfs fractionele bits mogelijk (zoals 3,5 of 4,25 bits per gewicht), waardoor een model exact op maat gemaakt kan worden voor een specifieke VRAM-capaciteit van bijvoorbeeld 24 GB.

De vergeten factor: de KV-cache berekenen

Zodra de modelgewichten in het geheugen zijn geladen, is het model nog niet klaar om vragen te beantwoorden. Tijdens het genereren van tekst berekent het aandachtsmechanisme (Self-Attention) voor elk token in de invoer en uitvoer een Key- en Value-vector. Om te voorkomen dat het complete document bij elk nieuw gegenereerd woord opnieuw van begin tot eind doorgerekend moet worden, worden deze vectoren opgeslagen in de Key-Value cache (KV-cache).

De KV-cache groeit strikt lineair met de contextlengte en het aantal gelijktijdige gebruikers (batch size). De exacte formule voor het KV-cachegeheugen van een traditioneel Multi-Head Attention (MHA) model luidt:

KV_cache_grootte (bytes) = 2 * Lagen * Heads * Dimensie_per_head * Contextlengte * Batch_size * Bytes_per_element

Hierin staat de factor 2 voor de twee afzonderlijke vectoren (Key en Value). Moderne architecturen gebruiken vrijwel allemaal Grouped-Query Attention (GQA) of Multi-Query Attention (MQA). Bij GQA delen meerdere query-heads dezelfde KV-head, waardoor het geheugenbeslag van de cache met een factor 4 tot 8 afneemt. Laten we als concreet rekenvoorbeeld een model nemen met 32 lagen, 8 KV-heads (dankzij GQA), een head-dimensie van 128, draaiend op FP16 (2 bytes) met een context van 32.768 tokens bij batch size 1:

KV-cache = 2 * 32 * 8 * 128 * 32768 * 1 * 2 bytes
         = 4.294.967.296 bytes = 4,00 GB

Uit deze berekening blijkt direct het gevaar: wie een 8B-model in 4-bit laadt (4,5 GB gewichten) en een contextvenster van 32k tokens openzet, heeft alleen voor de KV-cache al 4,0 GB extra nodig. Wordt de context opgerekt naar 128k tokens, dan explodeert de KV-cache naar 16 GB, waarmee het dynamische geheugen het statische modelgewicht ruimschoots overtreft.

Activaties, context-overhead en runtime reserves

Naast de gewichten en de KV-cache claimt de inferentie-engine geheugen voor activaties: de tijdelijke tensoren die ontstaan tijdens de matrixvermenigvuldigingen in elke transformer-laag. Bij pure autoregressieve inferentie met batch size 1 is dit verbruik relatief bescheiden (tussen de 200 en 800 MB), maar bij prefilling (het in één keer verwerken van een gigantische prompt van 50.000 tokens) kan het activatiegeheugen plotseling pieken met meerdere gigabytes.

Daarnaast claimt de softwarestack zelf een niet te verwaarlozen hoeveelheid VRAM: - CUDA context: De runtime-omgeving van Nvidia reserveert standaard tussen 300 MB en 800 MB VRAM zodra PyTorch of vLLM initialiseert. - Geheugenfragmentatie: Paginering en dynamische allocaties veroorzaken lege gaten in het geheugen. Zonder geoptimaliseerde geheugenbeheerders (zoals PagedAttention in vLLM) gaat hierdoor 10 tot 20 procent aan effectieve capaciteit verloren. - Compute buffers: Kernels voor specifieke bewerkingen (zoals FlashAttention-3) alloceren scratchpads voor matrixberekeningen.

Als vuistregel geldt dat er altijd een veiligheidsmarge (headroom) van minimaal 1,5 tot 2,0 GB moet worden opgeteld bij de som van de gewichten en de KV-cache om onverwachte OOM-crashes tijdens piekbelasting te voorkomen.

Praktijkscenario's uitgerekend: van 8B tot 70B

Om de theorie om te zetten naar tastbare hardwarekeuzes, doorlopen we drie veelvoorkomende architecturale scenario's.

Scenario A: 8B model op een enkele 16 GB GPU (Nvidia RTX 4080 / T4)

Een ontwikkelaar wil een Llama-3-8B model draaien voor documentanalyse. In 4-bit AWQ nemen de gewichten 4,8 GB in beslag. Met een gewenste contextlengte van 16.000 tokens vergt de GQA KV-cache 2,0 GB. De CUDA-overhead en frameworkreserves bedragen 1,5 GB. De totale geheugenvraag is 4,8 + 2,0 + 1,5 = 8,3 GB VRAM. Dit past comfortabel op een 16 GB videokaart. Er is zelfs voldoende ruimte om de batch size te verhogen naar 4 gelijktijdige verzoeken (KV-cache stijgt dan naar 8,0 GB, totaal verbruik 14,3 GB).

Scenario B: 32B model op een enkele 24 GB GPU (Nvidia RTX 3090 / 4090)

Een Qwen-2.5-32B model in 4-bit precisie vereist circa 19,2 GB voor de gewichten. Tel hier 1,5 GB basisoverhead bij op en er resteert nog slechts 3,3 GB vrije ruimte voor de KV-cache. Bij een volledige 32k context vraagt de KV-cache echter 8,0 GB. Uitkomst: het model zal bij een context groter dan circa 8.000 tokens onherroepelijk crashen. De oplossing is hier om ofwel over te stappen op een sterkere 3-bit EXL2 quantisatie (waardoor de gewichten dalen naar ~15 GB), ofwel FP8 KV-cache kwantisatie in te schakelen om het cachegeheugen te halveren.

Scenario C: 70B model op 2x 24 GB GPU's (48 GB totaal)

Een Llama-3-70B model in 4-bit quantisatie vraagt 39,5 GB aan gewichten. Verdeeld over twee kaarten via Tensor Parallelism staat er circa 20 GB per kaart aan gewichten. Met een gecombineerde 48 GB blijft er circa 5,5 GB over voor de totale KV-cache en activaties. Dit is toereikend voor een context tot circa 12.000 tokens bij batch size 1. Voor intensief productiewerk met 32k of 64k context zijn minimaal twee 32 GB of 48 GB kaarten (zoals de Nvidia A6000 of L40S) noodzakelijk.

Multi-GPU setups: Tensor Parallelism versus Pipeline Parallelism

Wanneer een model niet op één grafische kaart past, moet de belasting worden verdeeld over meerdere processoren. De twee voornaamste strategieën hiervoor hebben een directe invloed op de geheugenverdeling:

Bij Tensor Parallelism (TP) worden individuele gewichtsmatrices horizontaal of verticaal opgeknipt over meerdere GPU's. Elke GPU voert tegelijkertijd een deel van de berekening uit. Hierdoor wordt niet alleen het modelgewicht perfect gelijkmatig verdeeld, maar splitst ook het aantal aandachtsheads zich, waardoor de KV-cache per GPU kleiner wordt. Het nadeel is dat TP extreem snelle communicatie tussen de kaarten vereist (bij voorkeur NVLink); over reguliere PCIe-bussen kan de synchronisatie-overhead de verwerkingssnelheid aanzienlijk vertragen.

Bij Pipeline Parallelism (PP) worden opeenvolgende transformer-lagen toegewezen aan opeenvolgende kaarten (bijvoorbeeld laag 1-40 op GPU 0 en laag 41-80 op GPU 1). Hoewel dit minder bandbreedte tussen de kaarten vereist, introduceert het zogeheten pipeline bubbles (wachttijden) en moet elke GPU voldoende reservegeheugen aanhouden voor de doorgifte van activaties.

Lokale hardware of uitwijken naar gehoste infrastructuren

De wiskunde achter VRAM maakt duidelijk dat de hardware-eisen exponentieel stijgen zodra modellen groter worden dan 32 miljard parameters of wanneer lange contexten van 100k+ tokens standaard vereist zijn. Voor veel organisaties vormt de aanschaf en het onderhoud van gespecialiseerde GPU-clusters een aanzienlijke kostenpost. Wie de totale kosten van on-premise hardware wil afwegen tegen schaalbare cloudoplossingen, kan het diepgaande kostenoverzicht in het artikel over totale eigendomskosten (TCO) van open versus closed modellen raadplegen voor concrete infrastructurele vergelijkingen.

Wanneer strikte vertrouwelijkheid, compliance en gegevenssoevereiniteit leidend zijn, blijft lokaal draaien vaak de enige toegestane route. In het overzicht van AI-modellen en privacy onder de AVG wordt uitvoerig uitgelegd onder welke juridische voorwaarden lokale verwerking noodzakelijk is om datalekken naar externe clouddiensten te voorkomen.

Staat flexibiliteit voorop en schommelen de werkvolumes sterk per dagdeel, dan kan het combineren van meerdere gespecialiseerde API-leveranciers via een routeringslaag financieel aanzienlijk gunstiger uitvallen dan overgedimensioneerde lokale hardware aanhouden. Om te begrijpen hoe geautomatiseerde failover en kostenoptimalisatie tussen tientallen modelaanbieders worden ingericht, biedt de gids over de werking van een LLM API-aggregator inzicht in geavanceerde gateway-architecturen.

VRAM-dynamiek bij audio- en multimodale modellen

Niet alle neurale netwerken volgen exact dezelfde geheugenkarakteristieken als zuivere autoregressieve tekstmodellen. Multimodale modellen (Vision-Language Models) en audionetwerken hanteren afwijkende aandachtsmechanismen en encoders die specifieke eisen stellen aan het videogeheugen.

Bij vision-modellen (zoals Qwen2-VL of Llama-3.2-Vision) wordt een afbeelding opgedeeld in patches die worden omgezet in honderden tot duizenden image tokens. Eén hoge-resolutie afbeelding kan daardoor in één klap 2.048 tokens aan de context toevoegen. Dit veroorzaakt een abrupte sprong in het KV-cachegeheugen. Bovendien moet de Vision Encoder (vaak een ViT-architectuur) gelijktijdig in het VRAM aanwezig blijven, wat doorgaans 1,0 tot 2,5 GB aan extra permanente gewichtsbelasting oplevert.

Bij audiotranscriptie en spraakgeneratie werken modellen vaak met een Encoder-Decoder structuur (zoals Whisper) of diffusie-gebaseerde architecturen. Wie wil weten hoe deze architecturen verschillen van klassieke taalmodellen qua geheugendruk en latentie, vindt diepgaande technische specificaties in het artikel over gespecialiseerde audio- en muziekmodellen, waarin de afwijkende geheugenvereisten van spectrograam-verwerking worden toegelicht.

Meetmethoden en technieken om geheugengebruik te reduceren

Wie zijn geheugenbudget wil optimaliseren zonder concessies te doen aan modelgrootte, heeft de beschikking over geavanceerde optimalisatietechnieken in moderne runtime-engines zoals vLLM, TensorRT-LLM en SGLang:

1. KV-Cache Quantisatie (FP8 en INT4): Door de Key- en Value-vectoren niet in 16-bit float maar in 8-bit float (FP8 E4M3 of E5M2) of 4-bit integer op te slaan, halveert of kwartiert het geheugengebruik van de context. Het kwaliteitsverlies bij FP8 KV-cache is op standaard benchmarks verwaarloosbaar klein (<0,5%), terwijl er direct gigabytes aan VRAM vrijkomen voor langere prompts of grotere batch sizes.

2. PagedAttention en Chunked Prefill: PagedAttention verdeelt de KV-cache in virtuele pagina's (vergelijkbaar met het paginabeheer in besturingssystemen). Dit elimineert interne geheugenfragmentatie volledig, waardoor de bezettingsgraad van het VRAM van circa 70% naar meer dan 96% stijgt. Chunked prefill splitst gigantische invoerprompts op in behapbare stukken, waardoor de activatiepieken tijdens de promptverwerking worden afgevlakt.

3. Nauwkeurig meten in productie: Vertrouw tijdens het testen nooit uitsluitend op eenvoudige tools zoals nvidia-smi, omdat frameworks zoals PyTorch vooraf grote blokken geheugen alloceren via hun eigen caching allocator. Gebruik in plaats daarvan de interne profiling tools van de inferentie-engine (zoals torch.cuda.memory_allocated() versus torch.cuda.memory_reserved()) om het daadwerkelijke dataverbruik te onderscheiden van gereserveerde buffers.

Door de statische gewichten, de gequantiseerde KV-cache, het piekniveau van de activaties en een vaste headroom van twee gigabyte systematisch bij elkaar op te tellen, kan elk implementatietraject vooraf foutloos worden gedimensioneerd. Zo wordt voorkomen dat kostbare GPU-investeringen tekortschieten of onnodig overgedimensioneerd raken.