DiffusionGemma Technical Report — part 6/6

Cleaned-text code points [77774, 84408). Bibliography omitted here; source.md includes it.

We estimate per-token generation speed by fitting the following model via non-negative least-squares (NNLS): Total Time = α ⋅ effective_prefill_tokens + β ⋅ total_output_tokens + γ , \text{Total Time}=\alpha\cdot\text{effective\_prefill\_tokens}+\beta\cdot\text{total\_output\_tokens}+\gamma, (14) where effective_prefill_tokens = prompt_tokens − cached_tokens \text{effective\_prefill\_tokens}=\text{prompt\_tokens}-\text{cached\_tokens} is the number of tokens requiring fresh computation, α \alpha is the per-token prefill time, β \beta is the per-token generation time, and γ \gamma captures constant per-request overhead (network latency, etc.). From the fitted β \beta , we obtain the generation speed as 1 / β 1/\beta TPS. The non-negativity constraint reflects that processing tokens, generating tokens, and per-request overhead can only add time. In practice, we disable caching across queries.

In order to capture any potential per-task variation in generation speed (e.g. from adaptive computation methods), we fit Equation ( 14 ) independently per benchmark, before taking an arithmetic average. Similarly, for open weight models we compute aggregate TPS measurements by first measuring per-task generative speed and then taking the arithmetic average.

##### Speed estimates.

Our speed measurements for Figure 1 are based on the GPQA-Diamond and LiveCodeBench-v6 datasets. For Mercury 2, we estimate the generative speed per task using the above methodology. Figure 19 shows the corresponding analysis; we obtain a TPS of 452.6 for GPA Diamond and 525.5 TPS for LiveCodeBench-v6, which translates into an average speed of 489 TPS.

Our speed measurements for Table 3 are based on seven benchmarks where we have measurements for all models: AIME 2026, GPQA Diamond, HumanEval, LBPP, LiveCodeBench-v6, MGSM, and Natural2Code. Again, for Mercury 2 we fit our speed estimation model on each task separately first before taking an arithmetic average. Figures 20 and 21 report the corresponding analysis; we obtain average TPS estimates of 600 TPS for high reasoning effort and 547 TPS for medium reasoning effort. We note that some evals (notably HumanEval and Natural2Code) have outliers that generate 50,000 tokens at extremely high speeds. These give a slightly favorable bias to our generation speed estimates and also explain why high reasoning effort have a higher TPS than medium reasoning effort. These outliers represent corrupted outputs where the model gets stuck in a thinking loop and exhaust the maximum generation length without returning a valid response.

Inception reports ∼ \sim 1000 TPS on NVIDIA Blackwell GPUs 8 8 8 https://www.inceptionlabs.ai/blog/introducing-mercury-2 , retrieved July 28, 2026. while Artificial Analysis 9 9 9 https://artificialanalysis.ai/models/mercury-2 , retrieved July 28, 2026. reports a median of ∼ \sim 987 TPS on undisclosed hardware. The difference to our estimate can be due to a number of reasons—in particular different hardware, serving optimizations, and/or different datasets used for measurement (this may have a large impact due to adaptive computation). It is worth noting that Artificial Analysis also reports substantial variance. Our estimate reflects the average speed a user would experience via the OpenRouter API.

## Appendix F Denoising trajectory sampled from DiffusionGemma

## Appendix G More on Practical Advantages of Text Diffusion

### G.1 Bidirectional Reasoning and Self-Correction

Consider the frog crossing puzzle in Figure 23 . This example highlights the necessity of self-correction in logical deduction. The prompt introduces a deceptive mathematical trap—an infinite loop—that the AR baseline blindly falls into, generating a contradictory “Yes”. DiffusionGemma’s parallel generation exhibits a distinct self-correction trajectory. While it initially assigns high probability to the intuitive but incorrect “Yes”, the bidirectional propagation of the logical constraints across the sequence enables the model to revise its stance and cleanly output “No” before the final tokens are sampled.

### G.2 More on Dynamic and Adaptive Computation

To concretely demonstrate the adaptive behavior of text diffusion, we contrast a structurally “hard” generation task against an “easy” task in Figures 24 and 25 . Both tasks involve generating a sequence of binary digits governed by identical local logical rules. However, in the structurally hard variant (Figure 24 ), each new token strictly depends on the two immediately preceding generated tokens. This causal dependency requires sequential reasoning, forcing the model to resolve the logic in a predominantly left-to-right manner. Consequently, the diffusion process adaptively expends more computational effort, requiring 7 denoising steps to fully resolve the sequence. It is crucial to note, however, that even on this structurally difficult, sequential problem, DiffusionGemma successfully decodes the entire sequence of 40 tokens (20 binary digits and 20 delimiting spaces) in only 7 denoising steps—a substantial acceleration compared to the 40 discrete sequential steps an AR model would require.

Conversely, the “easy” convolutional variant (Figure 25 ) asks the model to apply the exact same logic rules over a statically provided input string. Because the causal dependency on the model’s own dynamic output is removed, the task lacks sequential structure. DiffusionGemma immediately leverages its bidirectional attention to independently resolve all local rules in parallel, allowing the entire output sequence to converge simultaneously in merely 4 denoising steps.

### G.3 Structured and Constrained Outputs

## Instructions for reporting errors

We are continuing to improve HTML versions of papers, and your feedback helps enhance accessibility and mobile support. To report errors in the HTML that will help us improve conversion and rendering, choose any of the methods listed below:

Click the "Report Issue" ( ) button, located in the page header.

Tip: You can select the relevant text first, to include it in your report.

Our team has already identified the following issues . We appreciate your time reviewing and reporting rendering errors we may not have found yet. Your efforts will help us improve the HTML versions for all readers, because disability should not be a barrier to accessing research. Thank you for your continued support in championing open access for all.

Have a free development cycle? Help support accessibility at arXiv! Our collaborators at LaTeXML maintain a list of packages that need conversion , and welcome developer contributions .