Gemma 4 MTP verschwiegen, Community deckt es auf, Google liefert verspätet Umgehungslösung

 (reddit.com)
5 Punkte von darjeeling 1 시간 전 | 2 Kommentare | Auf WhatsApp teilen

Google hatte die MTP-Funktion aus der öffentlich verteilten Version von Gemma 4 entfernt, obwohl das Modell damit trainiert wurde. Nachdem dies durch Reverse Engineering der Community ans Licht kam, begann Google verspätet damit, Unterstützung in Form eines externen Hilfsmodells bereitzustellen.

Open-Source-Entwickler analysierten Dateien im von Google veröffentlichten Format .litertlm (auf TFLite-Basis) für mobile/Edge-Geräte und entdeckten dabei eine schockierende Tatsache. Die MTP-Architektur (Multi-Token Prediction), die in den auf HuggingFace veröffentlichten Standard-Modellgewichten nicht vorhanden war, war ausschließlich in den für Edge kompilierten Dateien enthalten.

Als dies öffentlich kritisiert wurde, räumte Google den Sachverhalt ein und antwortete wie folgt:

> „Die MTP-bezogenen Prediction-Heads wurden im öffentlichen Modell bewusst weggelassen, um die Kompatibilität mit der HuggingFace Transformers API sicherzustellen. In der LiteRT-Runtime wurden sie beibehalten, um die On-Device-Performance zu verbessern.“

Was ist MTP

Normale LLMs erzeugen Tokens nacheinander, eines nach dem anderen. MTP ist eine Technik, bei der in einem einzigen Forward Pass mehrere Tokens gleichzeitig vorhergesagt werden. In Kombination mit Speculative Decoding kann dies die Inferenzgeschwindigkeit ohne Veränderung der Ausgabequalität deutlich erhöhen. Theoretisch ist es eine verlustfreie Optimierung.

Reverse-Engineering-Versuche der Community

Der ursprüngliche Entdecker schaffte es, mehrere .tflite-Dateien aus einer .litertlm-Datei zu extrahieren, veröffentlichte die extrahierten Dateien und den Reproduktionsablauf auf HuggingFace und bat um die Mithilfe von Personen mit C++-Kenntnissen. Danach begannen Community-Mitwirkende mit dem eigentlichen Reverse Engineering.

Technische Hürde: Die TFLite-Kernel-Struktur war extrem problematisch. Eine 1024 breite Attention-Vektorstruktur wurde nach INT8 quantisiert → mit INT8-Gewichten multipliziert → das Ergebnis erneut quantisiert → anschließend wieder dequantisiert.

Ergebnis: Nach mehreren Tagen intensiver Arbeit gelang die Rekonstruktion der folgenden Elemente:

  • GQA-Struktur (Grouped-Query Attention) und externes KV-Cache-Mapping
  • Verhalten des Sliding Local Window
  • Quantisierungspfade für pre_project / q_proj / MLP / o_proj / post_project
  • Teilweises RoPE-Verhalten
  • 20/20 Top-1-Matches mit End-to-End-TFLite-Parität erreicht

Die Lizenz ist Apache 2.0, daher gibt es keine rechtlichen Probleme.

Reale Leistung: Wie schnell ist es

Von der Community gemessene Ergebnisse (auf Basis von Strix Halo):

Aufgabe Bisher Nach Anwendung von MTP
Codegenerierung 8 tps 25 tps (ca. 3x)
Allgemeines Schreiben 7~8 tps 11~14 tps

Verglichen mit Speculative Decoding bei bestehenden LLaMA-/Qwen3-Modellen, das üblicherweise bei etwa 1,5~1,7x und maximal 2x liegt, ist 3x beim Coding ein ungewöhnlicher Wert. Als Grund wird vermutet, dass bei der Codegenerierung viel wiederholter Boilerplate vorkommt und daher die Akzeptanzrate für Draft-Tokens hoch ist.

Reaktionen und Verdachtsmomente in der Community

Die Kritik ging im Wesentlichen in zwei Richtungen.

① Kritik an fehlender Dokumentation (Undocumented): Das Modell wurde mit MTP trainiert, doch in der öffentlichen Distribution wurde die Funktion absichtlich entfernt, ohne dies überhaupt zu erwähnen.

② Verdacht auf kommerzielle Motive: „Wenn ein lokal laufendes Open-Source-Modell mit 31B zu schnell wird, könnte das die Wettbewerbsfähigkeit der eigenen kommerziellen API (Flash Lite usw.) gefährden, daher wurde es absichtlich beschnitten“, so der Vorwurf. Auch das geleakte und später entfernte 122B-Modell wurde in diesem Zusammenhang erwähnt.

Googles strukturelle Entscheidung

Vertriebskanal MTP enthalten
Öffentliche Gewichte auf HuggingFace ❌ absichtlich entfernt
LiteRT (Edge/Mobil) ✅ integriert
gemma4_assistant (neu seit 5/5) ✅ Umgehungsunterstützung als externes Hilfsmodell

Googles verspätete offizielle Reaktion (5.–6. Mai)

Als der Druck aus der Community zunahm, veröffentlichte Google am 5. Mai das Hilfsmodell gemma4_assistant separat auf HuggingFace und kündigte über den offiziellen Blog den Gemma-4-MTP-Drafter an. Damit wird eine Funktion, die eigentlich im ursprünglichen Modell enthalten sein sollte, ausgelagert und auf Umwegen unterstützt.

  • Geschwindigkeit: bis zu 3-fach höhere Inferenzgeschwindigkeit ohne Qualitätsverlust
  • Assistant-Modell: leichter Drafter mit etwa 500M Parametern
  • Verwendung: Funktioniert, indem es einfach als Argument assistant_model= an die Funktion generate() übergeben wird. Keine eigene MTP-Implementierung erforderlich
  • Unterstützte Umgebungen: HuggingFace Transformers, vLLM, MLX (Apple Silicon), LiteRT-LM

> 💡 Kurzfassung in einem Satz: Google entfernte die MTP-Funktion aus der öffentlichen Gemma-4-Version trotz entsprechendem Training, und begann erst nach der Aufdeckung durch Reverse Engineering der Community mit einer verspäteten Umgehungsunterstützung über ein externes Hilfsmodell.

Verwandte Beiträge