> For the complete documentation index, see [llms.txt](https://unsloth.ai/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://unsloth.ai/docs/de/grundlagen/nvfp4.md). # Unsloth Dynamic NVFP4 ausführen - Anleitung Unsloth Dynamic NVFP4 ist ein quantisiertes Modellformat, das auf NVIDIA-Blackwell-GPUs läuft und für schnellere, genauere 4-Bit-Inferenz ausgelegt ist. Es kombiniert NVIDIAs native NVFP4-Präzision mit [Unsloth Dynamic 2.0](/docs/de/grundlagen/unsloth-dynamic-2.0-ggufs.md) Quantisierung, um die Modellgenauigkeit zu erhalten, während der VRAM-Verbrauch reduziert und die Geschwindigkeit erhöht wird. Dieser Leitfaden erklärt FP4-Quantisierung, vergleicht NVFP4 mit anderen Formaten und zeigt, wie man Modelle wie [Gemma 4](/docs/de/modelle/gemma-4.md) und [Qwen3.6](/docs/de/modelle/qwen3.6.md) 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 bleiben, während der Rest in W4A4 (nicht W4A16) bleibt, anstatt jede Schicht in FP4 zu zwingen. 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 FP8-KV-Cache-Kalibrierung, die **2x längere Kontextlängen**. {% hint style="success" %} **Alle** [**Gemma 4**](#gemma-4) **Modelle sind jetzt als Unsloth Dynamic NVFP4 Quants verfügbar:** E2B, E4B, 12B Unified, 26B-A4B MoE und 31B Dense. Entdecke die [Unsloth Dynamic NVFP4 Collection](https://huggingface.co/collections/unsloth/nvfp4) für alle unsere Modell-Uploads. {% endhint %} ### Float4 vs. andere Präzisionen Der Trick für **schnellere GPUs besteht darin, die numerische Präzision von Matrixmultiplikationen zu verringern**. Die Anzahl der Transistoren, die für die Matrixmultiplikationseinheiten benötigt wird, hängt mit dem **Quadrat der Mantisse**zusammen. Die Mantisse bestimmt, wie viele „Bruchteils“-Dezimalstellen Zahlen haben können – je mehr Bits, desto genauer können Dezimalzahlen dargestellt werden. Zum Beispiel ist die Darstellung von 0.121332 mit mehr Mantissen-Bits möglich, während wenige Mantissen-Bits sie auf 0.1 runden. {% columns %} {% column width="50%" %} FP32 hat 23 Mantissen-Bits, also werden 23^2 + 8 Exponenten-Bits = 537 Platz benötigt. Bfloat16 hat 7 Mantissen-Bits, also 7^2 + 8 Exponenten = 57 Platz. Das bedeutet, dass bfloat16 etwa 9x weniger Platz als FP32 benötigt! Und wenn wir zu float8 gehen, das 3 Mantissen-Bits hat, dann sind es 3^2 + 4 Exponenten = 13 – das ist 41x weniger Platz als FP32! Schließlich hat float4 1 Mantissen-Bit und 2 Exponenten, also 3 Platz – satte 179x weniger Platz als FP32 – das bedeutet im Wesentlichen, dass eine **GPU auf demselben Platz etwa 179x mehr FP4-Matrixmultiplikationen als FP32-Multiplikations-FLOPs durchführen kann**! {% endcolumn %} {% column width="50%" %} ![](/files/1f904f13dc03bb9f53712d1d05e6621155864cc9) {% endcolumn %} {% endcolumns %} ### NVFP4 vs. MXFP4
Es gibt noch ein anderes FP4-Format namens MXFP4 – es ist aufgrund von 2 Dingen ungenauer als NVFP4: 1. NVFP4 verwendet eine Blockgröße von 16 statt 32 wie MXFP4 – dadurch können Ausreißer leichter isoliert werden, und Skalierungsfaktoren werden für kleinere Teilmengen von Gewichten bereitgestellt, was die Genauigkeit erhöht 2. Pro Block wird eine E4M3-(FP8)-Skalierung statt einer E8M0-Skalierung (Potenzen-von-2-Skalierung) verwendet. Die Verwendung einer Blockgröße vom FP8-Typ scheint deutlich besser zu sein, insbesondere für LLMs. ### Leistungsanalyse Unsere neuen dynamischen NVFP4-Qwen3.6-Quants laufen \~**2,5× schneller** als andere NVFP4-Quants, mit **besserer Leistung** und vergleichbaren Dateigrößen. Führe Qwen3.6-27B NVFP4 aus **2,5x schneller** auf **24 GB VRAM** und Qwen3.6-35B-A3B **1,7x schneller** auf **32 GB VRAM**. Außerdem haben wir **FP8-KV-Cache-Kalibrierung** für 2x längere Kontextlängen hinzugefügt! NVFP4 erfordert NVIDIAs Blackwell-GPUs wie RTX 50X, DGX Spark (siehe [#dgx-spark-with-nvfp4-quants](#dgx-spark-with-nvfp4-quants "mention")), B200, B300 GPUs. Für ältere GPUs funktionieren unsere GGUFs gut!
Alle Benchmarks verwenden 1x B200 mit 128 gleichzeitigen Anfragen. Höhere Parallelität kann 35B auf 17.561 Token/s steigern. Wir veröffentlichen außerdem zwei 35B-A3B-NVFP4-Versionen: * [Qwen3.6-35B-A3B-NVFP4-Fast](https://huggingface.co/unsloth/Qwen3.6-35B-A3B-NVFP4-Fast) das ein vollständiger W4A4-Quant ist – 1,79x schneller * [Qwen3.6-35B-A3B-NVFP4](https://huggingface.co/unsloth/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 sich bei allen ähnlich verhalten:
Qwen3.6-35B-A3BQwen3.6-27B
Qwen3.6-35B-A3B-NVFP4 (1,56x schneller)Qwen3.6-27B-NVFP4 (2,5x schneller)
Qwen3.6-35B-A3B-NVFP4-Fast (1,79x schneller)
**MTP-Tensoren sind ebenfalls direkt in die Quants integriert, um zusätzliche Geschwindigkeitssteigerungen zu erzielen.** Die Genauigkeitsgewinne stammen aus Verbesserungen an Qwen3.6s Chat-Template und der Datensatzkalibrierung. Wir verwenden unsere früheren Chat-Template-Updates, um die Konsistenz bei Coding und Tool-Calling zu verbessern und gleichzeitig Looping sowie andere gemeldete Probleme zu reduzieren. Unsere Kalibrierung nutzt eine Mischung aus unserem für Coding, Tool-Calling und Chat optimierten Datensatz zusammen mit UltraChat. Für die Decode-Geschwindigkeit (Tokens pro Person) ist unsere Variante für 27B 1,03x schneller und für 35B 1,17x bzw. 1,22x schneller.
### Übersicht Unten findest du die Hardware-Anforderungen für die Modelle, die du verwenden kannst, einschließlich Gemma 4 und Qwen3.6. Sieh dir auch den gesamten Geschwindigkeitszuwachs an, den du erreichst: #### Gemma 4: | Gemma-4-Variante | Erforderlicher VRAM | Schneller als BF16 | | ------------------------------------------------------------------ | ------------------: | -----------------: | | [E2B](https://huggingface.co/unsloth/gemma-4-E2B-it-NVFP4) | 7 GB | 1,12× schneller | | [E4B](https://huggingface.co/unsloth/gemma-4-E4B-it-NVFP4) | 9 GB | 1,22× schneller | | [12B Unified](https://huggingface.co/unsloth/gemma-4-12b-it-NVFP4) | 11 GB | 1,26× schneller | | [26B A4B](https://huggingface.co/unsloth/gemma-4-26B-A4B-it-NVFP4) | 26 GB | 1,41× schneller | | [31B](https://huggingface.co/unsloth/gemma-4-31B-it-NVFP4) | 32 GB | 1,45× schneller |
#### Qwen3.6: | Qwen3.6-Variante | Erforderlicher VRAM | Schneller als andere NVFP4-Quants | | ------------------------------------------------------------------------- | ------------------: | --------------------------------: | | [27B](https://huggingface.co/unsloth/Qwen3.6-27B-NVFP4) | 24 GB | 2,5× schneller | | [35B A3B](https://huggingface.co/unsloth/Qwen3.6-35B-A3B-NVFP4) | 32 GB | 1,56× schneller | | [35B A3B Fast](https://huggingface.co/unsloth/Qwen3.6-35B-A3B-NVFP4-Fast) | 32 GB | 1,79× schneller | ### 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 decodieren als NVIDIAs Versionen, die W4A16 verwenden. Außerdem quantisieren wir Schichten dynamisch, um die Genauigkeit zu erhalten, und wir haben MMLU-Pro, AIME 2025 und GPQA für alle Quants durchgeführt, einschließlich des Vergleichs mit FP8 und BF16. **Genauigkeits-Benchmarks für Qwen3.6-27B NVFP4** | Anbieter | MMLU-Pro | GPQA | AIME 2025 | | -------- | -------: | ----: | --------: | | Unsloth | 86.25 | 86.34 | 93.12 | | NVIDIA | 85.96 | 86.87 | 93.12 | | FP8 | 86.11 | 86.87 | 93.75 | | BF16 | 85.96 | 88.13 | 93.33 | **Genauigkeits-Benchmarks für Qwen3.6-35B-A3B NVFP4** | Anbieter | MMLU-Pro | GPQA | AIME 2025 | | ---------------- | -------: | ----: | --------: | | Unsloth | 85.85 | 86.74 | 92.29 | | **Unsloth Fast** | 85.58 | 87.75 | 91.67 | | NVIDIA | 85.60 | 87.12 | 91.88 | | FP8 | 85.75 | 86.74 | 93.12 | | BF16 | 85.75 | 86.36 | 92.50 | 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 ihrer Quantisierung zunichtemachen würde! (Also: Wenn es 2x schneller ist, aber 2x mehr nachdenkt, dann ist das nutzlos)
## **NVFP4-Tutorials ausführen** Um NVFP4-Quants auszuführen, findest du unten Befehle, um Qwen3.6-27B in [vLLM](/docs/de/grundlagen/inference-and-deployment/vllm-guide.md) und [SGLang](/docs/de/grundlagen/inference-and-deployment/sglang-guide.md) auszuführen (du kannst den Modellnamen ändern in `Qwen3.6-35-A3B-NVFP4`). ### **vLLM-Tutorial** Du kannst alle NVFP4-Modelle in [vLLM](https://github.com/vllm-project/vllm)ausführen. Wähle KEIN MoE-Backend aus – überlasse vLLM die Auswahl – denn z. B. Marlin ist 2,5x langsamer! Siehe [#marlin-vs-flashinfer-vs-cutlass-vs-cute-dsl](#marlin-vs-flashinfer-vs-cutlass-vs-cute-dsl "mention")Wenn du einen DGX Spark hast, siehe [#dgx-spark-serving](#dgx-spark-serving "mention") du musst `--moe-backend flashinfer_b12x` verwenden, sonst erhältst du eine viel langsamere Inferenz. Um vLLM in einer separaten venv zu installieren: {% code overflow="wrap" expandable="true" %} ```bash uv venv unsloth-nvfp4-env --python 3.13 source unsloth-nvfp4-env/bin/activate uv pip install "vllm>=0.25.0" "flashinfer-python>=0.6.13" "nvidia-cutlass-dsl>=4.5.2" \\ --torch-backend=auto ``` {% endcode %} Dann, um die 35B-Fast-Variante bereitzustellen: ```shell vllm serve unsloth/Qwen3.6-35B-A3B-NVFP4-Fast ``` Ändere `unsloth/Qwen3.6-35B-A3B-NVFP4-Fast` zu den NVFP4-Quantnamen! Um MTP / spekulatives Dekodieren zu aktivieren (schnelleres Decoding, aber etwas geringerer Durchsatz), verwende: ```bash vllm serve unsloth/Qwen3.6-35B-A3B-NVFP4-Fast --speculative-config '{"method": "mtp", "num_speculative_tokens": 2}' ``` Wenn du Torchcodec-Probleme bekommst, führe bitte die folgenden Schritte aus und starte dann vllm neu. {% code overflow="wrap" expandable="true" %} ```bash sudo apt-get update sudo apt-get install -y ffmpeg ``` {% endcode %} ### **DGX-Spark-Tutorial** Um sicherzustellen, dass DGX Spark die richtigen Kernel hat (sonst erhältst du **2x LANGSAMERE Inferenz**), prüfe zuerst: {% code overflow="wrap" expandable="true" %} ```bash python -c " import torch; from vllm.utils.flashinfer import has_flashinfer_b12x_gemm as g, has_flashinfer_b12x_moe as m cap = torch.cuda.get_device_capability(); print('cap', cap, '| b12x gemm', g(), '| b12x moe', m()); assert cap[0] == 12 and g() and m(), 'b12x unavailable: serving would degrade to marlin W4A16'" ``` {% endcode %} was KEINEN Fehler auslösen sollte - falls doch, aktualisiere bitte vllm oder installiere erneut über: {% code overflow="wrap" expandable="true" %} ```bash uv venv unsloth-nvfp4-env --python 3.13 source unsloth-nvfp4-env/bin/activate uv pip install "vllm>=0.25.0" "flashinfer-python>=0.6.13" "nvidia-cutlass-dsl>=4.5.2" \\ --torch-backend=auto ``` {% endcode %} Dann, um in vLLM für DGX Spark bereitzustellen: {% code overflow="wrap" expandable="true" %} ```shellscript export CUTE_DSL_ARCH=sm_121a vllm serve unsloth/Qwen3.6-35B-A3B-NVFP4-Fast --moe-backend flashinfer_b12x ``` {% endcode %} Wenn du Torchcodec-Probleme bekommst, führe bitte die folgenden Schritte aus und starte dann vllm neu. {% code overflow="wrap" expandable="true" %} ```bash sudo apt-get update sudo apt-get install -y ffmpeg ``` {% endcode %} ### **SGLang-Tutorial:** Du kannst alle NVFP4-Modelle in [SGLang](https://github.com/sgl-project/sglang). Denk daran, den Modellnamen gegen das gewünschte Modell auszutauschen. **Qwen3.6:** ```bash python -m sglang.launch_server --model-path unsloth/Qwen3.6-27B-NVFP4 --speculative-algorithm NEXTN \\ --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4 ``` **Gemma 4:** ```bash python -m sglang.launch_server --model-path unsloth/Gemma-4-31B-NVFP4 --speculative-algorithm NEXTN \\ --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4 ``` ### Gemma 4 und andere Jede Gemma-4-Variante hat jetzt einen Unsloth Dynamic NVFP4-Checkpoint. Wir zeigen, dass Gemma-4 auf 1x B200 beim Bedienen von 128 gleichzeitigen Anfragen im Vergleich zu 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 – wenn man es aktiviert, führt das zu einer 2,5x Leistungsverschlechterung – also verwende CUTLASS, Flashinfer-TRTLLM oder Cute-DSL (in vLLM automatisch aktiviert)! Wenn du außerdem einen DGX Spark hast, siehe [#dgx-spark-serving](#dgx-spark-serving "mention") du musst `--moe-backend flashinfer_b12x` sonst erhältst du eine 2,5x langsamere Inferenz. **Stelle also kein Backend ein – vLLM wählt automatisch das beste aus.** | Modell | Schema | Backend | Decode Tok/s | Durchsatz Tok/s | | --------------- | ------ | ------------------- | ------------ | --------------- | | nvidia 27B | W4A16 | marlin (auto) | 115.6 | 2,403 | | unsloth 27B | W4A4 | marlin | 105.6 | 2,127 | | unsloth 27B | W4A4 | cutlass | 113.5 | 6,681 | | unsloth 27B | W4A4 | flashinfer\_trtllm | 112.6 | 6,158 | | unsloth 27B | W4A4 | **cute-DSL (auto)** | 125.9 | **6,863** | | nvidia 35B-A3B | W4A4 | marlin (auto) | 240.8 | 8,721 | | unsloth 35B-A3B | W4A4 | marlin | 215.8 | 8,619 | | unsloth 35B-A3B | W4A4 | cutlass | 158.3 | 11,017 | | unsloth 35B-A3B | W4A4 | **cute-DSL (auto)** | 295.2 | **15,636** | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://unsloth.ai/docs/de/grundlagen/nvfp4.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.