„Unser neuestes offenes, experimentelles Modell liefert bis zu 4x schnellere Inferenz auf dedizierten GPUs und öffnet die Tür zu geschwindigkeitskritischen, interaktiven lokalen Workflows“, heißt es in der Ankündigung von Google zu DiffusionGemma. Der Satz benennt das Ziel des Modells und die Grenze gleich mit: Es geht nicht um das bestmögliche Ergebnis, sondern um das schnellste. Die Research Scientists Brendan O’Donoghue und Sebastian Flennerhag beschreiben damit ein Modell, das anders rechnet als ein klassisches Sprachmodell – und das unter Apache 2.0 veröffentlicht wurde, also frei nutzbar und auch kommerziell einsetzbar.
Eine Zahl fasst die Ankündigung zusammen: 256. So viele Tokens erzeugt DiffusionGemma in einem einzigen Vorwärtsschritt, statt sie wie ein autoregressives Modell eines nach dem anderen auszugeben. Auf einer einzelnen NVIDIA H100 nennt Google über 1000 Tokens pro Sekunde, auf einer GeForce RTX 5090 noch über 700. Solche Werte kannte man bisher vor allem aus Cloud-Infrastruktur mit großen Batches. Hier sollen sie auf einem Arbeitsplatzrechner entstehen.
Was DiffusionGemma anders macht als ein klassisches Sprachmodell
DiffusionGemma ist ein Gemma-4-Modell mit 26 Milliarden Parametern, genauer ein Mixture of Experts. Bei dieser Bauform wird nicht bei jeder Anfrage das gesamte Netz aktiviert, sondern nur ein Teil – bei DiffusionGemma sind es 3,8 Milliarden Parameter pro Inferenzschritt. Deshalb passt das Modell quantisiert in 18 GB VRAM und läuft damit auf gehobenen Consumer-Grafikkarten. Man kann sich das wie eine große Redaktion vorstellen, in der nicht alle Ressorts gleichzeitig an jedem Text arbeiten, sondern immer nur die, die für die aktuelle Zeile gebraucht werden.
Entscheidend ist nicht die Größe, sondern das Verfahren. Autoregressive Modelle sagen das nächste Token auf Basis der vorherigen voraus, streng von links nach rechts. DiffusionGemma hängt an das Gemma-4-Fundament einen eigenen Diffusionskopf, der aus der Gemini-Diffusion-Forschung stammt und Blöcke von Text parallel erzeugt. Das Modell ist damit kein Ersatz für Gemma 4, sondern eine zweite Betriebsart derselben Familie. Die Autoren formulieren das selbst so: Für maximale Qualität bleibt das klassische Gemma 4 die Empfehlung, DiffusionGemma ist für Tempo gebaut.
Schreibmaschine gegen Druckerpresse: warum der Vorteil lokal entsteht
Die Analogie stammt aus der Ankündigung selbst: Ein autoregressives Modell arbeitet wie eine Schreibmaschine, ein Anschlag nach dem anderen, immer abhängig vom zuletzt getippten Zeichen. In der Cloud ist das kein Problem, weil Tausende Anfragen gebündelt werden und die Hardware dabei dauerhaft beschäftigt bleibt. Läuft das Modell dagegen lokal für eine einzige Person, wartet der Grafikprozessor den größten Teil der Zeit auf den nächsten „Anschlag“. Die Rechenleistung ist da, sie wird nur nicht abgerufen – der Engpass ist die Speicherbandbreite, nicht die Recheneinheit.
DiffusionGemma verschiebt genau diesen Engpass. Weil ein ganzer Block von 256 Tokens gleichzeitig entsteht, bekommt der Prozessor eine größere Aufgabe am Stück und arbeitet näher an seiner Auslastungsgrenze. Aus der Schreibmaschine wird eine Druckerpresse, die den ganzen Absatz in einem Zug aufs Papier bringt. Das erklärt auch, warum Google die Geschwindigkeitsgewinne ausdrücklich für lokale und nebenläufigkeitsschwache Szenarien beschreibt: Bei hoher Last in der Cloud lassen sich autoregressive Modelle ohnehin so bündeln, dass die Rechenleistung ausgelastet ist. Dort bringt die parallele Dekodierung wenig und kann die Serving-Kosten sogar erhöhen.
Textdiffusion in drei Schritten: Rauschen, Verfeinern, Schärfen
Wer Bildgeneratoren kennt, kennt das Prinzip bereits. Dort beginnt die Erzeugung mit visuellem Rauschen, das in mehreren Durchläufen zu einem klaren Bild verfeinert wird. DiffusionGemma überträgt das auf Text. Zuerst steht eine Leinwand voller zufälliger Platzhalter-Tokens, dann folgen mehrere Durchläufe, in denen das Modell bereits sichere Tokens fixiert und sie als Kontext für die übrigen nutzt, bis der Text am Ende in seine endgültige Form konvergiert.
Weil das Modell den gesamten Block gleichzeitig betrachtet, kann jedes Token auf alle anderen achten – bidirektionale Aufmerksamkeit statt reiner Links-nach-rechts-Kette. Das ist kein Detail: Es erklärt, warum bestimmte Aufgaben leichter fallen. Eine Markdown-Formatierung sauber schließen, Code in eine bestehende Lücke einfügen, ein Sudoku-Raster füllen. Bei einem Sudoku hängt jede Ziffer von Ziffern ab, die im Text erst später kommen – für ein klassisches Modell eine unangenehme Struktur. Das Team von Unsloth hat DiffusionGemma genau darauf feinabgestimmt, als Beleg dafür, dass sich die Architektur mit Training an solche Aufgaben heranführen lässt.
Dazu kommt die Selbstkorrektur. Das Modell prüft seinen eigenen Entwurf als Ganzes und bessert nach, statt Fehler wortwörtlich mitzuschleppen, bis der Satz zu Ende ist. In der Praxis ähnelt das einem Lektor, der nicht erst nach der letzten Seite anfängt zu lesen, sondern den Absatz vor sich sieht und währenddessen eingreift.
Wo die Geschwindigkeit zur Qualität wird – und wo nicht
Google ist in der Ankündigung offen über die Grenzen. Die Gesamtqualität von DiffusionGemma liegt unter der von Gemma 4, weil das Modell Geschwindigkeit und paralleles Layout priorisiert. Wer Produktionsausgaben mit hohem Anspruch braucht, soll beim klassischen Modell bleiben. Das ist kein Bug, den man wegpatchen könnte, sondern eine bewusste Abwägung. Die spannendere Frage ist, wofür man schnelles Schreiben überhaupt braucht.
Die Antwort liegt in Workflows, in denen ein Mensch wartet. Inline-Bearbeitung, bei der ein Vorschlag erscheinen soll, während getippt wird. Schnelles Durchprobieren von Varianten. Das Generieren nicht-linearer Strukturen wie Diagramme, SVG-Grafiken oder mathematischer Ausdrücke. Hugging Face zeigt in einem Demo, wie aus einer Textbeschreibung direkt ein 3D-SVG entsteht. Für solche Aufgaben ist die Latenz wichtiger als die letzte Feinheit im Satzbau – und dort liegt der Vorteil von DiffusionGemma.
Was Entwickler heute konkret in die Hand bekommen
Die Gewichte stehen ab sofort auf Hugging Face, lizenziert unter Apache 2.0. Für den Betrieb nennt Google MLX, vLLM mit Integrationsunterstützung von Red Hat und die Hugging-Face-Transformers. Wer selbst experimentieren will, findet einen Fine-Tuning-Tutorial auf Basis von Hackable Diffusion, einem modularen JAX-Toolkit, außerdem Anleitungen für Unsloth und NVIDIA NeMo. Unterstützung für llama.cpp ist angekündigt, aber noch nicht verfügbar.
Auf der Hardwareseite hat Google mit NVIDIA zusammengearbeitet. Quantisiert läuft das Modell auf GeForce-RTX-5090- und 4090-Karten, für Unternehmen sind Hopper und Blackwell mit NVFP4-Kernels vorgesehen, dazu DGX Spark und DGX Station für den Einsatz am Schreibtisch. NVFP4 meint vier Bit breite Gleitkommazahlen, die den Durchsatz erhöhen und laut Ankündigung nahezu verlustfrei bleiben. Wer keine eigene Karte stellen will, kann das Modell auch über den Gemini Enterprise Agent Platform Model Garden oder NVIDIA NIM beziehen.
Was das für lokale KI-Inferenz bedeutet
Man kann diese Veröffentlichung als Experiment lesen und als Randnotiz abtun. Interessanter wird es, wenn man eine andere Frage stellt. Bisher lautete sie, ob ein Modell überhaupt in den Speicher passt und schnell genug antwortet. DiffusionGemma zeigt, dass die zweite Hälfte davon eine Designentscheidung ist und keine Naturkonstante. Wer die Dekodierung von der Speicherbandbreite auf die Rechenleistung verlagert, gewinnt dort, wo ohnehin nur ein Nutzer vor dem Rechner sitzt.
Für Anwendungen, in denen jemand auf eine Antwort wartet, gibt es jetzt eine Option, die nicht auf Kosten der Cloud-Latenz geht. Für alles, was publiziert oder automatisiert in großer Zahl verarbeitet wird, bleibt das klassische Modell die vernünftigere Wahl. Und wer seine eigene Architektur prüfen will, hat hier einen Anlass – der Engpass liegt vielleicht nicht im Modell, sondern in der Annahme, dass Text immer Wort für Wort entstehen muss.
Quelle: blog.google
