Multi-Token Prediction Tutorial: So beschleunigst du LLMs

Was ist Multi-Token Prediction?

Die meisten LLMs erzeugen Text Token für Token. Das Modell sagt das nächste Token voraus, fügt es zum Kontext hinzu und wiederholt den Prozess. Das ist zuverlässig, kann aber langsam sein, weil für jedes neue Token in der Regel ein weiterer Decoding-Schritt nötig ist.

Multi-Token Prediction ändert das, indem das Modell vorausblicken und mehrere künftige Tokens statt nur eines vorschlagen kann. Diese Vorschläge werden anschließend durch den Haupt-Decoding-Prozess überprüft. Sind die Vorhersagen korrekt, kann das Modell mehrere Tokens in einem Rutsch übernehmen. Ist ein Token falsch, fällt das Modell ab diesem Punkt auf den normalen Pfad zurück.

In der Praxis funktioniert MTP wie ein integrierter Entwurfs-Mechanismus. Das Modell skizziert einige wahrscheinliche nächste Tokens, prüft sie und behält die gültigen. Je mehr Entwurfs-Tokens akzeptiert werden, desto weniger vollständige Decoding-Schritte sind nötig – dadurch steigen Tokens pro Sekunde, ohne die Ausgabequalität zu verändern.

Kurz gesagt:

• Ohne MTP: Token 1 generieren → Token 2 generieren → Token 3 generieren
• Mit MTP: Mehrere Tokens vorentwerfen → verifizieren → gültige Tokens gemeinsam übernehmen

Deshalb fühlt sich lokale LLM-Inferenz mit MTP deutlich schneller an. Statt das Modell zu zwingen, in Minischritten voranzugehen, darf es immer dann sicher vorspringen, wenn seine Entwurfs-Vorhersagen korrekt sind. 

In Tools wie llama.cpp und vLLM-ähnlichen Implementierungen ist das eng mit dem speculative decoding verwandt, bei dem Entwurfs-Tokens nur akzeptiert werden, wenn sie mit der Ausgabe des Verifizierers übereinstimmen. 

1. RunPod-RTX-3090-Maschine einrichten

Für diesen Guide habe ich eine RunPod-GPU-Instanz mit einer RTX 3090 verwendet. Du kannst auch eine andere CUDA-fähige GPU nutzen, aber die Benchmark-Ergebnisse in diesem Tutorial basieren auf einer RTX-3090-Konfiguration.

Erstelle zunächst einen neuen RunPod-Pod und wähle eine RTX 3090 als GPU aus.

Bevor du den Pod startest, passe die Template-Einstellungen an:

• Erhöhe die Volume-Disk-Größe auf 100 GB

• Füge einen zusätzlichen HTTP-Port hinzu: 8910

• Füge eine Umgebungsvariable HF_TOKEN hinzu und setze sie auf deinen Hugging-Face-Access-Token. 

Der zusätzliche HTTP-Port ermöglicht dir, den llama.cpp-Server und das Web-UI im Browser zu erreichen. Der Hugging-Face-Token authentifiziert den Download und kann vor allem bei großen GGUF-Dateien den Download beschleunigen.

Nachdem du das Template aktualisiert hast, deploye den Pod. Sobald er läuft, warte, bis RunPod dir Zugriff auf die JupyterLab-Instanz gibt. Öffne JupyterLab und starte ein neues Terminal.

Installiere im Terminal die benötigten Systempakete:

apt update
apt install -y git cmake build-essential curl wget python3-pip

2. Repo klonen und auf den MTP-Branch wechseln

Wechsle als Nächstes in das Workspace-Verzeichnis, in dem wir llama.cpp installieren und bauen:

cd /workspace

Klonen des llama.cpp-Repos:

git clone --depth 1 https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

Die MTP-Änderungen werden derzeit über einen eigenen Pull Request in llama.cpp getestet. Daher holen wir diesen Branch und wechseln dorthin, um die neueste MTP-Implementierung zu nutzen, bevor sie in den Standard-Main-Build einfließt.

Hole den MTP-Branch lokal:

git fetch origin pull/22673/head:mtp-pr
git checkout mtp-pr

Damit wechselst du deinen lokalen llama.cpp-Build auf die MTP-fähige Version, die wir im weiteren Verlauf verwenden.

3. llama.cpp mit CUDA-Unterstützung bauen

Da du nun auf dem MTP-Branch bist, baue llama.cpp mit CUDA-Unterstützung. So kann das Modell die RTX 3090 nutzen statt auf der CPU zu inferieren.

Starte die CMake-Build-Konfiguration:

cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release

Kompiliere dann die zwei Targets, die wir brauchen:

cmake --build build --target llama-cli llama-server -j

Das baut:

• llama-cli für schnelle Tests in der Kommandozeile

• llama-server zum Starten eines OpenAI-kompatiblen Servers mit Browserzugriff

Kopiere nach Abschluss des Builds die llama-server-Binary in das Hauptverzeichnis von llama.cpp:

cp ./build/bin/llama-server ./llama-server

So lässt sich der Server im nächsten Schritt einfacher aus dem Projekt-Root starten.

4. Qwen3.6-27B-MTP-Modell herunterladen

Lade nun das Qwen3.6 27B MTP GGUF-Modell herunter, das wir für die Tests verwenden. Wir führen es erst ohne MTP aus und dann mit aktiviertem MTP, um den Geschwindigkeitsunterschied zu vergleichen.

Installiere zuerst die Hugging-Face-Download-Tools:

pip install -U "huggingface_hub[hf_xet]" hf-xet hf_transfer

Aktiviere dann schnellere Hugging-Face-Downloads:

export HF_HUB_ENABLE_HF_TRANSFER=1

Das beschleunigt große Modelldownloads, insbesondere bei GGUF-Dateien.

Erstelle jetzt ein eigenes Verzeichnis für das Modell:

mkdir -p /workspace/models/qwen3.6-mtp

Lade das Qwen3.6 27B MTP GGUF-Modell herunter:

hf download froggeric/Qwen3.6-27B-MTP-GGUF \
 Qwen3.6-27B-Q4_K_M-mtp.gguf \
 --local-dir /workspace/models/qwen3.6-mtp

Wenn dich Fine-Tuning von LLMs interessiert, schau dir mein Tutorial zum Fine-Tuning von Qwen3.6 auf einem medizinischen Q&A-Datensatz an.

5. Qwen3.6-27B ohne MTP ausführen

Jetzt kommt der Kern dieses Guides: Wir testen die Modellgeschwindigkeit vor und nach dem Aktivieren von MTP.

Zuerst führen wir das Modell ohne MTP aus. Das liefert uns eine saubere Baseline für den späteren Vergleich. Wir nutzen dasselbe Modell, dieselbe GPU, dieselbe Kontextgröße und dieselben Servereinstellungen. Die einzige wesentliche Änderung im nächsten Schritt ist das Aktivieren von MTP.

Wechsle zurück in das llama.cpp-Verzeichnis:

cd /workspace/llama.cpp

Starte den Server ohne MTP:

./llama-server \
-m "/workspace/models/qwen3.6-mtp/Qwen3.6-27B-Q4_K_M-mtp.gguf" \
--alias qwen3.6-27b-no-mtp \
--host 0.0.0.0 \
--port 8910 \
-ngl 99 \
-c 100000 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-b 2048 \
-ub 512 \
-t 8 \
-fa on \
--temp 0.7 \
--top-k 20 \
--top-p 0.95 \
--repeat-penalty 1.1 \
--metrics

Damit startest du einen OpenAI-kompatiblen llama.cpp-Server auf Port 8910.

Das Laden kann kurz dauern, da die Modellgewichte in den GPU-Speicher geladen werden. Sobald alles bereit ist, zeigt das Terminal an, dass der Server auf Port 8910 verfügbar ist.

Weil wir den Port beim Einrichten des RunPod-Templates freigegeben haben, musst du nichts weiter konfigurieren. Gehe zurück ins RunPod-Dashboard und klicke auf den Link zu Port 8910. Dadurch öffnet sich das llama.cpp Web-UI in deinem Browser – mit bereits geladenem lokalen Modell.

Von hier aus kannst du Prompts direkt im Browser testen, ähnlich wie in einer Chat-Oberfläche.

In meinem Baseline-Test lag die Generationsgeschwindigkeit ohne MTP bei rund 38,86 Tokens/Sek.. Selbst mit komplexeren Prompts blieb die Geschwindigkeit in einem ähnlichen Bereich. 

Für ein 27B-Modell auf einer RTX 3090 ist das bereits gut nutzbar – vor allem, wenn man bedenkt, dass diese GPU im Vergleich zu neueren Datacenter-Karten langsamer ist und weniger Speicher hat. 

6. Qwen3.6-27B mit aktiviertem MTP ausführen

Jetzt führen wir dasselbe Modell erneut aus – diesmal mit aktiviertem MTP.

Wechsle zum Terminal mit dem laufenden Server und stoppe ihn mit:

CTRL + C

Wichtig ist, dass wir weder Modell, GPU, Quantisierung noch die meisten Runtime-Settings ändern. Wir fügen nur zwei MTP-bezogene Flags hinzu:

--spec-type mtp
--spec-draft-n-max 3

Das erste Flag weist llama.cpp an, MTP-ähnliches speculative decoding zu verwenden. Das zweite Flag setzt die maximale Anzahl an Entwurfs-Tokens auf 3. Das bedeutet, das Modell kann bis zu drei zukünftige Tokens vor dem Verifizieren entwerfen.

Starte den Server nun mit aktiviertem MTP neu:

./llama-server \
-m "/workspace/models/qwen3.6-mtp/Qwen3.6-27B-Q4_K_M-mtp.gguf" \
--alias qwen3.6-27b-mtp \
--host 0.0.0.0 \
--port 8910 \
-ngl 99 \
-c 100000 \
--spec-type mtp \
--spec-draft-n-max 3 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-b 2048 \
-ub 512 \
-t 8 \
-fa on \
--temp 0.7 \
--top-k 20 \
--top-p 0.95 \
--repeat-penalty 1.1 \
--metrics

Sobald der Server bereit ist, aktualisiere die Browserseite. Falls die Seite nicht automatisch verbindet, schließe sie und öffne den Link zu Port 8910 erneut im RunPod-Dashboard. 

Teste das Modell jetzt wieder mit den gleichen Arten von Prompts.

Mit aktiviertem MTP stieg die Geschwindigkeit merklich. Bei einem einfachen Begrüßungs-Prompt erreichte das Modell etwa 65–67 Tokens/Sek.. Verglichen mit der Baseline von rund 38,86 Tokens/Sek. ist das eine deutliche Verbesserung – allein durch zwei zusätzliche CLI-Flags. 

Bei komplexeren Prompts, etwa beim Bau eines einfachen Spiels in Python, war die Geschwindigkeit etwas niedriger, aber immer noch deutlich schneller als ohne MTP. In diesem Test lag die Generationsrate bei etwa 56–61 Tokens/Sek. – ein starkes Ergebnis für ein 27B-Modell auf einer RTX 3090. 

Insgesamt verbesserte MTP Qwen3.6 27B von rund 38 Tokens/Sek. auf 65 Tokens/Sek. auf dem RunPod-RTX-3090-Setup. Das entspricht einem 1,71x-Speedup bzw. rund 71% mehr Durchsatz – ohne Hardwarewechsel oder kleineres Modell. 

7. Empfehlung: Weitere Beschleunigung mit TurboQuant

Der Benchmark in diesem Guide nutzt das originale MTP-Setup von llama.cpp – ohne TurboQuant, Custom-Patches oder andere Runtime-Optimierungen. So bleibt der Test einfach, reproduzierbar und fokussiert auf den Geschwindigkeitsgewinn allein durch MTP.

Um noch mehr Leistung herauszuholen, bietet sich als nächster Schritt die Kombination aus MTP und TurboQuant an. MTP steigert den Durchsatz, indem mehrere vorhergesagte Tokens angenommen werden können, während TurboQuant den KV-Cache-Druck während der Inferenz reduziert. 

Das ist besonders hilfreich bei größeren Modellen, langen Kontexten und GPUs wie der RTX 3090, bei denen Speicherbandbreite und VRAM schnell limitieren.

Deshalb berichten einige Ergebnisse aus der r/LocalLLaMA-Community von höheren Tokens/Sek. als in diesem Guide. Diese Setups kombinieren oft MTP mit TurboQuant, gepatchten Builds, anderen KV-Cache-Einstellungen oder schnelleren GPUs. Da dieses Tutorial auf einen sauberen MTP-only-Benchmark zielt, ist TurboQuant als nächstes Experiment zu verstehen – nicht als Teil des aktuellen Setups.

Abschlussgedanken 

Ich verfolge seit Kurzem die Posts in der LocalLLaMA-Reddit-Community und es ist beeindruckend, wie weit lokale LLM-Inferenz gekommen ist. Modelle wie Qwen3.6 27B laufen inzwischen als lokale Coding-Agents – sogar auf älteren GPUs mit begrenztem VRAM. Manche setzen Ähnliches auch auf dem Mac um, und die Ergebnisse sind wirklich stark.

Nach meinen eigenen MTP-Tests verstehe ich die Begeisterung. Mit demselben Modell und demselben RTX-3090-Setup stieg die Generationsgeschwindigkeit durch Multi-Token Prediction von rund 38 Tokens/Sek. auf 65 Tokens/Sek.. Das ist fast ein 2x-Speedup – ohne GPU-Upgrade oder kleineres Modell.

Dieser Guide setzt auf ein simples, reproduzierbares MTP-Setup mit llama.cpp, aber das ist erst der Anfang. Der nächste Schritt: bessere GGUF-Quantisierung, MTP, TurboQuant und feinere Runtime-Settings kombinieren, um die lokale Inferenz weiter zu beschleunigen.

Am spannendsten ist für mich, was das für lokale Coding-Agents bedeutet. Du kannst starke Modelle auf eigener Hardware laufen lassen, Kosten pro Anfrage senken, deinen Code privat halten und einen KI-Coding-Assistenten nutzen – ohne komplett von Internet-APIs abhängig zu sein. Lokale LLMs werden schneller, praktischer und deutlich nützlicher als noch vor Kurzem.