H200 NVFP4 und MXFP4: FP4-Modelle auf H200 NVL, L40S und anderen GPUs ohne FP4-Tensor-Kerne ausführen

FP4-Unterstützung auf H200 NVL, L40S und RTX-Ada-Karten

Die H200 NVL rechnet nicht in FP4, ebenso wenig die L40S, die L4 oder die RTX-Ada-Workstation-Karten. Ihre Tensor-Kerne reichen bei Gleitkommaformaten bis FP8, und FP4-Tensor-Kerne kamen mit Blackwell. NVFP4- und MXFP4-Modelle laufen auf diesen GPUs dennoch, wo die Serving-Engine Weight-only-Kernel hat: vLLM und SGLang halten die Gewichte mit 4 Bit im GPU-Speicher und entpacken sie für 16-Bit-Arithmetik. Die Speicherersparnis bleibt, während der Rechengewinn von FP4 entfällt.

Unser Leitfaden zu FP8, NVFP4, MXFP4, INT4 und GGUF erklärt die Formate: NVFP4 speichert 4-Bit-Werte mit einem FP8-Skalierungsfaktor je 16 Werte, MXFP4 mit einem Skalierungsfaktor als Zweierpotenz je 32 Werte. Dieser Artikel richtet sich an Teams mit H200-NVL- oder L40S-Servern und einem Modell, das in FP4 veröffentlicht wurde. Er zeigt, was jede Engine mit Stand Oktober 2026 für diese Karten dokumentiert und welchen Checkpoint Sie einsetzen sollten.

Welche Präzisionen H200 NVL, L40S und RTX-Ada-Karten rechnen

NVIDIAs Spezifikationstabelle für die H200 NVL hat Tensor-Core-Zeilen für FP64, TF32, BFLOAT16, FP16, FP8 und INT8, aber keine für FP4. Die Tabelle der L40S führt TF32, BFLOAT16, FP16, FP8, INT8 und INT4, ebenfalls ohne FP4, und NVIDIA beschreibt die Tensor-Kerne der vierten Generation dieser Karte „mit Unterstützung für FP8“. NVIDIAs Liste der Compute Capabilities führt die H200 mit 9.0 und die L4, L40S, RTX 6000 Ada, RTX 5000 Ada, RTX 4500 Ada und RTX 4000 Ada mit 8.9. Die RTX-PRO-Blackwell-Karten stehen dort mit 12.0 und DGX Spark mit 12.1, und diese rechnen FP4 direkt.

Produktseiten von NVIDIA zur H200 und zur L40S und Liste der CUDA Compute Capabilities (die die H200 nennt, nicht die H200 NVL), abgerufen am 10. Oktober 2026; Quantisierungsdokumentation von vLLM (14. September 2026) und Seite zum Model Optimizer (2. Oktober 2026); Quantisierungsdokumentation von SGLang; Quantisierungsmatrix von TensorRT-LLM 1.3.0rc29.

Wie vLLM NVFP4 und MXFP4 auf Hopper und Ada ausführt

Für einen NVFP4-Checkpoint wählt vLLM den Kernel für die Matrixmultiplikation beim Laden aus den Backends, die die Plattform bietet, CUTLASS, FlashInfer, Marlin und andere. Seine Seite zu Checkpoints aus NVIDIA Model Optimizer, datiert auf den 2. Oktober 2026, stellt fest: „Auf GPUs ohne unterstützten nativen FP4-GEMM-Kernel weicht vLLM über Marlin auf eine Weight-only-Ausführung (W4A16) aus“. Sie ergänzt, dass vLLM eine Warnung protokolliert und dass dies „bei rechenintensiven Arbeitslasten den Durchsatz verringern kann“. Auf einer H200 NVL oder einer L40S nimmt ein NVFP4-Modell standardmäßig diesen Weg. Die Option --linear-backend übersteuert die automatische Wahl und ersetzt die veraltete Variable VLLM_NVFP4_GEMM_BACKEND.

Der Marlin-FP4-Code im Quelltext von vLLM setzt Compute Capability 7.5 oder höher voraus und entpackt NVFP4 in Blöcken zu 16 und MXFP4 in Blöcken zu 32. Seine Warnung lautet auszugsweise: „Weight-only FP4 compression will be used leveraging the Marlin kernel.“ Die Quantisierungstabelle von vLLM führt Marlin für GPTQ, AWQ, FP8 und FP4 als unterstützt auf Turing, Ampere, Ada und Hopper.

W4A16 bedeutet 4-Bit-Gewichte und 16-Bit-Aktivierungen. Die Gewichte werden innerhalb jeder Multiplikation in 16 Bit umgewandelt, die Tensor-Kerne leisten also dieselbe Arbeit wie bei einem BF16-Modell. Für den KV-Cache führt TensorRT-LLM ein FP8-Format für Ada und Hopper, und vLLM stellt es mit --kv-cache-dtype fp8 ein.

TensorRT-LLM und SGLang mit FP4-Checkpoints

Die Quantisierungsmatrix von TensorRT-LLM, Dokumentation 1.3.0rc29, aktualisiert am 26. September 2026, führt für Hopper FP8 je Tensor, je Block und je Zeile, einen FP8-KV-Cache sowie INT4 AWQ und GPTQ als W4A16 und W4A8. Ada erhält FP8 je Tensor, den FP8-KV-Cache und dieselben vier INT4-Modi. NVFP4 und MXFP4 erscheinen nur in den Blackwell-Zeilen. NVIDIAs NVFP4-Checkpoint von Llama 3.3 70B nennt „NVIDIA Blackwell“ als unterstützte Mikroarchitektur und TensorRT-LLM als Laufzeit-Engine.

Die einzige Ausnahme für Hopper ist gpt-oss. Der Deployment-Leitfaden von TensorRT-LLM zu gpt-oss stellt fest: „Für Hopper ist das Standard-MoE-Backend TRITON.“ Seine Support-Tabelle kombiniert MXFP4-MoE-Gewichte mit BF16-Aktivierungen auf der H200, die 4-Bit-Gewichte werden also auch dort mit 16-Bit-Präzision gerechnet.

Die Quantisierungsseite von SGLang führt die Methode ModelOpt FP4 für NVIDIA mit „SM80-SM90 über Marlin; SM100+ natives FP4“ und beschreibt sie als „Marlin-W4A16-Fallback auf Ampere/Hopper“. Ihre automatische Backend-Wahl ist so angegeben: „Auf SM80-SM90 wählt auto Marlin für NVFP4.“ Die Seite nennt Ampere und Hopper; die 8.9 von Ada liegt innerhalb dieses Bereichs. Unser Vergleich von vLLM, SGLang, TensorRT-LLM und Ollama behandelt die Engines über die Quantisierung hinaus.

Speicher und Geschwindigkeit von Weight-only-FP4 auf einer H200 NVL

Weight-only-FP4 verringert den Speicher, den die Gewichte belegen, und die Bytes, die für jedes erzeugte Token gelesen werden. Die Arithmetik verringert es nicht. NVIDIAs Leitfaden zum Model Optimizer erklärt, wann das zählt: „Typischerweise ist die Inferenz in Szenarien mit kleinen Batches (Batchgröße ≤ 4) oft ‚speichergebunden‘.“ Für solche Lasten nennt er Weight-only-Verfahren als den größeren Gewinn. Für Batches ab 16 empfiehlt er, auch die Aktivierungen zu quantisieren, und schreibt: „Wir schlagen vor, vorrangig zuerst FP8 zu verwenden, da FP8 nur eine sehr geringe Verschlechterung der Genauigkeit verursacht und eine hohe Leistung bietet.“ Ein Unternehmensassistent mit Hunderten von Nutzern erreicht in seinen Spitzenzeiten Batches von 16 und mehr.

Nehmen Sie Llama 3.3 70B auf einer H200 NVL. NVIDIAs FP8-Checkpoint ist laut den Dateigrößen auf Hugging Face 72,7 GB (67,7 GiB) groß, sein NVFP4-Checkpoint 42,7 GB (39,8 GiB). Unsere Dimensionierungsregel gibt dem KV-Cache 0,9 × die 140,4 GiB, die der Treiber meldet, abzüglich 3 GiB und abzüglich der Gewichte; ein FP8-Cache braucht bei 8.192 Token 1,25 GiB je Sitzung. Der FP8-Checkpoint lässt 55,7 GiB frei, Platz für 44 gleichzeitige Sitzungen. Der NVFP4-Checkpoint lässt 83,6 GiB frei, Platz für 66. Auf acht H200 NVL in zwei Servern, mit einer Kopie des Modells je Karte, sind das 352 gegenüber 528 Sitzungen im Speicher.

Das sind Obergrenzen des Speichers. Ob die NVFP4-Kopie mehr Nutzer mit akzeptabler Antwortzeit bedient, hängt davon ab, wie sich der 16-Bit-Pfad von Marlin bei Ihrer Batchgröße gegenüber der FP8-Arithmetik der Tensor-Kerne verhält, und mit Stand Oktober 2026 haben wir keine veröffentlichte Messung der beiden auf einer H200 von NVIDIA oder vom vLLM-Projekt gefunden. NVIDIAs Model Cards nennen MMLU-Werte von 81,1 für den FP4-Checkpoint, 83,2 für FP8 und 83,3 für BF16, und die FP8-Model-Card führt Hopper und Lovelace unter den unterstützten Architekturen, die NVFP4-Model-Card nur Blackwell. Ein Lasttest beider Checkpoints in Ihrer Engine-Version bei Ihrer höchsten Parallelität entscheidet. Unser Vergleich von RTX PRO 6000 und H200 NVL zeigt den Fall, in dem natives FP4 auf einer Blackwell-Karte besser passt.

Wir liefern die H200 NVL und bauen GPU-Server damit nach Auftrag. Schicken Sie uns das Modell, seinen Checkpoint und Ihre höchste Parallelität, und wir antworten innerhalb eines Werktages mit einer Konfiguration und einem Angebot.

gpt-oss in MXFP4 auf Hopper und Ada

OpenAI veröffentlicht gpt-oss mit MoE-Gewichten in MXFP4, ebenso die darauf aufbauenden Modelle gpt-oss-safeguard. Die Model Card von OpenAI stellt fest: „Die Modelle wurden mit einer MXFP4-Quantisierung der MoE-Gewichte nachtrainiert, wodurch gpt-oss-120b auf einer einzelnen 80-GB-GPU läuft“, und nennt die H100 als Beispiel. Hier ist der MXFP4-Checkpoint die Veröffentlichung selbst, auf Hopper ist er also der Checkpoint, den Sie betreiben. Unser Leitfaden zur Hardware für gpt-oss-120b dimensioniert seine 65,3 GB Gewichte auf einer H200 NVL.

Das gpt-oss-Rezept von vLLM, aktualisiert am 22. September 2026, führt die H100, H200 und B200 unter den NVIDIA-GPUs, „mit laufender Arbeit für Ampere/Ada/RTX 5090“. Für Hopper sagt es, den Blackwell-Befehl ohne die Einstellung für den FP8-KV-Cache und ohne die FlashInfer-MoE-Flags auszuführen. Auf einer einzelnen A100 nennt es „Marlin MXFP4 MoE“ als Standard. Der ältere Leitfaden in der Dokumentation von vLLM enthält ein auskommentiertes VLLM_MXFP4_USE_MARLIN=1, einen Workaround für eine Leistungsregression von vLLM v0.12.0 auf Hopper bei geringer Parallelität, die laut dem Leitfaden upstream behoben wurde.

Auf der L40S braucht gpt-oss-120b mehr als eine Karte, da 65,3 GB Gewichte 48 GB übersteigen. Die Quantisierungstabelle von vLLM führt Marlin FP4 für Ada, während das gpt-oss-Rezept Ada noch als laufende Arbeit bezeichnet. Behandeln Sie gpt-oss auf L40S-Servern als Konfiguration, die zu testen ist, nicht als dokumentiertes Rezept. Unser Artikel zu den Benchmarks der L40S sammelt, was auf der Karte gemessen wurde.

Welchen Checkpoint Sie auf einer Flotte aus H200 NVL oder L40S betreiben

Rezepte von vLLM für Llama 4 Scout (24. September 2026), gpt-oss (22. September 2026) und DeepSeek-V4-Flash (29. September 2026); Quantisierungsmatrix von TensorRT-LLM 1.3.0rc29; Model Cards von NVIDIAs Llama 3.3 70B in FP8 und NVFP4 und von Kimi K2 Thinking auf Hugging Face, abgerufen am 10. Oktober 2026.

Das Rezept von vLLM für Llama 4 Scout, geschrieben für „NVIDIA Blackwell & Hopper Hardware“, macht die Wahl explizit. Sein Startskript wählt den FP4-Checkpoint nur bei Compute Capability 10.0 und auf jeder anderen GPU den FP8-Checkpoint, eine H200 NVL bedient Scout also in FP8. Dieser Checkpoint ist 111,6 GB oder 103,9 GiB groß und passt nach der Regel oben auf eine Karte, mit etwa 19 GiB für den Cache.

Einige Modelle werden mit ihren Expertengewichten in einem 4-Bit-Format veröffentlicht. Das Rezept von vLLM für DeepSeek-V4-Flash, aktualisiert am 29. September 2026, stellt für den Preview-Checkpoint fest, dass „MoE-Expertengewichte in FP4 gespeichert werden“, während die übrigen Parameter in FP8 bleiben, und seine Befehle für die H200 bedienen diesen Checkpoint. Es sagt nicht, welcher Kernel die FP4-Experten auf Hopper rechnet. Kimi K2 Thinking nutzt stattdessen Ganzzahlen: Seine Model Card beschreibt eine „INT4-Weight-only-Quantisierung für die MoE-Komponenten“ mit quantisierungsbewusstem Training, gespeichert im Format compressed-tensors. Das ist dieselbe W4A16-Arithmetik wie beim FP4-Fallback, auf Gewichten, die für die Speicherung in 4 Bit trainiert wurden.

Auf einer L40S fällt die Wahl meist zwischen FP8 und INT4 AWQ. Nehmen Sie Qwen3-32B auf einem Server mit acht L40S, eine Kopie je Karte. Qwens FP8-Checkpoint ist 34,3 GB (32,0 GiB) groß, sein AWQ-Checkpoint 19,3 GB (18,0 GiB). Die L40S hat GDDR6 mit ECC, und NVIDIAs CUDA C++ Best Practices Guide stellt fest, dass auf GDDR-Speicher mit eingeschaltetem ECC „sich der verfügbare DRAM um 6,25 % verringert“. Wir gehen daher von etwa 44,8 GiB je Karte mit eingeschaltetem ECC und 47,8 GiB mit ausgeschaltetem ECC aus, beides unsere Schätzungen, und wenden dieselbe Regel an. Bei 1 GiB FP8-Cache je 8K-Sitzung hält die FP8-Kopie mit eingeschaltetem ECC etwa 5 Sitzungen je Karte und die AWQ-Kopie etwa 19, nach unserer Schätzung also 40 gegenüber 152 im ganzen Server. Mit ausgeschaltetem ECC sind es 8 und 22 je Karte, und nvidia-smi -q zeigt den ECC-Modus der gelieferten Karte. AWQ läuft in vLLM und TensorRT-LLM auf Ada als W4A16, ohne FP4-Fallback.

Wir bauen L40S- und H200-NVL-Server nach Auftrag und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Beschreiben Sie die Modelle und Checkpoints, die Sie betreiben wollen, im Formular unten, mit Ihrer höchsten Zahl an Nutzern.

Wie Sie prüfen, welchen Kernel ein FP4-Modell nutzt

1. Lesen Sie die Quantisierungsmetadaten des Checkpoints, bevor Sie ihn herunterladen: hf_quant_config.json bei Checkpoints aus NVIDIA Model Optimizer oder den Quantisierungsabschnitt der config.json.
2. Starten Sie vLLM mit dem Checkpoint auf einer Karte und durchsuchen Sie das Log nach der Weight-only-Warnung von Marlin, die den Fallback-Pfad bestätigt.
3. Starten Sie den FP8- oder AWQ-Checkpoint desselben Modells mit derselben Engine-Version, derselben Kontextlänge und demselben FP8-KV-Cache.
4. Belasten Sie beide mit Ihrer erwarteten höchsten Parallelität und erfassen Sie die Zeit bis zum ersten Token und die Token pro Sekunde je Nutzer.
5. Lassen Sie Ihren eigenen Evaluierungsdatensatz auf beiden laufen, denn die Genauigkeitskosten unterscheiden sich zwischen Modellen und Formaten.

Was wir liefern

Wir liefern die H200 NVL, die L40S und die L4, die RTX-Ada-Karten (RTX 6000 Ada, RTX 5880 Ada, RTX 5000 Ada, RTX 4500 Ada und RTX 4000 Ada) und die RTX-PRO-Blackwell-Karten, deren FP4-Tensor-Kerne NVFP4 und MXFP4 direkt rechnen. Alle professionellen NVIDIA-GPUs kommen mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Wir bauen KI-Server nach Auftrag um sie herum, mit Konfiguration und Angebot innerhalb eines Werktages und mit Lizenzen für NVIDIA AI Enterprise auf derselben Rechnung.

FAQ