Ollama: scegliere tra q4_K_M, q8_0 e 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 durante l'addestramento. Un tag che termina con q4_K_M usa circa quattro bit per peso, mentre fp16 ne usa sedici. Il download ha quindi dimensioni pari a circa un quarto e la macchina legge circa un quarto 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 in memoria molto inferiore 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 trascorrere venti minuti a scaricare un file che non potrà essere contenuto in memoria.

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 di 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 usando quattro bit per peso. q8 significa otto. fp16 non è quantizzato: rappresenta 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 vengono 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 un fattore di scala preciso. Un blocco che contiene un singolo valore anomalo di grandi dimensioni ne usa uno più ampio. Questi fattori di scala per blocco rendono utilizzabile un file a quattro bit e spiegano anche perché un file a quattro bit non usa 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 superiore, 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 una dimensione del file quasi identica.

Chiedi a Ollama quali dati sono presenti su disco, invece di dedurli dal nome inserito:

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, quando non ricordi più quale variante avevi scelto.

I bit per peso determinano la dimensione del file

Ogni stima della dimensione parte da un numero: quanti bit il formato usa per ogni peso, calcolati come media sull'intero file. llama.cpp pubblica valori misurati per Llama 3.1 8B nella documentazione di quantize, applicabili anche a 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 in quella tabella è la seconda colonna. Q4_K_M non usa quattro bit per peso. Il valore misurato è di 4.89 bit, perché le scale dei blocchi e i tensori promossi occupano spazio effettivo. Q8_0 usa 8.5 bit invece di otto, per lo stesso motivo. Usa il valore misurato: il calcolo si discosta di pochi punti percentuali dal file reale:

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 dopo il caricamento. Ollama non espande i pesi durante il 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. Queste sono le dimensioni di Qwen3 ad agosto 2026, ricavate dall'elenco dei tag nella pagina del modello.

[
  {
    "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 controvoglia. È il formato predefinito scelto dal progetto upstream, quindi adottarlo è il primo passo più sensato per qualsiasi modello che non sia stato testato direttamente. 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 settanta per cento di spazio in più, non esattamente il doppio, perché i tensori di embedding e di output non aumentano nella stessa proporzione del resto. fp16 richiede circa il triplo dello spazio di q4_K_M. Un modello 32B in q4_K_M occupa 20 GB di pesi, una quantità già superiore a quella che un server con 16 GB può contenere insieme a una finestra di contesto, anche minima. Per una panoramica più ampia dei modelli compatibili con ciascun server, consulta quali modelli puoi eseguire in self-hosting.

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

I pesi rappresentano il costo fisso. La KV cache (cache delle chiavi e dei valori) è 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 configurata. Viene allocata per l'intera finestra quando il modello viene caricato, non man mano che la conversazione si estende. 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 provengono dalla configurazione del modello: 36 layer, 8 head key/value e una dimensione delle head pari a 128. ollama show fornisce l'architettura e il numero di parametri, mentre 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 la finestra predefinita di Ollama, pari a 4096 token, la cache aggiunge 0.6 GB ai pesi. Portando la finestra a 32k, la sola cache raggiunge 4.83 GB. È quasi la stessa quantità di memoria occupata dai pesi quantizzati e il limite minimo per l'intero modello diventa 10 GB. Si parla di limite minimo perché i buffer di calcolo e il sistema operativo richiedono ulteriore memoria. Dopo il caricamento del modello, leggere il valore effettivo nella colonna SIZE di ollama ps.

La finestra viene impostata sul server, non per singola richiesta, quando Ollama viene eseguito 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 è l'impostazione predefinita, q8_0 usa circa metà della memoria di f16 e q4_0 circa un quarto. È un'opzione globale, quindi tutti i modelli del server ricevono lo stesso trattamento. Su un server con risorse limitate e una finestra ampia, dimezzare la cache libera più memoria di qualsiasi altra singola modifica. Impostare num_ctx e comprenderne il costo descrive in dettaglio la finestra stessa.

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

Considera il consumo dei pesi, aggiungi la KV cache 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 con q4_K_M occupa 2.6 GB e lascia spazio per una finestra lunga. Un modello 8B con q4_K_M entra con la finestra predefinita da 4k e lascia pochissimo margine. Non pianificare l'uso di 8B con una finestra da 32k, perché il minimo di 10 GB supera già la memoria disponibile sul VPS.

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

32 GB. 14B con q8_0 (16 GB) e 32B con q4_K_M (20 GB) vengono caricati entrambi. La build 32B con una finestra grande si avvicinerà al limite, quindi monitora 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 tra le capacità di un 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 viene compromessa per prima. Il recupero esatto di un numero di versione, di una firma 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. Lo stesso vale per i formati di output rigidi, in cui una parentesi errata fa fallire una chiamata a uno strumento.

Quest'ultimo caso è il test più pratico. Quando un modello deve restituire JSON che il codice analizza, il danno causato dalla quantizzazione si manifesta come un errore di parsing anziché come un testo semplicemente meno efficace. Di conseguenza, il problema diventa visibile lo stesso giorno. Un agente di programmazione è la versione più severa di questo test, perché esegue una sequenza di chiamate agli strumenti. Per questo indirizzare un agente al tuo server Ollama fa emergere una quantizzazione troppo aggressiva nel giro di un pomeriggio.

Al di sotto di quattro bit, la perdita aumenta rapidamente. I tipi q3 e a due bit servono a chi cerca di eseguire un modello di grandi dimensioni su hardware limitato. Sono una scelta reale quando l'alternativa è non eseguire affatto il modello. Non sono una buona impostazione predefinita. La differenza tra q4_K_M e q8_0 è abbastanza ridotta da rendere insufficiente una tabella pubblicata della perplexity per decidere quale sia adatto al tuo carico di lavoro. Non cercare quindi di decidere in questo modo. Esegui entrambi sui tuoi trenta prompt 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 minimi: estrazione strutturata, chiamate agli strumenti, codice che deve essere compilato. In questo caso acquisti una garanzia aggiuntiva, 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 sacrificato con la build a quattro bit. Eseguire il modello in fp16 richiede tre volte la memoria di q4_K_M per una differenza che la maggior parte delle persone non riesce a distinguere senza conoscere il formato; inoltre, su un sistema dotato solo di CPU, riduce a un terzo anche la velocità di generazione dei token.

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 il risultato con i tuoi prompt invece di accettarlo senza controlli.

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

La maggior parte dei piani VPS non dispone di 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 dai calcoli aritmetici, perché per produrre un token è necessario leggere tutti i pesi una volta. Questo impone 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 è un valore teorico approssimativo per un host con memoria DDR4-3200 a doppio canale. La larghezza di banda disponibile per la tua VPS è inferiore, perché il bus è condiviso con tutti gli altri tenant della macchina. Considera quindi questi valori come un limite massimo che nessuno raggiunge. L’aspetto importante è l’andamento: sulla CPU, dimezzare il numero di bit per peso raddoppia approssimativamente la velocità di generazione dei token. La quantizzazione è il principale parametro per aumentare le prestazioni su una macchina senza GPU.

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

Non accettare questi calcoli senza verificarli. Misura i token al secondo sulla tua macchina usando lo stesso prompt per ogni livello di quantizzazione e considera prevalenti i tuoi risultati.

Creare autonomamente un modello quantizzato

Ollama può creare un modello quantizzato a partire da una sorgente fp16 o fp32. Questo è utile quando si esegue il fine-tuning di un modello e non esiste alcun tag di libreria corrispondente. Indicare i pesi non quantizzati in un Modelfile:

FROM /path/to/my/model/f16

Quindi creare il modello e verificare 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 esiste alcuna opzione q6_K o q5_K_M. Per questi formati, eseguire la quantizzazione con lo strumento incluso in llama.cpp e importare il file GGUF risultante. La riga quantization di ollama show consente di verificare che la compilazione abbia applicato le impostazioni richieste.

Cosa vedrai quando qualcosa non funziona

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

ollama ps

Il comando stampa 100% GPU, 100% CPU oppure una suddivisione come 48%/52% CPU/GPU. Una suddivisione indica che i pesi e la KV cache non entravano 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 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 dei pesi, della KV cache e dei buffer ha superato la memoria disponibile sul sistema. Su un VPS senza swap configurato, l'intera macchina può bloccarsi per diversi secondi prima che compaia quella riga.

Le risposte sono peggiorate anche se non hai modificato nulla. In ollama ls possono coesistere due build dello stesso modello 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 da q4_K_M. È il tag predefinito che la libreria Ollama usa 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 il carico di lavoro penalizza gli errori minimi, ad esempio nelle chiamate agli strumenti o nell’output JSON strutturato. Quando il budget di memoria è fisso, un modello più grande a q4_K_M di solito offre risultati migliori di un modello più piccolo a q8_0. Verifica quindi questa combinazione prima di usare più RAM 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, fornisce la dimensione del file in byte.

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

Considera i pesi, la cache KV e un margine operativo. Qwen3 8B a q4_K_M occupa 5.2 GB per i soli 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. Considera 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 o una suddivisione come 48%/52% CPU/GPU indica che i pesi e la cache KV non entravano 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.