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

Ein lokales Sprachmodell auf einem Mac mit Apple Silicon antwortet heute auf derselben Hardware doppelt so schnell wie noch vor wenigen Monaten. Die Beschleunigung kommt aus der Software, die das Modell ausführt. Multi-Token Prediction, kurz MTP, steckt in Qwen 3.6 bereits drin. DFlash haben wir für Gemma 4 31B selbst eingerichtet und vermessen. Beides bringt doppelt so viele Token pro Sekunde, und die Antworten bleiben dieselben.

Warum das überhaupt geht

Der Engpass eines Sprachmodells auf lokaler Hardware ist die Speicherbandbreite, nicht die Rechenleistung. Für jedes neue Token liest der Chip die kompletten Modellgewichte einmal durch. Bei einem Modell mit 31 Milliarden Parametern auf einem M5 Max mit 600 GB pro Sekunde dauert das rechnerisch knapp 50 Millisekunden, also rund 20 Token pro Sekunde. Diese Grenze gilt, solange ein Token nach dem anderen entsteht.

Genau dort setzen MTP und DFlash an. Beide sagen mehrere Token gleichzeitig voraus und prüfen sie mit einem einzigen Durchgang durch den Speicher. Sie unterscheiden sich darin, wie diese Vorhersage entsteht. Im Fach heißt das Verfahren spekulatives Dekodieren.

Bei Qwen 3.6 sitzt der Vorhersagekopf im Modell

Multi-Token Prediction hat Alibaba direkt in Qwen 3.6 eingebaut. Statt nur das nächste Token vorherzusagen, hat das Modell zusätzliche kleine Köpfe, die daneben auch das übernächste und das darauf folgende vorschlagen. In einem zweiten Durchgang prüft das eigentliche Modell diese Vorschläge. Stimmen sie, sind sie ohne zusätzlichen Speicherdurchgang entstanden, und der Durchsatz steigt.

Der Vorteil liegt darin, dass keine zweite Modelldatei nötig ist. Der Vorhersagekopf steckt in derselben Datei, und die ausführende Software wie llama.cpp oder LM Studio schaltet ihn über eine Einstellung an. Wir haben Qwen 3.6 27B in unserer 8-Bit-Fassung auf dem M5 Max gemessen und rund doppelt so viele Token pro Sekunde gesehen.

Eine Bedingung gehört dazu. MTP greift nur, wenn Speicherbandbreite frei ist. Bei einem Modell mit 31 Milliarden Parametern in voller 16-Bit-Genauigkeit belegt schon der normale Betrieb die gesamte Bandbreite des M5 Max, für die parallele Prüfung bleibt nichts übrig, und die Beschleunigung geht gegen null. Dieselbe Architektur in 8 Bit überträgt die halbe Datenmenge, und erst der freie Rest macht den Effekt sichtbar. Wer MTP auf lokaler Hardware ausreizen will, kommt an einer Verkleinerung der Gewichte auf 8 Bit oder darunter kaum vorbei.

Bei Gemma 4 rechnet ein zweites, winziges Modell voraus

DFlash geht den anderen Weg. Statt eines Kopfes im Modell trainiert das Team von z-lab ein eigenes kleines Modell, das einen ganzen Block von Token auf einmal vorschlägt. Für Gemma 4 hat dieses Entwurfsmodell 0,5 Milliarden Parameter, also rund 60-mal weniger als Gemma 4 31B selbst. Es erzeugt seinen Vorschlag nicht Token für Token, sondern über ein Diffusionsverfahren als Block von 16 Token, und das große Modell prüft diesen Block in einem Durchlauf.

Der Unterschied zeigt sich in der Annahmequote. Beim klassischen spekulativen Dekodieren mit einem kleinen Sprachmodell als Entwurf werden im Schnitt 2 bis 3 Token je Block übernommen. DFlash kommt durch sein Diffusionstraining auf 6 bis 8. Das schlägt unmittelbar auf den Durchsatz durch.

Gemessen haben wir gegen 32 Beispiele aus dem GSM8K-Datensatz, einer Sammlung von Textaufgaben aus der Mathematik. Ohne DFlash kommt Gemma 4 31B über MLX auf 15,63 Token pro Sekunde. Mit DFlash sind es 35,80, bei gleichem Chip, gleichem Modell und gleicher Genauigkeit. Die Annahmequote lag bei 6,89 Token je Block, das große Modell bestätigt also bei jedem Durchgang rund 7 Vorhersagen auf einmal.

Was mit der Qualität passiert

Spekulatives Dekodieren ist rechnerisch verlustfrei. Übernommen wird nur, was das große Modell ohnehin erzeugt hätte. Wir haben trotzdem 5 inhaltlich verschiedene Anfragen gegeneinander laufen lassen, von einer Mathematikaufgabe über einen Programmierauftrag bis zur Erklärung eines Begriffs auf Deutsch. In 2 der 5 Fälle war die Ausgabe Zeichen für Zeichen dieselbe. In den 3 anderen gab es kleine Abweichungen im Wortlaut, etwa "in one go" statt "in a single pass". Diese Unterschiede stammen aus der geänderten Reihenfolge der Rechenschritte beim Prüfen des Blocks. Inhaltlich waren alle Antworten richtig und gleichwertig.

Das ist der Punkt, auf den es ankommt. Ein schnelleres Modell mit schlechteren Antworten wäre in einer Beratung oder in einem laufenden Ablauf wertlos.

Was das für eine Anschaffung bedeutet

Wer heute Hardware für lokale KI plant und dabei die Geschwindigkeit von vor einem halben Jahr zugrunde legt, rechnet mit Zahlen, die die Software inzwischen überholt hat. Ein Modell mit 31 Milliarden Parametern, das auf einem MacBook Pro M5 Max ohne MTP rund 15 Token pro Sekunde erzeugt, liegt mit DFlash bei 35. Wer in dieser Lage ein Gerät ausschreibt, nimmt die unterstützten Verfahren in die Ausschreibung mit auf.

Wo die Grenze liegt

Beide Verfahren stoßen an dieselbe Grenze. Sie brauchen Speicherbandbreite, die der normale Betrieb nicht schon verbraucht. Läuft ein System am Anschlag, wartet die zusätzliche Prüfung auf dieselben Daten wie der reguläre Weg, und der Gewinn verschwindet. Betroffen sind vor allem sehr große Modelle in voller Genauigkeit, die alle Parameter je Token durchrechnen, sowie Hardware mit knapper Bandbreite wie ältere Grafikkarten aus dem Handel.

Unsere eigenen Messungen zeigen das deutlich. Bei 31 Milliarden Parametern in 16 Bit liegt der Gewinn durch MTP auf dem M5 Max praktisch bei null, dieselbe Architektur in 8 Bit verdoppelt den Durchsatz. Wer mit MTP oder DFlash plant, plant deshalb die Verkleinerung der Gewichte gleich mit, und 8 oder 6 Bit zusammen mit spekulativem Dekodieren ist die Kombination, die den vollen Effekt bringt.

Eine Bauart wie bei Qwen 3.6 35B-A3B hat dabei einen zusätzlichen Vorteil. Weil dort je Token ohnehin nur ein Bruchteil der Parameter rechnet, bleibt mehr Bandbreite für die Prüfung frei. Auf Cloud-Hardware mit H100-Karten bringt DFlash bei solchen Modellen nach Messungen von z-lab das 2,4- bis 2,9-Fache, bei Gemma 4 31B auf Mathematikaufgaben bis zum 5,8-Fachen.

Was praktisch zu tun ist

Sieh nach, welche Kombination aus Modell, Genauigkeit und Software bei dir heute läuft, und ob sie MTP oder DFlash für genau diese Kombination unterstützt. Wenn nicht, lohnt der Wechsel zu einer Software, die es kann.

Bei Qwen 3.6 27B in 8 Bit mit llama.cpp oder LM Studio ist MTP eine Zeile in der Konfiguration. Für Gemma 4 31B auf Apple Silicon musst du derzeit noch das Repository von z-lab holen und einen eigenen Python-Pfad einrichten. Das ist zu schaffen, aber keine Installation mit einem Klick. Wir setzen es in Projekten ein, in denen die Geschwindigkeit darüber entscheidet, ob die Leute das Modell benutzen, also bei Chatoberflächen und bei Abläufen mit vielen Zwischenschritten.

Die Beschleunigung kommt aus den Software-Veröffentlichungen, die nach dem Kauf des Geräts erscheinen. Wer das in die Beschaffung einbezieht, holt mehr aus dem Rechner heraus, der ohnehin schon dasteht.