LLM:n VRAM-vaatimukset: Vuoden 2026 master-taulukko (jokainen malli, jokainen kvantisointi)

LLM:n VRAM-vaatimukset: Vuoden 2026 master-taulukko (jokainen malli, jokainen kvantisointi)

Tässä on luku, joka yllättää kaikki: DeepSeek-V3.2:ssa on 671 miljardia parametria, mutta vain 37 miljardia aktivoituu millä tahansa yksittäisellä tokenilla. Joten kuinka paljon VRAM-muistia se todella tarvitsee? Kaikki 671 miljardia, eli noin 382 Gt Q4-kvantisoinnilla. LLM:n VRAM-vaatimukset harvoin seuraavat intuitiota, ja kuilu ”aktiivisten parametrien” ja ”ladattavan datan” välillä on juuri se kohta, jossa laitteistobudjetit räjähtävät käsiin. Tämä opas antaa sinulle master-taulukon (jokainen merkittävä avoin malli, jokainen kvantisointitaso, gigatavut ja sen suorittava GPU) sekä kaavan minkä tahansa mallin koon laskemiseen itse noin kymmenessä sekunnissa.

Keskeiset havainnot

• Painojen VRAM ≈ parametrit × tavua/parametri: FP16 = 2,0, Q8 = 1,0, Q5_K_M ≈ 0,68, Q4_K_M ≈ 0,57. Lisää päälle KV-välimuisti ja noin 15–20 %:n yleiskustannus.
• Asiantuntijasekoitusmallien (Mixture-of-Experts, kuten DeepSeek, GLM-5.2, Qwen3-235B) on ladattava kaikki asiantuntijat VRAMiin. ”Aktiiviset parametrit” tuovat nopeutta, ei muistinsäästöä.
• KV-välimuisti on piilokustannus. Llama 3.3 70B tarvitsee noin 2,6 Gt välimuistia 8K:n kontekstilla ja noin 41 Gt 128K:n kontekstilla painojen lisäksi.
• Q4_K_M on järkevä oletusarvo: lähes täysi laatu noin neljäsosalla FP16:n muistijalanjäljestä.
• 12B:n malli, kuten Gemma 4, mahtuu 8 Gt:n kortille Q4-kvantisoinnilla. 70B:n tiheä malli tarvitsee noin 40 Gt. 671B:n huipputason MoE-malli vaatii pienen palvelimen.

LLM:n VRAM-vaatimukset mallikohtaisesti: Master-taulukko

Lyhyt vastaus: Q4_K_M-kvantisoinnilla pienet mallit (alle 14B) mahtuvat kuluttajatason 8–12 Gt:n korteille, keskikokoiset mallit (24–32B) kaipaavat 16–24 Gt, 70B:n tiheä malli tarvitsee noin 40 Gt, ja huipputason MoE-mallit hyppäävät satoihin gigatavuihin, koska jokaisen asiantuntijan on oltava muistissa. Tässä on koko kuva yhdessä paikassa. Kaikki luvut ovat vain painojen muistinkulutusta, laskettu kunkin mallin parametrimäärästä ja tarkistettu virallisia mallikortteja vasten lähteistä Meta AI, Qwen ja Hugging Face.

Taulukosta voi päätellä kaksi asiaa. Ensinnäkin, kvantisointi on suurin vipuvarsi: pudotus FP16:sta Q4:ään leikkaa muistijalanjäljen noin neljäsosaan laadun tuskin havaittavalla heikkenemisellä. Toiseksi, MoE-rivit näyttävät raaoilta, koska ne ovat sitä. Qwen3-30B-A3B aktivoi vain 3B parametria per token, joten se pyörii pienen mallin nopeudella, mutta sinun on silti pidettävä kaikki 30B muistissa, jotta jokainen asiantuntija on valmiina. Haluatko mallikohtaiset yksityiskohdat näiden lukujen takaa? Gemma 4 12B syväluotaus ja vuoden 2026 parhaat avoimen lähdekoodin LLM:t kattavat benchmarkit ja lisenssit.

VRAM-kaava: Laske minkä tahansa mallin koko itse

Minkä tahansa mallin koon arvioimiseksi kerro sen parametrimäärä kvantisointisi tavuilla/parametri ja lisää hieman KV-välimuistille ja ajonaikaiselle yleiskustannukselle. Siinä kaikki. Painot ovat hallitseva tekijä, ja aritmetiikka on tarpeeksi yksinkertaista tehtäväksi servietin takapuolelle.

Ydin yhtälö painoille:

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

Tarvittavat bitit/paino-arvot (nämä ovat GGUF k-quant -tiedostojen tehollisia arvoja, jotka sisältävät hieman lohkometadataa nimellisbittisyvyyden päälle):

Laskuesimerkki, Gemma 4 12B Q4_K_M:llä: 11,95 × 4,5 ÷ 8 = noin 6,7 Gt painoille. Tämä vastaa virallisen mallikortin mainitsemaa noin 6,6 Gt:a ja selittää, miksi se mahtuu 8 Gt:n kortille tilaa jääden vielä kohtuulliselle kontekstille. Tee sama lasku 70B:n mallille Q4:llä, ja saat 70 × 4,5 ÷ 8 = 39,4 Gt, mikä on syy siihen, miksi ”tarvitset kaksi 24 Gt:n korttia tai yhden 48 Gt:n kortin 70B:n malliin” on yleinen sääntö.

Kokonaiskuvaan lisätään kaksi termiä: kokonais-VRAM ≈ painot + KV-välimuisti + ~15–20 % yleiskustannus. Yleiskustannus kattaa aktivointipuskurit, CUDA-kontekstin ja muistifragmentaation, ja GPU varaa myös noin puoli gigatavua ajurille, joten älä koskaan suunnittele käyttäväsi 100 %:a ilmoitetusta VRAMista.

Miksi KV-välimuisti on luku, joka puree

KV-välimuisti tallentaa attention-avaimet ja -arvot jokaiselle kontekstissa jo olevalle tokenille, ja se kasvaa lineaarisesti kontekstin pituuden myötä. Lyhyillä kehotteilla se on pyöristysvirhe. Pitkässä kontekstissa se voi kuitenkin kilpailla tai jopa ylittää itse painojen koon. Tämä on yleisin syy siihen, miksi malli, jonka ”pitäisi mahtua”, heittää muistinylitysvirheen kesken generoinnin.

Kaava 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)

Otetaan esimerkki Llama 3.3 70B: 80 kerrosta, 8 KV-headia, head-dimensio 128, joten kv_dim on 1024. FP16:lla tämä on 80 × 2 × 1024 × 2 = 327 680 tavua per token, noin 0,31 Mt. Kerro kontekstin pituudella, ja tarina kirjoittaa itsensä: 8K tokeneilla välimuisti on noin 2,6 Gt, 32K:lla noin 10 Gt ja 128K:lla se paisuu noin 41 Gt:iin. Viimeksi mainittu luku on 40 Gt:n painojen päälle, joten ”40 Gt:n mallista” tulee hiljaa 80 Gt:n ongelma heti, kun ikkuna täyttyy.

Kaksi käytännöllistä pakoreittiä. Ryhmitetty kyselyattention (Grouped-query attention), jota kaikki uusimmat mallit käyttävät, pienentää jo kv_dimiä verrattuna vanhaan multi-head-suunnitteluun, joten modernit mallit ovat tässä suhteessa ystävällisempiä kuin Llama 2. Lisäksi useimmat inferenssimoottorit voivat kvantisoida KV-välimuistin 8-bittiseksi tai 4-bittiseksi, puolittaen tai neljännekseen sen koon pienellä laatumaksulla. Jos tarjoat pitkiä konteksteja tuotannossa, vLLM vs SGLang -vertailu käsittelee, mikä backend hallinnoi tätä muistia tehokkaimmin sivutetun attentionin avulla.

MoE-mallit: Miksi ”aktiiviset parametrit” eivät säästä VRAMia

Tämä on ansa, joka maksaa ihmisille eniten rahaa. Asiantuntijasekoitusmalli (Mixture-of-Experts), kuten DeepSeek-V3.2 (671B yhteensä, 37B aktiivisia, jakaa V3-arkkitehtuurin) tai GLM-5.2 (744B yhteensä, 40B aktiivisia), reitittää jokaisen tokenin pienen osajoukon asiantuntijoidensa kautta. Markkinointi nojaa aktiiviseen lukuun, koska se kuvaa nopeutta: maksat vain 37B parametrin verran laskentaa per token, joten inferenssi on nopeaa mallin kokoon nähden. Mutta jokaisen asiantuntijan on istuttava muistissa, valmiina valittavaksi, mikä tarkoittaa, että VRAM-budjettisi määräytyy kokonaisparametrimäärän, ei aktiivisen määrän, perusteella.

Joten taulukon rehellinen tulkinta: GLM-5.2 pyörii 40B:n mallin nopeudella, mutta vie 744B:n muistin. Siksi nämä huipputason avoimet mallit tarvitsevat 8-GPU-palvelimen tai suuren unified-memory-koneen, vaikka yksittäinen forward-pass on halpa. Qwen3-235B-A22B on sama rakenne pienemmässä mittakaavassa, nopea per token, raskas isännöidä.

MoE:n etu näkyy unified-memory-laitteistossa. Mac Studio, jossa on 512 Gt unified memoryä, voi pitää 671B:n mallia Q4-kvantisoinnilla ja silti ajaa sitä käyttökelpoisella nopeudella, koska vain 37B aktivoituu, joten muistikaistan vaatimus per token pysyy kohtuullisena. Jos olet uusi paikallisessa ajamisessa, aloita paikallisen LLM:n asennusoppaastamme ennen laitteistohankintoja.

Minkä kvantisoinnin pitäisi valita?

Lähes kaikille Q4_K_M on oikea oletusarvo: se säilyttää lähes täyden laadun samalla kun leikkaa FP16:n jalanjäljen noin neljäsosaan. Nouse Q5_K_M:ään tai Q8:aan vain, jos sinulla on ylimääräistä VRAMia ja laatuherkkä tehtävä, ja turvaudu FP16:een vain hienosäädössä tai vertaillessasi viitearvoon. Alle Q4:n laadun heikkeneminen tulee huomattavaksi nopeasti, joten Q3 ja alempaat ovat viimeinen keino mahduttaa malli kortille, joka on aidosti liian pieni.

Yksi varoitus: kvantisoinnin laatu ei ole identtinen eri malleissa. Erittäin pienet mallit (alle 4B) tuntevat Q4:n voimakkaammin kuin suuret, koska niillä on vähemmän redundanssia varattavaksi. 70B:n mallissa Q4:n ja Q8:n eroa on vaikea erottaa useimmissa tehtävissä. 1,7B:n mallissa ero on todellinen.

Mitä GPU:ta todella tarvitset?

Sovita master-taulukon Q4-sarja korttiin, jossa on hieman pelivaraa KV-välimuistille. Tässä on käytännön kartoitus budjettikuluttajalaitteistosta datakeskukseen, ja mallitaso, jonka kukin luokka ajaa mukavasti Q4:llä.

Apple Silicon ansaitsee erityismaininnan, koska unified memory muuttaa laskukaavaa. Mac ei jaa VRAMia ja järjestelmämuistia, joten 128 Gt:n M-sarjan kone voi ladata malleja, jotka vaatisivat useita erillisiä GPU:ita, vaihtaen huippuläpäisykyvyn kykyyn mahduttaa valtavat painot yhdelle työpöytäkonelle. Backendeista, jotka puristavat eniten irti näistä korteista, parhaat työkalut LLM:n ajamiseen paikallisesti -katsauksemme benchmarkkaa todelliset nopeuserot.

Miten mitoitamme VRAMin asiakasasennuksissa

Techsyssä asennamme avoimia malleja asiakkaille niin usein, että VRAMin mitoitus on ensimmäinen keskustelunaihe, ennen mallin valintaa, ennen kehotteita, ennen mitään. Menetelmämme on tarkoituksellisen tylsä, koska epäonnistumismuoto (OOM tuotannossa todellisella kontekstikuormalla) on kallis. Tässä on prosessi, jonka todella ajamme.

Aloitamme taulukkolaskennasta, sitten mittaamme. Kun malli on ladattu, tarkistamme todellisen residentin jalanjäljen luottamatta arvioon:

# 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

Toistuva oppitunti: tiimit mitoittavat painot ja unohtavat KV-välimuistin, ihmetellen sitten, miksi malli, joka latautui hyvin, kuolee kolmen pitkän pyynnön jälkeen demossa. Mitoitamme painot plus KV-välimuistin sovelluksen maksimikontekstilla, plus pelivara, ja rajoitamme --ctx-size:n, jottei hallitsematon pyyntö aiheuta OOM-virhettä. Kaikille asiakaskohtaamisille mieluummin ajamme kvantisoitua 32B:tä, joka ei koskaan kaadu, kuin FP16 70B:tä, joka saa OOM-virhan kuormituksen alla.

Jos punnitset avoimen mallin itse-isännöintiä versus hostatun API:n käyttöä, tuo kompromissi (laitteistokustannus ja operatiivinen taakka versus per-token-hinnoittelu ja kontrolli) on juuri sitä, mitä tiimimme kartoittaa AI-integraatioprojektissa. Jos olisi hyödyllistä, että joku laskee luvut todellista workloadiasi vasten, varo ilmainen konsultaatio ja mitoitamme sen kanssasi.

Kirjoittajasta

Mert Batur Gurbuz on Techsy.io:n co-founder, jossa tiimi toimittaa AI-agentteja, automaatiojärjestelmiä ja voice/SDR-pipelineja B2B-asiakkaille. Hän opiskelee Birminghamin yliopistossa ja kirjoittaa LLM-työkalupakista, jota Techsyn tiimi todella käyttää tuotannossa.

Referenssit: Co-Founder, Techsy.io, Birminghamin yliopisto. Yhdistä LinkedInissä.

Usein kysytyt kysymykset

Kuinka paljon VRAMia tarvitsen 70B:n mallin ajamiseen?

70B:n tiheä malli, kuten Llama 3.3 70B, tarvitsee noin 40 Gt VRAMia painoille Q4_K_M:llä, joten varaudu 48 Gt:n korttiin (RTX 6000 Ada) tai kahteen 24 Gt:n korttiin. Lisää useita gigatavuja KV-välimuistille, jos käytät pitkää kontekstia, mikä nostaa käytännön vaatimukset kohti 48 Gt tai enemmän.

Kuinka paljon VRAMia Llama, Qwen tai DeepSeek tarvitsee?

Se riippuu täysin variantista. Llama 4 Scout tarvitsee noin 62 Gt Q4:llä, Qwen3-32B noin 18 Gt ja Qwen3-8B alle 5 Gt. DeepSeek-V3.2, 671B MoE, tarvitsee noin 382 Gt, koska jokainen asiantuntija on ladattava. Tarkista aina kokonaisparametrimäärä, ei aktiivinen, MoE-malleissa.

Voinko ajaa LLM:ää 8 Gt:n GPU:lla?

Kyllä, mukavasti. 8 Gt:n kortti, kuten RTX 4060, ajaa malleja jopa noin 12B parametria Q4_K_M:llä. Gemma 4 12B mahtuu noin 6,8 Gt:iin, jättäen tilaa kohtuulliselle kontekstille. Mitään suurempaa varten joko kvantisoi kovempaa, pidä konteksti lyhyenä tai siirry isompaan korttiin.

Mitä 24 Gt:n GPU, kuten RTX 4090, pystyy ajamaan?

24 Gt:n kortti käsittelee tiheitä malleja jopa noin 32B asti Q4_K_M:llä tilaa jääden kohtuulliselle kontekstille, joten Qwen3-32B ja Mistral Small 3.2 24B ovat mukavia. Se ajaa myös Qwen3-30B-A3B MoE:n, joka lataa 30B painoja mutta generoi 3B:n mallin nopeudella harvan aktivoinnin ansiosta.

Heikentääkö kvantisointi mallin laatua?

Q4_K_M:ssä ja ylöspäin laadun menetys on pieni ja usein havaitsematon todellisissa tehtävissä, erityisesti malleissa, jotka ovat yli 13B. Kuilu levenee, mitä alemmas mennään ja mitä pienemmiksi mallit tulevat, joten Q4 70B:ssä on lähes ilmaista, kun taas Q4 1,7B:ssä on huomattavaa. Q8 on käytännössä häviötön, jos muistia riittää.

Tarvitsevatko MoE-mallit vähemmän VRAMia kuin tiheät mallit?

Eivät, ja tämä on yleisin väärinkäsitys. Asiantuntijasekoitusmallin on pidettävä kaikki asiantuntijat VRAMissa, joten sen muisti määräytyy kokonaisparametrimäärän perusteella. Aktiivisten parametrien luku kuvaa vain inferenssinopeutta. GLM-5.2 pyörii 40B:n mallin nopeudella, mutta tarvitsee 744B:n muistin.

Onko unified memory sama kuin VRAM?

Toiminnallisesti, mallien lataamisessa, kyllä. Apple Silicon ja jotkin muut järjestelmät jakavat yhden muistipoolin CPU:n ja GPU:n välillä, joten 128 Gt:n Mac voi ladata malleja, jotka muuten vaatisivat useita erillisiä GPU:ita. Kompromissi on kaistanleveys: unified memory tarjoaa yleensä alhaisemman huippuläpäisykyvyn kuin huipputason datakeskus-GPU, joten tokeneita sekunnissa on vähemmän.

Voinko siirtää osan mallista järjestelmämuistiin tai CPU:hun?

Kyllä. Moottorit kuten llama.cpp ja Ollama antavat sinun pitää osan kerroksista GPU:lla ja loput järjestelmämuistissa lipulla kuten --n-gpu-layers. Sen avulla voit ajaa mallia, joka on liian suuri VRAMILlesi, mutta jokainen CPU:lla oleva kerros hidastaa generointia jyrkästi, joten käytä sitä tekemään mallista mahdollinen, ei nopea.

Miten lasken VRAMin mallille, jota ei ole taulukossa?

Kerro parametrimäärä miljardeissa kvantisointisi biteillä/paino ja jaa 8:lla. Q4_K_M:lle käytä noin 4,5 bittiä, joten 40B:n malli tarvitsee 40 × 4,5 ÷ 8 = noin 22,5 Gt painoille. Lisää noin 15–20 % yleiskustannus plus KV-välimuistisi todelliseen vaatimukseen.