- Published on
Qwen3.8-27B auf DGX Spark: NVFP4-Quantisierung bringt 34–38 Tokens pro Sekunde — und spart 25 % Speicher
- Authors

- Name
- Phillip Pham
- @ddppham
Qwen3.8-27B auf dem DGX Spark: Was die Community gerade herausholt
Der NVIDIA DGX Spark ist 2026 das heißeste Thema für lokale KI im Mittelstand. Doch die Frage war lange: Welche Modelle laufen dort wirklich schnell? Ein 27B-Modell mit 20–27 Tokens pro Sekunde ist für den Produktiveinsatz zäh.
In dieser Woche hat sich das geändert. Mehrere viel beachtete Threads im NVIDIA-Forum zeigen, dass Qwen3.8-27B mit NVFP4-Quantisierung und dem SGLang-Inference-Server 34–38 Tokens pro Sekunde erreicht — das heiße Setup kommt als One-Command-Installer daher und hat innerhalb weniger Tage 11.000+ Aufrufe und 90 Antworten gesammelt.
Für IT-Entscheider ist das relevant: Ein 27B-Modell in „gut nutzbarer" Geschwindigkeit auf einem Deskside-Gerät für ca. 3.200–3.999 EUR bedeutet echte lokale KI ohne Cloud-Kosten — datenschutzkonform, ohne laufende Token-Gebühren.
Was ist NVFP4 und warum ist es auf dem GB10 so wichtig?
NVFP4 ist eine 4-Bit-Quantisierung, die NVIDIA für die Blackwell-Architektur (SM121, Compute Capability 12.1) eingeführt hat. Das Besondere am Setup, das die Community nutzt:
| Baustein | Wert |
|---|---|
| Modell | Qwen3.8-27B (Open-Weight, 27 Mrd. Parameter) |
| Quantisierung NVFP4 | 4-Bit MLP + 8-Bit Attention + FP8 KV-Cache |
| Modellgröße NVFP4 | ca. 23,4 GB (statt 30,9 GB bei FP8) |
| Inference-Server | SGLang oder vLLM |
| Beschleuniger | DSpark (block-speculative Decoding), basierend auf DeepSeeks Methode |
Der GB10-Chip ist bei der Decodierung bandbreiten-gebunden: Mit effektiv rund 225 GB/s und ca. 20 GB Speicherzugriff pro Schritt ist die Speicherbandbreite der Flaschenhals — nicht die Rechenleistung. Jede Speichereinsparung (kleinere Quantisierung) wirkt daher direkt auf die Token-Geschwindigkeit. Genau hier greift NVFP4.
Die Zahlen: NVFP4 vs. FP8 im direkten Vergleich
Ein Community-Benchmark mit vLLM 0.27.1 und 16 parallelen Anfragen auf einem einzelnen DGX Spark vergleicht die offizielle FP8-Version (Qwen/Qwen3.8-27B-FP8) mit dem NVFP4-Modell (unsloth/Qwen3.8-27B-NVFP4):
| Szenario | FP8 (tok/s) | NVFP4 (tok/s) | Vorteil NVFP4 |
|---|---|---|---|
| Prompt-lastig (8k → 1k) | 65,6 | 87,9 (Peak 128) | +34 % |
| Decode-lastig (1k → 8k) | 99,5 | 132,1 (Peak 144) | +33 % |
| Ausgeglichen (1k → 1k) | 104,4 | 134,4 (Peak 144) | +29 % |
Zusätzlich:
- Modellgröße: 30,9 GB → 23,4 GB (ca. 25 % weniger Speicher)
- KV-Cache-Nutzung im Decode-Szenario: ~15 % → ~5,6 %
- Time-to-First-Token (prompt-lastig): 36,9 s → 29,8 s
Für den Einzelnutzer-Dialog („batch 1", also genau ein User an der Oberfläche) ist das Maß der Dinge die reale Token-Rate. Hier misst die Community:
| Setup | Token/s (realistisch) |
|---|---|
| llama.cpp UD-Q4_K_XL + MTP | ~27 |
| vLLM 0.27 NVFP4 + MTP | ~24,5 |
| SGLang + NVFP4 + DSpark | ~34 (eval-lastig 38, Peak 46,7) |
Die Qualität bleibt nach Angaben der Tester gleich: NVFP4 ist ein W4A4-Checkpoint mit derselben Quantisierungsbasis wie andere Konfigurationen, DSpark ist verlustfrei (block-speculative Decoding) — verifiziert gegen ein Q8-Referenzmodell.
Praktisches Setup: Was der One-Command-Installer liefert
Der veröffentlichte Open-Source-Installer (git clone + ./install.sh) packt das validierte Setup in ein Systemd-fähiges Paket:
- systemd-Service: startet beim Boot, übersteht Stromausfälle
- OpenAI- und Anthropic-kompatible Endpoints — Claude Code funktioniert out of the box (drei bekannte Integrationsfehler sind vorgefixt)
- Gepinnte Docker-Digests und HF-Revisionen: funktioniert auch in Monaten noch reproduzierbar
- Benchmark-Skript (
./bench.sh) zur Verifikation auf der eigenen Hardware
Die wichtigste Warnung aus der Community
Die klarste Erkenntnis aus den Threads für alle, die es selbst nachbauen: SGLang nicht nativ auf dem GB10 betreiben. Das Speicher-Management von SGLang sieht die 25–40 GB transienten Allokationen (flashinfer-Autotuner, CUDA-Graph-Capture) im Unified Memory nicht — mehrere Nutzer haben das Gerät damit komplett eingefroren („hard freeze", nur Power-Cycle half).
Lösung: alles in einen speicher-gedeckelten Container packen und --mem-fraction-static 0.50 setzen. Das reproduziert die dokumentierten 34–38 tok/s ohne Absturz. Diese Details sind genau die Art Stolpersteine, die ein KI-Pilotprojekt verlängern — oder eben mit der dokumentierten Vorgehensweise ersparen.
Was das für den Mittelstand bedeutet
- 27B-Modelle sind lokal nutzbar geworden. Mit 34–38 tok/s eignet sich Qwen3.8-27B für Chat-Bots, Dokumentanalyse und Agenten-Setups auf einem Gerät, das in ein Büro-Rack oder unter den Schreibtisch passt.
- NVFP4 wird zum Standard für GB10. Die Kombination aus kleinerer Modellgröße, weniger KV-Cache und höherem Durchsatz macht NVFP4 gegenüber FP8 zur ersten Wahl auf dem Spark. Das vLLM-vs-SGLang-Umfeld sortiert sich entsprechend.
- Kostenrechnung ändert sich. Ein lokaler KI-Server mit einem 27B-Modell ersetzt für viele Anwendungen Cloud-APIs — ohne laufende Token-Gebühren und ohne Datenabfluss ins Ausland.
- Die Software-Lage bessert sich. Wer die Software-Realität des Spark kennt, profitiert jetzt von ausgereiften Rezepten: Container first, Versionen pinnen, Setup-Startpakete nutzen.
Für wen sich das Setup lohnt
Lohnt sich, wenn:
- Sie ein 27B-Modell für Chat, Dokument-RAG oder Coding-Agenten lokal betreiben wollen
- DSGVO-Konformität und Datenhoheit zählen (On-Premise statt Cloud)
- Sie ohnehin mit SGLang oder vLLM in Containern arbeiten
Weniger relevant, wenn:
- Sie viele parallele Nutzer bedienen müssen — dann skalieren Multi-GPU-Server oder GPU-Mietmodelle besser
- Ihre Workloads extrem lange Kontexte brauchen — dann das 1M-Kontext-Setup prüfen
- Sie 70B+ Modelle benötigen — dafür ist der Spark weiterhin die Speicheroption, aber langsamer
Fazit: Die „gute genug"-Schwelle ist erreicht
Mit Qwen3.8-27B + NVFP4 + SGLang hat der DGX Spark 2026 die Schwelle zur praktischen Nutzbarkeit für den Mittelstand überschritten: 34–38 tok/s, 23 GB Modell, ein Gerät, kein Cloud-Abo. Die Community-Benchmarks sind offen, reproduzierbar und werden aktiv weitergetrieben (Quantisierungs-, Speculative-Decoding- und TP/DP-Studien laufen bereits).
Wer lokale KI plant, sollte dieses Setup in die Hardware-Auswahl einbeziehen — und mit einem Speicher-/VRAM-Check gegenrechnen, ob ein einzelner Spark reicht oder ein Cluster nötig wird.
Sie prüfen, ob ein DGX Spark mit einem 27B-Modell Ihre Anforderungen erfüllt — oder ob ein klassischer GPU-Server die wirtschaftlichere Wahl ist? Sprechen Sie uns an — wir bewerten unabhängig von Anbietern.
Häufige Fragen
Was ist NVFP4-Quantisierung?
NVFP4 ist eine 4-Bit-Quantisierung für NVIDIA-Blackwell-Chips (SM121): MLP-Schichten 4-Bit, Attention 8-Bit, KV-Cache FP8. Auf dem GB10 verkleinert sie das Modell (30,9 → 23,4 GB bei Qwen3.8-27B) und erhöht den Durchsatz, weil die Decodierung speicherbandbreiten-gebunden ist.
Wie viel schneller ist NVFP4 als FP8 auf dem DGX Spark?
Je nach Workload rund 29–34 % mehr Tokens pro Sekunde bei gleicher Hardware (vLLM, 16 parallele Requests). Im Einzelnutzer-Dialog erreicht SGLang + NVFP4 + DSpark 34–38 tok/s gegenüber ca. 24–27 tok/s mit llama.cpp/vLLM.
Ist die Qualität bei NVFP4 schlechter?
Nach Community-Verifikation nein: Der NVFP4-Checkpoint liegt auf derselben Quantisierungsbasis wie andere W4A4-Konfigurationen, und DSpark (block-speculative Decoding) ist verlustfrei — verifiziert gegen ein Q8-Referenzmodell.
Warum sollte man SGLang auf dem GB10 nicht nativ betreiben?
SGLangs Speicher-Buchführung sieht die transienten Allokationen (25–40 GB) im Unified Memory nicht und kann das Gerät einfrieren. Empfohlen ist ein speicher-gedeckelter Container mit --mem-fraction-static 0.50.
Quellen & Weiterführende Links
- NVIDIA Developer Forum: Qwen3.8-27B at 34–38 tok/s on DGX Spark — open-source one-command setup (SGLang + NVFP4 + DSpark) ↗
- NVIDIA Developer Forum: Qwen3.8-27B on DGX Spark using vLLM: NVFP4 vs FP8 performance ↗
- NVIDIA Developer Forum: Qwen3.8-27B-NVFP4 on a single DGX Spark — up to 1M context, vLLM+MTP measurements ↗
- NVIDIA Developer Forum: Comprehensive Qwen3.8-27B Study on DGX Sparks — Quantization, Speculative Decoding, TP/DP Scaling ↗
- GitHub: hasso5703/dgx-spark-qwen38 — one-command SGLang + NVFP4 + DSpark setup ↗
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
DGX-Spark-Cluster managen: Open-Source-Control-Plane (DGX Manager) — Deployment, Fine-Tuning & Monitoring ohne Cloud
Wer mehrere DGX Spark (GB10) zu einem Cluster verbindet, steht vor einem Verwaltungsproblem: Deployment, Load-Balancing, Fine-Tuning und GPU-Telemetrie. Die NVIDIA-Community baut gerade Open-Source-Control-Planes wie DGX Manager — ein Web-Dashboard, das alles auf eigener Hardware erledigt. Was Mittelständler jetzt wissen müssen.
DGX Spark Software-Realität: CUDA-, Treiber- und Ökosystem-Probleme — was Sie vor dem Kauf wissen müssen
Der NVIDIA DGX Spark begeistert mit 128 GB Unified Memory — aber die Community berichtet offen über schwache CUDA- und Treiber-Kompatibilität. Was Mittelständler über die Software-Realität wissen müssen, bevor sie 3.200 EUR investieren.
NVIDIA DGX Spark: Der lokale KI-Supercomputer für den Mittelstand
NVIDIA DGX Spark (GB10): Der persönliche KI-Supercomputer mit 128 GB Unified Memory für den Mittelstand. Was er kann, was er kostet und wo die Grenzen liegen.
Bereit für KI im Mittelstand?
Nutzen Sie unsere 10 kostenlosen KI-Tools und Praxis-Guides – oder sprechen Sie direkt mit unseren Experten.
Pexon Consulting – KI-Beratung für den Mittelstand | Scaly Academy – Geförderte KI-Weiterbildung (KI-Spezialist, KI-Experte, Workflow-Automatisierung)