> 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 Leitfaden 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](/docs/de/grundlagen/dynamic-3.0-ggufs.md) 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](/docs/de/modelle/qwen3.8.md), [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 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**. {% hint style="success" %} **14. Aug.:** [**Qwen3.8-27B**](/docs/de/modelle/qwen3.8.md) **ist jetzt zusammen mit unserem NVFP4-Quant verfügbar.** **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. Entdecken Sie 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 für die Matrixmultiplikationseinheiten benötigten Transistoren hängt mit dem **Quadrat der Mantisse**zusammen. 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. {% columns %} {% column width="50%" %} 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**! {% endcolumn %} {% column width="50%" %} ![](/files/1f904f13dc03bb9f53712d1d05e6621155864cc9) {% endcolumn %} {% endcolumns %} ### 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 VRAM**aus. 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 [#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 Concurrency. Höhere Concurrency kann 35B auf 17.561 Tokens / s steigern. Wir haben außerdem gerade unsere neuen [Qwen3.8](/docs/de/modelle/qwen3.8.md) NVFP4-Quants veröffentlicht: * [Qwen3.8-27B NVFP4](https://huggingface.co/unsloth/Qwen3.8-27B-NVFP4) (neu) 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 bei allen ähnlich abschneiden:
| Qwen3.8-27B (neu) | | --------------------------------------------------------------------------- | | [Qwen3.8-27B NVFP4](https://huggingface.co/unsloth/Qwen3.8-27B-NVFP4) (neu) |
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 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: | 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,5x 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 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** | 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 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](/docs/de/grundlagen/inference-and-deployment/vllm-guide.md) und [SGLang](/docs/de/grundlagen/inference-and-deployment/sglang-guide.md) (Sie können den Modellnamen ändern in `Qwen3.6-35-A3B-NVFP4`). ### **vLLM-Tutorial** Sie können alle NVFP4-Modelle in [vLLM](https://github.com/vllm-project/vllm)ausführen. WÄHLEN Sie kein MoE-Backend aus – lassen Sie vLLM es auswählen – z. B. ist Marlin 2,5x langsamer! Siehe [#marlin-vs-flashinfer-vs-cutlass-vs-cute-dsl](#marlin-vs-flashinfer-vs-cutlass-vs-cute-dsl "mention")Wenn Sie einen DGX Spark haben, siehe [#dgx-spark-serving](#dgx-spark-serving "mention") Sie müssen `--moe-backend flashinfer_b12x` verwenden, sonst erhalten Sie eine deutlich 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 ``` Ä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: ```bash vllm serve unsloth/Qwen3.6-35B-A3B-NVFP4-Fast --speculative-config '{"method": "mtp", "num_speculative_tokens": 2}' ``` Wenn Sie Torchcodec-Probleme haben, führen Sie unbedingt das Folgende aus und starten Sie 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 erhalten Sie **2x LANGSAMERE Inferenz**), prüfen Sie 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 – wenn doch, aktualisieren Sie bitte vllm oder installieren Sie es neu ü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 Sie Torchcodec-Probleme haben, führen Sie unbedingt das Folgende aus und starten Sie dann vllm neu. {% code overflow="wrap" expandable="true" %} ```bash sudo apt-get update sudo apt-get install -y ffmpeg ``` {% endcode %} ### **SGLang-Tutorial:** Sie können alle NVFP4-Modelle in [SGLang](https://github.com/sgl-project/sglang). Denken Sie daran, den Modellnamen durch das gewünschte Modell zu ersetzen. **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 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 [#dgx-spark-serving](#dgx-spark-serving "mention") 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.** | 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.