VRAM-krav för LLM: Den kompletta 2026-tabellen (alla modeller, alla kvantiseringar)

VRAM-krav för LLM: Den kompletta 2026-tabellen (alla modeller, alla kvantiseringar)

Här är siffran som får alla att haja till: DeepSeek-V3.2 har 671 miljarder parametrar, men bara 37 miljarder aktiveras för en given token. Så hur mycket VRAM behöver den egentligen? Alla 671 miljarder värda, ungefär 382 GB vid Q4. VRAM-krav för LLM följer sällan intuitionen, och gapet mellan "aktiva parametrar" och "vad du faktiskt måste ladda" är exakt där hårdvarubudgetar spricker. Den här guiden ger dig mastertabellen (varje större öppen modell, varje kvantiseringsnivå, GB-talet och GPU:n som kör den) plus formeln för att räkna ut storleken på vilken modell som helst själv på ungefär tio sekunder.

Nyckelinsikter

• VRAM för vikterna ≈ parametrar × byte per parameter: FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Lägg till KV-cache och ~15-20% overhead ovanpå det.
• Mixture-of-Experts-modeller (DeepSeek, GLM-5.2, Qwen3-235B) måste ladda varje expert i VRAM. "Aktiva parametrar" ger dig hastighet, inte minne.
• KV-cache är den dolda kostnaden. Llama 3.3 70B behöver ungefär 2.6 GB cache vid 8K kontext och runt 41 GB vid 128K, ovanpå vikterna.
• Q4_K_M är det förnuftiga standardvalet: nästan full kvalitet på ungefär en fjärdedel av FP16:s minnesavtryck.
• En 12B-modell som Gemma 4 får plats på ett 8 GB-kort vid Q4. En 70B tät modell behöver ungefär 40 GB. En 671B frontier-MoE behöver en liten server.

LLM VRAM-krav per modell: Mastertabellen

Kort svar: vid Q4_K_M får små modeller (under 14B) plats på konsument-GPU:er med 8-12 GB, mellanstora modeller (24-32B) vill ha 16-24 GB, en 70B tät modell behöver ungefär 40 GB, och frontier-MoE-modellerna hoppar upp i hundratals gigabyte eftersom varje expert måste finnas i minnet. Här är hela bilden på ett ställe. Alla siffror är minnet för enbart vikterna, beräknat från varje modells parameterantal och kontrollerat mot de officiella modellkorten från Meta AI, Qwen och Hugging Face.

Två saker att läsa ut ur tabellen. För det första: kvantisering är den största spaken du har. Att gå från FP16 till Q4 sänker minnesavtrycket med ungefär 4x med en knappt märkbar kvalitetsförsämring. För det andra: MoE-raderna ser brutala ut eftersom de är det. Qwen3-30B-A3B aktiverar bara 3B parametrar per token, så den körs i samma hastighet som en liten modell, men du måste ändå hålla alla 30B i minnet för att ha varje expert redo. Vill du ha modell-för-modell-detaljerna bakom de här siffrorna? Vår djupdykning i Gemma 4 12B och sammanställningen av de bästa öppna LLM:erna 2026 täcker benchmarks och licenser.

VRAM-formeln: Räkna ut vilken modell som helst själv

För att räkna ut storleken på vilken modell som helst multiplicerar du parameterantalet med byte per parameter för din kvantisering, och lägger sedan till lite för KV-cache och runtime-overhead. Det är allt. Vikterna är den dominerande termen, och matematiken är enkel nog att göra på baksidan av ett kuvert.

Grundekvationen för vikterna:

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

Bitar-per-vikt-värdena du behöver (de här är de effektiva talen för GGUF k-quant-filer, som bär lite blockmetadata utöver det nominella bitdjupet):

Räkneexempel, Gemma 4 12B vid Q4_K_M: 11.95 × 4.5 ÷ 8 = ungefär 6.7 GB för vikterna. Det stämmer bra med de ungefär 6.6 GB som det officiella modellkortet anger och förklarar varför den får plats på ett 8 GB-kort med utrymme kvar för lite kontext. Gör samma räkning för en 70B-modell vid Q4 och du får 70 × 4.5 ÷ 8 = 39.4 GB, vilket är anledningen till att "du behöver två 24 GB-kort eller ett 48 GB-kort för en 70B" är tumregeln alla upprepar.

Hela bilden lägger till två termer: total VRAM ≈ vikter + KV-cache + ~15-20% overhead. Overheaden täcker aktiveringsbuffertar, CUDA-kontexten och minnesfragmentering, och din GPU reserverar dessutom en halv gigabyte eller så åt drivrutinen, så räkna aldrig med att använda 100% av den utlovade VRAM-mängden.

Varför KV-cache är siffran som biter dig

KV-cachen lagrar attention-nycklarna och -värdena för varje token som redan finns i kontexten, och den växer linjärt med kontextlängden. Vid korta prompter är den ett avrundningsfel. Går du mot en lång kontext kan den matcha eller till och med överstiga vikterna själva. Det här är den enskilt vanligaste anledningen till att en modell som "borde få plats" kastar ett minnesfel mitt i genereringen.

Formeln, 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 lager, 8 KV-huvuden, huvuddimension 128, så kv_dim blir 1024. Vid FP16 blir det 80 × 2 × 1024 × 2 = 327,680 byte per token, ungefär 0.31 MB. Multiplicera med kontextlängden och historien skriver sig själv: vid 8K token är cachen ungefär 2.6 GB, vid 32K är den ungefär 10 GB, och vid 128K sväller den till runt 41 GB. Den sista siffran är ovanpå de 40 GB vikter, så en "40 GB-modell" blir tyst och stilla ett 80 GB-problem i samma stund du fyller fönstret.

Två praktiska utvägar. Grouped-query attention (som alla nya modeller använder) skär redan ner kv_dim jämfört med den gamla multi-head-designen, så moderna modeller är betydligt snällare här än Llama 2 var. Och de flesta inferensmotorer kan kvantisera KV-cachen till 8-bit eller 4-bit, vilket halverar eller fyrdubblar minskningen av storleken för en liten kvalitetskostnad. Om du serverar långa kontexter i produktion täcker jämförelsen mellan vLLM och SGLang vilken backend som hanterar det här minnet mest effektivt med paged attention.

MoE-modeller: Varför "aktiva parametrar" inte sparar VRAM

Det här är fällan som kostar folk mest pengar. En Mixture-of-Experts-modell som DeepSeek-V3.2 (671B totalt, 37B aktiva, delar V3-arkitekturen) eller GLM-5.2 (744B totalt, 40B aktiva) routar varje token genom en liten delmängd av sina experter. Marknadsföringen lutar sig mot det aktiva talet eftersom det beskriver hastighet: du betalar bara beräkning motsvarande 37B parametrar per token, så inferensen är snabb i förhållande till modellens storlek. Men varje expert måste ligga i minnet, redo att väljas, vilket innebär att din VRAM-budget sätts av det totala parameterantalet, inte det aktiva.

Så den ärliga tolkningen av tabellen ovan: GLM-5.2 körs i samma hastighet som en 40B-modell men upptar minnet av en 744B-modell. Det är därför de här frontier-öppna modellerna behöver en server med 8 GPU:er eller en stor maskin med unified memory, trots att en enda forward-pass är billig. Qwen3-235B-A22B har samma mönster i mindre skala: snabb per token, tung att hosta.

Fördelen med MoE syns på hårdvara med unified memory. En Mac Studio med 512 GB unified memory kan hålla en 671B-modell vid Q4 och ändå köra den i användbara hastigheter, just eftersom bara 37B aktiveras, så minnesbandbreddskravet per token förblir rimligt. Om du är ny på att köra de här lokalt, börja med vår guide till att köra LLM lokalt innan du spenderar pengar på hårdvara.

Vilken kvantisering ska du välja?

För nästan alla är Q4_K_M rätt standardval: den håller nästan full kvalitet samtidigt som den sänker FP16-avtrycket med ungefär 4x. Gå upp till Q5_K_M eller Q8 bara om du har VRAM över och en kvalitetskänslig uppgift, och ta till FP16 bara när du finjusterar eller benchmarkar mot en referens. Under Q4 blir kvalitetsförsämringen snabbt märkbar, så Q3 och lägre är en sista utväg för att pressa in en modell på ett kort som verkligen är för litet.

En brasklapp: kvantiseringens kvalitetspåverkan är inte densamma för alla modeller. Väldigt små modeller (under 4B) märker av Q4 mer än stora modeller, eftersom de har mindre redundans att avvara. På en 70B-modell är Q4 kontra Q8 svårt att skilja åt i de flesta uppgifter. På en 1.7B-modell är skillnaden verklig.

Vilken GPU behöver du egentligen?

Matcha Q4-kolumnen i mastertabellen mot ett kort med lite marginal för KV-cache. Här är den praktiska mappningen från budget-hårdvara för konsumenter upp till datacentret, med den modellklass varje kategori kör bekvämt vid Q4.

Apple Silicon förtjänar ett särskilt omnämnande eftersom unified memory ändrar kalkylen. En Mac delar inte upp VRAM och system-RAM, så en 128 GB M-seriemaskin kan ladda modeller som annars skulle kräva flera diskreta GPU:er, mot att du byter bort topphastighet för förmågan att få plats med enorma vikter på ett enda skrivbord. För de backends som pressar ut mest av vilket som helst av de här korten benchmarkar vår sammanställning av de bästa verktygen för att köra LLM lokalt de verkliga hastighetsskillnaderna.

Så här dimensionerar vi VRAM för kunddriftsättningar

På Techsy driftsätter vi öppna modeller åt kunder tillräckligt ofta för att VRAM-dimensionering ska vara det första samtalet, före modellval, före prompter, före allt annat. Vår metod är avsiktligt trist, eftersom felläget (en OOM i produktion under verklig kontextbelastning) är dyrt. Så här ser processen ut som vi faktiskt kör.

Vi börjar med tabellmatematiken och mäter sedan. Efter att vi laddat en modell kontrollerar vi det faktiska minnesavtrycket istället för att lita på uppskattningen:

# 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äxan som upprepas gång på gång: team dimensionerar för vikterna och glömmer KV-cachen, och undrar sedan varför en modell som laddades fint dör tre långa requests in i en demo. Vi dimensionerar för vikterna plus KV-cachen vid den maximala kontext appen faktiskt kommer att använda, plus marginal, och vi begränsar --ctx-size så att en request som spårar ur inte kan OOM:a maskinen. För allt som är kundvänt kör vi hellre en kvantiserad 32B som aldrig faller ihop än en FP16 70B som OOMar under belastning.

Om du väger mellan att självhosta en öppen modell eller stanna kvar på ett hostat API, är den avvägningen (hårdvarukostnad och driftbörda kontra pris per token och kontroll) precis vad vårt team kartlägger under ett AI-integrationsuppdrag. Om det skulle hjälpa att ha någon som räknar på siffrorna mot din faktiska arbetsbelastning, boka en kostnadsfri konsultation så räknar vi ut det tillsammans med dig.

Vanliga frågor

Hur mycket VRAM behöver jag för att köra en 70B-modell?

En 70B tät modell som Llama 3.3 70B behöver ungefär 40 GB VRAM för vikterna vid Q4_K_M, så räkna med ett 48 GB-kort (RTX 6000 Ada) eller två 24 GB-kort. Lägg till några gigabyte till för KV-cache om du använder en lång kontext, vilket driver de praktiska kraven mot 48 GB eller mer.

Hur mycket VRAM behöver Llama, Qwen eller DeepSeek?

Det beror helt på varianten. Llama 4 Scout behöver ungefär 62 GB vid Q4, Qwen3-32B ungefär 18 GB, och Qwen3-8B under 5 GB. DeepSeek-V3.2, en 671B MoE, behöver runt 382 GB eftersom varje expert måste laddas. Kolla alltid det totala parameterantalet, inte det aktiva, för MoE-modeller.

Kan jag köra en LLM på en 8 GB-GPU?

Ja, utan problem. Ett 8 GB-kort som RTX 4060 kör modeller upp till ungefär 12B parametrar vid Q4_K_M. Gemma 4 12B får plats på ungefär 6.8 GB, med utrymme kvar för lite kontext. För allt större får du antingen kvantisera hårdare, hålla kontexten kort, eller flytta till ett större kort.

Vad kan en 24 GB-GPU som RTX 4090 köra?

Ett 24 GB-kort klarar täta modeller upp till ungefär 32B vid Q4_K_M med marginal för en rimlig kontext, så Qwen3-32B och Mistral Small 3.2 24B är inga problem. Det kör också Qwen3-30B-A3B MoE, som laddar 30B vikter men genererar i samma hastighet som en 3B-modell tack vare gles aktivering.

Försämrar kvantisering modellkvaliteten?

Vid Q4_K_M och uppåt är kvalitetsförlusten liten och ofta omärkbar i verkliga uppgifter, särskilt för modeller över 13B. Gapet växer ju lägre du går och ju mindre modellerna blir, så Q4 på en 70B är nästan gratis medan Q4 på en 1.7B är märkbart. Q8 är i praktiken förlustfri om du har minnet.

Behöver MoE-modeller mindre VRAM än täta modeller?

Nej, och det här är det vanligaste missförståndet. En Mixture-of-Experts-modell måste hålla varje expert i VRAM, så dess minnesbehov sätts av det totala parameterantalet. Talet för aktiva parametrar beskriver bara inferenshastigheten. GLM-5.2 körs i samma hastighet som en 40B-modell men behöver minnet av en 744B-modell.

Är unified memory samma sak som VRAM?

Funktionellt, för att ladda modeller, ja. Apple Silicon och vissa andra system delar en gemensam minnespool mellan CPU och GPU, så en 128 GB Mac kan ladda modeller som annars skulle kräva flera diskreta GPU:er. Det du byter bort är bandbredd: unified memory levererar vanligtvis lägre topphastighet än en högklassig datacenter-GPU, så antalet token per sekund blir lägre.

Kan jag lasta av en del av en modell till system-RAM eller CPU?

Ja. Motorer som llama.cpp och Ollama låter dig behålla vissa lager på GPU:n och resten i system-RAM med en flagga som --n-gpu-layers. Det gör att du kan köra en modell som är för stor för din VRAM, men varje lager som ligger på CPU:n saktar ner genereringen rejält, så använd det för att göra en modell möjlig att köra, inte snabb.

Hur räknar jag ut VRAM för en modell som inte finns i tabellen?

Multiplicera parameterantalet i miljarder med bitar per vikt för din kvantisering, och dela sedan med 8. För Q4_K_M använder du ungefär 4.5 bitar, så en 40B-modell behöver 40 × 4.5 ÷ 8 = ungefär 22.5 GB för vikterna. Lägg till ungefär 15-20% overhead plus din KV-cache för det verkliga kravet.