Quantizzazione: Cos'è e Come Far Girare un LLM sul Tuo PC

Ieri abbiamo visto che Qwen 3.5-9B gira su un laptop con 16GB. Oggi vediamo come.

La risposta è una parola: quantizzazione. È la tecnica che prende un modello da 28GB e lo comprime a 4-5GB, perdendo meno dell'1% di qualità. È il motivo per cui nel 2026 puoi avere un modello da miliardi di parametri sul tuo portatile — offline, gratis, senza mandare un byte ai server di nessuno.

E non serve essere un ML engineer per usarla. Serve capire cosa scegliere e perché.

Il Problema: I Modelli Sono Troppo Grossi

Un LLM memorizza la sua "conoscenza" in pesi — miliardi di numeri decimali. Ogni peso è un numero come 0.0023847.

Di default, ogni peso occupa 16 bit (FP16 — floating point a 16 bit). Facciamo due conti:

Modello	Parametri	Peso in FP16	RAM necessaria
Qwen3.5-9B	9 miliardi	2 byte × 9B	~18 GB
Llama 3.1 8B	8 miliardi	2 byte × 8B	~16 GB
Qwen3.5-27B	27 miliardi	2 byte × 27B	~54 GB
Qwen3.5-35B-A3B (MoE)	35 miliardi	2 byte × 35B	~70 GB

Anche un "piccolo" modello da 8B richiede 16GB solo per i pesi — a cui devi aggiungere la memoria per il contesto (KV cache), il sistema operativo, e tutto il resto. Un laptop con 16GB di RAM non ce la fa.

E qui entra la quantizzazione.

Cos'è la Quantizzazione (in 60 Secondi)

Quantizzare significa ridurre la precisione dei numeri.

Immagina di avere il numero 3.14159265. In FP16 lo memorizzi con alta precisione: 3.14159. In INT4 (4 bit) lo comprimi a qualcosa come 3. Hai perso i decimali, ma il "senso" del numero è preservato.

Applicato a miliardi di pesi:

FP16: ogni peso = 16 bit → modello 8B = ~16 GB
INT8: ogni peso =  8 bit → modello 8B =  ~8 GB
INT4: ogni peso =  4 bit → modello 8B =  ~4 GB

Dimezzi i bit, dimezzi la memoria. Un modello da 8B passa da 16GB a 4GB. Ora ci sta nel tuo laptop.

Ma la qualità?

Ecco il dato che sorprende: la perdita di qualità è minima.

Benchmark di perplexity (più basso = meglio) su Llama 3.1 8B:

Formato	Bit per peso	Dimensione	Perplexity	Δ da FP16
FP16 (originale)	16	~16 GB	7.46	baseline
Q8_0	8	~8 GB	7.49	+0.4%
Q5_K_M	5	~5.5 GB	7.50	+0.5%
Q4_K_M	4	~4.5 GB	7.53	+0.9%
Q3_K_M	3	~3.5 GB	7.68	+2.9%
Q2_K	2	~2.5 GB	8.45	+13.3%

Q4_K_M — 4 bit — perde meno dell'1% di qualità occupando un quarto dello spazio. È il motivo per cui è diventato lo standard de facto per l'uso locale.

Sotto i 4 bit (Q3, Q2) la qualità degrada visibilmente. A 2 bit il modello inizia a produrre nonsense su task complessi. Il sweet spot è tra 4 e 5 bit.

I Tre Formati: GGUF, GPTQ, AWQ

Non esiste un solo modo di quantizzare. I tre formati dominanti nel 2026 sono pensati per hardware diverso.

GGUF — Il Formato Universale

Cos'è: il formato nativo di llama.cpp, il motore di inferenza più usato per LLM locali.

Per chi è: chiunque voglia far girare un LLM su CPU, Apple Silicon (M1/M2/M3/M4), o GPU con VRAM limitata.

Come funziona: divide i pesi in blocchi e li quantizza con fattori di scala individuali. I "K-quant" (Q4_KM, Q5K_S) usano blocchi di dimensione variabile per preservare i pesi più importanti con più precisione.

Vantaggi:

Gira su qualsiasi hardware — CPU, GPU NVIDIA, AMD, Apple Silicon, persino Raspberry Pi
Supporta offloading parziale: parte del modello su GPU, parte su CPU
Il formato più supportato su Hugging Face
Da 1.5 bit a 8 bit — massima flessibilità

Svantaggi:

Su GPU NVIDIA pure, è più lento di GPTQ/AWQ (~30-40%)

GPTQ — Velocità Pura su GPU

Cos'è: un metodo di quantizzazione post-training che analizza ogni layer per minimizzare l'errore di quantizzazione.

Per chi è: chi ha una GPU NVIDIA con abbastanza VRAM per il modello intero.

Come funziona: usa l'inversa della matrice Hessiana per decidere come quantizzare ogni peso — i pesi che causano più errore vengono trattati con più cura. Richiede un dataset di calibrazione.

Vantaggi:

Fino a 5x più veloce di GGUF su GPU con kernel ottimizzati (ExLlama v2, Marlin)
Eccellente per servire modelli via API locale

Svantaggi:

Solo GPU — non gira su CPU
Richiede che il modello stia interamente in VRAM
Il processo di quantizzazione è lento (ore per modelli grandi)

AWQ — Il Compromesso Intelligente

Cos'è: Activation-Aware Weight Quantization. Protegge i pesi più importanti osservando le attivazioni del modello, non solo i pesi stessi.

Per chi è: chi vuole la migliore qualità possibile a 4 bit, specialmente per coding e task creativi.

Come funziona: identifica i canali con attivazioni ampie (che sono quindi "più importanti") e li protegge durante la quantizzazione. Non usa backpropagation — è più veloce da produrre di GPTQ.

Vantaggi:

Miglior qualità a parità di bit, specialmente su task di coding e ragionamento
Più veloce da quantizzare rispetto a GPTQ
Buon supporto su vLLM per serving

Svantaggi:

Solo GPU
Ecosistema più piccolo di GGUF

La Tabella Decisionale

Hai...	Usa...	Formato
Solo CPU o Apple Silicon	Ollama / llama.cpp	GGUF Q4_K_M
GPU con 8GB VRAM	llama.cpp con GPU offloading	GGUF Q4_K_M
GPU con 12-16GB VRAM	vLLM o llama.cpp	AWQ o GPTQ
GPU con 24GB+ VRAM	vLLM	AWQ (miglior qualità)
Vuoi la massima semplicità	Ollama	GGUF (automatico)

Guida Pratica: Da Zero a LLM Locale in 5 Minuti

Basta teoria. Facciamo girare un modello.

Opzione 1: Ollama (la più semplice)

Ollama è il "Docker per gli LLM". Installi, scrivi un comando, il modello gira. Usa GGUF sotto il cofano.

Installazione:

# Windows (PowerShell) — scarica da ollama.com
winget install Ollama.Ollama

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.com/install.sh | sh

Scarica e avvia un modello:

# Qwen 3.5 9B (il modello di ieri, quantizzato Q4_K_M)
ollama run qwen3.5:9b

# Llama 3.1 8B
ollama run llama3.1:8b

# Qwen 3.5 27B (serve ~16GB di RAM)
ollama run qwen3.5:27b

Fatto. Ollama scarica il modello quantizzato (Q4_K_M di default), lo carica e apre una chat nel terminale. Il primo download richiede qualche minuto, poi è istantaneo.

Usalo come API:

# Ollama espone un'API compatibile OpenAI sulla porta 11434
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.5:9b",
    "messages": [{"role": "user", "content": "Spiega cos'\''è un closure in JavaScript"}]
  }'

Qualsiasi tool che supporta l'API OpenAI funziona con Ollama cambiando solo l'endpoint. Continue, Open WebUI, qualsiasi SDK — puntano a localhost:11434 e parlano con il tuo modello locale.

Opzione 2: llama.cpp (controllo totale)

Se vuoi scegliere esattamente quale quantizzazione usare, llama.cpp ti dà il controllo completo.

Setup:

# Clona e compila
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release

# Scarica un modello GGUF da Hugging Face
# (cerca "GGUF" nei modelli — i più popolari sono quelli di bartowski e unsloth)

Avvia:

./build/bin/llama-server \
  --model qwen3.5-9b-q4_k_m.gguf \
  --ctx-size 8192 \
  --n-gpu-layers 35 \
  --port 8080

I parametri chiave:

--n-gpu-layers: quanti layer caricare su GPU (il resto va su CPU). Se hai poca VRAM, parti basso (10-15) e sali
--ctx-size: finestra di contesto in token. Più grande = più RAM
--port: porta per l'API (compatibile OpenAI)

Quale Quantizzazione Scegliere

La nomenclatura sembra criptica ma ha una logica:

Q[bit]_[metodo]_[dimensione]

Q4 = 4 bit          K = K-quant (metodo avanzato)
Q5 = 5 bit          S = Small
Q8 = 8 bit          M = Medium
                     L = Large

Q4_K_M = 4 bit, K-quant, dimensione Medium. È il default per un motivo.

La Regola Pratica

RAM disponibile     → Quantizzazione consigliata
─────────────────────────────────────────────
8 GB                → Q4_K_M per modelli ≤ 7-9B
16 GB               → Q4_K_M per modelli ≤ 27B
                    → Q5_K_M per modelli ≤ 14B
32 GB               → Q5_K_M per modelli ≤ 27B
                    → Q8_0 per modelli ≤ 14B
64 GB+              → Q8_0 o FP16 per quasi tutto

Nota: questi sono approssimazioni. La RAM effettiva dipende anche dalla finestra di contesto (KV cache) e dal sistema operativo. Lascia sempre 2-4GB liberi per il sistema.

Quando Salire di Qualità

Coding: Q5_K_M o superiore. Il codice è sensibile alla precisione — un peso quantizzato male può far generare parentesi sbagliate
Ragionamento matematico: Q5_K_M o superiore. Le catene logiche lunghe amplificano gli errori di quantizzazione
Chat generica: Q4_K_M basta. La conversazione è più "robusta" alla quantizzazione
Traduzione: Q4_K_M basta. Il pattern linguistico è resiliente

Benchmark Reali: Quanto È Veloce?

I numeri dipendono dall'hardware, ma ecco riferimenti reali del 2026:

Su GPU (NVIDIA RTX 4090, 24GB VRAM)

Modello	Quantizzazione	Velocità	Note
Llama 3.1 8B	Q4_K_M (GGUF)	~95 tok/s	Conversazione fluida
Qwen 3.5 9B	Q4_K_M (GGUF)	~85 tok/s	Eccellente
Qwen 3.5 27B	Q4_K_M (GGUF)	~35 tok/s	Buono, leggero ritardo
Llama 3.1 8B	INT4 (GPTQ)	~140 tok/s	Con ExLlama v2

Su Apple Silicon (MacBook Pro M3 Pro, 18GB)

Modello	Quantizzazione	Velocità	Note
Llama 3.1 8B	Q4_K_M	~45 tok/s	Fluido
Qwen 3.5 9B	Q4_K_M	~38 tok/s	Buono
Qwen 3.5 27B	Q4_K_M	~12 tok/s	Usabile ma lento

Su CPU (Intel i7-13700, 32GB RAM)

Modello	Quantizzazione	Velocità	Note
Llama 3.1 8B	Q4_K_M	~18 tok/s	Accettabile
Qwen 3.5 9B	Q4_K_M	~15 tok/s	Usabile
Qwen 3.5 27B	Q4_K_M	~5 tok/s	Lento, ma funziona

Per riferimento: la velocità di lettura media è ~4 parole al secondo, quindi ~5-6 token/secondo. Qualsiasi cosa sopra i 10 tok/s è "tempo reale percepito" — leggi più lento di quanto il modello generi.

Qwen 3.5 sul Tuo PC: La Guida Pratica

Colleghiamo tutto. Ieri abbiamo visto che Qwen 3.5 ha modelli da 0.8B a 397B. Ecco quali girano sul tuo hardware:

Il setup consigliato per scenario

Laptop con 8GB RAM (il minimo):

ollama run qwen3.5:4b

Il 4B in Q4_K_M occupa ~2.5GB. Lascia spazio per il sistema e una finestra di contesto ragionevole. Per coding semplice e chat, funziona.

Laptop con 16GB RAM (il sweet spot):

ollama run qwen3.5:9b

Il 9B in Q4_K_M occupa ~5GB. Prestazioni da frontier su GPQA Diamond (81.7 — batte modelli 13x più grandi). Il rapporto qualità/risorse migliore.

Desktop con 32GB RAM o GPU 24GB:

ollama run qwen3.5:27b

Il 27B denso in Q4_K_M occupa ~15GB. Performance da GPT-5 mini su SWE-bench (72.4). Su GPU 24GB gira interamente in VRAM — velocissimo.

Workstation o server:

ollama run qwen3.5:35b

Il 35B MoE (3B attivi) in Q4_K_M occupa ~20GB. Attiva solo 3B parametri per token — veloce come un 3B, intelligente come un 35B.

I Limiti della Quantizzazione

La quantizzazione non è magia. Ha limiti reali che è importante conoscere:

1. Non tutte le task degradano allo stesso modo

Le task che richiedono ragionamento lungo e preciso (matematica multi-step, coding complesso) sono più sensibili alla quantizzazione. Un errore minuscolo in un peso si propaga attraverso molti step di ragionamento.

Le task "larghe" (chat, riassunti, traduzione) sono più robuste — c'è ridondanza sufficiente per assorbire gli errori.

2. I modelli piccoli soffrono di più

Un modello da 70B ha abbastanza ridondanza che la quantizzazione a 4 bit lo danneggia poco. Un modello da 3B ha meno margine — ogni peso conta di più. Per modelli sotto i 7B, considera Q5_K_M invece di Q4_K_M.

3. La finestra di contesto costa

La quantizzazione comprime i pesi, non la KV cache (la memoria del contesto). Una finestra da 32K token può occupare 4-8GB di RAM aggiuntiva, indipendentemente dalla quantizzazione.

Se usi un modello Q4_K_M da 5GB con una finestra da 32K, il consumo reale potrebbe essere 10-12GB. Tienilo a mente.

4. Sotto i 4 bit, si rompe

A 3 bit il modello inizia a perdere coerenza su task complessi. A 2 bit genera output degradato visibilmente. A 1.5 bit (sì, esiste) è un esperimento accademico, non un tool utile.

Il floor pratico è 4 bit. È lì che il rapporto qualità/compressione è ottimale.

Il Quadro Completo

La quantizzazione è il motivo per cui il 2026 è l'anno dell'AI locale. Non perché i modelli siano diventati piccoli — sono diventati comprimibili senza perdite significative.

I numeri parlano chiaro:

Q4_K_M: -75% di memoria, -0.9% di qualità. Un trade-off che non ha senso non fare
Ollama: da zero a LLM funzionante in un comando
Qwen 3.5 9B quantizzato: batte modelli 13x più grandi su benchmark scientifici, gira su un laptop da 16GB

E i vantaggi vanno oltre le performance:

Privacy totale: nessun dato esce dal tuo dispositivo
Zero costo per token: dopo il download iniziale, ogni inferenza è gratis
Zero latenza di rete: la risposta inizia istantaneamente
Nessun vendor lock-in: il modello è tuo, il formato è aperto

Il gap tra modelli cloud e modelli locali si chiude un po' ogni mese. I modelli cloud restano superiori per i task più complessi (refactoring multi-file, ragionamento lungo). Ma per il 70% del lavoro quotidiano — completamento codice, spiegazioni, refactoring locale, chat — un modello locale quantizzato è abbastanza buono e infinitamente più privato.

Se non hai mai provato, oggi è il giorno giusto. ollama run qwen3.5:9b. Cinque minuti, zero config, e hai un assistente AI sul tuo PC che non parla con nessuno.

Fonti: