MTP und DFlash: Wenn Software schneller wird als die nächste Grafikkarte

Ein lokales Sprachmodell auf einem Mac mit Apple Silicon erzeugt heute mit derselben Hardware doppelt so schnell Antworten wie noch vor wenigen Monaten. Die Beschleunigung kommt aus der Software, die das Modell ansteuert. Multi-Token Prediction (MTP) ist in Qwen 3.6 eingebaut, DFlash haben wir für Gemma 4 31B im eigenen Setup eingerichtet und vermessen. Beides liefert Faktor 2 mehr Tokens pro Sekunde, ohne dass die Antwortqualität leidet.

Warum das überhaupt geht

Der Engpass beim Sprachmodell auf lokaler Hardware liegt in der Speicherbandbreite. Die Rechenleistung moderner Chips bleibt dabei weitgehend ungenutzt. Für jedes neue Token muss der Chip die kompletten Modellgewichte einmal durchlesen. Bei einem 31-Milliarden-Parameter-Modell auf einem M5 Max mit 600 GB pro Sekunde Bandbreite dauert das rechnerisch knapp 50 Millisekunden, was rund 20 Tokens pro Sekunde entspricht. Diese Obergrenze gilt, solange das Modell ein Token nach dem anderen erzeugt.

MTP und DFlash drehen genau an dieser Stelle. Beide Verfahren sagen mehrere Tokens gleichzeitig vorher und prüfen sie mit einer einzigen Speicher-Durchquerung. Die Verfahren unterscheiden sich darin, wie sie diese Mehrfach-Vorhersage erzeugen, aber sie bauen auf demselben Prinzip auf. In der Fachsprache heißt das Speculative Decoding.

MTP bei Qwen 3.6: Der eingebaute Vorhersage-Kopf

Multi-Token Prediction ist die Variante, die Alibaba in Qwen 3.6 direkt ins Modell eingebaut hat. Statt nur eine Vorhersage für das nächste Token zu liefern, hat das Modell zusätzliche kleine Vorhersage-Köpfe, die parallel auch das übernächste, überübernächste und so weiter vorhersagen. Diese Vorhersagen werden dann in einem zweiten Durchgang vom eigentlichen Modell geprüft. Stimmen sie, sind sie umsonst dazugekommen, und der Durchsatz steigt.

Der Charme von MTP liegt darin, dass keine zweite Modelldatei nötig ist. Der Vorhersage-Kopf sitzt im selben Checkpoint, Inference-Frameworks wie llama.cpp und LM Studio aktivieren ihn über einen Schalter. Wir haben das bei Qwen 3.6 27B in unserer 8-Bit-Quantisierung gemessen und auf dem M5 Max rund 2× mehr Tokens pro Sekunde gesehen.

Eine Bedingung muss erfüllt sein. MTP funktioniert nur, wenn der Chip Bandwidth-Reserve hat. Bei einem 31-Milliarden-Parameter-Modell in BF16 (das volle 16-Bit-Format) belegt das normale Decoding bereits die komplette Speicherbandbreite des M5 Max. Spielraum für die parallele Verifikation bleibt dann nicht mehr, und der Speedup geht gegen null. Bei derselben Architektur in 8-Bit-Quantisierung halbiert sich die übertragene Datenmenge, und der freie Spielraum macht die Beschleunigung erst sichtbar. Wer auf lokaler Hardware den vollen Nutzen aus MTP ziehen will, kommt um eine Quantisierung von Q8 oder kleiner kaum herum.

MTP (Multi-Token Prediction)

Vorhersage-Kopf direkt im Modell, eine einzige Datei. Aktivierung per Schalter im Inference-Framework. Funktioniert sofort mit jeder Quantisierung, die das Modell ohnehin liefert. Bei uns für Qwen 3.6 27B in Q8 ungefähr 2× schneller auf dem M5 Max.

DFlash (Block Diffusion)

Separates Draft-Modell mit nur 0,5 Milliarden Parametern, das gleichzeitig einen kompletten Token-Block vorhersagt. Höhere Akzeptanzrate als klassisches Speculative Decoding. Bei uns für Gemma 4 31B in Q8 mit 2,29× gemessen.

DFlash bei Gemma 4: Das Diffusionsmodell als Draft

DFlash geht einen anderen Weg. Statt einen Vorhersage-Kopf ins Modell zu integrieren, trainiert das Team von z-lab ein kleines, separates Modell, das parallel einen ganzen Block von Tokens vorhersagt. Dieses Draft-Modell hat bei Gemma 4 nur 0,5 Milliarden Parameter, also rund 60-mal weniger als das eigentliche Gemma 4 31B. Das Draft nutzt dabei Block Diffusion statt klassischer autoregressiver Erzeugung. Es schlägt 16 Tokens auf einmal vor, und das große Modell verifiziert diese in einem einzigen Durchlauf.

Der Vorteil dieses Ansatzes liegt in der Akzeptanzrate. Bei klassischem Speculative Decoding mit einem normalen kleinen Sprachmodell als Draft werden im Schnitt 2-3 Tokens pro Block akzeptiert. DFlash erreicht durch das Diffusions-Training Akzeptanzlängen von 6-8 Tokens. Das übersetzt sich direkt in mehr nutzbaren Durchsatz.

Wir haben das eingebaut und gemessen. Auf dem M5 Max mit Gemma 4 31B in 8-Bit-Quantisierung gegen einen GSM8K-Datensatz mit 32 Beispielen ergibt sich folgendes Bild.

Ohne DFlash

15,63 Tokens pro Sekunde, Standard-Decoding über MLX. Das ist die Geschwindigkeit, mit der das Modell ein Token nach dem anderen erzeugt.

Mit DFlash

35,80 Tokens pro Sekunde, gleicher Chip, gleiches Modell, dasselbe Quantisierungsformat. Faktor 2,29 auf einer Aufgabe, die das Modell vorher schon konnte.

Akzeptanzlänge

6,89 Tokens pro Block im Schnitt. Das heißt, das große Modell verifiziert bei jedem Durchgang rund sieben vorhergesagte Tokens auf einmal.

Was wir bei der Qualität gefunden haben

Speculative Decoding ist mathematisch verlustfrei. Akzeptiert werden nur Tokens, die das große Modell ohnehin so erzeugt hätte. Trotzdem haben wir den Vergleich zwischen Baseline und DFlash auf fünf inhaltlich unterschiedlichen Anfragen geprüft, vom Mathematik-Problem über einen Code-Auftrag bis zur deutschen Erklärung eines Konzepts. In zwei der fünf Fälle war der Output Zeichen für Zeichen identisch. In den anderen drei gab es minimale Abweichungen, etwa “in one go” statt “in a single pass”. Das ist numerischer Drift durch unterschiedliche Reihenfolge der Gleitkomma-Operationen im Block-Forward-Pass, kein Qualitätsverlust. Inhaltlich blieben alle Antworten korrekt und gleichwertig.

Das ist relevant, weil ein schnelleres Modell mit schlechteren Antworten in einer Beratungssituation oder in einem produktiven Workflow wertlos wäre. Bei DFlash und MTP bleibt die Antwortqualität erhalten.

Hardware-Sparmaßnahme oder Investitionsverschiebung

Für Unternehmen, die gerade über lokale KI-Infrastruktur nachdenken, lohnt sich die Frage, wie viel Geschwindigkeit sich aus der vorhandenen Hardware herausholen lässt. Wer ohne MTP und DFlash plant, kalkuliert die Geräte gegen Modellgeschwindigkeiten, die in den nächsten Monaten überholt sein werden, ohne dass jemand neue Hardware kauft.

Ein 31B-Modell, das auf einem MacBook Pro M5 Max ohne MTP rund 15 Tokens pro Sekunde schafft, liegt mit DFlash bei 35 Tokens. Wer in dieser Phase Hardware ausschreibt, sollte die Frage nach unterstützten Inference-Verfahren mit aufnehmen, sonst beantwortet er die falsche Frage.

Hinweis zur Auswahl:

MTP und DFlash funktionieren nur in einem Inference-Framework, das sie aktiv unterstützt. Für MTP reicht aktuell llama.cpp ab Version 4.5 oder LM Studio in einer aktuellen Build. DFlash auf Apple Silicon ist über das MLX-Backend des z-lab-Projekts verfügbar. Wer auf Server-Hardware geht, hat zusätzlich vLLM und SGLang als Optionen. Bevor Sie sich auf ein Setup festlegen, prüfen Sie, ob das geplante Framework das gewählte Modell und die Beschleunigung tatsächlich kennt.

Wo die Grenze liegt

Beide Verfahren haben dieselbe Achillesferse. Sie brauchen freie Speicherbandbreite, die das normale Decoding nicht ohnehin schon belegt. Auf einem System, das am Bandbreiten-Limit läuft, bringt der zusätzliche parallele Verifikationsschritt nichts, weil er auf dieselben Daten warten muss wie der reguläre Pfad. Davon betroffen sind vor allem sehr große Dense-Modelle in voller Präzision sowie Hardware mit knapper Speicherbandbreite, etwa ältere Consumer-GPUs.

In unseren eigenen Messungen ist das deutlich geworden. Bei einem 31-Milliarden-Modell in BF16 auf dem M5 Max liegt der MTP-Speedup praktisch bei null. Dieselbe Architektur in Q8 liefert 2×. Wer also über MTP oder DFlash plant, muss die Quantisierung gleich mit planen. Die Kombination aus moderner Quantisierung (Q8 oder Q6) und Speculative Decoding ist die Konstellation, die den vollen Effekt bringt. Eine MoE-Architektur wie bei Qwen 3.6 35B-A3B hat einen weiteren Vorteil. Da pro Token ohnehin nur ein Bruchteil der Parameter aktiv ist, bleibt mehr Bandwidth-Reserve für die parallele Verifikation. Auf Cloud-Hardware wie H100-GPUs bringt DFlash bei diesen Modellen laut z-lab-Benchmarks 2,4-2,9×, bei Gemma 4 31B sogar bis 5,8× auf Mathematik-Aufgaben.

Was das praktisch heißt

Wer aktuell ein lokales KI-Setup plant oder bereits betreibt, sollte den eigenen Stand prüfen. Welche Modell-, Quantisierungs- und Framework-Kombination läuft heute, und unterstützt sie MTP oder DFlash für genau diese Konstellation. Wenn nicht, lohnt sich die Suche nach einer Alternative, die das kann.

Bei Qwen 3.6 27B in Q8 mit llama.cpp oder LM Studio funktioniert MTP nativ, der Schalter ist eine Zeile in der Konfiguration. Bei Gemma 4 31B auf Apple Silicon erfordert DFlash aktuell noch das Klonen des z-lab-Repositories und einen separaten Python-Pfad. Das ist machbar, aber kein Klick-Setup. Wir setzen es in Beratungsprojekten ein, in denen die Geschwindigkeit über die Akzeptanz des Modells entscheidet, etwa bei interaktiven Chatbots oder agentischen Workflows mit vielen Zwischenschritten.

Die Beschleunigung steckt aktuell in den Software-Veröffentlichungen, die nach dem Kauf des Geräts erscheinen. Wer diese Entwicklung in die Beschaffungsentscheidung einbezieht, holt aus jedem investierten Euro mehr Geschwindigkeit aus dem Gerät, das im Schrank ohnehin schon steht.