Wanneer een klant aangeeft een 70B-model lokaal te willen draaien op één server met twee GPU's, is de eerste reactie doorgaans dezelfde: "Dat past niet." In FP16 klopt dat — zo'n model heeft 140–168 GB VRAM nodig, een configuratie die zelden beschikbaar is. Maar in 4-bit kwantisering zakt datzelfde model naar 35–40 GB, wat neerkomt op twee middenklasse GPU-kaarten. En het kwaliteitsverlies? Bij het juiste formaat valt dat mee voor de meeste mensen.
Kwantisering is vandaag een van de belangrijkste praktische vaardigheden bij het uitrollen van LLM's op eigen hardware. Dit artikel legt uit wat er tijdens kwantisering precies met de modelgewichten gebeurt, wat het verschil is tussen de formaten GGUF, AWQ en GPTQ, hoeveel kwaliteit u op de verschillende niveaus werkelijk verliest, en hoe dit verschilt van destillatie — een begrip dat men vaak met kwantisering verwart.
Wat kwantisering met gewichten doet
Moderne LLM's worden getraind in BF16 of FP16 — elke parameter neemt 16 bits in beslag. Een model met 7 miljard parameters heeft daardoor al zo'n 14 GB nodig voor de gewichten alleen (plus KV-cache en activaties).
Kwantisering stelt dezelfde gewichten voor in een lagere numerieke precisie. In plaats van een 16-bit float gebruikt u een 8-bit of 4-bit integer. De formule is rechtstreeks: VRAM (GB) ≈ (aantal parameters in miljarden × bits) / 8. Bij 4-bit kwantisering van een 7B-model krijgt u 5–7 GB — dat past op een gewoon werkstation.
De prijs voor deze besparing is informatieverlies. De numerieke precisie daalt, sommige subtiele verschillen tussen gewichten worden "afgeplat" naar dezelfde representeerbare waarde. Het gevolg is een lichte daling van de uitvoerkwaliteit — de vraag is hoe groot die is.
Belangrijk om te begrijpen wat kwantisering niet is: het is geen destillatie. Kwantisering behoudt de architectuur en het aantal parameters van het oorspronkelijke model en wijzigt alleen het numerieke formaat van de gewichten. Destillatie daarentegen draagt kennis over naar een kleiner model met een andere architectuur — het is kennisoverdracht, geen compressie. Meer over destillatie in het artikel Modeldestillatie: hoe u een klein, snel model maakt van een groot model.
GGUF — formaat voor CPU en cross-platform uitrol
GGUF is een binair formaat dat is ontwikkeld voor llama.cpp en tegenwoordig ook native ondersteund door Ollama. De kernkwaliteit: het model kan puur op de CPU draaien, of in een hybride CPU+GPU-modus waarbij een deel van de lagen op de GPU loopt en de rest op de CPU met gebruik van RAM.
Voor bedrijfsuitrol betekent dit een praktisch voordeel: een ontwikkelaar kan een 13B-model draaien op een werkstation zonder dedicated GPU, of op een server met minder VRAM dan het model in FP16 vereist.
Kwantiseringsniveaus in GGUF
De aanduiding volgt het schema Q<bits>_<variant>. De belangrijkste niveaus:
- Q8_0 — 8-bit kwantisering, het kleinste kwaliteitsverlies (~1–2 % ten opzichte van FP16). Aanbevolen als u voldoende VRAM heeft en maximale precisie wilt.
- Q4_K_M — 4-bit, "medium"-variant met adaptieve kwantisering voor gevoelige lagen. Behoudt ~92–95 % van de FP16-kwaliteit. Het standaard sweet spot voor de meeste use-cases.
- Q4_K_S — 4-bit, "small"-variant, iets kleiner dan K_M bij vergelijkbare kwaliteit.
- Q3_K_M — 3-bit, aanmerkelijk kleiner geheugenvoetafdruk, merkbare degradatie bij complex redeneren.
- Q2_K — 2-bit, aanzienlijke degradatie. Alleen bruikbaar bij extreem beperkte hardware en eenvoudige taken.
De letter K in de aanduiding staat voor "k-quants" — een verfijndere methode die hogere precisie toepast op lagen die het gevoeligst zijn voor kwantiseringsfouten (doorgaans embedding- en uitvoerlagen), en agressievere compressie op minder kritieke delen. Het resultaat is een betere kwaliteit-grootteverhouding dan bij eenvoudige uniforme kwantisering.
AWQ — gekalibreerde kwantisering voor de GPU-stack
AWQ (Activation-aware Weight Quantization) is een methode die bij kwantisering rekening houdt met de statistieken van activaties — met andere woorden: welke invoerwaarden het model in de praktijk tegenkomt. Op basis van die statistieken identificeert het de "belangrijke" gewichten en behoudt daarvoor een hogere precisie, terwijl de rest agressiever wordt gekwantiseerd.
Het resultaat: AWQ 4-bit behoudt ~93–96 % van de FP16-kwaliteit, iets beter dan GPTQ bij dezelfde grootte. Het verschil is het meest zichtbaar bij langere tekstgeneratie en code, waar coherentie sneller wegvalt bij ongekalibreerde kwantisering.
AWQ vereist een GPU voor inferentie — het is niet bedoeld voor CPU-only omgevingen. Het wordt native ondersteund door vLLM en TGI. Voor productie-uitrol op NVIDIA is het vandaag een van de geprefereerde formaten.
GPTQ — maximale doorvoer op NVIDIA GPU
GPTQ (Generative Pre-trained Transformer Quantization) is een oudere en ingeburgerde methode. Het maakt gebruik van tweede-orde afgeleiden (Hessian) om de kwantiseringsfout bij een gegeven batchkalibratie te minimaliseren. In de praktijk scoort GPTQ 4-bit iets lager dan AWQ wat betreft kwaliteitsbehoud (~90–93 % vs FP16), maar biedt maximale doorvoer op NVIDIA GPU's dankzij gefuseerde kernels.
Voor scenario's waarbij het hoogste aantal tokens per seconde prioriteit heeft (bijvoorbeeld serving voor meerdere gelijktijdige gebruikers), levert GPTQ in combinatie met vLLM sterke resultaten. Net als AWQ vereist het een GPU — CPU-inferentie wordt niet native ondersteund.
Vergelijking van formaten — wanneer wat te gebruiken
- GGUF — wanneer u cross-platform uitrol nodig heeft, CPU-inferentie of hybride CPU+GPU-modus, of wanneer u via
Ollamauitrolt op ontwikkelaarswerkstations - AWQ — puur GPU-stack (NVIDIA), productie-uitrol via
vLLMofTGI, prioriteit ligt bij coherentie van de uitvoer - GPTQ — puur GPU-stack (NVIDIA), productie-uitrol via
vLLM, prioriteit ligt bij maximale doorvoer bij multi-user serving
Deze formaten zijn niet onderling uitwisselbaar of compatibel — een model dat in GPTQ is gekwantiseerd, kunt u niet rechtstreeks laden in llama.cpp, en omgekeerd. Voor u een formaat kiest, moet u weten welke serving-stack en hardware u van plan bent te gebruiken.
Werkelijk kwaliteitsverlies — wat de cijfers zeggen
De vraag die klanten het vaakst stellen: "Hoeveel kwaliteit verliezen we?"
Het antwoord hangt af van het kwantiseringsniveau en het type taak. Metingen over uiteenlopende modellen (Qwen, DeepSeek, Mistral, Llama) tonen een consistent patroon:
- Q8_0 / 8-bit: verschil in perplexiteit onder 1–2 % ten opzichte van FP16. In gewone gesprekken vrijwel niet te onderscheiden.
- Q4_K_M / AWQ 4-bit: verschil in perplexiteit doorgaans onder 5–8 % ten opzichte van BF16. Voor de meeste taken — informatieextractie, samenvatting, classificatie — is het verschil met het blote oog niet waarneembaar. Bij complex meertraps redeneren (wiskunde, code, lange reeksen stappen) kan een lichte daling zichtbaar zijn.
- Q3 en lager: degradatie is merkbaar. Het model begint minder coherente uitvoer te produceren, met name bij lange generaties of taken waarbij precisie telt.
- Q2: aanzienlijke degradatie. Alleen geschikt bij extreme hardwarebeperkingen en niet-kritieke taken.
Een belangrijke nuance: kwaliteitsverlies is niet gelijkmatig verdeeld. Modellen met meer parameters tolereren agressievere kwantisering beter — een 70B-model in Q4_K_M behoudt doorgaans meer capaciteiten dan een 7B-model in dezelfde configuratie. Bij kleine modellen (7B en kleiner) is het verschil tussen Q8 en Q4 zichtbaarder.
Een tweede nuance: benchmarks meten gemiddelden. Voor een specifieke domeingerichte use-case (bijvoorbeeld analyse van technische documentatie) is het verstandig een eigen vergelijking te maken van FP16 versus Q4 op een steekproef van echte invoer — een paar dozijn voorbeelden volstaat doorgaans voor een oriënterende conclusie.
VRAM-besparing in de praktijk
Concrete cijfers voor de meest voorkomende modelgroottes:
- 7–9B model: FP16 ~16–19 GB → Q8_0 ~8–13 GB → Q4_K_M ~5–7 GB
- 13B model: FP16 ~26 GB → Q8_0 ~14 GB → Q4_K_M ~8 GB
- 27–34B model: FP16 ~54–68 GB → Q8_0 ~30–34 GB → Q4_K_M ~17–20 GB
- 70B model: FP16 ~140–168 GB → Q8_0 ~70–75 GB → Q4_K_M ~35–40 GB
Bij deze cijfers komt nog de KV-cache, die toeneemt met de contextlengte en het aantal gelijktijdige verzoeken. Een 70B-model met een lange context kan bij enkele parallelle gesprekken nog eens 20–40 GB extra vergen voor de KV-cache. Plan bij het dimensioneren van de infrastructuur daarom niet alleen voor de gewichten — de KV-cache is een even belangrijke variabele. Meer hierover in het artikel Welke GPU voor LLM-inferentie.
Kwantisering en serving-stack — wat vLLM en Ollama hierover weten
Ollama is een uitstekend hulpmiddel voor ontwikkelaarstoepassingen — met één opdracht downloadt u een GGUF-model en het draait lokaal zonder configuratie. Onder de motorkap zit llama.cpp. De voornaamste beperking: Ollama is geen productie-serving-framework. Bij meerdere gelijktijdige gebruikers kunt u een aanzienlijk lagere doorvoer ervaren dan met vLLM — en dat staat los van de kwantisering.
vLLM met AWQ- of GPTQ-modellen is bedoeld voor productieomgevingen met meerdere gelijktijdige verzoeken. Het maakt gebruik van PagedAttention voor efficiënt KV-cachebeheer en continuous batching — de resulterende doorvoer kan bij meerdere gelijktijdige gebruikers aanzienlijk hoger liggen dan bij Ollama. De prijs is een complexere setup en een GPU-vereiste.
Voor bedrijfsuitrol is de gebruikelijke aanpak: ontwikkelaars en testers werken met GGUF-modellen via Ollama, de productie-inferentieserver draait op vLLM met AWQ of GPTQ. Beide aanpakken bestaan naast elkaar — het is geen óf/óf. Een gedetailleerder vergelijking van deze serving-tools vindt u in het artikel vLLM vs SGLang vs Ollama.
Kwantisering vs destillatie — een belangrijk onderscheid
Deze twee begrippen worden in de praktijk door elkaar gehaald, maar het gaat om fundamenteel verschillende technieken.
Kwantisering behoudt de oorspronkelijke architectuur van het model — u wijzigt alleen het numerieke formaat van de gewichten. Het proces is snel, vereist geen training en bestaande kwantiseringstools verwerken een 70B-model in enkele uren op een gewone server. Er gaat informatie verloren in numerieke precisie.
Destillatie creëert een nieuw, kleiner model door dit te trainen op de uitvoer van een groter (teacher-)model. Het is een volwaardig trainingsproces — het vereist data, rekentijd en hyperparameter-tuning. Het resultaat is een model met minder parameters en een andere architectuur dat heeft "geleerd" de teacher na te bootsen. Er gaat capaciteit verloren — een kleiner model heeft simpelweg niet genoeg parameters voor sommige complexe taken.
In de praktijk zijn beide benaderingen complementair: een gedestilleerd model kunt u vervolgens kwantiseren. Een klein model dat via destillatie uit een frontier-model is gemaakt, kunt u bijvoorbeeld verspreiden als GGUF Q4 voor edge-uitrol.
Hoe u kwantisering in een project aanpakt
Enkele praktische aanbevelingen op basis van uitrolprojecten die wij hebben begeleid:
- 1.Begin met Q4_K_M — voor de meeste bedrijfsgerichte use-cases (extractie, classificatie, Q&A over documenten) biedt Q4_K_M voldoende kwaliteit en een redelijke VRAM-voetafdruk
- 2.Valideer op eigen data — als de toepassing specifieke eisen stelt (bijvoorbeeld nauwkeurige extractie van numerieke waarden uit technische rapporten), vergelijk dan FP16 en Q4 op een steekproef van 50–100 echte invoervoorbeelden voor u een definitieve keuze maakt
- 3.Onderschat de KV-cache niet — reken bij het plannen van hardware ook de KV-cache boven op de gewichtsgrootte mee, zeker als u lange contexten plant
- 4.Houd rekening met de serving-stack — kiest u voor vLLM, dan is AWQ een goede keuze; kiest u voor Ollama of cross-platform, dan GGUF; geeft u prioriteit aan doorvoer op NVIDIA, dan GPTQ
- 5.Q2 liever niet — de degradatie is aanzienlijk; gebruik liever een kleiner model in Q4 dan een groter model in Q2
Veelgestelde vragen
Kan ik zelf elk model kwantiseren?
Ja, tools zoals llama.cpp (voor GGUF), AutoAWQ en AutoGPTQ zijn open-source en beschikbaar. Voor gangbare groottes (7–34B) slaagt een gewone server in enkele uren de kwantisering af. Voor modellen van 70B en groter heeft u aanzienlijk meer RAM nodig (kwantisering vanuit FP16 vóór conversie). In de praktijk is het voor de meeste teams eenvoudiger om voorgekwantiseerde modellen van Hugging Face te gebruiken — de kwaliteit is geverifieerd en u bespaart tijd.
Is het verschil tussen Q4_K_M en Q4_K_S merkbaar?
In de dagelijkse praktijk minimaal. Q4_K_S is iets kleiner bestand bij zeer vergelijkbare kwaliteit. Q4_K_M is de conservatievere keuze die iets meer precisie behoudt in gevoelige lagen. Voor de meeste use-cases raden wij Q4_K_M aan als startpunt.
Kwantisering en AVG — is er iets om rekening mee te houden?
Niet direct — kwantisering verandert het gedrag van het model bij gegevensverwerking niet, alleen de VRAM-voetafdruk en snelheid. De AVG-implicaties hangen af van *waar* het model draait en *wie* toegang heeft tot de gegevens. On-premise uitrol van een gekwantiseerd model kan u helpen met de AVG vanuit het oogpunt van gegevenslokalisatie (gegevens verlaten de infrastructuur niet), maar compliance vereist veel meer — auditlogs, toegangscontroles, een gedocumenteerd VVA-proces. Meer in het artikel On-prem LLM voor gereguleerde sectoren.
Kan ik een gekwantiseerd model verder fine-tunen?
Directe fine-tuning van een gekwantiseerd model (bijv. GGUF Q4) is geen gangbare werkwijze — de meeste fine-tuning-frameworks werken met FP16- of BF16-gewichten. QLoRA is de uitzondering: het maakt training mogelijk met 4-bit gekwantiseerde basisgewichten, waarbij de LoRA-adapters in hogere precisie worden getraind. Details vindt u in het artikel LoRA vs QLoRA vs full fine-tuning.
Wat is het verschil tussen NVFP4 en standaard 4-bit kwantisering?
NVFP4 is een hardware-native formaat dat specifiek is voor de nieuwste NVIDIA GPU's met Blackwell-architectuur. In tegenstelling tot softwarematige 4-bit methoden (GPTQ, AWQ, GGUF Q4) wordt NVFP4 rechtstreeks versneld in de tensorkernen van de chip. Het resultaat is een hogere doorvoer dan generieke 4-bit formaten op dezelfde hardware. Als u geen Blackwell GPU heeft, is dit formaat niet relevant voor u — standaard AWQ of GPTQ zijn dan de juiste keuze.
*De keuze van het juiste kwantiseringsformaat en de bijbehorende serving-stack is een beslissing die de kosten en prestaties van uw productie-uitrol sterk beïnvloedt. Bij MP Industrial Solutions helpen wij bedrijven van het eerste experiment met een lokale LLM naar een productie-infrastructuur — inclusief hardwarebeoordeling, modelkeuze en selectie van het kwantiseringsformaat voor uw specifieke use-case. Als u een on-premise LLM-uitrol overweegt, plannen wij graag een vrijblijvend kennismakingsgesprek.*