Jeder 'Schnellere KI'-Trick war nur ein Workaround. DiffusionGemma ist das erste Modell, das wirklich läuft.

Ein Token nach dem anderen vorhersagen. Das war schon immer die Bremse für alle Modelle, auch die lokalen.

Das Problem hatte nichts mit unzureichender Hardware oder zu kleinen Modellen zu tun. Es war architektonisch bedingt, von Anfang an eingebacken.

Um jeden Token zu generieren, lädt deine GPU alle Modellgewichte aus dem Speicher, produziert 1 Token und fängt von vorne an. Dieser Memory-Bandwidth-Flaschenhals ist der Grund, warum lokale Inferenz selbst auf ordentlicher Hardware frustrierend blieb. Und warum 5 Jahre Optimierungen (Flash Attention, Quantisierung, Speculative Decoding) alle um dieselbe strukturelle Decke herumgearbeitet haben, ohne sie jemals zu verschieben.

Es passiert etwas, wenn du merkst, dass du die richtige Metrik auf der falschen Ebene optimiert hast. Flash Attention war ein echter Durchbruch, INT4-Quantisierung war ein echter Durchbruch, und die H100 für 40.000 Dollar pro Karte war ein echter Durchbruch für alle, die sie sich leisten konnten. Und nichts davon hat die fundamentale Beschränkung verschoben. Die Gewichte mussten immer noch für jeden einzelnen Token geladen werden. Die Tensor Cores der GPU, designed für massive parallele Matrix-Operationen, saßen während der Inferenz größtenteils untätig herum und warteten auf den nächsten Memory-Zyklus. Jeder Ingenieur, der lokale Inferenz auf einer High-End-Consumer-GPU laufen ließ, spürte das als eine Art unterschwellige Frustration: die Zahlen sollten aufgehen, tun sie aber nicht ganz.

Das Rennen, das niemand hinterfragte

Flash Attention kam 2022 raus. Wirklich brillant: die Attention-Berechnung I/O-bewusst umgeschrieben, Zwischenwerte im SRAM gehalten statt ständig zurück ins HBM zu schreiben. Echte Speedups, messbar, innerhalb von 18 Monaten überall deployed. Das Paper bekam in etwa 2 Jahren 15.000 Zitierungen.

Dann baute das Feld weiter Schichten auf dasselbe Fundament. INT4-Quantisierung, GGUF, Speculative Decoding, Groqs LPU von Grund auf für AR-Inferenz gebaut, H100s für 40.000 Dollar pro Karte, dann H200s, dann GB200s. Ganze Unternehmen mit Milliardenbewertungen auf der Prämisse, dass AR schneller zu machen das Problem war, das es zu lösen galt. Groq baute Custom Silicon von Grund auf für AR-Inferenz, und die Industrie nannte es visionär. Niemand im Raum schlug vor, dass vielleicht die Architektur selbst die Frage war.

Die ganze Industrie organisierte sich um einen einzigen Flaschenhals. Niemand hinterfragte, ob der Flaschenhals architektonisch bedingt war.

Fairerweise: warum hätten sie auch? Die Modelle liefen, die Produkte funktionierten. Der Training-Stack, die Inference-Serving-Infrastruktur, das CUDA-Kernel-Ökosystem, jedes Deployment-Pattern von vLLM bis TGI bis Ollama, alles um autoregressive Next-Token-Prediction gebaut. Die Architektur von innerhalb dieses Ökosystems zu hinterfragen ist wie zu fragen, ob Autos Räder haben sollten, während man gerade einen schnelleren Reifen designed. Die Switching-Kosten waren nicht nur technisch. Es waren die akkumulierten Sunk Costs der Industrie: jeder CUDA-Kernel, jede Serving-Optimierung, jeder Hardware-Kauf, der gegen AR-Throughput-Zahlen gerechtfertigt wurde.

Inception Labs war das erste Unternehmen, das tatsächlich etwas anderes auslieferte. Mercury kam Anfang 2025 raus, Mercury 2 Anfang 2026, 1.000+ Token pro Sekunde. Wirklich beeindruckende Zahlen. Völlig unzugänglich: kommerzielle API, geschlossene Gewichte, du konntest es nicht selbst laufen lassen. Nützlich als Marktsignal, nicht umsetzbar für alle, die auf ihrer eigenen Hardware bauen.

DiffusionGemma kam am 10. Juni 2026 raus, offene Gewichte unter Apache 2.0, vLLM-Support ab Tag 0, läuft auf einer RTX 4090.

Für die Developer-Community bedeutet "erstes offenes Release von einem Tier-1-Lab" Tag-0-vLLM-Support, eine HuggingFace-Model-Card, Unsloth-Integration und eine Community, die innerhalb von Tagen interessante Fine-Tunes rausbringen wird. Die Lücke zwischen einem Research-Paper und etwas, womit du tatsächlich bauen kannst, schloss sich etwa 18 Monate schneller als erwartet, als Gemini Diffusion auf der I/O 2025 als Experiment angekündigt wurde.

Das ist der Unterschied zwischen "jemand hat bewiesen, dass es theoretisch funktioniert" und "du kannst die Gewichte heute Nacht pullen."

5 Jahre Workarounds. Der eigentliche Fix lief gestern auf deiner GPU.

Was DiffusionGemma tatsächlich ändert (und was nicht)

Die AR-Inferenz-Schleife ist memory-bound. Um 256 Token zu generieren, lädt deine GPU die vollständige Gewichtsmatrix 256 Mal aus dem Speicher, 1 Ladung pro Token. Die Tensor Cores, designed für parallele Matrix-Multiplikationen im Massivmaßstab, führen ihre eigentliche Berechnung in etwa 1% der Gesamtzeit aus. Die anderen 99% warten darauf, dass Daten aus dem VRAM ankommen. Stell dir vor, du besetzt eine Küche mit Michelin-Stern-Köchen und leitest jeden einzelnen Teller zwischen den Gängen durch ein 300 Meter entferntes Lager. Das ist deine H100 bei AR-Inferenz. Deshalb führte die Skalierung der theoretischen FLOPS einer GPU selten linear zu Inferenz-Geschwindigkeit: du warst nicht compute-bound, sondern memory-bound, und eine Karte mit mehr Tensor Cores zu kaufen half weniger als eine mit höherer Memory Bandwidth. Jede Optimierung von Flash Attention an arbeitete daran, diese 99% Wartezeit zu verkürzen, nicht sie zu eliminieren. Die Decke war immer dieselbe Decke, nur aus einem etwas anderen Winkel angenähert.

DiffusionGemma lädt die Gewichte einmal pro Denoising-Pass und generiert 256 Token parallel. Der Flaschenhals verschiebt sich. Die Tensor Cores sind jetzt die eigentliche Decke und führen bidirektionale Attention über den vollen 256-Token-Block bei jedem Forward-Pass aus. Dafür wurden diese Chips designed. Die Memory-Bandwidth-Wand verschwindet nicht, sie hört auf, das zu sein, was dich limitiert.

Zahlen von Google und NVIDIA: 700+ Token/Sek auf RTX 5090, 1.000+ auf H100, 4x schneller als Gemma 4 AR auf äquivalenter Hardware. Das Modell hat 26B Parameter als Mixture of Experts, 3,8B aktiv während der Inferenz, läuft in 18GB VRAM wenn quantisiert.

Die Einschränkungen sind real und sollten klar benannt werden.

DiffusionGemma liegt bei Reasoning-Benchmarks um eine bedeutsame Spanne hinter Gemma 4 AR zurück. AIME 2026: 69,1% vs 88,3%. LiveCodeBench v6: 69,1% vs 77,1%. GPQA Diamond: 73,2% vs 82,3%. Das sind 15-20-Punkte-Lücken bei schweren Reasoning-Tasks, keine Rundungsfehler.

Das Context Window ist 8.192 Token. Die meisten aktuellen AR-Modelle laufen bei 128K+. Für alles Agentische oder Long-Context ist das eine echte Wand. Eine mäßig komplexe TypeScript-Datei frisst 3.000 Token. 3 Dateien und du bist bereits an der Decke.

Google selbst nennt es "experimentell". Fine-Tuning-Rezepte wurden beim Launch noch veröffentlicht. MLX-Support für Apple Silicon war an Tag 0 unvollständig. Für High-Volume-Cloud-Serving batchen AR-Modelle im Maßstab immer noch effizienter.

Die Performance ist real, und die Decke auch. Die Frage ist, ob die Decke für deinen Use Case relevant ist.

Der Beweis jenseits der Geschwindigkeit

Ein Sudoku-Brett hat 81 Felder. Jedes ist gleichzeitig durch seine Reihe, seine Spalte und sein 3x3-Quadrat beschränkt. Um es korrekt zu lösen, musst du alle diese Beschränkungen gleichzeitig im Blick behalten.

Ein autoregressives Modell generiert 1 Feld nach dem anderen, von links nach rechts, von oben nach unten. Wenn es Feld 72 ausfüllt, kann es nicht zurückgehen und Feld 3 korrigieren. Es konditioniert nur auf das, was es bereits generiert hat. Das ist kein Fehler der Skalierung oder ein Training-Data-Problem. Es ist eine strukturelle Eigenschaft sequenzieller Generierung. Du kannst ein AR-Modell größer, schneller, besser im Pattern Matching machen, und es wird trotzdem Felder ohne globale Constraint-Resolution ausfüllen, weil es strukturell nicht vorausschauen kann.

Google führte einen direkten Test dazu durch. DiffusionGemma Basis-Modell auf Sudoku-Puzzles: 0% Erfolgsrate. Standard-SFT-Fine-Tuning mit einem JAX-Rezept auf einem Sudoku-Dataset: 80% Erfolgsrate, mit 4x weniger Inferenz-Schritten als die Baseline.

Die Verbesserung kam von bidirektionaler Attention, nicht von roher Geschwindigkeit. Jeder Token im 256-Token-Block attendiert zu jedem anderen Token während der Generierung. Das Modell sieht das ganze Brett auf einmal. Es propagiert Constraints über den vollen Block bei jedem Denoising-Pass und korrigiert sich selbst, bevor der Output finalisiert wird.

Ich denke, hier wird die langfristige Bedeutung von Diffusion-LLMs unterschätzt, selbst in der Launch-Coverage. Die Geschwindigkeitszahlen bekommen die Schlagzeilen. Die Bidirektionalität ist die interessantere Eigenschaft.

Deine Codebase ist schwieriger als ein Sudoku-Brett. Jede Funktion ist durch die Typen, die sie zurückgibt, die APIs, die sie aufruft, die Verträge, die sie implizit über Dateien hinweg annimmt, beschränkt. Code Infilling (eine Funktions-Body ausfüllen, gegeben was davor und danach kommt) ist strukturell genau dieses Problem. AR-Modelle handhaben Infilling durch ein spezielles Fill-in-the-Middle-Training-Objective, was ein Workaround für die direktionale Beschränkung ist. DiffusionGemma handhabt es architektonisch. Dieselbe Problemklasse, andere Ebene des Fixes. Dasselbe Muster zeigt sich bei SQL-Schema-Migrationen, Config-File-Generierung, allem wo du Struktur mit harten Constraints auf beiden Seiten ausfüllst. Eine Migration, die eine Spalte hinzufügt, muss sowohl mit dem bestehenden Schema als auch mit den nachgelagerten Queries, die darauf referenzieren, konsistent sein. AR generiert von links nach rechts ohne frühere Entscheidungen basierend auf späteren Constraints zu überdenken. Du kannst das mit sorgfältigem Prompting und Multi-Pass-Generierung umgehen. Workarounds, jeder einzelne davon.

Ich verbrachte 3 Monate damit, subtil inkonsistente Type Signatures über Dateien hinweg in Claude Code Sessions zu verfolgen. Das Context Window spaltete die relevanten Verträge zwischen 2 Sessions auf. Bidirektionale Attention innerhalb eines Generierungs-Blocks löst Cross-File-Kohärenz nicht vollständig, aber es verschiebt, wo die Inkonsistenz entsteht. Anderes Problem, anderer Fix.

Wann wechseln, wann bleiben

Die Arbitrage für einen Builder, der täglich Claude Code nutzt, sieht so aus.

DiffusionGemma macht Sinn für Tasks, wo der Flaschenhals Throughput bei kurzen bis mittleren Outputs mit strukturellen Constraints ist: Boilerplate-Generierung in Batches, Code Infilling wo der umgebende Kontext verfügbar ist, strukturierte Templates ausfüllen (API-Schemas, Config-Files, Migration-Stubs), schnelle Iterationszyklen wo du 10-20 Varianten unter 4.000 Token regenerierst. Das Modell ist jetzt draußen, offene Gewichte unter Apache 2.0, vLLM-ready, deploybar auf RTX 4090. Variable API-Kosten für diese Tasks gehen gegen null. Die Ökonomie verschiebt sich auf spezifische und reale Weise für High-Repetition-Local-Workflows.

Bleib bei Claude für Multi-Step-Reasoning-Chains, Debugging das Logic-Tracing über viele Schritte erfordert, Architektur-Entscheidungen die großen kohärenten Kontext brauchen, jeden Production-Task wo du mehr als 8K Token in einem einzigen Pass brauchst, alles im reasoning-heavy Tier wo diese 15-20-Punkte-Differenz der Unterschied zwischen einem nützlichen Output und einer plausibel aussehenden falschen Antwort ist.

Die Context-Window-Beschränkung ist der echte praktische Limiter. 8.192 Token klingen nach viel, bis eine einzige mäßig komplexe Datei 3.000 davon nimmt. Das ist kein Fine-Tuning-Problem. Es ist in die aktuelle Generation Block Size eingebacken. Zukünftige Versionen werden das nach oben drücken. Vorerst macht es DiffusionGemma zu einem task-spezifischen Tool, nicht zu einem allgemeinen Drop-in.

Karen aus der Buchhaltung würde fragen, ob das eine zweite GPU rechtfertigt. Die ehrliche Antwort: wenn du bereits einen lokalen Model-Stack auf einer RTX 4090 laufen hast, ist es eine Pull-and-Test-Situation, keine Hardware-Entscheidung. Wenn du bei null anfängst, erfordert der Breakeven bei dedizierter Hardware vs API-Credits echte Throughput-Zahlen aus deinem realen Workflow, nicht Begeisterung über den Benchmark 😅. Das JAX-Fine-Tuning-Rezept im Developer Guide ist gut genug dokumentiert, dass ein 500-Sample-SFT-Experiment in einer spezifischen Domain ein Wochenend-Projekt ist (machbarer als "ich werde das dieses Wochenende in Rust umschreiben" jedenfalls).

Auf der Infra-Seite: wenn du bereits Tasks über verschiedene Model-Backends routest, wird das Pattern hinter CLI-native Agents für throughput-sensitive Workloads bauen relevanter mit einem lokalen Diffusion-Backend im Mix. DiffusionGemma fügt sich sauber in diese Architektur ein.

Die Annahme, die du nie hinterfragt hast

Ich habe eine WooCommerce-Integration in meiner Pipeline, die Distributor-CSV-Feeds in einem Format parst, das sich seit 2019 nicht geändert hat. Ich habe die umgebende Infrastruktur 3 Mal neu gebaut. Der CSV-Parser ist immer noch dieselbe Funktion, dieselbe Spaltenreihenfolge, derselbe Regex-Workaround für einen Edge Case, den ich 2021 fand. Niemand fasst ihn an, weil er funktioniert. Die Frage "sollte das 2026 immer noch ein CSV-Parser sein" wurde nie gestellt. Irgendwann hörte es auf, eine Entscheidung zu sein und wurde zu Mobiliar.

Jeder Stack hat Mobiliar.

Das Muster zeigt sich jedes Mal, wenn eine technische Beschränkung lange genug stabil bleibt, um unsichtbar zu werden. 2023 bedeutete lokale Inferenz, ein 7B-Modell zu laden und Token mit 3 pro Sekunde ankommen zu sehen. Die Latenz machte es für alles Interaktive unbrauchbar. Entwickler probierten es, fanden es unpraktisch, wechselten zu API-Calls, und die Entscheidung verfestigte sich: lokale Inferenz ist für Hobbyisten, echte Arbeit geht über die API. Was niemand in diese Entscheidung kodierte, war das Ablaufdatum. "Lokale Inferenz ist langsam" klingt wie ein Fakt über Physik. "Lokale Inferenz auf 2023-Hardware mit 2023-Modellen war zu langsam für diesen Use Case" ist eine Behauptung über einen spezifischen Kontext, und spezifische Kontexte ändern sich.

AR wurde nicht über Diffusion gewählt, weil jemand einen Vergleich durchführte und schloss, dass es besser war. Es wurde gewählt, weil Diffusion-Text-Generierung nicht machbar war. Die Annahme "wir nutzen AR" war eine pragmatische Beschränkung, die unsichtbar wurde, sobald sie nicht mehr bestritten wurde.

Wenn du durcharbeitest, welche Defaults in deinem Stack es wert sind, überdacht zu werden, ist wie ich Routing-Entscheidungen mit Prompt Contracts intentional machte wo ich anfing. Oder wenn der Stack selbst neueres Territorium ist, behandelt Vibe Coding, For Real das Bauen auf expliziten Prinzipien von Anfang an, kostenlos verfügbar auf Kindle Unlimited.

Für die Builder: wenn dein Workflow eine repetitive Generierungs-Schicht mit strukturellen Constraints hat, fang mit dem Sudoku-Fine-Tuning-Rezept im Developer Guide an. Lass es laufen, schau was sich zwischen 0% und 80% Genauigkeit ändert, und frag dich, was das für deine eigenen constraint-heavy Tasks bedeutet.

Die Routing-Entscheidung ist jetzt eine echte Architektur-Entscheidung: nicht welche API diesen Monat billiger ist, sondern welche strukturelle Beschränkung dieses Modell auflösen kann, die das andere architektonisch nicht kann.

Quellen

• DiffusionGemma: The Developer Guide, Google Developers Blog, 10. Juni 2026
• Run DiffusionGemma on NVIDIA, NVIDIA Technical Blog, 10. Juni 2026
• DiffusionGemma benchmarks, Unsloth, Juni 2026
• Google's DiffusionGemma: first open diffusion release from a tier-one lab, Decrypt, 10. Juni 2026

Dieser Post könnte Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern).