mojo-dllm runs LLaDA and Dream locally in Mojo, with no Python at runtime

mojo-dllm is a local inference runtime for diffusion language models, written in Mojo. It loads quantized GGUF checkpoints for LLaDA-8B-Instruct, LLaDA-1.5, Dream-v0-Instruct-7B, Dream-Coder-v0-Instruct-7B, and DiffuCoder-7B-cpGRPO. The GGUF reader, tokenizer, quantized matrix multiplication, GPU kernels, transformer, and denoising loop are all implemented in Mojo, according to the README. The target user is a developer evaluating Mojo for local model serving or experimenting with diffusion LMs outside a Python stack. The compiled build/mojo-dllm binary needs no Python at runtime and the GPU is optional. The convenience launcher, ./mojo-dllm, is a Python script run by uv that builds and starts the binary, so the build path still depends on that tooling even if the runtime does not. A diffusion LM does not generate left to right. It starts from a canvas of masked tokens and, over a fixed number of steps, commits the tokens it is most confident about. By default each step reruns the full model over the full canvas, which makes the workload a repeated stream of large matrix multiplications. The project is organized around that pattern, including an ablation that computes logits for every position to check how much of the step time that work accounts for. What the benchmark evidence shows The README publishes results with hardware, checkpoint quantization, and evidence files stated for each run. On CPU, for LLaDA-8B-Instruct in Q4_K_M on a 13th Gen Intel i5-13420H with 12 threads, generating 128 tokens in 32 denoising steps, mojo-dllm recorded 3,005 ms per step and 1.33 tokens per second, compared with 5,807 ms and 0.69 tokens per second for llama.cpp’s diffusion CLI under the same stated conditions. For Dream-v0-Instruct-7B on the same CPU setup, the figures were 2,967 ms per step and 1.35 tokens per second versus 5,566 ms and 0.72 tokens per