Handleiding voor modelkwantisatie: van fundamenten tot production serving

Viacheslav Dubrov

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

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

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

Kies het doel op basis van de actuele bottleneck: weight memory, activation compute, KV-cachegrootte, kernels, hardware, calibration data of kwaliteit. Een 4-bit model kan in VRAM passen en toch traag draaien 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 GPUs. De hardwarematrix van TensorRT-LLM toont de ondersteunde paden. Voor lange contexten of hoge concurrency kan KV-cache quantization meer geheugen besparen dan weight quantization.

ML- en platform engineers kunnen de bottleneck gebruiken om een kandidaat-format en runtime te selecteren en vervolgens dat exacte serving-pad vóór deployment te valideren.

Zie LLM Quantization Formats voor het korte artifact en de vergelijking van 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 numerieke precisie op zichzelf.

Veelvoorkomende bottlenecks en hun startpunten:

Gebruik deze tabel als routekaart. De volgende secties leggen uit waarom deze startpunten verschillen.

Notatie in servingrecepten

• W{x}A{y} geeft de precisie aan voor ondersteunde weight- en activation-math, doorgaans GEMM-paden in serving engines. W4A16 slaat weights op in 4-bit-vorm en behoudt activations met 16-bit-precisie. 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 naar een lower-precision format mapt.
• GGUF is een file format dat tensors en metadata opslaat voor GGML- en llama.cpp-style runtimes. Een GGUF-bestand kan unquantized tensor types bevatten zoals F16, BF16 of F32, evenals quantized encodings. Presets zijn onder meer Q4_K_M, Q5_K_M, Q8_0, IQ*, TQ* en MXFP4. De tensor encoding bepaalt de quantizationkeuze. GGUF alleen beschrijft geen CUDA-style 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 lower-precision cache format zoals FP8, INT8, INT4 of INT2, afhankelijk van runtime support. Dit verschilt van prefix caching, PagedAttention of offload: die bepalen respectievelijk of cache entries worden hergebruikt, hoe ze worden gealloceerd of waar ze worden opgeslagen.
• GEMM betekent general matrix multiply. Het grootste deel van de transformer-inferencetijd gaat op aan matrixvermenigvuldiging.

2. Quantization is gecontroleerde afronding

Quantization mapt high-precision values naar een kleinere set representable values. Dat is de kerndefinitie die zowel Hugging Face Optimum als TensorRT-LLM gebruiken. Je bespaart memory en bandwidth, maar introduceert ook rounding error.

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

Symmetric en asymmetric mapping

Volgens de affine mapping uit gangbare quantization guides mapt quantization een continue floatwaarde $x \in [\beta, \alpha]$ naar een discrete grid.

• $x$ is de oorspronkelijke high-precision value.
• $x_q$ is de quantized value.
• $s$ is de scale, oftewel step size.
• $z$ is het zero point, de integerlocatie die 0.0 representeert.
• $[q_{\min}, q_{\max}]$ is het target integer range. Signed 4-bitwaarden gebruiken vaak $[-7, 7]$.

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

Dit is hardwarevriendelijk, omdat runtime-math geen zero-point offset hoeft af te trekken. De quantization stack van PyTorch stelt deze affine scale- en zero-pointkeuzes beschikbaar als primitive quantization parameters in torchao.

Asymmetric quantization verschuift het grid om skewed ranges te dekken:

Dit verschoven grid kan positive-only activations beter behouden, maar de offset voegt werk toe tenzij de kernel dit efficiënt afhandelt.

Scale granularity is belangrijk

De scale factor kan een volledig weight tensor, één channel of een kleine groep values omvatten. De FP8 KV-cache docs van vLLM gebruiken hetzelfde onderscheid tussen per-tensor- en per-attention-head-scale-strategieën. Kleinere groepen behouden doorgaans beter de kwaliteit, 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 ranges afhankelijk zijn van de workload.

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

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

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

PTQ en QAT vinden in verschillende fasen plaats

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

Calibration data moet lijken op het verkeer dat je gaat serven. Het KV-cache-calibrationpad van vLLM gebruikt bijvoorbeeld een gecureerde dataset via llm-compressor. Als production prompts lange RAG traces zijn, leveren korte Wikipedia-paragrafen nette benchmarkcijfers maar een defecte deployment op. Calibration kiest static activation- of cache-scales en ranges uit die distributie van korte teksten; het stemt de vaste modelparameters niet af. Echte long-context prompts kunnen andere activation patterns produceren. Long-context quantization evaluations meten dit risico rechtstreeks.

3. Number formats bepalen de hardwarevereisten

Het number format bepaalt welke waarden het model in memory kan representeren. Efficiënte computation vereist runtime-kernels en hardware support voor dezelfde bit-width en hetzelfde format. TensorRT-LLM documenteert zowel de receptlijst als de hardware support matrix.

BF16 en FP16 gebruiken beide 16 bits, maar verdelen precision anders en falen daardoor op verschillende manieren. BF16 behoudt het 8-bit exponentbereik van FP32 en overflowt minder snel. FP16 heeft meer mantissa-bits 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-servingformats.

FP8 heeft twee gangbare varianten. E4M3 biedt meer precision en wordt doorgaans gebruikt voor forward weights en activations. E5M2 biedt een groter dynamic range en is nuttiger voor gradients of volatiele activation paths. vLLM stelt zowel FP8 E4M3- als E5M2-KV-cache-dtypes beschikbaar. 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, evaluatiesuite en servingconfiguratie. Elke deployment heeft nog steeds een eigen quality gate nodig.

Blackwell voegt microscaling formats toe, zoals MXFP8 en NVFP4. In plaats van één scale voor een volledige tensor of row gebruikt microscaling zeer kleine blocks. De NVFP4-uitleg van NVIDIA beschrijft 4-bit floating-point values in blocks van 16, met FP8 scale factors en een hoger-niveau FP32 scale. Deze aanpak probeert een footprint die dicht bij INT4 ligt te combineren met floating-pointgedrag. Daarvoor zijn echter een passende hardwarearchitectuur, compiler en runtime support nodig. Daarom vermeldt TensorRT-LLM FP4- en FP8-support per GPU-generatie.

4. Weight-only versus weight-activation quantization

De notatie WxAy beschrijft de precision van weights en activations, die tijdens inference verschillende belastingen op de GPU leggen.

Tijdens prefill verwerkt het model de input prompt. 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 uit VRAM blijft laden om de volgende token te produceren. Weight-only papers zoals GPTQ en AWQ richten zich op die druk door het aantal weight-bytes te verminderen.

W4A16 comprimeert weights en houdt activations in BF16 of FP16. De GPU laadt minder weight-bytes en dequantizet de weights vervolgens terug naar een higher-precision vorm voor de multiply. Dit helpt bij decode- en fit-to-memoryproblemen. Compute-bound prefill kan weinig voordeel zien, omdat de matrix-math nog steeds in 16-bit draait.

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 matrix-math rechtstreeks in FP8 of INT8 uitvoeren. FP8 kan high-throughput serving daardoor helpen door memory traffic te verminderen en snellere arithmetic te gebruiken. De KV cache heeft een eigen storage setting, dus controleer de cache dtype of cache implementation van de runtime afzonderlijk.

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

5. Algoritmen versus runtime-kernels

Quantizationalgoritmen, zoals GPTQ en AWQ, definiëren hoe de weights van het model naar lower precision worden gemapt. Runtime-kernels, zoals Marlin of custom kernels van vLLM, zijn de low-level GPU-code die de matrixvermenigvuldiging uitvoert. Een sterk gecomprimeerd model draait alleen snel als er een geoptimaliseerde kernel bestaat voor het specifieke quantizationformat.

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

Kopieer deze cijfers niet naar je eigen stack. Ze komen uit één model, één GPU-klasse en één softwareconfiguratie. Ze illustreren een specifieker punt: de algoritmenaam op het checkpoint zegt niet hoe snel serving zal zijn.

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

Benchmark de baseline en compressed variants met dezelfde promptmix en dezelfde tool. Start elke variant als server en geef deze een stabiele API-modelnaam; vllm bench serve stuurt requests naar die API in plaats van het checkpoint zelf te laden:

vllm serve ./outputs/Qwen2.5-32B-Instruct-AWQ-W4A16 \
  --served-model-name qwen2.5-32b-awq \
  --host 127.0.0.1 \
  --port 8000

vllm bench serve \
  --backend openai \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/completions \
  --model qwen2.5-32b-awq \
  --dataset-name sharegpt \
  --num-prompts 200 \
  --input-len 1024 \
  --output-len 256

Meet throughput, TTFT, inter-token latency, memorygebruik en task quality. Wanneer sommige daarvan tegengesteld bewegen, is die trade-off precies wat je vóór shipping moet zien.

Het algoritmemenu

Gebruik deze tabel als routekaart, niet als ranking:

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

Pruning en distillation verlagen servingkosten via afzonderlijke workflows. 2:4 structured sparsity verwijdert weights volgens een patroon dat NVIDIA sparse tensor cores kunnen gebruiken. 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 de shortlist op als het project het extra pruning- of trainingwerk kan dragen.

6. Serving memory omvat meer dan weights

Het gecomprimeerde checkpoint is slechts een deel van de serving-memory-footprint. Dimensioneer de volledige runtime voordat je beslist of weight quantization volstaat. PagedAttention identificeert de KV cache als een belangrijke serving-memoryterm.

Offline quantization kan layer-bounded zijn. Tools zoals llm-compressor kunnen één transformer block laden, calibration- en quantizationmath uitvoeren, het gecomprimeerde block wegschrijven en doorgaan. Daardoor blijft de peak GPU memory dichter bij de grootste actieve layer plus calibration buffers. Je hebt nog steeds CPU RAM en disk nodig voor het source checkpoint, maar de GPU hoeft niet altijd het volledige BF16-model vast te houden.

Peak GPU memory tijdens offline quantization kan er ongeveer zo uitzien:

Serving is strenger. Het volledige gecomprimeerde checkpoint moet resident blijven samen met de KV cache en runtime buffers. De KV cache groeit met context length en actieve batch size:

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}}$ 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 serving-stackvoorbeeld dat dit artikel gebruikt.

KV-cache quantization verandert storage, terwijl reuse allocation verandert

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

Veel serving stacks bewaren dat object in de model- of cache-dtype. 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 als een lower-precision representation plus scales. Latere attention dequantizet de cache binnen de kernel of voert op sommige backends een deel van de attention-operatie uit in het quantized domain.

De stabiele Quantized KV Cache-docs van vLLM stellen dit rechtstreeks beschikbaar met kv_cache_dtype="fp8" of --kv-cache-dtype fp8. vLLM ondersteunt FP8 E4M3- en E5M2-cacheformats, plus per-tensor- en per-attention-head-scale-strategieën. De runtime kan default scales of dataset calibration via llm-compressor gebruiken. Met FlashAttention 3 kan vLLM attention-operaties ook in het FP8-domain uitvoeren door naast keys en values ook queries te kwantiseren.

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

Gewone KV caching slaat eerdere keys en values op om herberekening te vermijden. Prefix caching hergebruikt cache blocks tussen requests met dezelfde prefix. PagedAttention vermindert fragmentation en verbetert allocation, terwijl KV offload cache blocks tussen memory tiers verplaatst. Deze combinaties zijn runtime-dependent. Hugging Face’s QuantizedCache ondersteunt geen offloading. vLLM documenteert zijn quantized KV cache afzonderlijk van prefix caching en andere cache-managementfeatures. Verifieer elke combinatie in de runtime die je deployt.

Het kwaliteitsrisico verschilt ook van weight-only PTQ. KV-cache quantization injecteert error in de attention state die bij elke latere decode step wordt uitgelezen. Test long-context retrieval, multi-turn behavior, 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.

Model size en context length bepalen op zichzelf niet of cache compression beter is dan nog een ronde weight compression. Bereken de cache-bytes met de bovenstaande equation op basis van het KV-head count, de head dimension, de actieve batch en de cache dtype van het model. Vergelijk dit 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 het opnieuw verkleinen van de weights.

7. Hardware beperkt het menu

De weight footprint is eenvoudig te schatten uit parameter count en storage precision, volgens hetzelfde sizingidee als in discussies over serving memory rond de KV cache:

Mixture-of-experts-modellen kunnen per token minder parameters activeren, maar de volledige set weights moet ergens aanwezig blijven tenzij de runtime offload ondersteunt. De quantization support matrix van TensorRT-LLM behandelt MoE-modelfamilies als deploymenttargets met eigen ondersteunde recipes.

Je deploymenthardware beperkt welke quantizationformats haalbaar zijn:

• CPU serving hangt af 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 voor GGML-executors is gebouwd.
• NVIDIA Ampere ondersteunt INT8 tensor-core servingpaden, maar geen native FP8 W8A8 tensor-core math. Gebruikelijke keuzes zijn W4A16 weight-only quantization of static INT8, in lijn met de TensorRT-LLM hardware support matrix.
• NVIDIA Ada en Hopper ondersteunen FP8-servingpaden in TensorRT-LLM. FP8 W8A8 serving is het testen waard op deze GPUs.
• NVIDIA Blackwell voegt NVFP4- en microscaling-support toe, maar het softwarepad blijft belangrijk. Behandel vroege low-bit floating-point stacks als versiegevoelig.

8. Calibration en evaluatie vóór deployment

Een model dat laadt, heeft een smoke test doorstaan. Deployment vereist quality- en servingchecks voor de target workload. Recente quantizationevaluaties rapporteren uiteenlopende 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 target workload op. Static PTQ hangt af van calibration data die overeenkomt met de production distribution.
• Laat sequence lengths overeenkomen. Korte single-turn prompts brengen long-context activation behavior niet aan het licht.
• Houd embed_tokens en lm_head in higher precision als de methode of runtime dit toestaat; dit is een gangbaar exclusion pattern in LLM Compressor recipes.
• Gebruik voldoende samples om activation ranges te stabiliseren. Het vLLM KV-cachevoorbeeld stelt NUM_CALIB_SAMPLES = 512 in. Beschouw dat als één gedocumenteerd voorbeeld, niet als een universeel aantal. Het juiste aantal samples hangt af van de methode, het model, de sequence length en de production workload.
• Redigeer secrets en private userdata voordat je production logs gebruikt.

Test bij evaluatie zowel language quality als serving behavior:

• Perplexity op een standard corpus vangt brede language degradation op, maar de JarvisLabs-benchmark herinnert eraan dat perplexity en throughput verschillend kunnen bewegen.
• Domain tasks brengen failures aan het licht die perplexity verbergt. Gebruik HumanEval voor coding, MMLU voor brede kennis en AIME of MATH-500 voor mathematical reasoning wanneer die domains relevant zijn.
• Format checks zijn belangrijk voor agentic systems. Test JSON Schema-compliance, markdown-output, tool-call shape en refusal behavior, omdat quantized model evaluations application-level failures kunnen missen zelfs wanneer aggregate benchmark accuracy stabiel lijkt.
• Long-context tests brengen schade door KV-cache quantization aan het licht. Needle-in-a-haystack is primitief, maar long-context quantization results laten zien waarom deze checks in de deploy gate thuishoren.
• Load tests moeten throughput, TTFT, inter-token latency, maximale batchcapaciteit en peak memory rapporteren. vLLM stelt deze metingen beschikbaar via vllm bench serve.

Evalueer reasoning-heavy models grondig. Sub-4-bit of unrotated W4A4 quantization kan reasoning accuracy schaden, zelfs wanneer baseline perplexity stabiel lijkt. Dat is de kernwaarschuwing uit de quantized reasoning-modelstudie.

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 dit artikel: vLLM, LLM Compressor, TensorRT-LLM en de algoritmepapers.

De publieke 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 vereist het benchmarkplan nog de target servinghardware.

Kopieer de FP8-recipe-output van die pinned revision niet. Het recipe --algorithm fp8-dynamic-command produceert een intern inconsistent model- en outputpad. Het command blijft hier weggelaten totdat de companion is gerepareerd.

Clone de repository en inspecteer de ondersteunde algoritmen:

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 daarna een recipe en preview 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 doel, schat memory, voer een dry run van de recipe uit, benchmark serving en vergelijk vervolgens de kwaliteit met thresholds. Deze volgorde weerspiegelt de scheiding in dit artikel tussen memory sizing, runtime benchmarking en quality evaluation.

10. Diffusion-modellen vereisen een afzonderlijk pad

Diffusion- en diffusion-transformerpipelines hebben ander activation behavior dan autoregressieve LLMs. SVDQuant behandelt diffusion quantization als een afzonderlijk probleem rond activation outliers.

Autoregressieve LLMs genereren één token per keer. Diffusion-modellen voeren herhaalde denoising steps uit en hun activation distributions verschuiven tijdens dat proces. Een standaard 4-bit LLM-quantizationpass kan het geheugen van een diffusion-model verlagen, maar tegelijk ernstige visual artifacts veroorzaken. Diffusiongerichte methoden zoals SVDQuant / Nunchaku en NVIDIA ModelOpt diffusion quantization pakken dit afwijkende activation pattern 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 bij de eerste vergelijking in 16-bit. Deze conservatieve heuristiek vermindert één bron van image artifacts. Test lower precision alleen wanneer de methode en target pipeline 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 memory, latency en image quality voor de target pipeline. Diffusion quantization methods hanteren dezelfde component-level aanpak.
3. Behandel text encoders afzonderlijk. Het kwantiseren van T5-XXL of CLIP kan prompt alignment of text rendering in een bepaalde pipeline beïnvloeden. Evalueer ze daarom apart en ga niet uit van generiek transformer behavior.
4. Gebruik diffusion-aware methoden zoals SVDQuant wanneer activation outliers het hoofdprobleem zijn.
5. Evalueer met images, niet met text metrics. Controleer prompt adherence, text rendering, skin tones, color balance, fine detail, latency en VRAM.

Als de evaluationset alleen eenvoudige of veelvoorkomende prompts bevat, mis je edge-case failures. Neem moeilijke gevallen op: kleine tekst, handen, herhaalde objecten, structured layouts en prompts met negative constraints, omdat diffusion-quantizationfailures visueel zichtbaar worden en niet in language-model perplexity.

11. Production defaults

Begin voor enterprise LLM serving met een BF16-baseline in de exacte 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 AWQ of GPTQ W4A16 met Marlin-class kernels. Als long context of concurrency het probleem is, test FP8 KV-cache quantization. Als herhaalde prefixes het probleem zijn, activeer dan ook prefix caching. Ship de compressed variant alleen wanneer zowel quality- als servingbenchmarks slagen.

Begin voor local en edge inference met een GGUF-bestand met Q4_K_M of Q5_K_M. Ga over naar een Q8_0 GGUF wanneer memory dit toestaat en quality belangrijker is dan footprint. Onder 4-bit gaan is een last resort, geen default.

Gebruik voor fine-tuning NF4 met QLoRA om adapters goedkoop te trainen. Evalueer de adapter in de applicatie voordat je deze merge’t. Exporteer na het mergen naar het serving artifact dat je werkelijk nodig hebt: een llama.cpp-compatibel GGUF-bestand, een AWQ/GPTQ/compressed-tensors checkpoint, een FP8 serving checkpoint of BF16.

Begin voor diffusion met deze conservatieve heuristieken en test elke combinatie van pipeline, model en runtime visueel. Text perplexity vertelt je niet of een image pipeline defect is geraakt. Gebruik daarom diffusion-specifieke evidence zoals SVDQuant en visual evaluation.

References

• JarvisLabs vLLM Benchmarks: JarvisLabs, vLLM Quantization Complete Guide and Benchmarks, 2026. JarvisLabs.
• Hugging Face Optimum Quantization Guide: Hugging Face, Quantization conceptual guide. Docs.
• vLLM Quantization Docs: vLLM project, Quantization. Docs.
• vLLM Quantized KV Cache Docs: vLLM project, Quantized KV Cache. Docs.
• vLLM Benchmark Docs: vLLM project, vllm bench serve. Docs.
• LLM Compressor Docs: 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: Ollama local model runtime. Website.
• LM Studio: LM Studio local AI runtime. Website.
• AutoGPTQ status: AutoGPTQ repository, archived April 2025. GitHub.
• AutoAWQ status: AutoAWQ repository, archived and deprecated May 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., Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP 2023. arXiv:2309.06180.
• Grouped-Query Attention: Ainslie et al., GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints, EMNLP 2023. arXiv:2305.13245.
• vLLM FP8 KV Cache: Kubler, Kurtic, Wilkinson et al., The State of FP8 KV-Cache and Attention Quantization in vLLM, vLLM Blog, April 2026. vLLM Blog.
• KIVI: Liu et al., KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache, ICML 2024. arXiv:2402.02750.
• KVQuant: Hooper et al., KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, NeurIPS 2024. arXiv:2401.18079.
• LLM Serving Evaluation: Kurtic et al., “Give Me BF16 or Give Me Death”? Accuracy-Performance Trade-Offs in LLM Quantization, ACL 2025. arXiv:2411.02355.
• Long-context Quantization Evaluation: Mekala et al., Does quantization affect models’ performance on long-context tasks?, arXiv:2505.20276. arXiv:2505.20276.
• Reasoning Evaluation: Quantization Hurts Reasoning? An Empirical Study on Quantized Reasoning Models, 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.