LLM VRAM-krav: Mastertabellen for 2026 (alle modeller, alle kvantiseringer)

LLM VRAM-krav: Mastertabellen for 2026 (alle modeller, alle kvantiseringer)

Her er tallet som overrasker de fleste: DeepSeek-V3.2 har 671 milliarder parametere, men bare 37 milliarder er aktive per token. Så hvor mye VRAM trenger den egentlig? Alle 671 milliardene, rundt 382 GB ved Q4. LLM VRAM-krav følger sjelden intuisjonen, og gapet mellom «aktive parametere» og «det du faktisk må laste inn» er nøyaktig der maskinvarebudsjetter sprekker. Denne guiden gir deg mastertabellen (hver eneste store åpne modell, hvert kvantiseringsnivå, GB-tallet og GPU-en som kjører den), pluss formelen for å beregne størrelsen på hvilken som helst modell selv på rundt ti sekunder.

Viktigste poenger

• VRAM for vektene ≈ parametere × byte per parameter: FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Legg til KV-cache og ca. 15-20 % overhead på toppen.
• Mixture-of-Experts-modeller (DeepSeek, GLM-5.2, Qwen3-235B) må laste inn hver eneste ekspert i VRAM. «Aktive parametere» gir deg fart, ikke minne.
• KV-cache er den skjulte kostnaden. Llama 3.3 70B trenger rundt 2.6 GB cache ved 8K kontekst og rundt 41 GB ved 128K, i tillegg til vektene.
• Q4_K_M er det fornuftige standardvalget: nesten full kvalitet på rundt en firedel av FP16-fotavtrykket.
• En 12B-modell som Gemma 4 får plass på et 8 GB-kort ved Q4. En tett 70B-modell trenger rundt 40 GB. En 671B frontier-MoE trenger en liten server.

LLM VRAM-krav per modell: Mastertabellen

Det korte svaret: ved Q4_K_M får små modeller (under 14B) plass på forbrukerkort med 8-12 GB, mellomstore modeller (24-32B) vil ha 16-24 GB, en tett 70B-modell trenger rundt 40 GB, og frontier-MoE-modellene hopper opp i hundrevis av gigabyte fordi hver ekspert må være til stede samtidig. Her er hele bildet samlet på ett sted. Alle tallene er minnet for vektene alene, beregnet ut fra hver modells parameterantall og kryssjekket mot de offisielle modellkortene fra Meta AI, Qwen og Hugging Face.

To ting du bør legge merke til i denne tabellen. For det første er kvantisering den kraftigste spaken du har: å gå fra FP16 til Q4 kutter fotavtrykket med rundt 4x, med et nesten umerkelig kvalitetstap. For det andre ser MoE-radene brutale ut fordi de er det. Qwen3-30B-A3B aktiverer bare 3B parametere per token, så den kjører like raskt som en liten modell, men du må likevel holde alle 30B i minnet for å ha hver ekspert klar. Vil du ha modell-for-modell-detaljene bak disse tallene? Vår dybdegjennomgang av Gemma 4 12B og oversikten over de beste åpne LLM-ene i 2026 dekker benchmarker og lisenser.

VRAM-formelen: Beregn hvilken som helst modell selv

For å beregne størrelsen på en hvilken som helst modell, ganger du parameterantallet med byte per parameter for kvantiseringen din, og legger så til litt for KV-cache og kjøretidsoverhead. Det er alt. Vektene er den dominerende faktoren, og regnestykket er enkelt nok til å gjøre på baksiden av en serviett.

Kjerneligningen for vektene:

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

Bits-per-weight-verdiene du trenger (dette er de effektive ratene for GGUF k-quant-filer, som har litt blokk-metadata på toppen av den nominelle bitdybden):

Utregnet eksempel, Gemma 4 12B ved Q4_K_M: 11.95 × 4.5 ÷ 8 = rundt 6.7 GB for vektene. Det stemmer godt med de rundt 6.6 GB som det offisielle modellkortet oppgir, og forklarer hvorfor modellen får plass på et 8 GB-kort med litt rom til en beskjeden kontekst. Gjør samme regnestykke for en 70B-modell ved Q4, og du får 70 × 4.5 ÷ 8 = 39.4 GB, som er grunnen til at «du trenger to 24 GB-kort eller ett 48 GB-kort til en 70B» er tommelfingerregelen alle gjentar.

Det fulle bildet legger til to faktorer til: total VRAM ≈ vekter + KV-cache + ~15-20 % overhead. Overheaden dekker aktiveringsbuffere, CUDA-konteksten og minnefragmentering, og GPU-en din reserverer også en halv gigabyte eller så til driveren, så planlegg aldri med å bruke 100 % av den oppgitte VRAM-en.

Hvorfor KV-cache er tallet som biter deg

KV-cachen lagrer attention-nøklene og -verdiene for hvert token som allerede er i konteksten, og den vokser lineært med kontekstlengden. Ved korte prompter er det en avrundingsfeil. Går du mot en lang kontekst, kan den konkurrere med eller overgå selve vektene. Dette er den desidert vanligste årsaken til at en modell som «burde ha plass», kaster en out-of-memory-feil midt i genereringen.

Formelen, 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)

Ta Llama 3.3 70B: 80 lag, 8 KV-hoder, hodedimensjon 128, så kv_dim er 1024. Ved FP16 blir det 80 × 2 × 1024 × 2 = 327,680 byte per token, rundt 0.31 MB. Ganger du med kontekstlengden, skriver historien seg selv: ved 8K token er cachen rundt 2.6 GB, ved 32K er den rundt 10 GB, og ved 128K sveller den opp til rundt 41 GB. Det siste tallet kommer i tillegg til de 40 GB med vekter, så en «40 GB-modell» blir stille og rolig til et 80 GB-problem i det øyeblikket du fyller konteksten.

To praktiske utveier. Grouped-query attention (som alle nyere modeller bruker) kutter allerede kv_dim kraftig sammenlignet med den gamle multi-head-designen, så moderne modeller er langt snillere her enn Llama 2 var. Og de fleste inferensmotorer kan kvantisere KV-cachen til 8-bit eller 4-bit, og halvere eller kvartere størrelsen for en liten kvalitetskostnad. Kjører du lange kontekster i produksjon, dekker sammenligningen av vLLM og SGLang hvilken backend som håndterer dette minnet mest effektivt med paged attention.

MoE-modeller: Hvorfor «aktive parametere» ikke sparer VRAM

Dette er fellen som koster folk mest penger. En Mixture-of-Experts-modell som DeepSeek-V3.2 (671B totalt, 37B aktive, deler V3-arkitekturen) eller GLM-5.2 (744B totalt, 40B aktive) sender hvert token gjennom et lite utvalg av ekspertene sine. Markedsføringen lener seg på det aktive tallet fordi det beskriver hastighet: du betaler bare for 37B parameteres regnekraft per token, så inferensen er rask for modellens størrelse. Men hver ekspert må ligge i minnet, klar til å bli valgt, noe som betyr at VRAM-budsjettet ditt bestemmes av det totale parameterantallet, ikke det aktive.

Så den ærlige tolkningen av tabellen over: GLM-5.2 kjører like raskt som en 40B-modell, men opptar minnet til en 744B-modell. Det er derfor disse frontier-modellene med åpen kildekode trenger en 8-GPU-server eller en stor maskin med unified memory, selv om et enkelt forward pass er billig. Qwen3-235B-A22B har samme form i mindre skala: rask per token, tung å hoste.

Fordelen med MoE viser seg på maskinvare med unified memory. En Mac Studio med 512 GB unified memory kan holde en 671B-modell ved Q4 og likevel kjøre den i brukbar hastighet, nettopp fordi bare 37B aktiveres, så kravet til minnebåndbredde per token holder seg rimelig. Er du ny på å kjøre disse lokalt, start med guiden vår for lokalt LLM-oppsett før du bruker penger på maskinvare.

Hvilken kvantisering bør du velge?

For nesten alle er Q4_K_M det riktige standardvalget: det holder nesten full kvalitet samtidig som det kutter FP16-fotavtrykket med rundt 4x. Gå opp til Q5_K_M eller Q8 bare hvis du har VRAM til overs og en kvalitetssensitiv oppgave, og velg FP16 bare når du finjusterer eller benchmarker mot en referanse. Under Q4 blir kvalitetstapet raskt merkbart, så Q3 og lavere er en siste utvei for å presse en modell inn på et kort som rett og slett er for lite.

Ett forbehold: kvantiseringskvaliteten er ikke lik på tvers av modeller. Veldig små modeller (under 4B) merker Q4 mer enn store modeller, fordi de har mindre redundans å gå på. På en 70B-modell er det vanskelig å skille Q4 fra Q8 på de fleste oppgaver. På en 1.7B-modell er forskjellen reell.

Hvilken GPU trenger du egentlig?

Match Q4-kolonnen i mastertabellen mot et kort med litt slingringsmonn til KV-cachen. Her er den praktiske oversikten fra rimelig forbrukermaskinvare og helt opp til datasenternivå, med modelltieret hver klasse kjører komfortabelt ved Q4.

Apple Silicon fortjener en egen nevnelse fordi unified memory endrer regnestykket. En Mac skiller ikke VRAM fra system-RAM, så en 128 GB M-serie-maskin kan laste inn modeller som ellers ville trengt flere diskrete GPU-er, mot at du ofrer toppytelse til fordel for å få plass til enorme vekter på én desktop. For backendene som får mest ut av hvert av disse kortene, benchmarker vår oversikt over de beste verktøyene for å kjøre LLM-er lokalt de reelle hastighetsforskjellene.

Slik dimensjonerer vi VRAM for kundeprosjekter

Hos Techsy setter vi i produksjon åpne modeller for kunder ofte nok til at VRAM-dimensjonering er den første samtalen, før modellvalg, før prompter, før alt annet. Metoden vår er kjedelig med vilje, fordi feilmodusen (en OOM i produksjon under reell kontekstbelastning) er dyr. Her er prosessen vi faktisk kjører.

Vi starter med regnestykket fra tabellen, og måler deretter. Etter at en modell er lastet inn, sjekker vi det faktiske minnefotavtrykket i stedet for å stole blindt på estimatet:

# 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

Lærdommen som gjentar seg: team dimensjonerer for vektene og glemmer KV-cachen, og lurer så på hvorfor en modell som lastet fint, dør tre lange forespørsler inn i en demo. Vi dimensjonerer for vektene pluss KV-cachen ved den maksimale konteksten appen faktisk kommer til å bruke, pluss slingringsmonn, og vi setter et tak på --ctx-size slik at en forespørsel som løper løpsk, ikke kan OOM-e boksen. For alt som er kundevendt, kjører vi heller en kvantisert 32B som aldri velter, enn en FP16 70B som OOM-er under last.

Vurderer du om du skal selv-hoste en åpen modell eller bli på et hostet API, er akkurat den avveiningen (maskinvarekostnad og driftsbyrde mot pris per token og kontroll) det teamet vårt kartlegger under et AI-integrasjonsoppdrag. Om det hadde vært nyttig å få noen til å regne på tallene mot din faktiske arbeidsmengde, kan du få en gratis konsultasjon, så dimensjonerer vi det sammen med deg.

Ofte stilte spørsmål

Hvor mye VRAM trenger jeg for å kjøre en 70B-modell?

En tett 70B-modell som Llama 3.3 70B trenger rundt 40 GB VRAM for vektene ved Q4_K_M, så planlegg for et 48 GB-kort (RTX 6000 Ada) eller to 24 GB-kort. Legg til flere gigabyte for KV-cache hvis du bruker en lang kontekst, noe som presser det praktiske behovet mot 48 GB eller mer.

Hvor mye VRAM trenger Llama, Qwen eller DeepSeek?

Det kommer helt an på varianten. Llama 4 Scout trenger rundt 62 GB ved Q4, Qwen3-32B rundt 18 GB, og Qwen3-8B under 5 GB. DeepSeek-V3.2, en 671B MoE, trenger rundt 382 GB fordi hver ekspert må lastes inn. Sjekk alltid det totale parameterantallet, ikke det aktive, for MoE-modeller.

Kan jeg kjøre en LLM på en 8 GB GPU?

Ja, uten problemer. Et 8 GB-kort som RTX 4060 kjører modeller opptil rundt 12B parametere ved Q4_K_M. Gemma 4 12B får plass på rundt 6.8 GB, og etterlater rom til en beskjeden kontekst. For alt som er større, må du enten kvantisere hardere, holde konteksten kort, eller gå opp til et større kort.

Hva kan en 24 GB GPU som RTX 4090 kjøre?

Et 24 GB-kort håndterer tette modeller opptil rundt 32B ved Q4_K_M med slingringsmonn til en rimelig kontekst, så Qwen3-32B og Mistral Small 3.2 24B er komfortable. Det kjører også Qwen3-30B-A3B MoE, som laster inn 30B vekter, men genererer i tempoet til en 3B-modell takket være sparsom aktivering.

Går kvantisering ut over modellkvaliteten?

Ved Q4_K_M og oppover er kvalitetstapet lite og ofte umerkelig på reelle oppgaver, spesielt for modeller over 13B. Gapet øker jo lavere du går og jo mindre modellene er, så Q4 på en 70B er nesten gratis, mens Q4 på en 1.7B er merkbart. Q8 er praktisk talt tapsfritt hvis du har minnet til det.

Trenger MoE-modeller mindre VRAM enn tette modeller?

Nei, og dette er den vanligste misforståelsen. En Mixture-of-Experts-modell må holde hver ekspert i VRAM, så minnebehovet bestemmes av det totale parameterantallet. Det aktive parametertallet beskriver bare inferenshastigheten. GLM-5.2 kjører like raskt som en 40B-modell, men trenger minnet til en 744B-modell.

Er unified memory det samme som VRAM?

Funksjonelt sett, for å laste inn modeller, ja. Apple Silicon og noen andre systemer deler ett minnebasseng mellom CPU og GPU, så en 128 GB Mac kan laste inn modeller som ellers ville trengt flere diskrete GPU-er. Avveiningen er båndbredde: unified memory leverer vanligvis lavere toppytelse enn en datasenter-GPU i toppklassen, så tokens per sekund blir lavere.

Kan jeg avlaste deler av en modell til system-RAM eller CPU?

Ja. Motorer som llama.cpp og Ollama lar deg beholde noen lag på GPU-en og resten i system-RAM med et flagg som --n-gpu-layers. Det gjør at du kan kjøre en modell som er for stor for VRAM-en din, men hvert lag på CPU-en bremser genereringen kraftig, så bruk det for å gjøre en modell mulig, ikke rask.

Hvordan beregner jeg VRAM for en modell som ikke er i tabellen?

Gang parameterantallet i milliarder med bits-per-weight for kvantiseringen din, og del på 8. For Q4_K_M bruker du rundt 4.5 bits, så en 40B-modell trenger 40 × 4.5 ÷ 8 = rundt 22.5 GB for vektene. Legg til rundt 15-20 % overhead pluss KV-cachen din for det reelle behovet.