Guide voor model quantization: van de basis tot serving in productie

Viacheslav Dubrov

2026-07-05 · Bijgewerkt 2026-07-22 · 24 min · Modelengineering · AI-infrastructuur

Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Kwantisatie gebruikt minder bits om modelwaarden te representeren. Een serving path kan weights, activations, de KV-cache of een combinatie daarvan kwantiseren, waarbij elk target een ander servingprobleem oplost.

Kies het target op basis van de huidige bottleneck: weight memory, activation compute, KV-cachegrootte, kernels, hardware, calibratiedata of kwaliteit. Een 4-bit model past mogelijk in VRAM, maar draait toch traag met een niet-geoptimaliseerde kernel, zoals de JarvisLabs vLLM-benchmark laat zien. FP8 werkt goed op NVIDIA Hopper-hardware met een compatibele runtime, maar biedt geen native voordeel op niet-ondersteunde GPU’s. De hardwarematrix van TensorRT-LLM toont de ondersteunde paden. Voor lange contexten of hoge concurrency kan KV-cachekwantisatie meer geheugen besparen dan weight quantization.

Als je een ML- of platform engineer bent die een quantization path kiest voor een model dat je moet serven, is deze gids voor jou. Na het lezen ervan moet je een bottleneck kunnen koppelen aan een candidate format, runtime en validatieplan voordat je deployt.

Zie LLM Quantization Formats voor de korte vergelijking van artifacts en methoden.

1. Begin met de bottleneck

Bepaal wat de workload beperkt voordat je een bit-width kiest. Het antwoord kan model weight memory, prefill compute, decode bandwidth of de KV-cache zijn, en niet numerical precision op zichzelf.

Veelvoorkomende bottlenecks en hun startpunten:

Gebruik deze tabel als leidraad. In de onderstaande secties wordt uitgelegd waarom die startpunten van elkaar verschillen.

Notatie in serving-recepten

• W{x}A{y} geeft de precisie aan voor ondersteunde weight- en activation-berekeningen, meestal GEMM-paden in serving engines. W4A16 slaat weights op in 4-bit-formaat en gebruikt 16-bit-precisie voor activations. W8A8 gebruikt 8-bit weights en activations in ondersteunde compute-paden, maar definieert niet automatisch het persistente storage-dtype van elke runtime-tensor.
• FP8, INT8, INT4, NF4 zijn number formats. Ze bepalen welke waarden kunnen worden gerepresenteerd.
• GPTQ, AWQ, SmoothQuant, QuaRot zijn algoritmen. Ze bepalen hoe je een getraind model omzet naar een format met lagere precisie.
• GGUF is een bestandsformaat waarin tensors en metadata voor GGML- en llama.cpp-achtige runtimes worden opgeslagen. Een GGUF-bestand kan niet-gequantiseerde tensor types bevatten, zoals F16, BF16 of F32, evenals quantized encodings. Presets zijn onder andere Q4_K_M, Q5_K_M, Q8_0, IQ*, TQ* en MXFP4. De tensor encoding bepaalt de quantization-keuze. GGUF beschrijft op zichzelf geen CUDA-stijl FP8 W8A8-servingrecept.
• KV cache is de attention-cache die tijdens generation wordt gebruikt. Deze slaat eerdere keys en values op, zodat het model niet bij elke token de volledige conversatie opnieuw hoeft te berekenen.
• KV-cache quantization slaat gecachte key/value-activation-tensors op in een cache-format met lagere precisie, zoals FP8, INT8, INT4 of INT2, afhankelijk van de runtime-ondersteuning. Dit verschilt van prefix caching, PagedAttention en offload: die bepalen respectievelijk of cache-items worden hergebruikt, hoe ze worden gealloceerd en waar ze worden opgeslagen.
• GEMM staat voor general matrix multiply. Het grootste deel van de transformer-inference-tijd gaat op aan matrixvermenigvuldigingen.

2. Quantization is gecontroleerd afronden

Quantization brengt waarden met hoge precisie in kaart op een kleinere verzameling representeerbare waarden. Dat is de kerndefinitie die zowel Hugging Face Optimum als TensorRT-LLM gebruikt. Je bespaart memory en bandwidth, maar introduceert ook afrondingsfouten.

INT4 biedt slechts 16 discrete waarden. Het mappen van BF16-weights naar dat grid veroorzaakt daarom afrondingsfouten. Methoden zoals GPTQ, AWQ en SVDQuant richten zich op het behouden van outliers en het verminderen van reconstruction error. Een goede mapping bespaart memory met weinig kwaliteitsverlies. Een slechte mapping schaadt reasoning, instruction following of visuele getrouwheid.

Symmetric en asymmetric mapping

Volgens de affine mapping die in gangbare quantization guides wordt gebruikt, mapt quantization een continue floatwaarde $x \in [\beta, \alpha]$ naar een discreet grid.

• $x$ is de oorspronkelijke waarde met hoge precisie.
• $x_q$ is de gekwantiseerde waarde.
• $s$ is de scale, oftewel de stapgrootte.
• $z$ is het zero point: de integerpositie die 0.0 representeert.
• $[q_{\min}, q_{\max}]$ is het doelbereik van integers. Voor signed 4-bit waarden wordt vaak $[-7, 7]$ gebruikt.

Symmetric quantization centreert het grid rond nul en stelt $z = 0$ in:

Dit is hardwarevriendelijk, omdat runtime-berekeningen geen zero-point-offset hoeven af te trekken. PyTorchs quantization stack stelt deze affine scale- en zero-point-keuzes beschikbaar als elementaire quantization parameters in torchao.

Asymmetric quantization verschuift het grid om scheve bereiken af te dekken:

Dat verschoven grid kan activations met uitsluitend positieve waarden beter behouden, maar de offset voegt extra werk toe tenzij de kernel hier goed mee omgaat.

De scale-granulariteit is belangrijk

De scale factor kan een volledige weight tensor, één channel of een kleine groep waarden afdekken. De FP8 KV-cache-documentatie van vLLM gebruikt hetzelfde onderscheid tussen per-tensor- en per-attention-head-scale-strategieën. Kleinere groepen behouden doorgaans de kwaliteit beter, maar vereisen meer scale-metadata.

Weights zijn statisch, dus hun scales kunnen offline worden berekend voordat je het model laadt. Activations veranderen bij elke token, waardoor hun bereiken afhankelijk zijn van de workload.

De KV cache zit tussen die twee gevallen in. Keys en values beginnen als runtime activation tensors: elke layer berekent ze tijdens de forward pass uit hidden states. Zodra ze zijn gegenereerd, zijn het geen tijdelijke matmul-intermediates meer, maar persistente serving state die attention voor latere tokens uitleest.

Een serving engine kan die state in lagere precisie opslaan en de scale metadata ernaast bewaren. vLLM’s Quantized KV Cache, TensorRT-LLM’s FP8 KV Cache en Transformers QuantizedCache bieden allemaal deze storagekeuze.

De precisie van cache storage staat los van de activation precision die binnen linear kernels wordt gebruikt. “KV-cache quantization” verwijst naar één cache-optimalisatie, niet naar elke techniek die cache entries hergebruikt, alloceert of verplaatst.

PTQ en QAT vinden in verschillende fasen plaats

Post-training quantization, of PTQ, comprimeert een getraind model achteraf. Quantization-aware training, of QAT, stelt het model tijdens training bloot aan quantization noise, zodat het zich kan aanpassen.

Calibratiegegevens moeten eruitzien als het verkeer dat je daadwerkelijk gaat bedienen. Het KV-cache-calibratiepad van vLLM gebruikt bijvoorbeeld een gecureerde dataset via llm-compressor. Als production-prompts lange RAG-traces zijn, leveren korte Wikipedia-paragrafen nette benchmarkcijfers op, maar een deployment die niet werkt. Het model stemt zijn activation scales af op korte tekst en krijgt vervolgens andere activation patterns te verwerken wanneer echte prompts met een lange context binnenkomen. Long-context quantization evaluations meten dit risico rechtstreeks.

3. Number formats bepalen hardwarevereisten

Het number format bepaalt welke waarden het model in het geheugen kan representeren. Efficiënte berekeningen vereisen runtime-kernels en hardwareondersteuning voor dezelfde bit-width en hetzelfde format. TensorRT-LLM documenteert zowel de recipe list als de hardware support matrix.

BF16 en FP16 gebruiken beide 16 bits, maar verdelen de precisie anders en falen daardoor op verschillende manieren. BF16 behoudt het 8-bit exponentbereik van FP32 en overflowt minder snel. FP16 heeft meer mantissabits en een smaller exponentbereik, waardoor activation spikes meer aandacht vereisen. De evaluatie van Kurtic et al. gebruikt expliciet BF16 als baseline bij het vergelijken van FP8-, INT8- en INT4-servingformaten.

FP8 heeft twee gangbare varianten. E4M3 biedt meer precisie en wordt doorgaans gebruikt voor forward weights en activations. E5M2 biedt een groter dynamisch bereik en is nuttiger voor gradients of volatiele activation paths. vLLM biedt zowel FP8 E4M3- als E5M2-KV-cache-dtypes. In de ACL 2025-studie van Kurtic et al., “Give Me BF16 or Give Me Death,” was FP8 W8A8 effectief lossless voor de Llama-3.1-familie over meer dan 500.000 evaluaties. Dit resultaat geldt voor die modelfamilie, evaluationsuite en servingconfiguratie. Elke deployment heeft nog steeds een eigen quality gate nodig.

Blackwell voegt microscaling-formaten toe, zoals MXFP8 en NVFP4. In plaats van één scale voor een volledige tensor of rij gebruikt microscaling zeer kleine blocks. NVIDIA’s NVFP4-uitleg beschrijft 4-bit floating-pointwaarden in blocks van 16, met FP8 scale factors en een FP32 scale op een hoger niveau. Deze aanpak is bedoeld om een footprint die bijna overeenkomt met INT4 te combineren met floating-pointgedrag. Er zijn echter een bijpassende hardwarearchitectuur, compiler en runtime-ondersteuning voor nodig. Daarom vermeldt TensorRT-LLM ondersteuning voor FP4 en FP8 per GPU-generatie.

4. Weight-only versus weight-activation-quantization

De notatie WxAy beschrijft de precisie van weights en activations, die tijdens inference op verschillende manieren druk op de GPU zetten.

Tijdens prefill verwerkt het model de inputprompt. Deze fase is doorgaans compute-bound, omdat de GPU grote matrixvermenigvuldigingen uitvoert. Daarom zijn W8A8 FP8/INT8-recepten relevant voor throughput-georiënteerde serving.

Tijdens decode genereert het model één token per keer. Deze fase is vaak memory-bandwidth-bound, omdat de GPU weights telkens uit VRAM laadt om het volgende token te produceren. Weight-only papers zoals GPTQ en AWQ richten zich op deze druk door het aantal bytes voor weights te verminderen.

W4A16 comprimeert weights en houdt activations in BF16 of FP16. De GPU laadt minder bytes aan weights en dequantizet deze vervolgens terug naar een vorm met hogere precisie voor de vermenigvuldiging. Dit helpt bij decode en bij problemen rond het in het geheugen passen van modellen. Compute-bound prefill kan weinig voordeel opleveren, omdat de matrixberekeningen nog steeds in 16-bit worden uitgevoerd.

W8A8 comprimeert weights en de activation tensors die door ondersteunde matmul-kernels worden gebruikt. Als de hardware native low-precision tensor cores heeft, kan de serving engine matrixberekeningen rechtstreeks in FP8 of INT8 uitvoeren. FP8 kan high-throughput serving daardoor verbeteren door memory traffic te verminderen en snellere arithmetic te gebruiken. De KV-cache heeft een eigen storage-instelling. Controleer daarom afzonderlijk de cache dtype of cache implementation van de runtime.

Als het model maar net in het VRAM past, begin dan met weight-only quantization om de memory footprint te verkleinen. Past het model wel, maar heeft het moeite met de throughput bij hoge batch loads, evalueer dan FP8 of INT8 W8A8 om de compute-fase te versnellen. Ontstaan memoryproblemen alleen tijdens lange gesprekken, schat dan eerst de KV-cache-term. Test KV-cache quantization wanneer die term dominant is. Schakel prefix caching in wanneer herhaalde prefixes dominant zijn.

5. Algorithms versus runtime kernels

Quantization-algorithms (zoals GPTQ en AWQ) bepalen hoe de weights van het model naar lagere precisie worden gemapt. Runtime kernels (zoals Marlin en vLLM’s custom kernels) zijn de low-level GPU-code die de matrix multiplication uitvoert. Een sterk gecomprimeerd model draait alleen snel als er een geoptimaliseerde kernel beschikbaar is voor het specifieke quantization-format.

De vLLM-benchmark van JarvisLabs op Qwen2.5-32B-Instruct met een NVIDIA H200 maakt het effect van de kernel zichtbaar:

Neem deze cijfers niet zonder meer over voor je eigen stack. Ze komen uit één model, één GPU-klasse en één softwareconfiguratie. Ze illustreren een specifieker punt: de algorithmenaam op de checkpoint vertelt je niet hoe snel serving zal zijn.

AWQ en Marlin-AWQ gebruiken bijvoorbeeld dezelfde 4-bit weights. De Marlin-implementatie is veel sneller omdat de CUDA-kernel dequantization en matrix multiplication fuseert tot één sterk geoptimaliseerde GPU-operatie.

Benchmark de baseline en de gecomprimeerde varianten met dezelfde promptmix en dezelfde tool, zoals vllm bench serve:

vllm bench serve \
  --model ./outputs/Qwen2.5-32B-Instruct-AWQ-W4A16 \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --input-len 1024 \
  --output-len 256

Houd throughput, TTFT, inter-token latency, memorygebruik en task quality bij. Wanneer sommige daarvan zich in tegengestelde richting ontwikkelen, is die trade-off precies wat je moet zien voordat je naar production gaat.

Het algorithm-menu

Gebruik deze tabel als overzicht, niet als ranking:

De toolchain ontwikkelt zich actief. AutoGPTQ werd in april 2025 gearchiveerd, en AutoAWQ werd in mei 2025 gearchiveerd en officieel deprecated verklaard. Begin voor nieuwe compressed-tensors-checkpoints die door vLLM worden gebruikt met llm-compressor. Gebruik GPTQModel wanneer je het actieve GPTQ-pad met Marlin, Machete, MoE-geheugenopties of disk offload nodig hebt.

Pruning en distillation verlagen de serving-kosten ook via afzonderlijke workflows. 2:4 structured sparsity verwijdert weights volgens een patroon dat NVIDIA sparse tensor cores kunnen benutten. Distillation traint een kleiner student model om een groter model te imiteren, wat goed kan werken voor narrow tasks. Neem een van beide paden alleen op in de shortlist wanneer het project het extra pruning- of trainingswerk kan ondersteunen.

6. Serving memory is meer dan alleen weights

Het compressed checkpoint is slechts een deel van de serving-memory-footprint. Bereken de volledige runtime-footprint voordat je beslist of weight quantization volstaat. PagedAttention identificeert de KV cache als een belangrijke component van het serving-memory-verbruik.

Offline quantization kan per layer worden uitgevoerd. Tools zoals llm-compressor kunnen één transformer block laden, calibration- en quantization-berekeningen uitvoeren, het gecomprimeerde block wegschrijven en doorgaan naar het volgende. Daardoor blijft het piekgebruik van GPU memory dichter bij de grootste actieve layer plus de calibration-buffers. Je hebt nog steeds CPU RAM en diskruimte nodig voor het source checkpoint, maar de GPU hoeft niet altijd het volledige BF16-model te bevatten.

Het piekgebruik van GPU memory tijdens offline quantization kan er eerder zo uitzien:

Serving stelt strengere eisen. Het volledige compressed checkpoint moet resident blijven, samen met de KV cache en runtime-buffers. De KV cache groeit mee met de contextlengte en de actieve batchgrootte:

Waarbij:

• $L$ het aantal layers is.
• $H_{\text{kv}}$ het aantal key-value attention heads is. Grouped-query attention verlaagt dit aantal doordat veel query heads minder KV heads delen.
• $D$ de dimensie van elke head is, vaak 128 of 256.
• $S_{\text{ctx}}$ het aantal prompt tokens plus gegenereerde tokens is.
• $B_{\text{batch}}$ de actieve serving-batch is.
• $\text{BytesPerValue}$ 2 is voor BF16 of FP16 en 1 voor FP8 of INT8. De FP8 KV-cache mode van vLLM is het voorbeeld uit de serving stack dat dit artikel gebruikt.

KV-cache quantization verandert de opslag, terwijl reuse de allocatie verandert

De KV cache kan tijdens inference worden gequantiseerd. Elke decode step produceert K- en V-activation tensors voor het nieuwe token. Een W8A8-model gebruikt mogelijk al FP8 of INT8 voor ondersteunde projection math, maar de cache blijft een afzonderlijk storage-object.

Veel serving stacks bewaren dit object in de dtype van het model of de cache. Om dit te wijzigen, activeer je een KV-cache dtype, gebruik je een checkpoint met cache scales of kies je een quantized cache implementation.

Wanneer KV-cache quantization is ingeschakeld, schrijft de engine entries weg als een lower-precision representatie plus scales. Latere attention dequantizet de cache in de kernel of voert op sommige backends een deel van de attention-operatie uit in het quantized domain.

De stabiele Quantized KV Cache-documentatie van vLLM maakt dit direct zichtbaar met kv_cache_dtype="fp8" of --kv-cache-dtype fp8. vLLM ondersteunt FP8 E4M3- en E5M2-cacheformaten, plus per-tensor- en per-attention-head-scale-strategieën. Het biedt drie manieren om de scales te verkrijgen: defaults, schatting tijdens warmup en dataset calibration via llm-compressor. Met FlashAttention 3 kan vLLM attention-operaties ook uitvoeren in het FP8-domain door naast keys en values ook queries te quantizen.

TensorRT-LLM stelt FP8 KV cache beschikbaar via KvCacheConfig(dtype='fp8') en vermeldt FP8 KV cache en NVFP4 KV cache als afzonderlijke quantization recipes, los van weight/activation quantization. Hugging Face Transformers heeft eveneens een QuantizedCache-pad via cache_implementation="quantized", waarbij hqq de cacheformaten int2, int4 en int8 ondersteunt en quanto int2 en int4 ondersteunt.

Gewone KV caching bewaart eerder berekende keys en values om herberekening te voorkomen. Prefix caching hergebruikt cacheblokken voor requests met dezelfde prefix. PagedAttention vermindert fragmentatie en verbetert de allocatie, terwijl KV offload cacheblokken tussen memory tiers verplaatst. Deze combinaties zijn runtime-afhankelijk. Hugging Face’s QuantizedCache ondersteunt geen offloading. vLLM documenteert zijn quantized KV cache afzonderlijk van prefix caching en andere features voor cachemanagement. Controleer elke combinatie in de runtime die je uitrolt.

Het kwaliteitsrisico verschilt ook van weight-only PTQ. KV-cache quantization introduceert fouten in de attention state die bij elke volgende decode-stap wordt uitgelezen. Test long-context retrieval, multi-turn gedrag, safety en refusals, tool-use formatting en output latency afzonderlijk. KVQuant, KIVI en de vLLM FP8 KV-cache study evalueren KV-cache quantization allemaal als een afzonderlijk probleem.

Alleen modelgrootte en contextlengte bepalen niet of cachecompressie meer oplevert dan nog een ronde weight compression. Bereken het aantal cachebytes met de bovenstaande vergelijking, op basis van het aantal KV-heads, de head dimension, de actieve batch en het cache-dtype van het model. Vergelijk dat resultaat vervolgens met de bytes die je bespaart tussen twee benoemde weight formats, zoals BF16 en INT4. Als de cache groter is, kan het testen van FP8 KV-cache quantization meer serving memory vrijmaken dan de weights nog verder verkleinen.

7. Hardware beperkt de mogelijkheden

De weight footprint is eenvoudig te schatten op basis van het aantal parameters en de storage precision; dit is hetzelfde sizing-principe als in discussies over serving memory rond KV cache:

Mixture-of-experts-modellen activeren mogelijk minder parameters per token, maar de volledige set weights moet ergens beschikbaar blijven, tenzij de runtime offload ondersteunt. De quantization support matrix van TensorRT-LLM behandelt MoE-model families als deployment targets met hun eigen ondersteunde recipes.

De hardware van je deployment beperkt welke quantization formats haalbaar zijn:

• CPU-serving is afhankelijk van vectorinstructies zoals AVX-512 of AMX. Een GGUF-bestand dat via llama.cpp wordt geladen, is de praktische route.
• Apple Silicon gebruikt unified memory, waardoor lokale modellen een grote gedeelde RAM-pool kunnen gebruiken in plaats van dedicated VRAM. GGUF en llama.cpp blijven de gebruikelijke route voor local runtimes, omdat GGUF is built for GGML executors.
• NVIDIA Ampere ondersteunt INT8 tensor-core serving paths, maar geen native FP8 W8A8 tensor-core math. Gebruikelijk zijn weight-only quantization met W4A16 of statische INT8, in overeenstemming met de TensorRT-LLM hardware support matrix.
• NVIDIA Ada en Hopper ondersteunen FP8 serving paths in TensorRT-LLM. FP8 W8A8-serving is het testen waard op deze GPU’s.
• NVIDIA Blackwell voegt NVFP4 and microscaling support toe, maar de software stack blijft belangrijk. Behandel vroege low-bit floating-point stacks als versiegevoelig.

8. Calibration en evaluation vóór deploy

Een model dat laadt, heeft een smoke test doorstaan. Voor deployment zijn quality- en serving-checks voor de beoogde workload vereist. Recente quantization-evaluaties rapporteren verschillende uitkomsten voor LLM serving, long-context tasks en reasoning-heavy models.

Gebruik voor calibration prompts die op production lijken:

• Neem RAG-traces, SQL-queries, agent histories, code-tasks, tool-call payloads en system prompts uit de beoogde workload op. Static PTQ is afhankelijk van calibration data die overeenkomt met de production distribution.
• Laat de sequence lengths overeenkomen. Korte single-turn prompts leggen long-context activation behavior niet bloot.
• Houd embed_tokens en lm_head op hogere precision als de method of runtime dit toestaat; dit is een gebruikelijk exclusion pattern in LLM Compressor recipes.
• Gebruik voldoende samples om activation ranges te stabiliseren. Het vLLM KV-cache example stelt NUM_CALIB_SAMPLES = 512 in. Beschouw dit als één gedocumenteerd voorbeeld, niet als een universeel aantal. Het juiste aantal samples hangt af van de method, het model, de sequence length en de production workload.
• Redigeer secrets en private user data voordat je production logs gebruikt.

Test voor evaluation zowel language quality als serving behavior:

• Perplexity op een standaardcorpus detecteert brede taaldegradatie, maar de JarvisLabs-benchmark herinnert er terecht aan dat perplexity en throughput zich verschillend kunnen ontwikkelen.
• Domeintaken detecteren fouten die perplexity verbergt. Gebruik HumanEval voor coding, MMLU voor brede kennis en AIME of MATH-500 voor mathematical reasoning wanneer die domeinen relevant zijn.
• Format checks zijn belangrijk voor agentic systems. Test JSON schema compliance, markdown-output, de vorm van tool calls en refusal behavior, omdat quantized model evaluations fouten op applicatieniveau kunnen missen, zelfs wanneer de aggregate benchmark accuracy stabiel lijkt.
• Long-context tests detecteren schade door KV-cache quantization. Needle-in-a-haystack is een ruwe test, maar long-context quantization results laten zien waarom deze checks deel moeten uitmaken van de deploy gate.
• Load tests moeten throughput, TTFT, inter-token latency, maximale batchcapaciteit en piekgeheugengebruik rapporteren. vLLM maakt deze metingen beschikbaar via vllm bench serve.

Evalueer reasoning-heavy models grondig. Sub-4-bit- of unrotated W4A4-quantization kan de reasoning accuracy verlagen, zelfs wanneer de baseline-perplexity stabiel lijkt. Dat is de belangrijkste waarschuwing uit de quantized reasoning-model study.

9. Workflow voor de companion repository

De companion repository, slavadubrov/model-compression-demo, is bedoeld om het besluitvormingsproces reproduceerbaar te maken. De repository gebruikt uv en richt zich op planning, recipes, dry runs en benchmarkconfiguraties die zijn gebaseerd op dezelfde bronnen als hier: vLLM, LLM Compressor, TensorRT-LLM en de algorithm papers.

De public README op revision 8b45003849e830bed2ff341a9f027b017d932c1f is gecontroleerd op 2026-08-16. De companion checkout is niet aanwezig in deze workspace, dus ik kon de CLI hier niet uitvoeren. De onderstaande commands zijn illustratief totdat je ze vanuit die pinned checkout uitvoert; bovendien heeft het benchmarkplan nog de target serving hardware nodig.

Kopieer de FP8-recipe-output uit die pinned revision niet. De opdracht recipe --algorithm fp8-dynamic genereert een intern inconsistent model en output path. De command blijft hier weggelaten totdat de companion is gerepareerd.

Clone de repository en inspecteer de ondersteunde algorithms:

git clone https://github.com/slavadubrov/model-compression-demo.git
cd model-compression-demo
git checkout 8b45003849e830bed2ff341a9f027b017d932c1f
uv run python demo.py list-algorithms

Begin met planning en sizing:

uv run python demo.py plan \
  --model-preset qwen3-8b \
  --goal fit-memory \
  --hardware ampere \
  --context 4096 \
  --concurrency 4

uv run python demo.py estimate \
  --model-preset qwen3-8b \
  --scheme w4a16 \
  --context 4096 \
  --concurrency 4

uv run python demo.py plan \
  --model-preset qwen3-0.6b \
  --hardware cpu

Genereer vervolgens een recipe en preview de quantization voordat je GPU-tijd besteedt:

uv run python demo.py recipe --algorithm gptq-w4a16

uv run python demo.py quantize --dry-run
uv run python demo.py quantize \
  --algorithm gptq-w4a16 \
  --model Qwen/Qwen3-8B \
  --dry-run

Voor serving- en benchmarkplanning:

uv run python demo.py serve-command \
  --algorithm fp8-dynamic \
  --fp8-kv-cache \
  --enable-prefix-caching

uv run python demo.py benchmark-plan \
  --model Qwen/Qwen3-8B \
  --algorithms gptq-w4a16,rtn-w8a16,fp8-dynamic \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --input-len 1024 \
  --output-len 256 \
  --output-json reports/quantization-benchmark-plan.json

Vergelijk ten slotte de base- en compressed models met expliciete thresholds:

uv run python demo.py quality-eval \
  --base-model Qwen/Qwen3-8B \
  --compressed-model outputs/Qwen3-8B-W4A16 \
  --mode all \
  --lm-eval-task hellaswag \
  --lm-eval-limit 50 \
  --max-perplexity-delta-pct 5 \
  --output-json reports/qwen3-8b-w4a16-quality.json

Voer het werk in deze volgorde uit: plan het target, schat het geheugengebruik, voer een dry run van de recipe uit, benchmark serving en vergelijk vervolgens de kwaliteit met de thresholds. Die volgorde weerspiegelt de scheiding in dit artikel tussen memory sizing, runtime benchmarking en quality evaluation.

10. Diffusion-modellen hebben een afzonderlijk pad

Diffusion- en diffusion-transformer-pipelines vertonen ander activation-gedrag dan autoregressieve LLM’s. SVDQuant behandelt diffusion-quantization als een afzonderlijk probleem met activation outliers.

Autoregressieve LLM’s genereren één token per keer. Diffusion-modellen voeren herhaalde denoising-stappen uit, waarbij hun activation-distributies tijdens het proces verschuiven. Een standaard 4-bit LLM-quantization-pass kan geheugen besparen bij diffusion-modellen, maar tegelijkertijd ernstige visuele artefacts veroorzaken. Diffusion-gerichte methoden zoals SVDQuant / Nunchaku en NVIDIA ModelOpt diffusion quantization pakken dat afwijkende activation-patroon aan.

Gebruik het volgende als conservatieve heuristieken, niet als universele defaults. De pipeline, component, het model en de runtime vereisen elk afzonderlijke tests:

1. Houd de VAE voor de eerste vergelijking op 16-bit. Deze conservatieve heuristiek beperkt één mogelijke bron van beeldartefacts. Test lagere precisie alleen wanneer de methode en de doelpipeline dit valideren.
2. Probeer eerst de DiT- of U-Net-backbone, omdat die vaak het grootste aandeel van de parameters bevat. Dit is een heuristiek; controleer daarom memorygebruik, latency en beeldkwaliteit voor de doelpipeline. Diffusion-quantizationmethoden hanteren dezelfde componentgerichte aanpak.
3. Behandel text encoders afzonderlijk. Quantization van T5-XXL of CLIP kan in een bepaalde pipeline de prompt alignment of textrendering beïnvloeden. Evalueer ze daarom onafhankelijk, in plaats van generiek transformer-gedrag te veronderstellen.
4. Gebruik diffusion-aware methoden zoals SVDQuant wanneer activation outliers het belangrijkste probleem vormen.
5. Evalueer met afbeeldingen, niet met text metrics. Controleer prompt adherence, textrendering, huidtinten, kleurbalans, fijne details, latency en VRAM.

Als de evaluatieset alleen eenvoudige of veelvoorkomende prompts bevat, mis je failures in edge cases. Neem moeilijke gevallen op: kleine tekst, handen, herhaalde objecten, gestructureerde lay-outs en prompts met negatieve constraints, omdat fouten in diffusion-quantization visueel zichtbaar worden en niet in language-model perplexity.

11. Production-defaults

Begin voor enterprise LLM serving met een BF16-baseline in exact de serving-engine die je wilt gebruiken. Als throughput het doel is en de hardware dit ondersteunt, test dan FP8 W8A8. Als het model niet past, test dan AWQ of GPTQ W4A16 met Marlin-class kernels. Als long context of concurrency het probleem vormt, test dan FP8 KV-cache quantization. Als repeated prefixes het probleem vormen, schakel dan ook prefix caching in. Breng de gecomprimeerde versie pas in productie wanneer zowel de quality- als de serving-benchmarks slagen.

Begin voor local en edge inference met een GGUF-bestand met Q4_K_M of Q5_K_M. Stap over op een Q8_0 GGUF wanneer het geheugen dit toelaat en kwaliteit belangrijker is dan de footprint. Onder 4-bit gaan is een laatste redmiddel, geen default.

Gebruik voor fine-tuning NF4 with QLoRA om op kostenefficiënte wijze adapters te trainen. Evalueer de adapter in de applicatie voordat je deze mergen. Exporteer na het mergen naar het serving-artifact dat je daadwerkelijk nodig hebt: een llama.cpp-compatibel GGUF-bestand, een AWQ/GPTQ/compressed-tensors-checkpoint, een FP8-serving-checkpoint of BF16.

Begin voor diffusion met die conservatieve heuristieken en test elke combinatie van pipeline, model en runtime visueel. Perplexity op tekst vertelt je niet of een image pipeline defect is geraakt; gebruik daarom diffusion-specifiek bewijs, zoals SVDQuant, en visuele evaluatie.

Referenties

• JarvisLabs vLLM-benchmarks: JarvisLabs, vLLM Quantization Complete Guide and Benchmarks, 2026. JarvisLabs.
• Hugging Face Optimum-quantization guide: Hugging Face, Quantization conceptual guide. Docs.
• vLLM-quantizationdocumentatie: vLLM-project, Quantization. Docs.
• Documentatie voor vLLM Quantized KV Cache: vLLM-project, Quantized KV Cache. Docs.
• vLLM-benchmarkdocumentatie: vLLM-project, vllm bench serve. Docs.
• LLM Compressor-documentatie: vLLM-project, LLM Compressor. Docs.
• GPTQModel: ModelCloud, GPTQModel. GitHub.
• TensorRT-LLM-quantization: NVIDIA, TensorRT-LLM Quantization. Docs.
• NVIDIA NVFP4: NVIDIA, Introducing NVFP4 for Efficient and Accurate Low-Precision Inference. Blog.
• Hugging Face QuantizedCache: Hugging Face, Cache strategies: Quantized cache. Docs.
• NVIDIA Model Optimizer: NVIDIA, Model Optimizer. GitHub.
• torchao-quantization: PyTorch, torchao quantization overview. Docs.
• bitsandbytes-quantization: Hugging Face, bitsandbytes. Docs.
• HQQ: Dropbox, Half-Quadratic Quantization. GitHub.
• PEFT: Hugging Face, Parameter-Efficient Fine-Tuning. Docs.
• Ollama: lokale model runtime van Ollama. Website.
• LM Studio: lokale AI-runtime van LM Studio. Website.
• Status van AutoGPTQ: AutoGPTQ-repository, gearchiveerd in april 2025. GitHub.
• Status van AutoAWQ: AutoAWQ-repository, gearchiveerd en deprecated sinds mei 2025. GitHub.
• GPTQ: Frantar et al., GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers, NeurIPS 2023. arXiv:2210.17323.
• Marlin: Frantar et al., MARLIN: Mixed-Precision Auto-Regressive Parallel Inference on Large Language Models, arXiv:2408.11743. arXiv:2408.11743.
• AWQ: Lin et al., AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration, MLSys 2024. arXiv:2306.00978.
• SmoothQuant: Xiao et al., SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models, ICML 2023. arXiv:2211.10438.
• QuaRot: Ashkboos et al., QuaRot: Outlier-Free 4-Bit Inference in Rotated LLMs, NeurIPS 2024. arXiv:2404.00456.
• SpinQuant: Meta AI Research, SpinQuant: LLM Quantization with Learned Rotations, arXiv:2405.16406. arXiv:2405.16406.
• QLoRA / NF4: Dettmers et al., QLoRA: Efficient Finetuning of Quantized LLMs, NeurIPS 2023. arXiv:2305.14314.
• SVDQuant / Nunchaku: MIT HAN Lab, SVDQuant: Absorbing Outliers by Low-Rank Components for 4-Bit Diffusion Models, ICLR 2025. arXiv:2411.05007, Nunchaku.
• vLLM PagedAttention: Kwon et al., Efficiënt geheugenbeheer voor het serveren van Large Language Models met PagedAttention, SOSP 2023. arXiv:2309.06180.
• Grouped-Query Attention: Ainslie et al., GQA: Generalized Multi-Query Transformer Models trainen vanuit Multi-Head Checkpoints, EMNLP 2023. arXiv:2305.13245.
• vLLM FP8 KV Cache: Kubler, Kurtic, Wilkinson et al., De status van FP8 KV-Cache en Attention Quantization in vLLM, vLLM Blog, april 2026. vLLM Blog.
• KIVI: Liu et al., KIVI: Een tuning-vrije asymmetrische 2bit-quantization voor de KV Cache, ICML 2024. arXiv:2402.02750.
• KVQuant: Hooper et al., KVQuant: Naar LLM-inference met een contextlengte van 10 miljoen via KV Cache Quantization, NeurIPS 2024. arXiv:2401.18079.
• LLM Serving Evaluation: Kurtic et al., “Geef me BF16 of geef me de dood”? Accuracy-Performance Trade-Offs in LLM Quantization, ACL 2025. arXiv:2411.02355.
• Long-context Quantization Evaluation: Mekala et al., Heeft quantization invloed op de prestaties van modellen bij long-context-taken?, arXiv:2505.20276. arXiv:2505.20276.
• Reasoning Evaluation: Quantization schaadt reasoning? Een empirische studie naar gequantiseerde reasoning-modellen, arXiv:2504.04823. arXiv:2504.04823.
• SlideSparse: SlideSparse: Fast and Flexible (2N-2):2N Structured Sparsity, arXiv:2603.05232v1. arXiv:2603.05232v1.
• HumanEval: OpenAI, HumanEval. GitHub.
• MMLU: Hendrycks et al., Measuring Massive Multitask Language Understanding. arXiv:2009.03300.
• MATH-500: Hugging Face H4, MATH-500. Dataset.
• GGUF and llama.cpp: ggml-org, GGUF file format en llama.cpp. GGUF, llama.cpp.
• Hugging Face GGUF Docs: Hugging Face, GGUF. Docs.
• Reference Repository: slavadubrov/model-compression-demo.