Qwen auf dem DGX Spark optimieren: 20 Prozent mehr Durchsatz mit MTP1

Seit einigen Wochen ist Qwen3.6-35B-A3B-FP8 mein lokaler Daily Driver auf der NVIDIA DGX Spark. Es übernimmt agentische Aufgaben, liefert strukturierte Ausgaben und arbeitet stabil mit Tools. Ich wollte wissen, ob im Serving noch Leistung steckt, ohne Checkpoint oder Agentenvertrag zu wechseln.

Im Lab fror ich Checkpoint, Hardware und Messprotokoll ein. Dann änderte ich das Recipe Schritt für Schritt und prüfte jeweils Durchsatz, Toolcalls, Strict JSON und reale Textaufgaben. Der schnellste Kandidat schaffte fast 80 Prozent mehr Tokens pro Sekunde, fiel aber im Tool-Eval durch. MTP1 war am Ende besser.

Unter vLLM stieg der TG128-Durchsatz im gleichen Benchy-Protokoll von 53.8 auf 64.6 tok/s: 20.0 Prozent mehr für Decode-lastige Agentenanfragen. Die Time-to-First-Response erhöhte sich von 112.7 auf 148.2 ms. Tool-Eval Short blieb bei 100 von 100, Hardmode bei 91 von 100; die Produktionsfixtures zeigten dennoch Grenzen. Die Kernfrage: Bleibt das System trotz höherem Durchsatz zuverlässig?

Der Messvertrag

Vor jeder Zahl steht das Protokoll. Die Kern-Ablation friert Checkpoint, Container, Hardware und Benchmark-Konfiguration ein; nur die Zahl der MTP-Draft-Tokens ändert sich. DFlash und NVFP4 stehen später bewusst als vollständige Alternativ-Recipes daneben, nicht als kausale Ein-Schalter-Tests.

Die Recipe-Matrix auf der DGX Spark

Fünf Serving-Varianten liefen auf derselben Maschine. Baseline, MTP1 und MTP2 bilden die direkt vergleichbare Kern-Ablation. DFlash ergänzt einen separaten Drafter und ändert unter anderem KV-Datentyp, Batchbudget und Concurrency; NVFP4/MTP3 wechselt zusätzlich Quantisierungsformat und Container. Benchmark-Hinweis: Diese beiden Alternativen sind nur eingeschränkt vergleichbar. Die Performancewerte stammen aus AISyndicate-eigenen Messungen vom Juli 2026. Die Qualitätswerte stammen aus Tool-Eval-Gates mit Native Reasoning. Sie zeigen den Agentenvertrag des jeweiligen Recipes, bilden wegen der zusätzlichen Stack-Unterschiede bei DFlash und NVFP4 aber kein striktes Qualitätsranking.

Decode-Durchsatz nach Output-Länge. Die durchgezogenen Linien bilden die direkte Same-Stack-Ablation; DFlash und NVFP4/MTP3 sind als eingeschränkt vergleichbare Alternativ-Recipes gestrichelt. Fehlerbalken bei TG128 zeigen ± σ aus drei Wiederholungen.

Die Tabelle zeigt Mittelwert und Standardabweichung aus je drei TG128-Läufen. Sie ist eine Recipe-Matrix auf einer Maschine, keine universelle Modellrangliste.

Baseline: Wo das Modell ohne MTP steht

Die FP8-Daily-Konfiguration serviert Qwen3.6-35B-A3B-FP8 im nativen 262-K-Kontext ohne Speculative Decoding. Über die vier Output-Längen bleibt sie nahezu flach bei rund 53.8 tok/s; die Einzelwerte stehen in der Matrix. Die Time-to-First-Response von 112.7 ms bleibt für einen 35B-Checkpoint auf 128 GB Unified Memory sauber. Das ist der Referenzpunkt, an dem jede Optimierung gemessen wird. Alles, was schneller ist, muss diesen Vertrag halten oder verbessern; alles, was ihn bricht, ist keine Optimierung.

MTP1: Was Speculative Decoding im Qwen-Checkpoint auslöst

Multi-Token Prediction ist im offiziellen Qwen3.6-Checkpoint bereits nativ trainiert. Kein separates Draft-Modell, der Draft-Head sitzt im gleichen Checkpoint. In vLLM wird dafür die Speculative-Config mit der Methode MTP und einem Draft-Token aktiviert; das vollständige Kommando steht im Recipe weiter unten. Das Modell schlägt pro Schritt ein Draft-Token vor, das Target-Modell verifiziert es im gleichen Forward Pass. Bei hoher Akzeptanzrate spart das einen kompletten Decode-Schritt.

Auf dem TG128-Profil mit Auto-Backend springt der Durchsatz von 53.8 auf 63.1 tok/s. Über alle Output-Längen macht sich der Effekt bemerkbar, verliert aber mit steigender Sequenzlänge relativ an Kraft: TG32 legt am stärksten zu, TG512 am wenigsten. Das ist erwartbar. Speculative Decoding rechnet sich vor allem dann, wenn der Overhead pro Token gering im Verhältnis zur eingesparten Passzahl bleibt. Alle Messwerte in der folgenden Output-Matrix: AISyndicate-eigene Benchmarks, ASUS GX10 / DGX Spark, Juli 2026.

Für Agenten mit typischen Response-Längen zwischen 100 und 300 Tokens liegt der Sweetspot der MTP1-Ablation. Wer bevorzugt lange Berichte generiert, sieht schmalere Gewinne, aber immer noch spürbare zweistellige Prozent.

Ein zweiter Draft-Token verbessert diese Kurve nicht. MTP2 erreicht bei TG32 zwar 67.6 tok/s und liegt damit 2.6 Prozent vor MTP1. Bei TG128 fällt der Durchsatz jedoch auf 60.1 tok/s, 7.0 Prozent unter MTP1; bei TG256 bleibt er praktisch gleich und bei TG512 sinkt er um 4.9 Prozent. Gleichzeitig steigt die TTFR über alle vier Output-Längen um 20.4 bis 28.7 Prozent gegenüber MTP1. Tool-Eval Short bleibt mit 100 von 100 vollständig grün. Der Agentenvertrag hält; das Serving wird trotzdem schlechter. Das passt zur vLLM-Bootwarnung, dass die wiederholte Nutzung derselben MTP-Schicht die Akzeptanzrate senken kann. Wir haben sie nicht separat gemessen. Auf diesem Stack liegt der Sweetspot bei einem Draft-Token.

FlashInfer-Pinning ist Reproduzierbarkeitskontrolle, kein Wundergewinn

Hier lauert die häufigste Fehlinterpretation. vLLM hatte bereits im Auto-Modus FlashInfer gewählt. Der gepinnte Lauf liegt bei TG128 zwar 2.5 Prozent höher als MTP1-Auto (64.6 statt 63.1 tok/s), verliert aber bei TG256 und TG512 leicht. Das ist kein belastbarer zweiter Speedup. Der eigentliche Sprung kommt von MTP1; das Pinning fixiert vor allem die Backend-Identität gegen verschobene Defaults zwischen Container-Builds.

FlashInfer stellt paged Attention-Kernels wie BatchDecodeWithPagedKVCacheWrapper bereit. Auf der DGX Spark war es im Bootlog als aktives Attention-Backend sichtbar. Die 20 Prozent aus der Zielthese lassen sich FlashInfer nicht isoliert zuschreiben. Sie messen das Delta zwischen Baseline und dem finalen MTP1-Recipe. Der Pin macht diesen Runtimepfad reproduzierbar.

TTFR und Cold-Start: Der bewusste Trade-off

Speculative Decoding hat Kosten. Die Time-to-First-Response steigt von 112.7 ms auf 148.2 ms. Für Streaming-Chats ist das wahrnehmbar. In unserem agentischen Profil war der Preis akzeptabel, weil der höhere Decode-Durchsatz die Gesamtlatenz längerer Antworten senkt; für kurze Toolcalls kann die zusätzliche TTFR dagegen relevant bleiben.

Beim Cold-Start gab es zwei Beobachtungen, die zum Protokoll gehören. Zwei MTP-Kaltstarts zeigten beim ersten Versuch je einen fehlerhaften Strict-JSON-Response; ein sofortiger identischer Retry lieferte gültige Struktur. Der Produktions-Kaltstart mit dem promoted Recipe blieb beim ersten Versuch valide. Short- und Hardmode-Suiten reproduzierten den Fehler nicht. Die Stichprobe ist klein (n=2+1). Aus diesen drei Beobachtungen behandeln wir das als Varianzsignal beim allerersten Request nach Modell-Load ohne abschliessende Ursachenanalyse und dokumentieren es transparent statt es zu glätten.

Quality Gates: Warum DFlash rausgeflogen ist

DFlash und die zugehörige FlashQLA-Attention-Variante lieferten spektakuläre Rohzahlen: 102.7, 96.7, 86.3 und 69.8 tok/s über die vier Output-Längen. Das sind auf TG128 79.6 Prozent mehr Durchsatz als die Baseline. Wer nur Decode-Speed misst, würde den Kandidaten sofort promoten.

Wir messen agentisch: Tools wählen, Argumente strukturieren, Aufrufe fortsetzen, Fehler behandeln und Aktionen verweigern. Der Tool-Eval-Bench umfasst 15 Szenarien und 30 Punkte. Der Gewinner erreicht 100 von 100; DFlash dreimal 53 von 100, mit Strukturbrüchen und verstümmelten Tool-Argumenten.

Der mechanische Längenvertrag wurde als zeitnahes A/B mit drei Läufen pro FP8-Lane wiederholt. Die Pre-MTP-Baseline erreichte 22/24, MTP1 20/24 brauchbare Kurztexte; die Teaser bestanden beidseitig 24/24. Alle Fehler waren reine Längenüberschreitungen. Der kleine Baseline-Vorsprung ist ein Warnsignal, bei dieser Stichprobe aber kein Beleg für eine kausale oder deutliche MTP-Regression.

Die zweite Ebene ist redaktionell: In beiden FP8-Lanes fanden wir unbelegte technische oder kausale Details. Bei einem dünnen Input antwortete MTP1 häufiger selbstsicher, während die Baseline eher auf eine Antwort verzichtete. Das ist ein Richtungssignal, kein statistisch belegter Qualitätsverlust. Tool-Eval 100/100 bleibt stark, ersetzt aber weder Evidenzfilter noch Human Review.

NVFP4 erreichte auf demselben Acht-Fälle-Set in einem älteren Lauf 5/8. Weil Quantisierung, Container und Serving-Schalter gemeinsam wechselten, gehört dieser Wert nicht in das direkte FP8-A/B. Strukturiertes JSON-Scoring und quellengebundene Research-Note-Extraktion liefen ebenfalls auf mehreren Recipes; unterschiedliche Quelltextlängen verhindern dort ein reines Latenz-A/B.

NVFP4/MTP3 ist ein alternatives Recipe, kein A/B

Das NVIDIA-Recipe fährt NVFP4-Quantisierung mit drei Speculative-Tokens in einem anderen Container. TG128 liegt bei 114.0 tok/s, aber mit deutlich höherer Streuung als MTP1. Es ist kein isoliertes A/B: Quantisierungsformat, Container und weitere Serving-Schalter ändern sich gemeinsam. Tool-Eval Hardmode blieb mit 89 von 100 stark; in separaten produktionsnahen Tests waren kurze faktgebundene Texte jedoch weniger zuverlässig. Deshalb blieb das Recipe eine alternative Lane statt unseres Daily-Profils.

Hardware-Kompatibilität

Die Messwerte gelten nur für die getestete DGX Spark. Für andere Hardware trennt die folgende Matrix belastbare Aussagen von blosser Übertragbarkeit.

Das promoted Recipe

Das folgende YAML bildet den reproduzierbaren Serving-Vertrag hinter allen Zahlen im Text ab. Netzwerkadresse und Port sind bewusst generisch. Wer die Konfiguration auf einer DGX Spark mit vergleichbarer Systemlast fährt, sollte innerhalb der Streubreite unserer Wiederholungen landen.

recipe_version: "1"
name: qwen3.6-35b-a3b-fp8-256k-vllm-freshwheels-reasoning-c4-mtp1-flashinfer-pinned
description: Qwen3.6 FP8 256K MTP1 with explicitly pinned FlashInfer attention
model: Qwen/Qwen3.6-35B-A3B-FP8
solo_only: true
container: vllm-node-freshwheels-20260713

defaults:
  port: 8000
  host: 0.0.0.0
  served_model_name: Qwen/Qwen3.6-35B-A3B-FP8
  max_model_len: 262144
  gpu_memory_utilization: 0.70
  max_num_batched_tokens: 16384
  max_num_seqs: 4

env:
  VLLM_ENABLE_CUDAGRAPH_GC: 1
  VLLM_USE_FLASHINFER_SAMPLER: 1
  VLLM_USE_DEEP_GEMM: 0

command: |
  vllm serve Qwen/Qwen3.6-35B-A3B-FP8 \
    --served-model-name {served_model_name} \
    --quantization fp8 \
    --language-model-only \
    --max-model-len {max_model_len} \
    --gpu-memory-utilization {gpu_memory_utilization} \
    --max-num-batched-tokens {max_num_batched_tokens} \
    --max-num-seqs {max_num_seqs} \
    --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":1}' \
    --attention-backend flashinfer \
    --port {port} \
    --host {host}

Was bleibt

Serving-Recipes sind keine Feinschliffkosmetik; sie entscheiden, ob LLM-Inferenz auf lokaler Hardware sich für Agenten überhaupt lohnt. MTP1 liefert 20 Prozent mehr TG128-Durchsatz und hält die generischen Tool-Gates stabil. Die Produktionsfixtures zeigen zugleich: Längen- und Evidenzfilter sowie Human Review bleiben nötig. DFlash ist die drastische Warnung, MTP1 die brauchbare Optimierung mit Grenzen.

Das Recipe steht oben, viel Spaß beim Messen und Experimentieren!