Quantizzazione: perché lo stesso modello può girare su una macchina molto più piccola

Vai a scaricare un modello per farlo girare sul tuo computer e ti trovi davanti a una lista di file che hanno tutti lo stesso nome. Stesso modello, stessa versione, stesso numero di parametri. Uno pesa 141 GB. Un altro 75 GB. Un altro ancora 43 GB. Ne prendi due, li provi con le stesse domande, e le risposte si somigliano al punto che fatichi a dire quale sia quale. Poi guardi la barra della memoria: uno ha riempito il computer, l’altro ci sta comodo.

Non è un errore del sito e non sono modelli diversi travestiti. È lo stesso mucchio di numeri, scritto due volte con un numero diverso di cifre. La parola che descrive l’operazione è quantizzazione, e una volta capita ti dà anche la chiave per leggere «70 miliardi di parametri», che è la cifra più citata e meno capita del settore.

In questo articolo scoprirai:

• Lo stesso modello, un terzo della memoria, quasi le stesse risposte
• Cosa succede davvero: i pesi sono numeri, e i numeri si possono scrivere più corti
• Il conto: da 16 bit a 8, peso per peso
• Quantizzazione a blocchi: perché un peso piccolo può sparire
• Il conto grosso: quanta memoria serve per un modello quantizzato
• Dove si vede all'opera: la conversazione tiene, la matematica no
• Quando questa spiegazione non vale, e cosa cambia in «70 miliardi di parametri»

Lo stesso modello, un terzo della memoria, quasi le stesse risposte

I numeri qui sopra non sono inventati per l’esempio: sono i file veri di Llama 3.3 da 70 miliardi di parametri, come li distribuisce Ollama nella pagina dei tag del modello. La versione a 16 bit occupa 141 GB, quella a 8 bit 75 GB, quella a 4 bit «K_M» 43 GB, quella più aggressiva di tutte 26 GB. Stessi pesi, stessa architettura, stesso addestramento.

La conseguenza pratica è quella che il lettore ha già visto: la prima versione non entra in nessuna macchina che una persona normale possieda; la terza entra in una workstation con due schede grafiche da consumo, o in un Mac con memoria unificata generosa. E se le metti a confronto su una conversazione qualunque, la differenza non si sente. Il modello non è diventato più piccolo: è diventato meno preciso, e per la maggior parte di quello che gli chiedi non se ne accorge nessuno.

Cosa succede davvero: i pesi sono numeri, e i numeri si possono scrivere più corti

Un modello non è un’idea astratta. È una collezione di numeri, i pesi, che vengono fissati durante l’addestramento e poi non cambiano più: sono quelli che una rete aggiusta un passo alla volta mentre impara, con il meccanismo che abbiamo raccontato parlando di come una rete corregge i suoi errori. Ogni singolo peso, per esistere dentro un file, deve essere scritto con una certa quantità di bit. Quanti gliene dai decide due cose insieme: quanto spazio occupa e con quante cifre lo stai descrivendo.

La quantizzazione è la riscrittura dei pesi di un modello con meno bit ciascuno: invece di conservare ogni numero in virgola mobile a 16 bit, lo si approssima al gradino più vicino di una scala a 256 valori (8 bit) o a 16 valori (4 bit), memorizzando a parte il fattore di scala che riporta i gradini ai valori originali. Funziona perché il risultato che conta è la somma di milioni di moltiplicazioni: un errore di arrotondamento minuscolo e non sistematico su ogni singolo peso, nella somma, in larga parte si compensa.

È lo stesso principio per cui un prezzo arrotondato all’euro non rovina il conto della spesa, ma con una differenza che l’analogia non regge: qui l’arrotondamento è sulla singola cifra di ogni peso, e in un large language model i pesi sono decine di miliardi. Il conto vero è nella prossima sezione.

Il conto: da 16 bit a 8, peso per peso

Come si scrive a 8 bit un peso nato a 16

Prendiamo quattro pesi veri di un blocco, così come si presentano a 16 bit: 0,0217, −0,1043, 0,0004, 0,1876. La quantizzazione a 8 bit interi lavora per blocchi: cerca il valore di modulo massimo del blocco (0,1876) e lo mappa sull’estremo della scala intera, che va da −127 a +127. Il fattore di scala è quindi 0,1876 / 127 = 0,00148: è il gradino, la distanza minima fra due valori rappresentabili.

Poi ogni peso viene diviso per il gradino e arrotondato all’intero più vicino:

• 0,0217 / 0,00148 = 14,69 → 15 → riletto vale 0,02216 → errore +0,00046 (2,1%)
• −0,1043 / 0,00148 = −70,61 → −71 → riletto vale −0,10488 → errore −0,00058 (0,55%)
• 0,0004 / 0,00148 = 0,27 → 0 → riletto vale 0,0000 → errore −0,0004 (il peso sparisce)
• 0,1876 / 0,00148 = 127 → 127 → riletto vale 0,1876 → errore 0

Quantizzazione a blocchi: perché un peso piccolo può sparire

Nessun errore può superare mezzo gradino, cioè 0,00074, su pesi che arrivano a 0,19. Il caso interessante è il terzo: un peso molto piccolo viene azzerato del tutto, errore relativo del 100%. È il motivo per cui i blocchi si tengono corti, un blocco da 32 pesi ha una scala sua, e un peso minuscolo finisce accanto ad altri pesi minuscoli invece che accanto a un gigante che gli schiaccia la risoluzione.

La dimensione del blocco è il parametro nascosto di tutta la faccenda. Un blocco da 32 pesi si porta dietro un fattore di scala scritto a 16 bit: fa mezzo bit di sovrapprezzo per ogni peso, ed è esattamente la ragione per cui il file «a 8 bit» costa in realtà 8,5 bit. Allargare il blocco a 256 pesi farebbe scendere il sovrapprezzo a 0,06 bit per peso, ma metterebbe sotto la stessa scala valori molto più distanti fra loro, e i pesi piccoli farebbero la fine del terzo della lista. È un baratto fra spazio e risoluzione, e vive dentro le matrici di cui la rete è fatta: l’algebra lineare spiega perché quegli errori si sommano nel modo in cui si sommano.

Il conto grosso: quanta memoria serve per un modello quantizzato

La formula è una moltiplicazione: memoria in gigabyte ≈ (miliardi di parametri × bit per peso) ÷ 8. Llama 3.3 ha 70,6 miliardi di parametri. A 16 bit: 70,6 × 16 ÷ 8 = 141 GB, esattamente il file che Ollama mette in scaricamento. A 8 bit dovrebbe fare 70,6 GB, e invece il file è 75 GB: la differenza è il fattore di scala, un numero a 16 bit ogni 32 pesi, che porta il costo reale a 8,5 bit per peso (70,6 × 8,5 ÷ 8 = 75,0). A 4 bit «K_M» il file è 43 GB, cioè 4,87 bit per peso: non 4 tondi, perché quel formato tiene alcune parti della rete a 6 bit. Il conto torna sempre, basta usare i bit veri e non quelli nominali.

Dove si vede all’opera: la conversazione tiene, la matematica no

La misura standard è la perplexity, cioè quanto il modello resta sorpreso dal testo che legge: più bassa, meglio è. Sulla tabella pubblicata dagli sviluppatori di llama.cpp per un modello da 7 miliardi, passare da 16 bit a 8 bit costa +0,0004 di perplexity, un rumore. Scendere al formato a 4 bit raccomandato costa +0,0535. Scendere a 2 bit costa +0,8698, ed è il punto in cui il modello smette di essere lo stesso modello.

Il degrado non è lineare, ed è questo il dato che conviene tenere a mente: fra 8 e 4 bit il costo si moltiplica per più di cento, fra 4 e 2 bit per altre sedici volte. È la forma tipica di questa curva, piatta finché c’è margine di precisione da bruciare, verticale nel momento esatto in cui il margine finisce.

Dove la quantizzazione spinta rompe il ragionamento

Ma la perplexity è la misura più indulgente che esista, perché premia il testo plausibile. Il comportamento cambia prima e cambia altrove. Lo studio empirico Quantization Hurts Reasoning?, che ha provato modelli da 1,5 a 70 miliardi su AIME, MATH-500, GPQA e LiveCodeBench, trova che a 8 bit sui pesi e sulle attivazioni la perdita è sostanzialmente nulla, mentre più in basso i rischi sull’accuratezza diventano concreti, e si concentrano sui compiti dove una catena di ragionamento lunga amplifica l’errore invece di annacquarlo. È l’esatto contrario di quello che succede in una chiacchierata: lì un peso sbagliato del 2% cambia forse un sinonimo.

Lo vedi nei due posti dove la gente incontra i modelli quantizzati. In locale, con Ollama o LM Studio, dove il formato a 4 bit è il default di fatto e il modello scrive benissimo ma sbaglia i conti che la versione grande azzeccava: capita anche con i modelli nati piccoli, come quelli pensati per girare su CPU. E nell’inferenza di produzione, dove la documentazione di Hugging Face elenca oltre venti metodi diversi da 1 a 8 bit proprio perché la scelta non è mai «quantizzato sì o no», ma «quanto, e dove».

Quando questa spiegazione non vale, e cosa cambia in «70 miliardi di parametri»

La nota che va detta prima di tutte le altre: non tutti i pesi sono uguali, e trattare la quantizzazione come un interruttore unico è una semplificazione che si rompe subito. Il paper LLM.int8() di Dettmers e colleghi ha mostrato che in un transformer da 6,7 miliardi di parametri compaiono valori anomali estremi concentrati in appena 6 dimensioni su migliaia: se li arrotondi come gli altri, il modello degrada di colpo anche a 8 bit. La soluzione è tenere quel 0,1% di valori a 16 bit e quantizzare tutto il resto, ed è la stessa logica per cui il formato K_M dei file locali spende 6 bit sulle proiezioni di attenzione e 4 sul resto. Quando leggi «modello a 4 bit», quasi mai vuol dire quattro bit ovunque.

Quantizzazione e schede tecniche: dai parametri alla memoria reale

Il resto è la conseguenza pratica per chi legge le schede tecniche. «70 miliardi di parametri» non dice quanta memoria serve: dice quanti numeri ci sono. La memoria la ottieni solo moltiplicando per la precisione, ed è per questo che lo stesso modello a volte gira su una macchina normale e a volte non ci sta neanche in dieci. La stessa asimmetria vale al contrario quando confronti due modelli diversi: un modello da 30 miliardi a 8 bit occupa 30 GB, uno da 70 miliardi a 4 bit ne occupa 43, e la scelta fra i due non si decide guardando la cifra dei parametri. Da qui il percorso prosegue verso il percorso completo da una frase alla risposta, per vedere in che punto quei pesi vengono effettivamente usati.

Quando poi la scelta della precisione diventa una decisione da prendere su un sistema in esercizio e non su un portatile, con utenti veri che aspettano e un costo di infrastruttura da giustificare, si entra nel mestiere dell’ottimizzazione dei modelli in produzione.

Fonti:

• Ollama nella pagina dei tag del modello
• tabella pubblicata dagli sviluppatori di llama.cpp
• Quantization Hurts Reasoning?
• la documentazione di Hugging Face
• LLM.int8()