- Google hat nur wenige Wochen nach der Veröffentlichung von Gemma 4 die Marke von 60 Millionen Downloads überschritten und einen Multi-Token-Prediction-(MTP)-Drafter für die Gemma-4-Familie vorgestellt
- Der MTP-Drafter ist eine spezialisierte Architektur für speculative decoding, die die Inferenzgeschwindigkeit ohne Einbußen bei Ausgabequalität oder Inferenzlogik um bis zu das 3-Fache erhöht, und wurde auf Hardware mit LiteRT-LM, MLX, Hugging Face Transformers und vLLM getestet
- Standard-LLM-Inferenz leidet unter einem starken Engpass bei der Speicherbandbreite, weil für die Erzeugung eines einzelnen Tokens Milliarden von Parametern aus dem VRAM zu den Recheneinheiten bewegt werden müssen; MTP lässt stattdessen einen leichten Drafter mehrere zukünftige Tokens vorschlagen, die das Zielmodell parallel validiert
- Wenn das Zielmodell den Entwurfs-Tokens zustimmt, übernimmt es die gesamte Sequenz in einem einzigen Forward-Pass und erzeugt zusätzlich noch ein weiteres Token, sodass Anwendungen typischerweise in der Zeit für ein einzelnes Token die Entwurfssequenz plus ein zusätzliches Token ausgeben können
- Der MTP-Drafter teilt sich die Aktivierungen des Zielmodells und den KV-Cache, nutzt für die Edge-Modelle E2B und E4B effizientes Embedder-Clustering, und die Gewichte sind unter Apache 2.0 auf Hugging Face und Kaggle verfügbar
Warum speculative decoding nötig ist
- Standard-LLM-Inferenz ist an die Speicherbandbreite gebunden, was zu einem hohen Latenz-Engpass führt
- Prozessoren verbringen den Großteil ihrer Zeit damit, für die Erzeugung eines einzelnen Tokens Milliarden von Parametern aus dem VRAM in die Recheneinheiten zu verschieben
- Diese Struktur führt besonders auf Consumer-Hardware dazu, dass Rechenressourcen nicht vollständig genutzt werden und die Latenz steigt
- Speculative decoding trennt Token-Erzeugung und Validierung
- Dabei wird ein schweres Zielmodell, zum Beispiel Gemma 4 31B, mit einem leichten Drafter, dem MTP-Modell, kombiniert, das freie Rechenressourcen nutzt, um mehrere zukünftige Tokens gleichzeitig vorherzusagen
- Der Drafter schlägt mehrere Tokens in kürzerer Zeit vor, als das Zielmodell für die Verarbeitung eines einzelnen Tokens benötigt, und das Zielmodell validiert die vorgeschlagenen Tokens parallel
So funktioniert MTP
- Standardmäßige große Sprachmodelle erzeugen Text autoregressiv und produzieren immer genau ein Token gleichzeitig
- Dieses Verfahren investiert dieselbe Rechenmenge sowohl in eine einfache Fortsetzung wie nach „Actions speak louder than…“ mit „words“ als auch in das Lösen komplexer Logikrätsel
- MTP reduziert diese Ineffizienz mithilfe von speculative decoding, das Google-Forschende in Fast Inference from Transformers via Speculative Decoding eingeführt haben
- Wenn das Zielmodell den Entwurfs-Tokens zustimmt, übernimmt es die gesamte Sequenz in einem einzigen Forward-Pass, und das Zielmodell selbst erzeugt gleichzeitig noch ein zusätzliches Token
- Anwendungen können typischerweise in der Zeit, die sonst für die Erzeugung eines einzelnen Tokens nötig ist, die gesamte Entwurfssequenz plus ein weiteres Token ausgeben
Leistungsvorteile für Entwickler
- Für Entwickler ist die Inferenzgeschwindigkeit oft ein zentraler Engpass bei Produktionsbereitstellungen
- Bei autonomen Agenten, Coding-Assistenten und reaktiven mobilen Anwendungen, die vollständig on-device laufen und schnelle mehrstufige Planung benötigen, zählt selbst Latenz im Millisekundenbereich
- In Kombination mit dem passenden Drafter bieten Gemma-4-Modelle folgende Vorteile
-
Bessere Reaktionsfähigkeit
- Die Latenz bei nahezu Echtzeit-Chats, immersiven Sprach-Anwendungen und agentischen Workflows lässt sich deutlich reduzieren
-
Schnellere lokale Entwicklung
- 26B-MoE- und 31B-Dense-Modelle laufen auf PCs und Consumer-GPUs schneller und unterstützen damit komplexe Offline-Coding- und agentische Workflows
-
Höhere On-Device-Performance
- E2B- und E4B-Modelle geben auf Edge-Geräten schneller aus und können so helfen, den Batterieverbrauch des Geräts zu senken
-
Keine Qualitätsverluste
- Da das Basismodell Gemma 4 die finale Validierung beibehält, liefert es dieselbe Inferenz- und Genauigkeitsqualität deutlich schneller
- Ein Beispiel mit Gemma 4 26B auf einer NVIDIA RTX PRO 6000 vergleicht die Tokens pro Sekunde zwischen Standard-Inferenz und MTP-Drafter und zeigt bei gleicher Ausgabequalität etwa halbierte Latenz
- Das Vergleichsvideo kann heruntergeladen werden
Interne Optimierungen des MTP-Drafters
- Um den MTP-Drafter schnell und präzise zu machen, wurden mehrere Architekturverbesserungen umgesetzt
- Das Entwurfsmodell nutzt die Aktivierungen des Zielmodells direkt und teilt sich dessen KV-Cache
- Durch das Teilen des KV-Caches wird keine Zeit darauf verschwendet, Kontext erneut zu berechnen, den das große Modell bereits verarbeitet hat
- Bei den Edge-Modellen E2B und E4B wird die finale Logit-Berechnung zu einem großen Engpass, daher wurde im Embedder eine effiziente Clustering-Technik implementiert, um die Generierung zu beschleunigen
- Es wurden auch hardwarespezifische Optimierungen untersucht
- Auf Apple Silicon hat das 26B-mixture-of-experts-Modell bei Batch-Größe 1 besondere Routing-Herausforderungen, doch bei gleichzeitiger Verarbeitung mehrerer Anfragen sind lokal Geschwindigkeitssteigerungen von bis zu etwa dem 2,2-Fachen möglich
- Beispielhafte Batch-Größen liegen bei 4 bis 8, und auch auf einer NVIDIA A100 zeigen sich ähnliche Verbesserungen bei steigender Batch-Größe
- Die visuelle Architektur, das Teilen des KV-Caches und die Funktionsweise des effizienten Embedders werden in der technischen Detailerklärung gezeigt
Nutzung und Verfügbarkeit
- Der MTP-Drafter für die Gemma-4-Familie wird wie Gemma 4 selbst unter der Open-Source-Lizenz Apache 2.0 bereitgestellt
- Wie MTP zusammen mit Gemma 4 verwendet wird, ist in der Dokumentation beschrieben
- Die Modellgewichte können auf Hugging Face und Kaggle heruntergeladen werden
- Schnellere Inferenz lässt sich mit transformers, MLX, vLLM, SGLang und Ollama ausprobieren
- In der Google AI Edge Gallery kann es direkt unter Android oder iOS getestet werden
- Google hofft, dass dieser Geschwindigkeitsschub die Entwicklung im Gemma-Ökosystem Gemmaverse beschleunigt
1 Kommentare
Hacker-News-Kommentare
Gemma und Gemini verwenden im Vergleich zu anderen Modellen deutlich weniger Ausgabetokens und kommen dabei den Spitzenwerten in Benchmarks ziemlich nahe
Vergleicht man Gemma mit Qwen, ist Qwen zwar etwas besser, braucht für eine Aufgabe aber 22 Minuten, während Gemma denselben Prompt oft in 4 Minuten beendet, selbst wenn dabei die Button-Ausrichtung falsch ist
Oberflächlich betrachtet liegt Gemma vielleicht 5–10 % hinter den führenden Open-Source-Modellen, braucht dafür aber nur 1/10 der Zeit
Ich hatte nie das Gefühl, aufrüsten zu müssen, so wie andere bei Claude oder Codex auf 100-Dollar-Pläne wechseln
Allerdings wurde Gemini im letzten Jahr ein paar Mal schwächer und die Rate Limits wurden strenger, daher ist unklar, ob es dauerhaft so gut bleibt
Da größere Modelle pro Einheit Intelligenz meist weniger Tokens verbrauchen, könnte das den Unterschied beim Tokenverbrauch erklären
Ich habe es auf einer 4070 ausprobiert; die Ausgabe war nicht extrem schnell, aber brauchbar
Für komplexe Aufgaben habe ich es noch nicht getestet, dort könnte es anders aussehen
Nach der Google I/O werden vielleicht mehr Leute merken, wie gut Gemini ist
Wenn es ein Alignment-Problem gibt, muss man zum Beheben noch einmal Eingabe- und Ausgabetokens verbrauchen
Für llama.cpp wird MTP-Support hinzugefügt, zumindest für Qwen-Modelle ist das bereits in Arbeit (https://github.com/ggml-org/llama.cpp/pull/20533)
Gemma 4 dürfte bald folgen
Wie stark sich Qualität und Geschwindigkeit lokaler bzw. selbstgehosteter Modelle in den letzten Monaten verbessert haben, ist bemerkenswert
Für jemanden, der schon lange lokale Modelle betreibt, ist das wirklich eine spannende Zeit
Ich bin gespannt, wie sich das im Vergleich zu MTP schlägt
Das war ein ziemlich gutes Tool
Google trägt die westliche Open-Source-Modell-Landschaft fast im Alleingang
Gemma 4 31B ist großartig
Allerdings ist es ziemlich schmerzhaft, die beste Version inklusive Vision-Funktionen und dem bald erscheinenden Drafter in 24 GB VRAM unterzubringen
In meinem Build kann ich keine weiteren GPUs hinzufügen, und für maximale Leistung müsste ich wohl entweder noch eine 4090 kaufen, was zu teuer ist, oder das System komplett ersetzen
--no-mmproj-offloadin llama.cpp kann man den multimodalen Projektor, also den Teil für Audio-, Bild- und PDF-Verständnis, im System-RAM haltenDann gibt es dafür natürlich keine GPU-Beschleunigung, aber es spart VRAM
Man kann es je nach Aufgabe stärker abstimmen und so wählen, ob man Denken und Genauigkeit oder Inferenzgeschwindigkeit priorisiert
Wenn ich einem Computer beim Schreiben zusehe, erinnert mich das an die Zeit, als man sich noch per Modem in BBS-Systeme einwählte
Das fühlt sich an wie der Sprung von 300 Baud auf 1200 Baud: eine große Verbesserung, aber immer noch ziemlich langsam, und irgendwann werden wir uns wohl fragen, wie wir das überhaupt ertragen konnten
Tokens beim Herausfließen zuzusehen erinnert an JPEGs, die zeilenweise Pixel für Pixel laden, und auch an all die Lade- und Verbindungsanimationen, die Apps früher hatten, bevor alles schnell genug war
Die Arbeit von Cerebras und Taalas liefert interessante Hinweise darauf, was in diese Richtung möglich ist
Es macht auch Spaß, sich vorzustellen, was möglich wäre, wenn man selbst modernste Modelle zu sehr niedrigen Kosten mit einer Million Tokens pro Sekunde nutzen könnte
Claude hat als Vergleich Modem gegen Claude Folgendes berechnet: bei 2368 Zeichen sind 300 Baud 1 Minute 19 Sekunden, 1200 Baud 19,7 Sekunden, 2400 Baud 9,9 Sekunden, 14,4K 1,6 Sekunden, 33,6K 705 ms, 56K 447 ms und Claude 7,9 Sekunden
Das lag im Bereich von mehreren Tausend Tokens pro Sekunde
Googles Strategie scheint etwas anders zu sein als die der anderen Frontier-Anbieter
Es wirkt, als konzentriere man sich stärker auf Performance-Effizienz pro Recheneinsatz als auf reine Spitzenleistung, wodurch Gemini nach außen hin vielleicht zurückgefallen aussieht
Andere Anbieter stoßen an Kapazitätsgrenzen und auch ihre Fähigkeit, Inferenzkosten zu subventionieren, hat Grenzen
Googles Strategie scheint darauf ausgerichtet zu sein, diese Modelle für bereits bestehende Milliarden von Nutzern zu skalieren und auszurollen
Eher wirkt es wie eine andere Art von Intelligenz als die neueren GPT-5- und Claude-Familien
Letztere fokussieren sich zunehmend auf Produktivität und Arbeitsautomatisierung und sind für lange, agentische, selbstkorrigierende Inferenzschleifen optimiert
Gemini wirkt wie ein viel klügeres Basismodell, besonders im Deep-Think-Modus, wo sich die Intuition deutlich tiefer anfühlt, aber für langreichweitige selbstkorrigierende Agentenloops ist es nicht ganz so gut
In den letzten Monaten sah mein Workflow so aus: Gemini für kreative Sprünge und Einsichten, Codex, Claude und GPT-5.5 Pro für repetitive oder präzise Aufgaben
Ich hatte lokale Modelle eine Weile pausiert und habe kürzlich das 26B-A4B-Modell auf einer RTX 3090 mit vLLM in 4 Bit eingerichtet; von der Geschwindigkeit und Qualität, die man für unter 1000 Dollar Investition bekommt, war ich völlig überrascht
Zuerst habe ich es mit Qwen probiert, aber das war instabil und die Denkspuren waren absurd lang
Es ist immer noch etwas heikel, aber mit ein bisschen Nacharbeit wirklich beeindruckend
Lokale Modelle sind die Zukunft, und das ist großartig
Bei Coding-Aufgaben ist es klar schlechter als Qwen 3.6, was eher dafür spricht, wie stark die Qwen-Modelle sind
Auf meinem Rechner ist tg im Vergleich zu anderen 30B-Modellen mindestens doppelt so schnell wie erwartet, vermutlich wegen Hybrid Attention
Die Eingabeverarbeitung ist allerdings etwas langsamer
Ich frage mich, ob es jemand geschafft hat, das in LM Studio zum Laufen zu bringen
Es gibt zwar eine Option in der UI, aber sie scheint nicht aktiviert zu werden
[1] https://github.com/ml-explore/mlx-lm/pull/990
[2] https://github.com/ggml-org/llama.cpp/pull/22673
Da es keine kleinen Modelle gibt, sollte man prüfen, ob man nicht versehentlich ein sparsames Gemma-Modell verwendet
Und ich habe alle Bildmodelle aus dem Workspace entfernt
Manchmal taucht es auf, wenn man diese löscht
Diese Dateien scheinen irgendwie mit Vision-Funktionen verbunden zu sein und speculative decoding zu blockieren, aber frag mich nicht warum
Bei Gemma funktionierte speculative decoding über den llama-server-Weg besser als in LM Studio
Meist müssen Anbieter, Quantisierung usw. exakt zusammenpassen
Es kann etwas dauern, bis man ein passendes Set gefunden hat
In meinen Tests brachte das Gemma-4-31B-Modell bei Coding-Aufgaben den größten Geschwindigkeitsschub mit Ollamas MLX-Runner, ungefähr um den Faktor 2
Allerdings senkt Quantisierung die Akzeptanzrate stark, daher braucht man einen ziemlich leistungsstarken Mac
Die drei anderen kleineren Modelle waren nicht so gut, weil die Zeit zur Verifikation des Draft-Modells den Geschwindigkeitsgewinn größtenteils wieder aufgefressen hat
Ich optimiere noch, um zu sehen, ob sich mehr herausholen lässt
Man kann es in Ollama 0.23.1 mit
ollama run gemma4:31b-coding-mtp-bf16ausprobierenSobald das in llama.cpp gemergt ist, will ich es unbedingt testen
In meinem Setup ist Gemma 4 26B-A4B etwa dreimal schneller als Qwen3.6-35B-A3B, deshalb klingt schon allein die Vorstellung von zusätzlich 1,5-facher Beschleunigung verlockend
Ich habe auch Draft-Modelle ausprobiert, aber mit begrenztem Erfolg; selbst kleinere 3B-Draft-Modelle und das dichte 14B-Ministral-Modell verursachten schon zu viel Overhead
Gemma4 26B liegt mit derselben Quantisierung bei über 200 TPS
Wichtig ist auch, dass Qwen eine extrem geringe Inferenz-Effizienz hat
Die Chain of Thought ist im Schnitt etwa dreimal so lang wie bei Gemma
Ich frage mich, ob das so etwas wie Branch Prediction in Betriebssystemen ist
Nur dass die Wahrscheinlichkeiten im Modell selbst eingebaut sind, also in einer viel verlässlicheren Form
Eine Fehlvorhersage bei Branch Prediction verbrennt Zyklen, während ein schlechter Tipp hier meist nur bedeutet, dass man keine Bonustokens bekommt
https://arxiv.org/abs/2211.17192