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

Mit einer verschiebbaren Zahl anfangen: INT4 und NVFP4 visuell vergleichen und Rundung, Skalierung und Block-Overhead verstehen, bevor es unten ins Bit-Layout geht. 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 — Nutzdaten-Bits plus anteilige Skalen-/Zero-Point-Metadaten. Reale 4-Bit-Formate haben unterschiedliche effektive Breiten; Tensoren mit gemischter Präzision verändern den Checkpoint-Durchschnitt zusätzlich. Beim Referenzmodell Qwen3-VL-32B (~33,4 Milliarden Parameter — 33.357.390.064 gemäß Hugging-Face-Safetensors-Zensus, siehe unseren VRAM-Deep-Dive) können diese Unterschiede mehrere Gigabyte ausmachen.

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 einer Gewichtsmatrix. Eine mögliche Granularität der Gewichtsquantisierung mit geringem Metadatenaufwand.
3. Pro Gruppe (k=128) — eine Skale pro 128 Gewichten. Eine verbreitete Einstellung von GPTQ-/AWQ-Checkpoints; 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.cpp dokumentiert die Arithmetik seiner K-Quants. Der Quellcode definiert die Superblock-Struktur (QK_K = 256) und enthält static_asserts für die Byte-Zahlen; daraus folgen diese Kosten pro Gewicht:⁷

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 beschreiben eine Tensor-Politik: 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 pro Modell: Q4_K_M misst laut llama.cpp-Tabelle 4,84 bpw auf Llama-2-7B, 4,83 auf 13B und 4,80 auf 70B.⁷ Die Perplexity-Messungen des Repositorys gelten für die getesteten LLaMA-Checkpoints und belegen keine allgemeingültige Qualitätseinbuße für andere Modelle oder Aufgaben.

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. Die beispielhaften 4-Bit-Breiten ergeben für 33,4B Gewichte etwa 17,7–20,2 GB, vor unquantisierten Tensoren, KV-Cache und Runtime-Speicher. Der NVFP4-Eintrag im Site-Rechner verwendet 4,5 bpw; darin sind die FP8-Blockskalen bereits enthalten.
2. FP8 halbiert die reinen Nutzdaten gegenüber FP16/BF16; Skalen und unveränderte Tensoren fügen Bytes hinzu. Qualität hängt von Modell, Checkpoint und Aufgabe ab.
3. Die relative Genauigkeit von NVFP4, MXFP4, AWQ und GGUF muss am selben Modell mit denselben Evaluierungen gemessen werden. NVIDIAs veröffentlichte FP8-gegen-NVFP4-Ergebnisse beschreiben eine konkrete Konvertierungsstudie, keine allgemeine 1-%-Grenze.

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: Prüfen Sie NVFP4, wenn Checkpoint und Runtime es unterstützen. Es ist nativ für Blackwells FP4-Tensor-Cores. NVIDIA berichtete bei einer bestimmten DeepSeek-Konvertierung über eine ähnliche Genauigkeit wie FP8; messen Sie das für Ihre Aufgabe nach. MXFP4 ist ein OCP-Standard mit einem anderen 4,25-bpw-Blocklayout.

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

• Nemotron 3.5 Bolt: heterogenes LatentMoE und IQ2 — das 66-Byte-IQ2_XXS-Layout entschlüsseln und Mixed-Precision-Gewichte von hybriden Laufzeitzuständen trennen.
• 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.