Hoeveel VRAM heb je nodig om een LLM te draaien?

Voor inferentie is het geheugen dat je nodig hebt ruwweg de gewichten plus de KV-cache plus de runtime-overhead. Gewichten nemen het aantal parameters maal het aantal bytes per parameter in: ongeveer 2 GB per miljard parameters bij BF16, 1 GB bij FP8 en ruwweg 0.5 GB bij 4-bit. De KV-cache groeit met elk token in het geheugen, over alle gelijktijdige verzoeken heen, en bij de lange contexten die agents nodig hebben, wedijvert hij in omvang met de gewichten. Serving-frameworks geven niet de hele kaart aan het model, dus houd ruimte over voordat je een GPU kiest. Zonder GPU geldt dezelfde rekensom voor het systeem-RAM, met een lagere snelheid.

• Gewichten = parameters × bytes per parameter (2 bij BF16, 1 bij FP8, ongeveer 0.5 bij 4-bit).
• KV-cache per token = 2 × lagen × KV-heads × head-dimensie × bytes; vermenigvuldig met het aantal tokens dat tegelijk in het geheugen staat.
• Schattingen verschillen vooral in de contextlengte die ze aannemen; controleer die voordat je twee getallen vergelijkt.
• Mixture-of-experts-modellen moeten elke expert laden, ook al zijn er per token maar weinig actief.
• Volledig fine-tunen met Adam vraagt ongeveer 16 bytes per parameter, nog vóór activaties; adapters vragen veel minder.

Een taalmodel serveren kost GPU-geheugen voor drie dingen: de gewichten, de KV-cache met de attention-keys en -values van elk token dat in behandeling is, en werkgeheugen voor activaties, de CUDA-context en het serving-framework zelf.

De eerste twee volgen uit de modelkaart en je instellingen. De derde hangt af van de runtime, en daardoor is een kaart nooit volledig beschikbaar voor het model. vLLM laat de model-executor bijvoorbeeld een vast deel van het GPU-geheugen gebruiken, ingesteld met --gpu-memory-utilization, dat in de huidige documentatie standaard 0.92 is [1], en standaard legt het CUDA-graphs vast, die volgens vLLM “take up extra memory in the GPU” (extra GPU-geheugen innemen) [2].

Gewichten hebben één waarde per parameter nodig. Vermenigvuldig het aantal parameters met het aantal bytes per waarde: een miljard parameters in BF16 nemen ongeveer 2 GB in.

Qwen3-8B heeft 8.2 miljard parameters [3], dus de gewichten nemen ongeveer 16.4 GB in bij BF16, 8.2 GB bij FP8 en ruwweg 4.1 GB bij 4-bit. Gekwantiseerde formaten slaan naast de waarden ook schaalfactoren op, dus echte 4-bit-bestanden zijn iets groter dan een halve byte per parameter.

Mixture-of-experts-modellen laden elke expert

Een mixture-of-experts-model gebruikt per token maar een deel van zijn parameters, maar ze moeten allemaal in het geheugen staan. Qwen3-30B-A3B heeft in totaal 30.5 miljard parameters, waarvan er 3.3 miljard geactiveerd worden [4]: het rekent als een klein model, maar heeft ongeveer 61.0 GB nodig voor de gewichten in BF16. Het formaat telt net zo zwaar als het aantal: gpt-oss-120b van OpenAI heeft 117 miljard parameters, en omdat de expertgewichten in MXFP4 worden geleverd, draait het op één GPU van 80 GB, terwijl gpt-oss-20b binnen 16 GB draait [5].

Voor elk token waaraan het model werkt, houdt elke laag per KV-head een key-vector en een value-vector bij. Het PagedAttention-artikel geeft het voorbeeld van OPT-13B, waar één token 800 KB inneemt: 2 (key en value) × 5,120 (verborgen dimensie) × 40 (lagen) × 2 bytes [6].

Nieuwere modellen gebruiken grouped-query attention, met minder KV-heads dan query-heads, waardoor de cache kleiner wordt. Qwen3-8B heeft 32 query-heads maar 8 KV-heads [3]. Met het aantal lagen en de head-dimensie uit het configuratiebestand van elk model komt de cache bij BF16 als volgt uit:

Het aantal tokens dat telt, is alles wat tegelijk in het geheugen staat: contextlengte × gelijktijdige verzoeken. Tien chats met elk 8K tokens hebben dezelfde cache nodig als één chat met 80K tokens. Daarom kan een model dat in een snelle test “past”, onder belasting toch zonder geheugen komen te zitten.

Twee instellingen maken de cache kleiner. vLLM schrijft dat de KV-cache in FP8 opslaan “can significantly reduce its memory footprint” (het geheugengebruik flink kan verkleinen), zodat er meer tokens in hetzelfde geheugen passen [11], en een grens aan de contextlengte (max_model_len) en de batchgrootte (max_num_seqs) beperkt hoeveel cache er kan worden aangevraagd [2].

Gewichten plus een KV-cache van 32,768 tokens bij BF16 geven het geheugen waarmee je rekent, nog vóór de runtime-overhead:

• Qwen3-8B heeft bij BF16 ongeveer 21.2 GB nodig: krap op een kaart van 24 GB zodra de overhead erbij komt, ruim op 48 GB, en ongeveer 13.0 GB met FP8-gewichten.
• Qwen3-30B-A3B rekent als een model van 3B, maar heeft bij BF16 ongeveer 64.2 GB nodig, omdat elke expert geladen blijft.
• Qwen2.5-72B-Instruct heeft bij BF16 ongeveer 156.1 GB nodig, meer dan twee GPU's van 80 GB met de standaardinstelling aan vLLM overlaten (147.2 GB). Met FP8-gewichten (83.4 GB) past het op één H200 van 141 GB of verdeeld over twee GPU's van 80 GB. Bij 4-bit past het alleen met een kleiner budget op een kaart van 48 GB: ongeveer 39.0 GB met 8K tokens.

Waarom schattingen voor hetzelfde model verschillen

Geheugencalculators zijn het zelden oneens over de gewichten. Ze verschillen in de context die ze aannemen, in de vraag of ze de KV-cache überhaupt meetellen, en in hoeveel van de kaart ze als bruikbaar beschouwen. Hetzelfde model en dezelfde precisie geven heel verschillende antwoorden:

Controleer, voordat je twee schattingen vergelijkt, de contextlengte en het aantal gelijktijdige verzoeken achter elk ervan. Om de rekensom voor je eigen model, precisie en context te maken, gebruik je de tool VRAM en modelgrootte.

Agents hebben lange contexten nodig, en de KV-cache groeit met elk token. Hermes Agent vereist bijvoorbeeld een model met een context van minstens 64,000 tokens en vraagt je een lokaal model op 64K in te stellen, bijvoorbeeld --ctx-size 65536 in llama.cpp [12]. Ollama gebruikt een contextvenster van 4,096 tokens, tenzij je het verhoogt met OLLAMA_CONTEXT_LENGTH of num_ctx [13], dus de standaardwaarde ligt ver onder wat zo'n agent nodig heeft.

Bij 65,536 tokens heeft Qwen3-8B ongeveer 26.1 GB nodig met gewichten en cache in BF16, meer dan een kaart van 24 GB kan bevatten. Met FP8-gewichten en een FP8-KV-cache komt het uit op ongeveer 13.0 GB. Het model ondersteunt standaard 32,768 tokens, dus een venster van 64K betekent ook dat je YaRN-schaling inschakelt zoals de modelkaart beschrijft [3].

Gelijktijdigheid vermenigvuldigt de cache opnieuw: in Ollama groeit het geheugen dat een model nodig heeft met het aantal parallelle verzoeken maal de contextlengte [13]. Reken op het aantal gesprekken dat de agent tegelijk voert, niet op één.

De eigen richtlijn van vLLM voor het kiezen van een indeling is kort:

• Past het model op één GPU, draai het dan op die GPU; gedistribueerde inferentie is dan waarschijnlijk niet nodig.
• Is het te groot voor één GPU maar past het op één node met meerdere GPU's, gebruik dan tensor parallelism.
• Is het te groot voor één node, combineer tensor parallelism dan met pipeline parallelism [14].

Tensor parallelism verdeelt het model over GPU's (tensor_parallel_size) [2], en die GPU's wisselen dan bij elke laag data uit. Daar telt de interconnect uit de GPU-cloudchecklist: GPU's die via NVLink verbonden zijn, kunnen dat veel beter aan dan kaarten die alleen via PCIe communiceren.

Probeer, voordat je GPU's toevoegt, eerst de goedkopere knoppen: kwantiseer de gewichten, sla de KV-cache op in FP8 en begrens de contextlengte en de gelijktijdigheid tot wat je toepassing nodig heeft.

Trainen houdt veel meer vast dan de gewichten. Het ZeRO-artikel splitst training met gemengde precisie en de Adam-optimizer uit: 2 bytes per parameter voor FP16-gewichten, 2 voor gradiënten en 12 voor de FP32-kopie van de gewichten, momentum en variantie, in totaal 16 bytes. Een GPT-2 met 1.5 miljard parameters heeft daarom minstens 24 GB nodig, tegenover 3 GB voor alleen de FP16-gewichten [15]. Met dezelfde rekensom heeft volledig fine-tunen van Qwen3-8B ongeveer 131.2 GB nodig voor de modeltoestand, nog vóór activaties, en dat betekent meerdere GPU's en een gesharde optimizer.

Adapters veranderen het budget

Low-rank adapters trainen in plaats daarvan een klein aantal extra gewichten. Vergeleken met fine-tunen van GPT-3 175B met Adam melden de auteurs van LoRA 10,000 keer minder trainbare parameters en een 3 keer kleinere behoefte aan GPU-geheugen [16]. QLoRA combineert een 4-bit-basismodel met adapters en maakte het mogelijk een model van 65B te fine-tunen op één GPU van 48 GB [17].

Met een schatting in de hand kies je het kleinste geheugenniveau dat ruimte laat voor overhead en pieken in het verkeer. De tabel toont elke GPU in onze catalogus die vandaag een gecontroleerde prijs heeft:

Providers per niveau staan in de vergelijkingen voor inferentiehosting en GPU-cloud. Per geheugenniveau: RTX 4090-cloud (24 GB), L40S-hosting (48 GB) en H100-hosting (80 GB).

Een model kan ook vanuit gewoon systeemgeheugen draaien. llama.cpp draait op x86-CPU's met AVX, AVX2, AVX512 en AMX, en de hybride CPU+GPU-modus bestaat om “partially accelerate models larger than the total VRAM capacity” (modellen die groter zijn dan het totale VRAM gedeeltelijk te versnellen) [18]. Ollama laat zien waar een geladen model staat: ollama ps meldt 100% GPU, 100% CPU (systeemgeheugen) of een verdeling tussen die twee [13].

De rekensom verandert niet: gewichten plus KV-cache moeten passen, nu in het RAM, naast het besturingssysteem en al het andere op de server. Op een machine met 16 GB heeft Qwen3-8B bij 4-bit met een cache van 32,768 tokens ongeveer 8.9 GB nodig en past het, terwijl Qwen3-30B-A3B bij 4-bit alleen voor de gewichten al ongeveer 15.3 GB nodig heeft en niet genoeg ruimte overlaat.

Reken erop dat genereren op alleen een CPU trager is dan op een GPU; dat verschil is wat de hybride modus hierboven gedeeltelijk dicht. Het past bij kleine modellen, weinig verkeer en agents op de achtergrond; test je model bij de contextlengte die je nodig hebt voordat je een plan kiest. CPU-servers worden vergeleken onder AI-VPS, en providers met Ollama-templates of -handleidingen onder Ollama-hosting.