ALoDLM: allocating computation to unresolved tokens
Amazon’s diffusion language models refine latent states through adaptively repeated transformer layers.
ALoDLM decoding and recurrent refinement diagram. Credit: Amazon. Original image ↗
ALoDLM explores how a diffusion language model should spend computation while generating multiple tokens. Amazon’s model card describes 1.7B and 8B models initialized from corresponding Qwen3 backbones.
Why some token positions need more work
Consider generating a short program. Punctuation near a known function call may be easy to resolve, while a value that depends on a calculation may remain uncertain. Giving every unresolved position the same refinement budget can spend effort on decisions that are already straightforward.
ALoDLM’s shared transformer layers revisit unresolved states. Its adaptive allocation decides where further computation is useful before committing tokens. This explains the research question more precisely than calling the model fast: how much additional reasoning can parallel generation retain, and at what cost in latency or output quality?
Refine what is still uncertain
Rather than applying a fixed computational depth everywhere, the model repeatedly uses shared transformer layers. Committed tokens become context. Unresolved positions retain their hidden states and receive further refinement.
A learned halting policy controls the recurrent loop. Inference thresholds let researchers vary the balance between additional computation and committing more tokens in parallel.
Work through an adaptive computation budget
Think of four unresolved token positions with illustrative refinement counts of 1, 2, 4, and 5. Counting token-pass work gives 12 units. Applying a fixed five passes to every position would give 20. This deliberately simplified accounting model explains the allocation question:
The difference is eight token-passes, or 40% of that hypothetical fixed budget. It is not a measured ALoDLM speedup. Transformer operations can be batched, committed positions may still supply context, and memory movement and kernels add costs. A reduction in this toy work count cannot be converted directly into wall-clock latency. The actual halting and commitment mechanisms must be evaluated in their supported inference implementation.
This distinction also explains why parallel decoding and benchmark-quality decoding should not be conflated. Changing how many tokens commit together changes both the work schedule and the quality setting. A faster operating point may be useful, but its quality must be measured at that point rather than borrowed from a different configuration.
Read the benchmark without averaging away the task
The model card reproduces the paper's protocol and comparison table. In the 8B group, Qwen3-8B scores 81.8% on MATH-500 and ALoDLM-8B scores 80.8%. On HumanEval, the corresponding results are 85.4% and 87.8%. The chart below selects MATH-500, preserving a zero baseline and the two model identities. It illustrates why an advantage on one task is not an advantage everywhere.
For MATH-500, the reported gap is minus one percentage point. Relative to 81.8%, its magnitude is about 1.22%; those are different descriptions of the same comparison. Neither proves statistical significance. Keep the native chat templates, generation limit, window size, and halting settings from the source attached to the scores. The model card's separate optimized B200 throughput experiment cannot establish throughput for this quality configuration or for a portable decoder. Report quality and timing together only when they came from the same run and conditions.
MATH-500: retain the task-specific comparison
Focus the graph and use arrow keys, or tap a point, to inspect values. The complete data table is available below.
View data table
| Category | Score (%) |
|---|---|
| Qwen3-8B | 81.8 |
| ALoDLM-8B | 80.8 |
Two inference paths
The release provides optimized and portable inference instructions through its linked source repository. The model card’s throughput measurements refer to a particular optimized setup on an NVIDIA B200. They should not be read as a speed guarantee for the portable decoder or other hardware.
Choose the inference path before comparing speed
The model card distinguishes an optimized inference route from a portable one. Hardware, kernels, decoding settings, and the recurrent computation budget affect results. Record all four before comparing an output rate with the reported B200 experiment.
Use a small evaluation set with known answers. For code, include tests that check the behavior of the generated program. For mathematics, check the final answer and the intermediate calculation. Compare several gate or entropy settings only within the implementation’s documented range, and retain the quality results alongside throughput.
Check the license and output failures
The published weights use Creative Commons Attribution-NonCommercial 4.0. Resolve that requirement before planning a commercial service; “available to download” is not the same as permission for every deployment.
Also separate compilation, correctness, and instruction-following failures. A response that finishes sooner but requires extra repair can lose its apparent speed advantage in an application. Begin with the repository and setup instructions linked from the model card. We have reviewed the release material, not reproduced the optimized hardware measurements or certified the model for a production workload.
