Guida alla quantizzazione LLM: 7 metodi a confronto (con i numeri dei benchmark)

Guida alla quantizzazione LLM: 7 metodi a confronto (con i numeri dei benchmark)

Llama 3.3 70B in FP16 richiede 140 GB solo per i pesi. Due H100. A Q4_K_M, lo stesso modello entra in circa 42 GB, cioè una RTX A6000 usata comprata su eBay. Quello scarto è l'intera ragione per cui esiste la quantizzazione LLM, e scegliere il metodo sbagliato ti costa qualità che vedi a occhio oppure VRAM che non hai.

Questa guida alla quantizzazione LLM confronta i 7 metodi che contano nel 2026, con ogni numero ricondotto a una fonte pubblicata.

Punti chiave

• La quantizzazione scambia memoria e banda con una perdita di qualità misurabile, di solito piccola.
• GPTQ e AWQ nascono per la GPU; GGUF è il formato che gira anche su CPU.
• Q4_K_M si attesta vicino a 4,8 bit per peso, non 4. Il nome nasconde l'overhead.
• La quantizzazione a 6 bit resta entro circa lo 0,1% della perplexity FP16, secondo la PR k-quants di llama.cpp.

Cosa fa davvero la quantizzazione LLM al tuo modello?

La quantizzazione LLM memorizza i pesi del modello a una precisione numerica inferiore, riducendo memoria e banda al prezzo di un errore di arrotondamento. Un modello da 70B parametri scende da 140 GB in FP16 a circa 42 GB a 4 bit. L'intelligenza resta; le cifre decimali se ne vanno. Ogni metodo di questa guida è una variante di questo compromesso.

La scala della precisione parte da FP32 (32 bit), passa per FP16 e BF16 (16 bit ciascuno), poi INT8, poi INT4. Ogni gradino dimezza i byte per parametro. Lo standard IEEE 754 definisce i formati floating point; il paper di Mark Horowitz del 2014 "Computing's Energy Problem" ha mostrato perché spostare quei byte, non l'aritmetica che ci fai sopra, domina il costo energetico. È questa la ragione fisica per cui la quantizzazione accelera l'inferenza.

Due parametri fanno funzionare la quantizzazione: un fattore di scala (il moltiplicatore che riporta l'intervallo di interi ai valori reali) e uno zero-point (l'intero che rappresenta 0,0). La quantizzazione simmetrica centra l'intervallo sullo zero e salta lo zero-point; quella asimmetrica lo sposta per usare l'intero intervallo di interi quando i pesi si concentrano lontano dallo zero.

I pesi si quantizzano bene perché sono statici e distribuiti normalmente. Le attivazioni no. Le attivazioni anomale, a volte 100 volte la mediana, fanno esplodere l'errore di arrotondamento se le quantizzi in modo ingenuo. Questa asimmetria è il motivo per cui la maggior parte dei metodi qui quantizza solo i pesi (W4A16) e lascia le attivazioni in FP16.

La quantizzazione post-training (PTQ) converte un modello finito dopo l'addestramento. Il quantization-aware training (QAT) simula l'arrotondamento durante l'addestramento, così il modello si adatta. Tutto ciò che è in questo articolo è PTQ. Il QAT costa più calcolo e un run di addestramento: è una decisione separata.

Le righe INT4 e NF4 sono il 4 bit puro teorico: 4 bit per peso e nient'altro. I formati a 4 bit reali portano con sé scale e minimi di blocco, quindi atterrano più in alto. Un modello 70B a Q4_K_M pesa circa 42 GB, non 35. La tabella VRAM più avanti usa invece i tassi effettivi.

La quantizzazione non riduce l'intelligenza del modello. Riduce il numero di cifre decimali in cui quell'intelligenza è memorizzata. E se paghi a token per l'inferenza via API, ridurre la bolletta delle API LLM spesso comincia proprio dal far girare da solo un modello quantizzato.

I 7 metodi di quantizzazione, fianco a fianco

I sette metodi qui sotto coprono ogni percorso di produzione per quantizzare un LLM nel 2026. Due sono solo GPU (GPTQ, AWQ), uno gira ovunque (GGUF), uno quantizza al caricamento (BitsandBytes), due puntano al serving ad alto throughput (SmoothQuant, FP8) e uno è nativo PyTorch (TorchAO). La scelta giusta dipende dal tuo hardware, non da quale metodo ottiene il punteggio più alto in una classifica.

GPTQ quantizza strato per strato usando l'inversa dell'Hessiana per ridistribuire l'errore di arrotondamento sui pesi restanti. Serve un set di calibrazione e una GPU. Il paper GPTQ riporta la quantizzazione di un modello 175B a 3-4 bit in circa 4 GPU-ore.

AWQ individua circa l'1% dei pesi che contano di più (i pesi salienti, trovati dalle magnitudini delle attivazioni) e li scala per proteggerli dall'arrotondamento. Il paper AWQ (best paper MLSys 2024) riporta più di 3x di speedup rispetto all'implementazione FP16 di HuggingFace sia su GPU desktop sia mobili.

GGUF è un formato di file, non un algoritmo. L'algoritmo al suo interno è lo schema a blocchi k-quant della PR #1684 di llama.cpp. È l'unico metodo qui che gira su CPU, il che lo rende il default per l'inferenza locale. Vedi modelli open-weight che vale la pena quantizzare per sapere cosa dargli in pasto.

BitsandBytes quantizza al caricamento invece che in anticipo. NF4 (4-bit NormalFloat) è il suo formato distintivo, ed è la spina dorsale del fine-tuning QLoRA. Non serve un set di calibrazione.

SmoothQuant migra le attivazioni anomale nei pesi così che entrambi possano girare a INT8. Il paper riporta fino a 1,56x di speedup e 2x di riduzione della memoria, e punta al throughput nel serving su batch grandi, dove i metodi W4A16 lasciano prestazioni sul tavolo.

FP8 (W8A8) è il percorso nativo su GPU H100 e B200. Quasi lossless a 8 bit, nessun mal di testa da calibrazione, e vLLM lo supporta direttamente.

TorchAO è la libreria di quantizzazione di PyTorch stessa, costruita per funzionare con torch.compile. Se la tua pipeline è già PyTorch, è la strada con meno attrito.

Le vere domande sono solo due: il tuo hardware lo esegue, e riesci a convivere con la qualità che ti costa?

Cosa mostrano davvero i benchmark pubblicati?

I benchmark pubblicati dicono che la quantizzazione a 4 bit costa l'1-2% di perplexity su un modello 7B, e che a 6 bit costa meno dello 0,1%. Quei numeri arrivano dalla PR #1684 di llama.cpp (2023), misurati dai manutentori di llama.cpp su un singolo modello 7B con una RTX 4080. Sono le cifre più citate nel campo della quantizzazione, e sono reali. Sono anche n = 1.

Fonte: PR #1684 di llama.cpp (2023). Modello 7B, RTX 4080, misurata dai manutentori di llama.cpp. n = 1 modello.

Una nota sulla colonna bit/peso: quelli sono i tassi nominali del tipo k-quant di base, e i mix _K alzano il tasso effettivo. Q2_K ne è un esempio. Applichi la formula stessa dell'articolo al valore nominale 2,5625 e a un modello da 6,74B parametri e ottieni circa 2,0 GB, ma la riga riporta un file da 2,67 GB, che a ritroso dà circa 3,4 bit per peso. Il resto di questo articolo usa i tassi effettivi, ricavati da queste dimensioni dei file.

I numeri dei metodi GPU arrivano direttamente dai paper. GPTQ riporta speedup di inferenza end-to-end rispetto a FP16 di circa 3,25x su A100 e circa 4,5x su A6000, con un modello 175B quantizzato a 3-4 bit in circa 4 GPU-ore. AWQ riporta "più di 3x di speedup rispetto all'implementazione FP16 di Huggingface sia su GPU desktop sia mobili", oltre al primo deployment di un Llama-2 70B su GPU mobile via TinyChat. Citiamo la formulazione del paper invece di parafrasare un numero in una falsa precisione.

Il contributo originale qui è aritmetica. La memoria per i pesi segue: pesi (GB) ≈ parametri (B) × bit per peso ÷ 8. L'insidia è quale numero di bit per peso ci inserisci. La PR #1684 pubblica il tasso del tipo k-quant di base (Q4_K = 4,5), e i mix _S/_M/_L stanno sopra quel tasso di base perché danno bit extra ai tensori di attenzione e feed-forward. Quindi abbiamo ricavato i tassi effettivi dalle dimensioni dei file che la PR stessa pubblica, su un modello 7B che in realtà è da 6,74B parametri: Q2_K a 2,67 GB dà a ritroso circa 3,4 bpw, Q4_K_S a 3,56 GB circa 4,5, Q6_K a 5,15 GB circa 6,6. Q4_K_M si attesta vicino a 4,8.

Questo cambia il numero da titolo. Un modello 70B a Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. La maggior parte degli articoli dice 35 GB. Stanno usando 4,0 bpw e saltando del tutto l'overhead delle scale di blocco. La controprova richiede un clic: Llama-3.3-70B-Instruct-Q4_K_M.gguf pesa 42,5 GB su HuggingFace, nei repo bartowski, lmstudio-community e second-state allo stesso modo. Abbiamo ricalcolato ogni cella della tabella VRAM qui sotto su quella base.

La nostra lettura di questi numeri: il gap di perplexity tra Q6_K (5,9110) e F16 (5,9066) è 0,0044, cioè più piccolo del gap tra due fine-tune diversi dello stesso modello di base. Ecco perché "usa Q4_K_M o Q5_K_M e basta" è il consiglio che sopravvive al contatto con l'hardware reale. La colonna ms/token mostra anche che Q2_K non compra velocità rispetto a Q4_K_S (entrambi 15,5 ms/token) mentre costa 0,75 di perplexity. Q2_K è lo scambio peggiore della tabella.

Quello che i numeri non ti dicono: la perplexity su wikitext non è la stessa cosa della qualità sui tuoi prompt. Un modello su una GPU è n = 1. Le cifre di velocità dipendono dalla dimensione del batch. Trattali come indicazioni direzionali, non universali.

La quantizzazione a 6 bit atterra entro circa lo 0,1% della perplexity del modello a piena precisione. A quel livello la compressione è quasi gratuita.

GPTQ vs AWQ: scegliere tra i due metodi GPU

GPTQ e AWQ producono entrambi checkpoint GPU a 4 bit da un set di calibrazione, ed entrambi sono ben supportati in vLLM. La differenza è come gestiscono l'errore di arrotondamento. GPTQ lo ridistribuisce sui pesi restanti usando l'inversa dell'Hessiana. AWQ protegge l'1% dei pesi che le attivazioni segnalano come importanti. Funzionano entrambi. La scelta riguarda il tuo pattern di serving.

GPTQ lavora strato per strato. Per ogni strato, quantizza un peso alla volta, poi aggiusta i pesi restanti di quello strato per compensare l'arrotondamento appena fatto. L'aggiustamento usa informazioni del secondo ordine dalla matrice Hessiana, ed è per questo che serve un set di calibrazione per calcolarlo. Il risultato è forte per l'inferenza batch dove il throughput conta più della latenza per token.

AWQ prende un'altra angolazione. Individua i pesi salienti guardando le magnitudini delle attivazioni sul set di calibrazione, grosso modo l'1% dei canali migliori. Quei pesi ricevono un fattore di scala per canale che li mantiene in un intervallo a precisione più alta durante l'arrotondamento. Il set di calibrazione può essere più piccolo di quello di GPTQ, e AWQ ci va meno in overfitting perché protegge caratteristiche strutturali invece di adattarsi a input specifici. Il paper riporta risultati forti nel serving sensibile alla latenza.

Scegli GPTQ se: fai inferenza batch su GPU, hai un buon set di calibrazione che combacia con il tuo dominio, e il throughput è la metrica.

Scegli AWQ se: servi richieste single-user a bassa latenza, vuoi un set di calibrazione più piccolo, o stai facendo deployment su GPU edge/mobili.

# Servi un checkpoint AWQ pubblicato con vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Servi un checkpoint GPTQ pubblicato con vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Se stai scegliendo anche tra motori di serving, vLLM contro SGLang copre quella decisione separatamente.

GGUF e K-Quants: cosa significa davvero Q4_K_M

GGUF è un formato di file, non un algoritmo di quantizzazione. La spec GGUF definisce un contenitore per pesi del modello, metadati e dati del tokenizer. L'algoritmo di quantizzazione dentro un file GGUF è lo schema a blocchi k-quant (o i-quant) della PR #1684 di llama.cpp. Confondere il contenitore con l'algoritmo è l'errore più comune in questo campo, e porta a domande come "qual è meglio, GGUF o GPTQ?" che non hanno davvero senso.

Lo schema di naming si decodifica così. Q significa schema a blocchi k-quant; IQ significa i-quant con importance-matrix (una variante più recente che usa una matrice di importanza per una qualità migliore alla stessa profondità di bit). Il numero è la profondità di bit nominale. _K marca la famiglia k-quant rispetto ai formati legacy come Q4_0. _S, _M, _L controllano quali gruppi di tensori ricevono bit extra: small, medium, large. Suffisso più alto significa più bit allocati ai tensori di attenzione e feed-forward che contano di più.

Tassi effettivi, ricavati a ritroso dalle dimensioni dei file del 7B (6,74B parametri) pubblicate nella PR #1684, non dalle cifre del tipo di base. Le righe legacy sono esatte per costruzione: un blocco Q4_0 è 32 pesi a 4 bit più una scala FP16, cioè 4,5 bit per peso, e Q8_0 è 32 pesi a 8 bit più una scala FP16, cioè 8,5. La PR lo conferma, elencando i file 7B Q4_0 e Q4_K_S agli stessi 3,56 GB.

Q4_K_M non è 4 bit per peso. È circa 4,8. Le scale e i minimi di blocco devono pur stare da qualche parte, e il mix _M spende poi bit extra sui tensori di attenzione e feed-forward, ed esattamente per questo che Q4_K_M sta sopra Q4_K_S e Q3_K_M sta sopra Q3_K_S invece di eguagliarlo.

Perché GGUF gira dove GPTQ non può: supporta l'inferenza su CPU e l'offload dei layer tra VRAM della GPU e RAM di sistema. Un modello 32B che non entra tutto sulla tua GPU può girare con metà dei suoi layer in offload, lentamente ma in modo funzionale. GPTQ non ha un percorso CPU.

# Scarica un tag di quant specifico con Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Converti un GGUF F16 in Q4_K_M con llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Nuovo ai modelli locali? Parti col far girare il tuo primo modello locale prima di quantizzare alcunché. E se vuoi una UI nel browser, Open WebUI sopra Ollama richiede circa dieci minuti. I docs GGUF di HuggingFace spiegano come l'Hub espone il naming dei tipi di quant.

BitsandBytes, Marlin, SmoothQuant e TorchAO

Questi quattro coprono i percorsi di produzione restanti. Nessuno è un "GPTQ migliore". Risolvono problemi diversi.

BitsandBytes quantizza al momento del caricamento, non in anticipo. Lo punti a un checkpoint FP16 e converte al volo in NF4 o FP4. Niente set di calibrazione, niente step offline. La sua principale pretesa di fama è QLoRA: un modello base congelato a 4 bit con adattatori LoRA addestrati sopra, che rende possibile il fine-tuning di un modello 65B su una sola GPU con 48 GB di VRAM. QLoRA è una tecnica di addestramento, non di inferenza, ma è il motivo per cui la maggior parte delle persone incontra BitsandBytes per primo.

Marlin non è un metodo di quantizzazione. È un kernel GEMM a precisione mista INT4xFP16 che rende più veloci i checkpoint a 4 bit esistenti a dimensioni di batch moderate. Il paper Marlin riporta speedup su A100 e H100. Se il tuo stack di serving lo supporta, lo abiliti su un modello già quantizzato. Non "quantizzi con Marlin".

SmoothQuant sposta le attivazioni anomale nei pesi tramite un fattore di scala per canale, rendendo praticabile W8A8 (sia pesi sia attivazioni a INT8). Il paper punta al serving su batch grandi dove i metodi W4A16 lasciano throughput sul tavolo. Se servi centinaia di richieste concorrenti, questa è la mossa.

TorchAO è la quantizzazione nativa PyTorch che funziona con torch.compile. Niente dipendenze esterne, niente conversione di formato. Se la tua pipeline di inferenza è già PyTorch, è l'opzione con meno attrito. Per eseguire modelli di embedding in locale, il percorso Ollama è di solito più semplice, ma TorchAO si adatta a stack PyTorch custom.

Quanta VRAM serve a un modello quantizzato?

La formula è pesi (GB) ≈ parametri (B) × bit per peso ÷ 8. Un modello 70B a Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. I tassi qui sotto sono quelli effettivi, ricavati a ritroso dalle dimensioni dei file che la PR #1684 di llama.cpp pubblica piuttosto che dai numeri del tipo di base, perché i mix _M girano sempre sopra il loro tasso k-quant di base. Abbiamo ricalcolato invece di copiare la solita scorciatoia da 4,0 bpw.

Calcolato dai bit per peso effettivi: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Ricavati dalle dimensioni dei file del 7B (6,74B parametri) nella PR #1684, poi verificati contro una build 70B pubblicata: Llama-3.3-70B-Instruct-Q4_K_M.gguf pesa 42,5 GB su HuggingFace, contro i 42,0 GB previsti qui.

La caveat onesta: questi sono solo i pesi. KV cache, lunghezza del contesto e overhead del framework si sommano sopra. La KV cache scala con la lunghezza del contesto e la dimensione del batch. Una sessione con contesto 32k su un modello 70B può aggiungere diversi GB. La tabella dei pesi è il pavimento, non il budget. Anche la tua finestra di contesto affitta VRAM. Per il quadro completo, vedi requisiti VRAM per modello in dettaglio.

Quale metodo di quantizzazione dovresti usare?

Il tuo hardware decide prima delle tue preferenze. Un metodo che non gira sulla tua GPU non è una scelta, è un desiderio. La tabella qui sotto mappa configurazioni comuni al metodo che funziona davvero per loro, sulla base dei vincoli hardware e dei compromessi qualitativi coperti sopra.

Per la maggior parte dei lettori su hardware consumer, un GGUF Q4_K_M o Q5_K_M pre-quantizzato è la risposta giusta. Scaricalo da HuggingFace, fallo girare in Ollama o llama.cpp, e smetti di ottimizzare. La differenza di qualità tra Q4_K_M e Q5_K_M è abbastanza piccola che dovresti scegliere in base al fatto che il file entri o meno, non in base a una tabella di perplexity. Tutto ciò che va oltre è ottimizzazione fine a sé stessa, e vale la pena farla solo dopo aver confermato che il modello risolve davvero il tuo problema a Q4.

La guida agli strumenti che eseguono davvero questi modelli in locale copre il lato serving una volta scelto il livello di quant.

Cinque modi in cui la quantizzazione va storta

I fallimenti della quantizzazione sono quasi sempre problemi di configurazione, non di metodo. Questi cinque spuntano di continuo.

1. Il set di calibrazione non combacia con il tuo dominio. GPTQ e AWQ si adattano entrambi ai dati di calibrazione. Se calibri su Wikipedia e fai deployment su trascrizioni mediche, il modello quantizzato performa peggio sui token che non ha mai visto. Rimedio: usa un set di calibrazione preso dalla tua distribuzione di input reale, anche solo 128 campioni aiutano.

2. Group size impostata troppo grande. La group size di GPTQ controlla quanti pesi condividono un fattore di scala. 128 è lo standard. 256 o 512 risparmia calcolo durante la quantizzazione ma colpisce un muro qualitativo sui modelli più piccoli. Rimedio: resta a 128 a meno che tu non abbia confermato che la qualità regge sui tuoi prompt.

3. Aspettarsi che Q2_K sia utilizzabile. Secondo i dati della PR #1684, Q2_K costa circa 0,87 di perplexity rispetto a F16 e non compra velocità rispetto a Q4_K_S (entrambi 15,5 ms/token sul benchmark 7B). Ottieni un file più piccolo e output peggiori senza alcun guadagno di latenza. Rimedio: Q4_K_S è il pavimento a meno che la dimensione del file non sia un vincolo rigido.

4. Fare benchmark sulla perplexity di wikitext invece che sui tuoi prompt. La perplexity è una metrica di language modeling. Non misura se il modello segue il tuo system prompt, formatta JSON correttamente, o gestisce il vocabolario del tuo dominio. Rimedio: fai girare 20-30 dei tuoi prompt reali sia sul modello quantizzato sia su quello non quantizzato e confronta gli output.

5. Confondere GGUF il contenitore con l'algoritmo di quantizzazione al suo interno. Questo porta a confrontare "GGUF vs GPTQ" come se fossero la stessa categoria. Non lo sono. GGUF è un formato di file. Lo schema k-quant al suo interno è l'algoritmo. Rimedio: confronta i livelli k-quant (Q4_K_M vs Q5_K_M), non i formati di file.

Domande frequenti

Cos'è la quantizzazione LLM?

La quantizzazione LLM riduce la precisione numerica dei pesi di un modello, di solito da floating point a 16 bit a interi a 4 bit o 8 bit. Questo taglia l'uso di memoria e accelera l'inferenza riducendo la banda. Un modello 70B scende da 140 GB a circa 42 GB a 4 bit. Il costo qualitativo è di solito l'1-2% di perplexity a 4 bit, meno a 6 bit.

La quantizzazione riduce l'accuratezza di un modello?

Sì, ma meno di quanto la maggior parte delle persone si aspetti. Secondo i benchmark della PR #1684 di llama.cpp, Q4_K_S su un modello 7B costa circa il 2% di perplexity rispetto a F16, e Q6_K costa meno dello 0,1%. L'impatto pratico sui prompt reali è spesso più piccolo di quanto il numero di perplexity suggerisca, specialmente a Q4_K_M e sopra.

È meglio GPTQ o AWQ?

Nessuno dei due è universalmente migliore. GPTQ usa la ridistribuzione dell'errore tramite inversa dell'Hessiana ed è adatto all'inferenza batch su GPU. AWQ protegge i pesi salienti tramite scaling aware delle attivazioni ed è adatto al serving sensibile alla latenza. AWQ serve un set di calibrazione più piccolo e ci va meno in overfitting. Se servi richieste single-user a bassa latenza, parti con AWQ.

Cosa significa Q4_K_M?

Q4_K_M è un livello di quantizzazione GGUF k-quant. "Q4" significa profondità nominale a 4 bit, "K" marca lo schema a blocchi k-quant (rispetto al legacy Q4_0), e "M" significa medium: i tensori di attenzione e feed-forward ricevono bit extra. I bit per peso effettivi sono circa 4,8, non 4,0, perché le scale e i minimi di blocco aggiungono overhead e il mix medium spende di più sopra.

Posso eseguire un modello quantizzato su CPU?

Sì, ma solo via GGUF. GPTQ e AWQ sono formati solo GPU. I modelli k-quant di GGUF girano su CPU tramite llama.cpp o Ollama, e supportano l'offload dei layer tra VRAM della GPU e RAM di sistema. Q4_K_M è il quant standard per CPU. Aspettati una generazione di token più lenta che su GPU, ma inferenza funzionale.

Qual è la differenza tra GGUF e GGML?

GGML è la vecchia libreria di tensori e formato di file che llama.cpp usava in origine. GGUF lo ha sostituito nell'agosto 2023 come formato contenitore più flessibile con un miglior supporto ai metadati. I file GGUF sono quelli che scarichi da HuggingFace oggi. I file GGML sono legacy e raramente distribuiti ormai.

Dovrei quantizzare un modello da solo o scaricarne uno pre-quantizzato?

Scarica prima un modello pre-quantizzato. Le community di llama.cpp e HuggingFace hanno già quantizzato la maggior parte dei modelli popolari a ogni livello. Quantizzare da solo ha senso solo se ti serve un set di calibrazione specifico per il tuo dominio, o se non esiste una versione pre-quantizzata del tuo modello.

Quando dovrei usare la quantizzazione invece di un modello più piccolo?

Usa la quantizzazione quando ti serve la capacità del modello più grande ma non riesci a farlo entrare in memoria. Un modello 70B quantizzato in genere supera un modello 13B non quantizzato sui task di ragionamento complesso. Usa invece un modello più piccolo quando la latenza è il vincolo, dato che i modelli più piccoli generano token più velocemente indipendentemente dalla quantizzazione.

Qual è la differenza tra quantizzazione e distillazione?

La quantizzazione riduce la precisione numerica dei pesi di un modello esistente. La distillazione addestra un modello più piccolo a imitarne uno più grande, producendo un'architettura genuinamente diversa (più piccola). La quantizzazione preserva l'architettura del modello originale ed è reversibile in linea di principio. La distillazione crea un nuovo modello e richiede un run di addestramento.

La versione breve: la quantizzazione è il modo in cui fai entrare un modello che vuoi nell'hardware che hai. Per la maggior parte delle persone su GPU consumer o Apple Silicon, un GGUF Q4_K_M pre-quantizzato scaricato da HuggingFace è l'intera soluzione. GPTQ e AWQ sono le risposte per il serving su GPU. FP8 e SmoothQuant sono le risposte per il throughput in produzione. Tutto il resto è ottimizzazione dopo che hai confermato che il modello funziona.

Se stai decidendo cosa self-hostare e vuoi una seconda opinione sull'abbinamento hardware-metodo, siamo felici di parlarne.