LLM quantization: scegliere formato e precisione

Scegliete la precisione più alta che rientra nei limiti del vostro carico di lavoro e supera le vostre verifiche di qualità. Un file più piccolo da scaricare è utile solo se il modello continua a rispondere correttamente e lascia memoria sufficiente per la conversazione.

La documentazione e le indicazioni sulla compatibilità sono state verificate sulle pagine ufficiali dei progetti il 20 ottobre 2026. I valori di memoria sono calcolati a partire dal numero di parametri documentato di Qwen2.5-7B-Instruct: non sono misurazioni dell'uso della GPU né risultati di benchmark.

LLM quantization: meno precisione, stessa struttura del modello

La quantizzazione memorizza i valori appresi dal modello usando meno bit. Un modello linguistico di grandi dimensioni, o LLM, genera testo servendosi di parametri numerici appresi, chiamati pesi. Ridurne la precisione rende meno oneroso memorizzarli e trasferirli, ma introduce un errore di approssimazione. La panoramica di Hugging Face sulla quantizzazione descrive questo compromesso tra memoria e accuratezza.

Immaginate un progetto architettonico con misure annotate in modo molto preciso. Arrotondarle rende le annotazioni più compatte, ma modifica leggermente alcune dimensioni. L'edificio mantiene comunque le stesse stanze. Allo stesso modo, la normale quantizzazione dei pesi non trasforma un modello grande in uno con meno strati o meno parametri appresi: cambia la precisione con cui vengono rappresentati i pesi.

L'analogia ha un limite: quantizzare richiede scelte più mirate del semplice taglio delle cifre decimali. I valori possono essere raggruppati, associati a un fattore di scala e ricondotti a un insieme più ristretto di valori rappresentabili. Il fattore di scala permette al runtime di ricostruirne un'approssimazione quando deve eseguire i calcoli. Le parti più importanti possono mantenere una precisione superiore. La spiegazione di IBM sulla quantizzazione illustra queste corrispondenze e l'errore che ne deriva.

Prima di scegliere il file da scaricare, distinguete tre elementi:

• Pesi: i valori appresi e memorizzati nel modello.
• Attivazioni: i valori intermedi prodotti durante l'elaborazione dell'input.
• Cache KV: i dati di attenzione conservati per il contesto già elaborato, che occupano ulteriore memoria man mano che la conversazione si allunga.

Uno schema di quantizzazione dei soli pesi riduce la prima componente. Non riduce automaticamente anche le altre due. Ecco perché un modello può caricarsi senza problemi e poi esaurire la memoria con una richiesta lunga. La documentazione di Ollama su memoria e cache tratta separatamente la capacità del contesto e la precisione della cache.

Quantizzazione dopo l'addestramento o durante l'addestramento?

Per chi sviluppa un'applicazione e scarica un modello, il punto di partenza è di solito la quantizzazione dopo l'addestramento. La post-training quantization, o PTQ, converte un checkpoint già addestrato. Alcuni metodi impiegano dati di calibrazione: input rappresentativi che aiutano a scegliere come approssimare i pesi. Il quantization-aware training, o QAT, tiene invece conto degli effetti della bassa precisione durante l'addestramento o il fine-tuning. IBM descrive entrambi gli approcci.

Per usare un checkpoint quantizzato già pubblicato non serve addestrare un modello. Serve però sapere da quale modello originale deriva, quale procedura lo ha prodotto e quale runtime può caricarlo. Il nome del file, da solo, dice ben poco.

GGUF, AWQ, GPTQ e FP8: quale scegliere per il proprio runtime?

Questi nomi indicano livelli diversi del sistema: non sono alternative intercambiabili. GGUF è un contenitore. AWQ e GPTQ sono metodi di quantizzazione. FP8 è un formato numerico. Un checkpoint è il modello salvato, che riunisce i pesi e le informazioni necessarie per caricarli.

Hugging Face, piattaforma di hosting dei modelli e sviluppatore di Transformers, documenta sia i formati dei file sia i metodi di caricamento. La tabella unisce queste informazioni alle indicazioni dei runtime. È una guida pratica alla scelta, senza presumere che ogni architettura funzioni con tutte le combinazioni elencate.

Nemmeno l'estensione .safetensors basta a stabilire la precisione. Identifica un formato per memorizzare tensori. Per capire come sono rappresentati e quale loader usare, leggete la configurazione di quantizzazione e la scheda del modello. La documentazione GGUF di Hugging Face distingue i metadati del contenitore dai dati dei tensori; la sua guida ad AWQ mostra i campi pertinenti di quantization_config.

Che cosa significa Q4_K_M?

Q4_K_M è una configurazione predefinita a precisione mista, non la garanzia che ogni parametro occupi esattamente quattro bit. Q4 identifica la famiglia nominale a quattro bit, K lo schema a blocchi K-quant e M la variante medium. Alcuni tensori possono usare una precisione maggiore in base all'architettura del modello e alle regole del quantizzatore. Il codice di quantizzazione di llama.cpp rende esplicite queste scelte.

Anche un semplice blocco Q4_K include informazioni di servizio: la tabella di codifica dei tensori del progetto indica 4.5 bit per peso, contando anche le informazioni sulla scala e sul minimo. È un valore riferito al singolo blocco, non la media di ogni modello Q4_K_M.

Su una macchina locale con risorse limitate, Q4_K_M è un candidato ragionevole da provare. Se una variante a precisione maggiore rientra nella memoria disponibile con il contesto previsto, confrontate anche quella. Non sacrificate la qualità delle risposte solo perché esiste un file più piccolo.

Quanta memoria serve? Il calcolo per Qwen2.5-7B-Instruct

Partite dal numero totale di parametri, poi aggiungete la memoria necessaria all'esecuzione. Qwen2.5-7B-Instruct, il modello di Qwen ottimizzato per seguire istruzioni che usiamo come esempio concreto, ha 7.61 miliardi di parametri totali. La sua scheda riporta separatamente 6.53 miliardi di parametri esclusi gli embedding: usare questo valore più basso escluderebbe una parte del modello memorizzato. Scheda del modello Qwen.

Il calcolo teorico è:

Byte dei pesi ≈ numero di parametri × bit per parametro ÷ 8

A 16 bit, il calcolo è 7,610,000,000 × 16 ÷ 8 = 15,220,000,000 bytes. Ripetendolo per le altre precisioni si ottiene:

Sono nostri calcoli basati sul numero arrotondato di parametri della scheda del modello, nell'ipotesi che ciascun parametro usi il numero di bit indicato. Per ottenere i GB decimali si dividono i byte per 1,000,000,000; per i GiB si dividono per 1,073,741,824. Cambia il numero visualizzato, non la quantità di memoria.

La tabella esclude volutamente fattori di scala della quantizzazione, tensori a precisione maggiore, metadati del file, cache, attivazioni, buffer temporanei e memoria riservata dal runtime. Un file Q4_K_M non avrà le dimensioni della riga teorica a quattro bit. Quella riga, inoltre, non dimostra che il modello possa girare su un'ipotetica GPU da 4 GB.

Per un assistente di programmazione locale, quindi, una breve chat non basta a verificare la capacità. Un test utile include i file sorgente, le istruzioni e la lunghezza delle risposte che prevedete di usare. Su un server vanno aggiunte le richieste simultanee. Ollama documenta esplicitamente l'effetto sulla memoria delle richieste parallele e dell'allocazione del contesto.

La guida alla cache KV approfondisce il calcolo separato della memoria per il contesto. Quantizzazione dei pesi e quantizzazione della cache sono regolazioni distinte; anche vLLM documenta la quantizzazione della cache KV come funzionalità a sé.

Scegliere il formato a partire dal runtime

Prima decidete come eseguire il modello, poi scegliete la precisione. La compatibilità è un requisito imprescindibile. Una volta verificata, la scelta dipende da memoria disponibile, qualità delle risposte e latenza misurata sul vostro carico di lavoro.

llama.cpp: partire da un GGUF compatibile

llama.cpp, motore di inferenza locale, è la strada diretta per GGUF quando volete controllare il file del modello e la sua distribuzione sui dispositivi. La documentazione del progetto elenca l'esecuzione su CPU, il supporto per Apple silicon e l'esecuzione mista CPU/GPU. È quindi utile quando i pesi di un modello non possono risiedere tutti su una GPU dedicata. Documentazione del progetto llama.cpp.

Il limite è che riuscire a caricare un modello non garantisce una velocità utile. Suddividerlo tra CPU e GPU cambia le condizioni di esecuzione: occorre comunque misurare le prestazioni con prompt e risposte reali. Scegliete prima l'architettura del modello, poi un GGUF compatibile e infine una configurazione di quantizzazione.

La guida ai migliori LLM locali del sito aiuta a scegliere il modello di partenza. La quantizzazione non può rendere un modello inadatto capace di comprendere un compito che svolge male anche a precisione maggiore.

Ollama: importare il modello già quantizzato

Ollama, che permette di eseguire modelli in locale, può importare un GGUF già preparato, ma l'importazione non lo quantizza. La guida attuale richiede di preparare prima il file quantizzato. È una distinzione essenziale se ci si aspetta che un comando di importazione converta automaticamente un modello a precisione maggiore in Q4_K_M. Documentazione di Ollama sull'importazione.

Con Ollama installato e un file compatibile, già quantizzato, salvato come model.gguf nella directory corrente, la procedura documentata diventa:

printf 'FROM ./model.gguf\n' > Modelfile
ollama create quant-check
ollama run quant-check

Eseguite ollama ps in un altro terminale per controllare come il modello caricato è distribuito tra CPU e GPU. È una verifica di ciò che è stato caricato, non un benchmark di qualità. FAQ di Ollama.

Anche con Ollama, il limite resta la memoria richiesta dal carico di lavoro. Un comando comodo per avviare il modello non elimina il fabbisogno di contesto e concorrenza. Il confronto tra Ollama e llama.cpp aiuta a scegliere il livello di controllo sul file del modello e sul runtime.

vLLM: checkpoint, kernel e GPU devono essere compatibili

vLLM, motore per l'inferenza e l'erogazione di modelli, richiede un checkpoint quantizzato compatibile con una modalità di esecuzione supportata. Partite da un file AWQ, GPTQ o FP8 supportato da chi pubblica il modello, poi verificate la GPU nella matrice hardware di vLLM. Un kernel è l'implementazione di calcolo a basso livello che consente di eseguire un formato in modo efficiente su quell'hardware.

Per le nuove quantizzazioni AWQ, la documentazione attuale rimanda a LLM Compressor. AutoAWQ è deprecato; AWQ come metodo e famiglia di checkpoint continua a esistere. Per GPTQ in Transformers, il backend mantenuto è GPTQModel, e la compatibilità può dipendere dalle impostazioni del checkpoint. Indicazioni di vLLM su AWQ, indicazioni di Hugging Face su GPTQ.

Per FP8 serve un'ulteriore distinzione. W8A8 indica pesi e attivazioni a otto bit; W8A16 indica pesi a otto bit e attivazioni a sedici bit. vLLM documenta FP8 W8A8 nativo per NVIDIA Ada, Hopper e Blackwell, mentre Turing e Ampere possono usare una modalità W8A16 con quantizzazione dei soli pesi tramite Marlin. Leggere «FP8 supportato» non basta quindi a sapere quale modalità di calcolo si otterrà. Documentazione FP8 di vLLM.

Non scegliete GGUF come formato predefinito per il deployment con vLLM solo perché ha funzionato in locale. La documentazione attuale rimanda a vllm-gguf-plugin per usare GGUF e lo descrive ancora come sperimentale e poco ottimizzato, con possibili incompatibilità tra funzionalità. È un vincolo da considerare nella migrazione, non la prova che GGUF sia di per sé inferiore. Documentazione GGUF di vLLM.

API gestite: scegliere tra le opzioni esposte dall'endpoint

Se un'API gestita non espone un'impostazione di precisione, non avete una scelta di quantizzazione locale da compiere. Leggete le specifiche dell'endpoint. Se offre varianti con una precisione dichiarata, valutate quella selezionata; altrimenti valutate risultati e latenza del servizio senza fare ipotesi sulla rappresentazione interna.

Lo stesso nome di modello non garantisce la stessa quantizzazione, lo stesso runtime o gli stessi risultati presso fornitori diversi. Chiedete un checkpoint documentato o una garanzia sulla precisione solo quando l'applicazione ne ha bisogno. Caricare e mettere in servizio i propri pesi è una scelta di deployment distinta, che riporta al problema della compatibilità tra runtime e hardware.

Quantizzazione dei modelli: il compromesso tra memoria, velocità e qualità

Rappresentazioni più compatte riducono la memoria; velocità e qualità vanno valutate separatamente. Mantenere meno dati in memoria può ridurre il lavoro necessario per trasferire i pesi. Il runtime, però, può anche dover decomprimere o convertire quei valori prima di usarli nei calcoli. La documentazione GPTQ di Hugging Face spiega come un kernel fuso possa ricostruire i pesi a bassa precisione per il calcolo senza espandere l'intero modello nella memoria globale della GPU.

Qui stanno sia l'opportunità sia il limite. Un kernel supportato può sfruttare i vantaggi dei pesi compatti. Una modalità di esecuzione inadatta può annullarli. Misurate il tempo al primo token, la velocità di generazione e il throughput al livello di concorrenza previsto: le dimensioni del file non sono un benchmark di velocità.

Anche la qualità dipende dal compito. Per un assistente di programmazione, confrontate la capacità delle modifiche proposte di superare i test pertinenti. Per l'estrazione dai documenti, confrontate la presenza dei campi richiesti e la validità dell'output strutturato. Per un assistente multilingue, includete le lingue che dovrà gestire. Una risposta scorrevole non basta a dimostrare che la quantizzazione abbia preservato il comportamento sul vostro compito.

Il confronto utile usa lo stesso checkpoint originale, a precisione maggiore e con la quantizzazione candidata, mantenendo identici prompt, template di chat e impostazioni di generazione. Se nel frattempo confrontate anche modelli diversi, non potete isolare gli effetti della quantizzazione.

Quando conviene evitare la quantizzazione e quali promesse ridimensionare

Mantenete una precisione maggiore se il modello rientra già nelle risorse disponibili e la variante quantizzata non offre vantaggi operativi misurati. Comprimere ulteriormente significa avere un altro file e un altro comportamento da validare. Deve servire a risolvere un problema concreto.

Non adottate una variante a precisione inferiore se fallisce verifiche importanti per il compito, se la sua modalità di esecuzione è scarsamente supportata o se il carico di lavoro con contesto lungo continua a superare la memoria disponibile. In quest'ultimo caso, esaminate contesto e concorrenza prima di continuare a ridurre i pesi.

Neppure un modello quantizzato per l'inferenza va considerato un checkpoint universale per l'addestramento. Bitsandbytes documenta il supporto all'addestramento a bassa precisione per parametri aggiuntivi, come i pesi degli adapter. È un processo specifico di fine-tuning, che non permette di presumere che ogni modello quantizzato scaricato supporti il normale addestramento di tutti i pesi. Documentazione bitsandbytes di Hugging Face.

Le promesse esagerate sono facili da riconoscere:

• «A quattro bit, l'intera applicazione usa un quarto della memoria.» È il rapporto teorico tra il numero di bit dei pesi rispetto ai sedici bit. La memoria di esecuzione comprende altre componenti.
• «Otto bit indica un unico formato.» FP8, INT8 e Q8_0 sono rappresentazioni e modalità di esecuzione diverse.
• «Meno bit significa sempre più velocità.» Checkpoint, kernel, hardware e carico di lavoro determinano se il risparmio di memoria si traduce in una latenza inferiore o in un throughput maggiore.
• «Un modello grande quantizzato batte sempre un modello piccolo a precisione maggiore.» Il numero di parametri e di bit, da soli, non determina la qualità sul compito. Se entrambi rientrano nella memoria disponibile, valutateli entrambi.

Per individuare modelli adatti alla programmazione, usate la guida ai migliori modelli AI locali per scrivere codice, poi confrontate le varianti di quantizzazione del checkpoint scelto sul lavoro che dovrà svolgere.

Quantizzazione LLM: come passare alla prova pratica

Partite da un file supportato e da una valutazione breve e ripetibile. Mantenete fisso il modello originale finché non avete compreso l'effetto della precisione.

Domande frequenti

Per guide pratiche su come eseguire e mettere in produzione sistemi AI, iscrivetevi alla newsletter.