Quantizzazione Ollama: q4_K_M, q8_0 o fp16?

Cosa cambia la quantizzazione di Ollama

La quantizzazione di Ollama memorizza ogni peso di un modello con un numero di bit inferiore rispetto al file usato per l'addestramento. Un tag che termina con q4_K_M usa circa quattro bit per peso, mentre fp16 ne usa sedici. Di conseguenza, il download è grande circa un terzo e la macchina legge circa un terzo dei byte per generare ogni token. I pesi vengono arrotondati su una griglia più grossolana, non eliminati. Con quattro bit, la maggior parte dei modelli risponde in modo simile alla versione a precisione completa.

Questo è l'intero compromesso: un ingombro molto inferiore in memoria e più token al secondo, a fronte di una lieve perdita di accuratezza. Di seguito viene spiegato come prevedere entrambi gli aspetti per un modello specifico su un server specifico, prima di dedicare venti minuti al download di un file che non potrà essere contenuto nella memoria disponibile.

Se Ollama non è ancora in esecuzione, inizia da installare Ollama su un VPS. Questa pagina presuppone che ollama ls funzioni già.

Come leggere un tag di quantizzazione Ollama come q4_K_M

I modelli locali vengono distribuiti come file GGUF, il formato usato da llama.cpp per memorizzare i pesi su disco. Ollama si basa su llama.cpp, quindi i tag Ollama mantengono invariati i nomi delle quantizzazioni di llama.cpp.

Il numero indica la larghezza target. q4 significa che la maggior parte dei tensori dei pesi è impacchettata a quattro bit per peso. q8 significa otto bit. fp16 non è quantizzato: rappresenta il modello in virgola mobile a sedici bit, la precisione con cui viene pubblicata la maggior parte dei modelli.

K indica una quantizzazione K. I pesi vengono raggruppati in piccoli blocchi e ogni blocco memorizza il proprio fattore di scala accanto ai valori impacchettati. Un blocco in cui tutti i pesi sono vicini a 0.01 usa un fattore di scala più preciso. Un blocco che contiene un valore anomalo elevato ne usa uno più ampio. Sono questi fattori di scala per blocco a rendere utilizzabile un file a quattro bit; per lo stesso motivo, un file a quattro bit non occupa mai esattamente quattro bit per peso.

L'ultima lettera indica la combinazione. S, M e L determinano quanti tensori vengono memorizzati con una larghezza superiore a quella target. In q4_K_M, i tensori che subiscono la maggiore perdita quando vengono arrotondati sono memorizzati con una larghezza maggiore, mentre la maggior parte dei dati resta a quattro bit. Per questo q4_K_M produce un output migliore rispetto al precedente q4_0, con dimensioni del file quasi identiche.

Chiedi a Ollama quali modelli sono presenti su disco invece di dedurre il formato dal nome digitato:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show stampa architecture, parameters, quantization, context length e embedding length. La riga quantization è il riferimento effettivo per un modello che hai scaricato mesi fa e non ricordi più di aver scelto.

I bit per peso determinano la dimensione del file

Ogni stima delle dimensioni parte da un numero: quanti bit il formato usa per peso, in media sull'intero file. llama.cpp pubblica valori misurati per Llama 3.1 8B nella documentazione di quantize; questi valori sono validi anche per qualsiasi modello denso di forma simile.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

La sorpresa nella tabella è la seconda colonna. Q4_K_M non usa quattro bit per peso. Il valore misurato è di 4.89 bit, perché anche gli scale dei blocchi e i tensori promossi occupano spazio. Q8_0 usa 8.5 bit invece di otto, per lo stesso motivo. Usa il valore misurato e il calcolo si discosterà di pochi punti percentuali dalle dimensioni effettive del file:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Questo è il file Q4_K_M da 4.58 GiB, ricavato da due numeri. È anche, con buona approssimazione, la memoria occupata dai pesi una volta caricati. Ollama non decomprime nulla al caricamento: i pesi quantizzati restano in memoria nello stesso formato compresso e ogni blocco viene convertito quando viene utilizzato.

Cosa distribuisce realmente Ollama per ogni dimensione del modello

La libreria pubblica un tag q4_K_M, un tag q8_0 e un tag fp16 per la maggior parte delle famiglie. Alcune famiglie più recenti non seguono questo schema e nella libreria compaiono soltanto come tag cloud, senza nulla da scaricare a qualsiasi dimensione. È questo il limite che si incontra quando si tenta di eseguire GLM 5.2 su un VPS. Queste sono le dimensioni di Qwen3 a ottobre 2026, ricavate dall’elenco dei tag nella pagina del modello. Ogni valore riportato di seguito indica lo spazio su disco prima che il modello venga caricato nella RAM; inoltre, due o tre modelli insieme possono riempire il volume root di un VPS di piccole dimensioni. Conviene quindi sapere dove Ollama salva i modelli scaricati prima di iniziare a raccogliere tag.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

Il tag predefinito è importante. ollama pull qwen3:8b scarica esattamente gli stessi 5.2 GB di ollama pull qwen3:8b-q4_K_M, perché il tag senza suffisso è la build q4_K_M. Q4_K_M non è un compromesso offerto dalla libreria solo perché non ci sono alternative migliori. È il formato predefinito scelto dal progetto upstream, quindi adeguarsi a questo formato è il primo approccio sensato per qualsiasi modello non ancora testato direttamente. Lo stesso criterio guida la scelta dei tag in eseguire Qwen 3 su un VPS.

I rapporti restano validi per ogni riga. Passare da q4_K_M a q8_0 richiede circa il settanta per cento di spazio in più, non esattamente il doppio, perché i tensori di embedding e output non aumentano nella stessa proporzione del resto. fp16 occupa all’incirca tre volte lo spazio di q4_K_M. Un modello 32B in q4_K_M contiene 20 GB di pesi, una quantità già superiore a quella che un sistema con 16 GB può contenere insieme a una finestra di contesto, anche minima. Per una panoramica più ampia dei modelli compatibili con ciascun tipo di macchina, vedere quali modelli è possibile eseguire in self-hosting.

Perché la cache KV è un costo aggiuntivo dipendente dal contesto

I pesi rappresentano il costo fisso. La cache KV (cache delle chiavi e dei valori) rappresenta il costo variabile. Ogni token nella finestra di contesto conserva i propri vettori key e value per ogni layer, quindi la cache cresce linearmente con la dimensione della finestra consentita. Viene allocata per l'intera finestra quando il modello viene caricato, non man mano che la conversazione si estende. Per questo una finestra lunga consuma memoria anche con un prompt di una sola parola.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Quei numeri del modello derivano dalla configurazione del modello: 36 layer, 8 teste key/value e una dimensione della testa pari a 128. ollama show fornisce l'architettura e il numero di parametri, mentre la config.json del modello su Hugging Face fornisce gli altri dati. Moltiplicando il costo per token per la dimensione della finestra, la cache non è più un errore di arrotondamento.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Con 4096 token, la finestra predefinita scelta da Ollama quando sono disponibili meno di 24 GiB di VRAM (incluso un VPS con il solo uso della CPU), la cache aggiunge 0.6 GB ai pesi. Aumentando la finestra a 32k, la sola cache raggiunge 4.83 GB. È quasi la stessa quantità di memoria occupata dai pesi quantizzati e porta il requisito minimo dell'intero modello a 10 GB. Si parla di requisito minimo perché a questo valore vanno aggiunti i buffer di calcolo e la memoria del sistema operativo. Dopo il caricamento del modello, leggere il valore effettivo nella colonna SIZE di ollama ps. Su una GPU con 24-48 GiB di VRAM la finestra predefinita è 32k, mentre da 48 GiB in su è 256k. Su una scheda con molta memoria, quindi, non bisogna assumere il valore di 4k.

La finestra viene impostata sul server, non per richiesta, quando si esegue Ollama come servizio:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Con un'installazione systemd, inserirla invece in un drop-in:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Riavviare con sudo systemctl restart ollama, quindi controllare la colonna CONTEXT di ollama ps per verificare con quale finestra il modello in esecuzione è stato effettivamente caricato. OLLAMA_KV_CACHE_TYPE esegue la quantizzazione della cache stessa: f16 è il valore predefinito, q8_0 utilizza circa metà della memoria usata da f16 e q4_0 circa un quarto. È un'opzione globale, quindi tutti i modelli sul server ricevono lo stesso trattamento. La quantizzazione della cache ha effetto solo quando Flash Attention è abilitato. Ollama lo abilita automaticamente quando il backend lo supporta, mentre OLLAMA_FLASH_ATTENTION=1 lo forza. Su un server con risorse limitate e una finestra lunga, dimezzare la cache libera più memoria di qualsiasi altra modifica singola. Impostazione di num_ctx e relativo costo descrive in dettaglio la finestra. La cache viene inoltre dimensionata una volta per ogni slot di richiesta concorrente, non una volta per server. Consentire a Ollama di rispondere contemporaneamente a due prompt raddoppia quindi il valore appena calcolato. Questo è il calcolo alla base di scelta del numero di slot paralleli e del limite della coda.

Cosa entra in un VPS da 8, 16 o 32 GB

Considerate i pesi del modello, la KV cache, il margine per il sistema operativo e qualsiasi altro processo in esecuzione. Su un VPS di piccole dimensioni, 2 GB di margine sono una quantità adeguata.

8 GB. Un modello 4B con q4_K_M occupa 2.6 GB e lascia spazio per una finestra di contesto lunga. Un modello 8B con q4_K_M entra con la finestra predefinita di 4k, ma lascia pochissimo margine. Non pianificate di usare un modello 8B con una finestra di 32k, perché il limite minimo di 10 GB supera già la memoria disponibile sul VPS.

16 GB. Un modello 8B con q4_K_M e una finestra di 16k o 32k entra agevolmente. Un modello 14B con q4_K_M occupa 9.3 GB di pesi e funziona con una finestra di dimensioni moderate. Un modello 8B con q8_0 occupa 8.9 GB, quindi entra anch'esso. Confrontare questi due modelli sui vostri prompt è il modo più utile per dedicare un'ora a questo argomento.

32 GB. Un modello 14B con q8_0 (16 GB) e un modello 32B con q4_K_M (20 GB) vengono caricati entrambi. La build 32B con una finestra ampia si avvicinerà al limite, quindi monitorate ollama ps invece di dare per scontato che ci sia memoria sufficiente.

Cosa degrada per primo con la quantizzazione

L'errore di quantizzazione non si distribuisce in modo uniforme sulle capacità del modello. La fluidità è l'ultima a risentirne. Proprio per questo il danno è facile da non rilevare: un modello quantizzato male continua a generare frasi corrette. La precisione è la prima a degradarsi. Il recupero esatto del numero di versione, della firma di un'API o di una data. Anche le catene di ragionamento lunghe, in cui un piccolo errore al passaggio due produce una risposta errata al passaggio otto. E i formati di output rigidi, in cui una parentesi errata fa fallire una chiamata a uno strumento.

Quest'ultimo è il test pratico. Quando un modello deve restituire JSON che il codice analizza, il danno della quantizzazione si manifesta come un errore di parsing e non come una prosa semplicemente peggiore. In questo modo lo rilevi lo stesso giorno. Un agente di coding è la versione più severa di questo test, perché usa il modello per eseguire una chiamata a uno strumento dopo l'altra. Per questo, indirizzare un agente al tuo server Ollama farà emergere una quantizzazione troppo aggressiva nel giro di un pomeriggio.

Al di sotto dei quattro bit, la perdita aumenta rapidamente. I tipi q3 e a due bit sono pensati per chi deve eseguire un modello di grandi dimensioni su hardware limitato e rappresentano un'opzione concreta quando l'alternativa è non eseguire affatto il modello. Non sono una scelta predefinita consigliabile. La differenza tra q4_K_M e q8_0 è abbastanza ridotta da rendere insufficiente, per il tuo carico di lavoro, una tabella pubblicata della perplexity. Non cercare quindi di decidere in questo modo. Esegui entrambi i modelli su trenta prompt di tua proprietà e confronta l'output.

Quando q8_0 o fp16 giustificano l'uso della RAM

Usa q8_0 quando la memoria è realmente disponibile e il compito penalizza gli errori anche piccoli: estrazione strutturata, chiamate a strumenti e codice che deve essere compilato. In questo caso stai acquistando una garanzia, non un modello sensibilmente più intelligente.

Usa fp16 solo per due motivi. Stai quantizzando personalmente il modello e ti serve il file sorgente, oppure stai misurando una baseline per capire quanto hai perso con la build a quattro bit. Eseguire il modello in fp16 usa tre volte la memoria richiesta da q4_K_M, a fronte di una differenza che la maggior parte delle persone non riesce a distinguere in un test alla cieca; inoltre, su un sistema con sola CPU, riduce a un terzo anche il numero di token al secondo.

La regola più importante, a parità di memoria disponibile, è questa: un modello più grande in q4_K_M di solito supera un modello più piccolo in q8_0. 9.3 GB di pesi 14B contro 8.9 GB di pesi 8B richiedono quasi la stessa RAM (random access memory), ma il modello più grande contiene più conoscenze. Verifica questo comportamento con i tuoi prompt, invece di accettarlo senza verificarlo.

L’inferenza eseguita solo sulla CPU è limitata dalla larghezza di banda della memoria

La maggior parte dei piani VPS non include una GPU, quindi il modello viene eseguito nella memoria di sistema tramite la CPU dell’host. La generazione è quindi limitata dalla larghezza di banda della memoria, non dalla capacità di calcolo, perché per produrre ogni token è necessario leggere tutti i pesi una volta. Ne deriva un limite massimo che non dipende dal numero di core acquistati.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

50 GB/s è all’incirca il valore teorico per un host con memoria DDR4-3200 a doppio canale. La larghezza di banda effettivamente disponibile è inferiore, perché un VPS condivide quel bus con tutti gli altri tenant della macchina. Considera quindi questi valori come un limite massimo che non viene raggiunto da nessuno. L’aspetto utile è l’andamento: sulla CPU, dimezzare i bit per peso raddoppia all’incirca il numero di token generati al secondo. La quantizzazione è il principale fattore di velocità disponibile su una macchina senza GPU. La velocità ottenuta sia sufficiente dipende dal modello; Nemotron 3.5 Lightning su un VPS verifica questo calcolo per una build e un tag specifici, includendo anche il valore della RAM. L’altro fattore che determina il tempo di attesa è la quantità di testo che il modello decide di generare: a 10 token al secondo, una risposta di 600 token richiede un minuto intero. Per questo motivo, limitare la risposta con num_predict spesso riduce il tempo di attesa più di un ulteriore passaggio a una precisione inferiore.

L’elaborazione del prompt funziona in modo diverso. La lettura di un prompt lungo è limitata dalla capacità di calcolo, non dalla larghezza di banda. I core aggiuntivi sono quindi utili in questa fase, ma incidono poco sulla velocità di generazione. Una macchina che acquisisce rapidamente un prompt di 4k e poi genera lentamente si comporta normalmente.

Non considerare attendibili questi calcoli senza verificarli. Misura i token al secondo sulla tua macchina usando lo stesso prompt per ogni livello di quantizzazione, e considera i tuoi valori più affidabili di queste stime.

Quantizzare personalmente un modello

Questo è necessario quando hai eseguito un fine-tuning e non esiste alcun tag per la libreria. La procedura dipende dal formato finale desiderato, perché Ollama non produce più i K-quant GGUF misurati in questa pagina.

Per un K-quant come q4_K_M, esegui la quantizzazione prima che Ollama elabori il file. Ollama non quantizza i modelli GGUF durante l'importazione e rifiuta --quantize quando la sorgente è un file GGUF. Quantizza il file GGUF non quantizzato con llama-quantize di llama.cpp, quindi importa il file risultante. Questa procedura di importazione presenta un problema specifico: una mancata corrispondenza del template di chat può indurre il modello a rispondere con testo senza senso. La guida importare un file GGUF in Ollama descrive come gestirlo. La riga quantization di ollama show consente di verificare che il file importato sia la build prevista.

--quantize di Ollama funziona soltanto con importazioni di file safetensors. Imposta un Modelfile in modo che punti alla directory che contiene i pesi safetensors non quantizzati:

FROM /path/to/safetensors/directory

Quindi esegui la build:

ollama create --quantize int4 mymodel

A partire da Ollama v0.40.2 (verificato il 2026-10-11), --quantize accetta int4, int8, nvfp4, mxfp4 e mxfp8. q4 e q8, oltre a fp4 e fp8, vengono interpretati come alias di int4 e int8. I nomi GGUF come q4_K_M, q4_K_S, q8_0, q6_K e q5_K_M vengono rifiutati con un errore unsupported quantize type. Questi tipi non corrispondono ai K-quant GGUF nelle tabelle precedenti. Non usare quindi i valori di bit per peso e dimensione del file riportati in questa pagina per prevedere i risultati relativi a questi tipi.

Cosa vedrai quando qualcosa non funziona

Tutto viene eseguito sulla CPU anche se ti aspettavi l'uso della GPU. Leggi la colonna PROCESSOR:

ollama ps

Il comando restituisce 100% GPU, 100% CPU oppure una suddivisione come 48%/52% CPU/GPU. Una suddivisione indica che i pesi e la KV cache non entrano nella VRAM (video RAM, la memoria della scheda grafica), quindi una parte del modello è stata collocata nella memoria di sistema. La velocità scende quasi al livello della sola CPU, perché ogni token deve attendere la parte più lenta. Riduci la finestra di contesto, quantizza la cache oppure usa una build più piccola. Aggiungere core non risolve il problema.

Il modello viene terminato durante il caricamento. Controlla il kernel e il log del servizio:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Una riga contenente Out of memory: Killed process indica che il totale di pesi, KV cache e buffer ha superato la memoria disponibile sul sistema. Su una VPS senza swap configurato, l'intera macchina può bloccarsi per diversi secondi prima che venga visualizzata quella riga.

Le risposte sono peggiorate e non hai modificato nulla. Due build dello stesso modello possono trovarsi una accanto all'altra in ollama ls con tag diversi, e uno script che scarica il nome senza suffisso seguirà il riferimento a cui la libreria lo associa in quel momento. Esegui ollama show usando il tag esatto richiesto dal client e leggi la riga quantization, invece di fare affidamento sul nome nel file di configurazione.

FAQ

Quale quantizzazione Ollama devo scaricare?

Inizia con q4_K_M. È il tag predefinito utilizzato dalla libreria Ollama per la maggior parte dei modelli, quindi ollama pull qwen3:8b e ollama pull qwen3:8b-q4_K_M scaricano lo stesso file. Passa a q8_0 solo quando hai memoria disponibile e l'attività penalizza gli errori ridotti, ad esempio nel tool calling o nell'output JSON strutturato. Quando il budget di memoria è fisso, un modello più grande a q4_K_M offre generalmente risultati migliori di un modello più piccolo a q8_0. Verifica quindi questa combinazione prima di usare RAM aggiuntiva per aumentare la precisione.

q4_K_M significa davvero quattro bit per peso?

No. Misurato su Llama 3.1 8B, il valore è di 4.89 bit per peso, perché ogni blocco di pesi memorizza il proprio fattore di scala e i tensori più sensibili vengono promossi a un tipo più ampio. Per lo stesso motivo, Q8_0 misura 8.5 bit invece di otto. Per le stime, usa il valore misurato: il numero di parametri moltiplicato per i bit per peso, diviso per otto, restituisce la dimensione del file in byte.

Quanta RAM richiede un modello 8B su un VPS che usa solo la CPU?

Somma i pesi, la cache KV e il margine di sicurezza. Qwen3 8B a q4_K_M occupa 5.2 GB per i pesi. Con la finestra predefinita di 4096 token, la cache aggiunge 0.6 GB, per un minimo di circa 5.8 GB, prima di considerare i buffer di calcolo e il sistema operativo. Con una finestra di 32k, la sola cache occupa 4.83 GB. Prevedi 8 GB per una finestra breve e 16 GB per una finestra lunga.

Perché il modello usa il 100% della CPU se il server dispone di una GPU?

Esegui ollama ps e leggi la colonna PROCESSOR. 100% CPU, oppure una suddivisione come 48%/52% CPU/GPU, indica che i pesi e la cache KV non entrano nella VRAM. Ollama ha quindi collocato una parte o l'intero modello nella memoria di sistema. La causa più comune è una finestra di contesto più grande della capacità della scheda, perché la cache viene allocata per l'intera finestra quando il modello viene caricato. Riduci la finestra con OLLAMA_CONTEXT_LENGTH, imposta OLLAMA_KV_CACHE_TYPE=q8_0 per dimezzare la cache oppure scarica una quantizzazione più piccola.