Abstract
Diffusion language models spend more computation on novel, rare, or incorrect outputs, and decoding speed can improve inference efficiency and reliability.
Diffusion language models can write several tokens in one forward pass, and they decide during generation how many passes to spend. Two outputs of the same token length can therefore vary a lot in cost. To understand the underlying factors of this cost variation, we analyze two diffusion models across 10 tasks. We find that the number of forward passes per token depends heavily on the task. Text copied or lightly edited from the input is cheap, while open-ended writing is costly. In DiffusionGemma, generating a token for story writing requires more than three times as many forward passes as for grammar correction. Two output properties explain much of this gap: how much of it is new relative to the input, and how rare its words are within the task. The same holds within a single response when thinking is involved. The final answer is cheap when it repeats the model's reasoning trace and costly when it adds something new. In multilingual generation, we find that highly tokenized languages also require more passes per token, adding to the cost they already pay with more tokens. Finally, cost tracks correctness: on the same math problem, wrong answers take more passes per token than correct ones, and weighting candidate answers by decoding speed beats majority voting by up to 4.2 points at no extra cost. Taken together, our results show that diffusion's computational advantage depends on how much of the output is already determined, while its decoding effort offers a practical signal for making inference more efficient and reliable.
Community
Diffusion language models such as DiffusionGemma vary in per-token generation speed across tasks and languages, and this speed provides a signal for selecting better candidate answers at no extra cost.
Anyone pricing this per token is going to get burned. If forward passes per token swing by task and by language, my cost per request becomes a function of the input distribution rather than the token count, which means the invoice is a monthly surprise and the p99 latency SLO is unenforceable without a hard cap per task.
What I'd want out of this is a pass budget table: for each task family and locale, the passes needed to clear a quality bar, so cheap requests get routed to a fixed low budget and only the adaptive cost gets paid where it earns something. The language variance worries me more than the task variance, because a locale that shifts the whole cost profile is a pricing decision, not an inference detail, and it's the kind of thing that only surfaces after launch.
Haven't run it, but I'd guess the variance buckets into two or three tiers rather than needing a real scheduler. Does the pass count correlate with anything observable before generation starts? A budget you can't predict before you spend it isn't a budget.
Models citing this paper 0
No model linking this paper
Datasets citing this paper 0
No dataset linking this paper
Spaces citing this paper 0
No Space linking this paper
Collections including this paper 0
No Collection including this paper