KV cache: perché la RAM serve più del solo modello

Hai scaricato un modello da 8B in Q4, l'hai caricato in Ollama o llama.cpp, e il programma ti dice che la memoria occupata è molto più del solo peso del modello. Non è un bug: è la KV cache (key-value cache), e oggi capiamo cos'è, quanto occupa e come gestirla, con i numeri di un modello che puoi avere su un laptop.

Se vuoi il "perché" numerico della compressione del modello in sé — cosa fa la quantizzazione e dove perde qualità — l'articolo su Quantizzazione copre quel terreno. Qui parliamo di una cosa diversa: la memoria che il modello usa mentre genera, token dopo token.

Cos'è la KV cache

Un modello transformer legge un testo in "testate" (tokens) e, per ogni nuovo token, guarda quelli precedenti tramite l'attenzione. Per farlo, calcola per ogni token tre matrici: Query (Q), Key (K) e Value (V). Se ricominciasse da zero a ogni nuovo token, ricalcolerebbe K e V per tutti i token già letti: il costo crescerebbe in modo quadratico e la generazione sarebbe inutilmente lenta.

La KV cache è la scorciatoia: i valori di K e V di ogni token, una volta calcolati, vengono salvati in memoria. Quando arriva il token successivo, il modello legge la cache invece di ricalcolare. È la memoria a breve termine della conversazione: più lungo è il contesto, più spazio occupa.

Quanto spazio: la formula

La dimensione della KV cache dipende da quattro parametri che trovi nel file di configurazione del modello (il config.json su Hugging Face) e dalla precisione con cui la memorizzi:

byte per token = 2 × livelli × teste_KV × dimensione_testa × byte per valore

Il "2" sta per le due matrici, K e V. "Teste_KV" è il numero di teste usate dalla cache: nei modelli con GQA (Grouped-Query Attention) è diverso dal numero di teste di query, e in genere più piccolo — ma per la memoria totale conta sempre il numero di teste_KV. "Dimensione_testa" è la dimensione di ogni testa. "Byte per valore" è 2 per fp16, 1 per int8.

Facciamo il calcolo con numeri veri. Da config.json di Llama 3.1 8B: 32 livelli, 8 teste_KV, dimensione_testa 128, fp16.

2 × 32 × 8 × 128 × 2 = 131 072 byte = 128 KiB per token

Stesso modello, int8 per la KV cache: 65 536 byte, cioè 64 KiB per token — la metà.

Per confrontare un modello diverso, config.json di Qwen3 8B: 36 livelli, 8 teste_KV, dimensione_testa 128.

2 × 36 × 8 × 128 × 2 = 147 456 byte = 144 KiB per token (fp16)

Esempio pratico: 8B, 8K o 128K di contesto

Ora moltiplichiamo per la lunghezza del contesto, che è il moltiplicatore principale.

Llama 3.1 8B (128 KiB per token in fp16):

Contesto	Token	KV cache
8K	8 192	≈ 1,0 GiB
32K	32 768	≈ 4,0 GiB
128K	131 072	≈ 16 GiB

Qwen3 8B (144 KiB per token in fp16):

Contesto	Token	KV cache
8K	8 192	≈ 1,1 GiB
32K	32 768	≈ 4,5 GiB
128K	131 072	≈ 18 GiB

Qui sta il punto che sorprende: un modello da 8B che in Q4 pesa 5–6 GB sul disco può richiedere 20 GB di memoria totale se lo fai girare con 128K di contesto in fp16. La KV cache, a lungo contesto, pesa più del modello stesso.

Questo è il motivo per cui, quando dimenzioni la memoria necessaria per un setup, bisogna sommare pesi + KV cache + attivazioni. I pesi sono una costante (dipende dal modello e dalla quantizzazione); la KV cache è variabile (dipende dal contesto e dalla sua precisione). Se vuoi capire come leggere la VRAM richiesta per un modello, l'articolo Hardware per IA locale parte da lì.

Come si configura

Hai tre leve principali.

1. La lunghezza del contesto. È la più ovvia. In Ollama si imposta con num_ctx nel file Modell, in LM Studio è il cursore "Context length", in llama.cpp è il flag -c (per esempio -c 8192). Se non stai facendo conversazioni molto lunghe o non carichi documenti interi, 8K o 16K sono spesso più che sufficienti, e la KV cache resta sotto i 2 GiB.

2. Quantizzare la KV cache. È la leva più efficace. In llama.cpp i flag --cache-type-k e --cache-type-v permettono di memorizzare le matrici K e V in int8 (Q8_0) invece che in fp16. La metà della memoria, con una perdita di qualità trascurabile per la maggior parte dei modelli. Ollama e LM Studio hanno opzioni equivalenti nel loro pannello di configurazione. Il risultato: un contesto da 128K che in fp16 occupava 16 GiB scende a 8 GiB in Q8_0, su Llama 3.1 8B.

3. Flash Attention. Non riduce la dimensione della KV cache, ma rende il calcolo dell'attenzione più efficiente in termini di picco di memoria: invece di materializzare la matrice completa delle attese, Flash Attention la elabora a blocchi. In llama.cpp si attiva con --flash-attn (o -fa). Documentazione di llama.cpp lo descrive come un'ottimizzazione consigliata sempre che sia supportata dal backend.

GQA: perché i modelli recenti occupano meno

I modelli "vecchi" (GPT-3, Llama 2 7B) usavano MHA: ogni testa di query aveva la propria K e V, quindi il numero di teste_KV era uguale al numero di teste di query (per esempio 32). I modelli con GQA (Llama 3, Qwen3, Mistral) raggruppano più teste di query sotto un singolo gruppo K-V, riducendo il numero di teste_KV a 8 o 12. Questo non cambia il conteggio totale della memoria per token (la formula è la stessa), ma rende il decode più veloce perché il modello legge meno tensori separati dalla memoria a ogni passo.

Cosa ricordare

La KV cache non è un dettaglio di contorno: è la parte della memoria che tu controlli, perché dipende dal contesto che scegli. I pesi del modello sono fissi; la KV cache è variabile. Quando un modello non entra nella tua RAM, il primo posto dove guardare è il contesto, non il peso del modello: spesso basta ridurlo da 128K a 32K, oppure quantizzare la KV cache in int8, e il problema sparisce.

Il modello da 8B che hai sul laptop occupa 6 GB di pesi. Ma la RAM che gli servi per farlo girare bene dipende dal contesto che gli dai — e quella è la parte che puoi regolare tu, senza ricambiare hardware.

Articolo generato con IA