Die Decode-Geschwindigkeit von Qwen3.8-Flash-Next mit MTP auf RTX-GPUs verdoppeln

Viele sagen, Qwen3.8-Flash-Next werde seinen Benchmark-Ergebnissen nicht gerecht. Im täglichen Einsatz neben Qwen3.8-27B verhält es sich anders, als dieser Ruf vermuten lässt. Für seine Größe verbraucht es nicht viele Denk-Tokens, tut ohne Widerrede, was man verlangt, behält in einer langen Sitzung den Faden und erinnert sich korrekt an früheren Verlauf. Verglichen mit DeepSeek V4 Flash 0731 ist es der angenehmere Alltagsassistent, und schnell macht man es zum Standardmodell.

Der einzige Kritikpunkt ist die Geschwindigkeit. Auf drei RTX 3090 plus einer RTX 3070 Ti liegt das Decoding bei etwa 30 Tokens pro Sekunde. Das ist ein langsames, gleichmäßiges Tröpfeln, und wer schnell tippt, ist schneller.

Es gibt eine bekannte Abhilfe, und sie heißt MTP (Multi-Token Prediction). Das ist die DeepSeek-Variante des spekulativen Decodings: Ein leichtgewichtiger Draft-Head, der an das Modell angeflanscht ist, schlägt mehrere kommende Tokens vor, und das vollständige Netz prüft sie nur noch. Prüfen kostet weit weniger als Erzeugen, sodass fünf Tokens in der Zeit entstehen können, die sonst eines braucht.

Der Haken: llama.cpp hat MTP für dieses Modell nicht gemergt. Nach viel Ausprobieren hat eine Kombination aus Gewichten, Fork und Flags den Durchsatz mit denselben Modelldateien, demselben Server und denselben vier GPUs ungefähr verdoppelt. Das Rezept folgt unten, danach geht es darum, warum die Auslieferung dieses Features so chaotisch verlaufen ist.

Die richtigen Gewichte besorgen

Für das Hauptmodell laden Sie den Q4_K_M-Build mit 4,27bpw aus dem GGUF-Repository von AtomicChat.

Dieser Quant wurde mit Blick auf MacBooks erstellt, er ist auf den Unified Memory von Apple Silicon zugeschnitten. Auf RTX-Karten läuft er trotzdem einwandfrei und braucht weniger VRAM als der vergleichbare Unsloth-Quant. Manchmal passt ein Build, der für ein Publikum geschnürt wurde, auch für ein anderes.

Das Repo enthält außerdem eine kleinere IQ4_XS-Variante mit 3,84bpw. Beide wurden getestet, und die kleinere ist deutlich schlechter. 0,4 Bit pro Gewicht zu sparen ist den Verlust nicht wert.

Der MTP-Head kommt als eigene Sidecar-Datei, die Sie im Sidecar-Ordner von Unsloth finden. Hier wurde der Q8_0-Head verwendet. Ist das VRAM knapp, funktioniert auch der Q4_K_M-Head.

Den Fork bauen

Der funktionierende Code liegt im Branch qwen4exp/mtp von danielhanchens llama.cpp-Fork. Unsloths eigene Dokumentation verweist auf denselben Branch, was verrät, wo dieses Feature derzeit wirklich zu Hause ist.

Es ist ein gewöhnlicher CMake-Build: Pakete installieren, Branch klonen, konfigurieren.

apt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
git clone --branch qwen4exp/mtp https://github.com/danielhanchen/llama.cpp
cmake llama.cpp -B llama.cpp/build \
    -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first \
    --target llama-cli llama-mtmd-cli llama-server llama-gguf-split

Den Server starten

Hier ein Startbefehl, der unverändert funktioniert. Er nutzt vier GPUs, ein Kontextfenster von 200K und einen MTP-Draft, der bis zu 5 Tokens pro Schritt vorschlagen kann.

CUDA_VISIBLE_DEVICES=0,1,2,3 llama-server \
  -m .../Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64-00001-of-00033.gguf \
  --alias Qwen3.8-Flash-Next \
  --jinja \
  -ngl 99 \
  -c 200000 \
  --split-mode layer \
  --tensor-split 0.9,0.22,1.0,0.75 \
  -fit off \
  --host 0.0.0.0 --port 8082 \
  --metrics \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.0 \
  --reasoning-format none \
  --reasoning-effort low \
  --parallel 1 \
  -md .../mtp-Qwen3.8-Flash-Next-Q8_0.gguf \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  --spec-type draft-mtp --spec-draft-n-max 5

Der Großteil der Beschleunigung geht auf eine Handvoll Flags zurück:

• --spec-type draft-mtp aktiviert den MTP-Draft-Head. Bis Upstream die Arbeit merged, kennt nur der Fork dieses Flag.
• --spec-draft-n-max 5 lässt den Draft bis zu fünf Tokens vorausraten. Mit diesem Modell war die Akzeptanzrate hoch genug, dass sich fünf lohnen.
• -md ... zeigt auf die Sidecar-Datei mit dem MTP-Head, weil der Haupt-Quant ihn nicht enthält.
• --parallel 1 ist nicht optional. Es gibt einen offenen Bug, bei dem MTP zusammen mit mehreren parallelen Slots Inhalte eines Gesprächs in ein anderes durchsickern lässt. Ein einziger Slot hält die Ausgabe sauber.
• --split-mode layer mit --tensor-split 0.9,0.22,1.0,0.75 verteilt die Layer auf vier ungleiche Karten: drei 3090 mit 24 GB und eine 3070 Ti mit 8 GB. Diese Verhältnisse wurden genau auf diese Mischung abgestimmt, rechnen Sie also damit, sie für Ihre Hardware anzupassen.
• -fit off sorgt dafür, dass llama.cpp genau das lädt, was Sie angeben, statt eigene Speicherentscheidungen zu treffen.

Was Sie bekommen

Auf dieser Maschine sah der Vorher-nachher-Vergleich so aus:

Before MTP    After MTP
Decode speed          ~30 t/s       60–80 t/s
Model weights         same          same
Server hardware       same          same
Quality               same          same
Total VRAM used       76GB          ~80 GB

Man spürt den Unterschied mehr, als man ihn misst. Bei 30 Tokens pro Sekunde schaut man einem Modell beim Tippen zu. Bei 60 bis 80 führt man ein Gespräch mit ihm. Dieselben Gewichte, dieselbe Kiste, derselbe Morgen, und die Ausgabequalität hat sich nicht verändert.

Alles mit mehr als 80 GB VRAM kann genau dieses Setup fahren und sollte denselben Zugewinn sehen.

Warum ist das noch nicht gemergt?

Weil Open Source manchmal schlecht ausgeht, selbst wenn der Code existiert.

MTP für Qwen3.8-Flash-Next ist kein ungelöstes Forschungsproblem. vLLM und SGLang unterstützten es vom ersten Tag an. Forks von llama.cpp liefern es aus, und Unsloth packt es in seine Desktop-App. Die Demo-Videos mit 170 Tokens pro Sekunde sind echt.

Im Upstream von llama.cpp haben fünf separate Pull Requests versucht, es unterzubringen, und keiner kam durch. Einer lag als Entwurf mit Merge-Konflikten herum und ohne ein einziges Review. Ein anderer wurde geschlossen, nachdem ein Beitragender fremden Code ohne Erlaubnis des Urhebers eingereicht hatte. Ein Maintainer erklärte, dass jemanden zu nennen nicht dasselbe ist, wie seine Zustimmung einzuholen, und seither ist die beste funktionierende Implementierung verwaist. Ein dritter, der sauberste von allen, wurde letzte Woche von seinem eigenen Autor geschlossen, mit dem Hinweis, dass es upstream derzeit nicht weiterverfolgt werde. Den festgefahrenen PR #27836 und den aufgegebenen PR #28610 können Sie selbst nachlesen.

Um diese PRs ranken sich drei harte Probleme. Das erste ist ein Streit über das GGUF-Format: drei konkurrierende Layouts dafür, wo der MTP-Head gespeichert wird. Das zweite ist der Korrektheitsfehler mit parallelen Slots, verfolgt in Issue #28286. Das dritte sind Backend-Regressionen, denn dasselbe Feature, das die Geschwindigkeit unter CUDA verdoppelt, ist unter Vulkan ein Verlustgeschäft.

Nichts davon macht die Maintainer zu Bösewichten. Ihre Regel lautet, dass der Hauptzweig nie den Produktionsserver von irgendwem kaputtmachen darf, und spekulatives Decoding auf einem Modell mit hybridem Zustand ist wohl der furchteinflößendste Diff, den man ihnen schicken kann. Trotzdem sind ein Feature, das funktioniert, und ein Feature, das ausgeliefert wird, zwei getrennte technische Artefakte, und der Abstand dazwischen misst sich in Wochen des Wartens.

Sollten Sie es ausprobieren?

Ein Nachmittag Bauen hat ein Modell für den täglichen Einsatz doppelt so schnell gemacht, und die Befehle oben sind das gesamte Rezept. Wenn Sie 80+ GB VRAM haben und ein Qwen3.8-Flash-Next, das Tokens nur tröpfeln lässt, lohnt sich der Aufwand. Unsloths eigener MTP-Leitfaden deckt die Herstellerseite ab.

Ob der Hauptzweig aufholt, weiß niemand. Die Voraussetzungen kommen nach und nach, das Format setzt sich, also wird vermutlich jemand die richtige Implementierung mit dem Segen ihrer Autoren in den richtigen Branch bringen. Bis dahin lebt die Speerspitze in Forks, also klonen Sie entsprechend.