GGUF-kwantisatie: welk niveau moet je kiezen?

Kies standaard Q4_K_M; ga naar Q6_K of Q8_0 als je VRAM over hebt en de laatste paar procent kwaliteit nodig hebt. GGUF-kwantisatie verkleint de gewichten van een model van 16 bits naar minder — Q4_K_M slaat ruwweg 4.85 bits per gewicht op, dus een 7B-model zakt van ~14 GB naar ~4.1 GB met een perplexiteit die typisch minder dan 1% slechter is dan het origineel. De vraag ‘welke gguf-kwantisatie moet ik gebruiken’ heeft een saai stabiel antwoord dat de meeste online drama verhult. Hieronder: wat kwantisatie echt met gewichten doet, hoeveel kwaliteit elk niveau kost, hoe je de groottewiskunde zelf doet, en één commando om de schade op je eigen hardware te meten in plaats van de benchmark van een vreemde te vertrouwen.

Wat doet GGUF-kwantisatie eigenlijk?

Een model wordt getraind in 16-bit floating point (FP16 of BF16): elk van zijn miljarden gewichten is een getal van 2 bytes. Kwantisatie comprimeert elk gewicht naar minder bits. De naïeve manier — elk gewicht afronden naar een 4-bit integer — vernietigt kleine maar belangrijke waarden, dus GGUF gebruikt twee trucs:

1. Blokschaling. Gewichten worden gegroepeerd in blokken (meestal 32) en elk blok krijgt een eigen schaalfactor. De 4-bit-waarden zijn offsets binnen dat blok, dus een breed bereik aan groottes overleeft het.
2. Belanghebbende k-quants. De ‘K’ in Q4_K_M betekent super-blokken van schalen, plus dat attention- en feed-forward-lagen verschillend behandeld worden, omdat ze compressie ongelijk verdragen.

De ‘I’-familie (IQ4_XS en vrienden) gaat verder met information-theoretische codebooks, geleend uit beeldcompressie. Zelfde idee, verfijnder encoderen: minder bits per gewicht bij vergelijkbare kwaliteit, ten koste van iets tragere inferentie op sommige backends.

Eén verduidelijking die de meeste verwarring voorkomt: kwantisatie verandert alleen de opgeslagen gewichten. Architectuur, tokenizer en contextafhandeling blijven onaangeroerd. Een Q4-bestand en een Q8-bestand van hetzelfde model zijn hetzelfde model in andere jassen.

Q4 vs Q8: is hogere kwantisatie beter?

Technisch ja; waarnembaar nee. Met de perplexity-runs van llama.cpp zelf op Llama-modellen als referentie: Q8_0 zit binnen ~0.02% van FP16 — voor elke praktische doeleinde verliesloos. Q6_K is vrijwel ononderscheidbaar. Q4_K_M wint ruwweg 1–2% perplexiteit, Q4_0 iets meer, en Q2_K is waar coherente antwoorden op kleine modellen beginnen uiteen te vallen.

Twee regels die uit die cijfers volgen:

• Modelgrootte koopt kwantisatiemarge. Een 70B-model overleeft Q2/Q3 veel beter dan een 7B, omdat grotere modellen redundanter zijn. Een 7B naar Q2 kwantiseren is amputatie; een 70B naar Q3 is maatwerk.
• De kwaliteitsvloer verschuift met de taak. Chat verdraagt Q4. Exacte codegeneratie, wiskunde en RAG over precieze documenten leggen kwantisatieruis eerder bloot. Blijft een Q4-model subtiel foute code schrijven, test dan hetzelfde model op Q6_K voordat je het model de schuld geeft.

Niveau	Bits/gewicht	Grootte vs FP16	Kwaliteitsverlies	Gebruik wanneer
Q2_K	~3.4	~21%	Ernstig onder 13B	Niets anders past, alleen grote modellen
Q3_K_M	~3.9	~25%	Merkbaar	Krappe VRAM, ≥14B-modellen
Q4_K_S	~4.6	~29%	Klein	Q4_K_M past net niet en het zit dichtbij
Q4_K_M	~4.85	~30%	~1% perplexiteit	De standaard. Beste kwaliteit/grootte-trade
Q5_K_M	~5.7	~35%	~0.5%	VRAM beschikbaar, kwaliteitskritieke taken
Q6_K	~6.6	~41%	Vrijwel nul	Code/wiskunde, past nog comfortabel
Q8_0	~8.5	~53%	Effectief nul	Referentieruns, fine-tune-basis
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M net te groot, backend ondersteunt i-quants

Hoeveel VRAM heeft elk niveau nodig?

Doe de groottewiskunde zelf in plaats van tabellen te memoreren — het is één regel:

size_GB ≈ (bits_per_weight × params) / 8
# 8B model @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# 8B model @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Tel daar de onderdelen bij op die de formule weglaat: de KV-cache (groeit met de contextlengte — enkele honderden MB tot meerdere GB), activaties en compute-buffers. Praktische marge: een model van ‘4.9 GB’ wil een kaart van 6 GB bij 4k context, plus flash-attention en KV-cache-kwantisatie om daar ook op 16k te blijven. De gewichten zijn de kop, niet de hele rekening.

Welke GGUF-kwantisatie moet je kiezen?

Beslissingsvolgorde, geen uitzonderingen die het memoreren waard zijn:

1. Bereken eerst je context- en KV-budget, dan de gewichten. Context die niet past is erger dan kwaliteit die je niet kunt meten.
2. Standaard Q4_K_M. Het is de community-standaard met reden — ruwweg 1% perplexiteit voor 70% van de grootte. Elke registry, inclusief die van Ollama, verscheept ‘m als baseline.
3. Stap over op Q6_K als de taak ruis afstraft: code, wiskunde, extractie, alles wat je ongezien aan een pipeline voert.
4. Gebruik Q8_0 alleen als referentie — A/B-tests, kwantisatieschade meten, of een fine-tune-basis. Als daily driver koopt het vooral warmte in je VRAM-sensoren.
5. Onder Q4 alleen onder dwang, en alleen op grote modellen. Test met een bekend-moeilijke prompt voordat je ‘m vertrouwt.

Kies je op Hugging Face welk bestand je downloadt, geef dan één Q4_K_M.gguf de voorkeur boven gesplitste shards, tenzij de uploader alleen het laatste verscheept — minder bewegende delen. En kies je waar je het draait, dan is de engine-keuze een aparte as: zie daarvoor llama.cpp vs Ollama.

Hoe meet je kwantisatieschade zelf?

Benchmarks verschillen; jouw prompt is constant. Bouw llama.cpp één keer, download twee niveaus van hetzelfde model en meet zowel perplexiteit (lager is beter) als tokens per seconde:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf 
  --local-dir models

# perplexity on a wiki-text chunk (lower = closer to the original model)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# and speed on the same hardware
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Het Q4_K_M-getal ligt een paar honderdste punt slechter dan Q8_0 en het bestand is ~40% kleiner. Ziet je downstream-taak het verschil niet — en bij de meesten ziet het dat niet — dan heb je je antwoord zonder iemands leaderboard te lezen.

Doet kwantisatie afbreuk aan privacy of local-only-claims?

Nee — het is rekenwerk op gewichten, volledig offline, en het gekwantiseerde bestand is gewoon een kleinere container met dezelfde parameters. Een Q4_K_M lokaal draaien lekt exact evenveel (of weinig) als het full-precision-model lokaal draaien: er verlaat niets de machine. De privacyrelevante variabele is waar de inferentie draait, niet de bitbreedte. De gebruikelijke kanttekeningen over modelherkomst gelden voor elk quant-niveau: een ‘uncensored’ fine-tune op een gestolen base in Q8 is niet veiliger dan dezelfde gewichten in Q4. Voor de bestandsformaatkant hiervan: zie GGUF-modellen lokaal draaien.

Welk niveau kies je?

Q4_K_M, en stop fora erover te lezen. Upgrade naar Q6_K voor precisiehongerig werk als de VRAM het toelaat, houd één Q8_0 achter de hand voor A/B-vergelijkingen en behandel alles onder Q4 als noodrantsoen, uitsluitend voor grote modellen. De enige fout die je moet vermijden is symmetrisch: je druk maken over Q4-vs-Q5 terwijl je de contextlengte negeert — die verknalt meer lokale setups dan welke quant ooit heeft gedaan.