Gemma 4 wurde ohne MTP-Daten veröffentlicht — Warum das wichtig ist

Google hat Gemma 4 am 3. April 2026 veröffentlicht — eine Familie von Open-Weight-Modellen mit starken Benchmark-Ergebnissen, multimodalen Fähigkeiten und bis zu 256K Kontext. Auf dem Papier ist es eine beeindruckende Veröffentlichung. Doch innerhalb weniger Stunden entdeckte die Community etwas Fehlendes: Die Multi-Token-Prediction-Heads waren aus den öffentlichen Gewichten entfernt worden.

Das Modell wurde mit MTP trainiert. Googles eigenes LiteRT-Framework enthält die MTP-Komponenten. Aber die Version, die jeder von HuggingFace herunterladen kann? Nur standardmäßige autoregressive Generierung. Kein Geschwindigkeitsschub. Kein Speculative Decoding.

Dieser Beitrag erklärt, was MTP ist, warum es wichtig ist und was diese Entscheidung für alle bedeutet, die Gemma 4 auf eigener Hardware betreiben.

Was ist Gemma 4?

Gemma 4 ist die neueste Open-Weight-Modellfamilie von Google DeepMind, veröffentlicht unter der Apache 2.0-Lizenz. Sie umfasst vier Größen:

Zu den wichtigsten Fähigkeiten gehören native multimodale Unterstützung, Funktionsaufrufe, strukturierte JSON-Ausgabe und Training in über 140 Sprachen. Die 31B-Variante belegt Platz 3 auf der LMArena-Text-Bestenliste.

Unter der Haube führt Gemma 4 mehrere architektonische Innovationen ein: alternierende lokale Sliding-Window- und globale Attention-Schichten, proportionales RoPE (p-RoPE), Per-Layer Embeddings (PLE), geteilter KV-Cache und eine „Keys equal Values"-Speicheroptimierung.

Nach den Zahlen ist dies eine starke Veröffentlichung. Das Problem ist, was in den öffentlichen Gewichten fehlt.

Was ist Multi-Token Prediction?

Standardmäßige große Sprachmodelle generieren Text Token für Token. Jedes Token erfordert einen vollständigen Vorwärtsdurchlauf durch das Modell. Das nächste Token kann erst beginnen, wenn das vorherige abgeschlossen ist. Dies ist autoregressive Dekodierung, und sie ist von Natur aus sequenziell.

Multi-Token Prediction (MTP) ändert dies, indem dem Modell zusätzliche Prediction-Heads hinzugefügt werden. Anstatt nur das nächste Token vorherzusagen, sagt das Modell die Tokens N+1, N+2, N+3 und so weiter voraus — alles in einem einzigen Vorwärtsdurchlauf.

So funktioniert es:

1. Trainingsphase: Zusätzliche leichtgewichtige Prediction-Heads werden zusammen mit dem Hauptmodell trainiert. Jeder Head lernt, eine andere zukünftige Position vorherzusagen (1 voraus, 2 voraus, 3 voraus usw.)
2. Inferenzphase: Die zusätzlichen Heads generieren „Draft"-Tokens parallel. Das Hauptmodell verifiziert dann alle in einem einzigen Vorwärtsdurchlauf.
3. Verifikation: Wenn die Draft-Tokens mit dem übereinstimmen, was das Hauptmodell generiert hätte, werden sie alle auf einmal akzeptiert — mehrere sequenzielle Dekodierungsschritte werden übersprungen. Wenn ein Draft-Token falsch ist, kehrt die Generierung zu dieser Position zurück.

Dies ist eng mit Speculative Decoding verwandt, hat aber einen entscheidenden Vorteil: Die Draft-Tokens stammen vom Modell selbst, anstatt ein separates, kleineres „Draft-Modell" zu erfordern.

Wie viel schneller ist MTP?

Die Beschleunigung hängt davon ab, wie oft die Draft-Tokens korrekt sind (die „Akzeptanzrate"). DeepSeek V3 hat die Auswirkungen in der Praxis demonstriert:

Eine Akzeptanzrate von 2,4 bedeutet, dass im Durchschnitt jeder Vorwärtsdurchlauf durch das Hauptmodell 2,4 Tokens statt 1 erzeugt. Die Ausgabe ist mathematisch identisch mit der Standarddekodierung — jedes Token wird verifiziert. Man erhält die gleiche Qualität bei nahezu doppelter Geschwindigkeit.

Bereit, Ihr Geschäft zu erweitern?

Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.

Demo anfragen Anmelden

Was mit Gemma 4 passiert ist

Ein HuggingFace-Nutzer (@shadowlilac ) entdeckte, dass Googles LiteRT-Paket für Gemma 4 MTP-Prediction-Heads und Multi-Token-Prediction-Funktionalität enthält. Aber die öffentlich veröffentlichten Gewichte auf HuggingFace enthalten nichts davon.

Die MTP-Komponenten wurden bewusst entfernt:

• Keine MTP-Heads im Checkpoint
• Kein MTP in der Modellkonfiguration
• Kein MTP im Vorwärtsdurchlauf

Googles Erklärung

Ein Google-Ingenieur (@srikanta-221 ) bestätigte, dass dies beabsichtigt war:

Das öffentliche Modell stellt nur eine standardmäßige autoregressive Schnittstelle „für breite Kompatibilität" bereit. MTP-Heads sind aus der Modellkonfiguration, dem Vorwärtsdurchlauf und dem Checkpoint ausgeschlossen. Dies gewährleistet die Kompatibilität mit HuggingFace-Transformers-APIs und sorgt für ein konsistentes Checkpoint- und Laufzeitverhalten.

Google stellt MTP als eine „Deployment-Zeit-Optimierung" dar, nicht als eine Kernfunktion des Modells. Die MTP-Prediction-Heads werden nur in den LiteRT-exportierten Modellen aufbewahrt — Googles eigenem On-Device-Inferenz-Framework.

Warum das ein Problem ist

Die Erklärung hält einer genaueren Prüfung nicht stand:

1. Das Modell wurde mit MTP trainiert. Die Fähigkeit existiert. Sie aus der Veröffentlichung zu entfernen, ist eine Entscheidung, keine technische Einschränkung.

2. Drittanbieter-Engines können es nicht implementieren. vLLM, llama.cpp, SGLang und andere Inferenz-Frameworks können MTP-basiertes Speculative Decoding ohne die Prediction-Heads nicht nutzen. Diese Engines bedienen die überwiegende Mehrheit der Open-Source-LLM-Deployments.

3. Nutzer erhalten die langsame Version. Ohne MTP läuft Gemma 4 mit standardmäßigen autoregressiven Geschwindigkeiten. Der Leistungsunterschied ist in der Praxis bereits sichtbar:

4. Es schafft Ökosystem-Lock-in. Googles eigenes LiteRT-Framework erhält den Geschwindigkeitsvorteil. Alle anderen bekommen ein langsameres Modell. Für eine „Open-Weight"-Veröffentlichung unter Apache 2.0 ist das eine erhebliche Asymmetrie.

Wie Speculative Decoding funktioniert (und warum MTP besser ist)

Um zu verstehen, warum die fehlenden MTP-Heads wichtig sind, hilft es zu sehen, wo MTP in der Entwicklung der Inferenzoptimierung steht.

Ansatz 1: Traditionelles Speculative Decoding

Ein separates, kleineres „Draft-Modell" schlägt Tokens vor. Das Hauptmodell verifiziert sie parallel. Wenn die Entwürfe korrekt sind, werden mehrere Tokens pro Schritt akzeptiert.

• Vorteile: Funktioniert mit jedem Modellpaar
• Nachteile: Erfordert die Pflege und das Laden eines zweiten Modells; die Qualität des Draft-Modells begrenzt die Beschleunigung; zusätzlicher Speicheraufwand

Ansatz 2: MTP (eingebaute Prediction-Heads)

Das Hauptmodell verfügt über eigene leichtgewichtige Prediction-Heads, die Draft-Tokens generieren. Kein separates Modell erforderlich.

• Vorteile: Kein zusätzliches Modell nötig; engere Integration bedeutet höhere Akzeptanzraten; geringerer Speicheraufwand
• Nachteile: Funktioniert nur, wenn die Prediction-Heads in der Veröffentlichung enthalten sind

Warum MTP gewinnt

MTP-Prediction-Heads werden zusammen mit dem Hauptmodell trainiert. Sie teilen die gleichen internen Repräsentationen und lernen die eigene Token-Verteilung des Modells. Dies führt typischerweise zu höheren Akzeptanzraten als ein externes Draft-Modell, was mehr akzeptierte Tokens pro Verifikationsschritt und insgesamt schnellere Generierung bedeutet.

Die Prediction-Heads sind zudem klein — sie erhöhen die Gesamtparameterzahl des Modells typischerweise nur um 1–3 %. Der Speicheraufwand ist im Vergleich zum Laden eines separaten Draft-Modells vernachlässigbar.

Abonnieren Sie unseren Newsletter

Erhalten Sie die neuesten Tipps, Trends und Angebote kostenlos.

E-Mail-Adresse

Abonnieren

Die weiterreichenden Auswirkungen

Es geht hier nicht nur um Gemma 4. Die Entscheidung setzt einen Präzedenzfall dafür, wie „offen" Open-Weight-Veröffentlichungen tatsächlich sind.

Was Nutzer verlieren:

• MTP-basiertes Speculative Decoding auf jeder Drittanbieter-Inferenz-Engine
• Die Möglichkeit, die MTP-Heads zu feintunen oder damit zu experimentieren
• Leistungsparität mit Googles eigenen Deployment-Tools

Was Nutzer weiterhin haben:

• Die Basis-Modellgewichte (die wirklich gut sind)
• Traditionelles Speculative Decoding mit einem separaten Draft-Modell (vLLM Issue #38893 verfolgt Eagle3-Unterstützung für Gemma 4)
• Standardmäßige Quantisierungs- und Optimierungstechniken

Die Community-Reaktion war deutlich. Der 24-Stunden-Konsens war, dass Gemma 4s Benchmark-Ergebnisse konkurrenzfähig sind — es liegt gleichauf mit oder leicht hinter Qwen 3.5 — aber das Produkt „nicht fertig ist". Geschwindigkeit, Stabilität und Tooling müssen verbessert werden. Weitere Probleme umfassen die anfänglich fehlende Gemma-4-Architekturunterstützung in HuggingFace Transformers, PEFTs Unfähigkeit, die neuen Layer-Typen zu verarbeiten, und Abstürze bei Mac-Nutzern beim Laden größerer Modelle.

Was können Sie tun?

Wenn Sie Gemma 4 für den Einsatz evaluieren, gibt es praktische Optionen:

Nutzen Sie traditionelles Speculative Decoding. Externe Draft-Modelle können die Gemma-4-Inferenz weiterhin beschleunigen. Frameworks wie vLLM fügen speziell für Gemma 4 Eagle3-Speculative-Decoding-Unterstützung hinzu. Die Beschleunigung wird nicht an eingebautes MTP heranreichen, aber sie ist besser als nichts.

Ziehen Sie Alternativen für geschwindigkeitskritische Workloads in Betracht. Qwen 3.5 liefert deutlich bessere Tokens-pro-Sekunde auf vergleichbarer Hardware. Wenn die Inferenzgeschwindigkeit Ihre primäre Einschränkung ist, bietet Qwen derzeit ein besseres Geschwindigkeits-Qualitäts-Verhältnis.

Beobachten Sie Community-Workarounds. Die LiteRT-Exporte enthalten die MTP-Heads. Forscher könnten Wege finden, sie zu extrahieren und wieder an die HuggingFace-Gewichte anzuhängen, obwohl Google diesen Weg nicht offiziell unterstützt.

Geben Sie Feedback. Googles Ingenieure beobachten aktiv die HuggingFace-Diskussionsthreads. Klare, technische Anfragen zur Veröffentlichung der MTP-Heads haben Gewicht.

Fazit

Gemma 4 ist eine leistungsfähige Modellfamilie mit echten architektonischen Innovationen und starken Benchmark-Ergebnissen. Die Entscheidung, MTP-Prediction-Heads aus der öffentlichen Veröffentlichung zu entfernen — während sie in Googles eigenem LiteRT-Framework erhalten bleiben — untergräbt das „Open" in Open-Weight.

MTP ist keine geringfügige Optimierung. Es kann 1,5–2-fache Inferenzbeschleunigungen bei null Auswirkung auf die Ausgabequalität liefern. Das Zurückhalten aus den öffentlichen Gewichten, während das Modell offensichtlich damit trainiert wurde, schafft ein Zweiklassensystem: schnelle Inferenz für Googles Tools, langsame Inferenz für alle anderen.

Für die Open-Source-KI-Community ist die Botschaft klar: Prüfen Sie, was tatsächlich in den Gewichten steckt, nicht nur die Benchmarks. Eine offene Lizenz bedeutet nicht immer eine offene Veröffentlichung.

Erstellt mit FlowHunt . Bleiben Sie auf dem Laufenden über die neuesten Entwicklungen in der Open-Source-KI in unserem Blog .