Was ist MTP und warum spielt es eine Rolle?

Multi Token Prediction wird als kostenloser Geschwindigkeitstrick für lokale LLMs verkauft. Man legt in der Inference Engine einen Schalter um, und die Generierung wird um ein Viertel bis zum Dreifachen schneller, ohne Einbußen bei der Ausgabequalität. So weit stimmt das Versprechen. MTP hat beim Betrieb lokaler Modelle aber auch einen interessanten diagnostischen Aspekt: Wie groß der MTP-Gewinn bei einem bestimmten Modell ausfällt, misst direkt, wie stark dieses Modell ausgehungert war, bevor Sie MTP eingeschaltet haben. Und woran es ihm gefehlt hat, ist nicht Rechenleistung.

Der falsche Engpass

Autoregressive Generierung hat eine ziemlich verschwenderische innere Schleife. Um ein Token zu erzeugen, holt die Engine den gesamten Parametersatz des Modells aus dem VRAM durch die Recheneinheiten der GPU. Dann macht sie das für das nächste Token noch einmal, und für das übernächste. Die Rechenarbeit pro Token ist für eine moderne GPU trivial, die Datenbewegung nicht. Eine Spitzenkarte wie die 5090 schaufelt Speicher mit rund 1,8 Terabyte pro Sekunde; die Karten, auf denen die meisten Leute lokale Modelle betreiben, schaffen ein paar hundert Gigabyte. Bei diesen Raten verbringen die Recheneinheiten den Großteil jedes Generierungsschritts damit, auf die Gewichte zu warten. Das ist die eigentliche Grenze lokaler Inferenz. Nicht die FLOPS, sondern die Bandbreite.

Ein Drafter schlägt vor, ein Target prüft

MTP gehört zu einer Familie von Techniken namens Speculative Decoding, erstmals 2022 veröffentlicht, und das Überraschende daran ist: Niemand bringt dem großen Modell bei, mehrere Token auf einmal vorherzusagen. Das übernimmt stattdessen ein zweites, viel kleineres Modell. In der üblichen Terminologie heißt das kleine Modell Drafter, das große Target. Der Drafter prescht vor und schlägt nacheinander eine Handvoll Kandidaten-Token vor, was er sich leisten kann, weil er klein und schnell ist. Das Target prüft dann den ganzen Stapel in einem einzigen Forward Pass. Prüfen ist die billige Richtung: Während das Target die Entwürfe kontrolliert, erzeugt es zusätzlich ein eigenes Token, ein Durchlauf, der drei Draft-Token bestätigt, liefert also insgesamt vier Token. Wo das Target einem Entwurf widerspricht, gewinnt sein eigenes Token, und die Generierung setzt an dieser Stelle wieder an.

Der technische Erklärartikel von heise rechnet das an einem anschaulichen Beispiel vor: Bei einer Akzeptanzrate von fünf aus sechs liefern zwei Target-Durchläufe sieben verifizierte Token, aus nominell 10 Token pro Sekunde werden effektiv 35. Die Zahlen sind eher Illustration als Benchmark, aber das Muster stimmt. Die Technik entkoppelt Vorhersage und Prüfung und lässt beide in ihrem eigenen Tempo laufen. Wie oft der Drafter richtig rät, hängt vom Text ab. Wahrscheinliche Fortsetzungen fallen einem kleinen Modell leicht, und nichts hat wahrscheinlichere Fortsetzungen als Code, der Regeln folgt. Am schlechtesten lässt sich freie Prosa in einer morphologisch reichen Sprache vorhersagen.

Die Implementierungen unterscheiden sich darin, woher der Drafter kommt. Google trainiert einen integrierten Draft Head, der sich den Key-Value-Cache und die internen Aktivierungen mit dem Target teilt. Der Hersteller schreibt diesem Design mehr als eine Verdopplung der Geschwindigkeit zu; die Zahl stammt von Google selbst. Zu den Ansätzen aus der Community gehört EAGLE, und ein Preprint der UC San Diego nutzt ein kleines Diffusionsmodell als Drafter, weil Diffusionsarchitekturen von Haus aus mehrere Token pro Schritt ausgeben.

Die Prüfung verbraucht, was die Generierung verschwendet

Der Trick liegt in der Buchhaltung. Mehrere Token in einem Durchlauf zu prüfen kostet zusätzliche Rechenleistung, aber genau die liegt ohnehin brach. Der teure Teil, den kompletten Parametersatz über den Speicherbus zu schleppen, passiert einmal pro Durchlauf, egal wie viele Token am anderen Ende herauskommen. Rät der Draft Head gut, bringt eine Fahrt über den Bus mehrere Token statt einem. Wohlgemerkt: Hier wird nichts approximiert. Das Target bleibt Schiedsrichter über jedes akzeptierte Token, die Ausgabe ist also identisch mit dem, was Standard-Decoding liefern würde, ohne Präzisionsverlust. Aus dem Design folgt direkt eine Grenze. Der Drafter hilft nur bei der Generierung; das Verarbeiten des Prompts bleibt allein Sache des Targets, deshalb bringt MTP bei der Prompt-Verarbeitung nichts. Ansätze für spekulatives Parsing gibt es, sie stehen aber noch am Anfang. Darum bleibt der gemessene Verarbeitungsdurchsatz mit MTP gleich oder sinkt leicht.

Die Asymmetrie bei MoE

Dichte Modelle, die für jedes Token jeden Parameter aktivieren, profitieren am stärksten. Ein dichtes Modell mit 12 Milliarden Parametern, das auf einer Consumer-Karte mit 16 Gigabyte mit knapp über 21 Token pro Sekunde dahinkroch, kam in einem Test mit abgestimmtem MTP auf 74, also mehr als das Dreifache. Ein dichtes Modell mit 9 Milliarden Parametern verdoppelte sein Tempo. Mixture-of-Experts-Modelle legten weniger zu. Ein MoE-Modell mit 35 Milliarden Parametern, davon drei Milliarden aktiv, verbesserte sich auf derselben Karte um rund 70 Prozent, auf einer schnelleren um etwa 30 Prozent. Die dünn besetzte Aktivierung reduziert den Verkehr auf dem Speicherbus ohnehin schon, es gibt also weniger Mangel, den MTP lindern könnte. Dazu kommt bei MoE eine eigene Komplikation beim Drafting: Das Routing des Drafters kann bei einem anderen Experten landen, als das Target wählen würde, und das drückt die Akzeptanzraten. Der Gewinn schrumpft genau dort, wo sich der Engpass lockert.

Was ein einziger Schalter bringt

Die Zahlen oben stammen aus einem heise-Benchmark mit je einem Durchlauf pro Konfiguration: Auf zwei Consumer-GPUs, einer von AMD und einer von Nvidia, legte jedes getestete Modell um mindestens 25 Prozent zu. Die besten Fälle lagen über dem Faktor 3,5. Auf der schnelleren Karte stieg das dichte 12-Milliarden-Modell von 47 auf 171 Token pro Sekunde. Ein zweiter Benchmark, ebenfalls von heise, mittelte zehn Durchläufe pro Konfiguration und ergänzt zwei Einschränkungen, die der Einzeltest nicht zeigen konnte. Erstens hängt der Gewinn vom Inhalt ab: Coding-Prompts wurden je nach Engine um 73 bis 150 Prozent schneller, deutschsprachige Prosa auf denselben Modellen teils nur um 10 Prozent. Zweitens hängt der Gewinn vom Stack ab: Auf älterem Apple Silicon lag der gemessene Speedup nahe null, was sich auf Software zurückführen lässt, die für diese Hardware noch nicht optimiert ist. „MTP hilft immer“ stimmt also vielleicht nicht für jede Last, aber MTP hilft definitiv dort am meisten, wo der Drafter vorhersagen kann und die Software ausgereift ist.

An Stellschrauben gibt es so oder so wenige. In Llama.cpp sind es zwei Kommandozeilenparameter: Einer schaltet spekulatives MTP-Decoding ein, der andere begrenzt, wie viele Token der Draft Head pro Durchlauf vorschlägt. Das Optimum liegt je nach Modell zwischen zwei und sieben und wird durch Ausprobieren gefunden. vLLM bietet dieselben zwei Entscheidungen über seine Speculative Config an, und ein Llama.cpp-Fork, der auf dem Diffusions-Drafter aufbaut, setzt die Draft-Tiefe dynamisch und entfernt damit die letzte manuelle Stellschraube.

Lokale Agent-Schleifen

Der Generierungsdurchsatz ist die entscheidende Grenze für lokale Agent-Systeme. Eine Agent-Schleife ist keine Chat-Sitzung; sie verbrennt Token für Reasoning, Tool-Ausgaben, Wiederholungen und Selbstkorrektur, und jedes dieser Token liegt auf dem kritischen Pfad. Bei 21 Token pro Sekunde ist eine lokale Schleife eine Demo. Bei 74 wird sie langsam brauchbar, und weil die MTP-Gewinne bei vorhersagbarem Text am größten sind, passt das perfekt zu Code. Code ist schließlich der vorhersagbarste Text überhaupt. Die Arbeitslast, bei der MTP am besten abschneidet, nämlich strukturierte Ausgabe nach festen Regeln, ist genau die, die lokale Agent-Schleifen erzeugen. Insgesamt schließen lokale Open-Weight-Modelle zu größeren gehosteten Modellen auf, und bei Schleifen mit hohem Volumen kippt die Wirtschaftlichkeit in Richtung lokal. Wenn MTP auf Hardware, die man ohnehin schon besitzt, so einen Vorsprung verschafft, sieht das immer mehr nach einem Weg aus, den man gehen sollte.

Aus dem Englischen übersetzt: zum Originalbeitrag