Google DiffusionGemma: First Open-Weight Text Diffusion

Google DiffusionGemma is Google DeepMind’s first open-weight text diffusion model, released on June 10, 2026 under an Apache 2.0 license. It is a 26B mixture-of-experts model — roughly 3.8B active parameters per pass — that abandons left-to-right token generation for a parallel, block-by-block denoising process, reaching a vendor-stated 1,100-plus tokens per second on a single NVIDIA H100.

The reason this matters is the architecture, not the leaderboard. Autoregressive models — every GPT-style LLM you have used — emit one token at a time, bottlenecked by memory bandwidth. DiffusionGemma instead starts each 256-token block as random placeholders and iteratively refines the whole block in parallel, saturating compute instead of waiting on sequential memory reads. That is what produces the speed. It is also why the model can look back and forward inside a block, fixing its own mistakes mid-generation.

This guide covers what actually shipped, how discrete text diffusion works in plain terms, the architectural tradeoff against autoregressive models, the honest benchmark picture — Google itself recommends Gemma 4 when quality matters — and a workload routing matrix so you know exactly which tasks belong on DiffusionGemma. Every figure is sourced from Google’s announcement, developer docs, and the official model card, with vendor-stated numbers labelled as such.

DiffusionGemma launched as google/diffusiongemma-26B-A4B-it on Hugging Face under Apache 2.0, with same-day availability on Kaggle, Google Cloud Vertex AI Model Garden (corroborated via secondary coverage rather than the primary release notes), and NVIDIA NIM. The named research scientists are Brendan O’Donoghue and Sebastian Flennerhag at Google DeepMind. There is no dedicated DiffusionGemma arXiv preprint as of this writing — the canonical references are the Google blog and the official model card, with the block-diffusion technique itself rooted in the BD3-LMs paper (arXiv:2503.09573), an ICLR 2025 Oral.

Under the hood it is a 25.2B-parameter mixture-of-experts with 30 transformer layers, 8 active experts of 128 total plus 1 shared expert, and roughly 3.8B active parameters per forward pass. It carries a 262,144-token vocabulary, a 256K-token context window, and an approximately 550M-parameter vision encoder. It accepts text, images, and video up to 60 seconds at 1fps; it does not accept audio input and generates text only. The training data spans web documents in 140-plus languages, code, mathematics, and images, with a January 2025 cutoff — so its world knowledge is over a year stale at launch.

A standard language model is a typewriter: it predicts one token, commits it, then predicts the next conditioned on everything written so far. DiffusionGemma works the other way. It begins each 256-token block — Google calls it a “canvas” — as random placeholder tokens, then iteratively denoises the whole canvas at once, locking in the tokens it is most confident about and using them as context to refine the rest. When the block converges, it commits that block to the KV cache and starts the next canvas. This is the block-autoregressive interpolation between pure autoregression and pure diffusion that BD3-LMs introduced.

The recommended inference recipe is concrete: up to 48 denoising steps per canvas, a linear temperature schedule decaying from 0.8 to 0.4, and an entropy threshold of 0.005 for adaptive early stopping so easy blocks finish in fewer steps. Each forward pass refines the full canvas and commits roughly 15–20 tokens; at low batch sizes those passes compound into the headline throughput. Two attention regimes are in play: causal attention during the prefill stage that encodes your prompt into the KV cache, then bidirectional attention during denoising — and that bidirectionality is precisely what lets the canvas self-correct, because every position can see both directions.

The clearest demonstration of why iterative refinement is more than a speed trick is a Sudoku fine-tuning demo Google published. The base model solved essentially 0% of Sudoku puzzles; after fine-tuning, it reached an 80% success rate and solved puzzles in 12 denoising steps versus 48 for the base model. Constrained problems that stump a left-to-right model — where an early wrong digit poisons everything downstream — suit a model that can revisit and rewrite the whole grid as a unit. Built-in thinking mode and function calling are both supported, though each adds overhead worth profiling before you enable it in a throughput-sensitive pipeline.

The two paradigms differ on more than speed. The table below operationalizes the tradeoffs so an engineering decision-maker can reason about where each one belongs, rather than treating “diffusion = faster” as a blanket truth.

Google’s headline is up to 4x faster than Gemma 4 26B-A4B at a matched model size, and roughly 2.25x faster than Gemma 4 12B with speculative decoding enabled. Reported throughput is 1,000–1,100-plus tokens per second on an H100 in FP8, and 700-plus tokens per second on an RTX 5090 with the NVFP4 quantized build. Every one of these is vendor-stated at low batch sizes, and Google is explicit that they describe local, low-concurrency inference. Real-world throughput varies with concurrency and quantization.

The mechanism behind the gain is worth understanding, because it tells you when the speed is real. Autoregressive decoding is memory-bandwidth bound: each new token requires a sequential read of the growing KV cache, and the accelerator spends most of its time waiting on memory rather than computing. DiffusionGemma moves that bottleneck onto compute — denoising a whole canvas is a dense batch of matrix operations that keeps the tensor cores busy. When you are the only user and the GPU would otherwise sit idle between sequential reads, that is a large, real win. When the GPU is already saturated by batched cloud traffic, there is less idle time to reclaim, which is exactly why the advantage is local-inference-shaped.

Most coverage stops at “it is faster but worse.” The more useful view is benchmark by benchmark, because the one place it wins tells you the workload to route to it. The table below is the vendor-stated comparison against Gemma 4 26B-A4B from the official model card (Codeforces ELO and OmniDocBench corroborated via independent coverage). On every percentage benchmark, higher is better and Gemma 4 leads; on OmniDocBench 1.5, document parsing, the order flips.

The pattern is unambiguous and Google does not hide it: the model trails Gemma 4 across general knowledge, science, competition math, coding, hard reasoning, vision, and long-context retrieval, with the widest gaps on MMMU Pro vision (−19.5 points), AIME 2026 (−19.2 points), and a 289-point Codeforces ELO deficit. The one place the order flips is OmniDocBench 1.5, where bidirectional attention gives it a structural advantage on OCR and layout-aware extraction. This is not a model that is “almost as good and much faster” — it is a model with one genuine strength and a real quality cost everywhere else. Independent coverage notes the same trend held for earlier diffusion LLMs, so the trade-off looks like a property of the paradigm rather than a one-off.

The most interesting practical fact is the hardware envelope. The NVFP4-quantized build fits within roughly 18GB of VRAM, which puts a 26B-class model on a single consumer RTX 5090 — a fundamentally different deployment story from most 26B models that expect A100/H100-class hardware. FP8 needs about 28GB; BF16 full precision is 50GB-plus and effectively multi-GPU. For teams that care about local, private inference, the question shifts from “can we afford the cluster” to “does a single desktop GPU clear the bar.”

One known limitation deserves a flag for long-form work: because each canvas denoises semi-independently, very long structured outputs can show incoherence at the 256-token canvas boundaries. For document-length structured generation, validate the seams. If you are sizing the speed against your existing stack, our roundup of AI model latency benchmarks puts figures like 1,100 tokens per second in context against mainstream autoregressive throughput.

The benchmark profile resolves cleanly into a routing decision. Send DiffusionGemma the workloads that reward its speed and bidirectional attention; keep everything quality-sensitive on Gemma 4. The four cases below are the ones where the choice is non-obvious.

For the open-weight versus closed-weight framing of the broader text-diffusion landscape, the natural comparison point is Inception Labs Mercury 2, the first commercial text diffusion model. Both land near the 1,000-tokens-per-second mark, but Mercury 2 is a closed commercial API while DiffusionGemma is Apache 2.0 open weights with day-zero vLLM support. The two were not run through a shared benchmark suite, so treat the contrast as structural — open versus closed, self-hosted versus API — rather than a head-to-head quality number. The wider open-versus-closed question is covered in our open-weight vs closed-source AI models comparison.

Read narrowly, DiffusionGemma is an experimental release with one standout workload. Read as a signal, it is the moment text diffusion stopped being a closed-lab demo and became something any team can download, inspect, fine-tune, and self-host. That open-weight status is the part that compounds. Until now the fastest diffusion LLMs were commercial APIs; an Apache 2.0 model with native vLLM support and a JAX fine-tuning toolbox turns the paradigm into infrastructure researchers and product teams can build on without a vendor contract.

Projecting forward, the practical near-term value is not in replacing your default model — it is in routing specific workloads. Document extraction pipelines, single-user local assistants, and constrained generation tasks like the Sudoku demo are where iterative refinement and a single-GPU footprint pay off today. Expect the quality gap to narrow as the technique matures, the way successive autoregressive generations did, but do not bet a production pipeline on that convergence yet. The honest read for June 2026 is that diffusion is now a real, open option for a defined slice of workloads — and a poor fit for the rest. Teams weighing where it fits into a multi-model stack are exactly the kind of comparative evaluation our AI and digital transformation engagements begin with, alongside the autoregressive Gemma 4 family that DiffusionGemma trades quality against for speed.