Published on

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

Authors

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:

BausteinWert
ModellQwen3.8-27B (Open-Weight, 27 Mrd. Parameter)
Quantisierung NVFP44-Bit MLP + 8-Bit Attention + FP8 KV-Cache
Modellgröße NVFP4ca. 23,4 GB (statt 30,9 GB bei FP8)
Inference-ServerSGLang oder vLLM
BeschleunigerDSpark (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):

SzenarioFP8 (tok/s)NVFP4 (tok/s)Vorteil NVFP4
Prompt-lastig (8k → 1k)65,687,9 (Peak 128)+34 %
Decode-lastig (1k → 8k)99,5132,1 (Peak 144)+33 %
Ausgeglichen (1k → 1k)104,4134,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:

SetupToken/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:

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.

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen