Guide zur Model Quantization: Von den Grundlagen bis zum produktiven Model Serving

Viacheslav Dubrov

2026-07-05 · Aktualisiert 2026-07-22 · 24 Min. · Modellentwicklung · KI-Infrastruktur

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Quantization verwendet weniger Bits zur Darstellung von Model-Werten. Ein Serving-Pfad kann Weights, Activations, den KV-Cache oder eine Kombination daraus quantisieren, wobei jedes Ziel ein anderes Serving-Problem löst.

Wählen Sie das Ziel anhand des aktuellen Bottlenecks: Weight Memory, Activation Compute, KV-Cache-Größe, Kernels, Hardware, Calibration Data oder Qualität. Ein 4-Bit-Model passt möglicherweise in den VRAM, läuft mit einem nicht optimierten Kernel aber trotzdem langsam, wie der JarvisLabs-vLLM-Benchmark zeigt. FP8 funktioniert auf NVIDIA-Hopper-Hardware mit einem kompatiblen Runtime gut, bietet auf nicht unterstützten GPUs jedoch keinen nativen Vorteil. Die Hardware-Matrix von TensorRT-LLM zeigt die unterstützten Pfade. Bei langen Contexts oder hoher Concurrency kann KV-Cache Quantization mehr Speicher einsparen als Weight Quantization.

ML- und Platform Engineers können anhand des Bottlenecks ein geeignetes Format und einen passenden Runtime auswählen und anschließend genau diesen Serving-Pfad vor dem Deployment validieren.

Eine kurze Übersicht sowie den Methodenvergleich finden Sie unter LLM Quantization Formats.

1. Mit dem Bottleneck beginnen

Ermitteln Sie vor der Wahl der Bitbreite, was den Workload begrenzt. Dabei kann es sich um den Speicherbedarf der Model Weights, Prefill Compute, Decode-Bandbreite oder den KV-Cache handeln – und nicht um die numerische Präzision selbst.

Häufige Bottlenecks und ihre Ausgangspunkte:

Verwenden Sie diese Tabelle als Orientierung. In den folgenden Abschnitten wird erläutert, warum sich diese Ausgangspunkte unterscheiden.

Verwendete Notation in Serving-Rezepten

• W{x}A{y} gibt die Präzision für unterstützte Weight- und Activation-Berechnungen an, typischerweise für GEMM-Pfade in Serving Engines. W4A16 speichert Weights im 4-Bit-Format und hält Activations in 16-Bit-Präzision. W8A8 verwendet 8-Bit-Weights und -Activations in unterstützten Compute-Pfaden, definiert aber nicht automatisch den persistenten Storage-Dtype jedes Runtime-Tensors.
• FP8, INT8, INT4, NF4 sind Zahlenformate. Sie legen fest, welche Werte repräsentiert werden können.
• GPTQ, AWQ, SmoothQuant, QuaRot sind Algorithmen. Sie bestimmen, wie ein trainiertes Model in ein Format mit geringerer Präzision überführt wird.
• GGUF ist ein Dateiformat, das Tensoren und Metadaten für GGML- und llama.cpp-artige Runtimes speichert. Eine GGUF-Datei kann unquantisierte Tensor-Typen wie F16, BF16 oder F32 sowie quantisierte Encodings enthalten. Zu den Presets gehören Q4_K_M, Q5_K_M, Q8_0, IQ*, TQ* und MXFP4. Das Tensor-Encoding bestimmt die Quantization-Auswahl. GGUF allein beschreibt kein CUDA-artiges FP8-W8A8-Serving-Rezept.
• KV cache ist der während der Generation verwendete Attention-Cache. Er speichert zuvor berechnete Keys und Values, damit das Model nicht für jeden Token die gesamte Konversation neu berechnen muss.
• KV-cache quantization speichert gecachte Key/Value-Activation-Tensoren in einem Cache-Format mit geringerer Präzision, etwa FP8, INT8, INT4 oder INT2, abhängig vom Support der Runtime. Dies unterscheidet sich von Prefix Caching, PagedAttention oder Offload: Diese legen fest, ob Cache-Einträge wiederverwendet werden, wie sie allokiert werden oder wo sie liegen.
• GEMM steht für General Matrix Multiply. Der größte Teil der Transformer-Inference entfällt auf Matrixmultiplikationen.

2. Quantization ist kontrolliertes Runden

Quantization bildet Werte mit hoher Präzision auf eine kleinere Menge darstellbarer Werte ab. Das ist die Kerndefinition, die sowohl von Hugging Face Optimum als auch von TensorRT-LLM verwendet wird. Sie sparen Speicher und Bandbreite, führen aber zugleich Rundungsfehler ein.

INT4 bietet nur 16 diskrete Werte. Werden BF16-Weights auf dieses Raster abgebildet, entstehen Rundungsfehler. Verfahren wie GPTQ, AWQ und SVDQuant konzentrieren sich darauf, Outliers zu erhalten und den Rekonstruktionsfehler zu reduzieren. Eine gute Abbildung spart Speicher bei geringem Qualitätsverlust. Eine schlechte beeinträchtigt Reasoning, Instruction Following oder visuelle Qualität.

Symmetrische und asymmetrische Abbildung

Ausgehend von der affinen Abbildung, die in gängigen Quantization Guides verwendet wird, bildet Quantization einen kontinuierlichen Float-Wert $x \in [\beta, \alpha]$ auf ein diskretes Raster ab.

• $x$ ist der ursprüngliche hochpräzise Wert.
• $x_q$ ist der quantisierte Wert.
• $s$ ist die Scale beziehungsweise Schrittweite.
• $z$ ist der Zero Point, also die ganzzahlige Position, die 0.0 repräsentiert.
• $[q_{\min}, q_{\max}]$ ist der Zielbereich für Ganzzahlen. Vorzeichenbehaftete 4-Bit-Werte verwenden häufig $[-7, 7]$.

Symmetric Quantization zentriert das Raster um null und setzt $z = 0$:

Das ist hardwarefreundlich, weil die Runtime-Berechnung keinen Zero-Point-Offset abziehen muss. PyTorchs Quantization-Stack stellt diese affinen Scale- und Zero-Point-Auswahlen als grundlegende Quantization-Parameter in torchao bereit.

Asymmetric Quantization verschiebt das Raster, um asymmetrische Wertebereiche abzudecken:

Dieses verschobene Raster kann Activations, die ausschließlich positive Werte enthalten, besser erhalten. Der Offset verursacht jedoch zusätzlichen Rechenaufwand, sofern der Kernel ihn nicht effizient verarbeitet.

Die Granularität der Scale ist entscheidend

Der Scale-Faktor kann einen gesamten Weight-Tensor, einen einzelnen Channel oder eine kleine Gruppe von Werten abdecken. Die FP8-KV-Cache-Dokumentation von vLLM verwendet dieselbe Unterscheidung zwischen Per-Tensor- und Per-Attention-Head-Scale-Strategien. Kleinere Gruppen erhalten die Qualität in der Regel besser, benötigen jedoch mehr Scale-Metadaten.

Weights sind statisch, daher können ihre Scales offline berechnet werden, bevor du das Model lädst. Activations ändern sich mit jedem Token, wodurch ihre Wertebereiche vom Workload abhängen.

Der KV Cache liegt zwischen diesen beiden Fällen. Keys und Values beginnen als Activation-Tensoren des Runtimes: Jeder Layer berechnet sie während des Forward Passes aus den Hidden States. Nach ihrer Erzeugung sind sie keine flüchtigen Matmul-Zwischenergebnisse mehr, sondern persistenter Serving-State, den Attention für spätere Tokens liest.

Eine Serving Engine kann diesen State in geringerer Präzision speichern und die Scale-Metadaten zusammen mit ihm ablegen. vLLM’s Quantized KV Cache, TensorRT-LLM’s FP8 KV Cache und Transformers QuantizedCache bieten diese Speicheroption jeweils an.

Die Präzision der Cache-Speicherung bleibt von der Activation-Präzision getrennt, die innerhalb von Linear-Kernels verwendet wird. „KV-Cache Quantization“ bezeichnet eine Cache-Optimierung, nicht jede Technik, die Cache-Einträge wiederverwendet, allokiert oder verschiebt.

PTQ und QAT finden in unterschiedlichen Phasen statt

Post-Training Quantization, kurz PTQ, komprimiert ein trainiertes Model nachträglich. Quantization-Aware Training, kurz QAT, setzt das Model während des Trainings Quantization Noise aus, damit es sich daran anpassen kann.

Kalibrierungsdaten müssen dem Traffic entsprechen, den Sie später bedienen werden. Der KV-Cache-Kalibrierungspfad von vLLM verwendet beispielsweise ein kuratiertes Dataset über llm-compressor. Wenn Produktions-Prompts aus langen RAG-Traces bestehen, liefern kurze Wikipedia-Absätze zwar saubere Benchmark-Zahlen, aber ein fehlerhaftes Deployment. Die Kalibrierung wählt statische Activation- oder Cache-Skalen und Wertebereiche aus dieser Kurztextverteilung; sie passt die festen Model-Parameter nicht an. Echte Prompts mit langem Context können andere Activation-Muster erzeugen. Evaluierungen der Quantization für langen Context messen dieses Risiko direkt.

3. Zahlenformate bestimmen die Hardwareanforderungen

Das Zahlenformat legt fest, welche Werte das Model im Speicher darstellen kann. Für effiziente Berechnungen sind Runtime-Kernels und Hardware-Unterstützung für dieselbe Bitbreite und dasselbe Format erforderlich. TensorRT-LLM dokumentiert sowohl die Rezeptliste als auch die Hardware-Support-Matrix.

BF16 und FP16 verwenden beide 16 Bits, verteilen die Präzision jedoch unterschiedlich und scheitern daher auf unterschiedliche Weise. BF16 behält den 8-Bit-Exponentbereich von FP32 bei und läuft weniger schnell in einen Overflow. FP16 verfügt über mehr Mantissenbits und einen engeren Exponentbereich, weshalb Activation-Spikes mehr Aufmerksamkeit erfordern. Die Evaluation von Kurtic et al. verwendet ausdrücklich BF16 als Baseline beim Vergleich von FP8-, INT8- und INT4-Serving-Formaten.

FP8 hat zwei gängige Varianten. E4M3 bietet mehr Präzision und wird üblicherweise für Forward Weights und Activations verwendet. E5M2 bietet einen größeren Dynamikbereich und eignet sich besser für Gradients oder volatile Activation-Pfade. vLLM unterstützt sowohl FP8-E4M3- als auch E5M2-KV-Cache-Dtypes. In der ACL-2025-Studie von Kurtic et al. mit dem Titel „Give Me BF16 or Give Me Death“ war FP8 W8A8 praktisch verlustfrei für die Llama-3.1-Familie über mehr als 500.000 Evals hinweg. Das Ergebnis gilt für diese Model-Familie, die Eval-Suite und das verwendete Serving-Setup. Für jedes Deployment ist weiterhin ein eigener Quality Gate erforderlich.

Blackwell führt Microscaling-Formate wie MXFP8 und NVFP4 ein. Statt einen Scale-Faktor für einen gesamten Tensor oder eine Zeile zu verwenden, arbeitet Microscaling mit sehr kleinen Blöcken. NVIDIAs NVFP4-Erklärung beschreibt 4-Bit-Floating-Point-Werte in Blöcken aus jeweils 16 Werten, mit FP8-Scale-Faktoren und einem übergeordneten FP32-Scale-Faktor. Dieser Ansatz soll eine annähernde INT4-Speicherbelegung mit Floating-Point-Verhalten ermöglichen. Er erfordert jedoch eine passende Hardware-Architektur sowie Unterstützung durch Compiler und Runtime. Deshalb führt TensorRT-LLM FP4- und FP8-Support nach GPU-Generation auf.

4. Weight-only- vs. Weight-Activation-Quantization

Die Notation WxAy beschreibt die Präzision von Weights und Activations, die die GPU während der Inference auf unterschiedliche Weise belasten.

Beim Prefill verarbeitet das Model den Input-Prompt. Diese Phase ist üblicherweise Compute-bound, da die GPU große Matrix-Multiplikationen ausführt. Deshalb sind W8A8-FP8/INT8-Rezepte für Throughput-orientiertes Serving relevant.

Beim Decode generiert das Model jeweils einen Token. Diese Phase ist häufig durch die Memory Bandwidth begrenzt, da die GPU kontinuierlich Weights aus dem VRAM lädt, um den nächsten Token zu erzeugen. Weight-only-Papers wie GPTQ und AWQ zielen auf diese Belastung ab, indem sie die Anzahl der Weight-Bytes reduzieren.

W4A16 komprimiert Weights und belässt Activations in BF16 oder FP16. Die GPU lädt weniger Weight-Bytes und dequantisiert die Weights anschließend für die Multiplikation zurück in ein Format mit höherer Präzision. Das hilft beim Decode und bei Fit-to-Memory-Problemen. Compute-bound Prefill profitiert möglicherweise nur wenig, da die Matrix-Mathematik weiterhin in 16 Bit ausgeführt wird.

W8A8 komprimiert Weights und die Activation-Tensoren, die von unterstützten Matmul-Kernels verwendet werden. Verfügt die Hardware über native Low-Precision-Tensor-Cores, kann die Serving Engine die Matrix-Mathematik direkt in FP8 oder INT8 ausführen. FP8 kann dadurch bei High-Throughput-Serving helfen, indem es den Memory Traffic reduziert und schnellere Arithmetik nutzt. Der KV-Cache verfügt über eine eigene Storage-Einstellung. Prüfe daher separat den Cache-Dtype oder die Cache-Implementierung der Runtime.

Wenn das Model kaum in den VRAM passt, beginnen Sie mit Weight-only Quantization, um den Memory Footprint zu reduzieren. Wenn das Model zwar passt, aber bei hoher Batch-Last mit dem Throughput kämpft, evaluieren Sie FP8 oder INT8 W8A8, um die Compute-Phase zu beschleunigen. Wenn Memory-Probleme erst bei langen Conversations auftreten, schätzen Sie zunächst den KV-Cache-Term. Testen Sie KV-Cache Quantization, wenn dieser Term dominiert. Aktivieren Sie Prefix Caching, wenn wiederholte Prefixes dominieren.

5. Algorithmen vs. Runtime-Kernels

Quantization-Algorithmen (wie GPTQ oder AWQ) definieren, wie die Model Weights auf niedrigere Präzision abgebildet werden. Runtime-Kernels (wie Marlin oder Custom Kernels von vLLM) sind der GPU-Code auf niedriger Ebene, der die Matrixmultiplikation ausführt. Ein stark komprimiertes Model läuft nur dann schnell, wenn es für sein spezifisches Quantization-Format einen optimierten Kernel gibt.

Der vLLM-Benchmark von JarvisLabs mit Qwen2.5-32B-Instruct auf einer NVIDIA H200 macht den Einfluss des Kernels sichtbar:

Übertragen Sie diese Zahlen nicht einfach auf Ihren eigenen Stack. Sie stammen von einem Model, einer GPU-Klasse und einem Software-Setup. Sie zeigen einen engeren Punkt: Der Algorithmusname im Checkpoint sagt nicht aus, wie schnell das Serving sein wird.

Beispielsweise verwenden AWQ und Marlin-AWQ dieselben 4-Bit-Weights. Die Marlin-Implementierung ist deutlich schneller, weil ihr CUDA-Kernel Dequantization und Matrixmultiplikation zu einer einzigen, hochoptimierten GPU-Operation fusioniert.

Benchmarken Sie die Baseline und die komprimierten Varianten mit demselben Prompt-Mix und demselben Tool. Starten Sie jede Variante als Server und geben Sie ihr einen stabilen API-Modelnamen; vllm bench serve sendet Requests an diese API, statt den Checkpoint selbst zu 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

Erfassen Sie Throughput, TTFT, Inter-Token-Latency, Memory-Nutzung und Task-Qualität. Wenn sich einige dieser Werte in entgegengesetzte Richtungen bewegen, ist genau dieser Trade-off sichtbar, bevor Sie das System in Produktion nehmen.

Das Algorithmus-Menü

Verwende diese Tabelle als Orientierung, nicht als Ranking:

Die Toolchain entwickelt sich aktiv weiter. AutoGPTQ wurde im April 2025 archiviert, und AutoAWQ wurde im Mai 2025 archiviert und offiziell deprecated. Für neue compressed-tensors-Checkpoints, die von vLLM verarbeitet werden, solltest du mit llm-compressor beginnen. Verwende GPTQModel, wenn du den aktiven GPTQ-Pfad mit Marlin, Machete, MoE-Speicheroptionen oder Disk-Offload benötigst.

Pruning und Distillation reduzieren die Serving-Kosten ebenfalls, allerdings über separate Workflows. 2:4 Structured Sparsity entfernt Weights in einem Muster, das NVIDIA Sparse Tensor Cores nutzen können. Distillation trainiert ein kleineres Student Model darauf, ein größeres Model zu imitieren, was für eng umrissene Tasks gut funktionieren kann. Nimm einen der beiden Pfade nur dann in die Shortlist auf, wenn das Projekt den zusätzlichen Pruning- oder Trainingsaufwand tragen kann.

6. Serving Memory umfasst mehr als Weights

Der komprimierte Checkpoint macht nur einen Teil des Serving-Memory-Footprints aus. Dimensionieren Sie die vollständige Runtime, bevor Sie entscheiden, ob Weight Quantization ausreicht. PagedAttention weist den KV Cache als wesentlichen Bestandteil des Serving Memory aus.

Offline Quantization kann auf einzelne Layer begrenzt werden. Tools wie llm-compressor können einen Transformer-Block laden, Calibration und Quantization ausführen, den komprimierten Block schreiben und anschließend fortfahren. Dadurch bleibt der Peak der GPU Memory näher am größten aktiven Layer zuzüglich der Calibration Buffer. CPU RAM und Disk für den Source Checkpoint benötigen Sie weiterhin, aber die GPU muss nicht immer das vollständige BF16 Model halten.

Die GPU Memory während der Offline Quantization kann eher so aussehen:

Serving stellt höhere Anforderungen. Der vollständige komprimierte Checkpoint muss zusammen mit dem KV Cache und den Runtime Buffer resident bleiben. Der KV Cache wächst mit der Context Length und der aktiven Batch Size:

Dabei gilt:

• $L$ ist die Anzahl der Layer.
• $H_{\text{kv}}$ ist die Anzahl der Key-Value Attention Heads. Grouped-Query Attention reduziert diesen Wert, indem viele Query Heads weniger KV Heads gemeinsam nutzen.
• $D$ ist die Dimension jedes Heads, typischerweise 128 oder 256.
• $S_{\text{ctx}}$ ist die Summe aus Prompt Tokens und generierten Tokens.
• $B_{\text{batch}}$ ist die aktive Serving Batch.
• $\text{BytesPerValue}$ ist 2 für BF16 oder FP16 und 1 für FP8 oder INT8. Der FP8-KV-Cache-Modus von vLLM ist das in diesem Artikel verwendete Beispiel aus dem Serving Stack.

KV-Cache Quantization verändert die Speicherung, Reuse dagegen die Allocation

Der KV Cache kann während der Inference quantisiert werden. Jeder Decode Step erzeugt K- und V-Activation-Tensoren für das neue Token. Ein W8A8 Model verwendet für unterstützte Projection Math möglicherweise bereits FP8 oder INT8, der Cache bleibt jedoch ein separates Storage Object.

Viele Serving Stacks halten dieses Object im Model- oder Cache-Dtype. Um dies zu ändern, aktivieren Sie einen KV-Cache-Dtype, verwenden einen Checkpoint mit Cache Scales oder wählen eine quantized Cache Implementation.

Wenn KV-Cache Quantization aktiviert ist, schreibt die Engine Einträge als Repräsentation mit niedrigerer Precision plus Scales. Bei der späteren Attention dequantisiert der Kernel den Cache entweder intern oder führt auf manchen Backends einen Teil der Attention-Operation in der quantisierten Domäne aus.

Die stabile Dokumentation zum Quantized KV Cache von vLLM macht dies direkt mit kv_cache_dtype="fp8" oder --kv-cache-dtype fp8 zugänglich. vLLM unterstützt die FP8-KV-Cache-Formate E4M3 und E5M2 sowie Scale-Strategien pro Tensor und pro Attention Head. Es kann Default Scales oder Dataset Calibration über llm-compressor verwenden. Mit FlashAttention 3 kann vLLM Attention-Operationen außerdem in der FP8-Domäne ausführen, indem zusätzlich zu Keys und Values auch Queries quantisiert werden.

TensorRT-LLM stellt den FP8 KV Cache über KvCacheConfig(dtype='fp8') bereit und führt FP8 KV Cache sowie NVFP4 KV Cache als separate Quantization Recipes neben Weight/Activation Quantization auf. Hugging Face Transformers bietet ebenfalls einen QuantizedCache-Pfad über cache_implementation="quantized". Dabei unterstützt hqq die Cache-Formate int2, int4 und int8, während quanto int2 und int4 unterstützt.

Gewöhnliches KV-Caching speichert bereits berechnete Keys und Values, um eine erneute Berechnung zu vermeiden. Prefix Caching verwendet Cache-Blöcke über Requests mit demselben Prefix hinweg wieder. PagedAttention reduziert Fragmentierung und verbessert die Allokation, während KV-Offloading Cache-Blöcke zwischen Memory-Tiers verschiebt. Diese Kombinationen hängen vom Runtime ab. Hugging Faces QuantizedCache unterstützt kein Offloading. vLLM dokumentiert seinen quantisierten KV-Cache getrennt von Prefix Caching und anderen Cache-Management-Features. Verifizieren Sie jede Kombination in dem Runtime, den Sie deployen.

Das Qualitätsrisiko unterscheidet sich ebenfalls von Weight-only PTQ. KV-Cache-Quantization bringt Fehler in den Attention-State ein, der bei jedem späteren Decode-Schritt gelesen wird. Testen Sie Long-Context-Retrieval, Multi-Turn-Verhalten, Safety und Refusals, das Formatting von Tool Use sowie die Output-Latency separat. KVQuant, KIVI und die vLLM-FP8-KV-Cache-Studie evaluieren KV-Cache-Quantization jeweils als eigenständiges Problem.

Model-Größe und Context Length allein bestimmen nicht, ob Context Compression eine weitere Runde Weight Compression übertrifft. Berechnen Sie die Cache-Bytes mit der obigen Gleichung anhand der KV-Head-Anzahl, der Head-Dimension, der aktiven Batch-Größe und des Cache-Dtype des Models. Vergleichen Sie dieses Ergebnis anschließend mit den eingesparten Bytes zwischen zwei konkret benannten Weight-Formaten, etwa BF16 und INT4. Wenn der Cache größer ist, kann das Testen von FP8-KV-Cache-Quantization mehr Serving-Memory freisetzen als eine erneute Verkleinerung der Weights.

7. Hardware schränkt die Auswahl ein

Der Weight-Footprint lässt sich anhand der Parameteranzahl und der Storage-Precision leicht schätzen – nach demselben Sizing-Prinzip wie in Diskussionen zum Serving-Memory rund um den KV-Cache:

Mixture-of-Experts-Modelle können pro Token weniger Parameter aktivieren. Das vollständige Set der Weights muss jedoch weiterhin irgendwo liegen, sofern der Runtime kein Offloading unterstützt. Die Quantization-Support-Matrix von TensorRT-LLM behandelt MoE-Model-Familien als Deployment-Ziele mit eigenen unterstützten Recipes.

Ihre Deployment-Hardware schränkt ein, welche Quantization-Formate praktikabel sind:

• CPU-Serving hängt von Vector Instructions wie AVX-512 oder AMX ab. Eine GGUF-Datei, die über llama.cpp geladen wird, ist der praktikable Weg.
• Apple Silicon verwendet Unified Memory, sodass lokale Models einen großen gemeinsam genutzten RAM-Pool statt dediziertem VRAM nutzen können. GGUF und llama.cpp bleiben der gängige Pfad für lokale Runtimes, da GGUF für GGML-Executors entwickelt wurde.
• NVIDIA Ampere unterstützt INT8-Tensor-Core-Serving-Pfade, aber keine native FP8-W8A8-Tensor-Core-Mathematik. Gängige Optionen sind W4A16 Weight-only-Quantization oder statisches INT8, entsprechend der TensorRT-LLM-Hardware-Support-Matrix.
• NVIDIA Ada und Hopper unterstützen FP8-Serving-Pfade in TensorRT-LLM. FP8 W8A8-Serving ist auf diesen GPUs einen Test wert.
• NVIDIA Blackwell ergänzt NVFP4- und Microscaling-Support, aber der Softwarepfad bleibt entscheidend. Behandle frühe Low-Bit-Floating-Point-Stacks als versionsabhängig.

8. Calibration und Evaluation vor dem Deployment

Ein Model, das geladen werden kann, hat einen Smoke Test bestanden. Für ein Deployment sind Quality- und Serving-Checks für den Ziel-Workload erforderlich. Aktuelle Quantization-Evaluations berichten über unterschiedliche Ergebnisse für LLM-Serving, Long-Context-Tasks und Reasoning-intensive Models.

Verwende für die Calibration Prompts, die der Produktion ähneln:

• Beziehe RAG-Traces, SQL-Queries, Agent-Histories, Code-Tasks, Tool-Call-Payloads und System Prompts aus dem Ziel-Workload ein. Static PTQ hängt davon ab, dass die Calibration Data der Produktionsverteilung entspricht.
• Passe die Sequence Lengths an. Kurze Single-Turn-Prompts machen Long-Context-Activation-Verhalten nicht sichtbar.
• Halte embed_tokens und lm_head in höherer Precision, wenn die Methode oder Runtime dies erlaubt – ein gängiges Exclusion Pattern in LLM-Compressor-Rezepten.
• Verwende genügend Samples, um die Activation Ranges zu stabilisieren. Das vLLM-KV-Cache-Beispiel setzt NUM_CALIB_SAMPLES = 512. Betrachte das als ein dokumentiertes Beispiel, nicht als universelle Anzahl. Die richtige Sample-Anzahl hängt von Methode, Model, Sequence Length und Produktions-Workload ab.
• Entferne Secrets und private User-Daten, bevor du Produktions-Logs verwendest.

Teste bei der Evaluation sowohl die Language Quality als auch das Serving-Verhalten:

• Perplexity auf einem Standard-Corpus erfasst eine allgemeine Verschlechterung der Sprachqualität. Der JarvisLabs-Benchmark erinnert jedoch daran, dass sich Perplexity und Throughput unterschiedlich entwickeln können.
• Domain-Tasks erkennen Fehler, die Perplexity verbirgt. Verwende HumanEval für Coding, MMLU für allgemeines Wissen sowie AIME oder MATH-500 für mathematisches Reasoning, wenn diese Bereiche relevant sind.
• Formatprüfungen sind für agentische Systeme wichtig. Teste die Einhaltung des JSON-Schemas, Markdown-Output, die Form von Tool Calls und das Verweigerungsverhalten, da Evaluierungen quantisierter Modelle Fehler auf Anwendungsebene übersehen können, selbst wenn die aggregierte Benchmark-Genauigkeit stabil aussieht.
• Long-Context-Tests erkennen Schäden durch die Quantisierung des KV-Caches. Needle-in-a-Haystack ist zwar grob, aber die Ergebnisse zur Long-Context-Quantisierung zeigen, warum solche Prüfungen in den Deploy-Gate gehören.
• Load Tests sollten Throughput, TTFT, Inter-Token-Latency, die maximale Batch-Kapazität und den Spitzenverbrauch an Speicher ausweisen. vLLM stellt diese Messwerte über vllm bench serve bereit.

Bewerte Reasoning-lastige Modelle rigoros. Eine Quantisierung mit weniger als 4 Bit oder unrotierter W4A4-Quantisierung kann die Reasoning-Genauigkeit beeinträchtigen, selbst wenn die grundlegende Perplexity stabil aussieht. Genau darin liegt die zentrale Warnung der Studie zu quantisierten Reasoning-Modellen.

9. Workflow für das Begleit-Repository

Das Begleit-Repository slavadubrov/model-compression-demo soll den Entscheidungsprozess reproduzierbar machen. Es verwendet uv und konzentriert sich auf Planung, Rezepte, Dry Runs und Benchmark-Konfigurationen, die auf denselben Quellen wie hier basieren: vLLM, LLM Compressor, TensorRT-LLM und die Papers zu den Algorithmen.

Die öffentliche README in Revision 8b45003849e830bed2ff341a9f027b017d932c1f wurde am 2026-08-16 geprüft. Der Checkout des Begleit-Repositories ist in diesem Workspace nicht vorhanden, daher konnte ich die CLI hier nicht ausführen. Die folgenden Befehle sind illustrativ, bis du sie aus diesem gepinnten Checkout ausführst; außerdem benötigt der Benchmark-Plan noch die Zielhardware für das Model Serving.

Übernimm nicht den FP8-Rezept-Output aus dieser gepinnten Revision. Der Befehl recipe --algorithm fp8-dynamic erzeugt ein intern inkonsistentes Modell und einen inkonsistenten Output-Pfad. Der Befehl bleibt hier zunächst ausgelassen, bis das Begleit-Repository repariert ist.

Klone das Repository und prüfe die unterstützten Algorithmen:

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

Beginne mit Planung und 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

Erzeuge anschließend ein Rezept und führe einen Preview der Quantisierung aus, bevor du GPU-Zeit investierst:

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

Für Serving- und Benchmark-Planung:

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

Vergleiche schließlich die Base- und die komprimierten Modelle anhand expliziter Schwellenwerte:

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

Führe die Arbeit in dieser Reihenfolge aus: Ziel planen, Speicherbedarf schätzen, das Rezept per Dry Run prüfen, Serving benchmarken und anschließend die Qualität anhand der Schwellenwerte vergleichen. Diese Reihenfolge entspricht der in diesem Artikel beschriebenen Trennung zwischen Memory Sizing, Runtime-Benchmarking und Quality Evaluation.

10. Diffusion Models benötigen einen separaten Pfad

Diffusion- und Diffusion-Transformer-Pipelines zeigen ein anderes Activation-Verhalten als autoregressive LLMs. SVDQuant behandelt die Diffusion-Quantization als separates Problem mit Activation-Outliers.

Autoregressive LLMs generieren jeweils einen Token. Diffusion-Modelle führen wiederholte Denoising-Schritte aus, und ihre Activation-Distributionen verschieben sich während dieses Prozesses. Ein standardmäßiger 4-Bit-LLM-Quantization-Pass kann zwar den Speicherbedarf eines Diffusion-Modells reduzieren, zugleich aber starke visuelle Artefakte verursachen. Diffusion-spezifische Methoden wie SVDQuant / Nunchaku und die NVIDIA ModelOpt Diffusion-Quantization adressieren dieses abweichende Activation-Muster.

Verwenden Sie die folgenden Punkte als konservative Heuristiken, nicht als universelle Defaults. Pipeline, Komponente, Model und Runtime benötigen jeweils separate Tests:

1. Lassen Sie den VAE für den ersten Vergleich in 16 Bit. Diese konservative Heuristik reduziert eine mögliche Ursache für Bildartefakte. Testen Sie niedrigere Precision nur, wenn die Methode und die Ziel-Pipeline sie validieren.
2. Testen Sie zuerst das DiT- oder U-Net-Backbone, da es häufig den größten Parameteranteil enthält. Dies ist eine Heuristik; überprüfen Sie daher für die Ziel-Pipeline Memory, Latency und Bildqualität. Diffusion-Quantization-Methoden verfolgen denselben komponentenweisen Ansatz.
3. Behandeln Sie Text-Encoder separat. Die Quantization von T5-XXL oder CLIP kann in einer bestimmten Pipeline die Prompt-Ausrichtung oder das Text-Rendering beeinflussen. Evaluieren Sie sie daher unabhängig, statt ein generisches Transformer-Verhalten anzunehmen.
4. Verwenden Sie Diffusion-aware Methoden wie SVDQuant, wenn Activation-Outliers das Hauptproblem sind.
5. Evaluieren Sie mit Bildern, nicht mit Text-Metriken. Prüfen Sie Prompt-Adherence, Text-Rendering, Hauttöne, Farbbalance, feine Details, Latency und VRAM.

Wenn der Evaluationsdatensatz nur einfache oder häufige Prompts enthält, übersehen Sie Fehler in Edge Cases. Nehmen Sie schwierige Fälle auf: kleinen Text, Hände, wiederholte Objekte, strukturierte Layouts und Prompts mit negativen Constraints, da sich Fehler der Diffusion-Quantization visuell zeigen und nicht in der Perplexity von Language Models.

11. Production-Defaults

Für das Enterprise-LLM-Serving sollten Sie mit einer BF16-Baseline in genau dem Serving-Engine starten, den Sie einsetzen möchten. Wenn Throughput das Ziel ist und die Hardware ihn unterstützt, testen Sie FP8 W8A8. Wenn das Model nicht in den verfügbaren Speicher passt, testen Sie AWQ oder GPTQ W4A16 mit Marlin-Class-Kernels. Wenn Long Context oder Concurrency das Problem ist, testen Sie die FP8-KV-Cache-Quantization. Wenn wiederholte Prefixes das Problem sind, aktivieren Sie zusätzlich Prefix Caching. Bringen Sie die komprimierte Version erst dann in Production, wenn sowohl die Quality- als auch die Serving-Benchmarks bestanden sind.

Für lokale und Edge-Inference sollten Sie mit einer GGUF-Datei mit Q4_K_M oder Q5_K_M beginnen. Wechseln Sie zu einem Q8_0-GGUF, wenn der Speicher es erlaubt und Quality wichtiger als der Footprint ist. Unter 4 Bit zu gehen, ist ein letzter Ausweg und kein Default.

Für Fine-Tuning verwenden Sie NF4 mit QLoRA, um Adapter kostengünstig zu trainieren. Evaluieren Sie den Adapter in der Anwendung, bevor Sie ihn mergen. Nach dem Mergen exportieren Sie ihn in das Serving-Artefakt, das Sie tatsächlich benötigen: eine llama.cpp-kompatible GGUF-Datei, einen AWQ/GPTQ/compressed-tensors-Checkpoint, einen FP8-Serving-Checkpoint oder BF16.

Für Diffusion sollten Sie mit diesen konservativen Heuristiken beginnen und jede Kombination aus Pipeline, Model und Runtime visuell testen. Die Text-Perplexity zeigt nicht, ob eine Bild-Pipeline fehlerhaft ist. Verwenden Sie daher Diffusion-spezifische Nachweise wie SVDQuant sowie eine visuelle Evaluation.

Referenzen

• 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-Dokumentation: vLLM project, Quantization. Docs.
• vLLM-Dokumentation zum quantisierten KV-Cache: vLLM project, Quantized KV Cache. Docs.
• vLLM-Benchmark-Dokumentation: vLLM project, vllm bench serve. Docs.
• LLM-Compressor-Dokumentation: 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: Lokaler Model Runtime von Ollama. Website.
• LM Studio: Lokaler AI Runtime von LM Studio. Website.
• Status von AutoGPTQ: AutoGPTQ-Repository, im April 2025 archiviert. GitHub.
• Status von AutoAWQ: AutoAWQ-Repository, im Mai 2025 archiviert und deprecated. 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 und llama.cpp. GGUF, llama.cpp.
• Hugging Face GGUF Docs: Hugging Face, GGUF. Docs.
• Reference Repository: slavadubrov/model-compression-demo.