← Resources
By Ren Sugaya
— Performance Engineer, GPU & Inference
·
· INSIGHT
La quantizzazione degli LLM spiegata: GGUF, Q4 vs Q8 e qualità
La quantizzazione riduce le dimensioni di un LLM memorizzando i suoi pesi con precisione inferiore, tagliando la VRAM di circa quattro volte a 4 bit. Questa guida spiega il calcolo della VRAM, decodifica i nomi di quantizzazione GGUF come Q4_K_M, confronta GGUF con GPTQ e AWQ e mostra dove la qualità si degrada davvero.
Cos'è la quantizzazione e perché è importante
La quantizzazione riduce la precisione numerica usata per memorizzare i pesi del modello — di solito da FP16 (16 bit, 2 byte per peso) a 8 bit o 4 bit. Poiché la memoria scala linearmente con i bit per peso, il 4 bit usa circa quattro volte meno VRAM dell'FP16. Accelera anche l'inferenza, dato che la generazione dei token è limitata dalla larghezza di banda della memoria, non solo dalla potenza di calcolo.
Il calcolo delle dimensioni è semplice: byte ≈ (parametri × bit-per-peso) ÷ 8. Un modello da 8B in FP16 occupa circa 16 GB; a 4 bit sono circa 4,5 GB. Questa differenza è ciò che trasforma un modello che richiede una GPU da data center in uno che gira su un laptop.
GGUF è un formato di file, non un metodo
GGUF è un formato a file singolo che memorizza i pesi quantizzati insieme ai metadati del modello (tokenizzatore, architettura, iperparametri). È il successore di GGML del progetto llama.cpp, ottimizzato per CPU, Apple Silicon (Metal) e offload misto CPU/GPU — ecco perché domina l'inferenza locale e su laptop tramite llama.cpp, Ollama e LM Studio.
Il livello di quantizzazione è nel nome del file. Il numero è la media di bit per peso; `_K` indica i k-quant (il moderno metodo a super-blocchi con fattori di scala doppiamente quantizzati e allocazione dei bit sensibile agli strati); `_S`, `_M`, `_L` sono le varianti piccola, media e grande. `_M` mantiene selettivamente gli strati sensibili — attenzione e output — a maggiore precisione, motivo per cui Q4_K_M supera una quantizzazione uniforme a 4 bit.
Q4 vs Q5 vs Q8: dimensioni e qualità, con i numeri
Una valutazione peer-reviewed su Llama-3.1-8B rende concreti i compromessi (le dimensioni si riferiscono a quel modello; i rapporti si generalizzano). Rispetto a una perplexity di riferimento FP16 di circa 7,32 (più bassa è, meglio è):
- Q8_0 — 8,5 bit/peso, ~7,95 GiB, perplexity 7,33: essenzialmente senza perdite.
- Q6_K — 6,56 bpw, ~6,14 GiB, perplexity 7,35.
- Q5_K_M — 5,70 bpw, ~5,33 GiB, perplexity 7,40.
- Q4_K_M — 4,89 bpw, ~4,58 GiB, perplexity 7,56: il punto ottimale pratico, a meno di mezzo punto percentuale dal valore di riferimento.
- Q3 e inferiori — degradazione netta e costante, soprattutto nei task di ragionamento.
La fascia 4-5 bit è la zona sicura. Sotto i 3 bit servono le quantizzazioni a matrice di importanza (IQ), che usano dati di calibrazione per concentrare la precisione dove conta di più — utilizzabili, ma come ultima risorsa quando la memoria è molto limitata.
GGUF vs GPTQ vs AWQ
GGUF non è l'unica opzione; quella giusta dipende da dove esegui il modello.
- GGUF: progettato per CPU, Mac e offload misto. Sceglilo per l'inferenza locale e desktop.
- GPTQ: post-training, basato su calibrazione, usa informazioni di secondo ordine per minimizzare l'errore per strato. Il più preciso peso per peso a una data larghezza di bit, ma lento da produrre e orientato al servizio su GPU (vLLM, TGI, TensorRT-LLM).
- AWQ: protegge circa l'1% dei pesi più rilevanti in base alle magnitudini di attivazione; più veloce da produrre del GPTQ e ottimizzato per GPU a 4 bit.
- bitsandbytes: quantizza al volo durante il caricamento, senza checkpoint pre-quantizzato né calibrazione — il percorso più semplice, molto usato per il fine-tuning con QLoRA.
La distinzione pratica: GGUF per locale e laptop, AWQ o GPTQ per il throughput su server GPU.
Quanta qualità si perde davvero?
Meno di quanto la maggior parte delle persone tema a 4 bit, e più di quanto si aspetti sotto i 3 bit. Nella valutazione di Llama-3.1-8B, Q8 rientrava nel margine di arrotondamento della piena precisione, Q4_K_M ha perso meno di mezzo punto percentuale sui benchmark medi, e il crollo è comparso a 3 bit, con la degradazione più evidente nelle valutazioni di ragionamento intensivo come la matematica scolastica. Ricorda che i valori assoluti di perplexity e dimensioni sono specifici di ogni modello — le percentuali si generalizzano, ma verifica sempre i dati per il tuo modello base. E riserva VRAM oltre la dimensione del file: anche la KV cache e circa il 10-15% di overhead del framework hanno bisogno di margine.
Quantizzazione in osFoundry
Scegliere una quantizzazione di solito significa capire i bit per peso, lasciare spazio per la KV cache e setacciare un muro di suffissi GGUF criptici per trovare l'unico file che ci sta senza andare in crash. L'inferenza locale di osFoundry elimina questo passaggio: rileva la memoria disponibile e seleziona automaticamente la quantizzazione giusta — Q4_K_M per VRAM limitata, Q5_K_M o Q8_0 quando c'è margine — così il modello gira alla migliore qualità che il tuo hardware supporta. Il catalogo mostra solo le versioni compatibili invece di tutte le varianti, e ripiega senza intoppi su una quantizzazione più leggera se una più pesante non ci sta. Ottieni il punto ottimale tra dimensioni e qualità di scegliere un GGUF a mano, senza dover sapere cosa significa Q4_K_M.
Frequently asked questions
- Cos'è la quantizzazione degli LLM in parole semplici?
- È memorizzare i pesi di un modello con precisione numerica inferiore — per esempio 4 bit invece di 16 — per ridurne le dimensioni. Poiché la memoria scala con i bit per peso, la quantizzazione a 4 bit usa circa quattro volte meno VRAM dell'FP16 ed è più veloce, con un costo in qualità piccolo e in genere accettabile.
- Cosa significa GGUF e cos'è?
- GGUF è il formato di modello a file singolo del progetto llama.cpp (il successore di GGML) che raggruppa i pesi quantizzati con i metadati del modello. È ottimizzato per CPU, Apple Silicon e inferenza mista CPU/GPU, motivo per cui è lo standard degli strumenti locali come llama.cpp, Ollama e LM Studio. È un formato di file, non un algoritmo di quantizzazione.
- Qual è la differenza tra Q4, Q5 e Q8?
- Il numero è la media di bit per peso, quindi Q8 è più grande e più fedele di Q5, che a sua volta è più grande di Q4. Su un modello tipico da 8B, Q8 è quasi senza perdite con circa 8 GB, Q5_K_M è un gradino sotto con circa 5,3 GB, e Q4_K_M è il punto ottimale tra dimensioni e qualità con circa 4,6 GB e meno di mezzo punto percentuale di perdita.
- Quale quantizzazione GGUF dovrei usare?
- Q4_K_M nella maggior parte dei casi — è il miglior equilibrio tra dimensioni e qualità e il punto di partenza standard. Passa a Q5_K_M o Q8_0 se hai VRAM in eccesso e vuoi maggiore fedeltà, e scendi sotto Q4 (usando le quantizzazioni IQ a matrice di importanza) solo quando la memoria è davvero limitata, poiché la qualità cala bruscamente a 3 bit e inferiori.
- Quanta qualità si perde con la quantizzazione a 4 bit?
- Sorprendentemente poca. In una valutazione peer-reviewed di Llama-3.1-8B, Q4_K_M si è collocato a meno di mezzo punto percentuale dal valore di riferimento di piena precisione sui benchmark medi. La degradazione percepibile inizia a 3 bit, soprattutto nei task di ragionamento e matematica. I numeri esatti variano da modello a modello, ma la fascia 4-5 bit è ampiamente considerata la zona sicura.
- GGUF vs GPTQ vs AWQ — quale scegliere?
- GGUF per l'inferenza locale, su laptop e Apple Silicon tramite llama.cpp o Ollama. GPTQ e AWQ memorizzano un layout ottimizzato per GPU e sono la scelta migliore per il throughput su server GPU con vLLM o TGI — AWQ è più veloce da produrre, GPTQ è spesso il più preciso peso per peso. bitsandbytes è il più semplice, poiché quantizza al caricamento senza calibrazione.
- Come calcolo la VRAM necessaria per un modello quantizzato?
- Usa byte ≈ (parametri × bit-per-peso) ÷ 8. A 4 bit sono circa 0,5-0,6 GB per miliardo di parametri, quindi un modello da 8B occupa circa 4,5 GB. Aggiungi poi margine per la KV cache e circa il 10-15% di overhead del framework — l'impronta durante l'esecuzione è sempre maggiore del file su disco.
Sources