DiffusionGemma Explained: Google DeepMind's Diffusion Language Model

If you spent any time on Hacker News yesterday, you probably saw it. On August 20, 2026, a thread titled "DiffusionGemma Technical Report" climbed to the number one spot on the front page, pulling in more than 154 points and a long comment section arguing about whether diffusion is finally a real contender to autoregressive decoding for text generation [9]. The paper itself is not brand new, Google DeepMind quietly published the arXiv technical report on July 31, 2026 [1], but it took almost three weeks for the community to actually sit down and read it closely, and once people did, the reaction was the same one you see whenever a well-resourced lab ships something that sounds like a research toy and turns out to work.

DiffusionGemma is Google DeepMind's experimental open-weight diffusion language model, and the detail that makes it worth a technical deep dive is not that it exists. Diffusion models for text have been an active research direction for a few years now. The interesting part is how DeepMind built it: instead of training a diffusion model from scratch the way you would train a new image diffusion model, the team took an existing, already-trained autoregressive checkpoint, Gemma 4's 26 billion parameter mixture-of-experts model, and fine-tuned it into a discrete diffusion generator using less than a tenth of the original training budget [1]. That single decision, reuse instead of retrain, is the thread that connects everything else in this post: the mechanism, the training pipeline, the speed numbers, and the caveats that come with all of it.

This post walks through what DiffusionGemma actually is, how block diffusion generation works at the token level, the specific mechanistic trick that makes converting a decoder-only model into a denoiser tractable, the real inference speed numbers from both DeepMind's own product pages and the arXiv report itself, the concurrency caveat that the marketing copy tends to skip, and how to actually get the model running on your own hardware.

Step 1: What DiffusionGemma Actually Is

DiffusionGemma is built on top of Gemma-4-26B-A4B, the mixture-of-experts variant of Google's Gemma 4 model family. The naming convention tells you the shape of the model directly. It carries roughly 25.2 billion total parameters, though DeepMind's own materials and independent coverage round this to about 26 billion, and only about 3.8 billion of those parameters activate on any single forward pass [1][2]. If you have read our earlier explainer on Kimi K3's mixture-of-experts design, the underlying idea is the same one used there: a router selects a handful of expert sub-networks for each step of computation instead of running every parameter in the model every time. What makes DiffusionGemma unusual is not the mixture-of-experts backbone itself. It is what DeepMind did with that backbone once it was already trained.

Every mainstream large language model you have used, Gemini, GPT, Claude, Llama, and the base Gemma 4 model that DiffusionGemma started from, generates text autoregressively. That means the model predicts one token, appends it to the sequence, looks at the new longer sequence, predicts the next token, and repeats, strictly left to right, one token at a time. This is why streaming responses appear to type themselves out on screen. It is a direct visualization of the underlying computation.

DiffusionGemma throws that assumption out for the generation step, while keeping it as the training target for the base model it builds on. Instead of committing to one token and moving on, it starts with a block of up to 256 tokens that are entirely masked out, meaning replaced with a placeholder that means "unknown," and then iteratively refines the entire block across multiple denoising steps until real tokens emerge everywhere at once [1][3]. The mental model DeepMind and outside coverage both reach for is image diffusion: a text-to-image model like Stable Diffusion or Imagen starts with pure noise and gradually removes noise, step by step, until a coherent picture emerges across the whole canvas simultaneously, rather than painting the image one pixel at a time from the top-left corner. DiffusionGemma does the same thing to a block of text. It denoises the entire block together, not word by word from left to right [7].

The scale here matters, so it is worth being precise about the numbers. The technical report states the model generates around 20 finalized tokens per forward pass as it iterates through the denoising steps inside a single block, out of a maximum block size of 256 tokens [1]. That is the key efficiency lever. A standard autoregressive model needs one forward pass per token, full stop. DiffusionGemma needs one forward pass to make meaningful progress on roughly 20 tokens at once, because a single pass through the model updates its confidence about every masked position in the block simultaneously, and the sampler commits to the positions it is most confident about, leaving the rest to refine on the next pass.

DiffusionGemma is explicitly labeled "experimental" by Google DeepMind, which is an honest description rather than a hedge. It is not positioned as a replacement for Gemini or for the base Gemma 4 line in production Google products. It is a research artifact meant to demonstrate a specific idea: that you do not need to train a diffusion language model from the ground up to get the benefits of parallel, block-wise generation. You can take an autoregressive model you already have and convert it.

Step 2: How Block Diffusion Generation Actually Works, Mechanically

To understand why this works, it helps to separate two things that are easy to conflate: what a decoder-only transformer computes internally, and what it actually uses from that computation when you are running normal autoregressive generation.

What an autoregressive model throws away

Here is the detail that made the Hacker News thread genuinely interesting rather than just another model announcement. When you run a standard decoder-only transformer forward pass on a sequence of, say, 500 tokens, the model does not just compute a prediction for what comes after token 500. Because of how the attention mechanism and the final unembedding layer work, the model actually produces a full probability distribution, a set of logits, for every single position in that sequence: what the model would have predicted came after token 1, after token 2, after token 3, all the way through the end [8]. During ordinary autoregressive inference, you throw almost all of that away. You only care about the logits at the very last position, the ones that tell you what token to sample next. Every other position's logits get computed as a side effect of the matrix multiplications happening across the whole sequence, and then discarded the moment the forward pass finishes.

This is the insight the DiffusionGemma team leaned on. A decoder-only model, purely by virtue of how it processes a sequence, already computes something like "my best guess for what token belongs here" for every position simultaneously, not just the next one. It is not designed to be used that way for generation, and the training objective, next-token prediction, never explicitly asks the model to make those interior predictions good. But the computation is already happening. The DiffusionGemma team's contribution was recognizing that if you fine-tune the model so those interior, normally-discarded predictions become reliable, you can use them directly as a denoising signal for every masked position in a block, all in one pass, instead of only ever using the last position's prediction and marching forward one token at a time [8].

Put simply: the model already "knows" something about every position at every forward pass. Standard autoregressive decoding just never asks it. Diffusion training teaches the model to actually use that instead of throwing it away.

The block diffusion mechanics, step by step

With that framing in place, the actual generation loop is easier to follow. DiffusionGemma processes a target span, up to 256 tokens, as a block. Here is roughly what happens inside that block:

1. Every token position in the block starts fully masked, represented with a special mask token that stands in for "not yet decided."
2. The model runs a forward pass over the block, conditioned on whatever real tokens already exist before it in the sequence, exactly the way a normal autoregressive model conditions on prior context.
3. For every masked position, the model produces a distribution over what token should go there, using the logits at that position, the ones a standard decoder-only model would normally never use for anything.
4. A sampling and confidence-thresholding step picks the positions the model is most confident about, roughly 20 tokens worth per pass according to the technical report, and commits those tokens as final. The remaining positions stay masked.
5. The block runs through another forward pass. The newly committed tokens are now real context for the still-masked positions, which sharpens the model's next round of predictions, the same way removing noise from part of an image diffusion canvas helps the model resolve the rest of the picture more confidently.
6. This repeats until every position in the block is finalized, at which point the model can either move on to the next 256-token block or, if the generation is complete, stop.

The result is a generation pattern that looks nothing like the token-by-token stream you are used to watching scroll out of a chatbot. Instead, you would see an entire chunk of text appear mostly blank, then rapidly fill in across scattered positions in a handful of passes, closer to watching a photograph resolve out of static than watching someone type.

Why this genuinely differs from speculative decoding

It is worth being precise about what this is not, because the closest existing technique conceptually is speculative decoding, and the DiffusionGemma report itself makes this comparison directly, describing the model as substantially faster than autoregressive models "even with state-of-the-art speculative decoding" [1]. We covered how that technique works in detail in our speculative decoding explainer, but the short version is that speculative decoding uses a small, fast draft model to guess several tokens ahead, then has the large target model verify all of those guesses in a single batched forward pass, accepting the ones that match what the big model would have generated anyway and rejecting the rest. It is still fundamentally autoregressive under the hood. The draft tokens are still generated left to right, and the acceptance check still respects strict token order.

Block diffusion is a different animal. There is no draft model, no separate verification pass, and no strict left-to-right ordering constraint within a block. The same single model proposes and refines every position in the block directly, and positions inside the block do not need to be resolved in any particular sequence, only the blocks themselves are ordered relative to each other. That is a genuinely different point in the design space, not a variant of speculative decoding, even though both techniques exist to solve the same underlying problem: getting more finished tokens out of the model per unit of wall-clock time.

Step 3: The Training Pipeline, or How DeepMind Reused an Existing Checkpoint Cheaply

This is arguably the most economically interesting part of the whole report, because it changes who can realistically build something like this. Training a genuinely new architecture, especially one with a training objective as different from standard next-token prediction as discrete diffusion denoising, usually means starting from random weights and spending the full pretraining budget again. DeepMind did not do that.

According to the technical report, converting the existing Gemma-4-26B-A4B autoregressive checkpoint into DiffusionGemma used fewer than 10 percent of the original model's total training token budget [1]. In other words, the vast majority of what makes DiffusionGemma capable, its world knowledge, its language ability, its reasoning skill, came for free from the already-completed Gemma 4 pretraining run. The diffusion-specific behavior, learning to denoise masked blocks instead of predicting single next tokens, was layered on top with a comparatively small additional training run.

Stage one: supervised fine-tuning for bidirectional denoising

The first stage of the conversion pipeline is a supervised fine-tuning phase whose job is specifically to teach the model bidirectional denoising [1]. This is a real behavioral shift, not a cosmetic one. An autoregressive model has only ever seen training examples where it predicts a token using everything to its left and nothing to its right, because during generation it can never see tokens that have not been produced yet. A denoiser needs the opposite skill in a specific sense: given a block where some positions are masked and others already contain real tokens, possibly both before and after a given masked position, predict what belongs in each masked slot using all of the surrounding, unmasked context, not just the context to the left.

This supervised phase is what actually retrains the model's attention patterns and its output distributions at every position to be useful, not just the final position. It is the concrete mechanism by which the "wasted logits" insight from Step 2 gets turned into a trained capability rather than staying a theoretical possibility. The model already had the architectural capacity to produce a distribution at every position. This stage is what makes those distributions accurate and useful for denoising specifically.

Stage two: reinforcement learning combined with sampler distillation

The second stage combines reinforcement learning with what the report calls sampler distillation, jointly improving generation quality and inference efficiency [1]. This stage matters because supervised fine-tuning alone tends to produce a model that can denoise correctly, but not necessarily one that denoises quickly or confidently. Reinforcement learning here is being used to shape the model's behavior toward outputs that score well on downstream quality, the same broad category of technique used to align most modern chat models, adapted to the specifics of a diffusion generation loop instead of a single-token generation loop.

Sampler distillation is the other half of this stage, and it is aimed squarely at the practical bottleneck of diffusion generation: the number of denoising steps needed per block. A naive diffusion sampler might need many small refinement steps to fully resolve a block with high confidence. Sampler distillation trains the model, and the sampling procedure paired with it, to reach the same quality of output in fewer steps, which is exactly the lever that determines whether the roughly 20 tokens finalized per forward pass in the technical report's headline number is achievable in practice or just a theoretical ceiling. Without this stage, a diffusion language model can technically work while still being slower in practice than an autoregressive model, because it needs so many refinement passes per block that the parallelism gets eaten up by iteration count. The joint RL and sampler distillation stage is what turns block diffusion from a research curiosity into something that actually delivers a wall-clock speedup.

Why the "under 10 percent" number is the real headline

It is worth sitting with why this training efficiency claim is arguably more important than the raw speed numbers covered in the next section. Every major lab training a frontier autoregressive model has already sunk enormous compute into pretraining runs. If converting one of those existing checkpoints into a fundamentally different generation paradigm, discrete diffusion instead of autoregression, only costs a low single-digit percentage of the original budget, that is a template other labs and the open research community can realistically replicate on their own already-trained models, rather than a result that only a handful of labs with unlimited compute budgets can reproduce. That is very different from, say, a benchmark score that required a nine-figure training run to achieve. It is a methodology result, not just a capability result, and methodology results tend to spread through a field faster than capability results do.

Step 4: The Real Inference Speed Numbers, and the Concurrency Caveat Nobody Puts in the Headline

Here is where it is important to be precise, because two credible official sources report two different numbers, and understanding why they differ tells you something real about how these benchmarks get measured.

Two numbers, two sources, both real

Google DeepMind's own official product page and the Google AI for Developers documentation both describe DiffusionGemma as "up to 4x faster" than a comparable autoregressive model, translating to more than 1,000 tokens per second on a single NVIDIA H100 GPU [2][3]. The arXiv technical report itself, however, states a higher figure: roughly 1,500 output tokens per second on a single H100, and explicitly frames this as substantially faster than autoregressive models even when those models are accelerated with state-of-the-art speculative decoding [1].

Both numbers are legitimate, and the gap between them is not a contradiction so much as a difference in what exactly is being measured, product-page marketing copy tends to state a more conservative, broadly reproducible figure, while a technical report's benchmark section often reports the best result achieved under a specific, favorable configuration, batch size, prompt length, and sampling settings included. Treat "up to 1,000+ tokens per second" as the number to expect in a typical single-request deployment, and "roughly 1,500 tokens per second" as closer to a best-case ceiling you might approach under ideal conditions.

The concurrency caveat: this is a single-user speed story

This is the detail that separates a genuinely useful technical understanding of DiffusionGemma from a marketing-driven one. VentureBeat's coverage of the technical report makes an important qualification that the raw speed numbers alone do not communicate: the speed advantage is real, but it holds mainly in single-user or low-concurrency scenarios. Once you reach roughly 32 concurrent requests, standard autoregressive models catch up on total system throughput [7].

The reason this happens is not mysterious once you think through what the block-diffusion speedup is actually exploiting. A single request to an autoregressive model under-utilizes a modern GPU, because generating one token at a time on one sequence leaves most of the GPU's parallel compute capacity idle, waiting on memory bandwidth rather than doing useful matrix multiplication work. That is precisely the gap DiffusionGemma's block-wise, many-tokens-per-pass generation fills for a single request: it keeps the GPU busier per forward pass because it is resolving roughly 20 tokens' worth of useful work per pass instead of one.

But a production LLM server rarely serves one request at a time. It batches many concurrent requests together, and that batching is exactly the same trick block diffusion uses, just applied across users instead of within one block of one user's output. Once you have enough concurrent autoregressive requests batched together, roughly 32 in the numbers VentureBeat reports, the GPU is already close to fully utilized by ordinary batched autoregressive decoding, and the marginal advantage of resolving many tokens per pass within a single request's block stops mattering as much for total system throughput, because the system was already keeping the hardware busy through request-level parallelism instead of token-level parallelism.

This is a genuinely useful mental model to carry forward: block diffusion and request batching are two different routes to the same destination, keeping a GPU's compute saturated instead of leaving it idle waiting for the next token. At low concurrency, block diffusion wins because there is no batching to fall back on. At high concurrency, batching alone already gets you most of the way there, and the diffusion model's advantage narrows.

What this means for real deployment decisions

If your use case genuinely is single-user or very low concurrency, an internal tool with a handful of simultaneous users, a local coding assistant, an interactive creative writing application where one person is waiting on one response at a time, DiffusionGemma's speed advantage is a real, meaningful improvement in perceived latency. If your use case is a high-traffic public API or a backend service fielding dozens of simultaneous requests continuously, the calculus shifts, and a well-batched autoregressive deployment, potentially one already using speculative decoding, may deliver comparable total throughput without the added complexity of adopting a new generation paradigm.

This is not a knock against the model. It is a reminder that "faster" always needs a concurrency level attached to it before it means anything concrete, and any inference benchmark that reports a single throughput number without stating the batch size or concurrency it was measured at should be read skeptically, whether it is about DiffusionGemma or any other model.

Step 5: Hardware, Access, and Running DiffusionGemma Yourself

DiffusionGemma is genuinely accessible if you want to try it rather than just read about it. The model is available through Hugging Face, Kaggle, and Google Cloud Vertex AI Model Garden [2][5]. The specific Hugging Face repository is google/diffusiongemma-26B-A4B-it, the instruction-tuned variant, and the model card walks through recommended sampling parameters and known limitations in more detail than the arXiv report alone covers [4][5]. The paper also has a dedicated landing page on Hugging Face's papers section if you want the abstract and discussion threads without pulling the full PDF [6].

Hardware requirements

Despite the 25.2 billion total parameter count, DiffusionGemma's mixture-of-experts design means the memory footprint you actually need to care about is closer to the active parameter count, 3.8 billion, plus the overhead of holding the full set of expert weights resident even though only a fraction fire on any given pass. In practice, DeepMind reports that a quantized version of the model fits within 24GB of VRAM, meaning a single consumer card like an RTX 4090 or the newer RTX 5090 is enough to run it locally, rather than requiring a datacenter-class accelerator [2]. On NVIDIA's newer Blackwell-generation GPUs, the model additionally supports NVFP4, a 4-bit floating point format, for further memory and bandwidth savings without needing a full-precision checkpoint [2][3].

That 24GB figure is worth comparing to what it would take to self-host a much larger dense model, or even the full Gemma 4 mixture-of-experts checkpoint at higher precision. It puts DiffusionGemma solidly in "runs on a serious hobbyist or small-lab workstation" territory rather than "needs a rack of accelerators" territory, which matters if part of the appeal here is experimenting with block diffusion generation yourself rather than only reading about DeepMind's own benchmark numbers.

A hybrid model, not a diffusion-only one

One detail that is easy to miss in the excitement about the new generation mechanism: DiffusionGemma is not exclusively a diffusion model. Because it was built by fine-tuning an autoregressive base rather than training a diffusion architecture from nothing, it retains support for the same thinking mode, multimodal input handling, and long context window that the underlying Gemma 4 model shipped with [3][4]. More notably, the model can still fall back to standard autoregressive, one-token-at-a-time generation with only minor quality degradation [1]. That fallback capability is a direct consequence of how the model was trained: since the underlying weights were never wiped and retrained from scratch, the original next-token prediction behavior is degraded but not destroyed by the diffusion fine-tuning stages. In practice, this gives a deployment a genuine fallback path if block diffusion generation hits an edge case, a very long single-token completion, an unusual prompt structure, without needing to swap in an entirely different model.

Running it: a worked example

The most common way to serve a model like this today is through an inference stack that exposes a Hugging Face-compatible interface, whether that is transformers directly for smaller-scale experimentation or a serving framework like vLLM for anything closer to production load. Here is an illustrative example of loading and sampling from DiffusionGemma using the Hugging Face transformers library, written the way you would actually structure a script to try the model locally.

python
/code
# Illustrative example of loading DiffusionGemma with Hugging Face
# transformers and sampling from it. The exact denoising API surface may
# differ slightly by release, check the model card for the current
# generation call signature before relying on this in production.
# https://huggingface.co/google/diffusiongemma-26B-A4B-it
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

MODEL_ID = "google/diffusiongemma-26B-A4B-it"

tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID,
    torch_dtype=torch.bfloat16,
    device_map="auto",
)

prompt = "Explain why block diffusion can finalize many tokens per forward pass."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

# block_length controls how many masked tokens are resolved together per
# diffusion block (up to 256), and diffusion_steps controls how many
# denoising passes the sampler is allowed before it must commit the
# remaining masked positions in that block.
outputs = model.generate(
    **inputs,
    max_new_tokens=512,
    block_length=256,
    diffusion_steps=16,
    temperature=0.7,
)

print(tokenizer.decode(outputs[0], skip_special_tokens=True))

For anyone who wants to serve the model behind an API rather than just running a script, the same checkpoint can be pointed at a standard OpenAI-compatible serving layer. Here is a minimal example of standing up a local server and sending it a request from the command line.

bash
/code
# Standing up a local OpenAI-compatible server for DiffusionGemma and
# sending it a test request. Swap the serving command for whichever
# inference stack you use in production (vLLM-style servers are the most
# common choice for high-throughput deployments).
vllm serve google/diffusiongemma-26B-A4B-it \
  --quantization nvfp4 \
  --max-model-len 32768 \
  --port 8000

# In a separate terminal, once the server is up:
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google/diffusiongemma-26B-A4B-it",
    "messages": [
      {"role": "user", "content": "Summarize block diffusion generation in two sentences."}
    ],
    "max_tokens": 256
  }'

As the table shows, the practical tradeoff is not "DiffusionGemma is strictly better." It is closer per active-parameter compute cost to the base autoregressive Gemma 4 model it was built from, meaningfully faster at low concurrency, and converges toward parity with well-optimized autoregressive serving, including speculative decoding, once you are running a busy multi-tenant deployment. Where it sits on that spectrum for your own workload depends entirely on how many concurrent requests you actually expect to serve.

Why a Result Like This Matters Beyond a Leaderboard

It is easy to file inference-speed research under "interesting to researchers, irrelevant to anyone actually building a product," but that undersells what a result like this actually changes. Any creative or content pipeline that leans on a language model reasoning through several sequential steps, drafting a script, revising it, scoring candidate outputs, transcribing and analyzing a long video, benefits directly from a faster single-request generation path, because those pipelines are frequently bottlenecked on one step waiting on one model call to finish before the next step can start, which is exactly the single-user, low-concurrency regime where DiffusionGemma's advantage is strongest rather than the high-concurrency regime where it narrows.

Miraflow's own Text2Shorts workflow, for instance, walks a script through several distinct language-model-driven stages in sequence: generating an initial script from a topic, letting a user edit or regenerate it, then generating scene-by-scene visual prompts based on that script before handing off to video generation. Similarly, AI Clipping has to transcribe an uploaded video, analyze it for viral moments, and score multiple candidate clips before a single short gets produced. Neither of those workflows currently runs on DiffusionGemma, and there is no public indication that they do or will. But they are exactly the shape of task, several sequential language-model reasoning steps per single user's request, that a model architecture trading some multi-tenant scaling headroom for dramatically faster single-request generation is built to help with. That is the real reason a result like this is worth understanding even if you never touch a GPU cluster yourself: it is a preview of one direction inference is heading for latency-sensitive, sequential, single-request workloads, which describes a lot of real creative tooling, not just chatbots.

It is also worth putting DiffusionGemma in context next to other recent open-weight releases we have covered. Where Kimi K3 and the dense Qwen3.8 27B model compete primarily on raw capability and total cost per token, and Thinking Machines' Inkling pushes on a different mixture-of-experts design tradeoff, DiffusionGemma is one of the few recent open-weight releases competing on generation mechanism itself rather than parameter count or benchmark score. That is a genuinely different axis of progress, and one worth tracking separately from the usual "bigger model, better benchmark" release cadence, the same way Gemini 3.7 Flash's coding benchmark gains were a story about efficiency at a fixed capability tier rather than a story about scale.

Common Mistakes When Evaluating DiffusionGemma and Diffusion Language Models Generally

A handful of misunderstandings show up reliably whenever a result like this gets picked up outside the research community that produced it.

• Treating "up to 4x faster" or "1,500 tokens per second" as a number that holds at any concurrency level. Both figures describe single-request, low-concurrency conditions. At roughly 32 or more concurrent requests, well-batched autoregressive serving catches up on total throughput, per VentureBeat's coverage of the report [7].
• Assuming the two published speed numbers, DeepMind's "1,000+ tokens per second" and the technical report's "roughly 1,500 tokens per second," contradict each other. They are measured under different conditions, one closer to a broadly reproducible product-page figure, the other closer to a best-case benchmark result, and both are legitimate when attributed to their actual source.
• Assuming DiffusionGemma was trained as a diffusion model from scratch. The entire point of the release is that it was not. It reused an existing autoregressive Gemma 4 checkpoint and converted it using under 10 percent of the original training token budget [1].
• Assuming diffusion generation abandons sequential structure entirely. Blocks are still processed in order relative to each other, up to 256 tokens at a time. What changes is that positions inside a single block no longer have to resolve strictly left to right.
• Confusing this with speculative decoding because both techniques produce more than one finished token per meaningful unit of model computation. Speculative decoding is still fundamentally autoregressive, using a draft model and a verification pass. Block diffusion has no draft model and no strict token ordering within a block, and the technical report explicitly benchmarks against speculative decoding as a separate, competing approach [1].
• Overlooking that the model can still fall back to plain autoregressive generation with only minor quality loss. DiffusionGemma is a hybrid capability, not a diffusion-only architecture, precisely because it was fine-tuned from an autoregressive base rather than built from a blank slate [1].
• Assuming "experimental" means unusable. It means Google DeepMind is not positioning it as a production replacement for Gemini or the base Gemma 4 line, not that the model fails to work as described. The weights, model card, and benchmark numbers are all real and independently reproducible by anyone who downloads the checkpoint [4][5].

Production and Best-Practices Notes

If you are evaluating DiffusionGemma, or any block-diffusion language model, for a real deployment rather than a research experiment, a few practical points from the details above are worth carrying forward as design guidance rather than trivia.

First, profile your actual expected concurrency before choosing a serving strategy. If your product genuinely serves one user's request at a time, an internal tool, a single-tenant deployment, an interactive local application, the low-concurrency speed advantage is real and worth the added operational complexity of adopting a new generation paradigm. If you are building a shared, multi-tenant API, model your expected concurrent request volume against the roughly 32-request threshold VentureBeat's coverage identifies, and benchmark your own batching setup rather than assuming the headline speed number transfers directly to your workload [7].

Second, take advantage of the hybrid fallback rather than treating diffusion mode as the only option. Because the model retains autoregressive generation capability with only minor quality degradation, a production system can default to block diffusion for the common case and fall back to standard autoregressive decoding for edge cases where diffusion sampling behaves unpredictably, unusually long single completions, prompts with an ambiguous stopping point, or outputs where strict left-to-right causal structure genuinely matters for the task, such as certain kinds of streaming interfaces where partial output needs to be meaningful the moment it appears [1].

Third, if you are hardware constrained, the 24GB VRAM footprint and NVFP4 support on Blackwell-generation GPUs mean you do not need a datacenter-scale deployment to experiment seriously with this model. A single well-provisioned workstation GPU is a legitimate starting point, which lowers the bar for actually testing block-diffusion generation against your own prompts and workloads rather than only trusting published benchmark numbers [2].

Fourth, when you do publish or share your own benchmark numbers for a model like this, always state the concurrency level and hardware alongside the throughput figure, exactly the discipline that makes DeepMind's own two different numbers, 1,000+ and roughly 1,500 tokens per second, sensible once you know what each one is actually measuring rather than confusing. A tokens-per-second number with no stated batch size or concurrency is close to meaningless for anyone trying to reproduce it or make a deployment decision based on it.

Finally, treat sampler configuration as a real tuning surface rather than an afterthought. The technical report's sampler distillation stage exists specifically because naive diffusion sampling can need far more refinement steps per block than a well-distilled sampler needs to hit the same output quality [1]. If you are running the model yourself and see throughput well below the reported figures, the sampler configuration, not just the hardware, is one of the first places to look.

Photoreal tabletop still life, editorial product photography style. A wide wooden tray divided into a 4 by 4 grid of small square compartments by thin brass dividers, each compartment holding one blank cream paper tag. Roughly half the tags across the grid, scattered rather than filled in order, have just been stamped with a small dark ink mark from a wooden rubber stamp resting at the tray's corner beside a brass ink pad, the ink still glistening wet on those tags. The remaining tags sit blank. Warm soft studio lighting from above and slightly to one side, shallow depth of field with the wet-inked tags in sharpest focus, visible wood grain, paper fiber texture, and glistening ink sheen. No readable text, no people, no logos, gender neutral, scientifically and physically accurate materials and proportions.

A slow, steady overhead camera move across a wide wooden tray divided into a grid of small square compartments, each holding a blank cream paper tag. Over the course of the shot, tags scattered across the grid, not in left to right order, are stamped one after another in small clusters with a wooden rubber stamp dipped in dark ink, several tags receiving their stamp within the same moment rather than one at a time in sequence. Warm soft studio lighting, shallow depth of field, visible wood grain and paper fiber texture, glistening wet ink on freshly stamped tags. Clean editorial product-photography motion style, smooth steady camera movement, no readable text, no people, no logos.

Frequently Asked Questions

Is DiffusionGemma a completely new model architecture? No. It is built by fine-tuning Google's existing Gemma-4-26B-A4B autoregressive mixture-of-experts model into a discrete diffusion text generator, using fewer than 10 percent of the original model's total training token budget rather than training a diffusion architecture from scratch [1].

How many parameters does DiffusionGemma have? Roughly 25.2 billion total parameters, with about 3.8 billion active on any single forward pass, consistent with the mixture-of-experts design of its Gemma 4 base [1][2].

How fast is DiffusionGemma compared to a normal autoregressive model? Google DeepMind's product page and developer docs report up to 4 times faster generation, translating to more than 1,000 tokens per second on a single NVIDIA H100 GPU, while the arXiv technical report itself reports roughly 1,500 tokens per second on the same hardware [2][3][1]. Both numbers describe single-request or low-concurrency conditions.

Does DiffusionGemma stay faster at high traffic volumes? Not by the same margin. VentureBeat's coverage of the report notes that once you reach roughly 32 concurrent requests, standard autoregressive models catch up on total system throughput, because request-level batching starts filling the same GPU utilization gap that block diffusion fills for a single request [7].

What hardware do I need to run DiffusionGemma myself? A quantized version fits within 24GB of VRAM, meaning a consumer GPU like an RTX 4090 or RTX 5090 is enough. NVIDIA's Blackwell-generation GPUs additionally support the NVFP4 4-bit format for further efficiency [2].

Where can I actually download or try DiffusionGemma? The model is available on Hugging Face at google/diffusiongemma-26B-A4B-it, on Kaggle, and through Google Cloud Vertex AI Model Garden [5][2].

Can DiffusionGemma still generate text the normal, one-token-at-a-time way? Yes. Because it was fine-tuned from an autoregressive base rather than trained as a diffusion-only architecture, it can fall back to standard autoregressive generation with only minor quality degradation, in addition to retaining thinking mode, multimodal input, and long context from the underlying Gemma 4 model [1][3].

Is this the same thing as speculative decoding? No. Speculative decoding is still fundamentally autoregressive, using a small draft model to guess ahead and a verification pass on the larger model. Block diffusion has no draft model and resolves an entire block of up to 256 tokens together, without a strict left-to-right ordering constraint inside that block. The DiffusionGemma technical report benchmarks itself directly against speculative decoding as a separate, competing approach [1].

Conclusion

DiffusionGemma earned its spot at the top of Hacker News for a good reason. It is a real, working demonstration that you do not need to train a diffusion language model from a blank slate to get the benefits of parallel, block-wise text generation. You can take a large, already-trained autoregressive checkpoint, recognize that it is already computing useful information at every token position and simply not using most of it, and fine-tune that existing capacity into a genuine denoiser using a small fraction of the original training budget. The result is a model that can generate roughly 20 finalized tokens per forward pass, run at up to 4 times the speed of comparable autoregressive generation or more depending on which official benchmark you read, fit on a single consumer GPU when quantized, and still fall back to ordinary token-by-token generation when it needs to. The concurrency caveat, that this advantage narrows once you are serving dozens of simultaneous requests, is not a flaw in the research. It is a precise, honest description of where this specific technique helps most: single-request, latency-sensitive generation, which is exactly the shape of many real creative and agentic pipelines, not just chatbot demos. Whether or not DiffusionGemma itself ever leaves "experimental" status, the underlying method, reusing a pretrained autoregressive model instead of training a diffusion model from zero, is a template other labs and the open research community can realistically build on, and that is worth understanding well before the next model claiming to do the same thing shows up on the front page.

References and Sources

[1] arXiv. "DiffusionGemma Technical Report."

[2] Google DeepMind. "DiffusionGemma."

[3] Google AI for Developers. "DiffusionGemma."

[4] Google AI for Developers. "DiffusionGemma Model Card."

[5] Hugging Face. "google/diffusiongemma-26B-A4B-it."

[6] Hugging Face Papers. "DiffusionGemma Technical Report."

[7] VentureBeat. "Google's DiffusionGemma generates 256 tokens in parallel and self-corrects as it goes."

[8] The Decoder. "Google's DiffusionGemma proves you don't need to train from scratch to build a text diffusion model."

[9] Hacker News. "DiffusionGemma Technical Report" (discussion thread).