Naar de inhoud
NLEN
Illustratie: Quantization-formaten: GGUF, AWQ of EXL2 vergeleken

Quantization-formaten kiezen: GGUF, AWQ of EXL2 vergeleken

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

Bij het lokaal of op eigen servers draaien van grote taalmodellen is het originele 16-bits floating-point formaat (FP16 of BF16) zelden praktisch haalbaar. Een modern open-weights model van 70 miljard parameters vraagt ongecomprimeerd al snel meer dan 140 GB aan videogeheugen, puur om de statische gewichten in te laden. Wie efficiëntie zoekt, wendt zich tot gewichtskwantisatie: het terugbrengen van de numerieke precisie naar 8, 4 of zelfs 2 bits per parameter. Wie wil weten hoe de onderliggende compressiewiskunde en afrondingstechnieken functioneren, kan kwantisatie uitgelegd lezen in de praktijkgids over hardware-efficiëntie.

Toch is het kiezen van het juiste bestands- en runtime-formaat geen universele beslissing. Een formaat dat uitblinkt op een laptop met Apple Silicon presteert vaak matig in een Linux-servercluster met meerdere Nvidia A100- of H100-GPU's. De drie dominante formaten in het huidige ecosysteem — GGUF, AWQ en EXL2 — vertegenwoordigen drie fundamenteel verschillende filosofieën rond hardwareondersteuning, precisieverdeling, geheugenbandbreedte en runtime-engines. Om te bepalen hoeveel videogeheugen nodig is voor een specifieke configuratie, helpt het artikel over parameters omrekenen naar VRAM om direct inzicht te krijgen in de absolute minimumvereisten.

De technische kern van GGUF, AWQ en EXL2

Het landschap van modelkwantisatie is geëvolueerd van eenvoudige post-training rounding naar geavanceerde algoritmes die rekening houden met activeringsuitschieters en per-laag foutoptimalisatie. Elk van de drie toonaangevende formaten benadert dit probleem vanuit een ander perspectief.

GGUF (GPT-Generated Unified Format) is ontworpen als de binaire opvolger van GGML door het llama.cpp-project. Het is een binair containerformaat dat niet alleen de gekwantiseerde gewichten opslaat, maar ook alle benodigde metadata, tokenizerconfiguraties en hyperparameters in één enkel bestand verenigt. GGUF maakt gebruik van k-quants (zoals Q4_K_M of Q5_K_S), waarbij verschillende lagen en componenten binnen een transformer-blok (zoals aandachtsmechanismen versus feed-forward netwerken) op verschillende bit-precisies worden gehouden om kwaliteitsverlies te minimaliseren.

AWQ (Activation-aware Weight Quantization) kiest voor een hardware-geoptimaliseerde matrix-aanpak. In plaats van alle gewichten gelijk te behandelen, observeert AWQ tijdens een kalibratiestap welke gewichten overeenkomen met de 1% meest significante activaties in het model. Deze 'salient weights' worden beschermd tegen agressieve afrondingsfouten door schaling toe te passen in plaats van ze in FP16 te laten staan. Het resultaat is een homogeen 4-bit formaat dat native op GPU-tensor cores kan worden gedecodeerd via gespecialiseerde CUDA- of Triton-kernels, zonder complexe mixed-precision logica tijdens inference.

EXL2 (ExLlamaV2) is ontwikkeld met één specifiek doel voor ogen: maximale doorvoersnelheid en flexibele bitdieptes op Nvidia-consumenten- en datacenter-GPU's. EXL2 bouwt voort op het GPTQ-algoritme (Generalized Post-Training Quantization), maar introduceert de mogelijkheid voor variabele sub-bit quantization (bijvoorbeeld 3.2, 4.25 of 6.0 bits per gewicht). Hierdoor kan een model exact worden afgestemd op de harde fysieke grenzen van een specifieke GPU-geheugencapaciteit, zoals 24 GB op een RTX 3090 of RTX 4090.

Eigenschap GGUF AWQ EXL2
Primaire runtime llama.cpp, Ollama, LM Studio vLLM, TGI, AutoAWQ, SGLang ExLlamaV2, TabbyAPI
Doelhardware CPU, Apple Silicon, hybride GPU/RAM Nvidia datacenter & server GPU's Nvidia GPU's (CUDA-geoptimaliseerd)
Ondersteunde bitdieptes 1.5-bit tot 8-bit (k-quants/i-quants) Strikt 4-bit (en 8-bit varianten) Continu spectrum: 2.0 tot 8.0 bits
CPU/GPU-offloading Volledig dynamisch per laag Nee (strikt VRAM-gebonden) Beperkt (alleen GPU-geoptimaliseerd)
Bestandsstructuur Single-file (inclusief tokenizer) Safetensors-shards + config JSON Safetensors-shards + config JSON

Hardware-compatibiliteit en offloading-strategieën

De hardware-architectuur waarop het model draait, is de belangrijkste doorslaggevende factor bij de formaatkeuze. Wanneer een model niet in zijn geheel in het beschikbare videogeheugen past, ontstaan er grote operationele verschillen tussen de runtimes.

GGUF blinkt uit in omgevingen met heterogeen geheugen. Dankzij de architectuur van llama.cpp kan een model willekeurig worden opgesplitst over het systeem-RAM en het VRAM van een of meerdere grafische kaarten. Als een 70B-model in Q4_K_M circa 43 GB vraagt en er slechts een 16 GB GPU beschikbaar is, kan llama.cpp bijvoorbeeld 18 transformer-lagen naar de GPU sturen en de overige 62 lagen over de systeem-CPU laten lopen. Op platformen met unified memory, zoals Apple Silicon Mac's, leest GGUF direct vanuit het gedeelde geheugen via Metal-kernels, wat resulteert in uitstekende prestaties zonder CPU-GPU transfer overhead. Voor wie kleinschalige systemen inricht, biedt het overzicht over kleine modellen op het apparaat praktische vuistregels over geheugenbeperkingen.

AWQ en EXL2 zijn daarentegen strikt ontworpen voor GPU-inferentie. AWQ vereist dat het volledige model in het VRAM van de aangesloten GPU's past (eventueel verdeeld via Tensor Parallelism). Wanneer het geheugen volloopt, crasht de runtime met een Out-Of-Memory (OOM) fout; er is geen ingebouwde fallback naar systeem-RAM. EXL2 kent weliswaar experimentele CPU-offloading, maar in de praktijk stort de verwerkingssnelheid dan dermate hard in dat dit voor productiedoeleinden onbruikbaar is. EXL2 vereist specifieke Nvidia GPU-architecturen (Pascal of nieuwer) om zijn op maat gemaakte CUDA-kernels met maximale efficiëntie uit te voeren.

Geheugenbandbreedte en kwantisatieprecisie (PPL vs. VRAM)

De prestaties van een taalmodel tijdens de generatiefase (token-by-token generatie) worden vrijwel uitsluitend begrensd door de geheugenbandbreedte, niet door de rekenkracht van de compute cores. Het verlagen van de precisie verlaagt direct het aantal bytes dat per gegenereerd token over de geheugenbus moet worden getransporteerd.

Het reduceren van de bitdiepte introduceert echter kwantisatieruis, meetbaar via perplexity (PPL). Een lagere perplexity duidt op een model dat dichter bij de originele FP16-basisuitvoer blijft. Bij grotere modellen (vanaf 30B en 70B parameters) is het kwaliteitsverlies bij 4-bit en 5-bit kwantisatie verwaarloosbaar klein. Bij kleinere modellen (zoals 3B tot 8B) leidt agressieve kwantisatie onder de 4-bit grens tot merkbare degradatie in redeneervermogen, codeersyntaxis en meertalige consistentie.

AWQ behoudt bij 4 bits over het algemeen een zeer lage perplexity-stijging doordat het rekening houdt met activatiepatronen. GGUF compenseert dit via k-quants: in een Q4_K_M model worden kritieke componenten zoals de v_proj en output tensors met hogere precisie (6-bit) bewaard, terwijl minder gevoelige feed-forward matrices naar 4-bit worden teruggebracht. EXL2 biedt hier de hoogste granulariteit: in plaats van vast te zitten aan stappen van 1 bit (zoals de sprong van 4 naar 5 bit), kan een gebruiker exact 4.65 bits per gewicht targeten. Dit maakt het mogelijk om de resterende 2 GB vrije ruimte op een grafische kaart maximaal te benutten voor een groter contextvenster of een iets hogere precisie.

Inference-snelheid: single-stream versus hoge concurrency

De keuze voor een formaat hangt sterk af van het type werklast: bedient de server één enkele gebruiker die lage latentie per token verwacht (single-stream), of moet het systeem tientallen gelijktijdige verzoeken verwerken via continuous batching?

In single-stream scenario's op Nvidia-GPU's is EXL2 over het algemeen de snelste runtime. Doordat ExLlamaV2 speciaal geschreven kernels gebruikt die geoptimaliseerd zijn voor batch-grootte 1 tot 4, haalt een 70B model op een dual-GPU setup aanzienlijk hogere tokens per seconde dan een equivalente GGUF-configuratie via llama.cpp. De overhead van de kernel-aanroepen is minimaal en de decode-stap is extreem gestroomlijnd.

In productieomgevingen met honderden gelijktijdige API-aanroepen verschuift het voordeel volledig naar AWQ in combinatie met engines zoals vLLM of SGLang. Deze engines maken gebruik van PagedAttention en geavanceerde continuous batching. AWQ-kernels integreren naadloos met Tensor Parallelism over 2, 4 of 8 GPU's en behouden een hoge rekenkundige dichtheid wanneer de batch-grootte toeneemt. GGUF en EXL2 zijn weliswaar bruikbaar voor kleinschalige concurrency, maar schalen bij hoge gelijktijdige belasting minder efficiënt door beperkingen in dynamische geheugenallocatie voor de KV-cache.

# Starten van een AWQ model in vLLM met geoptimaliseerde tensor parallelism
python3 -m vllm.entrypoints.openai.api_server \
  --model casperhansen/llama-3.3-70b-instruct-awq \
  --quantization awq \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.95 \
  --port 8000

Impact op de KV-cache en contextlengte

Een veelvoorkomende misvatting is dat modelkwantisatie automatisch het volledige geheugenvraagstuk oplost. Kwantisatie van gewichten comprimeert uitsluitend de statische modelparameters. Zodra de contextlengte toeneemt tot 32k, 64k of 128k tokens, begint de Key-Value cache (KV-cache) een dominante factor te worden in het totale VRAM-beslag. Hoe een contextvenster zich opbouwt en waarom dit direct impact heeft op het dynamische geheugengebruik, staat nader toegelicht in het artikel over het context window en het belang ervan voor moderne LLM-architecturen.

Wanneer een model van 8B parameters bijvoorbeeld 5,5 GB VRAM inneemt in 4-bit precisie, kan een ongecomprimeerde FP16 KV-cache bij een context van 64k tokens daar zomaar 8 tot 12 GB aan dynamisch geheugen bovenop vragen. Zonder voldoende vrije VRAM-ruimte leidt dit onvermijdelijk tot out-of-memory fouten.

Hierin tonen de formaten verschillende oplossingen:

Productie, serving en ecosysteem-integratie

Naast pure rekenprestaties spelen tooling, deployment-gemak en ecosysteem-ondersteuning een doorslaggevende rol in IT-architectuurkeuzes.

GGUF is de onbetwiste standaard voor desktop- en edge-applicaties. Het single-file formaat maakt distributie eenvoudig: één bestand bevat de architectuur, lagen, metadata en chat-template. Runtimes zoals Ollama, LM Studio, Jan en LocalAI leunen vrijwel uitsluitend op GGUF. Voor ontwikkelaars die lokale assistenten, interne kantoor-chatbots of embedded systemen bouwen, minimaliseert GGUF de configuratiecomplexiteit tot een minimum.

AWQ is de standaardkeuze voor cloud-native en enterprise-omgevingen. Omdat AWQ-modellen worden opgeslagen in de standaard Hugging Face Safetensors-structuur met expliciete configuratiebestanden, integreren ze direct met professionele serving-frameworks zoals vLLM, TensorRT-LLM en Text Generation Inference (TGI). Monitoring via Prometheus, dynamic batching en gedistribueerde serving over Kubernetes-clusters werken vlekkeloos met AWQ.

EXL2 bevindt zich in een gespecialiseerde niche. Het is immens populair onder zelf-hosters, enthousiastelingen en mkb-ontwikkelaars die maximale prestaties willen persen uit een vaste set Nvidia RTX 3090 of 4090 GPU's. De integratie met server-tooling zoals TabbyAPI maakt het mogelijk om OpenAI-compatibele API-endpoints te serveren met een extreem lage latentie, hoewel de ondersteuning in grote enterprise orchestrators achterblijft bij AWQ.

# Voorbeeld van llama.cpp server met GGUF en 8-bit KV-cache compressie
./llama-server \
  -m models/Meta-Llama-3.1-8B-Instruct-Q5_K_M.gguf \
  -c 32768 \
  -ngl 99 \
  -ctk q8_0 \
  -ctv q8_0 \
  --host 0.0.0.0 \
  --port 8080

Beslisboom: welk formaat kies je wanneer?

Om een doordachte keuze te maken tussen GGUF, AWQ en EXL2, kunnen de volgende operationele criteria worden gehanteerd:

Kies voor GGUF als:

Kies voor AWQ als:

Kies voor EXL2 als:

Kwantisatie in productie: operationele valkuilen

Bij het inzetten van gekwantiseerde modellen in productieomgevingen moeten teams alert zijn op een aantal structurele valkuilen. Ten eerste reageren 'small language models' (tot 8 miljard parameters) veel gevoeliger op precisieverlies dan modellen van 70 miljard parameters. Het kwantiseren van een 8B model naar minder dan 4 bits leidt regelmatig tot syntaxfouten bij gestructureerde JSON-output of logische breuken in rekenstappen.

Ten tweede moet rekening worden gehouden met de kalibratiedataset die tijdens het kwantisatieproces is gebruikt. Zowel AWQ als EXL2 vertrouwen op kalibratiesets om de schaalfactoren van gewichten te bepalen. Wanneer een model uitsluitend is gekalibreerd op Engelstalige teksten, kan de perplexity op specialistische Nederlandse juridische documenten of complexe broncode onevenredig toenemen.

Tot slot vereist de combinatie van kwantisatie en lange contexten constante monitoring. Een systeem dat stabiel draait bij korte prompts kan abrupt falen zodra gebruikers documenten van tienduizenden tokens insturen en de dynamische KV-cache het resterende videogeheugen volledig opeist. Een robuuste architectuur reserveert daarom altijd minimaal 20% tot 30% van het totale VRAM als buffer voor context- en batch-expansie.