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

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

Her er det tal, der fanger de fleste på det forkerte ben: DeepSeek-V3.2 har 671 milliarder parametre, men kun 37 milliarder er aktive ved ethvert givent token. Så hvor meget VRAM kræver den egentlig? Alle 671 milliarder værd, hvilket svarer til cirka 382 GB ved Q4. LLM VRAM-krav følger sjældent intuitionen, og kløften mellem "aktive parametre" og "hvad du skal indlæse" er præcis dér, hvor hardwarebudgetterne eksploderer. Denne guide giver dig master-tabellen (alle store open-source-modeller, alle kvantiseringsniveauer, GB-tallet og GPU'en, der kører det) plus formlen til selv at dimensionere enhver model på omkring ti sekunder.

Vigtigste pointer

• VRAM til vægte ≈ parametre × bytes-pr-parameter: FP16 = 2,0, Q8 = 1,0, Q5_K_M ≈ 0,68, Q4_K_M ≈ 0,57. Læg KV-cache og ~15-20 % overhead oveni.
• Mixture-of-Experts-modeller (DeepSeek, GLM-5.2, Qwen3-235B) skal indlæse hver enkelt ekspert i VRAM. "Aktive parametre" giver dig hastighed, ikke mindre hukommelsesforbrug.
• KV-cachen er den skjulte omkostning. Llama 3.3 70B har brug for ca. 2,6 GB cache ved 8K kontekst og omkring 41 GB ved 128K, oven i vægtene.
• Q4_K_M er den fornuftige standardindstilling: næsten fuld kvalitet med cirka en fjerdedel af FP16's footprint.
• En 12B-model som Gemma 4 passer på et 8 GB-kort ved Q4. En 70B dense-model kræver omkring 40 GB. En 671B frontier MoE-model kræver en lille server.

LLM VRAM-krav pr. model: Master-tabellen

Det korte svar: Ved Q4_K_M passer små modeller (under 14B) på consumer 8-12 GB-kort, mellemstore modeller (24-32B) vil have 16-24 GB, en 70B dense-model kræver omkring 40 GB, og de nyeste MoE-modeller hopper op i hundredvis af gigabyte, fordi hver ekspert skal være resident. Her er det fulde overblik samlet ét sted. Alle tal er hukommelsen til selve vægtene, beregnet ud fra hver models parameterantal og krydstjekket med de officielle modelkort fra Meta AI, Qwen og Hugging Face.

To ting kan aflæses af denne tabel. For det første er kvantisering den største løftestang, du har: At gå fra FP16 til Q4 reducerer footprintet med cirka 4x med en knap mærkbar kvalitetsforskel. For det andet ser MoE-rækkerne brutale ud, fordi de er det. Qwen3-30B-A3B aktiverer kun 3B parametre per token, så den kører med hastigheden af en lille model, men du skal stadig have alle 30B i hukommelsen for at have hver ekspert klar. Vil du have detaljerne model-for-model bag disse tal? Vores dybdegående analyse af Gemma 4 12B og oversigten over de bedste open-source LLM'er i 2026 dækker benchmarks og licenser.

VRAM-formlen: Beregn enhver model selv

For at dimensionere enhver model ganger du dens parameterantal med bytes-per-parameter for din kvantisering og lægger derefter lidt til til KV-cachen og runtime-overhead. Det er det. Vægte er den dominerende faktor, og aritmetikken er simpel nok til at kunne laves på bagsiden af en serviet.

Kerneformlen for vægtene:

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

De bits-per-vægt-værdier, du skal bruge (dette er de effektive rater for GGUF k-quant-filer, som bærer en smule blok-metadata oven i den nominelle bitdybde):

Regneeksempel, Gemma 4 12B ved Q4_K_M: 11,95 × 4,5 ÷ 8 = ca. 6,7 GB til vægtene. Det stemmer overens med de cirka 6,6 GB, det officielle modelkort angiver, og forklarer, hvorfor det passer på et 8 GB-kort med plads til en beskeden kontekst. Kør samme matematik for en 70B-model ved Q4, og du får 70 × 4,5 ÷ 8 = 39,4 GB, hvilket er grunden til, at "du skal bruge to 24 GB-kort eller et 48 GB-kort til en 70B" er tommelfingerreglen, alle gentager.

Det fulde billede tilføjer to flere led: samlet VRAM ≈ vægte + KV-cache + ~15-20 % overhead. Overhead dækker aktiveringsbuffere, CUDA-konteksten og hukommelsesfragmentering, og din GPU reserverer også omkring en halv gigabyte til driveren, så planlæg aldrig med at bruge 100 % af den angivne VRAM.

Hvorfor KV-cachen er tallet, der bider dig

KV-cachen gemmer attention-nøgler og -værdier for hvert token, der allerede er i konteksten, og den vokser lineært med kontekstlængden. Ved korte prompts er det en afrundingsfejl. Skubber man mod en lang kontekst, kan den rivalisere med eller endda overstige selve vægtene. Dette er den enkelt mest almindelige årsag til, at en model, der "burde passe", kaster en out-of-memory-fejl midt i genereringen.

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

Tag Llama 3.3 70B: 80 lag, 8 KV-heads, head-dimension 128, så kv_dim er 1024. Ved FP16 er det 80 × 2 × 1024 × 2 = 327.680 bytes per token, ca. 0,31 MB. Gang med kontekstlængden, og historien skriver sig selv: ved 8K tokens er cachen cirka 2,6 GB, ved 32K er den omkring 10 GB, og ved 128K svulmer den op til omkring 41 GB. Det sidste tal kommer oven i de 40 GB vægte, så en "40 GB-model" bliver stille og roligt til et 80 GB-problem, i det øjeblik du fylder vinduet.

To praktiske flugtveje. Grouped-query attention (som alle nyere modeller bruger) skærer allerede kv_dim ned sammenlignet med det gamle multi-head-design, så moderne modeller er langt mere venlige her, end Llama 2 var. Og de fleste inferens-motorer kan kvantisere KV-cachen til 8-bit eller 4-bit, hvilket halverer eller firedeler dens størrelse for en lille kvalitetsomkostning. Hvis du serverer lange kontekster i produktion, dækker sammenligningen af vLLM vs SGLang, hvilken backend håndterer denne hukommelse mest effektivt med paged attention.

MoE-modeller: Hvorfor "aktive parametre" ikke sparer VRAM

Dette er den fælde, der koster folk flest penge. En Mixture-of-Experts-model som DeepSeek-V3.2 (671B totalt, 37B aktive, deler V3-arkitekturen) eller GLM-5.2 (744B totalt, 40B aktive) router hvert token gennem en lille undergruppe af sine eksperter. Markedsføringen læner sig op ad det aktive tal, fordi det beskriver hastighed: du betaler kun for 37B parametres beregning per token, så inferensen er hurtig for modellens størrelse. Men hver ekspert skal sidde i hukommelsen, klar til at blive valgt, hvilket betyder, at dit VRAM-budget sættes af det totale parameterantal, ikke det aktive.

Så den ærlige læsning af tabellen ovenfor: GLM-5.2 kører med hastigheden af en 40B-model, men optager hukommelsen af en 744B-model. Derfor kræver disse frontier open-source-modeller en 8-GPU-server eller en stor maskine med unified memory, selvom et enkelt forward pass er billigt. Qwen3-235B-A22B har samme form i mindre skala, hurtig per token, tung at hoste.

Fordelen ved MoE viser sig på hardware med unified memory. En Mac Studio med 512 GB unified memory kan holde en 671B-model ved Q4 og stadig køre den med brugbar hastighed, netop fordi kun 37B aktiveres, så hukommelsesbåndbreddens efterspørgsel per token forbliver rimelig. Hvis du er ny til at køre disse lokalt, så start med vores guide til opsætning af lokal LLM, før du bruger penge på hardware.

Hvilken kvantisering skal du vælge?

For næsten alle er Q4_K_M den rigtige standardindstilling: den bevarer næsten fuld kvalitet, mens den skærer FP16-footprintet med omkring 4x. Gå op til Q5_K_M eller Q8 kun hvis du har overskydende VRAM og en kvalitetsfølsom opgave, og gribe kun til FP16, når du finjusterer eller benchmarking mod en reference. Under Q4 bliver kvalitetsforringelsen hurtigt mærkbar, så Q3 og lavere er en sidste udvej for at presse en model ned på et kort, der er genuint for lille.

En forbehold: kvantiseringskvaliteten er ikke identisk på tværs af modeller. Meget små modeller (under 4B) mærker Q4 mere end store, fordi de har mindre redundans at give af. På en 70B-model er Q4 versus Q8 svær at skelne på de fleste opgaver. På en 1,7B-model er kløften reel.

Hvilken GPU har du egentlig brug for?

Match Q4-kolonnen i master-tabellen med et kort med lidt luft til KV-cachen. Her er det praktiske match fra budget consumer-hardware op til datacenteret, med det model-niveau hver klasse komfortabelt kører ved Q4.

Apple Silicon fortjener en særlig omtale, fordi unified memory ændrer regnestykket. En Mac splitter ikke VRAM fra system-RAM, så en 128 GB M-serie-maskine kan indlæse modeller, der ellers ville kræve flere diskrete GPU'er, og bytter peak throughput for evnen til at passe enorme vægte på én desktop. For de backends, der presser mest ud af nogen af disse kort, dækker vores roundup af de bedste værktøjer til at køre LLM'er lokalt de reelle hastighedsforskelle.

Hvordan vi dimensionerer VRAM til klient-deployments

Hos Techsy deployer vi open-source-modeller for kunder ofte nok til, at VRAM-dimensionering er den første samtale, før valg af model, før prompts, før noget som helst. Vores metode er kedelig med vilje, fordi fejltypen (en OOM i produktion under reel kontekstbelastning) er dyr. Her er processen, vi faktisk kører.

Vi starter med tabelmatematikken og måler derefter. Efter indlæsning af en model tjekker vi det reelle residente footprint i stedet for at stole 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

Lektien, der gentager sig: Teams dimensionerer efter vægtene og glemmer KV-cachen, undrer sig så over, hvorfor en model, der indlæste fint, dør tre lange requests inde i en demo. Vi dimensionerer efter vægtene plus KV-cachen ved den maksimale kontekst, appen virkelig vil bruge, plus luft, og vi begrænser --ctx-size, så en løbsk request ikke kan OOM'e boksen. Til alt, der er customer-facing, vil vi hellere køre en kvantiseret 32B, der aldrig falder om, end en FP16 70B, der OOM'er under belastning.

Hvis du overvejer, om du skal self-hoste en open-source-model eller blive på en hosted API, er den handel (hardwareomkostninger og ops-byrde versus pris per token og kontrol) præcis det, vores team scoper under en AI-integrationsengagement. Hvis det ville hjælpe at få nogen til at køre tallene mod din faktiske workload, så få en gratis konsultation, og vi dimensionerer det sammen med dig.

Ofte stillede spørgsmål

Hvor meget VRAM skal jeg bruge for at køre en 70B-model?

En 70B dense-model som Llama 3.3 70B har brug for omkring 40 GB VRAM til vægtene ved Q4_K_M, så planlæg efter et 48 GB-kort (RTX 6000 Ada) eller to 24 GB-kort. Tilføj flere gigabyte til KV-cache, hvis du bruger en lang kontekst, hvilket skubber de praktiske krav op mod 48 GB eller mere.

Hvor meget VRAM kræver Llama, Qwen eller DeepSeek?

Det afhænger helt af varianten. Llama 4 Scout har brug for omkring 62 GB ved Q4, Qwen3-32B omkring 18 GB, og Qwen3-8B under 5 GB. DeepSeek-V3.2, en 671B MoE, har brug for cirka 382 GB, fordi hver ekspert skal indlæses. Tjek altid det totale parameterantal, ikke det aktive, for MoE-modeller.

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

Ja, komfortabelt. Et 8 GB-kort som en RTX 4060 kører modeller op til omkring 12B parametre ved Q4_K_M. Gemma 4 12B passer i cirka 6,8 GB, hvilket efterlader plads til en beskeden kontekst. Til noget større skal du enten kvantisere hårdere, holde konteksten kort eller rykke op til et større kort.

Hvad kan en 24GB GPU som RTX 4090 køre?

Et 24 GB-kort håndterer dense-modeller op til omkring 32B ved Q4_K_M med luft til en rimelig kontekst, så Qwen3-32B og Mistral Small 3.2 24B er komfortable. Den kører også Qwen3-30B-A3B MoE, som indlæser 30B vægte, men genererer med hastigheden af en 3B-model takket være sparse activation.

Skader kvantisering modelkvaliteten?

Ved Q4_K_M og derover er kvalitetstabet lille og ofte umærkeligt på rigtige opgaver, især for modeller over 13B. Kløften bliver bredere, jo længere ned du går, og jo mindre modellerne bliver, så Q4 på en 70B er næsten gratis, mens Q4 på en 1,7B er mærkbar. Q8 er effektivt tabsfri, hvis du har hukommelsen.

Har MoE-modeller brug for mindre VRAM end dense-modeller?

Nej, og dette er den mest almindelige misforståelse. En Mixture-of-Experts-model skal holde hver ekspert i VRAM, så dens hukommelse sættes af det totale parameterantal. Tallet for aktive parametre beskriver kun inferenshastigheden. GLM-5.2 kører med hastigheden af en 40B-model, men har brug for hukommelsen af en 744B-model.

Er unified memory det samme som VRAM?

Funktionelt, for indlæsning af modeller, ja. Apple Silicon og nogle andre systemer deler én memory-pool mellem CPU og GPU, så en 128 GB Mac kan indlæse modeller, der ellers ville kræve flere diskrete GPU'er. Handlen er båndbredde: unified memory leverer normalt lavere peak throughput end en high-end datacenter-GPU, så tokens-per-sekund er lavere.

Kan jeg offloade en del af en model til system-RAM eller CPU?

Ja. Motorer som llama.cpp og Ollama lader dig beholde nogle lag på GPU'en og resten i system-RAM med et flag som --n-gpu-layers. Det lader dig køre en model, der er for stor til din VRAM, men hvert lag på CPU'en sænker generationen markant, så brug det til at gøre en model mulig, ikke hurtig.

Hvordan beregner jeg VRAM til en model, der ikke er i tabellen?

Gang parameterantallet i milliarder med bits-per-vægt for din kvantisering, og divider derefter med 8. For Q4_K_M brug ca. 4,5 bits, så en 40B-model har brug for 40 × 4,5 ÷ 8 = ca. 22,5 GB til vægtene. Tilføj cirka 15-20 % overhead plus din KV-cache for det reelle krav.