DiffusionGemma: 4x schnellere Textgenerierung

• DiffusionGemma ist ein experimentelles offenes 26B-MoE-Modell unter Apache-2.0-Lizenz, das komplette Textblöcke gleichzeitig per Textdiffusion generiert
• Anstelle der sequentiellen Token-Generierung typischer autoregressiver LLMs nutzt es 256 Token parallele Generierung und bietet auf dedizierten GPUs bis zu 4x schnellere Textgenerierung
• Bei der Inferenz werden von den gesamten 26B nur 3,8B Parameter aktiviert; quantisiert läuft es innerhalb eines 18-GB-VRAM-Limits auf gehobenen Consumer-GPUs
• Bidirektionale Attention und iterative Selbstkorrektur bringen Vorteile bei Inline-Bearbeitung, Code-Fill, Aminosäuresequenzen und mathematischen Graphen mit nichtlinearen Strukturen
• Da es sich um ein experimentelles Modell handelt, das Geschwindigkeit und parallele Layout-Generierung priorisiert, liegt die gesamte Ausgabequalität unter der von Standard-Gemma 4; für Anwendungen mit höchsten Qualitätsanforderungen wird die Bereitstellung von Standard Gemma 4 empfohlen

---

Neuer Nutzen für Entwickler

• DiffusionGemma ist ein experimentelles offenes Modell zur Erforschung von Textdiffusion und generiert statt der üblichen tokenweisen sequentiellen Verarbeitung autoregressiver LLMs komplette Textblöcke gleichzeitig
• Das Modell ist ein 26B Mixture-of-Experts-(MoE)-Modell unter Apache-2.0-Lizenz und liefert auf GPUs bis zu 4x schnellere Textgenerierung
• Es basiert auf der Intelligenz-pro-Parameter der Gemma-4-Familie und auf Gemini Diffusion research und integriert einen neuen Diffusions-Head zur Maximierung der Generierungsgeschwindigkeit
• Autoregressive Gemma-4-Modelle bleiben der Standard für hochwertige Produktionsausgaben, während DiffusionGemma für Forschende und Entwickler konzipiert ist, die geschwindigkeitskritische interaktive lokale Workflows erkunden möchten

• Zentrale Trade-offs

  • Schnelle Inferenz verlagert den Decoding-Flaschenhals von Speicherbandbreite zu Rechenleistung und liefert auf dedizierten GPUs bis zu 4x schnelleren Token-Output
  • Auf einer einzelnen NVIDIA H100 werden mehr als 1000 Token pro Sekunde erzeugt, auf einer NVIDIA GeForce RTX 5090 mehr als 700 Token pro Sekunde
  • Hardware-Zugänglichkeit ergibt sich aus einer Architektur, die bei der Inferenz nur 3,8B Parameter des gesamten 26B-MoE aktiviert
  • Quantisiert passt das Modell innerhalb des 18-GB-VRAM-Limits gehobener Consumer-GPUs
  • Bidirektionale Attention generiert bei jedem Forward-Pass 256 Token parallel, sodass alle Token aufeinander Bezug nehmen können
  • Das bringt Vorteile in nichtlinearen Bereichen wie Inline-Bearbeitung, Code-Fill, Aminosäuresequenzen und mathematischen Graphen
  • Selbstkorrektur bedeutet, dass das Modell seine Ausgabe iterativ verfeinert, während es den gesamten Textblock auf einmal bewertet und Fehler in Echtzeit korrigiert
  • Der experimentelle Status und die Produktions-Empfehlung sind klar: Da Geschwindigkeit und parallele Layout-Generierung priorisiert werden, ist die gesamte Ausgabequalität niedriger als bei Standard Gemma 4

• Beispiel für Fine-Tuning

  • Die Leistung bei spezifischen Aufgaben kann durch Fine-Tuning verbessert werden
  • Unsloth hat DiffusionGemma darauf feinabgestimmt, Sudoku zu lösen; Sudoku ist eine Aufgabe, mit der autoregressive Modelle Schwierigkeiten haben, weil jedes Token von zukünftigen Token abhängt
  • Die bidirektionale Attention von DiffusionGemma macht Aufgaben wie Sudoku deutlich leichter

Warum Diffusion für Text verwenden

• Die AI-Forschungsgemeinschaft erforscht seit Jahren diffusionsbasierte Textgenerierung, doch ihre Anwendung auf große Modelle blieb eine Herausforderung
• DiffusionGemma begegnet diesem Problem, indem es verändert, wie das Modell Hardware nutzt

• Trade-offs gegenüber bestehenden Modellen

  • Die meisten Sprachmodelle erzeugen wie eine Schreibmaschine Token einzeln von links nach rechts
  • In der Cloud ist dieser Ansatz effizient, weil Server Anfragen von Tausenden Nutzern gemeinsam batchen und so die Hardware-Auslastung teilen können
  • Wenn ein einzelner Nutzer das Modell lokal ausführt, schöpft die wortweise Generierung dedizierte GPUs oder TPUs nicht voll aus, und die Hardware wartet oft auf den nächsten „Tastenanschlag“
  • DiffusionGemma entwirft einen gesamten Absatz mit 256 Token gleichzeitig und gibt dem Computerprozessor dadurch größere Arbeitsblöcke auf einmal
  • Diese Architektur verwandelt Modellinferenz von einer sequentiellen Schreibmaschine in eine große Druckmaschine, die ganze Textblöcke gleichzeitig druckt

• Geschwindigkeitsgewinn für lokale Inferenz mit geringer Parallelität

  • Der Geschwindigkeitsgewinn von DiffusionGemma ist für lokale Inferenz und Inferenz mit geringer Parallelität ausgelegt
  • Beim Cloud-Serving mit hoher QPS können auch autoregressive Modelle so bereitgestellt werden, dass sie die Rechenleistung effizient auslasten
  • In Umgebungen mit hoher QPS sinkt der Vorteil des parallelen Decodings von DiffusionGemma, und die Serving-Kosten können höher ausfallen
  • Der Durchsatzvorteil ist auf einem einzelnen Beschleuniger bei kleinen bis mittleren Batch-Größen am stärksten

So funktioniert Textdiffusion

• Textdiffusion überträgt auf Text ein Verfahren, das der AI-Bildgenerierung ähnelt, bei der aus visuellem Rauschen gestartet und iterativ zu einem klaren Bild verbessert wird
• In der ersten Phase, der Canvas-Phase, startet das Modell mit einer Fläche aus zufälligen Platzhalter-Token
• In der iterativen Verfeinerungsphase führt das Modell mehrere Durchläufe aus, fixiert korrekte Token und nutzt sie als Kontext-Hinweise, um den Rest zu verfeinern
• In der abschließenden Verfeinerungsphase konvergiert der Text zu einer hochwertigen Ausgabe
• Weil das Modell während der Generierung ganze Absätze verarbeiten kann, werden Verhaltensmuster möglich wie das korrekte Schließen komplexer Markdown-Formatierung oder das nahezu in Echtzeit Generieren und Rendern von Code

Erste Schritte

• Die Gewichte des experimentellen Modells werden unter einer permissiven Apache-2.0-Lizenz bereitgestellt und sind auf Hugging Face verfügbar
• Im DiffusionGemma developer guide lässt sich nachlesen, wie die Integration erfolgt, und in A Visual Guide to DiffusionGemma gibt es einen tieferen Einblick in die internen Mechanismen
• Das Modell kann mit MLX, vLLM, Hugging Face Transformers bereitgestellt werden
• Die vLLM-Integration wird von Red Hat unterstützt
• Für schnelle Experimente gibt es ein Fine-Tuning-Tutorial auf Basis von Hackable Diffusion, einem modularen JAX-Toolkit, das auf Komponierbarkeit ausgelegt ist
• Fine-Tuning kann auch mit Unsloth und NVIDIA NeMo erkundet werden
• Offizielle Unterstützung für llama.cpp soll in Kürze folgen

Optimierung und Laufzeitumgebung

• In Zusammenarbeit mit NVIDIA wurde über den gesamten Hardware-Stack hinweg optimiert, um Kompatibilität und Leistung sowohl in Consumer-Umgebungen als auch in Enterprise-Systemen zu bieten
• Consumer-Umgebungen unterstützen Quantisierung für GeForce RTX 5090 und 4090 GPUs
• Enterprise-Umgebungen liefern hohe Leistung auf Hopper und Blackwell mit fortschrittlichen NVFP4-Kernels
• Auch NVIDIA DGX Spark und DGX Station für lokale Deskside-Bereitstellung sowie RTX PRO für AI-Fachleute gehören zu den Zielplattformen
• Die native Unterstützung für NVFP4 mit 4-Bit-Gleitkomma beschleunigt den Rechendurchsatz, sodass das Modell mit höherer Geschwindigkeit und nahezu verlustfreier Genauigkeit läuft
• Für den Betrieb kann zwischen Desktop-GPUs, Gemini Enterprise Agent Platform Model Garden, und NVIDIA NIM gewählt werden

[GN⁺]

Hacker-News-Kommentare

• Ich bin vor Kurzem zu OpenCode gewechselt und habe viele Modelle ausprobiert, die nicht von den großen Frontier-Forschungslaboren in den USA stammen. Unerwarteterweise hat mir Mercury am besten gefallen.
  Nicht, weil es „intelligenter“ wäre, sondern weil es absurd schnell war. Statt des heutigen agentenartigen Erlebnisses, bei dem man einen Prompt eingibt und wartet, fühlte es sich eher wie Pair Programming an. Man bekam die Vorteile von AI, aber auch etwas von dem Gefühl des Codens aus der Zeit vor AI zurück, was deutlich mehr Spaß machte. Es war nicht wie ein Spielautomat, bei dem man einen Prompt einwirft, wartet und hofft, dass die Richtung stimmt, und ich griff dadurch auch häufiger zu kleinen Modellen wie Gemini Flash Lite oder GPT Mini/Nano. Ich freue mich darauf, dass jetzt ein Open-Weights-Modell erscheint, und werde es sofort testen

  • Wenn man Tests schnell und billig laufen lassen kann und außerdem kostengünstige Metriken bauen kann, um schlechten oder hingeschluderten Code zu erkennen, dann kann in zeitkritischen Situationen ein schnelles, aber etwas schwächeres Modell besser sein als ein langsames, aber deutlich besseres Modell.
    Ich habe eine Metrik verwendet, die nicht die zyklomatische, sondern die tatsächliche Komplexität misst, und automatisch zurückrollen lassen, bis die zusätzlich eingebrachte Komplexität im Verhältnis zur Funktionalität in einem vernünftigen Bereich lag. Damit waren die Ergebnisse beim Einsatz von LLMs ziemlich gut
  • Mercury-2 ist hervorragend. Ich nutze es im llm-consortium oft als Schiedsrichter.
    Das Kontextfenster ist relativ klein, daher kann man es für größere Konsortien in so etwas wie ein rekursives Meta-Konsortium einbinden:
    llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
    Wenn man nun cns-meta-glm-kimi einen Prompt gibt, wählt es zunächst jeweils die beste von 5 Antworten bei kimi und glm aus und synthetisiert dann die beiden Siegerantworten
  • Ich frage mich, wie stark sich das auf lokale Modelle fürs Coden auswirken wird. Wenn man ein Diffusionsmodell verwendet, das ein paarmal schneller ist als Qwen oder Gemma 4, müsste ich mich zwar wie vor AI wieder stärker selbst vorbereiten, aber das könnte sogar gut sein, und man könnte lokal mit sehr schnellen und günstigen Modellen arbeiten.
    Wenn keine langen, schweren Berechnungen anfallen, dürften auch die Kosten für den Betrieb auf lokaler Hardware geringer sein
  • Ich weiß genau, was du meinst. Bei einem privaten Projekt war ich frustriert, weil Claude so langsam war, und bin deshalb zu Google Antigravity und den Flash-Modellen gewechselt. Der Geschwindigkeitsunterschied ist enorm.
    Man bleibt viel besser im Flow und konzentriert sich stärker auf die Arbeit. Mir war nicht klar, dass Geschwindigkeit so einen großen Unterschied macht. Bei sehr komplexen und großen Codebasen kann sich Claudes langsame Antwortzeit als Tausch gegen Aufgabenkomplexität lohnen, aber Antigravity oder andere schnelle Modelle passen viel besser, wenn man klein und leichtgewichtig iterativ Code schreiben, ausführen und debuggen will
  • Ja, Geschwindigkeit ist der entscheidende Faktor. Es ist großartig, Boilerplate-POJOs oder Datenklassen mit wahnsinnigen 300+ tok/s generieren zu lassen, und unter solchen Bedingungen ist Flash-Lite nützlicher als GPT-5.5.
    Wenn es zu langsam ist, steckt man in dieser verdammten asynchronen Warteschleife fest

• Google zeigt weiterhin seine Stärke. Es überrascht, dass Gemini für Code oder agentische Anwendungsfälle nicht konkurrenzfähiger gegenüber Claude oder OpenAI-Modellen ist, aber es ist offensichtlich, dass Google immer noch AI-Talente auf Spitzenniveau hat.
  Allerdings scheint Google sich eher auf Anwendungsfälle zu konzentrieren, die auf dem Smartphone laufen oder nahezu in Echtzeit sind, statt auf große nachdenkliche LLMs. Solche Effizienzverbesserungen könnten für AI in Zukunft enorm wichtig werden. Die Zeit, in der Tokens wie subventionierte Billigware verteilt wurden, um Leute an ein bestimmtes Ökosystem zu binden, geht zu Ende, und die Phase, in der echte Kosten bezahlt werden müssen, kommt. Gewinnen wird das Unternehmen, das herausfindet, wie sich wirklich intelligente Modelle kosteneffizient betreiben lassen. DeepSeek ist mehr als um einen einstelligen Faktor billiger als GPT 5.5 oder Opus 4.8, und auch wenn es schlechter ist als beide, ist es nicht katastrophal schlechter. Wenn das beste Coding-Modell genug menschliche Zeit spart, würde ich den 10-fachen Preis gern zahlen, aber bei einem Unterschied um den Faktor 100 ist das schwer zu akzeptieren, etwa wenn GPT 5.5 Pro in neueren Benchmarks mehr als 200-mal teurer ist als DeepSeek und etwa 30-mal teurer als Opus 4.8

  • Fable kostet doppelt so viel wie Opus und wirkt auch gegenüber GPT-Pro ziemlich konkurrenzfähig, daher könnte es eine brauchbare Option sein, solange überempfindliche Safety-Mechanismen kein großes Problem darstellen.
    Google hat in diesem Bereich ebenfalls eine eigene „Deep Research“-Option, und sie scheint gut zu funktionieren. Das Gute an DeepSeek ist, dass es sich ohne API-Kosten auf lokaler Hardware ausführen lässt. Wenn einem das wichtig ist, ist es kein großes Problem, wenn es etwas schwächer ist als Opus oder GPT
  • Am Ende wird Google wahrscheinlich gewinnen. Das Unternehmen konzentriert sich auf die wichtigen Punkte: Leistung pro Watt und Leistung pro Dollar.
    Es entwickelt eigene Inferenz-Hardware und geht in Richtung Edge Computing, um Latenz und Rechen-Overhead zu senken. Große LLMs sind noch nicht kosteneffizient, und Google lässt die Konkurrenz weiter Investorengeld verbrennen, um Verbrauchern ihre Produkte unter Kosten zu „verkaufen“. Selbst wenn die AI-Blase platzt, wird ein Unternehmen wie Google unbeschadet überleben, und diese Blase scheint darauf hinauszulaufen, einigen Großunternehmen die Fassade abzureißen

• Einige Reaktionen übersehen die Vorteile des Diffusionsansatzes. Auf Edge-Geräten wie Handy- oder Computer-GPUs könnte das große Auswirkungen haben
  Der Decoder eines LLM muss alle vorherigen Tokens berücksichtigen und berechnet sie deshalb einzeln. Herkömmliche LLM-Decoder skalieren gut, wenn die Last hoch genug ist, um mehrere Inferenzläufe zu Batches zusammenzufassen, und in dieser Umgebung sind die Vorteile von Diffusion begrenzt. Am Edge ist das Problem anders. Inferenzbeschleuniger hungern aus, weil sie ständig Gewichte im GB-Bereich aus dem RAM nachladen müssen. Consumer-RAM wie LPDDRx/GDDRx hat weniger Bandbreite als HBM, und weil Anfragen seriell sind, lassen sich gemeinsame Gewichtsberechnungen nicht zu Batches bündeln. Diffusion kann Tokens parallel berechnen und entschärft so den Speicherbandbreiten-Engpass

  • Edge-Geräten fehlt es nicht nur an Speicherbandbreite, auch die Rechenleistung ist stark begrenzt. In der Praxis sättigt man auch ohne große Batches die verfügbare Rechenkapazität schnell und stößt an klare Wärme- und Stromgrenzen
    Dass Anfragen bei Edge-Inferenz „von Natur aus seriell“ seien, stimmt ebenfalls nicht wirklich. Es laufen mehrere Anfragen gleichzeitig, also mehrere Chats, und wenn genug Speicher für den KV-Cache vorhanden ist, kann Batch-Verarbeitung angewendet werden. Wenn ein Diffusionsmodell mit mehr Rechenaufwand geringere Qualität liefert und die Einsparung bei der Speicherbandbreite fraglich ist, ist mir nicht klar, wie das helfen soll
  • Im Großen und Ganzen richtig, aber hier werden Attention und autoregressive/kausale Struktur durcheinandergebracht. Das eigentliche Problem, das den Einsatz von mehr Rechenleistung verhindert, ist die autoregressive/kausale Struktur
    Auch bei Diffusion kann Attention verwendet werden, und dieses Modell nutzt tatsächlich Attention

• NVIDIA bietet für dieses Modell einen kostenlosen Endpoint an. Details stehen unter https://build.nvidia.com/google/diffusiongemma-26b-a4b-it; man muss ein Konto anlegen und vermutlich auch die Telefonnummer verifizieren
  Ich habe es auch einen Pelikan zeichnen lassen: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

  • Wenn das Modell wirklich so schnell ist, könnte man sogar nach Animationsframes fragen. Zum Beispiel Frame 1: rechter Fuß auf 12 Uhr, linker Fuß auf 6 Uhr; Frame 2: rechter Fuß auf 3 Uhr, linker Fuß auf 9 Uhr
    Dann sollte man natürlich nicht Tokens pro Sekunde angeben, sondern Pelikan-Frames pro Sekunde
  • Ich habe mich vor ein paar Wochen registriert, aber obwohl ich die Schritte befolgt habe, ist mein Konto immer noch nicht verifiziert. Ohne verifiziertes Konto kann man die API nicht nutzen

• Eine gute visuelle Erklärung dazu, wie Text-Diffusionsmodelle wie DiffusionGemma funktionieren: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

• Noch vor ein paar Tagen dachte ich, Google würde über Diffusionsmodelle zur Textgenerierung überhaupt nicht sprechen, nachdem sie sie vor einem Jahr auf der I/O gezeigt hatten
  Es gab Gerüchte, dass sie zu teuer im Betrieb seien, aber wenn man wie in den bereitgestellten Diagrammen DiffusionGemma und normales Gemma auf derselben 1x-H100-Hardware vergleicht, scheint das nicht der Fall zu sein. Abgesehen davon, dass es etwas schwächer als Gemma ist, frage ich mich, was der Nachteil dieser Geschwindigkeit ist

  • Die Antwort auf „Ich frage mich, was der Nachteil dieser Geschwindigkeit ist“ scheint dieser Abschnitt zu sein:
    „Die Geschwindigkeitsvorteile von DiffusionGemma wurden für lokale Inferenz und Inferenz mit niedriger Parallelität entwickelt. Bei Cloud-Serving mit hoher QPS können autoregressive Modelle effizient zu Batches zusammengefasst werden, um die Rechenleistung auszulasten; dadurch schrumpft der Vorteil des parallelen Decodings von DiffusionGemma und die Serving-Kosten können höher sein“
  • Bei einem standardmäßigen autoregressiven Modell könnte man zum Beispiel bei 256 Nutzern 256 Tokens auf einmal erzeugen. Dieses Verfahren kann zwar für einen einzelnen Nutzer 256 Tokens erzeugen, benötigt dafür aber mehrere Vorwärtsdurchläufe
    Deshalb verbraucht der Diffusionsprozess mehr GFLOPs, und wenn es genügend Nutzer gibt, kann man das Gleichgewicht zwischen Speicher und Rechenleistung bereits herstellen

• „DiffusionGemma kehrt diese Ineffizienz um. Statt Wörter nacheinander vorherzusagen, erstellt es gleichzeitig einen Entwurf für einen ganzen Absatz mit 256 Tokens. Indem es dem Computerprozessor auf einmal größere Arbeitspakete gibt, nutzt es die Hardware maximal aus. Es wertet Modellinferenz von einer Schreibmaschine, die Zeichen für Zeichen tippt, zu einer riesigen Druckmaschine auf, die ganze Textblöcke gleichzeitig ausgibt“
  „Es arbeitet als Mixture-of-Experts-(MoE)-Modell mit insgesamt 26B Parametern, von denen während der Inferenz nur 3.8B aktiv sind, und passt quantisiert bequem innerhalb der 18-GB-VRAM-Grenze einer gehobenen dedizierten Consumer-GPU“
  Also ist Gemma 4 26B ein MoE-Modell, das mit ollama auf meiner 24-GB-GPU sehr schnell läuft. Das klingt für mich wie Speculative Decoding, aber ich dachte, bei MoE-Modellen funktioniert das nicht. Für Leute, deren Job es nicht ist, da dranzubleiben, sind es zu viele Veränderungen, um noch mitzuhalten

  • Das ist ein anderes Modell, das verwirrenderweise fast die gleiche Parameterzahl wie das bestehende gemma4-MoE hat. Ob und auf welche Weise eines von beiden aus dem anderen trainiert wurde, ist beim schnellen Überfliegen nicht klar
    Der Mechanismus ist nicht derselbe wie bei Speculative Decoding. Speculative Decoding läuft sequenziell, meist mit ein paar Tokens auf einmal. Diffusion tut das nicht, sondern verarbeitet einen ganzen Textblock auf einmal. Ich habe die Unterlagen noch nicht gelesen, vermute aber, dass trainiert wurde, bestimmte Experten über einen ganzen Diffusionsblock hinweg stabil zu halten

• Auf meiner 3090 Ti komme ich nicht einmal in die Nähe der beworbenen Geschwindigkeit, aber es macht Spaß zu sehen, wie die Antwort sich „auffüllt“
  Ich habe Simons Test „SVG-Pelikan auf einem Fahrrad“ ausprobiert, und das Ergebnis war ziemlich minimalistisch, erfüllte aber die Anforderungen: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- ausgeführt mit Q4-Quantisierung in einem gepatchten llama.cpp. Ich frage mich auch, ob Simons Ergebnis stark davon abweicht

• Wie würden diffusionbasierte Inferenzmodelle wohl aussehen? Würde man einen [thinking]-Block mit vorab festgelegter Länge lange diffundieren und den finalen Ausgabeblock dann so erzeugen, dass der Inhalt dieses Thinking-Blocks als Teil der Eingabe verwendet wird?
  Und wie legen Diffusionsmodelle überhaupt die Ausgabelänge fest? Ist das ein vorher definierter Parameter, oder wird irgendwo zwischendrin ein [end]-Token diffundiert? Das frage ich mich.

  • Beim Lesen der übrigen Kommentare habe ich auf eine Frage schon eine Antwort gefunden. Es leuchtet ein, dass der Diffusionsprozess selbst im Wesentlichen ein der Inferenz ähnlicher Prozess ist: https://www.inceptionlabs.ai/blog/introducing-mercury-2

• Sieht cool aus, aber auch wenn lokale Modelle inzwischen schon ganz okay sind, fallen sie gefühlt selbst hinter die billigste API noch klar zurück, daher reizt es mich kaum, für mehr Geschwindigkeit auch nur ein wenig Qualität zu opfern.
  Für manche Use Cases hat das sicher einen Wert, aber mich würde ein konkreter Fall interessieren, in dem man das tatsächlich in Production deployen will.

  • Zum Schreiben von Unit-Tests oder fürs Bootstraping könnte es brauchbar sein
    Selbst wenn es nicht Opus-Niveau hat, kann es schreiben, und Iteration ist auch leicht