Quanta VRAM serve per eseguire Llama 70B?

La VRAM necessaria dipende da tre fattori: quanti parametri ha il modello, quanti byte occupa ciascun parametro (quantizzazione) e quanta memoria di lavoro consuma il contesto (KV cache). I primi due danno l'ingombro dei pesi; aggiungi il terzo e hai il requisito reale. Questa guida calcola tutti e tre per i modelli classe Llama-70B — e ti dà il metodo per qualsiasi modello.

Il 70B a ogni livello di quant

Solo pesi — aggiungi KV-cache e ~1–2GB di overhead di runtime prima di decidere cosa "entra". Un 70B a IQ2 su una singola scheda da 24GB è un numero da circo, non un uso quotidiano: qualità e contesto soffrono entrambi.

La formula di sizing (qualsiasi modello denso)

VRAM (GB) ≈ parametri(B) × byte/peso × 1.15

Byte/peso ≈ 0,5–0,6 (4-bit), 1 (8-bit), 2 (FP16). Il ×1,15 copre l'overhead di runtime e un contesto modesto. Esempi:

• 7B @ 4-bit ≈ 4GB — gira su una scheda da 8GB. 13B @ 4-bit ≈ 7,5GB.
• 34B @ 4-bit ≈ 20GB (entra in 24GB con margine per il contesto).
• 70B @ 4-bit ≈ 40GB di pesi → ~44–48GB con un contesto di lavoro.
• 123B @ 4-bit ≈ 70GB → fascia 80GB; MoE 8×22B: vedi la sezione MoE.

La KV-cache, con numeri veri

Ogni token nel contesto memorizza chiavi e valori di attenzione per ogni layer. La formula:

Byte KV ≈ 2 × layer × kv_head × head_dim × byte × token

Per un modello classe Llama-70B (80 layer, GQA con 8 KV head, head_dim 128) a FP16 sono ~320 KB per token — ~2,6GB a 8k di contesto, ~10GB a 32k, ~40GB a 128k. A 128k la cache rivaleggia con gli stessi pesi Q4. Tre conseguenze pratiche:

• Due setup che eseguono "lo stesso 70B" possono richiedere VRAM molto diverse. Un chatbot a contesto 4k sta comodo in 48GB; un carico di analisi documentale a 128k vuole 80GB+ o una gestione aggressiva della cache.
• Quantizza la cache. La KV-cache Q8 dimezza quei numeri a costo di qualità trascurabile (llama.cpp --cache-type-k/v q8_0, cache FP8 di vLLM). È il contesto più economico che comprerai mai.
• La concorrenza moltiplica la cache. Ogni richiesta parallela ha il suo contesto: 10 sessioni concorrenti da 8k ≈ 26GB di cache FP16 oltre ai pesi. Nel dimensionare un server, cache × utenti è spesso il vincolo reale, non i pesi.

Nota positiva: le architetture moderne usano la grouped-query attention (GQA) proprio per ridurre tutto questo — i vecchi 70B senza GQA avevano cache ~8× più grandi. Quando valuti un modello nuovo, controlla la sua KV-cache-per-token, non solo il numero di parametri.

Se non entra: il precipizio dell'offloading

llama.cpp può tenere parte dei layer nella RAM di sistema ed eseguirli su CPU (--n-gpu-layers). Funziona — ma capisci la curva di velocità prima di pianificarci sopra. Poiché ogni token deve attraversare tutti i layer, i layer lenti su CPU strozzano l'intera pipeline:

• 100% su GPU: un 70B Q4 su 48GB ≈ 15–20 tok/s (dipende dalla banda).
• ~80% su GPU: già circa dimezzato.
• ~50% su GPU: ~3–5 tok/s — usabile per batch, doloroso in chat.
• Quasi tutto CPU (64GB DDR): 1–2 tok/s. Tecnicamente gira; in pratica è una demo.

Tratta l'offloading come un ponte (provare un modello prima di comprare hardware) o uno strumento da batch — non il piano di produzione. Se sei cronicamente in offloading, le soluzioni oneste sono: un quant più piccolo, un modello più piccolo, la quantizzazione della KV-cache, o più VRAM.

Modelli MoE: una regola di sizing diversa

I modelli Mixture-of-Experts pubblicizzano due numeri — parametri totali e attivi — e la VRAM segue il totale: tutti gli esperti devono essere residenti anche se solo alcuni si attivano per token. Un MoE "120B totali / 12B attivi" richiede memoria da ~120B (≈65–70GB a 4-bit) ma genera circa alla velocità di un 12B, perché per token si leggono solo i parametri attivi. Questo rende i MoE superbi per macchine con molta memoria unificata (Mac Studio, grandi rig multi-GPU): capacità enorme, poca banda per token. Regola: metti a budget la VRAM sui parametri totali, prevedi la velocità su quelli attivi.

Percorsi hardware per il 70B, con velocità attese

• Singola 80GB (A100/H100) — la soluzione pulita: Q4 con contesto molto lungo, o Q8. 25–40+ tok/s. Ideale in produzione; spesso conviene noleggiarla che possederla (vedi sotto).
• Singola 48GB (classe RTX A6000) — Q4_K_M con contesto moderato su una scheda silenziosa. ~12–18 tok/s. Il setup di proprietà più semplice.
• 2×24GB (doppia 3090/4090) — il classico percorso economico: layer-split via llama.cpp (~13–18 tok/s) o tensor-parallel via vLLM/ExLlama (più veloce). Richiede alimentatore grosso e flusso d'aria, ma costa circa metà di una scheda da 48GB.
• Mac Studio (96–192GB unificati) — contiene un 70B a Q5–Q8 con contesto gigante, in silenzio. ~7–12 tok/s in generazione: usabile, non veloce. La migliore opzione "niente rack in ufficio".
• 80GB a noleggio a ore — per bisogni occasionali di 70B, il noleggio batte il possesso con ampio margine (vedi la matematica dell'utilizzo nella guida ai costi).

Errori comuni di sizing

• Dimensionare solo sui pesi. "Modello da 40GB, scheda da 48GB, fatto" — poi la prima richiesta a 32k va in OOM. Budget = pesi + cache + overhead.
• Ignorare la concorrenza. Una scheda che serve comodamente un utente può andare in OOM a cinque. La cache scala per utente.
• Inseguire il quant più grande che tecnicamente si carica. Un Q5 che lascia 500MB liberi frammenterà e crasherà nell'uso reale; lascia il 10–15% di margine.
• Assumere che tutti i 70B siano uguali. La dimensione della KV-cache varia con l'architettura (GQA o no); controlla la model card.
• Pianificare sull'offloading. Il precipizio è reale — vedi sopra.