Gemini Diffusion

 (simonwillison.net)
14 Punkte von GN⁺ 2025-05-23 | 1 Kommentare | Auf WhatsApp teilen
  • Gemini Diffusion, von Google vorgestellt, ist das erste LLM, das statt Transformern einen Diffusion-Ansatz verwendet
    • Ähnlich wie bei Bildmodellen wie Imagen oder Stable Diffusion
  • Das Modell erzeugt Text nicht mit dem klassischen autoregressiven Verfahren, sondern über einen Diffusionsprozess, bei dem Rauschen schrittweise verfeinert wird
  • Das Ergebnis ist eine sehr hohe Antwortgeschwindigkeit; in Experimenten wurden 857 Token pro Sekunde erreicht
  • Genaue Benchmarks fehlen bislang noch, Google behauptet jedoch eine etwa 5-fach höhere Geschwindigkeit im Vergleich zu Gemini 2.0 Flash-Lite

Überblick über Gemini Diffusion

  • Gemini Diffusion ist ein neu vorgestelltes Large Language Model (LLM) von Google
  • Statt des autoregressiven Verfahrens herkömmlicher transformerbasierter LLMs setzt es auf einen Diffusion-Ansatz
  • Dieser Diffusionsansatz funktioniert ähnlich wie bei Bildgenerierungsmodellen (Imagen, Stable Diffusion usw.), wird hier jedoch auf die Textgenerierung angewendet
  • Zu den wichtigsten Merkmalen zählen schnelle Reaktionszeiten und die Fähigkeit, Fehler während des Generierungsprozesses effizient zu korrigieren
  • Im Beispiel mit dem Prompt "Build a simulated chat app" liefert es innerhalb weniger Sekunden HTML+JavaScript und erreicht eine Generierungsgeschwindigkeit von bis zu 857 Token pro Sekunde

Funktionsweise von Diffusions-Sprachmodellen

  • Herkömmliche autoregressive Sprachmodelle erzeugen Token nacheinander, was langsamer ist und die Konsistenz der Ausgabe begrenzen kann
  • Diffusionsmodelle hingegen starten mit Rauschen und verbessern das Ergebnis schrittweise, wobei ganze Sätze oder Absätze in mehreren Stufen auf einmal verarbeitet werden
  • Dadurch wird eine parallele Tokengenerierung möglich, was extrem schnelle Resultate erlaubt
  • Das ist besonders wirksam in Bereichen, in denen unmittelbares Feedback wichtig ist, etwa bei Textbearbeitung, Mathematik und Code

Ähnliche Modelle und Leistungsvergleich

  • Kommerzielle Diffusions-LLMs gab es bisher kaum; im Februar 2024 erschien mit dem Projekt Inception Mercury ein erster Fall
  • Bei Geschwindigkeit und Leistung ist Gemini Diffusion laut Google Gemini 2.0 Flash-Lite ähnlich, aber etwa 5-mal schneller
  • Ähnlich wie Cerebras Coder zeigt es eine hohe Generierungsgeschwindigkeit; objektive Benchmark-Daten sollen später noch ergänzt werden

Zusätzliche Erläuterungen und Korrekturen

  • Diffusions-Sprachmodelle ersetzen die Transformer-Architektur nicht vollständig, sondern ändern die Textgenerierungsstruktur von autoregressiv auf Diffusion
  • Sowohl Mercury als auch Gemini Diffusion basieren auf Transformern, verarbeiten jedoch den gesamten Input auf einmal und unterscheiden sich in der Art der Generierung
  • Es handelt sich um eine Weiterentwicklung des bisherigen BERT-artigen Maskierungs- und Rekonstruktionsverfahrens: Der Maskierungsgrad wird schrittweise erhöht, und selbst wenn alle Token maskiert sind, wird das Ergebnis allmählich vervollständigt
  • Beim Diffusionsansatz werden über mehrere Stufen hinweg jeweils nur einige Token final festgelegt; der Anteil festgelegter Token steigt wiederholt an, bis die gesamte Sequenz vollständig ist
  • Die Kernidee solcher Diffusions-LLMs ist die schrittweise Wiederherstellung bei gleichzeitiger paralleler Generierung

Fazit

  • Gemini Diffusion ist ein neuartiges LLM mit innovativen Eigenschaften bei Geschwindigkeit und Generierungsqualität
  • Es erweitert die bei der Bildgenerierung bewährten Vorteile von Diffusionsmodellen erfolgreich auf den Bereich der Textgenerierung
  • Die Erwartungen an den praktischen Nutzen in unterschiedlichen Einsatzszenarien und an künftige Benchmark-Ergebnisse sind entsprechend hoch

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-23
Hacker-News-Kommentare

  • Ich weiß nicht genau, wie das intern bei Google tatsächlich funktioniert, aber zuletzt gab es rund um RWKV etwas Bemerkenswertes. Es wurde experimentiert, den bisherigen Attention-Mechanismus vollständig durch WKV (lineare Attention) zu ersetzen, und das alles nur per Post-Training. Die Implikation ist, dass der Großteil des nützlichen Wissens wohl tatsächlich im FFN (Feedforward-Netzwerk) steckt und Attention selbst möglicherweise gar nicht so einzigartig oder wichtig ist, wie oft angenommen. Die verlinkten Materialien dazu sind ebenfalls lesenswert. Andererseits wäre es auch interessant, bereits trainierte Attention weiterzuverwenden und in einem Training mit GPT-2-Geschwindigkeit zu testen, wie schnell man nur mit FFN kommt. Das verstößt zwar ein wenig gegen die Regeln, aber ich würde so eine Arbeit gern lesen. Gestern las ich außerdem, dass sich die Embeddings aller Modelle zu einem bestimmten Zeitpunkt als (sehr) ähnlich erweisen, sodass man einen einfachen Konverter trainieren kann. Wenn beides stimmt, könnte man Embeddings und Attention teilen und das gesamte Training erheblich beschleunigen

    • Attention ist, bei allem größten Respekt gegenüber den Forschenden, im Grunde so, als würde man alle bisherigen Informationen des Netzwerks einspeisen und sie durch ein Reverse-MoE-Neuronales-Netz schicken. Der „Experte“ wählt dabei nicht einen Teil des Netzwerks aus, sondern einen Teil der Eingabe zur Ausführung. Dass das funktionieren könnte, war eigentlich klar, aber es war so ineffizient, dass nicht einmal R- oder Python-Nutzer auf die Idee kamen, es praktisch auszuprobieren. Das Training war schlicht zu langsam, um diese Architektur sinnvoll zu testen

    • Ich habe das Gefühl, dass „Attention is all you need“ sich vielleicht als notwendig, aber in einem ganz anderen Sinn interpretieren lässt

    • Die Aussage, dass Modellembeddings sich als (sehr) ähnlich erweisen und per einfachem Konverter abbildbar sind, stammt von hier

    • Ich sehe Attention als eine völlig willkürliche Methode, das Netzwerk aufzuteilen und paralleles Training zu ermöglichen. Der eigentliche Erfolgsfaktor waren die „shortcut connections“ zwischen den Layern. Sie geben den frühen Layern beim Training mehr Einfluss

    • Dass SDPA-Attention in heutigen Transformern relativ wenig unverzichtbar ist, ist bereits bekannt. FFN, Normalisierung und Residual-Verbindungen sind absolut unersetzlich, aber Attention lässt sich leicht durch irgendeine andere Schicht ersetzen, die Informationen zwischen Tokens austauscht, etwa Pooling, Convolution oder Random Mixing

  • Das ist wirklich absurd schnell. Bisher halte ich den besten Einsatz von Modellen für komplett neuen Code und schnelles Prototyping. Für die Verbesserung großer Codebasen, die bereits vielfach iterativ verfeinert wurden, fand ich sie bislang nicht besonders stark. Ein Grund dafür ist, dass ein Modell per Definition nichts über Dinge wissen kann, die nicht in der Codebasis enthalten sind. Dass etwas im Code „nicht vorhanden“ ist, kann ebenfalls ein aussagekräftiges Signal sein, und das ist ziemlich schwer darzustellen. Selbst ein sehr kluges Modell stößt dort meiner Meinung nach an grundlegende Grenzen, weil ihm „interner Kontext und Erfahrung“ fehlen. Wenn man etwa einem extrem talentierten Entwickler eine große Codebasis gibt und ihn bittet, sofort ein bestimmtes Problem zu lösen, kann ein durchschnittlicher Entwickler, der die Codebasis gut kennt, in derselben Zeit oft wertvollere Ergebnisse liefern

    • Wenn man sich auf die Kommunikationsweise konzentriert, lässt sich dieses Problem lösen. Mein wichtigster Workflow derzeit ist: Wenn größere Arbeiten anstehen, etwa neue Features oder Refactoring, beginne ich mit o3 ein Gespräch wie mit einem Kollegen. Ich füge fortlaufend die benötigten Quelldateien als Kontext ein und diskutiere auf höherer Ebene über Ziel und aktuellen Zustand des Codes. Dabei wird sowohl meine Absicht als auch der Kontext der Codebasis klarer. Danach bitte ich o3 um einen Implementierungsplan und übergebe diesen an Codex, das dann eine Reihe automatisierter Schritte ausführt: Quellcode lesen, Dateien ändern, Tests laufen lassen usw. Wenn der PR fertig ist, reicht manchmal noch etwas manuelle Nachbearbeitung, manchmal kann er direkt gemergt werden. Ich stimme zu, dass Modelle reichlich Kontext brauchen, aber das ist keine grundlegende Grenze, sondern eher eine Frage effektiver Zusammenarbeit. Mit genügend Übung steigert das nicht nur die Produktivität, sondern macht mir die Arbeit im Kopf auch angenehmer

    • Mit der Sichtweise, dass „das, was in der Codebasis nicht vorhanden ist, ein bedeutungsvolles Signal trägt“, resoniert bei mir sehr stark. Ich arbeite schon lange mit Software, aber diese grundlegende Wahrheit habe ich noch nie so klar bewusst wahrgenommen. Danke für diesen Gedanken

    • Nach meiner bisherigen Erfahrung sind LLMs gut darin, bestehend guten Code zu imitieren, aber sie erzeugen selten von sich aus neue und originelle Teile, sofern man das nicht ausdrücklich verlangt. Oft können sie die Codebasis nicht tief genug ingestieren, sodass ich andere Projektteile direkt angeben muss. Trotzdem wäre es großartig, wenn man wie bei Stable Diffusion einen „negativen Prompt“ geben könnte

    • Ich frage mich, was herauskäme, wenn ein LLM den kompletten Git-Verlauf, den Issue-Tracker und sogar Meeting-Aufzeichnungen als Kontext lesen könnte. Ob extrem große Kontexteingaben praktisch brauchbare Ergebnisse liefern, muss sich aber erst noch zeigen

  • Diese Ankündigung hat mich wirklich überrascht. Ich halte sie für die größte Ankündigung der IO, schade nur, dass sie von anderen Themen wie Veo 3 überschattet wurde. Dass ein Diffusion-Modell für Codegenerierung eingesetzt wird, ist von enormer Bedeutung. Wenn dafür ein Transformer verwendet wird, wäre das dann ein Modell aus der DiT-Familie (Diffusion Transformer). Ich habe vor ein paar Jahren an einem Hybridmodell mit U-Net-basierter Diffusion mitgearbeitet, und seitdem ist viel passiert. Ich glaube, im Bereich Diffusion steht uns ein großer Sprung bevor

    • Ich frage mich, wie die Intuition aus Vision Transformern auf Code übertragen werden kann. In der Bildverarbeitung beginnt man mit Rauschen und erzeugt schrittweise, Schicht für Schicht, ein immer schärferes Zielbild. Überträgt man dieses Prinzip auf Codegenerierung, scheint eine hierarchische Struktur nötig zu sein, die die Abstraktion stufenweise senkt, etwa: „Django verwenden“, „Liste der Endpunkte festlegen“, „konkreten Code erzeugen“. Diffusion hat aber keinen Backtracking-Mechanismus, sodass Probleme auf niedriger Ebene nur begrenzt sofort an höhere Layer zurückgemeldet werden können. Transformer hingegen lassen für jedes Token das gesamte Modell laufen, wodurch Backtracking und Designänderungen je nach Problem leichter möglich sind. Vielleicht ist mein Modell hier fehlerhaft, daher würde ich gern weitere Einsichten hören

    • Veo 3 wurde zum Gesprächsthema, weil Leistung und Differenzierung dort sehr intuitiv sichtbar sind. Den Wert wichtiger Fortschritte bei Text Completion zu verstehen, setzt dagegen voraus, dass man die bisherigen Ergebnisse und potenziellen Einsatzmöglichkeiten kennt. Viele sind sich noch nicht einmal sicher, dass LLMs fürs Coden überhaupt nützlich sind

    • Diffusionsbasierte Codegenerierungsmodelle sind wirklich revolutionär. Ein paar einfache Ideen dazu, was solche Modelle tun könnten: Funktionssignaturen und Ergebnisse fixieren und die Tokens dazwischen generieren, also bidirektionale Information nutzen. Zweitens zunächst den groben Umriss einer Funktion schreiben, ähnlich wie ein LLM die „Kapitel“ eines Artikels schreibt, und danach die Implementierung immer weiter ausarbeiten. Iterative Generierung im größeren Kontext, gesteuert durch Signale wie Linter oder AST-Informationen. Es gibt wirklich sehr viel zu experimentieren

    • Prinzipiell scheint diese Methode große Vorteile zu haben, und Modelle wie LLaDA, die ich selbst ausprobiert habe, waren trotz geringer Trainingsressourcen beeindruckend. Bei Kennzahlen wie Perplexity liegen sie aber noch zurück. Während der Generierung neigen sie stark zum Einfrieren, daher scheint das tiefe Überarbeiten von Text begrenzt zu sein; je höher die Maskierungswahrscheinlichkeit, desto schwieriger werden gleichzeitige Änderungen. Dennoch habe ich in echten Experimenten ziemlich praktische Ergebnisse erhalten

    • Ich habe bereits Demos von InceptionLabs und anderen gesehen, deshalb finde ich es nicht ganz so überraschend

  • Ich habe das Gefühl, dass der Kern dieser Meldung untergeht. Das ist ein wirklich schnelles und starkes InstructGPT. Es wird künftig definitiv für Rechtschreibprüfung, Codemods und Code-Editoren verwendet werden. Dank der Instant-Edits-Funktion sind wirklich schnelle und präzise Textbearbeitungen möglich, ohne unnötige Ergänzungen oder Vorschläge. Ich habe ein ShaderToy-Beispiel gebeten, die Variablennamen verständlicher zu machen, das Ergebnis kopiert und ausgeführt, und es funktionierte immer noch einwandfrei. Das hat mich überrascht

    • Ist Rechtschreibprüfung nicht schon längst ein vollständig gelöstes Problem?

  • Der Vorteil von Diffusion liegt nicht nur in der Geschwindigkeit. Laut ersten Benchmarks ist sie bei gleicher Parameterzahl AR auch bei Inferenz und Planung überlegen. Diffusion erlaubt Zwischenbearbeitungen und leidet nicht unter dem Bias früher Tokens

    • Interessante Behauptung. Kannst du dazu Benchmarks oder Belege verlinken?

    • AR an sich verhindert keine langfristige Planung, aber in der konkreten Implementierung aktueller populärer AR-Modelle treten solche Grenzen oft auf. AR ist grundsätzlich sehr wichtig, um die richtige Verteilung zu lernen

    • Ich würde dem gern zustimmen oder hoffen, dass es stimmt, aber ich habe noch keine Papers oder Demos zu revise diffusion text gesehen. Ich würde das gern ausprobieren, also wären Paper-Hinweise willkommen

  • Ich interessiere mich schon lange dafür, Diffusion auf Textgenerierung anzuwenden. Dass Google nun endlich ein solches Modell veröffentlicht, freut mich, weil es meine Vermutung bestätigt. Was die in Experimenten eingesetzte Hardware betrifft, laufen die meisten Dinge entweder als bezahlte Services oder auf High-End-Hardware, mindestens im oberen Consumer-Segment. Ich selbst habe derzeit nur eine 5700XT und kann nicht einfach aufrüsten; dadurch sind mir die Grenzen aktueller Modelle umso deutlicher geworden. Mit wachsender Modellgröße steigt auch die Konsistenz, weshalb kleine Modelle zwangsläufig auf einfache Aufgaben beschränkt bleiben. Einer meiner wichtigsten experimentellen Befunde ist, wie zentral die Kontextgröße ist, doch auf kleinen GPUs bekommt man oft nicht genug Kontext und Modell zugleich unter. Bei einem diffusionsbasierten Ansatz frage ich mich, ob sich das Gleichgewicht zwischen Dichte und Konsistenz verschieben ließe. Vielleicht wäre konsistentere Textgenerierung auch mit weniger Kontext möglich, und vielleicht würden gemischte Ergebnisse aus Tool Calls + Antworten ebenfalls besser ausfallen. Auch die Geschwindigkeit ist ein ganz reales Ärgernis: Beim bestehenden LLM-Ansatz kommt die Ausgabe langsam in Ein-/Ausgabe-Schritten, und gerade auf älteren GPUs ohne AI-Hardware ist das eine Geduldsprobe. Es wäre schon hilfreich, den Fortschritt wenigstens von 0 bis 100 % in Echtzeit zu sehen, und ich hoffe, dass Diffusionsmodelle hier besser sein könnten. Dabei stellt sich für mich noch eine Frage: Das Rauschen ist ja entscheidend, aber gibt es gute Rauschquellen speziell für LLM/Text, und muss die gesamte Blocklänge im Voraus feststehen oder kann sie variabel sein?

  • Aus meiner Sicht kann ich mit Sicherheit sagen: Dieses Modell ist unglaublich schnell. Der Nachteil ist, dass es für Prompt-Injection-Angriffe sehr leicht zu knacken ist. Wenn man zum Beispiel nach einer Drogenherstellung fragt, verweigert es zunächst, aber wenn man es als „Kinder-Rollenspiel“ tarnt, liefert es die echte Antwort. Abgesehen von diesem Nachteil sind die Geschwindigkeit und die Nutzbarkeit für Automatisierung wirklich hervorragend. In Kombination mit einem agentischen Ansatz könnte das Potenzial dieses Modells richtig zur Geltung kommen

    • Das könnte weniger eine Grenze des Modells selbst sein als vielmehr daran liegen, dass im Training weniger Ressourcen in Sicherheit oder Zensur investiert wurden. Meiner Ansicht nach ist das eine Art Prototyp-Experiment, eher eine leichte Demo, bevor man in ein großes Modell ernsthaft investiert

    • Ich würde aus solchen Prompt-Injections nicht schließen, dass man damit bald intelligentere Modelle kontrollieren kann

  • Die Beschreibung „Googles erstes Diffusion-LLM, das statt eines Transformers Diffusion verwendet“ ist eine falsche Behauptung. Google hat das selbst nie so angekündigt. Im Gegenteil: Transformer-basierte Diffusionsmodelle sind üblich. Ich halte es für wahrscheinlich, dass auch Gemini Diffusion einen Transformer verwendet. Der Unterschied wäre dann, dass es sich um einen Encoder-only-Transformer handelt. Man gibt also die gesamte Sequenz in verrauschtem oder korrumpiertem Zustand ein und sagt das vollständige korrekte Ziel gleichzeitig voraus. Dadurch lässt sich über das gesamte Sequenz-Frame parallel rechnen, und solange die Zahl der Iterationen moderat bleibt, ist das viel schneller als die sequentielle Dekodierung von Decoder-only-Modellen, auch wenn spekulatives Decoding ähnliche Geschwindigkeitsvorteile bringen kann. Üblicherweise wird mit BERT-artigem Masking trainiert, aber das ist weiterhin ein sehr aktives Forschungsfeld. Mich interessiert auch, wie genau die Beziehung zu Gemini aussieht und ob vorhandene Checkpoints genutzt wurden, also direkte Übernahme, diffusionsspezifisches Fine-Tuning, Wissensdestillation oder einfach nur Branding. Ich wünschte, die offiziellen Details wären veröffentlicht

  • Lächerlich schnell. Ich vermute, dass die GPU dabei ständig auf voller Auslastung läuft und dass es bei Batch-Verarbeitung kaum Rechenersparnis gibt. Andererseits ist das, wenn man darüber nachdenkt, nicht wirklich ein Trade-off im eigentlichen Sinn. Eine Sorge bleibt allerdings: Das Diffusion-Objective könnte bei der Leistungsfähigkeit hinter AR zurückliegen. Falls das stimmt, könnten Multi-Token-AR-Modelle dieselbe Geschwindigkeit erreichen wie Diffusion, oder man könnte Diffusionsmodelle als Entwurfs-Generatoren für spekulatives Decoding einsetzen

    • Mich würde interessieren, warum du glaubst, dass dLLMs qualitativ hinter arLLMs zurückliegen würden. Da die Ausgabe wiederholt als „strukturierte Gesamtheit“ verarbeitet wird, also Thema, Kernaussagen, Konzepte und Wortbaum, könnte die Qualität meiner Meinung nach sogar besser sein

    • Dieser strukturelle Trade-off ist für Self-Hosting deutlich vorteilhafter. Dort braucht man keine großen Batches, also ist der Vorteil in der Cloud kleiner, für lokale LLMs aber erheblich

  • Ich bin extrem begeistert von Diffusion-LLMs. Unser Team träumt von Spielmechaniken, die per Stimme direkt zu Code werden, und Diffusion könnte genau das fehlende Puzzlestück sein. Cerebras und Groq sind beeindruckend, aber durch ihre Custom-Hardware gibt es Grenzen beim Fine-Tuning und der Skalierung. Die übrigen Alternativen sind MoEs mit etwa 0.5b aktiven Parametern, aber aktuell haben wir nicht die Ressourcen, um in dieses Projekt voll einzusteigen. Falls jemand von Google oder DeepMind das liest: Bitte stellt unbedingt eine API bereit. Unser Team entwickelt ein generatives Sandbox-Spiel, und im ersten Titel gibt man Monstern in Echtzeit Befehle. Wir haben auch ein Prototyp-Video, das sich anzusehen lohnt