In dit artikel onderzoekt Piotr Migdał hoe verschillende kwantisatieniveaus de prestaties van het Qwen3.8 27B-model beïnvloeden. Met behulp van llama.cpp en Modal GPU's zijn diverse versies (BF16, 8-bit, 4-bit, 2-bit en 1-bit) getest op benchmarks zoals GPQA Diamond, IFBench en Terminal-Bench 2.1.
De belangrijkste bevindingen zijn:
- 4-bit (Q4KM): Presteert vrijwel identiek aan het volledige BF16-model en is ideaal voor consumentenhardware zoals de RTX 4090.
- 2-bit (UD-Q2KXL): Vertoont een merkbare daling in kwaliteit, maar blijft bruikbaar voor minder complexe taken.
- 1-bit (UD-IQ1_S): De kwaliteit stort volledig in; het model presteert op het niveau van willekeurig gokken en is onbruikbaar.
De auteur concludeert dat kwantisatie een effectieve manier is om grote modellen lokaal te draaien, mits men niet onder de 2-bit grens zakt.
Benchmarking Qwen3.8 27B kwantisaties: 4-bit houdt stand, 1-bit stort in
Hoeveel GPU-RAM heb je nu echt nodig om Qwen3.8 27B te draaien zonder kwaliteitsverlies?
Het volledige BF16-model weegt 55 GB, wat het onbruikbaar maakt voor de meeste consumentenhardware. Toch scoort de 17 GB Q4KM versie gelijk aan het volledige model op een populaire benchmark voor agentisch programmeren: Terminal-Bench 2.1. Deze versie past op een 24 GB kaart, zoals de RTX 4090, waarbij er nog ruimte overblijft voor ongeveer 64k tokens aan context.
Compressie bereikt echter uiteindelijk een breekpunt. Bij 1-bit presteert het model op GPQA Diamond ongeveer op het niveau van willekeurig gokken, en uitgebreidere redeneringen maken de resultaten zelfs slechter.
Achtergrond
De Qwen3.8 27B GGUF-kwantisaties zijn beschikbaar via Unsloth op Hugging Face. Er is een grote keuze, maar ik heb gekeken naar de volgende versies:
- 8-bit Q8_0 (29 GB)
- 4-bit Q4KM (17 GB)
- 2-bit UD-Q2KXL (10,7 GB)
- 1-bit UD-IQ1_S (6,2 GB) — de kleinste mogelijke versie.
Voorheen heb ik het Qwen3.6 27B-model onderzocht, dat zelfs bij 12 GB goed was in het genereren van SVG-pelikanen en tot 16 GB het grootste deel van zijn kennis behield.
Tegelijkertijd klagen veel gebruikers in Reddit-threads dat alle kwantisaties, zelfs de 8-bit versies, slechtere resultaten geven. Men vraagt zich af waarom een lokale LLM "dommer" aanvoelt dan hij zou moeten zijn. Zijn deze klachten gegrond?
Het meten van verschillen in token-voorspelling (KL-divergentie, top-1 voorspellingen) is eenvoudig, maar het vertelt ons niet of het model slechter wordt in het oplossen van taken. Sommige ruis is irrelevant voor het oplossen van taken, aangezien een gekwantiseerd model een antwoord van precies dezelfde kwaliteit kan genereren, maar dan iets anders geformuleerd. In andere gevallen kan één afwijkend token een logische fout zijn, of de output abrupt beëindigen.
Daarom focus ik op het direct meten van resultaten op populaire benchmarks: GPQA Diamond, de instructie-volgende IFBench en het programmeer-benchmark Terminal-Bench 2.1. Eerst probeer ik de officiële resultaten van het volledige BF16-model te repliceren, om vervolgens te zien hoe kwantisatie de resultaten beïnvloedt.
Methodologie
Voor het draaien van de modellen heb ik gebruikgemaakt van llama.cpp (build van 16 augustus 2026) op Modal GPU's, wat ongeveer $3.000 kostte. Hoewel het in principe op een laptop zou kunnen, zijn deze benchmarks te tijdrovend.
Belangrijke technische details:
- KV-cache: Ik gebruik overal een F16 KV-cache, ongeacht de kwantisatie van het model. Dit weegt ongeveer 2,3 GB per 32k tokens.
- Kwantisaties: Ik heb Unsloth-kwantisaties gebruikt: v2 voor de 2-, 4- en 8-bit modellen, en v3 voor de 1-bit modellen. (Let op: Unsloth heeft de v2-bestanden op 19 augustus 2026 vervangen, dus de exacte bestanden zijn mogelijk niet meer beschikbaar).
Kort samengevat: als je kiest voor een 4-bit kwantisatie (Q4KM, 17 GB), zul je in deze benchmarks geen verschil merken. Wel is de effort instelling (standaard is xhigh) zeer bepalend; dit is een lastige keuze, omdat het model anders kan gaan "overthinken".
One-shot tests
De eenvoudigste tests zijn de one-shot tests: de wetenschappelijke GPQA Diamond (op universitair niveau) en de instructie-volgende IFBench. Ik heb beide uitgevoerd met drie verschillende redeneerniveaus (reasoning efforts): low, medium en de standaard xhigh.
GPQA Diamond
Ten eerste kon ik de officiële resultaten succesvol repliceren. Het draaien van benchmarks is lastig vanwege verborgen instellingen die resultaten drastisch kunnen beïnvloeden, maar hier waren de resultaten direct conform de meldingen van Qwen.
Ten tweede is er, buiten de ruis, weinig verschil merkbaar tot en met 4-bit. Alleen de 2-bit versie scoort iets lager. Tegelijkertijd veranderde het redeneerniveau de score drastisch; de beste resultaten bij xhigh vereisten ongeveer 8k redeneertokens.
IFBench
Tot mijn grote verbazing is er hier geen enkel verschil tussen de modellen, tot en met een degelijke 2-bit versie die minder dan 11 GB weegt. De context is hier overigens lager, rond de 4k tokens.
Agentisch programmeren en Terminal-Bench 2.1
Voor programmeren is Terminal-Bench 2.1 de standaard voor agentisch gedrag, met 89 taken. Hierbij heb ik een timeout van 3 uur, de xhigh effort en 98k context gebruikt.
Niet alleen mijn meting van BF16 repliceert het gestelde resultaat, maar tot mijn verbazing doet Q4KM dat ook. Ik heb het draaien van Q8_0 overgeslagen; in dit geval kan ik veilig interpoleren tussen de 4-bit en de volledige modelwaarden. Dit zou zowel kostbaar als onnodig zijn.
Pas bij de 2-bit UD-Q2KXL gaat het een beetje mis. Er is een merkbare daling, maar het niveau blijft vergelijkbaar met Opus 4.7 of Gemini 3.1 Pro. Hoewel dit ver verwijderd is van de absolute top (frontier), is het zeker niet nutteloos.
Het proces
Wat betreft het proces: hebben kleinere modellen meer beurten, tokens of tijd nodig om tot een resultaat te komen?
Bij de taken die zowel door BF16 als UD-Q2KXL werden opgelost, heeft de 2-bit versie evenveel beurten nodig, maar schrijft deze ongeveer een kwart meer tokens. Het aantal beurten blijft dus ongeveer gelijk.
De 1-bit afgrond
Bij 1-bit keldert de kwaliteit volledig. Net als bij kennis is de schade van kwantisatie niet lineair: eerst is er geen meetbare verandering, dan een kleine daling, en uiteindelijk een totale instorting.
Hoewel 2-bit kwantisaties tot op zekere hoogte werken, is zelfs het beste 1-bit model nutteloos voor deze benchmarks. De scores liggen rond het niveau van willekeurig gokken, waarbij het kleinste model zelfs daaronder duikt.
Bovendien maakt een langere redenering het slechter: bij xhigh dalen de scores onder die van low, omdat het model vaker blijft redeneren tot het token-budget op is en vervolgens een leeg antwoord teruggeeft.
Unsloth claimt dat hun kleinere UD-1bit kwants (waaronder UD-IQ1_S van 6,2 GB) ongeveer 72% van de top-1% accuratesse behouden. In dit specifieke geval blijkt die resterende 28% echter cruciaal te zijn. Dit komt overeen met ervaringen van andere gebruikers (zie bijvoorbeeld de discussie over "1bit brain damage quant" op r/LocalLLaMA).
Kosten
Het draaien van deze benchmarks is niet goedkoop. API-gebruik is kostbaar, maar het huren van GPU's is nog duurder.
Ik heb gebruikgemaakt van Modal, omdat dit eenvoudig aan te sturen is via de CLI en agents. Ik gebruikte de volgende hardware:
- NVIDIA L40S (dezelfde Ada Lovelace-chip als de RTX 4090, maar met dubbele hoeveelheid geheugen: 48 GB)
- H100 (80 GB)
- H200 (141 GB)
Ter vergelijking: DeepSeek V4 Flash 0731 (een 284B model) kost via de goedkoopste providers op OpenRouter ongeveer $0,1 per miljoen output-tokens. Het is onduidelijk of dit verschil komt door efficiëntie bij schaalvergroting, prijsstrategie of populariteit.
Conclusie
Als je lokaal experimenteert, is het advies meestal om het beste model te kiezen dat samen met de benodigde context in je GPU-geheugen past.
Voor de meeste taken zou de Q4KM van Unsloth voldoende moeten zijn, zonder dat er een merkbaar verschil is. Voor eenvoudigere taken is de UD-Q2KXL waarschijnlijk meer dan genoeg. Aangezien er meldingen zijn dat KV-caches gevoeliger zijn voor kwantisatie, is dat iets wat ik in de toekomst wil testen.
Over het algemeen ben ik van mening dat kwantisatie omarmd moet worden in plaats van gevreesd.
Benchmarking Qwen3.8 27B kwantisaties: 4-bit houdt stand, 1-bit stort in
Hoeveel GPU-RAM heb je nu echt nodig om Qwen3.8 27B te draaien zonder kwaliteitsverlies?
Het volledige BF16-model weegt 55 GB, wat het onbruikbaar maakt voor de meeste consumentenhardware. Toch scoort de 17 GB Q4KM versie gelijk aan het volledige model op een populaire benchmark voor agentisch programmeren: Terminal-Bench 2.1. Deze versie past op een 24 GB kaart, zoals de RTX 4090, waarbij er nog ruimte overblijft voor ongeveer 64k tokens aan context.
Compressie bereikt echter uiteindelijk een breekpunt. Bij 1-bit presteert het model op GPQA Diamond ongeveer op het niveau van willekeurig gokken, en uitgebreidere redeneringen maken de resultaten zelfs slechter.
Achtergrond
De Qwen3.8 27B GGUF-kwantisaties zijn beschikbaar via Unsloth op Hugging Face. Er is een grote keuze, maar ik heb gekeken naar de volgende versies:
- 8-bit Q8_0 (29 GB)
- 4-bit Q4KM (17 GB)
- 2-bit UD-Q2KXL (10,7 GB)
- 1-bit UD-IQ1_S (6,2 GB) — de kleinste mogelijke versie.
Voorheen heb ik het Qwen3.6 27B-model onderzocht, dat zelfs bij 12 GB goed was in het genereren van SVG-pelikanen en tot 16 GB het grootste deel van zijn kennis behield.
Tegelijkertijd klagen veel gebruikers in Reddit-threads dat alle kwantisaties, zelfs de 8-bit versies, slechtere resultaten geven. Men vraagt zich af waarom een lokale LLM "dommer" aanvoelt dan hij zou moeten zijn. Zijn deze klachten gegrond?
Het meten van verschillen in token-voorspelling (KL-divergentie, top-1 voorspellingen) is eenvoudig, maar het vertelt ons niet of het model slechter wordt in het oplossen van taken. Sommige ruis is irrelevant voor het oplossen van taken, aangezien een gekwantiseerd model een antwoord van precies dezelfde kwaliteit kan genereren, maar dan iets anders geformuleerd. In andere gevallen kan één afwijkend token een logische fout zijn, of de output abrupt beëindigen.
Daarom focus ik op het direct meten van resultaten op populaire benchmarks: GPQA Diamond, de instructie-volgende IFBench en het programmeer-benchmark Terminal-Bench 2.1. Eerst probeer ik de officiële resultaten van het volledige BF16-model te repliceren, om vervolgens te zien hoe kwantisatie de resultaten beïnvloedt.
Methodologie
Voor het draaien van de modellen heb ik gebruikgemaakt van llama.cpp (build van 16 augustus 2026) op Modal GPU's, wat ongeveer $3.000 kostte. Hoewel het in principe op een laptop zou kunnen, zijn deze benchmarks te tijdrovend.
Belangrijke technische details:
- KV-cache: Ik gebruik overal een F16 KV-cache, ongeacht de kwantisatie van het model. Dit weegt ongeveer 2,3 GB per 32k tokens.
- Kwantisaties: Ik heb Unsloth-kwantisaties gebruikt: v2 voor de 2-, 4- en 8-bit modellen, en v3 voor de 1-bit modellen. (Let op: Unsloth heeft de v2-bestanden op 19 augustus 2026 vervangen, dus de exacte bestanden zijn mogelijk niet meer beschikbaar).
Kort samengevat: als je kiest voor een 4-bit kwantisatie (Q4KM, 17 GB), zul je in deze benchmarks geen verschil merken. Wel is de effort instelling (standaard is xhigh) zeer bepalend; dit is een lastige keuze, omdat het model anders kan gaan "overthinken".
One-shot tests
De eenvoudigste tests zijn de one-shot tests: de wetenschappelijke GPQA Diamond (op universitair niveau) en de instructie-volgende IFBench. Ik heb beide uitgevoerd met drie verschillende redeneerniveaus (reasoning efforts): low, medium en de standaard xhigh.
GPQA Diamond
Ten eerste kon ik de officiële resultaten succesvol repliceren. Het draaien van benchmarks is lastig vanwege verborgen instellingen die resultaten drastisch kunnen beïnvloeden, maar hier waren de resultaten direct conform de meldingen van Qwen.
Ten tweede is er, buiten de ruis, weinig verschil merkbaar tot en met 4-bit. Alleen de 2-bit versie scoort iets lager. Tegelijkertijd veranderde het redeneerniveau de score drastisch; de beste resultaten bij xhigh vereisten ongeveer 8k redeneertokens.
IFBench
Tot mijn grote verbazing is er hier geen enkel verschil tussen de modellen, tot en met een degelijke 2-bit versie die minder dan 11 GB weegt. De context is hier overigens lager, rond de 4k tokens.
Agentisch programmeren en Terminal-Bench 2.1
Voor programmeren is Terminal-Bench 2.1 de standaard voor agentisch gedrag, met 89 taken. Hierbij heb ik een timeout van 3 uur, de xhigh effort en 98k context gebruikt.
Niet alleen mijn meting van BF16 repliceert het gestelde resultaat, maar tot mijn verbazing doet Q4KM dat ook. Ik heb het draaien van Q8_0 overgeslagen; in dit geval kan ik veilig interpoleren tussen de 4-bit en de volledige modelwaarden. Dit zou zowel kostbaar als onnodig zijn.
Pas bij de 2-bit UD-Q2KXL gaat het een beetje mis. Er is een merkbare daling, maar het niveau blijft vergelijkbaar met Opus 4.7 of Gemini 3.1 Pro. Hoewel dit ver verwijderd is van de absolute top (frontier), is het zeker niet nutteloos.
Het proces
Wat betreft het proces: hebben kleinere modellen meer beurten, tokens of tijd nodig om tot een resultaat te komen?
Bij de taken die zowel door BF16 als UD-Q2KXL werden opgelost, heeft de 2-bit versie evenveel beurten nodig, maar schrijft deze ongeveer een kwart meer tokens. Het aantal beurten blijft dus ongeveer gelijk.
De 1-bit afgrond
Bij 1-bit keldert de kwaliteit volledig. Net als bij kennis is de schade van kwantisatie niet lineair: eerst is er geen meetbare verandering, dan een kleine daling, en uiteindelijk een totale instorting.
Hoewel 2-bit kwantisaties tot op zekere hoogte werken, is zelfs het beste 1-bit model nutteloos voor deze benchmarks. De scores liggen rond het niveau van willekeurig gokken, waarbij het kleinste model zelfs daaronder duikt.
Bovendien maakt een langere redenering het slechter: bij xhigh dalen de scores onder die van low, omdat het model vaker blijft redeneren tot het token-budget op is en vervolgens een leeg antwoord teruggeeft.
Unsloth claimt dat hun kleinere UD-1bit kwants (waaronder UD-IQ1_S van 6,2 GB) ongeveer 72% van de top-1% accuratesse behouden. In dit specifieke geval blijkt die resterende 28% echter cruciaal te zijn. Dit komt overeen met ervaringen van andere gebruikers (zie bijvoorbeeld de discussie over "1bit brain damage quant" op r/LocalLLaMA).
Kosten
Het draaien van deze benchmarks is niet goedkoop. API-gebruik is kostbaar, maar het huren van GPU's is nog duurder.
Ik heb gebruikgemaakt van Modal, omdat dit eenvoudig aan te sturen is via de CLI en agents. Ik gebruikte de volgende hardware:
- NVIDIA L40S (dezelfde Ada Lovelace-chip als de RTX 4090, maar met dubbele hoeveelheid geheugen: 48 GB)
- H100 (80 GB)
- H200 (141 GB)
Ter vergelijking: DeepSeek V4 Flash 0731 (een 284B model) kost via de goedkoopste providers op OpenRouter ongeveer $0,1 per miljoen output-tokens. Het is onduidelijk of dit verschil komt door efficiëntie bij schaalvergroting, prijsstrategie of populariteit.
Conclusie
Als je lokaal experimenteert, is het advies meestal om het beste model te kiezen dat samen met de benodigde context in je GPU-geheugen past.
Voor de meeste taken zou de Q4KM van Unsloth voldoende moeten zijn, zonder dat er een merkbaar verschil is. Voor eenvoudigere taken is de UD-Q2KXL waarschijnlijk meer dan genoeg. Aangezien er meldingen zijn dat KV-caches gevoeliger zijn voor kwantisatie, is dat iets wat ik in de toekomst wil testen.
Over het algemeen ben ik van mening dat kwantisatie omarmd moet worden in plaats van gevreesd.
Groetjes,