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

FP8: die Kodierungen E4M3 und E5M2 und ihre Skalierungsfaktoren

Samt Skalierungsfaktoren belegt FP8 8 Bit je Gewicht, NVFP4 4,5 und MXFP4 4,25, INT4 AWQ oder GPTQ etwa 4,15 und eine GGUF-Datei in Q4_K_M etwa 4,9 Bit. Ada- und Hopper-GPUs wie die L40S und die H200 NVL rechnen FP8, aber nicht FP4; NVFP4 und MXFP4 rechnen erst die Tensor-Kerne ab Blackwell nativ, etwa auf den RTX-PRO-Blackwell-Karten und im DGX Spark. FP8 ist das einfachste der fünf Formate, und die OCP-Microscaling-Spezifikation führt zwei Kodierungen dafür auf: E4M3, dessen größter normalisierter Wert ±448 ist und das keine Werte für Unendlich kennt, und E5M2, das bis ±57.344 reicht. In diesen Namen zählt E die Exponentenbits und M die Mantissenbits. 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. Wir liefern für jedes dieser Formate eine passende Karte, von der L4 bis zum DGX Spark. Schildern Sie kurz Modell und Nutzerzahl, unser Team hilft Ihnen bei der Wahl von Format und Karte.

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. Nach unserer Rechnung fügen die Skalierungsfaktoren bei Blöcken von 128 × 128 mit FP32-Faktoren etwa 0,002 Bit je Gewicht hinzu, FP8 belegt also ein Byte je Gewicht, halb so viel wie BF16. Die 8-Bit-Faktoren von MXFP8 fügen 0,25 Bit hinzu. Laut seiner Model Card erreicht NVIDIAs Llama 3.3 70B in FP8 83,2 im Benchmark MMLU und 94,3 in GSM8K mit Chain of Thought; das BF16-Modell erreicht 83,3 und 95,3.

NVFP4 und MXFP4: Blockgröße und Format der 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. Die beiden Formate unterscheiden sich im Skalierungsfaktor, der mit jedem Block von Werten gespeichert wird.

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, 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. Anders als der Zweierpotenz-Faktor von MXFP4 kann ein E4M3-Faktor auch Werte zwischen zwei Zweierpotenzen annehmen. NVIDIA beziffert die Ersparnis auf „etwa 3,5-mal gegenüber FP16 und etwa 1,8-mal im Vergleich zu FP8“. Außerdem berichtet NVIDIA, 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; das BF16-Modell erreicht 83,3 und 95,3.

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 „in der gesamten Arbeit“ 128 Gewichte je Skalierungsfaktor. Das GPTQ-Paper, dessen Hauptergebnisse je Zeile skalieren, beziffert die Kosten eines Skalierungsfaktors je 128 Gewichte 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 welche Variante die bessere Wahl ist. 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; das Pre-Release 1.4.0rc1 folgte am 21. Oktober 2026). 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 seine 68,45 Milliarden NVFP4-Gewichte 38,5 GB: 34,2 GB für die 4-Bit-Werte und 4,3 GB für die FP8-Skalierungsfaktoren. Seine 2,1 Milliarden BF16-Parameter kommen mit 4,2 GB hinzu. Zusammen sind das 42,7 GB, die veröffentlichte Größe, oder insgesamt etwa 0,61 Byte je Parameter. Dieselbe Rechnung geht für Qwen3-32B-AWQ auf: 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; TensorRT-LLM 1.4.0rc1 folgte am 21. Oktober 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.

Die Tabelle zeigt zwei Grenzen. 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 beginnt mit Blackwell: 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.“ Auf diesen GPUs spart der Checkpoint weiterhin Speicher, die Arithmetik läuft aber in 16 Bit, und NVIDIAs eigene NVFP4-Model-Card nennt Blackwell als einzige unterstützte Architektur.

Von den GPUs, die wir liefern, rechnen die RTX-PRO-Blackwell-Karten und DGX Spark FP4 nativ; die H200 NVL, die L40S und die L4 rechnen FP8, aber nicht FP4. Nennen Sie uns den Checkpoint, den Sie einsetzen wollen, und wir bieten Ihnen eine Karte an, die ihn nativ ausführt.

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 nutzt den Speicher, der nach dem Laden der Gewichte übrig bleibt. 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. Nehmen Sie eine H200 NVL mit FP8-Gewichten und unsere Regel für Nutzer je Karte: 90 Prozent der 140,4 GiB, die der Treiber meldet, abzüglich 3 GiB je Karte für Aktivierungen und Laufzeit und abzüglich der Gewichte. Nach 67,7 GiB für die Gewichte bleiben 55,7 GiB für den Cache, die nach unserer Rechnung 22 solche Gespräche in BF16 und 44 in FP8 aufnehmen.

Dieselbe Rechnung stellen wir in einem kostenlosen Sizing-Gespräch für Ihren Fall an und leiten daraus eine Serverkonfiguration ab, die Sie mit Cloud-GPUs vergleichen können. Schreiben Sie uns, welches Modell Sie für wie viele gleichzeitige Nutzer betreiben wollen.

vLLM schaltet den FP8-KV-Cache 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. vLLM 0.32.0 vom 18. Oktober 2026 hält fest, dass sein NVFP4-KV-Cache nun auf SM8x und SM12x läuft, also auch auf den RTX-PRO-Blackwell-Karten. Erste Genauigkeitswerte hat LMSYS am 16. September 2026 für SGLang veröffentlicht, wo die Unterstützung als experimentell gekennzeichnet ist: Bei Qwen3.8-27B lag ein NVFP4-Cache auf GSM8K 0,31 Prozentpunkte und auf GPQA-Diamond 1,01 Prozentpunkte unter einem FP8-Cache und löste 76,20 gegenüber 77,80 Prozent von SWE-bench Verified. Zwei Modelle ergeben keine allgemeine Regel; unsere Dimensionierung bleibt deshalb beim FP8-Cache, und Sie sollten den NVFP4-Cache mit Ihren Evaluierungsdaten prüfen, bevor Sie sich darauf verlassen. Unsere Seite zum NVFP4-KV-Cache auf der RTX PRO 6000 Server Edition nennt die Werte.

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

L4 und L40S (Ada). Verwenden Sie FP8 für jedes Modell, das 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 und 32B in FP8 auf der L40S; ein 70B-Modell in 4 Bit passt von den Gewichten her auf eine L40S, lässt aber kaum Speicher für den Cache.

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; wählen Sie diese Formate statt NVFP4-Checkpoints. gpt-oss läuft ebenfalls auf der H200 NVL. 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. Für Llama 3.3 70B mit FP8-Cache sind das nach unserer Regel für Nutzer je Karte 34 statt 12 Sitzungen mit 8K je RTX PRO 6000 oder 136 statt 48 auf einem Server mit vier RTX PRO 6000 Server Edition wie dem Inferenzknoten auf unserer Seite KI-Server.

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. In NVIDIAs eigenem Benchmark vom Oktober 2025 läuft gpt-oss-120b in MXFP4 über llama.cpp mit 55,37 Token pro Sekunde bei der Generierung, 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

Wir liefern die professionellen NVIDIA-GPUs aus dem Abschnitt oben: DGX Spark, die L4, die L40S und die H200 NVL, die RTX PRO 6000 in allen drei Editionen (Workstation, Max-Q und Server Edition) und die übrigen RTX-PRO-Blackwell-Workstation-Karten. Alles kommt mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Sie können die Karten allein bestellen oder eingebaut in einen Server oder eine Workstation, konfiguriert für das Modell und das Format, das Sie einsetzen wollen. Schicken Sie uns das Modell, und wir wählen die passende Karte dazu; Stückzahlen und Lieferzeit bestätigen wir schriftlich mit dem Angebot.

FAQ