Requisiti VRAM per gli LLM: la tabella master 2026 (ogni modello, ogni quantizzazione)

Requisiti VRAM per gli LLM: la tabella master 2026 (ogni modello, ogni quantizzazione)

Ecco il numero che spiazza tutti: DeepSeek-V3.2 ha 671 miliardi di parametri, ma solo 37 miliardi si attivano per ogni token. Quindi quanta VRAM serve davvero? Tutti i 671 miliardi, circa 382 GB a Q4. I requisiti VRAM degli LLM raramente seguono l'intuito, e il divario tra "parametri attivi" e "quello che devi caricare" è esattamente dove i budget hardware esplodono. Questa guida ti dà la tabella master (ogni modello open principale, ogni livello di quantizzazione, la cifra in GB e la GPU che lo fa girare) più la formula per dimensionare qualsiasi modello da solo in circa dieci secondi.

Punti Chiave

• La VRAM per i pesi ≈ parametri × byte per parametro: FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Aggiungi la KV cache e circa il 15-20% di overhead.
• I modelli Mixture-of-Experts (DeepSeek, GLM-5.2, Qwen3-235B) devono caricare in VRAM ogni singolo esperto. I "parametri attivi" comprano velocità, non memoria.
• La KV cache è il costo nascosto. Llama 3.3 70B richiede circa 2.6 GB di cache con un contesto di 8K e circa 41 GB a 128K, in aggiunta ai pesi.
• Q4_K_M è la scelta di default più sensata: qualità quasi piena a circa un quarto dell'ingombro di FP16.
• Un modello da 12B come Gemma 4 entra in una scheda da 8 GB a Q4. Un modello denso da 70B richiede circa 40 GB. Un MoE di frontiera da 671B richiede un piccolo server.

Requisiti VRAM degli LLM per modello: la tabella master

La risposta breve: a Q4_K_M, i modelli piccoli (sotto i 14B) entrano in schede consumer da 8-12 GB, i modelli di medie dimensioni (24-32B) vogliono 16-24 GB, un modello denso da 70B richiede circa 40 GB, e i modelli MoE di frontiera saltano a centinaia di gigabyte perché ogni esperto deve restare residente in memoria. Ecco il quadro completo in un unico posto. Tutte le cifre rappresentano solo la memoria per i pesi, calcolata dal numero di parametri di ciascun modello e verificata sulle schede ufficiali di Meta AI, Qwen e Hugging Face.

Due cose da notare in questa tabella. Primo, la quantizzazione è la leva più potente a tua disposizione: passare da FP16 a Q4 taglia l'ingombro di circa 4 volte con una perdita di qualità quasi impercettibile. Secondo, le righe MoE sembrano brutali perché lo sono davvero. Qwen3-30B-A3B attiva solo 3B di parametri per token, quindi gira alla velocità di un modello minuscolo, ma devi comunque tenere tutti i 30B in memoria per avere ogni esperto pronto all'uso. Vuoi i dettagli modello per modello dietro questi numeri? I nostri approfondimenti su Gemma 4 12B e la rassegna dei migliori LLM open source del 2026 coprono benchmark e licenze.

La formula della VRAM: calcola qualsiasi modello da solo

Per dimensionare qualsiasi modello, moltiplica il numero di parametri per i byte-per-parametro della tua quantizzazione, poi aggiungi un po' per la KV cache e l'overhead di runtime. Tutto qui. I pesi sono il termine dominante, e l'aritmetica è abbastanza semplice da fare a mente.

L'equazione di base per i pesi:

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

I valori di bit-per-peso di cui hai bisogno (questi sono i tassi effettivi per i file GGUF k-quant, che portano un po' di metadati a blocchi sopra la profondità di bit nominale):

Esempio pratico, Gemma 4 12B a Q4_K_M: 11.95 × 4.5 ÷ 8 = circa 6.7 GB per i pesi. Questo valore coincide con i circa 6.6 GB indicati dalla scheda ufficiale del modello e spiega perché entra in una scheda da 8 GB lasciando spazio per un contesto modesto. Fai lo stesso calcolo per un modello da 70B a Q4 e ottieni 70 × 4.5 ÷ 8 = 39.4 GB, motivo per cui "servono due schede da 24 GB o una da 48 GB per un 70B" è la regola empirica che tutti ripetono.

Il quadro completo aggiunge altri due termini: VRAM totale ≈ pesi + KV cache + ~15-20% overhead. L'overhead copre i buffer di attivazione, il contesto CUDA e la frammentazione della memoria, e la tua GPU riserva anche mezzo gigabyte o giù di lì per il driver, quindi non pianificare mai di usare il 100% della VRAM dichiarata.

Perché la KV cache è il costo che ti frega

La KV cache memorizza le chiavi e i valori di attenzione per ogni token già presente nel contesto, e cresce in modo lineare con la lunghezza del contesto. Su prompt brevi è un errore di arrotondamento. Spingiti verso un contesto lungo e può rivaleggiare o superare i pesi stessi. Questo è il motivo più comune per cui un modello che "dovrebbe entrarci" lancia un errore di memoria esaurita a metà generazione.

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

Prendi Llama 3.3 70B: 80 layer, 8 head KV, dimensione della head 128, quindi kv_dim è 1024. A FP16 fa 80 × 2 × 1024 × 2 = 327,680 byte per token, circa 0.31 MB. Moltiplica per la lunghezza del contesto e la storia si scrive da sola: a 8K token la cache è di circa 2.6 GB, a 32K è circa 10 GB, e a 128K sale fino a circa 41 GB. Quest'ultima cifra si somma ai 40 GB di pesi, quindi un "modello da 40 GB" diventa silenziosamente un problema da 80 GB nel momento in cui riempi la finestra di contesto.

Due vie d'uscita pratiche. La grouped-query attention (che ogni modello recente usa) riduce già kv_dim rispetto al vecchio design multi-head, quindi i modelli moderni sono molto più clementi su questo fronte rispetto a Llama 2. E la maggior parte dei motori di inferenza può quantizzare la KV cache a 8 bit o 4 bit, dimezzando o riducendo a un quarto la sua dimensione con un piccolo costo in qualità. Se stai servendo contesti lunghi in produzione, il confronto tra vLLM e SGLang copre quale backend gestisce questa memoria in modo più efficiente con la paged attention.

Modelli MoE: perché i "parametri attivi" non risparmiano VRAM

Questa è la trappola che costa più soldi alla gente. Un modello Mixture-of-Experts come DeepSeek-V3.2 (671B totali, 37B attivi, con l'architettura V3) o GLM-5.2 (744B totali, 40B attivi) instrada ogni token attraverso un piccolo sottoinsieme dei suoi esperti. Il marketing punta sul numero di parametri attivi perché descrive la velocità: paghi solo il costo computazionale di 37B di parametri per token, quindi l'inferenza è veloce per la dimensione del modello. Ma ogni esperto deve restare in memoria, pronto per essere selezionato, il che significa che il tuo budget di VRAM è determinato dal numero totale di parametri, non da quello attivo.

Quindi la lettura onesta della tabella qui sopra è questa: GLM-5.2 gira alla velocità di un modello da 40B ma occupa la memoria di uno da 744B. Ecco perché questi modelli open di frontiera hanno bisogno di un server con 8 GPU o di una macchina con grande memoria unificata, anche se un singolo forward pass è economico. Qwen3-235B-A22B ha la stessa forma su scala più piccola: veloce per token, pesante da ospitare.

Il vantaggio del MoE emerge sull'hardware a memoria unificata. Un Mac Studio con 512 GB di memoria unificata può ospitare un modello da 671B a Q4 e comunque farlo girare a velocità utilizzabili, proprio perché si attivano solo 37B, quindi la richiesta di banda di memoria per token resta ragionevole. Se sei alle prime armi con l'esecuzione locale, parti dalla nostra guida per eseguire un LLM in locale prima di spendere in hardware.

Quale quantizzazione dovresti scegliere?

Per quasi tutti, Q4_K_M è la scelta di default giusta: mantiene una qualità quasi piena tagliando l'ingombro di FP16 di circa 4 volte. Sali a Q5_K_M o Q8 solo se hai VRAM di scorta e un caso d'uso sensibile alla qualità, e ricorri a FP16 solo quando fai fine-tuning o benchmark contro un riferimento. Sotto Q4, il degrado di qualità diventa evidente in fretta, quindi Q3 e livelli inferiori sono un'ultima spiaggia per far entrare un modello in una scheda davvero troppo piccola.

Un avvertimento: la qualità della quantizzazione non è identica tra i vari modelli. I modelli molto piccoli (sotto i 4B) risentono di più di Q4 rispetto a quelli grandi, perché hanno meno ridondanza da cui attingere. Su un modello da 70B, distinguere Q4 da Q8 è difficile nella maggior parte dei task. Su un modello da 1.7B, il divario è reale.

Di quale GPU hai davvero bisogno?

Abbina la colonna Q4 della tabella master a una scheda con un po' di margine per la KV cache. Ecco la mappatura pratica dall'hardware consumer economico fino al data center, con la fascia di modelli che ogni classe fa girare comodamente a Q4.

Apple Silicon merita una menzione speciale perché la memoria unificata cambia i calcoli. Un Mac non separa la VRAM dalla RAM di sistema, quindi una macchina serie M da 128 GB può caricare modelli che richiederebbero più GPU discrete, scambiando il throughput di picco con la capacità di far entrare pesi enormi su un solo desktop. Per i backend che tirano fuori il massimo da ognuna di queste schede, la nostra rassegna dei migliori strumenti per eseguire LLM in locale confronta le differenze di velocità nel mondo reale.

Come dimensioniamo la VRAM per i deployment dei clienti

In Techsy distribuiamo modelli open per i clienti abbastanza spesso da far sì che il dimensionamento della VRAM sia la prima conversazione, prima della scelta del modello, prima dei prompt, prima di qualsiasi altra cosa. Il nostro metodo è volutamente noioso, perché il modo in cui si fallisce (un OOM in produzione sotto carico di contesto reale) costa caro. Ecco il processo che seguiamo davvero.

Partiamo dal calcolo della tabella, poi misuriamo. Dopo aver caricato un modello controlliamo l'ingombro reale in memoria invece di fidarci della stima:

# 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

La lezione che si ripete sempre: i team dimensionano per i pesi e si dimenticano la KV cache, poi si chiedono perché un modello che si caricava benissimo muore dopo tre richieste lunghe in una demo. Noi dimensioniamo per i pesi più la KV cache al contesto massimo che l'app userà davvero, più un margine, e limitiamo --ctx-size così una richiesta fuori controllo non può mandare in OOM la macchina. Per qualsiasi cosa rivolta ai clienti preferiamo far girare un 32B quantizzato che non si pianta mai piuttosto che un 70B FP16 che va in OOM sotto carico.

Se stai valutando se ospitare tu stesso un modello open o restare su un'API in hosting, quel compromesso (costo dell'hardware e carico operativo contro prezzo per token e controllo) è esattamente ciò che il nostro team analizza durante un progetto di integrazione AI. Se ti aiuterebbe avere qualcuno che fa i calcoli sul tuo carico di lavoro reale, richiedi una consulenza gratuita e li dimensioniamo insieme a te.

Chi è l'autore

Mert Batur è Co-Founder di Techsy.io, dove il team realizza agenti AI, sistemi di automazione e pipeline voice/SDR per clienti B2B. Scrive dello stack di strumenti LLM che il team Techsy usa davvero in produzione.

Credenziali: Co-Founder, Techsy.io. Connettiti su LinkedIn.

Domande Frequenti

Quanta VRAM serve per eseguire un modello da 70B?

Un modello denso da 70B come Llama 3.3 70B richiede circa 40 GB di VRAM per i pesi a Q4_K_M, quindi metti in conto una scheda da 48 GB (RTX 6000 Ada) o due schede da 24 GB. Aggiungi qualche GB in più per la KV cache se usi un contesto lungo, il che spinge i requisiti pratici verso i 48 GB o più.

Quanta VRAM serve per Llama, Qwen o DeepSeek?

Dipende interamente dalla variante. Llama 4 Scout richiede circa 62 GB a Q4, Qwen3-32B circa 18 GB, e Qwen3-8B meno di 5 GB. DeepSeek-V3.2, un MoE da 671B, richiede circa 382 GB perché ogni esperto deve essere caricato. Per i modelli MoE, controlla sempre il numero totale di parametri, non quello attivo.

Posso eseguire un LLM su una GPU da 8GB?

Sì, comodamente. Una scheda da 8 GB come una RTX 4060 fa girare modelli fino a circa 12B di parametri a Q4_K_M. Gemma 4 12B entra in circa 6.8 GB, lasciando spazio per un contesto modesto. Per qualsiasi cosa più grande devi quantizzare di più, tenere il contesto corto, oppure passare a una scheda più grande.

Cosa può far girare una GPU da 24GB come la RTX 4090?

Una scheda da 24 GB gestisce modelli densi fino a circa 32B a Q4_K_M con margine per un contesto ragionevole, quindi Qwen3-32B e Mistral Small 3.2 24B sono comodi. Fa girare anche il MoE Qwen3-30B-A3B, che carica 30B di pesi ma genera alla velocità di un modello da 3B grazie all'attivazione sparsa.

La quantizzazione danneggia la qualità del modello?

A Q4_K_M e livelli superiori, la perdita di qualità è piccola e spesso impercettibile su task reali, specialmente per modelli sopra i 13B. Il divario si allarga man mano che scendi e man mano che i modelli si fanno più piccoli, quindi Q4 su un 70B è quasi gratuito mentre Q4 su un 1.7B si nota. Q8 è praticamente senza perdite se hai la memoria.

I modelli MoE hanno bisogno di meno VRAM rispetto ai modelli densi?

No, ed è il fraintendimento più comune. Un modello Mixture-of-Experts deve tenere ogni esperto in VRAM, quindi la sua memoria è determinata dal numero totale di parametri. La cifra dei parametri attivi descrive solo la velocità di inferenza. GLM-5.2 gira alla velocità di un modello da 40B ma richiede la memoria di uno da 744B.

La memoria unificata è la stessa cosa della VRAM?

Dal punto di vista funzionale, per caricare i modelli, sì. Apple Silicon e altri sistemi condividono un unico pool di memoria tra CPU e GPU, quindi un Mac da 128 GB può caricare modelli che altrimenti richiederebbero più GPU discrete. Il compromesso è la banda: la memoria unificata di solito offre un throughput di picco inferiore rispetto a una GPU da data center di fascia alta, quindi i token al secondo sono più bassi.

Posso scaricare parte di un modello sulla RAM di sistema o sulla CPU?

Sì. Motori come llama.cpp e Ollama ti permettono di tenere alcuni layer sulla GPU e il resto nella RAM di sistema con un flag come --n-gpu-layers. Questo ti permette di far girare un modello troppo grande per la tua VRAM, ma ogni layer sulla CPU rallenta drasticamente la generazione, quindi usalo per rendere un modello possibile, non veloce.

Come calcolo la VRAM per un modello che non è in tabella?

Moltiplica il numero di parametri in miliardi per i bit-per-peso della tua quantizzazione, poi dividi per 8. Per Q4_K_M usa circa 4.5 bit, quindi un modello da 40B richiede 40 × 4.5 ÷ 8 = circa 22.5 GB per i pesi. Aggiungi circa il 15-20% di overhead più la tua KV cache per il requisito reale.