FP8, NVFP4, MXFP4, INT4 und GGUF erklärt: Bits je Gewicht, Skalierungsfaktoren und welche GPU was rechnet

FP8: zwei Kodierungen und ein Skalierungsfaktor

Ein quantisiertes Format beantwortet drei Fragen: wie viele Bits ein Gewicht belegt, wenn seine Skalierungsfaktoren mitgezählt werden, welche GPUs direkt darin rechnen und was es an Genauigkeit kostet. FP8 ist der einfachste Fall. Die OCP-Microscaling-Spezifikation führt seine beiden Kodierungen auf: E4M3, dessen größter normalisierter Wert ±448 ist und das keine Werte für Unendlich kennt, und E5M2, das bis ±57.344 reicht. NVIDIAs Dokumentation zur Transformer Engine ordnet E4M3 den Gewichten und Aktivierungen zu und E5M2 den Gradienten; Inferenz-Checkpoints wie Metas Llama 3.1 405B FP8 speichern ihre quantisierten Gewichte als E4M3.

Acht Bit allein können den Wertebereich eines Tensors nicht abdecken, deshalb tragen FP8-Tensoren Skalierungsfaktoren: einen FP32-Faktor je Tensor wie im ursprünglichen FP8-Rezept der Transformer Engine oder feinere je Zeile oder je Block, etwa den Faktor als Zweierpotenz je 32 Werte bei MXFP8. DeepSeek-V3 skaliert Gewichte je Block von 128 × 128 und Aktivierungen je Kachel von 1 × 128, um „Ausreißer besser aufzufangen“; Qwens FP8-Version von Qwen3-235B nutzt laut ihrer config.json Gewichtsblöcke von 128 × 128. Die Skalierungsfaktoren kosten fast nichts, nach unserer Rechnung etwa 0,002 zusätzliche Bit je Gewicht bei Blöcken von 128 × 128 mit FP32-Faktoren, FP8 ist also ein Byte je Gewicht, die Hälfte von BF16; die 8-Bit-Faktoren von MXFP8 fügen 0,25 Bit hinzu. NVIDIAs Llama 3.3 70B in FP8 erreicht 83,2 in MMLU und 94,3 in GSM8K mit Chain of Thought, gegenüber 83,3 und 95,3 in BF16, laut seiner Model Card.

NVFP4 und MXFP4: dieselben 4-Bit-Werte, andere Skalierungsfaktoren

Beide Formate speichern jedes Gewicht als FP4 E2M1: ein Vorzeichen, zwei Exponentenbits und ein Mantissenbit, was genau 0; 0,5; 1; 1,5; 2; 3; 4 und 6 erlaubt, positiv oder negativ. Was sich unterscheidet, ist der Skalierungsfaktor.

MXFP4 stammt aus der OCP-Microscaling-Spezifikation v1.0 vom September 2023: Je 32 Werte teilen sich einen 8-Bit-Skalierungsfaktor in E8M0, eine Zweierpotenz. Das ergibt 4 + 8/32 = 4,25 Bit je Gewicht, den Wert, den OpenAIs Model Card für die MoE-Gewichte von gpt-oss nennt und mit dem das 117B-Modell laut der Model Card auf eine einzelne GPU mit 80 GB passt.

NVFP4 ist NVIDIAs Variante: Je 16 Werte teilen sich einen Skalierungsfaktor in FP8 E4M3, der anders als der Zweierpotenz-Faktor von MXFP4 auch Werte zwischen zwei Zweierpotenzen annehmen kann, und ein zweiter FP32-Faktor je Tensor hält die Blockfaktoren im darstellbaren Bereich. Das ergibt 4 + 8/16 = 4,5 Bit je Gewicht, wie NVIDIAs Technikblog schreibt; der Faktor je Tensor fügt einem Tensor aus Millionen von Gewichten nur 32 Bit hinzu. NVIDIA beziffert die Ersparnis auf „etwa 3,5-mal gegenüber FP16 und etwa 1,8-mal im Vergleich zu FP8“ und berichtet, dass DeepSeek-R1-0528 beim Wechsel von FP8 zu NVFP4 über sieben Benchmarks „1 Prozent oder weniger“ verlor, zum Beispiel von 85 auf 84 Prozent in MMLU-Pro. NVIDIAs Llama 3.3 70B in NVFP4 erreicht 81,1 in MMLU und 92,6 in GSM8K, gegenüber 83,3 und 95,3 in BF16.

INT4 mit AWQ oder GPTQ: 4-Bit-Gewichte, Rechnen in 16 Bit oder FP8

AWQ und GPTQ wandeln Gewichte in 4-Bit-Ganzzahlen um und speichern meist für je 128 Gewichte einen Skalierungsfaktor, oft mit einem Nullpunkt: Das AWQ-Paper verwendet diese Größe „in der gesamten Arbeit“, und das GPTQ-Paper, dessen Hauptergebnisse je Zeile skalieren, beziffert die Kosten dafür auf etwa 0,15 zusätzliche Bit, also rund 4,15 Bit je Gewicht. Beide quantisieren nur die Gewichte. Das AWQ-Paper erklärt: „Die Hardware bietet keine Multiplikationsbefehle zwischen INT4 und FP16“, daher entpacken seine Kernel die Ganzzahlen innerhalb der Matrixmultiplikation zu FP16: W4A16, 4-Bit-Gewichte und 16-Bit-Aktivierungen. W4A8 kombiniert 4-Bit-Gewichte mit FP8-Aktivierungen, und NVIDIAs Leitfaden zum Model Optimizer führt es für „Ada, Hopper und neuer“, die GPUs mit FP8-Tensor-Kernen. W8A8 bringt Gewichte und Aktivierungen auf 8 Bit, als FP8 oder INT8.

Derselbe Leitfaden sagt, wann sich was lohnt. Bei Batchgrößen bis vier ist Inferenz oft „speichergebunden“, und INT4, bei dem nur die Gewichte quantisiert sind (Weight-only), bringt den größeren Gewinn; für Serving mit 16 und mehr empfiehlt er, auch die Aktivierungen zu quantisieren, und schlägt vor, „vorrangig zuerst FP8 zu verwenden“. INT4 AWQ führt er für „Ampere und neuer“.

GGUF: die Blockformate von llama.cpp

GGUF ist ein Dateiformat, kein Zahlenformat: eine Datei, die die Tensoren und ihre Metadaten für llama.cpp und die Werkzeuge enthält, die dessen Dateien nutzen, etwa Ollama, mit den eigenen Blocktypen von llama.cpp darin. Q8_0 speichert 8-Bit-Werte mit einem Skalierungsfaktor je 32 Gewichte: 8,5 Bit je Gewicht bei Llama 3.1 8B in der Tabelle von llama.cpp. Q4_K packt 256 Gewichte in einen Superblock aus acht Blöcken zu je 32 Gewichten mit 6-Bit-Skalierungsfaktoren und -Minima, 4,5 Bit je Gewicht. Das beliebte Q4_K_M ist ein Dateityp, kein Blocktyp: Es hält mehr Tensoren in Q6_K, darunter einige der Value-Projektionen der Attention und der Down-Projektionen des Feed-Forward-Netzes, weshalb dieselbe Tabelle dafür 4,89 Bit je Gewicht angibt, gegenüber 4,67 für Q4_K_S.

Kein Tensor-Kern rechnet diese Formate als solche. Die Build-Dokumentation von llama.cpp sagt, dass seine eigenen Kernel für quantisierte Modelle „auf GPUs mit Unterstützung für int8-Tensor-Kerne“ der Standard sind, mit cuBLAS in FP16 als Alternative. vLLM lädt GGUF-Dateien, nennt seine Unterstützung aber „hochgradig experimentell und unzureichend optimiert“; beginnen Sie bei einem vLLM-Dienst für mehrere Nutzer mit FP8, NVFP4 oder AWQ.

Bits je Gewicht, Skalierungsfaktoren eingerechnet

NVIDIAs Technikblog zu NVFP4 (24. Juni 2025), „OCP Microscaling Formats v1.0“, NVIDIAs FP8-Einführung zur Transformer Engine, OpenAIs Model Card zu gpt-oss, die Paper zu AWQ (MLSys 2024) und GPTQ (ICLR 2023), die GGUF-Dokumentation von Hugging Face, das README zu llama-quantize von llama.cpp, die Quantisierungsmatrix von TensorRT-LLM (1.3.0rc28). Der INT4-Wert wendet die Schätzung von GPTQ auf einen Skalierungsfaktor je 128 Gewichte an; der FP8-Overhead ist unsere Rechnung.

Diese Website setzt NVFP4 mit etwa 0,56 Byte je Parameter an, und das ist der Wert je Gewicht: 4,5 Bit sind 0,5625 Byte. Ganze Checkpoints fallen höher aus, weil nicht alles quantisiert wird. NVIDIAs Llama 3.3 70B in NVFP4 quantisiert nur die linearen Schichten innerhalb der Transformer-Blöcke und hält die Embeddings und die Ausgabeschicht in BF16. Nach unserer Rechnung aus den Tensortypen des Checkpoints belegen 68,45 Milliarden NVFP4-Gewichte 38,5 GB, davon 34,2 GB 4-Bit-Werte und 4,3 GB FP8-Skalierungsfaktoren, und 2,1 Milliarden BF16-Parameter belegen 4,2 GB: zusammen 42,7 GB, die veröffentlichte Größe, oder insgesamt etwa 0,61 Byte je Parameter. Qwen3-32B-AWQ lässt sich genauso nachrechnen: 31,2 Milliarden 4-Bit-Gewichte mit etwa 4,15 Bit und 1,56 Milliarden 16-Bit-Parameter für Embedding und Ausgabe ergeben seine 19,3 GB. Unser VRAM-Leitfaden macht aus Gewichten wie diesen ein Speicherbudget.

Welche Tensor-Kerne welches Format rechnen

Quantisierungs-Support-Matrix von TensorRT-LLM, Dokumentation 1.3.0rc28, und NVIDIAs Liste der Compute Capabilities, beide abgerufen am 23. September 2026. Die FP8-Skalierungsverfahren und INT4-Modi sind die, die TensorRT-LLM auf der jeweiligen Architektur unterstützt, keine Grenzen der Tensor-Kerne. „In vLLM“ kennzeichnet die Weight-only-Marlin-Kernel von vLLM, die in der Kompatibilitätstabelle von vLLM für Ampere, Ada und Hopper geführt werden.

Zwei Grenzen sind entscheidend. FP8-Arithmetik beginnt bei Compute Capability 8.9: vLLM schreibt, dass „FP8-Berechnungen auf NVIDIA-GPUs mit Compute Capability >= 8.9 (Ada Lovelace, Hopper, Blackwell) unterstützt werden“, und führt FP8-Modelle auf Turing und Ampere „als Weight-only-W8A16“ aus. FP4-Arithmetik ist Blackwell vorbehalten: NVIDIAs Blog schreibt, dass die „Tensor-Kern-Architektur der fünften Generation NVFP4 implementiert“, und die Rezepte von TensorRT-LLM stellen fest, dass „NVFP4 nur auf NVIDIA Blackwell unterstützt wird“. vLLM lädt NVFP4-Checkpoints dennoch auf Ampere-, Ada- und Hopper-GPUs; seine Dokumentation sagt, Stand September 2026: „Auf GPUs ohne unterstützten nativen FP4-GEMM-Kernel weicht vLLM über Marlin auf eine Weight-only-Ausführung (W4A16) aus und protokolliert eine Warnung; das kann bei rechenintensiven Arbeitslasten den Durchsatz verringern.“ Die Speicherersparnis bleibt, die FP4-Arithmetik nicht, und NVIDIAs eigene NVFP4-Model-Card nennt Blackwell als einzige unterstützte Architektur.

FP8-KV-Cache: der halbe Cache je Token

Der KV-Cache hält Keys und Values für jedes Token jedes offenen Gesprächs und bekommt den Speicher, den die Gewichte übrig lassen. In FP8 statt BF16 gespeichert, belegt er halb so viel: bei Llama 3.3 70B 160 statt 320 KiB je Token oder 1,25 statt 2,5 GiB für ein Gespräch mit 8.192 Token. Auf einer H200 NVL mit FP8-Gewichten bleiben nach einer Planungsregel, 90 Prozent der 140,4 GiB, die der Treiber meldet, abzüglich 68 GiB Gewichte, 58,4 GiB für den Cache: 23 solche Gespräche in BF16 und 46 in FP8, nach unserer Rechnung.

vLLM schaltet ihn mit --kv-cache-dtype fp8 ein; ohne Kalibrierung sind seine Skalierungsfaktoren 1,0, und die Dokumentation empfiehlt für maximale Genauigkeit eine Kalibrierung auf einem Datensatz über llm-compressor. SGLang akzeptiert fp8_e4m3 oder fp8_e5m2, und NVIDIAs Llama 3.3 70B in NVFP4 deklariert in seiner hf_quant_config.json einen FP8-KV-Cache. TensorRT-LLM führt den FP8-KV-Cache für jede Architektur von Ampere bis Blackwell und einen kleineren NVFP4-KV-Cache nur für die B200- und B300-Klasse.

Was Sie auf L4, L40S, H200 NVL, RTX PRO und DGX Spark wählen

L4 und L40S (Ada). FP8 für alles, was passt: Es ist nativ, halbiert die Gewichte und kostet laut NVIDIAs Model Cards zu Llama 3.3 70B 0,1 Punkte in MMLU. Für 4 Bit nehmen Sie INT4 AWQ oder GPTQ, W4A16 für wenige Nutzer und W4A8, wenn die Batches wachsen; in vLLM lassen sich NVFP4-Checkpoints nur über dessen Weight-only-Fallback laden. Unser Vergleich von L4 und L40S dimensioniert die Modelle: 14B in FP8 auf der L4, 32B in FP8 oder 70B in 4 Bit auf der L40S.

H200 NVL (Hopper). FP8 ist der Standard, mit jedem FP8-Skalierungsverfahren, das TensorRT-LLM bietet, und INT4 AWQ oder GPTQ, wenn der Speicher knapp wird; NVFP4-Checkpoints sind der falsche Download. gpt-oss läuft: OpenAI gibt an, dass es auf eine einzelne GPU mit 80 GB wie die H100 passt, und in vLLM laufen seine MXFP4-Gewichte im Weight-only-Modus, wie die Tabelle oben zeigt. Die Kartenzahl je Modell steht in unserem Leitfaden zu großen Modellen auf der H200 NVL.

RTX PRO Blackwell (12.0). NVFP4 und MXFP4 sind die nativen 4-Bit-Formate und in TensorRT-LLM die einzigen: Seine Matrix führt für diese Karten kein INT4 AWQ oder GPTQ und FP8 nur je Tensor. NVFP4-Gewichte brauchen etwa 56 Prozent des Speichers von FP8, 4,5 statt 8 Bit, bei den Genauigkeitskosten, die die Model Cards oben zeigen.

DGX Spark (GB10, 12.1). Bei 273 GB/s Speicherbandbreite schlägt sich jedes pro Gewicht gesparte Byte in Token pro Sekunde nieder. NVIDIAs Playbooks quantisieren mit Model Optimizer auf NVFP4 und stellen die Modelle mit TensorRT-LLM oder vLLM bereit; NVIDIAs eigener Benchmark vom Oktober 2025 führt gpt-oss-120b in MXFP4 über llama.cpp mit 55,37 Token pro Sekunde bei der Generierung aus, mit einem Prompt von 2.048 Token bei Batchgröße 1. GGUF über llama.cpp oder Ollama ist der schnellste Einstieg für einen Nutzer; unser Artikel zur Dimensionierung des DGX Spark zeigt, was passt.

Was wir liefern

Eurokommerz liefert DGX Spark sowie die L4, die L40S, die H200 NVL und die RTX-PRO-Blackwell-Workstation-Karten EU-weit mit Herstellergarantie, die Karten einzeln oder in Servern und Workstations, die für das Modell und das Format konfiguriert sind, die Sie einsetzen wollen. Unser Sortiment professioneller GPUs ist der Ausgangspunkt; schicken Sie uns das Modell, und wir wählen die passende Karte dazu.

FAQ