MTP auf vLLM und llama.cpp: 3,34× schnellere Inferenz für Gemma 4 und Qwen 3.6
Der Reddit-Post von r/LocalLLaMA dokumentiert eine mehrwöchige Benchmark-Reihe zu Multi-Token Prediction (MTP), einem spekulativen Decoding-Verfahren, das inzwischen von mehreren großen KI-Laboren in ihre Inferenz-Stacks integriert wird. Getestet wurden zwei Modell-Engine-Kombinationen: Gemma 4 31B (RedHatAI FP8-Block-Quantisierung) unter vLLM sowie Qwen 3.6 27B sowohl als Q8_0-GGUF unter llama.cpp als auch als FP8-Variante unter vLLM. Die Hardware war eine NVIDIA RTX PRO 6000 Blackwell mit 96 GB VRAM, betrieben auf Ubuntu 24.04 mit CUDA 13.1. Jede Konfiguration wurde mit 10 Runs à 1.500 Token bei deaktiviertem Prefix-Caching gemessen. Ein zentrales Ergebnis: llama.cpp unterstützt Gemma 4 MTP zum Testzeitpunkt noch nicht, weshalb ein direkter Engine-Vergleich auf demselben Modell nicht möglich war. Der Entwurfsmodell-Anteil ist bei Gemma 4 mit 76 Millionen Parametern sehr kompakt, was laut Autor den VRAM-Mehraufwand vernachlässigbar macht — allerdings ohne belastbare Messung. Der Autor erklärt den Effekt mechanistisch: Da Autoregressive Decoding speicherbandbeitengebunden ist, amortisiert MTP die Kosten für Gewichts- und KV-Cache-Bewegungen über mehrere akzeptierte Draft-Token pro Verifikationsschritt.
- Benchmark-Setup: 10 Runs, je 1.500 Token, sequenzieller vLLM-Modus, identischer Prompt, Prefix-Caching deaktiviert.
- Bestes Einzel-Ergebnis: Gemma 4 31B mit vLLM bei n=5 → 132,52 tok/s gegenüber 39,69 tok/s ohne MTP (3,34×).
- Qwen 3.6 27B unter llama.cpp (Q8_0): optimaler Sweet-Spot bei n_max=3 mit 117,70 tok/s; höhere n-Werte (4, 5) brachten keine weiteren Gewinne.
- Das Draft-Modell für Gemma 4 MTP hat lediglich 76 Mio. Parameter; verwendetes GGUF-Modell für Qwen: unsloth/Qwen3.6-27B-MTP-GGUF.
- Qualitätsverlust wurde nicht systematisch evaluiert; der Autor verweist auf die Architektur: Das Zielmodell verifiziert jeden Token, bevor er akzeptiert wird.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
MTP auf vLLM und llama.cpp: 3,34× schnellere Inferenz für Gemma 4 und Qwen 3.6
Der Reddit-Post von r/LocalLLaMA dokumentiert eine mehrwöchige Benchmark-Reihe zu Multi-Token Prediction (MTP), einem spekulativen Decoding-Verfahren, das inzwischen von mehreren großen KI-Laboren in ihre Inferenz-Stacks integriert wird. Getestet wurden zwei Modell-Engine-Kombinationen: Gemma 4 31B (RedHatAI FP8-Block-Quantisierung) unter vLLM sowie Qwen 3.6 27B sowohl als Q8_0-GGUF unter llama.cpp als auch als FP8-Variante unter vLLM. Die Hardware war eine NVIDIA RTX PRO 6000 Blackwell mit 96 GB VRAM, betrieben auf Ubuntu 24.04 mit CUDA 13.1. Jede Konfiguration wurde mit 10 Runs à 1.500 Token bei deaktiviertem Prefix-Caching gemessen. Ein zentrales Ergebnis: llama.cpp unterstützt Gemma 4 MTP zum Testzeitpunkt noch nicht, weshalb ein direkter Engine-Vergleich auf demselben Modell nicht möglich war. Der Entwurfsmodell-Anteil ist bei Gemma 4 mit 76 Millionen Parametern sehr kompakt, was laut Autor den VRAM-Mehraufwand vernachlässigbar macht — allerdings ohne belastbare Messung. Der Autor erklärt den Effekt mechanistisch: Da Autoregressive Decoding speicherbandbeitengebunden ist, amortisiert MTP die Kosten für Gewichts- und KV-Cache-Bewegungen über mehrere akzeptierte Draft-Token pro Verifikationsschritt.
- Benchmark-Setup: 10 Runs, je 1.500 Token, sequenzieller vLLM-Modus, identischer Prompt, Prefix-Caching deaktiviert.
- Bestes Einzel-Ergebnis: Gemma 4 31B mit vLLM bei n=5 → 132,52 tok/s gegenüber 39,69 tok/s ohne MTP (3,34×).
- Qwen 3.6 27B unter llama.cpp (Q8_0): optimaler Sweet-Spot bei n_max=3 mit 117,70 tok/s; höhere n-Werte (4, 5) brachten keine weiteren Gewinne.
- Das Draft-Modell für Gemma 4 MTP hat lediglich 76 Mio. Parameter; verwendetes GGUF-Modell für Qwen: unsloth/Qwen3.6-27B-MTP-GGUF.
- Qualitätsverlust wurde nicht systematisch evaluiert; der Autor verweist auf die Architektur: Das Zielmodell verifiziert jeden Token, bevor er akzeptiert wird.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.