Un modello linguistico moderno può contenere miliardi di parametri. Se ogni peso viene rappresentato con 16 bit, la memoria necessaria cresce rapidamente e può diventare il primo ostacolo al deployment. La quantizzazione nasce da una domanda molto concreta: quanta precisione numerica serve davvero per mantenere il comportamento utile del modello?
Ridurre la precisione permette di diminuire memoria, banda e spesso tempi di inferenza. Ma non è una compressione gratuita: introduciamo errore numerico. Il punto interessante non è quindi chiedersi se qualcosa si perda, perché qualcosa si perde sempre, ma capire dove, quanto e con quale impatto sul task reale.
In breve
- FP16, INT8 e INT4 riducono progressivamente la memoria dei pesi;
- la quantizzazione sostituisce valori continui con un insieme discreto di livelli;
- l’errore introdotto non colpisce tutti i layer e tutti i task allo stesso modo;
- la qualità va misurata sul proprio workload, non dedotta soltanto dal numero di bit;
- PTQ, GPTQ, AWQ e QAT affrontano il problema con strategie diverse.
Da FP32 a FP16, INT8 e INT4
Storicamente molti modelli venivano addestrati in FP32. Oggi FP16 e BF16 sono comuni perché dimezzano la memoria rispetto a FP32 mantenendo una dinamica numerica sufficiente per gran parte dell’addestramento e dell’inferenza.
Con INT8 la memoria dei pesi si dimezza ancora rispetto a FP16. Con INT4, almeno idealmente, si arriva a circa un quarto. Un modello che richiede 20 GB per i soli pesi in FP16 può quindi scendere verso 10 GB in INT8 e circa 5 GB in INT4, al netto di metadati, scale, buffer e KV cache.
Che cosa significa quantizzare
Immaginiamo un intervallo di valori reali. Con precisione elevata possiamo rappresentare moltissimi valori distinti. Con 4 bit disponiamo invece di soli 16 livelli. Dobbiamo quindi mappare molti valori reali sullo stesso livello discreto.
In una quantizzazione lineare semplice possiamo scrivere:
q = round(x / s) + z
dove x è il valore originale, s il fattore di scala e z lo zero-point. In dequantizzazione otteniamo:
x̂ = s(q − z)
La differenza ε = x − x̂ è l’errore di quantizzazione. Più riduciamo i livelli disponibili, più aumenta potenzialmente l’errore.
Perché il modello non crolla subito?
Potrebbe sembrare sorprendente che un modello continui a funzionare bene dopo una riduzione così forte della precisione. Una ragione è che le reti neurali sono sistemi ridondanti: il comportamento globale dipende dall’interazione di moltissimi pesi, e piccole perturbazioni locali possono essere assorbite.
Inoltre i pesi non sono tutti ugualmente sensibili. Alcune matrici e alcuni canali possono tollerare una quantizzazione aggressiva, mentre altri richiedono maggiore precisione. Da qui nascono tecniche che usano scale per gruppo, trattano separatamente gli outlier o mantengono alcune parti in precisione più alta.
Per-tensor, per-channel e group-wise
Usare una sola scala per un’intera matrice è semplice ma poco flessibile. La quantizzazione per-channel calcola scale diverse per canali distinti. Le tecniche group-wise dividono i pesi in gruppi più piccoli e assegnano una scala a ciascun gruppo.
Gruppi più piccoli tendono a preservare meglio la qualità perché la scala si adatta meglio alla distribuzione locale dei pesi, ma richiedono più metadati e possono ridurre parte del vantaggio in memoria.
Weight-only e quantizzazione delle attivazioni
Molti formati per LLM quantizzano soprattutto i pesi. È relativamente semplice e produce un forte risparmio di memoria. Quantizzare anche le attivazioni può aumentare ulteriormente l’efficienza, ma è più delicato perché i valori dipendono dagli input e possono presentare outlier imprevedibili.
Il fatto che un modello venga indicato come “4 bit” non significa quindi necessariamente che ogni operazione venga eseguita realmente a 4 bit. Spesso i pesi sono memorizzati in 4 bit, poi dequantizzati o combinati con calcoli in FP16/BF16 durante l’inferenza.
PTQ: quantizzare dopo l’addestramento
La Post-Training Quantization prende un modello già addestrato e ne riduce la precisione senza riaddestrarlo completamente. È l’approccio più pratico per distribuire modelli esistenti.
Le tecniche moderne cercano di capire quali pesi sono più sensibili e come scegliere scale e correzioni che minimizzino la degradazione. Metodi come GPTQ e AWQ appartengono a questa famiglia, pur con strategie differenti.
QAT: insegnare al modello a convivere con la quantizzazione
La Quantization-Aware Training simula durante l’addestramento gli effetti della quantizzazione. Il modello può così adattare i pesi tenendo conto dell’errore che verrà introdotto.
È più costosa e complessa della PTQ, ma può preservare meglio la qualità quando la precisione richiesta è molto bassa o il task è particolarmente sensibile.
Cosa si guadagna davvero
- meno memoria, quindi modelli più grandi sullo stesso hardware;
- meno traffico di memoria, spesso decisivo nell’inferenza;
- maggiore throughput quando l’hardware supporta bene il formato;
- deployment locale o edge prima impossibile;
- costi inferiori per serving e scaling.
Cosa si perde davvero
La perdita di qualità non è uniforme. Un modello quantizzato può restare quasi indistinguibile su conversazione generale e peggiorare invece su coding, matematica, long context o task che richiedono differenze sottili tra alternative simili.
È importante anche distinguere perplexity e qualità applicativa. Una piccola variazione della perplexity non dice necessariamente quanto peggiorerà un agente, un classificatore o un sistema RAG.
Un errore frequente: confrontare solo la RAM
La memoria dei pesi non è l’intera memoria necessaria. Durante l’inferenza servono anche KV cache, buffer temporanei, runtime e memoria per il contesto. Con contesti molto lunghi, la KV cache può diventare una componente importante.
Per questo un modello “da 5 GB” non significa automaticamente che bastino 5 GB di RAM o VRAM per usarlo in ogni configurazione.
Il ruolo dell’hardware
La quantizzazione produce vantaggi solo se il runtime e l’hardware sanno sfruttarla. Un formato estremamente compatto può ridurre la memoria ma non aumentare la velocità se richiede continue conversioni o kernel poco ottimizzati.
Il benchmark corretto deve quindi misurare insieme qualità, memoria, token/s, latenza e consumi sul dispositivo reale di destinazione.
Dove le cose si complicano
Non esiste una soglia universale oltre la quale “4 bit è troppo”. Dipende dal modello, dal metodo di quantizzazione, dal group size, dal task e dall’hardware. Perfino due quantizzazioni nominalmente INT4 possono comportarsi in modo diverso.
La scelta corretta è quindi empirica: definire un set di test rappresentativo, quantizzare con più configurazioni e costruire una curva qualità-efficienza.
Una regola pratica
Se il modello serve per prototipazione, uso locale o task ben tolleranti, una buona quantizzazione a 4 bit può essere un compromesso eccellente. Se il task è critico, richiede elevata accuratezza o mostra degradazioni anomale, conviene valutare INT8, precisione mista o mantenere alcune componenti in FP16/BF16.
Quantizzare non significa semplicemente comprimere un modello. Significa decidere, in modo controllato, quanta precisione numerica siamo disposti a sacrificare per ottenere memoria, velocità e possibilità di deployment.
← Torna al percorso Dentro l’IA
Lascia un commento