🦥Leitfaden zum Ausführen von Unsloth Dynamic NVFP4

Unsloth Dynamic NVFP4 ist ein quantisiertes Modellformat, das auf NVIDIA-Blackwell-GPUs läuft und für eine schnellere, genauere 4-Bit-Inferenz ausgelegt ist. Es kombiniert NVIDIAs native NVFP4-Präzision mit Unsloth Dynamic 2.0 Quantisierung, um die Modellgenauigkeit zu erhalten und gleichzeitig den VRAM-Verbrauch zu senken und die Geschwindigkeit zu erhöhen. Dieser Leitfaden erklärt FP4-Quantisierung, vergleicht NVFP4 mit anderen Formaten und zeigt, wie man Modelle wie Qwen3.8, Gemma 4 und Qwen3.6 lokal mit vLLM oder SGLang auf RTX 5050-5090, B200, RTX PRO 6000 und weiteren GPUs ausführt.

Dynamic NVFP4 funktioniert, indem wichtige Schichten ausgewählt werden, die in FP8 (W8A8) oder BF16 verbleiben, und der Rest in W4A4 (nicht W4A16), anstatt jede Schicht in FP4 zu erzwingen. Dadurch sind bis zu 2,5x schnellere Inferenz möglich, da W4A4 die FP4-Tensor-Cores der Blackwell-GPU nutzt. Für alle Quants bieten wir außerdem eine FP8-KV-Cache-Kalibrierung an, die 2x längere Kontextlängen.

Float4 vs. andere Präzisionen

Der Trick für schnellere GPUs besteht darin, die numerische Präzision von Matrixmultiplikationen zu verringern. Die Anzahl der für die Matrixmultiplikationseinheiten benötigten Transistoren hängt mit dem Quadrat der Mantissezusammen. Die Mantisse bestimmt, wie viele "Bruch"-Nachkommastellen Zahlen haben können – je mehr Bits, desto genauer können Dezimalzahlen dargestellt werden. Zum Beispiel ist die Darstellung von 0,121332 mit mehr Mantissenbits möglich, während wenige Mantissenbits auf 0,1 runden.

FP32 hat 23 Mantissenbits, also werden 23^2 + 8 Exponentenbits = 537 Platz benötigt. Bfloat16 hat 7 Mantissenbits, also 7^2 + 8 Exponenten = 57 Platz. Das bedeutet, dass bfloat16 etwa 9x weniger Platz als FP32 benötigt! Und wenn wir zu float8 mit 3 Mantissenbits gehen, also 3^2 + 4 Exponenten = 13 – das ist 41x weniger Platz als FP32!

Schließlich hat float4 1 Mantissenbit und 2 Exponenten, also 3 Platz – satte 179x weniger Platz als FP32 – das bedeutet im Wesentlichen, dass eine GPU auf derselben Fläche etwa 179x mehr FP4-Matrixmultiplikationen als FP32-Multiplikations-FLOPs ausführen kann!

NVFP4 vs. MXFP4

Es gibt ein weiteres FP4-Format namens MXFP4 – es ist aufgrund von 2 Dingen weniger genau als NVFP4:

1. NVFP4 verwendet eine Blockgröße von 16 statt 32 bei MXFP4 – dadurch lassen sich Ausreißer leichter isolieren und Skalierungsfaktoren werden für kleinere Teilmengen von Gewichten bereitgestellt, was die Genauigkeit erhöht

2. Pro Block wird ein E4M3-(FP8)-Skalierungswert anstelle eines E8M0-(Potenz-von-2-Skalierung)-Werts verwendet. Die Verwendung einer FP8-Blockgröße scheint deutlich besser zu sein, insbesondere für LLMs.

Leistungsanalyse

Unsere neuen dynamischen NVFP4-Qwen3.6-Quants laufen ~2,5x schneller als andere NVFP4-Quants, mit besserer Leistung und vergleichbaren Dateigrößen. Führen Sie Qwen3.6-27B NVFP4 2,5x schneller auf 24 GB VRAM und Qwen3.6-35B-A3B 1,7x schneller auf 32 GB VRAMaus. Wir haben außerdem FP8-KV-Cache-Kalibrierung für 2x längere Kontextlängen hinzugefügt! NVFP4 erfordert NVIDIAs Blackwell-GPUs wie RTX 50X, DGX Spark (siehe Unsloth Dynamic NVFP4), B200-, B300-GPUs. Für ältere GPUs funktionieren unsere GGUFs gut!

Alle Benchmarks verwenden 1x B200 mit 128 Concurrency. Höhere Concurrency kann 35B auf 17.561 Tokens / s steigern. Wir haben außerdem gerade unsere neuen Qwen3.8 NVFP4-Quants veröffentlicht:

• Qwen3.8-27B NVFP4 (neu)

Wir veröffentlichen außerdem zwei 35B-A3B-NVFP4-Versionen:

• Qwen3.6-35B-A3B-NVFP4-Fast das ein vollständiger W4A4-Quant ist – 1,79x schneller

• Qwen3.6-35B-A3B-NVFP4 das etwas größer, aber genauer und 1,56x schneller ist

Für Genauigkeits-Benchmarks haben wir MMLU-Pro, AIME 2025 und GPQA für FP8, BF16, NVIDIAs NVFP4 und unsere NVFP4s durchgeführt – wir zeigen, dass unsere schnelleren Quants bei allen ähnlich abschneiden:

MTP-Tensoren sind für zusätzliche Geschwindigkeitssteigerungen ebenfalls direkt in die Quants eingebaut. Genauigkeitsgewinne stammen aus Verbesserungen an Qwen3.6s Chat-Template und der Datensatzkalibrierung. Wir verwenden unsere früheren Chat-Template-Updates, um die Konsistenz beim Coden und bei Tool-Calls zu verbessern und gleichzeitig Loops und andere gemeldete Probleme zu reduzieren. Unsere Kalibrierung nutzt eine Mischung unseres für Coden, Tool-Calls und Chat optimierten Datensatzes zusammen mit UltraChat.

Für Decode-Geschwindigkeit (Tokens pro Person) sind unsere Quants bei 27B 1,03x schneller und bei 35B 1,17x bzw. 1,22x schneller.

Übersicht

Nachfolgend finden Sie die Hardwareanforderungen für die Modelle, die Sie verwenden können, einschließlich Gemma 4 und Qwen3.6. Sehen Sie auch die insgesamt erzielte Geschwindigkeitssteigerung:

Gemma 4:

Qwen3.6:

NVFP4-Benchmarks

NVFP4 führt 4-Bit-Gewichte und Matrixmultiplikationen direkt auf Blackwell Tensor Cores aus. Unsere Qwen3.6-NVFP4-Quants verwenden W4A4, sodass sie tatsächlich die FP4 Tensor Cores nutzen und daher schneller dekodieren als NVIDIAs Quants, die W4A16 verwenden. Wir quantisieren außerdem Schichten dynamisch, um die Genauigkeit zu erhalten, und wir haben MMLU-Pro, AIME 2025 und GPQA für alle Quants durchgeführt, einschließlich Vergleichen mit FP8 und BF16.

Genauigkeits-Benchmarks für Qwen3.6-27B NVFP4

Genauigkeits-Benchmarks für Qwen3.6-35B-A3B NVFP4

Wir haben auch die Ausgabelänge aller Benchmarks überprüft, und sie sind vergleichbar, sodass die neuen NVFP4-Quants nicht länger nachdenken, was den Zweck der Quantisierung zunichtemacht! (Wenn es also 2x schneller ist, aber 2x mehr nachdenkt, ist das nutzlos)

NVFP4-Tutorials ausführen

Um NVFP4-Quants auszuführen, finden Sie unten die Befehle, um Qwen3.6-27B in vLLM und SGLang (Sie können den Modellnamen ändern in Qwen3.6-35-A3B-NVFP4).

vLLM-Tutorial

Sie können alle NVFP4-Modelle in vLLMausführen. WÄHLEN Sie kein MoE-Backend aus – lassen Sie vLLM es auswählen – z. B. ist Marlin 2,5x langsamer! Siehe Unsloth Dynamic NVFP4Wenn Sie einen DGX Spark haben, siehe Unsloth Dynamic NVFP4 Sie müssen --moe-backend flashinfer_b12x verwenden, sonst erhalten Sie eine deutlich langsamere Inferenz.

Um vLLM in einer separaten venv zu installieren:

Dann, um die 35B-Fast-Variante bereitzustellen:

Ändern Sie unsloth/Qwen3.6-35B-A3B-NVFP4-Fast zu den NVFP4-Quantisierungsnamen!

Um MTP / speculative decoding zu aktivieren (schnelleres Decoding, aber etwas geringerer Durchsatz), verwenden Sie:

Wenn Sie Torchcodec-Probleme haben, führen Sie unbedingt das Folgende aus und starten Sie dann vllm neu.

DGX Spark-Tutorial

Um sicherzustellen, dass DGX Spark die richtigen Kernel hat (sonst erhalten Sie 2x LANGSAMERE Inferenz), prüfen Sie zuerst:

was KEINEN Fehler auslösen sollte – wenn doch, aktualisieren Sie bitte vllm oder installieren Sie es neu über:

Dann, um in vLLM für DGX Spark bereitzustellen:

Wenn Sie Torchcodec-Probleme haben, führen Sie unbedingt das Folgende aus und starten Sie dann vllm neu.

SGLang-Tutorial:

Sie können alle NVFP4-Modelle in SGLang. Denken Sie daran, den Modellnamen durch das gewünschte Modell zu ersetzen.

Qwen3.6:

Gemma 4:

Gemma 4 und andere

Jede Gemma-4-Variante hat jetzt einen Unsloth Dynamic NVFP4-Checkpoint.

Wir zeigen, dass Gemma 4 beim Serving von 128 gleichzeitigen Personen auf 1x B200 gegenüber BF16 höchstens einen 1,44x höheren Durchsatz hat. Qwen3.5-122B-A10B ist 1,38x schneller und GLM-4.7-Flash ist 1,27x schneller.

Marlin vs. Flashinfer vs. Cutlass vs. Cute-DSL

Wir haben außerdem festgestellt, dass Marlin-Kernel W4A4 nicht gut unterstützen – die Aktivierung führt zu einer 2,5x Leistungsverschlechterung – verwenden Sie daher CUTLASS, Flashinfer-TRTLLM oder Cute-DSL (in vLLM automatisch aktiviert)! Wenn Sie außerdem einen DGX Spark haben, siehe Unsloth Dynamic NVFP4 Sie müssen --moe-backend flashinfer_b12x sonst erhalten Sie eine 2,5x langsamere Inferenz.

Legen Sie also kein Backend fest – vLLM wählt automatisch das beste aus.