Summary: Google open-sourced DiffusionGemma on June 10, 2026 under Apache 2.0, reporting text generation up to 4x faster than autoregressive models and over 1,000 tokens per second on one H100. The 26B-A4B MoE fits about 18GB VRAM when quantized but trails Gemma 4 on most quality benchmarks. Google recommends standard Gemma 4 when top quality matters and notes high-QPS serving can erase the speed gain.
Google put an experimental open model on the board on June 10, 2026: DiffusionGemma. With it, text diffusion enters the Gemma family for the first time. The design sits on Gemma 4, the research draws on the company’s Gemini Diffusion work, the license is Apache 2.0, and the weights are already up on Hugging Face as google/diffusiongemma-26B-A4B-it.
One selling point, and it hits hard: speed. On dedicated GPUs, text generation runs up to 4x faster than autoregressive models — a single NVIDIA H100 clears 1,000 tokens per second, and a consumer RTX 5090 gets past 700.
Where the Diffusion Speedup Comes From
An autoregressive model writes one token per step, and that is exactly what pins the bottleneck to memory bandwidth. DiffusionGemma works differently: it writes onto a “canvas” — 256 random placeholder tokens go down first, then refinement runs in repeated passes, with every pass locking in the tokens it has settled on and carrying them forward as context until the whole output converges. Bidirectional attention means each token can look at all the others, and the bottleneck shifts from memory bandwidth to raw compute. The model card spells out the implementation: an autoregressive encoder takes care of prefill and keeps the KV cache, while the decoder runs bidirectional attention over the canvas; in low-batch, FP8 settings a single H100 goes beyond 1,100 tokens per second.
Generating in both directions also suits non-linear jobs: in-line editing, code infilling, amino acid sequences, and math graphs all fit. A fine-tune from Unsloth even solves Sudoku — a task Google itself flags as one autoregressive models handle badly.
The 26B-A4B MoE Built to Fit a Consumer Card
On paper, this is a 26B-A4B mixture of experts. The model card counts roughly 25.2B parameters in total with 3.8B active on each forward pass; 8 of the 128 experts are picked every time, alongside 1 shared expert. It is multimodal, too — an image-text-to-text model with a vision encoder of about 550M parameters, video input up to 60 seconds, a 256K-token context window, and a 262K vocabulary; 35+ languages work out of the box (140+ were covered in pretraining). Once quantized, it “fits comfortably” within the 18GB VRAM of high-end consumer GPUs. The encoder-decoder split is where the practical payoff sits: prefill behaves like any autoregressive model with its KV cache intact, so long prompts never pay a diffusion penalty — only the generation phase runs on canvases.
What the Quality Bar Gives Up: Gemma 4 Still Leads
Google puts the trade on the table itself. Against the same-architecture Gemma 4 26B-A4B: MMMU Pro lands at 54.3% against 73.8%, AIME 2026 without tools at 69.1% against 88.3%, GPQA Diamond at 73.2% against 82.3%, and MMLU Pro at 77.6% against 82.6%. The lone win is HLE without tools, 11.0% against 8.7%. The guidance that follows is blunt: when top quality is the goal, use standard Gemma 4. The speed story has edges, too — the figures describe local, low-concurrency inference. In high-QPS cloud serving, parallel decoding runs into “diminishing returns and can result in higher serving costs,” and Apple Silicon machines with unified memory may miss the same speedup because of their lower compute-to-memory bandwidth ratio. For sampling, Google’s pick is Entropy-Bounded Denoising: no more than 48 steps, with temperature sliding from 0.8 down to 0.4. That tuning recipe is a reminder that serving a diffusion model is its own operational discipline — step counts and entropy bounds take over the dials that temperature and top-p used to own.
Around the Model: Serving and Fine-Tuning
For serving, the model runs through MLX, vLLM (backed by Red Hat), and Hugging Face Transformers, while llama.cpp is listed as “arriving soon.” Fine-tuning comes in three routes: Hackable Diffusion (JAX), Unsloth, and NVIDIA NeMo. In the cloud, it already sits in the Gemini Enterprise Agent Platform Model Garden and on NVIDIA NIM, with NVFP4 kernels built for RTX 5090/4090, Hopper, and Blackwell — hardware that spans DGX Spark, DGX Station, and RTX PRO workstations.
How Developers Should Read It
Three points worth keeping. One, this is not a replacement for the model you use every day — it is a quick lane for specific jobs: local inference, in-line edits, code infilling, anything that gains from whole-canvas context. Two, once llama.cpp support actually lands, what consumer hardware can do for text generation gets redrawn; an 18GB VRAM floor puts most gaming cards in range. Nor should it be read as anyone’s default cloud serving flipping to diffusion — the 4x figure is a low-concurrency result, and multi-tenant GPU economics answer to a different equation. Three, by open-sourcing the diffusion route under Apache 2.0, Google has effectively asked the whole ecosystem to stress-test this architectural bet (see also: our 2026 opening outlook).