Ollama kwantisatie: Q4, Q8 en fp16 vergelijking

Wat Ollama-kwantisatie verandert

Ollama-kwantisatie slaat elk gewicht in een model op met minder bits dan het bestand waarin het getraind is. Een tag die eindigt op q4_K_M behoudt ongeveer vier bits per gewicht, terwijl fp16 er zestien behoudt. Hierdoor is de download ongeveer een kwart van de grootte en leest de machine een kwart van het aantal bytes om elk token te produceren. De gewichten worden afgerond op een grof raster en niet verwijderd; bij vier bits antwoorden de meeste modellen bijna op dezelfde manier als bij volledige precisie.

Dat is de hele afweging: een veel kleiner geheugengebruik en meer tokens per seconde, in ruil voor een klein verlies aan nauwkeurigheid. Hieronder staat hoe u beide kanten hiervan kunt voorspellen voor een specifiek model op een specifieke machine, voordat u twintig minuten besteedt aan het downloaden van een bestand dat niet past.

Als Ollama nog niet draait, begin dan met Ollama installeren op een VPS. Deze pagina gaat ervan uit dat ollama ls al werkt.

Hoe u een Ollama-kwantisatietag zoals q4_K_M leest

Lokale modellen worden uitgebracht als GGUF-bestanden, het formaat dat llama.cpp gebruikt om gewichten op schijf op te slaan. Ollama is gebouwd op llama.cpp, dus Ollama-tags dragen de kwantisatienamen van llama.cpp ongewijzigd over.

Het getal is de doelbreedte. q4 betekent dat de meeste gewichtstensoren zijn verpakt op vier bits per stuk. q8 betekent acht. fp16 is helemaal niet gekwantiseerd: het is het model in zestien-bits floating point, de precisie waarin de meeste modellen worden gepubliceerd.

K markeert een K-quant. Gewichten worden gegroepeerd in kleine blokken en elk blok slaat zijn eigen schaal op naast de verpakte waarden. Een blok waarvan de gewichten allemaal dicht bij 0.01 liggen, krijgt een fijne schaal. Een blok dat één grote uitschieter bevat, krijgt een grove schaal. Die schalen per blok zorgen ervoor dat een vier-bits bestand bruikbaar blijft, en ze zijn ook de reden dat een vier-bits bestand nooit exact vier bits per gewicht is.

De laatste letter is de mix. S, M en L bepalen hoeveel tensoren worden gepromoveerd tot boven de doelbreedte. In q4_K_M worden de tensoren die het meest te lijden hebben onder afronding breder opgeslagen, terwijl het grootste deel op vier bits blijft. Daarom produceert q4_K_M betere output dan de oudere q4_0 bij vrijwel dezelfde bestandsgrootte.

Vraag Ollama wat er op schijf staat in plaats van te gokken op basis van de naam die u heeft getypt:

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

ollama show toont architecture, parameters, quantization, context length en embedding length. De quantization-regel is de feitelijke waarheid voor een model dat u maanden geleden heeft binnengehaald en waarvan u niet meer weet welke u destijds heeft gekozen.

Bits per gewicht bepaalt de bestandsgrootte

Elke schatting van de grootte begint bij één getal: hoeveel bits het formaat per gewicht gebruikt, gemiddeld over het gehele bestand. llama.cpp publiceert gemeten waarden voor Llama 3.1 8B in de documentatie over quantize, en deze zijn goed toepasbaar op elk dense model met een vergelijkbare structuur.

[
  {
    "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
  }
]

De verrassing in die tabel is de tweede kolom. Q4_K_M is niet vier bits per gewicht. Het meet 4.89 bits, omdat de blokschaling en de gepromoveerde tensors beide daadwerkelijk ruimte in beslag nemen. Q8_0 meet 8.5 bits in plaats van acht, om dezelfde reden. Gebruik het gemeten getal en de berekening komt binnen enkele procenten uit op de werkelijke bestandsgrootte:

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

Dat is het 4.58 GiB Q4_K_M-bestand, afgeleid van twee getallen. Het is ook, bij benadering, het geheugen dat de gewichten innemen zodra ze zijn geladen. Ollama pakt niets uit bij het laden: de gequantiseerde gewichten blijven in het geheugen in dezelfde verpakte vorm en elk blok wordt geconverteerd op het moment dat het wordt gebruikt.

Wat Ollama daadwerkelijk meelevert voor elke modelgrootte

De bibliotheek publiceert voor de meeste families een q4_K_M, een q8_0 en een fp16 tag. Dit zijn de Qwen3-groottes per augustus 2026, afgelezen van de taglijst op de modelpagina.

[
  {
    "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
  }
]

De standaardtag is hier van belang. ollama pull qwen3:8b downloadt exact dezelfde 5.2 GB als ollama pull qwen3:8b-q4_K_M, omdat de tag zonder achtervoegsel de q4_K_M-build is. Q4_K_M is geen compromis dat de bibliotheek met tegenzin aanbiedt. Het is de standaard die upstream heeft gekozen, dus deze aanhouden is de meest logische eerste stap voor elk model dat u niet zelf heeft getest. Dezelfde redenering bepaalt de tagkeuzes in Qwen 3 draaien op een VPS.

De verhoudingen blijven in elke rij gelijk. Overstappen van q4_K_M naar q8_0 kost ongeveer zeventig procent meer in plaats van exact het dubbele, omdat de embedding- en output-tensoren niet op dezelfde manier schalen als de rest. fp16 is ruwweg drie keer zo groot als q4_K_M. Een 32B-model op q4_K_M is 20 GB aan gewichten, wat al meer is dan wat een 16 GB-server kan bevatten met enige context window. Voor een breder overzicht van wat op welke machine past, zie welke modellen u zelf kunt hosten.

Waarom de KV-cache een tweede, contextafhankelijke kostenpost is

Gewichten vormen de vaste kosten. De KV-cache (key and value cache) is de variabele kostenpost. Elke token in het contextvenster behoudt zijn key- en value-vectoren voor elke laag, waardoor de cache lineair meegroeit met het venster dat u toestaat. Deze wordt bij het laden van het model voor het volledige venster toegewezen, niet pas naarmate het gesprek vordert. Daarom kost een groot venster u geheugen, zelfs bij een prompt van slechts één woord.

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

Deze modelnummers zijn afkomstig uit de configuratie van het model zelf: 36 lagen, 8 key/value-heads en een head-dimensie van 128. ollama show geeft u de architectuur en het aantal parameters, en de config.json van het model op Hugging Face geeft u de rest. Vermenigvuldig de kosten per token met de venstergrootte en de cache is niet langer een verwaarloosbaar detail.

[
  {
    "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
  }
]

Bij het standaardvenster van Ollama van 4096 tokens voegt de cache 0.6 GB toe bovenop de gewichten. Verhoog het venster naar 32k en de cache alleen al bereikt 4.83 GB, wat bijna net zoveel geheugen is als de gekwantiseerde gewichten. De ondergrens voor het gehele model wordt dan 10 GB. We noemen dit een ondergrens omdat rekenbuffers en het besturingssysteem hier nog bovenop komen. Lees de werkelijke waarde af in de SIZE-kolom van ollama ps nadat het model is geladen.

Het venster wordt op de server ingesteld, niet per verzoek, wanneer u Ollama als service uitvoert:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Voor een systemd-installatie plaatst u dit in een drop-in-bestand:

sudo systemctl edit ollama

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

Herstart met sudo systemctl restart ollama en controleer vervolgens de CONTEXT-kolom van ollama ps om te bevestigen met welk venster het draaiende model daadwerkelijk is geladen. OLLAMA_KV_CACHE_TYPE kwantiseert de cache zelf: f16 is de standaard, q8_0 gebruikt ongeveer de helft van het geheugen van f16, en q4_0 ongeveer een kwart. Dit is een globale optie, dus elk model op die server krijgt dezelfde behandeling. Op een kleine machine met een groot venster levert het halveren van de cache meer geheugen op dan enige andere individuele wijziging. Het instellen van num_ctx en de bijbehorende kosten behandelt het venster zelf in detail.

Wat past er op een 8, 16 of 32 GB VPS

Budget voor gewichten, plus KV-cache, plus reservering voor het besturingssysteem en andere actieve processen. Een reservering van 2 GB is comfortabel op een kleine VPS.

8 GB. Een 4B-model op q4_K_M is 2.6 GB en laat ruimte over voor een lang contextvenster. Een 8B-model op q4_K_M past met het standaardvenster van 4k, maar met zeer weinig speling. Plan hier geen 8B-model met een 32k-venster, omdat de ondergrens van 10 GB de capaciteit van de server al overschrijdt.

16 GB. Een 8B-model op q4_K_M met een 16k- of 32k-venster is comfortabel. Een 14B-model op q4_K_M verbruikt 9.3 GB aan gewichten en past met een bescheiden venster. Een 8B-model op q8_0 is 8.9 GB, dus dit past ook. Het vergelijken van deze twee met uw eigen prompts is de meest nuttige tijdsbesteding aan dit onderwerp.

32 GB. Een 14B-model op q8_0 (16 GB) en een 32B-model op q4_K_M (20 GB) kunnen beide worden geladen. De 32B-build met een groot venster zal de limiet opzoeken, dus monitor ollama ps in plaats van uit te gaan van aannames.

Wat degradeert het eerst bij kwantisatie

Kwantisatiefouten verspreiden zich niet gelijkmatig over de prestaties van een model. Vloeiend taalgebruik blijft het langst behouden, en precies daarom is de schade gemakkelijk over het hoofd te zien: een slecht gekwantiseerd model schrijft nog steeds correcte zinnen. Precisie gaat als eerste verloren. Het exact onthouden van een versienummer, een API-signatuur of een datum. Lange redeneerketens, waarbij een kleine fout in stap twee leidt tot een foutief antwoord in stap acht. Strikte uitvoerformaten, waarbij één verkeerd haakje ervoor zorgt dat een tool call faalt.

Dat laatste is de praktische test. Wanneer een model JSON moet retourneren die uw code parseert, manifesteert kwantisatieschade zich als een parse-fout in plaats van als vaag slechter proza, waardoor u het dezelfde dag nog opmerkt. Een coding agent is de strengste versie van die test, omdat deze het model dwingt tot de ene na de andere tool call. Daarom zal het koppelen van een agent aan uw Ollama server een te agressieve kwantisatie binnen een middag blootleggen.

Onder de vier bits wordt het kwaliteitsverlies aanzienlijk. De q3 en twee-bit-types bestaan voor gebruikers die een groot model op beperkte hardware willen draaien, en ze zijn een reële optie wanneer het alternatief is dat het model helemaal niet draait. Het zijn echter slechte standaardinstellingen. Tussen q4_K_M en q8_0 is het verschil klein genoeg dat een gepubliceerde perplexiteitstabel geen uitsluitsel zal bieden voor uw specifieke werklast; probeer het dus niet op die manier te bepalen. Draai beide tegen dertig van uw eigen prompts en beoordeel de uitvoer.

Wanneer q8_0 of fp16 het RAM-gebruik waard is

Gebruik q8_0 wanneer u daadwerkelijk geheugen over heeft en de taak gevoelig is voor kleine fouten: gestructureerde extractie, het aanroepen van tools of code die moet compileren. U koopt hiermee zekerheid, niet per se een merkbaar slimmer model.

Gebruik fp16 om slechts twee redenen. Of u kwantiseert het model zelf en heeft het bronbestand nodig, of u meet een baseline om te bepalen hoeveel uw vier-bit build heeft ingeleverd. Het draaien van fp16 verbruikt drie keer zoveel geheugen als q4_K_M voor een verschil dat de meeste mensen in een blinde test niet kunnen opmerken, en op een systeem dat alleen op een CPU draait, verlaagt het uw token-snelheid bovendien tot een derde.

De belangrijkste regel bij een vast geheugenbudget: een groter model op q4_K_M presteert meestal beter dan een kleiner model op q8_0. 9.3 GB aan 14B gewichten tegenover 8.9 GB aan 8B gewichten verbruikt vrijwel evenveel RAM (random access memory) en het grotere model beschikt over meer kennis. Test dit met uw eigen prompts in plaats van het zomaar aan te nemen.

Inference op alleen de CPU wordt beperkt door geheugenbandbreedte

De meeste VPS-abonnementen beschikken niet over een GPU, waardoor het model in het systeemgeheugen op de host-CPU draait. De generatiesnelheid wordt in dat geval beperkt door de geheugenbandbreedte en niet door rekenkracht, omdat voor het produceren van één token elk gewicht één keer moet worden ingelezen. Dit creëert een bovengrens die losstaat van het aantal CPU-cores waarover u beschikt.

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 is ongeveer de theoretische waarde voor een dual-channel DDR4-3200 host. Uw aandeel is kleiner, omdat een VPS deze bus deelt met alle andere huurders op de machine; beschouw deze getallen daarom als een plafond dat in de praktijk niet wordt bereikt. De verhouding is hier het meest relevant: op een CPU zorgt het halveren van het aantal bits per gewicht voor een ruime verdubbeling van de tokensnelheid. Kwantisatie is de meest effectieve methode om de snelheid te verhogen op een systeem zonder GPU.

De verwerking van prompts gedraagt zich anders. Het inlezen van een lange prompt is rekenintensief in plaats van bandbreedte-intensief, waardoor extra cores hier wel helpen, terwijl ze voor de generatiesnelheid vrijwel niets toevoegen. Een systeem dat een prompt van 4k snel verwerkt en vervolgens traag genereert, vertoont normaal gedrag.

Ga niet uit van theoretische berekeningen. Meet het aantal tokens per seconde op uw eigen systeem met dezelfde prompt bij elke kwantisatie en laat uw eigen resultaten leidend zijn.

Zelf een model kwantiseren

Ollama kan een gekwantiseerd model bouwen vanuit een fp16- of fp32-bron. Dit is relevant wanneer u een model heeft gefinetuned waarvoor nog geen library-tag bestaat. Wijs in een Modelfile naar de ongekwantiseerde gewichten:

FROM /path/to/my/model/f16

Bouw vervolgens het model en controleer het resultaat:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize accepteert q8_0, q4_K_S en q4_K_M. Er is hier geen q6_K- of q5_K_M-optie beschikbaar; voor die formaten kwantiseert u met de eigen tool van llama.cpp en importeert u het voltooide GGUF-bestand. De regel quantization uit ollama show is de manier om te verifiëren of de build het gewenste resultaat heeft opgeleverd.

Wat u ziet wanneer het misgaat

Alles draait op de CPU terwijl u de GPU verwachtte. Lees de kolom PROCESSOR:

ollama ps

Deze toont 100% GPU, 100% CPU, of een splitsing zoals 48%/52% CPU/GPU. Een splitsing betekent dat de gewichten plus de KV-cache niet in het VRAM (video RAM, het geheugen op de videokaart) pasten, waardoor een deel van het model in het systeemgeheugen werd geplaatst. De snelheid daalt dan tot bijna het niveau van alleen de CPU, omdat elk token moet wachten op de trage helft. Verklein het contextvenster, kwantiseer de cache of haal een kleinere build op. Het toevoegen van cores helpt niet.

Het model wordt beëindigd tijdens het laden. Controleer de kernel- en servicelogs:

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

Een regel met Out of memory: Killed process betekent dat het totaal van de gewichten, de KV-cache en de buffers het geheugen van de machine overschreed. Op een VPS zonder geconfigureerde swap kan de gehele machine enkele seconden vastlopen voordat die regel verschijnt.

Antwoorden zijn verslechterd terwijl u niets heeft veranderd. Twee builds van hetzelfde model kunnen naast elkaar in ollama ls staan onder verschillende tags, en een script dat de naam zonder achtervoegsel ophaalt, volgt altijd waar de bibliotheek op dat moment naar verwijst. Voer ollama show uit voor de exacte tag die uw client opvraagt en lees de regel quantization, in plaats van te vertrouwen op de naam in uw configuratiebestand.

FAQ

Welke Ollama-kwantisatie moet ik ophalen?

Begin met q4_K_M. Dit is de standaardtag die de Ollama-bibliotheek meelevert voor de meeste modellen, dus ollama pull qwen3:8b en ollama pull qwen3:8b-q4_K_M halen hetzelfde bestand op. Stap pas over naar q8_0 als er voldoende geheugen beschikbaar is en de taak gevoelig is voor kleine fouten, zoals bij het aanroepen van tools of gestructureerde JSON-output. Bij een vast geheugenbudget presteert een groter model op q4_K_M meestal beter dan een kleiner model op q8_0; test daarom die combinatie voordat u extra RAM toewijst aan precisie.

Betekent q4_K_M echt vier bits per gewicht?

Nee. Gemeten op Llama 3.1 8B is dit 4.89 bits per gewicht, omdat elk blok gewichten zijn eigen schaal opslaat en de meest gevoelige tensors worden opgewaardeerd naar een breder type. Q8_0 meet om dezelfde reden 8.5 bits in plaats van acht. Gebruik het gemeten cijfer bij het schatten: het aantal parameters vermenigvuldigd met de bits per gewicht, gedeeld door acht, geeft de bestandsgrootte in bytes.

Hoeveel RAM heeft een 8B-model nodig op een VPS met alleen een CPU?

Tel de gewichten, de KV-cache en de reserve bij elkaar op. Qwen3 8B op q4_K_M is 5.2 GB aan gewichten. Bij het standaard venster van 4096 tokens voegt de cache 0.6 GB toe, wat neerkomt op een ondergrens van bijna 5.8 GB, nog voor de rekenbuffers en het besturingssysteem. Bij een venster van 32k is de cache alleen al 4.83 GB. Reken op 8 GB voor een kort venster en 16 GB als u een lang venster wilt gebruiken.

Waarom draait mijn model op 100% CPU terwijl de server een GPU heeft?

Voer ollama ps uit en lees de kolom PROCESSOR. 100% CPU, of een verdeling zoals 48%/52% CPU/GPU, betekent dat de gewichten en de KV-cache niet in het VRAM pasten, waardoor Ollama een deel of het gehele model in het systeemgeheugen heeft geplaatst. De gebruikelijke oorzaak is een contextvenster dat groter is dan de kaart kan bevatten, omdat de cache bij het laden van het model voor het volledige venster wordt toegewezen. Verklein het venster met OLLAMA_CONTEXT_LENGTH, stel OLLAMA_KV_CACHE_TYPE=q8_0 in om de cache te halveren, of haal een kleinere kwantisatie op.