DiffusionGemma

DiffusionGemma is an experimental open-weight large language model developed by Google DeepMind for multimodal text generation through discrete diffusion. Released on June 10, 2026, it differs from an autoregressive model that finalizes output one token at a time. DiffusionGemma iteratively denoises a 256-token canvas: it evaluates every position with bidirectional attention, accepts a subset of confident predictions, and revises the rest over multiple passes.^[1][2][3]

The public checkpoint is google/diffusiongemma-26B-A4B-it. It is based on the Gemma 4 26B A4B backbone and contains 25.2 billion total parameters, with about 3.8 billion active for each token. Google released BF16 weights under the Apache License 2.0 and classifies the model as experimental rather than its preferred production model for maximum output quality.^[1][3][6] Because the model reads and rewrites a whole canvas in one forward pass, a feature merged into vLLM in September 2026 also lets a client seed that canvas with an answer template and read a probability distribution for each answer slot after a single denoising step, which Google's Gemma account presented as a way to turn the model into a decision model in the style of Jev.^[13][14][18]

Release and specifications

DiffusionGemma sits in Google's Gemma family of open models and has its own section in the Gemma documentation, alongside the core models and variants such as FunctionGemma and EmbeddingGemma.^[2] Google released one instruction-tuned DiffusionGemma checkpoint in its official collection. The repository name rounds 25.2B total parameters to 26B and 3.8B active parameters to A4B. The active figure describes routed computation, not checkpoint size or memory footprint.^[3][6]

The layer counts, the 262,144-token vocabulary, the 1,024-token sliding window and the 256-token canvas length are all set in the repository's config.json, which declares the architecture diffusion_gemma with a gemma4_vision tower of 27 layers.^[6]

DiffusionGemma accepts interleaved text and images. It processes video by sampling frames and supports up to 60 seconds at one frame per second. The release does not support audio input, even though the model card lists audio among the pretraining data types. The model card claims out-of-the-box support for more than 35 languages after pretraining exposure to more than 140.^[2][3]

Block-diffusion architecture

The model uses one fine-tuned Gemma 4 backbone in two modes. A causal encoder reads the prompt and earlier completed output into a KV cache. A bidirectional decoder then denoises the current 256-token canvas while cross-attending to that cached prefix. Once the canvas is complete, the encoder adds it to the cache and the decoder starts a new canvas. Generation is therefore diffusion-based within a block and autoregressive across blocks.^[3][4]

This arrangement resembles the block-diffusion family described in prior research. Block diffusion combines parallel sampling within fixed blocks with causal dependencies between blocks, which permits variable-length generation and reuse of cached prefix computation.^[8] Google's own explainer frames the earlier approach as masking in the manner of masked language model training: random positions are replaced with a mask token and the model predicts what sits behind each one, but a position that has been filled cannot be revised if the surrounding context changes.^[4] Earlier large diffusion language models such as LLaDA worked that way.^[9] DiffusionGemma instead uses uniform-state discrete diffusion: it initializes the canvas with random tokens drawn from the vocabulary and can replace uncertain positions with fresh random tokens during denoising.^[4]

Each denoising pass predicts distributions for every canvas position. Self-conditioning converts the previous pass's distributions into vector representations and feeds them into the next pass. In vLLM's description of the same mechanism, the previous step's softmax distribution becomes a probability-weighted average of token embeddings and is added to the canvas embeddings through a small gated MLP, and the feedback is zeroed on encoder passes.^[4][13] The recommended entropy-bound sampler selects the lowest-entropy token predictions while keeping their mutual-information bound below 0.1, then fully re-noises unselected positions.^[2][3][4]

The standard sampler allows at most 48 denoising passes and lowers its temperature from 0.8 to 0.4. It stops early only when the canvas's average model entropy is below 0.005 and the most probable predictions remain unchanged across two consecutive passes. Google says this usually takes 12-16 passes, depending on the task. The model card describes 15-20 finalized tokens per forward pass.^[2][3]

A 256-token canvas consequently does not mean that one forward pass produces 256 finished tokens. All positions receive parallel computation, but commitment is iterative. The documented algorithm also confines revision to the active canvas. After a completed block enters the causal prefix, later canvases condition on it rather than denoising it again.^[3][4] What the engine finally emits is the clean argmax prediction of the converged canvas, not the noisy sampled canvas that is carried between steps.^[13]

Google's launch post places the work in the lineage of its Gemini Diffusion research and says DiffusionGemma "integrates a novel diffusion head designed to maximize generation speed". The post does not describe that head further.^[1]

Capabilities and intended uses

Google positions DiffusionGemma for low-concurrency, single-user workflows where response latency matters. The launch post names in-line editing, rapid iteration and "generating non-linear text structures", and lists in-line editing, code infilling, amino acid sequences and mathematical graphs as domains where bidirectional attention over a whole block helps. The model card adds code generation and completion, step-by-step reasoning, multi-turn chat, configurable thinking output, native system-prompt support and function calling.^[1][2][3]

The model's image capabilities include optical character recognition, document parsing, charts, screen understanding, object detection, handwriting, and pointing. A visual token budget from 70 to 1,120 tokens trades image detail for compute. Lower budgets target classification or video frames, while higher budgets preserve small text for OCR and document work.^[3]

Google describes DiffusionGemma as a research model for developers studying fast natural language processing and vision-language systems. The launch post explicitly recommends standard Gemma 4 instead when maximum output quality is the priority.^[1][3]

The developer guide uses Sudoku as its worked example of a task where left-to-right generation struggles, because each cell is constrained by cells that come later in the string. Google reports that the base model solves essentially none of its Sudoku puzzles, that a supervised fine-tuning recipe built with its Hackable Diffusion JAX toolbox raises this to an 80 percent success rate, and that the tuned model converges in fewer denoising steps (its illustration shows the base model failing after 48 steps and the tuned model finishing in 12). These are Google's own figures for its own dataset, with no sample count given.^[5]

Training and data

Google says the Gemma 4 26B A4B backbone was fine-tuned to perform both causal encoding and bidirectional denoising. The public explanation identifies uniform-state corruption and self-conditioning but does not give the adaptation dataset size, diffusion training schedule, token count, optimizer, training hardware, duration, energy use, or compute budget.^[4]

The model card describes a pretraining mixture of web documents, code, mathematical text, images, and audio with a January 2025 cutoff. It says the corpus covers more than 140 languages. Google applied multiple rounds of child sexual abuse material filtering, automated removal of some personal and sensitive information, and additional quality and safety filters.^[3]

No full corpus, source-domain proportions, image provenance list, or dataset-level license inventory is published. Google also does not separate the original Gemma 4 pretraining mixture from any data used specifically to adapt the backbone for diffusion or instruction following. The released implementation supports inference and fine-tuning, but it is not a reproduction package for the original model training.^[3][4][7]

Weights, software, and hardware

The official BF16 checkpoint is available from Hugging Face, with additional access through Kaggle and Vertex per the Gemma documentation; the launch post links a Gemini Enterprise Agent Platform Model Garden listing and the developer guide calls the same route Google Cloud Model Garden.^[2][5] Google's google-deepmind/gemma repository contains the JAX diffusion transformer, sampler, early-stopping logic, tests, example notebook, and an adapter for the Hackable Diffusion fine-tuning toolkit. Hugging Face Transformers, vLLM, SGLang and MLX are the inference routes named in the developer guide; Google also names NVIDIA NIM for deployment and Unsloth and NVIDIA NeMo for fine-tuning.^[2][5][6][7]

The weights and official implementation use the Apache License 2.0. Community quantizations and ports are separate artifacts. At launch, Google said official llama.cpp support was still forthcoming. As of October 1, 2026 the two llama.cpp pull requests that add block-diffusion support for the model, both opened on June 10, 2026, were still marked draft and unmerged, so a community GGUF file did not by itself establish upstream support.^[1][5][25]

Quantized checkpoints released alongside the model were produced with vLLM's LLM Compressor and saved in the compressed-tensors format: an FP8 model with quantized weights and fully dynamic activations, and an NVFP4 model with weights and activations both in NVFP4. Both are published on the RedHatAI Hugging Face account, and NVIDIA publishes its own NVFP4 conversion, which the later structured-read work used for testing.^[13][14] Red Hat, which says DiffusionGemma is a validated model on its AI platform, puts the NVFP4 footprint at roughly a third of BF16.^[16]

Google says a quantized model can fit within 18 GB of video memory. That claim does not describe the BF16 checkpoint or guarantee that every context length, vision-token budget, batch size, and cache configuration fits in 18 GB.^[1][2]

For speed, Google reports more than 1,100 tokens per second on one H100 using FP8 at low batch, more than 1,000 tokens per second in the launch summary, and more than 700 tokens per second on an RTX 5090. It characterizes the best result as up to four times faster than autoregressive generation on dedicated GPUs. The launch post also says Google worked with NVIDIA on quantized support for GeForce RTX 4090 and 5090 cards, Hopper and Blackwell servers using NVFP4 kernels, DGX Spark and DGX Station, and RTX PRO workstations.^[1][3]

These figures describe per-user output under favorable accelerator conditions. The launch post does not provide enough prompts, output lengths, repeated-run statistics, or complete baseline configurations to reproduce the four-times figure from the article alone. Google also says the advantage diminishes under high request volume, where autoregressive servers can batch many sequences and DiffusionGemma can cost more to serve. Its footnote warns that unified-memory architectures such as Apple Silicon Macs, which have lower compute-to-memory bandwidth ratios, may not see the same acceleration.^[1]

Hugging Face's own counters show heavy use of the weights. As of October 1, 2026 the Google repository showed 591,017 downloads in the preceding month and 1,265 likes, and Hugging Face's model search listed 129 repositories whose names match "diffusiongemma", the largest of them Unsloth's GGUF conversion with 226,794 downloads in the same window.^[6][30]

Serving in vLLM

Google says it worked with the vLLM team on the integration and credits Red Hat with supporting it. On launch day the vLLM team and Google DeepMind published a joint engineering post describing how a non-autoregressive decoder was fitted into an engine built for token-by-token generation, and calling DiffusionGemma "the first dLLM supported in vLLM".^[1][5][13]

The integration uses the ModelState abstraction introduced with vLLM's model runner v2 instead of forking the model runner. ModelState gives a model hooks that the generic runner calls at each stage: prepare_inputs() embeds the canvas tokens and applies self-conditioning, prepare_attn() sets causal attention for encoder requests and bidirectional attention for denoising requests, custom_sampler() installs a diffusion-specific sampler, and add_request() and remove_request() allocate and tear down per-request canvas state. The post presents this as a blueprint for adding further diffusion language models without touching the scheduler or runner.^[13]

The denoising loop rides on vLLM's existing speculative decoding data path, because a canvas can be treated as a large set of draft tokens that is either entirely accepted or entirely rejected. During a denoise step the sampler reports zero sampled tokens and marks every canvas position rejected, so the KV-cache position does not advance and the scheduler reschedules the same block; only a commit step advances it and emits 256 tokens. Supporting a batch that mixes causal prefill, bidirectional denoising and commit passes required dynamic per-sequence causal attention, implemented in the Triton and FlashAttention 4 backends, where a single boolean causal flag was replaced by a per-request tensor. Sliding-window layers become symmetric for canvas tokens, giving a window of 2W+1 instead of W. Automatic prefix caching works unchanged, because the encoder writes its KV exactly as an autoregressive model would. FlashInfer cannot serve the model, because a batch mixes causal prefill with bidirectional denoising, and --attention-backend FLASHINFER is rejected.^[15]

Support was merged into vLLM's main branch on June 12, 2026 and appears in the v0.24.0 release notes of June 29, 2026,^[28] which list the model along with a CPU path and structured-output guardrails for diffusion decoders. Later releases added tensor parallelism and Hugging Face stability-window semantics (v0.25.0, July 11, 2026) and top_k and top_p sampling for the model (v0.27.0, August 10, 2026). The architecture entry DiffusionGemmaForBlockDiffusion was added to vLLM's supported-models table on September 23, 2026, listed for text, image and video input and without LoRA or pipeline-parallel support.^[21][26][29]

vLLM's own deployment recipe, last updated September 23, 2026, documents flags that differ from standard Gemma 4 serving. It keeps --max-num-seqs at 4 for 256-token canvases because the self-conditioning probability buffers are preallocated as sequences times canvas length times the 262K vocabulary, sets --generation-config vllm so the checkpoint's own 256-token limit does not override per-request limits, and configures the entropy-bound sampler through --hf-overrides. Its measured comparison against the autoregressive Gemma 4 26B A4B baseline on a single H100 at concurrency 1 is vLLM's own, using a harness it names SPEED-Bench:^[17]

The pattern is the same one Google describes: much higher generation throughput, at roughly ten times the time to first token, because a whole canvas must be denoised before anything is emitted. In its own launch-day benchmark at batch size 1 the vLLM team measured 1,288 generation tokens per second for the FP8 model on an H200 and 1,008 on an H100, which it put at about six times and five times a standard autoregressive baseline and about three times and 2.6 times a baseline using multi-token prediction.^[13][17]

Structured reads and Jev-style decisions

On September 29, 2026 Google's Gemma account posted on X: "Turn DiffusionGemma into a Jev-like model." The post said that "By seeding a canvas with a response template, vLLM lets you extract confidence scores and probability distributions for yes/no, multiple-choice, and scored questions, all in a single denoising step", described the result as bringing "a new level of precision to structured tasks", and closed "Fast, efficient, and ready to scale!" An earlier post from the same account, on September 18, 2026, had pointed at the vLLM pull request behind the technique, put the cost at roughly 0.2 seconds on a DGX Spark, and claimed that full bidirectional attention yields "well-calibrated decision distributions".^[18][19]

Jev is a hosted structured output model from TypeSafe AI that answers typed questions about an input and returns a probability for every allowed answer, using yes/no ("noul"), multiple-choice and scored question types behind a POST /v1/systemone endpoint. The vLLM work does not use Jev. It reproduces the shape of that API on DiffusionGemma's own output distributions. Red Hat, whose engineers wrote the main public explanation of the technique, frames the appeal as self-hosting: Jev is a hosted API, and regulated industries, air-gapped sites and sovereign or public-sector deployments cannot send every routing decision to a third-party endpoint.^[16]

How a read works

The example README states the idea directly: "If the canvas is seeded with the answer's fixed text and only the answer slots are left as noise, one denoise step gives a distribution over each slot."^[15] In practice a read has four stages.^[15][16]

1. Seed the canvas. The client supplies the exact token ids of an answer template, for example a short block reading violates: @, category: @, severity: @, where each @ marks a noised slot. Everything else is pinned.
2. Run one denoising step. The request caps the number of steps and is marked read-only, so the engine emits the argmax canvas when the cap is reached and skips the commit forward pass.
3. Read each slot's distribution. The request asks for logprobs, at temperature 1, for the specific label token ids at every canvas position. The highest-probability label is the answer and the entropy of the distribution serves as the confidence.
4. Re-read only when uncertain. If a slot's entropy exceeds a threshold, the example server issues a few more reads with different noise draws and reports the agreement between them as a standard error. Confident answers return after one read.

The extra request fields that make this possible were added by pull request #57250, which was opened on September 16, 2026 and merged on September 22, 2026.^[14]

One structural constraint runs through the design: every answer label must be a single token, so that the canvas layout does not shift. The pull request notes that a client can always map a multi-token label onto a single-token one, giving moderation_spam to A as the example, and that several questions can be answered in one request.^[14][15]

What one denoising step buys, and what it does not

In ordinary generation the model may run up to 48 denoising passes over a 256-token canvas and then one more encoder pass to commit the block. A read runs one decoder pass over a canvas sized to the schema and stops, which is why the cost is roughly a single forward pass rather than a block generation. The recipe uses a 64-token canvas for decisions against 256 for text, and the smaller state buffers are what allows 32 concurrent requests where ordinary generation is held to about four.^[16][17]

On a single DGX Spark, with read-only single reads, a 32-position canvas and three decisions per request, the pull request's author measured 8.7 requests per second at 0.12 seconds with one request in flight, and 54.0 requests per second at 0.58 seconds at 32-way concurrency, which works out to roughly 162 decisions per second. The same write-up reports small accuracy spot checks: 10 of 10 on programming-language identification, 9 of 10 on human-language identification and 10 of 12 on a unit-comparison set, plus color, counting and quadrant tasks answered through the model's vision tower. These are the author's own measurements on small samples, not an independent evaluation.^[14][16]

The technique gives bounded answers and a number attached to each one. It does not add the calibration training that TypeSafe says underlies Jev; the confidence is a statistic of the distribution the existing model already produces. Google's September 18 post called the resulting distributions well-calibrated, but none of the pull request, the example README, the vLLM recipe or Red Hat's write-up publishes a calibration measurement for the one-step read.^{[14][15][16][17][19]} Nor does a bounded answer space make an answer correct: the pull request's own spot checks include misses where the model put most of its probability on the wrong label.^[14]

Announced versus shipped, as of October 1, 2026

The machinery is merged but not in a stable release. vLLM's newest published release on October 1, 2026 was v0.30.0, tagged on September 22, 2026 several hours before pull request #57250 landed, and the merge commit is not an ancestor of that tag. It is contained in the v0.31.0 release candidate tags, the newest of which points at a commit from October 1, 2026.^[14][21]

Red Hat and the vLLM recipe both describe it that way. Red Hat's article states that "Decisions currently need a nightly build", and the recipe's structured-decisions section pins a specific nightly container image.^[16][17] Documentation is correspondingly provisional: the request fields are described in an example README inside the repository and in the recipe page rather than in vLLM's reference documentation, and the Jev-compatible /v1/systemone route is served by examples/features/structured_diffusion/structured_server.py, which the recipe calls "an example server rather than a standard vLLM endpoint".^[15][17] A follow-up pull request to add a structured-decisions endpoint to vLLM proper was opened on September 29, 2026 and was still open on October 1, 2026.^[20]

Red Hat sets out a staged path for its own products: prototyping today on upstream nightlies through an unsupported custom serving runtime on Red Hat AI Inference and OpenShift AI, then a Developer Preview of the example server at its 3.6 general availability release, "assuming vLLM >= 0.31.0 is picked up", with support levels for a hardened endpoint undetermined.^[16]

Outside the engine, a community project, taeold/djev-run, packages the approach as a single Cloud Run deployment on an NVIDIA RTX PRO 6000 Blackwell GPU and builds on mmastrac/djev. Its README reports a median response time of 61 ms on the server and 117 ms end to end at one step and one sample, and about 100 to 123 requests per second at concurrency 32. These are the project's own numbers, and the project is an individual's, not a Google release.^[27]

Evaluation

Google compares the instruction-tuned DiffusionGemma checkpoint with its autoregressive Gemma 4 26B A4B sibling. The model card says the figures are for instruction-tuned models using the recommended entropy-bound sampler. The published results are:^[3]

DiffusionGemma trails its autoregressive sibling on every listed row except Humanity's Last Exam without tools. The 32.0% MRCR result is measured at 128K, half the advertised context capacity, so a 256K window does not guarantee reliable retrieval across that span. Google's conclusion that the model trades quality for speed is consistent with its own benchmark table.^[1][3]

MMLU-Pro expands multiple-choice questions to ten options and removes noisy or trivial items to emphasize reasoning.^[11] LiveCodeBench continuously collects recent coding problems to reduce contamination.^[12] Google identifies benchmark versions and some tool conditions, but the model card does not publish complete prompts, seeds, sample counts, variance, or a runnable evaluation harness. The results are author-reported, not independent replications.^[3]

An independent June 2026 preprint instrumented the public checkpoint on 686 prompts across six regimes. It found large simultaneous token-commit batches, together with a partial left-to-right commit bias whose measured strength changed with analysis granularity, leading the authors to argue that the model's apparent block size is an artifact of the measurement scale rather than the architecture. Structured JSON showed nearly arbitrary commit order. Commit confidence correlated with correctness on the paper's mathematics prompts but carried no signal on factual recall.^[10] This study supports parallel commitment while qualifying the simpler description that a whole paragraph appears at once. Its abstract characterizes DiffusionGemma as a masked discrete-diffusion model, which does not match Google's own account of uniform-state diffusion, and it lists no peer-reviewed venue.^[4][10]

A second preprint, from a group including Google DeepMind interpretability researchers, asks whether running more computation inside a denoising loop makes the model's reasoning less legible. It reports that DiffusionGemma's opaque serial depth, the serial computation between interpretable states, initially looks 28.6 times higher than Gemma 4's, but that mapping the information passed between denoising steps through an interpretable token bottleneck brings this down to 1.1 times Gemma 4's with no measured loss in downstream performance. The paper also describes diffusion-specific phenomena it names non-chronological reasoning, token and sequence smearing and intermediate-context reasoning, and finds DiffusionGemma "similarly monitorable" to Gemma 4.^[22]

Reception

Independent coverage at launch was descriptive and focused on the speed claim and the consumer-GPU footprint. SiliconANGLE's Maria Deutscher summarized the model as generating text four times faster than conventional LLMs while using less memory, and noted that the mixture-of-experts design and NVFP4 format are what let it run on high-end consumer graphics cards.^[23] Google's own posts link an independent explainer, Maarten Grootendorst's "A Visual Guide to DiffusionGemma", published the same day.^[1][24]

Safety and limitations

Google says DiffusionGemma underwent automated and human safety testing for child sexual abuse and exploitation content, dangerous instructions, sexually explicit output, hate speech, and harassment. The tests were run without external safety filters to examine the raw model. The model card reports fewer policy violations than Gemma 3 and Gemma 3n while keeping unjustified refusals low.^[3]

Those results are qualitative. Google does not publish per-category violation rates, sample counts, thresholds, language coverage, adversarial prompts, or a numerical refusal table for DiffusionGemma. The card advises deployers to add safeguards suited to their application and identifies misinformation, privacy violations, malicious use, and inherited social bias as risks.^[3]

The model can produce false or outdated claims, miss language nuance, and struggle with common sense or open-ended tasks. Multimodal input creates further dependence on resolution and visual-token settings. Function calling requires an external runtime to validate and execute requests; model support for a tool-call format does not make the resulting action safe.^[3]

Diffusion introduces its own operational tradeoffs. Quality and latency depend on the entropy sampler and the number of denoising passes. Revision stops at the current canvas boundary, long-context retrieval is weak in the disclosed MRCR comparison, and the speed advantage is specialized for compute-heavy, low-batch accelerators. The structured-read path narrows the output space but inherits the same caveats: it guarantees the shape of an answer, not its correctness, and its confidence number has not been independently calibrated. DiffusionGemma is therefore an experimental latency-focused vision-language model, not a general replacement for Gemma 4 or evidence that diffusion generation is faster on every workload.^{[1][3][10][14]}

References

1. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13O'Donoghue, Brendan; Flennerhag, Sebastian. DiffusionGemma: 4x faster text generation. Google, June 10, 2026.
2. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9Google AI for Developers. DiffusionGemma model overview. Last updated June 10, 2026.
3. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13 ^14 ^15 ^16 ^17 ^18 ^19 ^20 ^21Google AI for Developers. DiffusionGemma model card. Last updated June 10, 2026.
4. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9Google AI for Developers. Diffusion in Text Generation Explained. Last updated June 10, 2026.
5. ^1 ^2 ^3 ^4 ^5Ballantyne, Ian; Sanseviero, Omar. DiffusionGemma: The Developer Guide. Google Developers Blog, June 10, 2026.
6. ^1 ^2 ^3 ^4 ^5Google DeepMind. diffusiongemma-26B-A4B-it model repository. Hugging Face, 2026. Download, like, configuration and model-search figures accessed October 1, 2026.
7. ^1 ^2Google DeepMind. Gemma diffusion implementation. GitHub, 2026.
8. ^Arriola, Marianne; Gokaslan, Aaron; Chiu, Justin T.; et al. Block Diffusion: Interpolating Between Autoregressive and Diffusion Language Models. ICLR 2025.
9. ^Nie, Shen; Zhu, Fengqi; You, Zebin; et al. Large Language Diffusion Models. arXiv:2502.09992, 2025.
10. ^1 ^2 ^3Asaria, Ali; Salomone, Tony; Gandhi, Deep. Neither Parallel Nor Sequential: How DiffusionGemma Actually Commits Tokens. arXiv:2606.14620v1, June 12, 2026.
11. ^Wang, Yubo; Ma, Xueguang; Zhang, Ge; et al. MMLU-Pro: A More Robust and Challenging Multi-Task Language Understanding Benchmark. arXiv:2406.01574, 2024.
12. ^Jain, Naman; Han, King; Gu, Alex; et al. LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code. arXiv:2403.07974, 2024.
13. ^1 ^2 ^3 ^4 ^5 ^6 ^7The vLLM Team and Google DeepMind Team. DiffusionGemma: The First Diffusion LLM (dLLM) Natively Supported in vLLM. vLLM blog, June 10, 2026.
14. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9vLLM. [\[Core\] structured generation mode for DiffusionGemma model (Jev-like)](github.com/...57250). Pull request #57250, opened September 16, 2026, merged September 22, 2026.
15. ^1 ^2 ^3 ^4 ^5 ^6vLLM. Structured reads on DiffusionGemma. Example README, repository `examples/features/structured_diffusion`, accessed October 1, 2026.
16. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8Wilkinson, Lucas; Greenberg, Rob. Run decision models on vLLM and Red Hat AI using DiffusionGemma. Red Hat Developer, September 28, 2026.
17. ^1 ^2 ^3 ^4 ^5 ^6vLLM. diffusiongemma-26B-A4B-it on vLLM. vLLM recipes, updated September 23, 2026.
18. ^1 ^2Google Gemma (@googlegemma). Post on X, September 29, 2026.
19. ^1 ^2Google Gemma (@googlegemma). Post on X, September 18, 2026.
20. ^vLLM. [\[Feat\] Structured decisions endpoint (`/v1/systemone`)](github.com/...59299). Pull request #59299, opened September 29, 2026; open as of October 1, 2026.
21. ^1 ^2vLLM. Releases. GitHub, accessed October 1, 2026.
22. ^Engels, Joshua; McDougall, Callum; Chughtai, Bilal; et al. How Transparent is DiffusionGemma? arXiv:2606.20560, June 18, 2026.
23. ^Deutscher, Maria. Google open-sources speedy DiffusionGemma text diffusion model. SiliconANGLE, June 10, 2026.
24. ^Grootendorst, Maarten. A Visual Guide to DiffusionGemma. June 10, 2026.
25. ^llama.cpp. DiffusionGemma, draft pull request #24423, opened June 10, 2026, and Add diffusion-gemma block-diffusion support, draft pull request #24427. Both open as of October 1, 2026.
26. ^vLLM. vLLM v0.24.0 release notes. June 29, 2026.
27. ^taeold. djev-run. GitHub, accessed October 1, 2026.
28. ^vLLM. [\[Model\] Add DiffusionGemma Support](github.com/...45163). Pull request #45163, merged June 12, 2026.
29. ^vLLM. Supported Models. vLLM documentation, accessed October 1, 2026; architecture entry added by pull request #46466, merged September 23, 2026.
30. ^Unsloth. diffusiongemma-26B-A4B-it-GGUF model repository. Hugging Face, accessed October 1, 2026.