Quantizzazione Ollama: q4 vs q8 vs fp16

Cosa cambia con la quantizzazione di Ollama

La quantizzazione di Ollama memorizza ogni peso di un modello usando meno bit rispetto al file con cui il modello è stato addestrato. Un tag che termina con q4_K_M usa circa quattro bit per peso, mentre fp16 ne usa sedici. Di conseguenza, il download è all'incirca un quarto delle dimensioni e la macchina legge un quarto dei byte per generare ogni token. I pesi vengono arrotondati su una griglia più grossolana, non eliminati, e con quattro bit la maggior parte dei modelli risponde in modo simile a quello ottenuto con la precisione completa.

Questo è l'intero compromesso: un ingombro in memoria molto più ridotto e più token al secondo, a fronte di una piccola perdita di accuratezza. Di seguito viene spiegato come prevedere entrambi gli effetti 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 installazione di 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 di Ollama mantengono invariati i nomi della quantizzazione di llama.cpp.

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

K indica una quantizzazione K. I pesi sono raggruppati in piccoli blocchi e ogni blocco memorizza il proprio fattore di scala accanto ai valori impacchettati. Un blocco i cui pesi sono tutti vicini a 0.01 usa una scala precisa. Un blocco che contiene un valore anomalo di grandi dimensioni usa una scala più ampia. Questi fattori di scala per blocco mantengono utilizzabile un file a quattro bit e spiegano anche perché un file a quattro bit non occupa mai esattamente quattro bit per peso.

L'ultima lettera indica la combinazione. S, M e L stabiliscono 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 pesi 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 dedurlo dal nome che hai immesso:

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 scaricato mesi fa, del quale non ricordi più la variante scelta.

Bit per weight: da qui deriva la dimensione del file

Ogni stima della dimensione parte da un numero: quanti bit il formato utilizza per ogni weight, calcolati come media sull’intero file. llama.cpp pubblica valori misurati per Llama 3.1 8B nella documentazione di quantizzazione. Questi valori sono applicabili anche a qualsiasi modello dense 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 in quella tabella è la seconda colonna. Q4_K_M non usa quattro bit per weight. Il valore è 4.89 bit, perché le scale dei blocchi e i tensori promossi occupano spazio reale. Q8_0 usa 8.5 bit invece di otto, per lo stesso motivo. Usando il valore misurato, il calcolo si avvicina di pochi punti percentuali alla dimensione effettiva 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 weight una volta caricati. Ollama non decomprime nulla durante il caricamento: i weight quantizzati restano in memoria nello stesso formato compresso e ogni blocco viene convertito quando viene utilizzato.

Cosa include effettivamente 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 solo come tag cloud, senza nulla da scaricare a qualsiasi dimensione. È il limite che si incontra quando si prova a eseguire GLM 5.2 su un VPS. Queste sono le dimensioni di Qwen3 ad agosto 2026, ricavate dall’elenco dei tag nella pagina del modello. Ogni valore riportato di seguito indica lo spazio su disco necessario prima ancora che il modello venga caricato nella RAM. Due o tre di questi modelli possono riempire il volume root di un VPS di piccole dimensioni. Prima di iniziare a raccogliere tag, conviene quindi sapere dove Ollama archivia i modelli scaricati.

[
  {
    "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 che la libreria offre a malincuore. È la configurazione predefinita scelta dal progetto upstream. Per questo, usarla come riferimento è il primo approccio più sensato per qualsiasi modello non ancora testato personalmente. Lo stesso criterio determina 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 70% di spazio in più, non esattamente il doppio, perché i tensori di embedding e di output non scalano nello stesso modo del resto del modello. fp16 richiede all’incirca il triplo dello spazio di q4_K_M. Un modello 32B in q4_K_M contiene 20 GB di pesi. È già oltre la capacità di un sistema con 16 GB se si vuole mantenere una qualsiasi context window. Per una panoramica più ampia dei modelli adatti a ogni macchina, vedere quali modelli è possibile eseguire in self-hosting.

Perché la cache KV è un costo aggiuntivo che dipende dal contesto

I pesi rappresentano il costo fisso. La cache KV (cache di key e value) è 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 l’ampiezza della finestra consentita. Viene allocata per l’intera finestra quando il modello viene caricato, non man mano che la conversazione si riempie. Per questo una finestra ampia 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

Questi valori del modello provengono dalla configurazione del modello: 36 layer, 8 key/value head e una dimensione della head pari a 128. ollama show fornisce l'architettura e il numero di parametri, mentre il config.json del modello su Hugging Face fornisce i dati rimanenti. Moltiplica il costo per token per la dimensione della finestra e la cache smette di essere trascurabile.

[
  {
    "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 la finestra predefinita di Ollama, pari a 4096 token, 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 per l'intero modello a 10 GB. Si parla di requisito minimo perché i buffer di calcolo e il sistema operativo richiedono ulteriore memoria. Dopo il caricamento del modello, leggi il valore effettivo nella colonna SIZE di ollama ps.

La finestra viene impostata sul server, non per singola richiesta, quando esegui Ollama come servizio:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

In un'installazione systemd, inseriscila invece in un drop-in:

sudo systemctl edit ollama

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

Riavvia con sudo systemctl restart ollama, quindi controlla la colonna CONTEXT di ollama ps per verificare con quale finestra è stato effettivamente caricato il modello in esecuzione. OLLAMA_KV_CACHE_TYPE quantizza direttamente la cache: f16 è l'impostazione predefinita, q8_0 usa circa la metà della memoria di f16 e q4_0 circa un quarto. È un'opzione globale, quindi tutti i modelli su quel server ricevono lo stesso trattamento. Su una macchina con poca memoria e una finestra ampia, dimezzare la cache libera più memoria di qualsiasi altra singola modifica. Impostare num_ctx e relativo costo descrive in dettaglio la finestra. La cache viene inoltre dimensionata una volta per ogni slot di richieste concorrenti, 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 scegliere il numero di slot paralleli e un limite per la coda.

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

Considera il budget di memoria dei pesi, aggiungi la cache KV e lascia margine per il sistema operativo e per gli altri processi in esecuzione. Su un VPS piccolo, 2 GB di margine sono una quantità adeguata.

8 GB. Un modello 4B a q4_K_M occupa 2.6 GB e lascia spazio per una finestra di contesto ampia. Un modello 8B a q4_K_M entra con la finestra predefinita da 4k, ma lascia pochissimo margine. In questo caso non pianificare l'uso di 8B con una finestra da 32k, perché il limite minimo di 10 GB supera già la memoria disponibile.

16 GB. 8B a q4_K_M con una finestra da 16k o 32k entra comodamente. 14B a q4_K_M occupa 9.3 GB di pesi ed entra con una finestra di dimensioni moderate. 8B a q8_0 occupa 8.9 GB, quindi entra anch'esso. Confrontare questi due modelli sui propri prompt è il modo più utile per impiegare un'ora su questo argomento.

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

Cosa degrada per prima con la quantizzazione

L'errore di quantizzazione non si distribuisce in modo uniforme tra le capacità del modello. La fluidità è l'ultima a risentirne, ed è proprio per questo che il danno è difficile da rilevare: un modello quantizzato male continua a generare frasi corrette. La precisione viene compromessa per prima. Il recupero esatto del numero di versione, della firma di un'API o di una data. Le catene di ragionamento lunghe, in cui un piccolo errore al passaggio due produce una risposta errata al passaggio otto. I formati di output rigidi, in cui una parentesi errata fa fallire una chiamata allo strumento.

Quest'ultimo è il test pratico. Quando un modello deve restituire JSON elaborato dal codice, il danno della quantizzazione si manifesta come un errore di parsing invece che come una prosa semplicemente peggiore, quindi è possibile rilevarlo lo stesso giorno. Un agente di coding è la versione più severa di questo test, perché guida il modello attraverso una sequenza di chiamate agli strumenti; per questo, indirizzare un agente al proprio 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 a q3 e a due bit esistono 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. Sono una scelta predefinita poco indicata. La differenza tra q4_K_M e q8_0 è abbastanza ridotta da rendere insufficiente una tabella pubblicata della perplexity per decidere quale sia più adatta al proprio carico di lavoro; quindi non cercare di stabilirlo in questo modo. Esegui entrambi i modelli su trenta prompt personali e leggi l'output.

Quando q8_0 o fp16 giustificano la RAM

Usa q8_0 quando la memoria è realmente disponibile e il compito penalizza gli errori minimi: estrazione strutturata, chiamate a strumenti, codice che deve compilare. In questo caso acquisti una garanzia di affidabilità, 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 richiede tre volte la memoria di q4_K_M, a fronte di una differenza che la maggior parte delle persone non riesce a distinguere in un confronto alla cieca. Su una macchina con la sola CPU, inoltre, riduce a un terzo la velocità di generazione dei token.

La regola più importante, a parità di memoria disponibile, è questa: un modello più grande in q4_K_M generalmente supera un modello più piccolo in q8_0. 9.3 GB di pesi 14B contro 8.9 GB di pesi 8B richiedono una quantità di RAM (random access memory) quasi identica, ma il modello più grande contiene più conoscenza. Verificalo con i tuoi prompt invece di accettarlo senza test.

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 utilizzando la CPU dell’host. La generazione è quindi limitata dalla larghezza di banda della memoria, non dai calcoli aritmetici, perché per produrre ogni token è necessario leggere tutti i pesi una volta. Ne risulta 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 è approssimativamente 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 nessuno raggiunge. L’aspetto utile è l’andamento: sulla CPU, dimezzare i bit per peso raddoppia approssimativamente il numero di token generati al secondo. La quantizzazione è il principale fattore disponibile per aumentare la velocità su una macchina senza GPU. La velocità risultante sia accettabile dipende dal modello; Nemotron 3.5 Lightning su un VPS applica questo calcolo a una build specifica e include il relativo tag e valore di RAM. L’altra metà dell’attesa dipende dalla quantità di testo che il modello decide di scrivere: a 10 token al secondo, una risposta di 600 token richiede un minuto intero. Per questo limitare la risposta con num_predict spesso riduce i tempi di attesa più di un ulteriore passaggio a una precisione inferiore.

L’elaborazione del prompt si comporta in modo diverso. La lettura di un prompt lungo è limitata dai calcoli, non dalla larghezza di banda, quindi i core aggiuntivi aiutano in questa fase ma incidono quasi per nulla sulla velocità di generazione. Una macchina che acquisisce rapidamente un prompt da 4k e poi genera lentamente si comporta normalmente.

Non considerare attendibili a priori questi calcoli. Misura i token al secondo sulla tua macchina usando lo stesso prompt per ogni livello di quantizzazione e lascia che siano i tuoi valori a prevalere.

Quantificare personalmente un modello

Ollama può creare un modello quantizzato da una sorgente fp16 o fp32. Questo è utile quando hai eseguito il fine-tuning di un modello e non esiste alcun tag di libreria. Indica in un Modelfile i pesi non quantizzati:

FROM /path/to/my/model/f16

Quindi crea il modello e verifica il risultato:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize accetta q8_0, q4_K_S e q4_K_M. Qui non esistono le opzioni q6_K o q5_K_M. Per questi formati, esegui la quantizzazione con lo strumento incluso in llama.cpp e importa il file GGUF risultante. Questa procedura di importazione presenta un problema specifico: una mancata corrispondenza del modello di chat può causare risposte senza senso. La guida importare un file GGUF in Ollama descrive la procedura. La riga quantization di ollama show consente di verificare che la compilazione abbia eseguito l'operazione richiesta.

Cosa vedrai quando qualcosa non funziona

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

ollama ps

Mostra 100% GPU, 100% CPU oppure una suddivisione come 48%/52% CPU/GPU. Una suddivisione indica che i pesi e la cache KV non entrano nella VRAM (video RAM, la memoria della scheda grafica), quindi una parte del modello è stata collocata nella memoria di sistema. La velocità si avvicina così a quella della sola CPU, perché ogni token deve attendere la parte più lenta. Riduci la finestra di contesto, quantizza la cache oppure scarica 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, cache KV 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 anche se non hai modificato nulla. Due build dello stesso modello possono trovarsi affiancate 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 affidarti al nome presente nel file di configurazione.

FAQ

Quale quantizzazione di Ollama devo scaricare?

Inizia con q4_K_M. È il tag predefinito che la libreria Ollama rilascia 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 in genere q4_K_M supera un modello più piccolo in q8_0, quindi prova questa combinazione prima di dedicare RAM aggiuntiva alla 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, dà la dimensione del file in byte.

Quanta RAM richiede un modello 8B su un VPS con sola CPU?

Considera i pesi, la cache KV e un margine operativo. Qwen3 8B in 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 includere 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 entravano nella VRAM, quindi Ollama ha collocato una parte o tutto il modello nella memoria di sistema. La causa usuale è 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.