Wie beschleunigt Google Gemini Nano auf dem Pixel? Nicht mit größeren Chips, sondern mit einem anderen Schreibverfahren. In einem technischen Beitrag beschreibt Google, wie das Unternehmen Multi-Token Prediction nachträglich an bestehende, eingefrorene Gemini-Nano-v3-Modelle anbaut. Auf der Pixel-9- und der Pixel-10-Reihe läuft das Verfahren bereits. Wer Benachrichtigungen zusammenfassen lässt oder Proofread nutzt, arbeitet schon heute damit, ohne es zu merken.
Ein Sprachmodell auf dem Gerät heißt: Private Nachrichten müssen das Telefon nicht verlassen. Darin liegt für das Google-Team der Unterschied zu Cloud-Diensten. Der Preis ist ein knappes Budget. Ein Smartphone hat weniger Arbeitsspeicher, Kühlung und Energie als ein Rechenzentrum. Und es teilt diese Ressourcen mit allem, was sonst noch läuft.
Warum wortweises Schreiben bremst
Ein klassisches Sprachmodell arbeitet autoregressiv. Es erzeugt seine Ausgabe Schritt für Schritt und betrachtet dabei immer nur das nächste Token, ein Wortfragment von wenigen Buchstaben. Für N Token braucht es N Durchläufe durch das Netz, jedes Mal mit dem gesamten bisherigen Text im Gepäck. Das ist keine Schwäche des Modells, sondern die Grundlage seiner Funktionsweise. Und daraus entsteht die Bremse.
Das Problem ist weniger die Rechenleistung als der Datenverkehr. Bei jedem Durchlauf müssen die Gewichte und der Zwischenspeicher durch den Speicher wandern. Auf einem Telefon ist diese Bandbreite begrenzt. Man kann sich das wie einen Schreibtisch vorstellen, auf dem für jede neue Zeile das gesamte Manuskript neu aufgelegt werden muss. Die Recheneinheit wartet einen Teil der Zeit auf Nachschub, und in dieser Zeit verbraucht das Gerät trotzdem Energie. Am Ende steht eine Funktion, die korrekt arbeitet, aber träger wirkt als nötig.
Hier setzen die folgenden Optimierungen an. Es geht nicht darum, das Modell klüger zu machen, sondern seine Rechenzeit besser zu füllen. Deshalb wählt Google für mobile Geräte einen Ansatz, der zunächst unspektakulär klingt: Man baut nicht mehr Modell, sondern eine Abkürzung.
Spekulative Dekodierung: entwerfen und prüfen
Die naheliegende Abkürzung heißt spekulative Dekodierung. Sie funktioniert im Kern wie ein Lektorat. Ein kleines, schnelles Hilfsmodell, der Drafter, schlägt zunächst einige wenige Tokens vor, etwa drei. Das große Modell prüft diese Vorschläge dann in einem einzigen parallelen Durchlauf. Stimmen sie mit dem überein, was es selbst geschrieben hätte, werden sie übernommen. Beim ersten Abweichen setzt es bis zu dieser Stelle zurück und beginnt neu.
Google nennt in dem Beitrag frühere Arbeiten wie das EAGLE-Framework und Confident Adaptive Language Modeling als Grundlage. Der Gewinn: Wo sonst drei Durchläufe nötig wären, reicht oft einer, solange die Vorschläge stimmen. Die Qualität der Ausgabe leidet nicht, weil das große Modell jede Übernahme bestätigt. Für den mobilen Einsatz ist das ein Vorteil.
Der Haken liegt in der Umsetzung. Ein eigenständiger Drafter mit rund 128 Millionen Parametern konkurriert mit dem Hauptmodell um denselben knappen Arbeitsspeicher. Schlimmer noch: Er arbeitet blind. Er sieht nur den bisherigen Text und weiß nichts von dem semantischen Kontext, den das große Modell intern längst berechnet hat. Er rät also auf Basis eines Bruchteils der verfügbaren Information, und entsprechend oft liegt er daneben.
Ein angehängter Kopf statt eines zweiten Modells
Hier setzt Googles eingefrorene Multi-Token Prediction an. Statt ein zweites Modell zu trainieren, hängt das Team einen leichten Transformer-Kopf an die letzten Schichten von Gemini Nano v3. Dieser MTP-Kopf bekommt die finalen Aktivierungen des Hauptmodells zu sehen, also die hochdimensionalen Vektoren, in denen das Modell seinen Zwischenstand ablegt. Daraus sagt er die nächsten Tokens voraus. Er schreibt mit, statt von außen zu raten.
Entscheidend ist, dass das Hauptmodell dabei nicht mehr angefasst wird. Seine Gewichte bleiben eingefroren, trainiert werden ausschließlich die Parameter des angehängten Kopfes. Multi-Token Prediction wird damit zu einer reinen Effizienzoptimierung: Fähigkeiten und Sicherheitsausrichtung des Basismodells ändern sich nicht, weil niemand sie verändert.
Weil falsche Entwürfe bei der Prüfung ohnehin verworfen werden, bleibt die endgültige Ausgabe bit-genau identisch mit der des Hauptmodells. Für die Praxis ist das wichtig: Ein solches Update lässt sich ausrollen, ohne dass bestehende Anwendungen angepasst werden müssen. Für Entwickler entfällt ein mühsamer Schritt, der bisher bei jeder neuen Aufgabe anfiel: ein eigenes, speicherhungriges Entwurfsmodell zu trainieren.
Zero-Copy: der Entwurfskopf liest den Zwischenspeicher mit
Bleibt das Problem, dass zwei Instanzen doppelt Speicher belegen. In der Standardvariante führt ein Drafter einen eigenen Key-Value-Cache, also jenen Zwischenspeicher, in dem das Modell den bisherigen Gesprächsverlauf ablegt. Auf einem Telefon belastet das die knappste Ressource doppelt. Google beschreibt deshalb eine Zero-Copy-Architektur, in der der MTP-Kopf direkt auf den eingefrorenen Cache des Hauptmodells zugreift.
Der Entwurfskopf liest die Erinnerung des großen Modells also mit, statt eine eigene Kopie zu pflegen. Das hat zwei Folgen. Erstens entfällt die Vorlaufzeit, die ein separater Drafter braucht, um den Prompt zu verarbeiten. Er muss ihn nicht mehr verarbeiten. Zweitens sinkt der Speicherbedarf im Betrieb, laut Google um 130 Megabyte pro Instanz, unter anderem weil eigene Embedding-Tabellen, zusätzliche Attention-Varianten und anwendungsspezifische Feinabstimmungen wegfallen. Auf einem Gerät, auf dem jede Anwendung um dieselben Reserven ringt, zählt das.
Was die Messungen auf Pixel 9 und Pixel 10 zeigen
Die Zahlen sind deutlich. Gegenüber eigenständigen Draftern mit vergleichbarer Parameterzahl berichtet Google von Geschwindigkeitsgewinnen von 50 Prozent und mehr auf Pixel-9-Geräten, abhängig von der Aufgabe. Der Unterschied stammt aus den reicheren Repräsentationen: Wo ein separater Drafter das Hauptmodell als Blackbox behandelt, kennt der MTP-Kopf dessen internen Zustand. Bei Aufgaben mit komplexen Vorgaben wie Zusammenfassen, Umformulieren oder Instruction Following schlägt er den feinabgestimmten Konkurrenten deshalb klar.
Bei strukturierter Sprache wird der Abstand noch größer. Für Smart Replies, also die kurzen Antwortvorschläge, die dem Muster einer Nachricht folgen, lernt der Kopf die syntaktischen Gewohnheiten des Hauptmodells und kommt auf bis zu 55 Prozent mehr akzeptierte Tokens. Im Produktivbetrieb, etwa bei den Benachrichtigungszusammenfassungen und bei Proofread auf Pixel 9 und Pixel 10, sagt Multi-Token Prediction im Schnitt fast zwei zusätzliche Tokens pro Durchlauf korrekt voraus. Weniger Prüfschritte bedeuten weniger Zeit, in der schwere Prozessoren aufgeweckt werden, und damit weniger Energieverbrauch.
Parallele Pfade und nachsichtige Prüfung: die nächsten Schritte
Die Entwicklung ist damit nicht abgeschlossen. Google kündigt an, Multi-Token Prediction auch auf künftigen Pixel-Geräten einzusetzen. Parallel arbeitet das Team an Architekturen ohne Hilfskopf sowie an paralleler Dekodierung, um die Vorlaufzeit weiter zu drücken und mehr Tokens gleichzeitig zu prüfen. Beim Umgang mit Mehrdeutigkeit gibt es noch Luft: Klassische spekulative Dekodierung geht von einem einzigen besten Pfad aus. Das Team arbeitet daran, mehrere Möglichkeiten gleichzeitig zu verfolgen. Dazu kommt die Idee einer nachsichtigen Prüfung, die für bestimmte Anwendungsfälle exakte Übereinstimmung lockert.
Das Muster hinter der Ankündigung ist aufschlussreicher als die Zahlen. Der Fortschritt liegt nicht in einem neuen Modell, sondern in einer besseren Ausnutzung dessen, was bereits auf dem Gerät liegt. Spekulative Dekodierung auf Smartphones war lange ein Kompromiss zwischen Speicher, Qualität und Tempo. Ein angehängter, auf den bestehenden Zustand zugeschnittener Kopf verschiebt diesen Kompromiss. Für Nutzer heißt das schnellere Antworten bei gleicher Qualität und weniger Akkuverbrauch. Für Entwickler heißt es, dass On-Device-KI ohne Datenübertragung praktikabler wird, weil die Optimierung nicht bei jeder neuen Aufgabe von vorn beginnt.
Die genannten Zahlen beziehen sich auf Googles eigene Messungen und bestimmte Arbeitslasten, nicht auf jedes denkbare Szenario. Bemerkenswert ist, wo die Verbesserung sitzt: nicht im Modell, sondern in der Art, wie es schreibt. Ob sich ein Sprachmodell auf dem Telefon wie ein Werkzeug anfühlt oder wie eine Warteschlange, entscheidet sich auch dort.
Quelle: research.google
