LLM-Quantisierung: Bit-Layouts, Block-Skalen und die VRAM-Mathematik

Jede LLM-Deployment-Entscheidung — welche GPU, wie viele gleichzeitige Nutzer, ob das Modell überhaupt passt — beginnt mit einer Zahl: Bytes pro Gewicht. Quantisierung ist der Hebel mit der größten Wirkung, und es lohnt sich, sie auf Bit-Ebene zu verstehen, denn die Unterschiede zwischen den Formaten sind kein Marketing: Sie sind konkrete Bit-Layouts mit zählbarem Overhead und messbaren Genauigkeitskosten.

Dieser Guide geht tiefer als die meisten: Was die Bits in FP8/FP4 tatsächlich kodieren, wie sich Block-Skalen-Metadaten aufsummieren und wie jedes verbreitete Format (NVFP4, MXFP4, FP8, GPTQ, AWQ, GGUF-K-Quants) seine Bits verteilt. Jede Zahl hier stammt aus den Original-Papers, der OCP-Spezifikation oder der Hersteller-Dokumentation — und jede Größenberechnung nutzt dieselben Formeln wie der VRAM-Rechner dieser Website.

Die eine Formel, die zählt

Modellgewichte im Speicher:

Dabei ist $P$ die Parameteranzahl und $b_{\text{eff}}$ die effektiven Bits pro Gewicht — die Payload-Bits des Speicherformats plus sämtliche Skalen-/Zero-Point-Metadaten, dividiert durch die Gruppengröße. Der Unterschied zwischen „4-Bit"-Formaten liegt vollständig in $b_{\text{eff}}$: Naives 4-Bit sind 4,0 Bits, echte Formate liegen zwischen 4,125 und 4,85 Bits pro Gewicht. Beim Referenzmodell Qwen3-VL-32B (~33,4 Milliarden Parameter — 33.357.390.064 gemäß Hugging-Face-Safetensors-Zensus, siehe unseren VRAM-Deep-Dive) macht dieser Unterschied mehrere Gigabyte aus.

Verallgemeinerte Gruppen-Overhead — dieser eine Ausdruck erzeugt fast jede Effektiv-Bits-Zahl dieses Artikels:

$k$ = Elemente pro Gruppe/Block, $b$ = Payload-Bits pro Element, $s_{\text{scale}}$ und $s_{\text{zp}}$ = Bits für die Skale (und optional einen Zero-Point) der Gruppe. Eine 4-Bit-Payload mit einer FP16-Skale pro 128 Gewichten kostet $(128 \times 4 + 16)/128 = 4{,}125$ Bits pro Gewicht; mit zusätzlichem 16-Bit-Zero-Point sind es 4,25.

Wie eine Gleitkommazahl zu Bits wird

Eine binäre Gleitkommazahl besteht aus drei Feldern: Vorzeichen $s$, Exponent $e$, Mantisse $m$. Das IEEE-754-Muster, verallgemeinert:

Der Exponent speichert ein Zweierpotenz-Fenster, die Mantisse die Position innerhalb dieses Fensters. Normale Zahlen haben eine implizite führende 1 ($1.mmm$); bei $e = 0$ ist die Zahl subnormal ($0.mmm$), was den Bereich bis null mit fester Auflösung erweitert. Der Bias ist pro Format so gewählt, dass der Exponentenbereich nützlich zentriert ist.

Die 8- und 4-Bit-Formate des LLM-Inferenz sind alle dieselbe Struktur mit weniger Bits:

Zwei Asymmetrien in dieser Tabelle sind Absicht und stammen aus dem FP8-Format-Paper, das E4M3/E5M2 standardisiert hat (arXiv 2209.05433)¹:

• E4M3 hat keine Unendlichkeit und genau ein NaN-Muster. Die dadurch frei werdenden Kodierungen erweitern den nutzbaren Bereich auf $448 = 1{,}75 \times 2^8$. Es ist das Format für Gewichte/Aktivierungen: Transformer-Gewichtsverteilungen brauchen eher Mantissen-Präzision als Bereich.
• E5M2 folgt den IEEE-Konventionen (Unendlichkeit + NaN) und bietet damit viel mehr Bereich ($57.344 = 1{,}75 \times 2^{15}$) bei geringerer Präzision. Es ist das Format für Gradienten, deren Magnituden-Spreizung dominiert.

E2M1: Alle sechzehn Codes, schwarz auf weiß

Das 4-Bit-Element am Boden jedes FP4-Formats ist E2M1. Mit einem Mantissen-Bit und Bias 1 hat seine gesamte Dekodatabelle 16 Einträge — 8 Beträge, jeweils mit Vorzeichen:

Vorzeichenbit gesetzt → der jeweilige Negativwert. Das ist das gesamte darstellbare Universum von FP4: $\pm\{0,\ 0{,}5,\ 1,\ 1{,}5,\ 2,\ 3,\ 4,\ 6\}$ — sechzehn Codes und – da +0 und −0 denselben Wert kodieren – fünfzehn unterschiedliche Werte, genau. Rohes E2M1 ist für Transformer-Gewichte viel zu grob (deshalb ist ein 4-Bit-Format ohne Skalierung unbrauchbar); das gesamte Designproblem der Low-Bit-Formate besteht darin, diese sechzehn Stufen Block für Block so wiederzuverwenden, dass sie jede Gewichtsnachbarschaft gut abdecken. Alles Weitere in diesem Artikel ist dieser Trick — bei unterschiedlichen Granularitäten.

Die Granularitäts-Leiter

Der Quantisierungsfehler wird von Outliern dominiert: Ein einziges großes Gewicht in einer Gruppe erzwingt eine große Skale und verschwendet Auflösung für alles Kleinere. Die historische Lösung sind immer feinere Skalen:

1. Pro Tensor — eine Skale für alle Gewichte. Am günstigsten ($\approx 0$ Overhead) und am ungenauesten. Klassische FP8-Inferenz funktioniert so: eine einzige FP32-Skale pro Tensor, in Software angewendet.¹
2. Pro Kanal — eine Skale pro Ausgabezeile jeder Gewichtsmatrix. Weiterhin fast kostenlos, deutlich besser. Standard-Granularität von GPTQ und AWQ.
3. Pro Gruppe (k=128) — eine Skale pro 128 Gewichten. Die „kleine Gruppen"-Einstellung von GPTQ/AWQ; das AWQ-Paper stellt fest, dass Round-to-Nearest bei Gruppe 128 mit kluger Skalierung bereits „ziemlich stark" ist (arXiv 2306.00978).²
4. Pro Block, Zweierpotenz-Skale (k=32, E8M0) — der OCP-MX-Standard: 32 E2M1-Elemente teilen sich einen 8-Bit-Zweierpotenz-Exponenten (OCP MX v1.0-Spezifikation; die gemeinsame Skale ist ein reines $2^n$, die Dequantisierung ist damit ein Exponenten-Addieren).³
5. Pro Block, FP8-Skale + zweite Ebene (k=16, E4M3 + FP32) — NVFP4, das native Format des NVIDIA Blackwell, weiter unten im Detail.

Jede Sprosse kostet Skalen-Bits — das ist die $b_{\text{eff}}$-Arithmetik aus dem ersten Abschnitt — und jede Sprosse fasst Outlier enger. Der Sprung von Sprosse 1 zu Sprosse 5 ist ein rund 100× feineres Skalen-Maschenwerk für etwa 0,5 Bits pro Gewicht Metadaten.

NVFP4 gegen MXFP4: Dieselbe Payload, andere Maßstäbe

Zwei 4-Bit-Block-Floating-Formate laufen auf aktueller Hardware, und ihr Unterschied ist ein Lehrbuchstück über Skalen-Design. Beide speichern E2M1-Elemente; keiner rührt an den Payload-Bits. Nur der Maßstab unterscheidet sich:

Beide Layouts stammen direkt aus der NVIDIA-NVFP4-Einführung und der OCP-MX-Spezifikation.⁴³ NVFP4s zwei Änderungen greifen die beiden Fehlerquellen an:

• Halb so große Blöcke (16 statt 32): Ein Outlier verseucht halb so viele Nachbarn.
• Eine fraktionale Skale (E4M3 statt E8M0): Eine E8M0-Skale muss auf die nächste Zweierpotenz einrasten; ein Block mit Werten zwischen $2^n$ und $2^{n+1}$ verliert oben bis zur Hälfte seines darstellbaren Bereichs. Eine E4M3-Skale kann überall im FP8-Bereich landen. NVIDIA misst rund 88 % weniger Quantisierungsfehler für E4M3-Mikroblock-Skalierung gegenüber Zweierpotenz-Skalierung, und in einem direkten Pretraining-Vergleich brauchte MXFP4 rund 36 % mehr Tokens, um denselben Loss wie NVFP4 zu erreichen.⁵

Der Preis des feineren Maßstabs ist zählbar: 4,50 statt 4,25 Bits pro Element plus eine FP32 pro Tensor (bei Skala vernachlässigbar). Und weil die E4M3-Skale einen schmaleren Bereich hat als E8M0, ergänzt NVFP4 die FP32-Zweit-Ebene pro Tensor, um ganze Tensoren zu renormalisieren, sodass jede Block-Skale gut konditioniert bleibt — globaler Bereich oben, lokaler Sitz pro Block.

Genauigkeit, aus NVIDIAs eigener PTQ-Studie zu DeepSeek-R1-0528 (konvertiert FP8 → NVFP4): innerhalb von 1 % gegenüber FP8 über sieben Sprachmodellierungs-Evaluationen, wobei AIME 2024 sogar 2 Punkte höher liegt (89 → 91); MMLU-Pro 85 → 84, GPQA 81 → 80.⁴⁵ Der Punkt — ein 4-Bit-Footprint, der sich für die meisten Serving-Zwecke wie ein 8-Bit-Modell verhält:

was exakt NVIDIAs eigene Angabe ist (~3,5× und ~1,8×).⁴ Auf Blackwell-Tensor-Cores liegt der dense FP4-Durchsatz beim Doppelten der FP8-Rate — dieselbe generationale Verdopplung, die FP8 auf Hopper gegenüber FP16 geleistet hat.

Gewichtsnur-Integer-Formate: GPTQ und AWQ

GPU-Hardware vor Blackwell hat keinen FP16×INT4-Matrixpfad, deshalb sind 4-Bit-Integer-Formate Gewichtsnur-Formate (W4A16): Gewichte in 4 Bit gespeichert, im Fluge dequantisiert, Aktivierungen in FP16. Das GPTQ-Paper sagt ausdrücklich, dass seine Speedups vom geringeren Speicherverkehr stammen, nicht von billigerer Rechnung — es gibt auf Mainstream-Architekturen keine Mixed-Precision-Multiplikation (arXiv 2210.17323).⁶ Für die Decode-Phase der LLM-Inferenz ist genau das erwünscht: Die Tokenerzeugung eines Nutzers ist speicherbandbreitenbegrenzt (siehe unser Inferenz-Mathe-Guide), also ist ein 4× kleinerer Gewichtsstrom ein fast 4× schnellerer Tokenstrom — bis andere Decken greifen.

Die beiden Familien unterscheiden sich darin, wie sie runden:

• GPTQ (arXiv 2210.17323) quantisiert Gewichte spaltenweise und propagiert den Rundungsfehler jeder Spalte in die noch nicht quantisierten mit einer approximierten Korrektur zweiter Ordnung (Hessian-basiert). Es kompensiert Fehler, braucht einen Kalibrierungs-Datensatz und quantisiert Modelle der OPT-175B-Klasse in Stunden, nicht Tagen.⁶
• AWQ (arXiv 2306.00978, MLSys 2024 Best Paper) beobachtet, dass 0,1–1 % der Gewichtskanäle salient sind — erkennbar an der Aktivierungsverteilung, nicht an den Gewichten — und schützt sie, indem es eine Per-Kanal-Skalierung sucht, die die volle 4-Bit-Darstellung der salienten Kanäle genauer macht. Kein Backprop, keine Rekonstruktion: Es generalisiert über Domänen und Modalitäten, ohne den Kalibrierungssatz zu überfitten.²

Beide liefern typischerweise Gruppengröße 128 mit FP16-Skalen: $b_{\text{eff}} = (128 \times 4 + 16)/128 = 4{,}125$ Bits/Gewicht vor Zero-Points und Packing-Metadaten. Der interaktive Rechner modelliert diese Formatklasse pauschal mit 12 % Overhead-Faktor (int4/AWQ ×1,12), um über Implementierungen hinweg konservativ zu bleiben; rechnen Sie kritische Fälle mit der Formel oben selbst nach.

Eine Warnung von der untersten Ebene: Das Skalen-Layout — wie Skalen mit den gepackten Werten im Speicher verschränkt sind — variiert zwischen Exporten (block-interleaved, Skalen-nach-Werten, per-K, Tile-major) und ist eine wiederkehrende Quelle für Serving-Stack-Bugs, wenn ein Checkpoint von Werkzeug A von Runtime B geladen wird. Wenn ein 4-Bit-Modell Unsinn produziert, verdächtigen Sie das Skalen-Layout vor dem Modell.

GGUF-K-Quants: Die Byte-Layouts, verifiziert

llama.cpps K-Quants sind die am weitesten verbreiteten Gewichtsquantisierer der Welt, und sie dokumentieren ihre eigene Arithmetik. Der K-Quant-PR von 2023 definiert die Superblock-Struktur (QK_K = 256), und llama.cpps Quelle trägt static_asserts, die die Byte-Zahlen erzwingen; das sind die veröffentlichten Bits-pro-Gewicht-Kosten:⁷

Lesen Sie Q4_Ks Zeile wieder als die generische Formel: 2 Bytes d + 2 Bytes dmin + 12 Bytes gepackte 6-Bit-Skalen + $(256 \times 4)/8 = 128$ Bytes Nibbles = 144 Bytes pro 256 Gewichte — $144 \times 8 / 256 = 4{,}5$ Bits pro Gewicht, und zwar mit einer zweistufigen Skalen-Hierarchie (Superblock-FP16-Skale über 6-Bit-Blockskalen), damit feine Skalierung nicht eine volle FP16 pro 32 Gewichten kostet.

Die Suffixe _S/_M/_L sind eine Tensor-Politik, kein Format: Sie wählen, welche Tensoren über der Basisbreite gespeichert werden (Q4_K_M hält attention.v und die MLP-Down-Projektion auf höherer Präzision als Q4_K_S). Die veröffentlichten effektiven bpw variieren daher leicht pro Modell: Q4_K_M misst 4,84 bpw auf Llama-2-7B, 4,83 auf 13B, 4,80 auf 70B — die eigene Tabelle des llama.cpp-quantize-README.⁷ Die Qualitätsreihenfolge aus llama.cpps veröffentlichten Perplexity-Läufen (Llama-2-7B): Q8_0 bei 5,9070 gegenüber F16 5,9066 — praktisch ununterscheidbar; Q4_0-/Q4_K-Varianten liegen dazwischen; und der Community-Standard Q4_K_M kostet qualitativ rund 1 % Perplexity für ~30 % der FP16-Größe.

Die Formate Seite an Seite

Effektive Bits und was Sie dafür zahlen — mit $b_{\text{eff}}$ aus der Gruppen-Overhead-Formel (Integer-Formate bei typischer Gruppe 128; NVFP4 mit 4,50; GGUF mit veröffentlichten bpw):

Drei ehrliche Beobachtungen fallen aus der Tabelle ab:

1. „4-Bit" umfasst eine ~16-%-Größenspanne (17,7–20,6 GB) allein durch Skalen-Metadaten. Wenn ein quantisiertes Modell „nicht ganz passt", ist das Budget in den Metadaten verschwunden.
2. FP8 hat die High-End-Seite faktisch gewonnen. Flaggschiff-Open-Modelle erscheinen zuerst als FP8-Checkpoints (Qwen3-Next, DeepSeek), und E4M3 ist das Standard-Inferenzformat auf Hopper und Blackwell. 16→8 Bit halbiert den Footprint bei ≈ null Serving-Qualitätskosten.
3. Die 4-Bit-Formate sind heute qualitativ mit 8-Bit konkurrenzfähig. NVFP4s ≤-1-%-Delta ggü. FP8 und Q6_Ks nahezu kostenfreie Rechnung bedeuten: Das 4-5-Bit-Band liefert 3,2–3,8× mehr Modell pro GB als FP16 — wobei der Quantisierungsfehler heute von der Kalibrierungsqualität dominiert wird, nicht von der Bitzahl.

Welches Format sollen Sie betreiben?

Self-hosted, einzelner Nutzer oder kleine Batches (llama.cpp/LM Studio/Ollama): Starten Sie mit Q4_K_M. Rechnen Sie ein Upgrade mit $P \times b_{\text{eff}}/8$ gegen Ihren VRAM, nachdem Sie den KV-Cache reserviert haben (die KV-Mathematik des Break-Even-Rechners gilt unverändert). Wenn Code-/Mathe-Qualität zählt: Q6_K; für eine Referenzmessung: Q8_0.

vLLM/SGLang/TensorRT-LLM-Serving auf Hopper: FP8 (E4M3-Gewichte, Per-Tensor- oder Per-Block-Skalen je nach Runtime-Support). 4-Bit-Integer-Gewichte (AWQ/GPTQ), wenn der VRAM-Druck es verlangt — erwarten Sie einen kleinen, aber messbaren Qualitätsschritt.

Blackwell-Serving im Maßstab: NVFP4. Es ist das native Format der 4-Bit-Tensor-Cores der Hardware, das Ökosystem (vLLM/TRT-LLM Model Optimization) unterstützt es direkt, und die Genauigkeitssteuer ggü. FP8 liegt nach NVIDIAs Messungen bei ~1 %. MXFP4 bleibt die OCP-Standard-Option mit breiterer herstellerübergreifender Portabilität (AMDs MI-Serie unterstützt MX-Familien-Formate).

Was immer Sie wählen: Messen Sie. Veröffentlichen Sie Ihr eigenes Vorher/Nachher auf Ihrem Workload — die Perplexity-Deltas oben sind Llama-Familien-Messungen unter llama.cpp-Kalibrierung; Ankunftsverteilungen, Long-Context-Regimes und Tool-Calling-Muster verschieben sie. Die Formeln dieses Artikels geben Ihnen die Grenze; nur Ihr Benchmark sagt Ihnen, wo auf ihr Sie sich niederlassen sollten.

Weiterlesen

• LLM-VRAM-Bedarf: Ein mathematischer Deep-Dive — das vollständige Gewichts-+KV-Cache-Speichermodell, in das die Beispiele dieses Artikels einmünden.
• LLM-Inferenz-Mathematik: Von der Theorie zur Hardware — warum Decode speicherbegrenzt ist; deshalb ist $b_{\text{eff}}$ auch Ihr Durchsatzregler.
• Wie LLMs wirklich funktionieren — Tokenizer-, Attention- und Sampling-Hintergrund für die Formatentscheidungen oben.