Cerințe VRAM pentru LLM: Tabelul Master 2026 (Fiecare Model, Fiecare Cuantizare)

Cerințe VRAM pentru LLM: Tabelul Master 2026 (Fiecare Model, Fiecare Cuantizare)

Iată numărul care îi ia pe toți prin surprindere: DeepSeek-V3.2 are 671 de miliarde de parametri, dar doar 37 de miliarde se activează pentru orice token dat. Deci, de cât VRAM are nevoie realmente? De valoarea tuturor celor 671 de miliarde, adică aproximativ 382 GB la Q4. Cerințele VRAM pentru LLM rareori urmează intuiția, iar decalajul dintre „parametrii activi” și „ceea ce trebuie să încarci” este exact locul unde bugetele hardware explodează. Acest ghid îți oferă tabelul master (fiecare model open-source major, fiecare nivel de cuantizare, cifra în GB și GPU-ul care îl rulează), plus formula pentru a dimensiona singur orice model în aproximativ zece secunde.

Principalele Concluzii

• VRAM pentru ponderi ≈ parametri × octeți-per-parametru: FP16 = 2,0, Q8 = 1,0, Q5_K_M ≈ 0,68, Q4_K_M ≈ 0,57. Adaugă cache-ul KV și un overhead de ~15-20% peste acestea.
• Modelele Mixture-of-Experts (DeepSeek, GLM-5.2, Qwen3-235B) trebuie să încarce fiecare expert în VRAM. „Parametrii activi” îți oferă viteză, nu economie de memorie.
• Cache-ul KV este costul ascuns. Llama 3.3 70B are nevoie de aproximativ 2,6 GB de cache la un context de 8K și de roughly 41 GB la 128K, în plus față de ponderi.
• Q4_K_M este implicitul sensibil: calitate aproape completă la aproximativ un sfert din amprenta FP16.
• Un model de 12B precum Gemma 4 se potrivește pe o placă video de 8 GB la Q4. Un model dens de 70B are nevoie de aproximativ 40 GB. Un MoE de frontieră de 671B are nevoie de un server mic.

Cerințe VRAM pentru LLM pe Model: Tabelul Master

Răspunsul scurt: la Q4_K_M, modelele mici (sub 14B) se potrivesc pe plăci video consumer de 8-12 GB, modelele de dimensiuni medii (24-32B) doresc 16-24 GB, un model dens de 70B are nevoie de aproximativ 40 GB, iar modelele MoE de frontieră sar în sute de gigaocteți deoarece fiecare expert trebuie să fie rezident. Iată imaginea completă într-un singur loc. Toate cifrele reprezintă memoria doar pentru ponderi, calculată din numărul de parametri al fiecărui model și verificată încrucișat cu fișele tehnice oficiale de la Meta AI, Qwen și Hugging Face.

Două lucruri de observat în acest tabel. În primul rând, cuantizarea este cea mai mare pârghie pe care o ai: trecerea de la FP16 la Q4 reduce amprenta de aproximativ 4 ori, cu o scădere a calității abia perceptibilă. În al doilea rând, rândurile MoE arată brutal pentru că așa sunt. Qwen3-30B-A3B activează doar 3B parametri per token, deci rulează cu viteza unui model mic, dar tot trebuie să ții toți cei 30B în memorie pentru a avea fiecare expert gata de utilizare. Vrei detaliile model cu model din spatele acestor numere? Aprofundarea noastră despre Gemma 4 12B și lista celor mai bune LLM-uri open-source din 2026 acoperă benchmark-urile și licențele.

Formula VRAM: Calculează Singur Pentru Orice Model

Pentru a dimensiona orice model, înmulțește numărul de parametri cu octeții-per-parametru pentru cuantizarea ta, apoi adaugă puțin pentru cache-ul KV și overhead-ul de runtime. Asta e tot. Ponderile sunt termenul dominant, iar aritmetica este suficient de simplă pentru a fi făcută pe dosul unui șervețel.

Ecuația de bază pentru ponderi:

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

Valorile de biți-per-ponderi de care ai nevoie (acestea sunt ratele efective pentru fișierele GGUF k-quant, care poartă puțin metadate de bloc în plus față de adâncimea nominală în biți):

Exemplu concret, Gemma 4 12B la Q4_K_M: 11,95 × 4,5 ÷ 8 = aproximativ 6,7 GB pentru ponderi. Aceasta corespunde cu cei aproximativ 6,6 GB citați în fișa tehnică oficială și explică de ce se potrivește pe o placă de 8 GB cu loc pentru un context modest. Fă același calcul pentru un model de 70B la Q4 și obții 70 × 4,5 ÷ 8 = 39,4 GB, motiv pentru care „ai nevoie de două plăci de 24 GB sau una de 48 GB pentru un model de 70B” este regula pe care toată lumea o repetă.

Imaginea completă adaugă încă doi termeni: VRAM total ≈ ponderi + cache KV + ~15-20% overhead. Overhead-ul acoperă bufferele de activare, contextul CUDA și fragmentarea memoriei, iar GPU-ul tău rezervă, de asemenea, aproximativ jumătate de gigaoctet pentru driver, așa că nu planifica niciodată să folosești 100% din VRAM-ul declarat.

De Ce Cache-ul KV Este Numărul Care Te Lovește

Cache-ul KV stochează cheile și valorile de atenție pentru fiecare token deja prezent în context și crește liniar cu lungimea contextului. La prompturi scurte, este o eroare de rotunjire. Împinge către un context lung și poate rivaliza sau chiar depăși ponderile în sine. Acesta este cel mai frecvent motiv pentru care un model care „ar trebui să se potrivească” aruncă o eroare de memorie insuficientă (out-of-memory) la mijlocul generării.

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

Să luăm Llama 3.3 70B: 80 de straturi, 8 capete KV, dimensiunea capului 128, deci kv_dim este 1024. La FP16, asta înseamnă 80 × 2 × 1024 × 2 = 327.680 octeți per token, adică aproximativ 0,31 MB. Înmulțește cu lungimea contextului și povestea se scrie singură: la 8K tokeni, cache-ul este de aproximativ 2,6 GB, la 32K este de aproximativ 10 GB, iar la 128K ajunge la aproximativ 41 GB. Această ultimă cifră este în plus față de cei 40 GB de ponderi, astfel încât un „model de 40 GB” devine tacit o problemă de 80 GB în momentul în care umpli fereastra.

Două soluții practice. Atenția cu interogare grupată (Grouped-query attention), pe care o folosește fiecare model recent, reduce deja kv_dim comparativ cu vechea arhitectură multi-head, astfel încât modelele moderne sunt mult mai blânde aici decât era Llama 2. Și majoritatea motoarelor de inferență pot cuantiza cache-ul KV la 8-bit sau 4-bit, înjumătățind sau sfertuindu-i dimensiunea pentru un cost mic de calitate. Dacă servești contexte lungi în producție, comparația vLLM vs SGLang acoperă care backend gestionează această memorie cel mai eficient cu atenție paginată.

Modele MoE: De Ce „Parametrii Activi” Nu Salvează VRAM

Aceasta este capcana care costă oamenii cei mai mulți bani. Un model Mixture-of-Experts precum DeepSeek-V3.2 (671B total, 37B activi, împărtășind arhitectura V3) sau GLM-5.2 (744B total, 40B activi) rutează fiecare token printr-un subset mic din experții săi. Marketingul se bazează pe numărul activ deoarece descrie viteza: plătești doar computația pentru 37B parametri per token, deci inferența este rapidă pentru dimensiunea modelului. Dar fiecare expert trebuie să stea în memorie, gata să fie ales, ceea ce înseamnă că bugetul tău de VRAM este stabilit de numărul total de parametri, nu de cel activ.

Așadar, citirea onestă a tabelului de mai sus: GLM-5.2 rulează cu viteza unui model de 40B, dar ocupă memoria unuia de 744B. De aceea aceste modele open-source de frontieră au nevoie de un server cu 8 GPU-uri sau de o mașină cu memorie unificată mare, chiar dacă o singură trecere înainte (forward pass) este ieftină. Qwen3-235B-A22B are aceeași formă la o scară mai mică, rapid per token, greu de găzduit.

Avantajul MoE apare pe hardware-ul cu memorie unificată. Un Mac Studio cu 512 GB de memorie unificată poate ține un model de 671B la Q4 și îl poate rula la viteze utilizabile tocmai pentru că se activează doar 37B, astfel încât cererea de lățime de bandă a memoriei per token rămâne rezonabilă. Dacă ești nou în rularea acestora local, începe cu ghidul nostru de configurare LLM local înainte de a cheltui pe hardware.

Ce Cuantizare Ar Trebuie Să Alegi?

Pentru aproape toată lumea, Q4_K_M este implicitul corect: menține o calitate aproape completă în timp ce reduce amprenta FP16 de aproximativ 4 ori. Treci la Q5_K_M sau Q8 doar dacă ai VRAM liber și o sarcină sensibilă la calitate, și apelează la FP16 doar când faci fine-tuning sau benchmarking față de o referință. Sub Q4, degradarea calității devine vizibilă rapid, astfel încât Q3 și nivelurile inferioare sunt o ultimă soluție pentru a înghesui un model pe o placă video care este genuin prea mică.

O notă: calitatea cuantizării nu este identică între modele. Modelele foarte mici (sub 4B) simt mai tare Q4 decât cele mari, deoarece au mai puțină redundanță de sacrificat. La un model de 70B, diferența dintre Q4 și Q8 este greu de distins în majoritatea sarcinilor. La un model de 1,7B, decalajul este real.

De Ce GPU Ai Nevoie Realmente?

Potrivește coloana Q4 din tabelul master cu o placă video cu puțin spațiu suplimentar pentru cache-ul KV. Iată maparea practică de la hardware consumer bugetar până la data center, cu tier-ul de model pe care fiecare clasă îl rulează confortabil la Q4.

Apple Silicon merită o mențiune specială deoarece memoria unificată schimbă calculul. Un Mac nu separă VRAM-ul de RAM-ul sistemului, astfel încât o mașină M-series de 128 GB poate încărca modele care ar necesita multiple GPU-uri discrete, făcând un compromis între throughput-ul de vârf și capacitatea de a potrivi ponderi uriașe pe un singur desktop. Pentru backend-urile care stoarcă maximul din oricare dintre aceste plăci, lista noastră cu cele mai bune tool-uri pentru rularea LLM-urilor local compară diferențele de viteză din lumea reală.

Cum Dimensionăm VRAM pentru Implementările Clienților

La Techsy implementăm modele open-source pentru clienți suficient de des încât dimensionarea VRAM este prima conversație, înainte de alegerea modelului, înainte de prompturi, înainte de orice. Metoda noastră este plictisitoare în mod intenționat, deoarece modul de eșec (o eroare OOM în producție sub sarcină reală de context) este costisitor. Iată procesul pe care îl aplicăm efectiv.

Pornim de la matematica din tabel, apoi măsurăm. După încărcarea unui model, verificăm amprenta rezidentă reală în loc să ne bazăm pe estimare:

# 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

Lecția care se repetă constant: echipele dimensionează pentru ponderi și uită de cache-ul KV, apoi se întreabă de ce un model care s-a încărcat bine cedează după trei cereri lungi într-o demonstrație. Noi dimensionăm pentru ponderi plus cache-ul KV la contextul maxim pe care aplicația îl va folosi realmente, plus spațiu suplimentar, și limităm --ctx-size astfel încât o cerere scăpată de sub control să nu blocheze cutia cu OOM. Pentru orice orientat către client, preferăm să rulăm un model de 32B cuantizat care nu cedează niciodată, decât unul de 70B FP16 care dă OOM sub sarcină.

Dacă cântărești dacă să găzduiești singur un model open-source sau să rămâi pe un API găzduit, acel compromis (cost hardware și povară operațională versus preț per token și control) este exact ceea ce echipa noastră analizează durante unei integrări AI. Dacă ți-ar fi de ajutor ca cineva să calculeze cifrele pentru sarcina ta de lucru actuală, obține o consultație gratuită și le vom dimensiona împreună cu tine.

Despre Autor

Mert Batur Gurbuz este Co-fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voice/SDR pentru clienți B2B. El studiază la University of Birmingham și scrie despre stiva de tool-uri LLM pe care echipa Techsy o folosește efectiv în producție.

Credențiale: Co-fondator, Techsy.io, University of Birmingham. Conectează-te pe LinkedIn.

Întrebări Frecvente

De cât VRAM am nevoie pentru a rula un model de 70B?

Un model dens de 70B precum Llama 3.3 70B are nevoie de aproximativ 40 GB de VRAM pentru ponderi la Q4_K_M, așa că planifică pentru o placă de 48 GB (RTX 6000 Ada) sau două plăci de 24 GB. Adaugă câțiva gigaocteți în plus pentru cache-ul KV dacă folosești un context lung, ceea ce împinge cerințele practice către 48 GB sau mai mult.

De cât VRAM are nevoie Llama, Qwen sau DeepSeek?

Depinde în totalitate de variantă. Llama 4 Scout are nevoie de aproximativ 62 GB la Q4, Qwen3-32B de aproximativ 18 GB, iar Qwen3-8B sub 5 GB. DeepSeek-V3.2, un MoE de 671B, are nevoie de aproximativ 382 GB deoarece fiecare expert trebuie încărcat. Verifică întotdeauna numărul total de parametri, nu pe cel activ, pentru modelele MoE.

Pot rula un LLM pe un GPU de 8GB?

Da, confortabil. O placă de 8 GB, cum ar fi un RTX 4060, rulează modele de până la aproximativ 12B parametri la Q4_K_M. Gemma 4 12B se potrivește în aproximativ 6,8 GB, lăsând loc pentru un context modest. Pentru anything mai mare, fie cuantizezi mai agresiv, fie păstrezi contextul scurt, fie treci la o placă mai mare.

Ce poate rula un GPU de 24GB precum RTX 4090?

O placă de 24 GB gestionează modele dense de până la aproximativ 32B la Q4_K_M cu spațiu pentru un context rezonabil, astfel încât Qwen3-32B și Mistral Small 3.2 24B sunt confortabile. Rulează, de asemenea, MoE-ul Qwen3-30B-A3B, care încarcă 30B de ponderi, dar generează cu viteza unui model de 3B datorită activării sparse.

Cuantizarea afectează calitatea modelului?

La Q4_K_M și peste, pierderea de calitate este mică și adesea imperceptibilă în sarcini reale, în special pentru modele peste 13B. Decalajul se lărgește pe măsură ce cobori și pe măsură ce modelele devin mai mici, astfel încât Q4 pe un model de 70B este aproape gratuit, în timp ce Q4 pe unul de 1,7B este vizibil. Q8 este practic fără pierderi dacă ai memoria necesară.

Modelele MoE au nevoie de mai puțin VRAM decât modelele dense?

Nu, iar aceasta este cea mai frecventă concepție greșită. Un model Mixture-of-Experts trebuie să țină fiecare expert în VRAM, astfel încât memoria sa este stabilită de numărul total de parametri. Cifra parametrilor activi descrie doar viteza de inferență. GLM-5.2 rulează cu viteza unui model de 40B, dar are nevoie de memoria unuia de 744B.

Memoria unificată este la fel cu VRAM-ul?

Funcțional, pentru încărcarea modelelor, da. Apple Silicon și unele alte sisteme partajează un pool unic de memorie între CPU și GPU, astfel încât un Mac de 128 GB poate încărca modele care altfel ar necesita multiple GPU-uri discrete. Compromisul este lățimea de bandă: memoria unificată livrează de obicei un throughput de vârf mai mic decât un GPU high-end de data center, astfel încât tokenii-pe-secundă sunt mai puțini.

Pot descărca o parte din model în RAM-ul sistemului sau pe CPU?

Da. Motoare precum llama.cpp și Ollama îți permit să păstrezi unele straturi pe GPU și restul în RAM-ul sistemului cu un flag precum --n-gpu-layers. Îți permite să rulezi un model prea mare pentru VRAM-ul tău, dar fiecare strat de pe CPU încetinește brusc generarea, așa că folosește-l pentru a face un model posibil, nu rapid.

Cum calculez VRAM pentru un model care nu este în tabel?

Înmulțește numărul de parametri în miliarde cu biții-per-ponderi pentru cuantizarea ta, apoi împarte la 8. Pentru Q4_K_M folosește aproximativ 4,5 biți, deci un model de 40B are nevoie de 40 × 4,5 ÷ 8 = aproximativ 22,5 GB pentru ponderi. Adaugă aproximativ 15-20% overhead plus cache-ul KV pentru cerința reală.