Quantizzazione GGUF: che livello usare?

Di default scegli Q4_K_M; passa a Q6_K o Q8_0 quando hai VRAM da spendere e ti serve l’ultimo piccolo incremento di qualità. La quantizzazione GGUF comprime i pesi di un modello da 16 bit a meno — Q4_K_M memorizza circa 4.85 bit per peso, così un modello 7B scende da ~14 GB a ~4.1 GB con una perplexity tipicamente meno dell’1% peggiore dell’originale. La domanda «che quantizzazione gguf usare» ha una risposta stabile fino alla noia, che la maggior parte del dramma online offusca. Qui sotto: cosa fa davvero la quantizzazione ai pesi, quanto costa in qualità ogni livello, come fare i conti delle dimensioni da solo, e un comando per misurare il danno sul tuo hardware invece di fidarti del benchmark di uno sconosciuto.

Cosa fa davvero la quantizzazione GGUF?

Un modello viene addestrato in virgola mobile a 16 bit (FP16 o BF16): ognuno dei suoi miliardi di pesi è un numero da 2 byte. La quantizzazione comprime ogni peso in meno bit. Il modo ingenuo — arrotondare ogni peso a un intero a 4 bit — distrugge i valori piccoli ma importanti, così GGUF usa due trucchi:

1. Block scaling. I pesi sono raggruppati in blocchi (di solito 32), e ogni blocco ha il suo fattore di scala. I valori a 4 bit sono offset dentro quel blocco, così sopravvive un ampio intervallo di magnitudini.
2. K-quant sensibili all’importanza. La «K» in Q4_K_M indica super-blocchi di scale, più un trattamento diverso per i layer di attenzione e feed-forward, perché tollerano la compressione in modo diseguale.

La famiglia «I» (IQ4_XS e simili) va oltre, con codebook di teoria dell’informazione presi in prestito dalla compressione delle immagini. Stessa idea, codifica più raffinata: meno bit per peso a qualità simile, al prezzo di un’inferenza leggermente più lenta su alcuni backend.

Una precisazione che evita la maggior parte della confusione: la quantizzazione cambia solo i pesi memorizzati. Architettura, tokenizer e gestione del contesto restano intatti. Un file Q4 e un file Q8 dello stesso modello sono lo stesso modello con cappotti diversi.

Q4 vs Q8: una quantizzazione più alta è meglio?

Sì, tecnicamente; no, percettivamente. Prendendo come riferimento le misure di perplexity di llama.cpp stesso sui modelli Llama: Q8_0 resta entro ~0.02% da FP16 — per qualunque scopo pratico, lossless. Q6_K è quasi indistinguibile. Q4_K_M guadagna circa l’1–2% di perplexity, Q4_0 un po’ di più, e Q2_K è dove le risposte coerenti iniziano a sfaldarsi sui modelli piccoli.

Due regole che i numeri implicano:

• La dimensione del modello compra margine di quantizzazione. Un modello 70B sopravvive a Q2/Q3 molto meglio di un 7B, perché i modelli più grandi sono più ridondanti. Quantizzare un 7B a Q2 è un’amputazione; quantizzare un 70B a Q3 è sartoria.
• Il pavimento di qualità si sposta col task. La chat tollera Q4. Generazione di codice esatto, matematica e RAG su documenti precisi espongono prima il rumore di quantizzazione. Se un modello Q4 continua a scrivere codice sottilmente sbagliato, prova lo stesso modello a Q6_K prima di incolpare il modello.

Livello	Bit/peso	Peso vs FP16	Perdita di qualità	Usalo quando
Q2_K	~3.4	~21%	Grave sotto i 13B	Quando non c’è alternativa, solo modelli grandi
Q3_K_M	~3.9	~25%	Percettibile	VRAM stretta, modelli ≥14B
Q4_K_S	~4.6	~29%	Piccola	Q4_K_M non entra e ci sei vicino
Q4_K_M	~4.85	~30%	~1% di perplexity	Il default. Miglior compromesso qualità/peso
Q5_K_M	~5.7	~35%	~0.5%	VRAM disponibile, task critici sulla qualità
Q6_K	~6.6	~41%	Quasi nulla	Codice/matematica, entra ancora comodamente
Q8_0	~8.5	~53%	Effettivamente nessuna	Run di riferimento, basi per fine-tune
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M un filo troppo grande, il backend supporta gli i-quant

Quanta VRAM serve per ogni livello?

Fai i conti da solo invece di imparare le tabelle a memoria — è una riga:

size_GB ≈ (bits_per_weight × params) / 8
# modello 8B @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# modello 8B @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Poi aggiungi le parti che la formula lascia fuori: la KV cache (cresce con la lunghezza del contesto — da qualche centinaio di MB a più GB), le attivazioni e i compute buffer. Margine pratico: un modello «da 4.9 GB» vuole una scheda da 6 GB a contesto 4k, e flash-attention più quantizzazione della KV cache per restarci a 16k. I pesi fanno il titolo, non l’intero conto.

Quale quantizzazione GGUF dovresti usare?

Ordine decisionale, senza eccezioni da imparare a memoria:

1. Calcola prima il budget contesto + KV, poi i pesi. Un contesto che non ci sta è peggio di una qualità che non riesci a misurare.
2. Default a Q4_K_M. È il default della community per un motivo — circa l’1% di perplexity per il 70% della dimensione. Ogni registro, Ollama incluso, lo spedisce come baseline.
3. Sali a Q6_K quando il task punisce il rumore: codice, matematica, estrazione, qualsiasi cosa mandi in pipeline senza supervisione.
4. Q8_0 solo per riferimento — test A/B, misura del danno da quantizzazione, o base per un fine-tune. Come daily driver comprare soprattutto calore nei sensori della tua VRAM.
5. Sotto Q4 solo sotto costrizione, e solo su modelli grandi. Prova con un prompt notoriamente difficile prima di fidarti.

Se stai scegliendo quale file scaricare da Hugging Face, preferisci un singolo Q4_K_M.gguf agli split a shard, a meno che chi carica non spedisca solo quelli — meno parti mobili. E se stai scegliendo dove eseguirlo, la scelta del motore è un altro discorso: vedi llama.cpp vs Ollama per quell’asse.

Come misuri da solo il danno della quantizzazione?

I benchmark variano; il tuo prompt è costante. Compili llama.cpp una volta, scarichi due livelli dello stesso modello e misuri sia la perplexity (più bassa è meglio) sia i token/secondo:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# perplexity su un pezzo di wiki-text (più bassa = più vicino al modello originale)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# e la velocità sullo stesso hardware
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Il numero di Q4_K_M sarà di qualche centesimo di punto peggiore di Q8_0 e il file sarà ~40% più piccolo. Se il tuo task a valle non sente la differenza — e per la maggior parte non la sente — hai la tua risposta senza leggere la leaderboard di nessuno.

La quantizzazione danneggia la privacy o le dichiarazioni di «solo locale»?

No — è aritmetica sui pesi, completamente offline, e il file quantizzato è solo un contenitore più piccolo degli stessi parametri. Un Q4_K_M in locale disperde esattamente quanto (o poco quanto) il modello a precisione piena in locale: nulla lascia la macchina. La variabile che conta per la privacy è dove gira l’inferenza, non la larghezza di bit. I consueti avvertimenti sulla provenienza dei modelli valgono allo stesso modo per ogni livello di quant: un fine-tune «uncensored» con base rubata in Q8 non è più sicuro degli stessi pesi in Q4. Per il lato formato file, vedi come eseguire modelli GGUF in locale.

Che livello dovresti scegliere?

Q4_K_M, e smetti di leggere forum in proposito. Passa a Q6_K per il lavoro affamato di precisione se la VRAM lo consente, tieni un Q8_0 in giro per i confronti A/B, e tratta tutto ciò che sta sotto Q4 come una razione d’emergenza solo per modelli grandi. L’unico errore che vale la pena evitare è simmetrico: preoccuparsi di Q4 contro Q5 ignorando la lunghezza del contesto, che ha rovinato più setup locali di qualsiasi quant abbia mai fatto.