Scegliere la quantizzazione (Q4, Q5, Q8, FP16)

#Quantizzazione: a cosa rinunci in cambio di memoria

Un modello è un insieme di miliardi di numeri, i pesi. In FP16, ciascuno occupa 16 bit: un modello con 8 miliardi di parametri pesa circa 16 GB. La quantizzazione memorizza ogni peso usando meno bit. Secondo la documentazione dello strumento llama-quantize, questo processo riduce le dimensioni del modello e può accelerare l'inferenza, al prezzo di una perdita di precisione misurata in termini di perplessità o di divergenza di Kullback-Leibler. Il formato GGUF utilizzato da llama.cpp, Ollama e LM Studio riunisce queste varianti. La scelta giusta dipende da tre quantità: la memoria della tua scheda o del tuo Mac, le dimensioni del modello e il contesto che intendi utilizzare. Q4_K_M offre il miglior rapporto nella maggior parte dei casi, perché la perdita di qualità rimane bassa mentre le dimensioni scendono a circa il 30% di quelle in FP16.

#Decodificare i nomi: Q4_K_M, Q5_K_S, Q8_0, IQ3_XXS

Il numero (da Q2 a Q8)

Il numero nominale di bit per peso. Il valore reale è più alto, perché i tensori sensibili vengono mantenuti a una precisione superiore: Q4_K_M misura 4,89 bit per peso.

_0 e _1

Formati vecchi, con precisione uniforme. Q8_0 viene ancora utilizzato per la quasi assenza di perdita, ma Q4_0 e Q5_0 sono stati sostituiti dalle varianti K.

_K

I K-quants, più recenti, distribuiscono i bit in base all'importanza dei tensori.

S, M, L

Small, Medium, Large: a parità di numero di bit, M conserva più bit sui tensori importanti rispetto a S, quindi pesa un po' di più e perde un po' meno.

IQ

Gli I-quants, basati su una matrice di importanza: a parità di dimensioni conservano meglio la qualità a precisioni molto basse (sotto i 4 bit) e richiedono un po' più di calcolo durante la decodifica. Si basano su un file imatrix.

#Tabella decisionale: dimensioni e perdite misurate

Il README di llama-quantize pubblica, per Llama 3.1 8B, il numero di bit per peso e la dimensione di ogni formato. La libreria Ollama mostra, per lo stesso modello, le dimensioni dei file distribuiti. Le due fonti concordano approssimativamente e forniscono un ordine di grandezza applicabile ad altri modelli della stessa famiglia.

Una precisazione sull'ultima colonna: le perdite in termini di perplessità provengono da una discussione nel repository llama.cpp che riporta la tabella di aiuto dello strumento, elaborata nel 2023 su un modello da 7 miliardi di parametri. Mostrano l'ordine dei formati, non il comportamento esatto dei modelli attuali, alcuni dei quali sono più sensibili.

#Calcolare la memoria di un modello in pochi secondi

La dimensione di un file GGUF si ottiene con la seguente formula: il numero di parametri espresso in miliardi, moltiplicato per i bit per peso e diviso per otto, dà la dimensione in gigabyte. Per un 70B in Q4_K_M: 70 × 4,89 ÷ 8 ≈ 42,8 GB, come confermato dalla tabella di llama.cpp per Llama 3.1 70B (43,1 GB). Aggiungi poi la cache KV, che cresce con il contesto, e un margine per il sistema.

taille du fichier (Go) ≈ paramètres (milliards) × bits par poids ÷ 8

Exemple : 32 milliards en Q5_K_M
32 × 5,70 ÷ 8 ≈ 22,8 Go
+ cache KV (selon le contexte) + 1 à 2 Go de marge

#Come la quantizzazione influisce davvero sulla qualità

Le misure di perplessità classificano i formati in modo coerente: più bit, meno perdita. Ma la perplessità predice male le capacità specifiche. Uno studio pubblicato su arXiv a gennaio 2026 ha confrontato i formati di llama.cpp su Llama-3.1-8B-Instruct, con test di ragionamento, conoscenze e rispetto delle istruzioni: la perplessità su WikiText-2 va da 7,32 per FP16 a 8,96 per Q3_K_S, e gli autori osservano che la perplessità non è un predittore completo del comportamento nei compiti a valle. Il punteggio medio di Q5_0 nello studio supera persino leggermente quello di FP16 (69,92 % contro 69,47 %), un risultato dovuto al rumore di misura, non a un modello migliorato.

Il risultato utile riguarda il ragionamento matematico: su GSM8K, il punteggio passa da 77,63 in FP16 a 68,31 in Q3_K_S. Gli autori raccomandano di evitare la quantizzazione aggressiva a 3 bit e di preferire Q4_K_S o Q5_0 quando il carico di lavoro implica un ragionamento in più passaggi. I compiti che mettono per primi in difficoltà la quantizzazione sono quindi il calcolo, il codice e le lunghe catene di ragionamento, non la conversazione quotidiana.

Da Q8 a Q6

Differenza non misurabile in pratica nelle tabelle pubblicate.

Da Q6 a Q4_K_M

Perdita lieve, visibile soprattutto nei compiti che richiedono ragionamenti lunghi, nel codice e nelle lingue poco rappresentate.

Sotto i 4 bit

Netto calo delle capacità di ragionamento: da evitare se non per esigenze di memoria.

#Perché un file più piccolo consente anche una generazione più veloce

Le misurazioni del README di llama.cpp, effettuate su Llama 3.1 8B, illustrano un punto che le guide trascurano: la generazione del testo legge tutti i pesi attivi a ogni token, quindi dipende soprattutto dalla quantità di byte da leggere. In questa tabella, la velocità di generazione passa da circa 51 token al secondo in Q8_0 a circa 72 in Q4_K_M e a 90 in Q2_K_S. La lettura del prompt, invece, rimane stabile intorno a 800 token al secondo perché è limitata dal calcolo e non dalla memoria. Questi numeri provengono da uno specifico hardware riportato nel repository e non sono quelli della tua macchina; tieni presente la tendenza: meno bit, generazione più veloce.

Due conseguenze pratiche. Primo, passare da Q4_K_M a Q8_0 per ottenere un miglioramento impercettibile della qualità comporta una perdita di circa il 30% della velocità di generazione in queste misurazioni. Secondo, la quantizzazione dei pesi e quella della cache KV sono due impostazioni distinte: la seconda riduce la memoria necessaria per i contesti lunghi ed è trattata in una guida dedicata.

#Scegliere seguendo tre regole

1. 01
   Parti dalla tua memoria disponibile

   VRAM di una scheda NVIDIA o AMD, oppure memoria unificata di un Mac meno circa il 25% riservato al sistema. Se il modello richiede più memoria di quella disponibile, parte del calcolo viene trasferita alla CPU e la velocità cala, spesso di diverse volte.
2. 02
   Prendi il modello più grande che entra in memoria in Q4_K_M

   A parità di memoria, un modello più grande a 4 bit è generalmente migliore di uno più piccolo a 8 bit. È una regola empirica ampiamente condivisa, da verificare sulle tue attività, soprattutto per il codice.
3. 03
   Aumenta poi la precisione sfruttando il margine rimanente

   Se rimane della VRAM dopo aver riservato il contesto, passa a Q5_K_M, poi a Q6_K. Il guadagno è minore rispetto al passaggio da una dimensione del modello a quella successiva.

ollama run llama3.1:8b-instruct-q5_K_M

Le etichette della libreria Ollama indicano il formato e la dimensione di ogni variante; quando ometti il suffisso, Ollama applica l'etichetta predefinita del modello. Su Hugging Face, i nomi dei file GGUF includono il nome della quantizzazione.

#Gli I-quants e i formati inferiori a 4 bit

La tabella di llama.cpp permette di misurare il risparmio reale. Su Llama 3.1 8B, IQ4_XS pesa 4,17 GiB contro 4,58 GiB per Q4_K_M, cioè circa il 9% in meno; IQ3_XXS pesa 3,04 GiB; IQ2_XXS 2,23 GiB. Nelle misurazioni del repository, le velocità di generazione di questi formati rimangono vicine a quelle dei K-quants, con una differenza di pochi token al secondo: il costo aggiuntivo della decodifica è quindi modesto. Gli I-quants dipendono invece dalla qualità dell'imatrix e del modello: hanno senso solo quando Q4_K_M non rientra in memoria.

IQ4_XS

Dimensioni vicine a quelle di Q4_K_M, ma inferiori di circa il 9 %. Utile quando la VRAM è appena sufficiente.

IQ3_XXS e IQ3_S

Un modello 13B con circa 5 GB di pesi, con una perdita sensibile nelle capacità di ragionamento.

IQ2 e IQ1

Solo per modelli giganteschi, quando nessun'altra opzione entra in memoria. Con quantizzazioni di questo tipo, la fedeltà si misura: vedere l'esempio di Kimi K3, in cui la quantizzazione dinamica a 1 bit presenta solo il 78,9% di concordanza con l'originale.

#Modelli pubblicati direttamente in 4 bit

Alcuni modelli recenti non vengono più addestrati a 16 bit e poi compressi: i loro pesi vengono prodotti a 4 bit con un addestramento consapevole della quantizzazione. Kimi K3 ne è un esempio: la sua scheda indica pesi MXFP4 e attivazioni MXFP8, con quantization-aware training. Per questi modelli, il file nativo è già il riferimento, e un'ulteriore quantizzazione verso un formato a precisione inferiore degrada la qualità più della quantizzazione di un modello a 16 bit. Leggi sempre la scheda del modello prima di convertirlo.

#Che cosa scegliere in base alla memoria

#Per approfondire

• Q4_K_M, Q5_K_M e Q6_K in pratica
• Comprendere la finestra di contesto
• Quantizzare la cache KV: risparmiare VRAM
• GGUF, safetensors: capire i formati
• Calcolatore VRAM

• Fonte: README di llama-quantize (llama.cpp)
• Fonte: studio arXiv sulla quantizzazione llama.cpp (2026)
• Fonte: etichette Ollama di Llama 3.1
• Fonte: discussione su llama.cpp riguardo ai metodi di quantizzazione