FP4 auf Blackwell: Was NVFP4 für lokale KI wirklich ändert

Mit Blackwell hat NVIDIA nicht einfach einen schnelleren FP8-Stack ausgeliefert. Die Architektur bringt native Hardware-Unterstützung für NVFP4, ein 4-Bit-Floating-Point-Format mit einem Skalierungsregime, das sich grundlegend von dem unterscheidet, was bisher unter "FP4", "GPTQ-INT4" oder "Q4_K_M" lief. Wer nur die Zahl "4 Bit" sieht und gedanklich die Verbindung zur alten GGUF-Welt zieht, denkt am falschen Ende.

Die These, die sich aus NVIDIAs technischer Dokumentation, frühen Deployment-Daten und akademischer Sensitivitätsforschung ergibt: Blackwell verschiebt die Quantisierungsdebatte nicht von "gut" zu "besser", sondern von einem FP8-zentrierten Regime hin zu einem neuen 4-Bit-Feld, das höhere Kompression mit kalibrierten Accuracy-Erwartungen verbindet. Aber nur, wenn Betreiber verstehen, warum das Format funktioniert und wo es versagt.

Wer die Grundlagen von Quantisierungsformaten, Flips und KL-Divergenz noch nicht kennt, liest zuerst das Grundlagenstück zu LLM-Inferenz und Quantisierung. Dieser Artikel ist der zweite Teil dieses Quantisierungsclusters und fokussiert auf die konkrete Blackwell/NVFP4-Entwicklung.

Was NVFP4 von früheren 4-Bit-Formaten unterscheidet

Das E2M1-Layout von FP4 ist nicht neu: 1 Vorzeichenbit, 2 Exponent-Bits, 1 Mantissa-Bit. Dieses Layout existiert seit Jahren in der Forschungsliteratur. Der entscheidende Unterschied liegt im Skalierungsregime, und dieser Unterschied erklärt, warum frühere FP4-Versuche routinemäßig scheiterten.

Ältere FP4-Implementierungen und MXFP4 (definiert in der OCP-Microscaling-Spezifikation, einem offenen Industriestandard unter dem Open Compute Project, an dem AMD, Arm, Intel, Meta, Microsoft, NVIDIA und Qualcomm beteiligt sind) nutzen E8M0-Skalierung: Der Skalierungsfaktor wird auf die nächste Zweierpotenz gerundet. Das hält die Hardware-Implementierung einfach, vergrößert aber systematisch den Quantisierungsfehler, weil reale Gewichtsverteilungen selten genau auf eine 2^n-Grenze fallen. MXFP4 arbeitet dabei mit 32 Werten pro Block. Der Rounding-Fehler ist nicht willkürlich verteilt, sondern akkumuliert sich an den Stellen, wo die Verteilung gerade zwischen zwei Zweierpotenzgrenzen liegt.

NVFP4 ersetzt diese Power-of-Two-Skalierung durch E4M3-FP8-Scaling. Statt zur nächsten Zweierpotenz zu springen, sucht der Skalierungsalgorithmus den Faktor, der den mittleren quadratischen Fehler über alle 16 Werte eines Blocks minimiert. Pro Block aus 16 Werten gibt es einen gemeinsamen FP8-Skalierungsfaktor; dazu kommt eine zweite Ebene mit einem FP32-Skalierungsfaktor pro Tensor. Diese zweistufige Hierarchie ist rechnerisch aufwändiger als E8M0, aber Blackwells 5th-Gen-Tensor-Cores implementieren sie nativ, inklusive dynamischer Skalierung und 4-Bit-Matrixoperationen auf Chip-Ebene.

Das Ergebnis in der Speicherbilanz: Laut NVIDIA bis zu 4x weniger Speicher als FP16. Realistischer einzuordnen sind etwa 3,5x gegenüber FP16 und rund 1,6x gegenüber FP8 für typische LLM-Gewichtsmatrizen, weil die Skalierungsfaktoren eigenen Speicher beanspruchen. Für Betreiber mit GB10-basierten Systemen wie dem DGX Spark, dessen strategischen Wert für lokale Workloads ich an anderer Stelle beschrieben habe, bedeutet das: Modelle, die bisher auf die Speichergrenze stießen, rücken in erreichbares VRAM-Territorium.

DeepSeek-R1-0528: Das erste belastbare Praxisbeispiel

NVIDIA hat DeepSeek-R1-0528 als NVFP4-Checkpoint auf HuggingFace veröffentlicht und dabei Accuracy-Daten über sieben Benchmarks mitgeliefert. Das Gesamtbild: PTQ (Post-Training Quantization) von FP8 auf NVFP4 erzeugt bei diesem Modell minimale Accuracy-Differenzen, typischerweise weniger als einen Prozentpunkt.

Die Einzelzahlen verdienen methodische Einordnung. Der aktuelle NVFP4-v2-Checkpoint zeigt auf MMLU-Pro 84 gegenüber FP8s 85, auf GPQA Diamond 80 zu 81, auf AIME 2024 88 zu 89. Auf MATH-500 liegen beide bei 98. Auf SCICODE liegt NVFP4 mit 44 über FP8s 40, was mit hoher Wahrscheinlichkeit Stichprobenvarianz abbildet, nicht eine generelle Überlegenheit bei diesem Task. Das ist nicht identisch mit NVIDIAs früherer Blog-Zahl, in der der erste NVFP4-Checkpoint auf AIME 2024 noch über FP8 lag; der v2-Checkpoint quantisiert zusätzlich das wo-Modul in den Attention-Layern und gibt dort minimal nach. Wer aus einzelnen Benchmark-Positionen eine Aussage über NVFP4 als grundsätzlich besser oder schlechter als FP8 ableitet, zieht den falschen Schluss. Die Zahlen zeigen, was dieser Kalibrierungspfad bei diesem Modell auf diesen Tasks erzeugt, und das ist per se ein schmales Fenster.

Was die Daten dagegen belegen: Bei einem 671-Milliarden-Parameter-MoE-Modell ist NVFP4-PTQ kein automatisches Qualitätsproblem. Der Unterschied liegt im Skalierungsregime, und genau das ist der belastbare Befund aus dem DeepSeek-Experiment.

Deployment: TensorRT-LLM, vLLM und SGLang

Für die operative Frage "Wie komme ich an NVFP4-Inferenz?" gibt es aktuell drei Pfade, die unterschiedliche Kompromisse mitbringen.

TensorRT-LLM ist NVIDIAs eigener Inference-Stack mit nativer NVFP4-Unterstützung und direkter Blackwell-Optimierung. Ab Version 0.17 ist NVFP4 für B200 und weitere Blackwell-GPUs nativ unterstützt; der Stack bietet die tiefste Integration mit den Tensor-Core-spezifischen Optimierungen. vLLM hat frühe NVFP4-Unterstützung eingeführt, llm-compressor aus dem vLLM-Ökosystem bietet den vollständigen Quantisierungspfad mit anschließendem Serving über vLLM. SGLang hat NVFP4-Unterstützung für Blackwell-Hardware, einschließlich DGX Spark und Jetson Thor, mit dem NVIDIA-Release v26.05 (Mai 2026) ausgeliefert; die Stabilität variiert je nach Modellkonfiguration. Damit gibt es neben NVIDIAs Stack mehrere offene Serving-Pfade.

Der standardisierte HuggingFace-Checkpoint-Export macht NVFP4-Modelle portabler als ältere Quantisierungsformate. Ein NVFP4-Checkpoint läuft mit jedem Framework, das das Format unterstützt, ohne Neuquantisierung auf dem Zielsystem. Das reduziert Betriebsaufwand erheblich, wenn sich der Inference-Stack ändert, und ist ein konkreter Vorteil gegenüber proprietären TensorRT-Binaries, die an eine spezifische Hardware-Generation und Stack-Version gebunden sind.

Für Teams, die llm-compressor nutzen, gilt ein praktischer Hinweis: Die Kalibrierungsdaten-Wahl ist nicht trivial. Wer mit einem generischen 512-Sample-Corpus kalibriert und dann Long-Context-Reasoning evaluiert, misst zwei verschiedene Dinge. Der Quantisierungspfad muss das tatsächliche Deployment-Szenario widerspiegeln, weil die Sensitivitätsstruktur des Modells von der Eingabeverteilung abhängt.

Accuracy ist nicht gleich Accuracy: Layer-Sensitivität unter NVFP4

Eine der wichtigsten veröffentlichten Analysen zum Thema in der ersten Jahreshälfte 2026 ist die Layer-Sensitivitätsstudie von Cim et al. an Qwen2.5-Modellen zwischen 0,5B und 14B Parametern. Die Kernbefunde zeigen ein klares Muster, das sich für NVFP4 und MXFP4 unterschiedlich ausprägt und operativ direkte Konsequenzen hat.

MLP-up- und down-projection-Layer sind konsistent am empfindlichsten gegenüber FP4-Quantisierung. Gate-Projektionen reagieren moderat. Attention-Projektionen sind deutlich toleranter. Wer alle Layer gleichbehandelt und mit einem einheitlichen FP4-Schema quantisiert, zwingt die empfindlichsten Gewichte in denselben numerischen Raum wie die tolerantesten, ohne das notwendigerweise in Standardbenchmarks zu sehen. Die Akkumulation kleiner Fehler an MLP-Projektionen lässt sich durch Aggregate-Accuracy-Metriken oft nicht aufspüren, tritt aber bei längeren Kontexten und strukturiert-sprachlichen Aufgaben hervor.

Ein zweiter Befund ist operativ besonders relevant: Sensitivität lokalisiert sich nicht automatisch in den letzten Schichten. Frühe Modellblöcke können unter MXFP4 sehr sensitiv sein, auch wenn spätere Schichten tolerant bleiben. Das bricht die verbreitete Intuition "die letzten Layer sind kritisch" auf und erfordert systematisches Layer-Profiling statt Faustregeln. Wer nur die letzten paar Blöcke in höherer Präzision hält und den Rest uniform in FP4 quantisiert, kann dabei genau die empfindlichsten frühen Schichten übersehen.

Für praktische NVFP4-Deployments bedeutet das, dass Evaluierung aufgabenspezifisch sein muss. AIME-Reasoning-Benchmarks erfassen nicht dieselben Failure-Modi wie Long-Context-Summarization oder Mehrsprachigkeit. Nicht-englische Sprachgenerierung ist in fast keiner der aktuell veröffentlichten NVFP4-Evaluierungen abgedeckt, obwohl sie für viele Produktionsszenarien relevanter ist als englisches mathematisches Reasoning.

Egiazarian et al. liefern den zweiten wichtigen methodischen Befund: FP4 ist kein automatisches Upgrade über INT4. Die kleine Group-Size von NVFP4 neutralisiert traditionelle Outlier-Mitigation-Methoden, die bei INT4 funktionieren. Die Power-of-Two-Skalierung von MXFP4 degradiert Accuracy stark. Erst format-spezialisierte Methoden wie MR-GPTQ, Micro-Rotated-GPTQ mit blockweisen Hadamard-Transformationen, können 98-99 Prozent der FP16-Baseline-Accuracy zurückgewinnen und bringen dabei bis zu 2,2x End-to-End-Speedup auf NVIDIA B200 sowie 4x auf RTX 5090. Das zeigt, dass der technische Vorteil von NVFP4 nicht allein aus dem Format kommt, sondern aus der Kombination von Format, Skalierungsregime und Quantisierungsmethode. Das NVFP4-Versprechen gilt nicht pauschal, sondern unter der Bedingung, dass der Quantisierungsprozess das Format auch vollständig ausschöpft.

Antipatterns & Systemische Risiken

Aus Benchmarks, Sensitivitätsforschung und MR-GPTQ-Befunden ergibt sich eine Liste typischer Fehlmuster für frühe NVFP4-Deployments.

Score-Benchmark als Deployment-Freigabe. Ein Reasoning-Benchmark wie AIME zeigt, ob das Modell unter eng definierten Bedingungen stabil bleibt. Er zeigt nicht, wie es sich bei 64k-Token-Kontext, mehrsprachiger Eingabe oder stark strukturiertem Output verhält. NVFP4-Deployments, die nur auf zwei oder drei Standardbenchmarks validieren, haben eine methodische Lücke, die im Produktionsbetrieb sichtbar wird, spätestens wenn der Use Case von der Benchmark-Domäne abweicht.

Einheitliches FP4 über alle Layer. Die Layer-Sensitivitätsbefunde sind keine akademische Fußnote. MLP-up/down-Projektionen reagieren fundamental anders als Attention-Layer. Wer alle Gewichte uniform quantisiert, akzeptiert unnötige Accuracy-Verluste an den kritischsten Punkten, ohne das in Standardbenchmarks zu sehen.

Kalibrierungsdaten, die nicht zum Use Case passen. Wer auf generischem Web-Corpus kalibriert und dann auf Domänen-Tasks deployt, schätzt die Quantisierungsfehlerstruktur falsch ein. Die Sensitivitätsverteilung eines Modells ist nicht universell, sondern hängt von der Eingabeverteilung ab, die während der Kalibrierung gesehen wurde.

NVFP4 mit INT4 oder altem FP4 verwechseln. Die Bit-Breiten klingen gleich, die Formate sind es nicht. Wer NVFP4-Accuracy-Zahlen auf ältere FP4-Erfahrungen projiziert oder umgekehrt, arbeitet mit falschen Priors und unter- oder überschätzt das Risiko systematisch. Die Skalierungsarchitektur macht den entscheidenden Unterschied.

Fremde Checkpoints ohne Audit deployen. Mit wachsendem NVFP4-Checkpoint-Angebot auf HuggingFace steigt die Versuchung, vorkalibrierte Weights direkt zu deployen. Wer das tut, trägt die Produktionsverantwortung für Kalibrierungsentscheidungen eines Dritten. Kalibrierungskorpus, Layer-Sensitivitätsprofil und Mixed-Precision-Konfiguration sind im Checkpoint nicht transparent, im Produktionsbetrieb aber relevant.

Fehlende Fallback-Strategie für sensible Layer. Mixed-Precision, also kritische Layer in FP8 oder BF16 bei restlichem NVFP4, ist technisch machbar und methodisch sinnvoll. Frameworks unterstützen das; es erfordert aber explizite Konfiguration und eigene Evaluierung. Wer das nicht von Anfang an einplant, lässt eine der wichtigsten Risikominderungsoptionen liegen.

Fazit

NVFP4 verändert die Kalkulation für lokale Inferenz auf Blackwell-Hardware konkret: weniger Speicher bei beherrschbarem Accuracy-Verlust für große Modelle, nativer Hardware-Support in den Tensor-Cores, standardisierter HuggingFace-Export, funktionsfähige Deployment-Toolchain über TensorRT-LLM, vLLM und SGLang. Das sind messbare Verbesserungen gegenüber dem FP8-Status-quo.

Die schwächste Annahme in den aktuellen Evaluierungen ist die Modell- und Task-Abdeckung. Nahezu alle belastbaren Zahlen stammen aus sehr großen MoE-Modellen wie DeepSeek-R1 (671 Milliarden Parameter) oder aus dichten Qwen2.5-Varianten bis 14B. Mittelgroße dichte Decoder-Architekturen zwischen 30B und 70B sind in der veröffentlichten Literatur kaum evaluiert. Die Layer-Sensitivitätsmuster können dort anders ausfallen als bei MoE-Architekturen mit selektiver Experten-Aktivierung.

Der erste Second-Order-Effekt: Wenn NVFP4-PTQ für große Modelle so stabil ist wie die frühen Zahlen andeuten, verschiebt sich der Wettbewerb von der Modellgröße hin zur Quantisierungsqualität. Wer dasselbe Basismodell besser quantisiert und evaluiert, gewinnt Latenz, Speicher und Durchsatz gleichzeitig. Das ist keine Hardware-Frage mehr, das ist eine operative Strategie.

Der zweite, weniger offensichtliche Effekt betrifft die Verteilungsökonomie. Mit wachsendem Angebot an vorkonfigurierten NVFP4-Checkpoints auf HuggingFace entsteht eine neue Schicht zwischen Modellentwicklung und Deployment: Wer externe Checkpoints einsetzt, delegiert Kalibrierungsentscheidungen an Dritte. Das ist bequem, solange Kalibrierungskorpus, Layer-Profil und Eval-Tasks zum eigenen Szenario passen. Oft ist genau das nicht transparent. Die Fähigkeit, solche Entscheidungen zu auditieren oder eigene Checkpoints zu produzieren, wird zum operativen Differenzierungsmerkmal.