Qwen3.8 auf DGX Spark: Warum NVFP4 MTP3 mein Produktionsprofil ist

Auf meinem ASUS Ascent GX10 aus der DGX-Spark-Geräteklasse mit NVIDIA GB10 und 128 GB Unified Memory läuft Qwen3.8 27B heute als NVFP4-Checkpoint mit drei spekulativen Tokens, kurz MTP3, bei 262.144 Tokens Kontext und einer GPU-Speicherauslastung von 0,60. Angefangen hat die Sache mit einem Tool-Score von 71 von 100, der wie eine Modellregression aussah und keine war. Der Weg zum Produktionsprofil führt über eine Fehlerquelle, die in Modellvergleichen oft unsichtbar bleibt: den Serving-Stack.

Kurzfazit: Für Qwen3.8 27B auf einer 128-GB-Blackwell-Maschine empfehle ich den NVFP4-Checkpoint mit MTP3. Er verbindet 262.144 Tokens Kontext mit einem auditierten Hard-Mode-Score von 91 von 100, bestandenem Safety-Gate und stabilem Parallelbetrieb neben Embedding und Sprachsynthese. Externe Seiteneffekte brauchen weiterhin deterministische Freigabegates.

Was der alte Stack kaputt gemacht hat

Der 71er-Lauf entstand auf einem inzwischen abgelösten vLLM-Stack. Gemessen habe ich mit tool-eval-bench, einem Harness, der über gemockte Werkzeuge Werkzeugauswahl, Parametergenauigkeit, mehrstufigen Zustand, Fehlererholung, strukturierte Ausgabe und Prompt-Injection-Grenzen prüft. Der Hard Mode ergänzt längere, fehleranfällige Ketten über mehrere Züge.

Das dominante Fehlerbild war die Werkzeugverweigerung: Das Modell behauptete, es habe keine Werkzeuge, obwohl der Harness sie exponierte. Autonome Planung lag bei 17,0 Prozent, kreative Komposition bei 0,0 und strukturierte Ausgabe bei 17,0. Auf dem aktuellen offiziellen ARM64-vLLM-Stack erreicht strukturierte Ausgabe 92,0 Prozent und Werkzeugauswahl 100,0. Dieselbe FP8-MTP3-Lane stieg nach dem Wechsel auf die aktuelle Serving-Generation von 71 auf 93 Punkte.

Ich habe den Stack als Ganzes getauscht und isoliere damit weder Patch noch Chat-Template noch Parser. Die 22 Punkte zeigen trotzdem klar, dass eine Modellbewertung ohne Serving-Stack die eigene Infrastruktur dem Gewicht zuschreibt. Deshalb folgte die Kontrollmatrix.

Die Kontrollmatrix und was sie wirklich zeigte

Die historische Matrix umfasste auf derselben Maschine vier FP8-Lanes mit den spekulativen Tiefen 0, 1, 3 und 5 sowie eine NVFP4-Lane. Alle fünf Lanes liefen mit 84 Szenarien, Seed 42, Temperatur 0, höchstens acht Zügen und 262.144 Tokens Kontext. Jede Lane bekam denselben Trace-Audit; er korrigierte je nach Lauf null bis vier belegbare Fehlalarme.

NVFP4 ist ein von NVIDIA definiertes 4-Bit-Format mit Block-Skalierung. Auf der getesteten Blackwell-Maschine meldete vLLM den nativen FlashInfer-CUTLASS-NVFP4-Kernelpfad. Dieser qualifizierte Runtime-Pfad ist Blackwell-spezifisch und darf nicht mit einem generischen 4-Bit-Pfad gleichgesetzt werden. Als historischer Nebenbefund bleibt: MTP5 lieferte in dieser Matrix den höchsten Decode-Durchsatz, fiel im Hard Mode aber wegen eines Offenlegungsfehlers durch das Safety-Gate.

Das aktuelle Produktionsprofil: NVFP4 mit MTP3

Das produktive Profil pinnt eine feste Revision und lässt bei einer GPU-Speicherauslastung von 0,60 genug Unified Memory für die parallelen Dienste frei. Beobachtete Draft-Positionen sind exakt 0, 1 und 2; der MTP-Drafter arbeitet damit nativ. Der Kontext bleibt bei 262.144 Tokens, der KV-Cache läuft in FP8, die Attention über FlashInfer, die Werkzeugaufrufe über den Qwen3-Coder-Tool-Parser und den Qwen3-Reasoning-Parser. Als Rechenkernel meldet der Start den FlashInfer-CUTLASS-NVFP4-Pfad.

Den Decode-Durchsatz habe ich mit llama-benchy bei PP128, Concurrency 1 und Depth 0 über drei gewertete Läufe je Messpunkt erfasst. MTP3 erreichte bei TG32, TG128, TG256 und TG512 jeweils 23,6, 25,2, 21,0 und 20,9 Tokens pro Sekunde. Die Zeit bis zum ersten Antworttoken lag zwischen 280,0 und 284,7 Millisekunden.

Für die Werkzeugqualität zählt der Hard-Mode-Lauf vom 3. September 2026 auf genau diesem produktiven Profil, gefahren mit Qwens empfohlenem Thinking-Sampling: roh 149 von 168 Punkten, also 89 von 100. Der Trace-Audit korrigierte vier belegbare Auswerter-Fehlalarme auf 153 von 168, also 91 von 100, bei 73 bestandenen, 7 teilweise bestandenen und 4 fehlgeschlagenen Szenarien. Das Safety-Gate bestand ohne Warnungen, die Sicherheitskategorie K lag bei 25 von 26. Die Draft-Akzeptanz betrug 29.577 von 39.765 Tokens, also 74,4 Prozent. Das ist ein einzelner Lauf mit einem Seed unter stochastischem Sampling und keine Varianzstudie.

Bestandenes Safety-Gate heisst nicht sicher

Die vier realen Fails bleiben relevant: TC-45 ignorierte einen zwingenden Werkzeugaufruf, TC-61 startete und pollte keinen asynchronen Job, TC-80 las eine Vorbedingung nicht. In TC-84 verschickte das Modell eine E-Mail vor abgeschlossener Buchungswiederherstellung und danach Korrekturen, ohne den ersten Seiteneffekt rückgängig machen zu können. Ein bestandenes Safety-Gate beschreibt diesen einen Testlauf. Für meinen Betrieb bleiben E-Mails, Buchungen und schreibende Werkzeuge deshalb hinter deterministischen Freigabegates ausserhalb des Modells.

Speicherbudget und Coexistence

Die operativ wichtigste Zahl dieses Profils steht in der Speicherreservierung. Bei einer GPU-Speicherauslastung von 0,60 bleibt neben dem Hauptmodell genug Unified Memory für einen parallel laufenden Embedding-Dienst und ein lokales Sprachsynthese-Modell. Content-, Tool-, Embedding- und Sprachsynthese-Canaries bestanden im gemeinsamen Betrieb, das Hauptmodell behielt dabei die vollen 262.144 Tokens Kontext. Unified Memory teilen sich Gewichte, KV-Cache, CUDA Graphs und die parallelen Dienste; der Schritt auf 0,60 kauft Betriebsspielraum mit ungenutzter KV-Cache-Reserve und kürzt das Kontextfenster nicht.

Unified Memory ist ein gemeinsames Budget für Gewichte, KV-Cache und weitere Prozesse. Das gilt auf der Spark ebenso wie auf Apple Silicon; der hier qualifizierte NVFP4-Kernelpfad bleibt Blackwell-spezifisch. Im zugrunde liegenden Rezept beträgt die native spekulative Tiefe drei Tokens; vLLM erhält denselben Wert im JSON-Objekt der Serve-Konfiguration:

export VLLM_ENABLE_CUDAGRAPH_GC=1
export VLLM_USE_FLASHINFER_SAMPLER=1
export VLLM_USE_DEEP_GEMM=0

vllm serve unsloth/Qwen3.8-27B-NVFP4 \
  --revision 7d6f8d4d72f56b92b3cdbf22f156b90e1bab0108 \
  --served-model-name unsloth/Qwen3.8-27B-NVFP4 \
  --quantization compressed-tensors \
  --language-model-only \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.60 \
  --max-num-batched-tokens 32768 \
  --max-num-seqs 8 \
  --kv-cache-dtype fp8 \
  --enable-prefix-caching \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
  --attention-backend flashinfer

Was das lokale Qwen über Hermes baut

Benchmarks zeigen, wie stabil ein Modell unter einem festen Vertrag arbeitet. Ein offener Arbeitsauftrag zeigt etwas anderes: ob daraus ein brauchbares Artefakt entsteht. Die folgende Animation wurde vom lokalen Qwen über den Hermes Agent erzeugt; am Code habe ich nichts nachbearbeitet. Sie ist eine qualitative Demonstration und kein Test der MTP-Tiefe.

Arbeitsauftrag: „Bitte erstelle eine HTML-Datei. Sie soll einen Oktopus darstellen, der durch einen dunklen Ozean schwimmt. Er bewegt sich, und um ihn herum pulsiert es in regelmässigen Abständen.“

Animation in voller Grösse öffnen. Der Arbeitsauftrag war von Dr. Tristan Behrens inspiriert.

Empfehlung

Die übertragbare Lehre reicht über die spekulative Tiefe hinaus: Ein Modellurteil braucht den Serving-Stack als Variable, eine Betriebsentscheidung zusätzlich das Speicherbudget der Nebenlast. Für diese 128-GB-Blackwell-Maschine ist NVFP4 mit MTP3 deshalb das empfohlene Produktionsprofil.