> 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).
# Anleitung zu Unsloth Dynamic NVFP4
Erfahren Sie, wie Unsloth Dynamic NVFP4 schnelle und präzise 4-Bit-Inferenz auf NVIDIA-Blackwell-GPUs ermöglicht.
Unsloth Dynamic NVFP4 ist ein quantisiertes Modellformat, das auf NVIDIA-Blackwell-GPUs läuft und für schnelleres, genaueres 4-Bit-Inferencing ausgelegt ist. Es kombiniert NVIDIAs native NVFP4-Genauigkeit mit [Unsloth Dynamic 2.0](/docs/de/grundlagen/dynamic-3.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 die 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 zwingen. Dies ermöglicht bis zu **2,5x schnellere Inferenz** da W4A4 NVIDIAs FP4-Tensor-Cores der Blackwell-GPU nutzt. Für alle Quants bieten wir außerdem eine FP8-KV-Cache-Kalibrierung, 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-Sammlung](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 vom **Quadrat der Mantisse**. Die Mantisse bestimmt, wie viele „gebrochene“ 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 Mantissenbits möglich, während wenige Mantissenbits sie auf 0,1 runden würden.
{% columns %}
{% column width="50%" %}
FP32 hat 23 Mantissenbits, also werden 23^2 + 8 Exponentenbits = 537 Speicherplatz benötigt. Bfloat16 hat 7 Mantissenbits, also 7^2 + 8 Exponenten = 57 Speicherplatz. Das bedeutet, dass bfloat16 etwa 9x weniger Speicherplatz als FP32 benötigt! Und bei float8 mit 3 Mantissenbits, also 3^2 + 4 Exponenten = 13, ist das 41x weniger Speicherplatz als FP32!
Schließlich hat float4 1 Mantissenbit und 2 Exponenten, also 3 Speicherplatz – satte 179x weniger Speicherplatz als FP32 – das bedeutet im Wesentlichen ein **GPU kann etwa 179x mehr FP4-Matrixmultiplikationen als FP32-Multiplikations-FLOPs im selben Raum ausführen**!
{% endcolumn %}
{% column width="50%" %}
{% endcolumn %}
{% endcolumns %}
### NVFP4 vs. MXFP4
Es gibt ein weiteres FP4-Format namens MXFP4 – es ist aufgrund von 2 Dingen ungenauer als NVFP4:
1. NVFP4 verwendet eine Blockgröße von 16 statt 32 bei MXFP4 – dadurch können Ausreißer leichter isoliert werden, und Skalierungsfaktoren werden für kleinere Gewichtsuntermengen bereitgestellt, was die Genauigkeit erhöht
2. Pro Block wird eine E4M3-(FP8)-Skalierung statt einer E8M0-(Potenzen-von-2-Skalierung) verwendet. Die Verwendung einer Blockgröße vom Typ FP8 scheint insbesondere für LLMs viel besser zu sein.
### 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 aus **2,5x schneller** auf **24 GB VRAM** und Qwen3.6-35B-A3B **1,7x schneller** auf **32 GB VRAM**. Wir haben außerdem **FP8-KV-Cache-Kalibrierung** für doppelt so lange Kontextlängen! NVFP4 erfordert NVIDIA-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 Ausführungen. Höhere Parallelität kann 35B auf 17.561 Tokens/s beschleunigen. Wir haben gerade auch 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) die ein vollständiges W4A4-Quant ist – 1,79x schneller
* [Qwen3.6-35B-A3B-NVFP4](https://huggingface.co/unsloth/Qwen3.6-35B-A3B-NVFP4) die 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) |
**MTP-Tensoren sind ebenfalls direkt in die Quants eingebaut, um zusätzliche Geschwindigkeitssteigerungen zu ermöglichen.** Die Genauigkeitsgewinne stammen aus Verbesserungen am Chat-Template und an der Datensatzkalibrierung von Qwen3.6. Wir verwenden unsere früheren Aktualisierungen des Chat-Templates, um die Konsistenz bei Coding und Tool-Calling zu verbessern und gleichzeitig Schleifen und 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 Dekodiergeschwindigkeit (Tokens pro Person) ist unseres bei 27B 1,03x schneller und bei 35B 1,17x bzw. 1,22x schneller.
### Überblick
Unten sind die Hardwareanforderungen für Modelle, die Sie verwenden können, einschließlich Gemma 4 und Qwen3.6. Sehen Sie auch den gesamten Geschwindigkeitszuwachs, den Sie erreichen werden:
#### 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 Versionen, die W4A16 verwenden. Wir quantisieren zudem Schichten dynamisch, um die Genauigkeit zu erhalten, und 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 denken, was den Zweck ihrer Quantisierung zunichtemachen würde! (Wenn es z. B. 2x schneller ist, aber 2x mehr denkt, dann ist das nutzlos)
## **NVFP4-Tutorials ausführen**
Um NVFP4-Quants auszuführen, sehen Sie unten die Befehle zum Ausführen von 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). 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
```
Ändere `unsloth/Qwen3.6-35B-A3B-NVFP4-Fast` zu den NVFP4-Quantnamen hinzu!
Um MTP / spekulatives Decoding 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 unbedingt Folgendes 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 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 nicht verfügbar: die Bereitstellung würde auf marlin W4A16 zurückfallen'"
```
{% endcode %}
was nicht fehlschlagen sollte – wenn doch, aktualisieren Sie bitte vllm oder installieren Sie 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 du Torchcodec-Probleme bekommst, führe unbedingt Folgendes 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:**
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 bei der Bereitstellung von 128 gleichzeitigen Personen auf 1x B200 gegenüber BF16 höchstens einen 1,44x Durchsatzgewinn erzielt. 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 – das Aktivieren führt zu einer 2,5x Leistungseinbuße – also verwenden Sie 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` oder Sie erhalten eine 2,5x langsamere Inferenz.
**Also kein Backend festlegen – vLLM wählt automatisch das beste aus.**
| Modell | Schema | Backend | Decode Tok/s | Durchsatz Tok/s |
| --------------- | ------ | -------------------------- | ------------ | --------------- |
| nvidia 27B | W4A16 | marlin (automatisch) | 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 (automatisch)** | 125.9 | **6,863** |
| nvidia 35B-A3B | W4A4 | marlin (automatisch) | 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 (automatisch)** | 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
.png?alt=media&token=9178447f-d5ae-4489-9bdc-73b2b7b1631b)
