# MinerU-Diffusion reads documents with diffusion decoding instead of left to right

> MinerU-Diffusion is an ECCV 2026 research implementation that reframes document OCR as an inverse rendering problem and replaces autoregressive left to right decoding with block level parallel diffusion decoding, in a 2.5B model that reconstructs structured text from masked tokens under visual conditioning. The model weights are on Hugging Face and ModelScope, and the training code is not released yet.

**opendatalab/MinerU-Diffusion** — [ECCV 2026] A diffusion-based framework for document OCR that replaces autoregressive decoding with block-level parallel diffusion decoding. 

- Repository: https://github.com/opendatalab/MinerU-Diffusion
- Website: https://arxiv.org/pdf/2603.22458
- Stars: 620 · Forks: 42
- Language: Python
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/opendatalab-mineru-diffusion

## The idea: OCR as inverse rendering

MinerU-Diffusion: Rethinking Document OCR as Inverse Rendering via Diffusion Decoding, and the repository is the official implementation of that work.

The reframing is the contribution. An autoregressive OCR model reads a page left to right, token by token, and every token depends on all the ones before it. The diffusion approach treats the page as an image to be reconstructed: the model starts from masked tokens and repeatedly refines them, conditioned on the visual input, and the text emerges as a whole rather than arriving in order.

The README's own summary of the mechanism is precise. Diffusion decoding progressively reconstructs structured text from masked tokens under visual conditioning: black tokens are confirmed, red tokens are being updated, and yellow tokens remain masked, enabling parallel generation with global consistency, in contrast to autoregressive left-to-right decoding.

The important part is the block structure. The decoding is block-wise parallel, not globally parallel, and the training figure explains why. The target token sequence is randomly masked to form a partially observed input, and the model predicts only the masked positions under visual and prompt conditioning. The right panel shows the structured block-attention mask used during training, where tokens attend bidirectionally within each block and causally to all preceding blocks, enabling parallel diffusion refinement within blocks while preserving coarse autoregressive structure across blocks.

So the hybrid is deliberate. Within a block, tokens refine in parallel. Across blocks, the order is still causal. That is what makes the decoding tractable, and it is the single design decision that explains the rest of the system.

## What the numbers in the README claim

Two claims appear in the TL;DR and the Performance section, and they are the ones to look at when evaluating the work.

The first is about speed and robustness together. By introducing block-wise diffusion, uncertainty-driven curriculum learning, it achieves up to 3.2x faster decoding while improving robustness and reducing reliance on language priors.

That last clause is the interesting one for document OCR specifically. An autoregressive model that has read half a page will tend to complete the rest of the sentence in a plausible way even if the image says something else, and the model's language prior becomes a source of errors on tables, forms and figures where the text is not fluent. A model that reconstructs the whole block under visual conditioning has less room to guess, and reducing reliance on language priors is a claim about exactly that failure mode.

The second claim is about the trade-off curve rather than a single number. MinerU-Diffusion provides an adjustable accuracy-throughput trade-off through threshold control, and compared with MinerU2.5 it achieves up to 3.26x TPS, with the sentence about offering further practical benefits cut off in the text available here.

The distinction between the two figures is worth noting. The TL;DR says up to 3.2x faster decoding, and the Performance section says up to 3.26x TPS. TPS here is tokens per second, and the two are probably the same measurement reported at different precision in two places.

The README also notes a fast inference badge, block-wise parallel, layout aware and SGLang ready, so the claims are grouped around three things: the decoding scheme, the OCR quality and the deployment path.

## The model, the weights and the serving stack

The artefacts are published and the README links them all, which is what makes the project usable rather than only readable.

The model is 2.5B parameters, named MinerU-Diffusion-V1-0320-2.5B, and it is on Hugging Face and on ModelScope under the OpenDataLab organisation, with the same checkpoint on both. There is also a Hugging Face Spaces demo at opendatalab/MinerU-Diffusion-V1-0320-2.5B, which is the fastest way to see what it does.

The serving side is the part that makes the research usable. The README lists SGLang support to accommodate diffusion computation, and the Complete the Nano-vLLM adaptation used by the nano_dvlm engine for single-GPU inference. The badge list also names a Nano-DVLM adapted badge pointing at the GeeeekExplorer/nano-vLLM repository.

Single-GPU inference is worth dwelling on. Diffusion decoding normally needs many parallel samples or a large batch to be efficient, because the per-step cost is paid over the whole sequence. If the same quality is reachable on one GPU, that is what turns a paper into something a team can run.

The technical report is on arXiv at 2603.22458, and the repository records the release dates. MinerU-Diffusion-V1 was released on 2026/3/24, and the ECCV 2026 acceptance was announced on 2026/6/18, which matches the last push to the repository on 2026-06-18.

The licence is MIT, and the primary language of the repository is Python.

## Installing the dependencies, and what the pins imply

The requirements file is worth reading in full, because the pins say more about the target environment than any prose would.

The first comment sets the expectation: it is recommended for a first-time setup with a Conda environment such as dmineru with Python 3.12, and the SGLang server installation is intentionally excluded and documented in docs/sglang/README.md.

The second line is the extra index for the CUDA build:

```text
--extra-index-url https://download.pytorch.org/whl/cu128
```

And the packages are pinned exactly, including torch==2.8.0+cu128, torchaudio==2.8.0+cu128 and torchvision==0.23.0+cu128, with numpy==2.2.6, transformers==4.52.1, accelerate==1.11.0, einops==0.8.1, safetensors==0.6.2, sentencepiece==0.2.1, pillow==12.0.0, scipy not present but triton==3.4.0 and flash-attn==2.8.3 are, along with liger-kernel==0.6.4, qwen-vl-utils==0.0.14, termcolor==3.2.0, tqdm==4.67.1 and xxhash==3.6.0.

The cu128 suffix is the key detail. These are CUDA 12.8 builds, and the extra index URL is what makes pip find them, since the default PyPI wheels for the same versions are not the same build. flash-attn and triton are the two entries that most often decide whether an install succeeds on a given machine, and liger-kernel is a set of fused Triton kernels, so the whole set is arranged around a specific NVIDIA stack rather than being generic.

That is the price of a research reproduction. The environment is fixed to one CUDA generation, and anyone on a different driver or a non-NVIDIA accelerator is out of the path the project documented.

## The repository layout and the engines

The top level of the repository is small and shows that the engine layer is where the engineering sits.

There is mineru_diffusion/ for the model code, engines/ for the serving and inference integrations, scripts/ for helper scripts, docs/ for documentation, assets/ for the figures and the banner, requirements.txt, and a LICENSE.

The separate engines/ directory is the part that makes the project a deployable system rather than a notebook. The roadmap lists the SGLang support, the Nano-vLLM adaptation with the nano_dvlm engine for single-GPU inference, and the Gradio-based interactive demo as completed items, and the badges in the README link to both upstream projects.

The roadmap also states the long-term goal plainly: build efficient and reliable 2.5B diffusion-based decoding for document OCR. Three items are ticked, V1 released, SGLang support, the Nano-vLLM adaptation and the Gradio demo. Two are unticked: MinerU-Diffusion-V2, described with the slogan More Small, More Faster, More Elegant, More Powerful, and the release of the training code.

The last one is the significant omission for a research repository. You can run and evaluate the released model, and you can read the technical report and the code, but you cannot train it from this repository.

## Where MinerU-Diffusion fits, and where it stops

The comparison worth making is with the other document parsing stacks, and with a plain autoregressive OCR model.

Against MinerU2.5, which is what the Performance section compares against, the difference is the decoding scheme and the resulting trade-off curve. The threshold control means the same model can be run at different points on the accuracy and throughput curve, which matters for a pipeline where some documents need the best answer and most do not.

Against a conventional autoregressive vision language model, the argument is about parallelism and about error rates. Parallel decoding across a block is where the throughput comes from, and reducing reliance on language priors is where the OCR accuracy on non-fluent text comes from. Whether that holds for your document mix is an empirical question the README does not answer for you.

The limits are clear. The training code is not released, so the work cannot be reproduced from scratch or fine-tuned from the released weights using the project's own pipeline. The requirements are pinned to a CUDA 12.8 stack with flash-attn and triton, which excludes non-NVIDIA hardware and constrains driver versions. The 2.5B checkpoint is a research release, and the roadmap's V2 entry is a promise rather than a shipped artefact.

And the scope is document OCR with layout awareness, block attention and visual conditioning, not a general document understanding system. The topics list names layout analysis, pdf parsing, pdf to markdown conversion, extract data and RAG, and the accompanying pdf-extractor-pretrain, pdf-extractor-rag and pdf-extractor-llm topics suggest a pipeline of related tasks the project is positioned within, but the diffusion decoding contribution here is specifically about producing structured text from a page image.

For a research team the release is substantial: weights, two serving backends, a demo and a report. For a production team it is a component to evaluate, with the caveat that the training half of the work is not published.

## Conclusion

MinerU-Diffusion suits a research team that wants to explore diffusion decoding for document parsing rather than only run a parser, since the repository carries the inference engines, the adapters for SGLang and Nano-vLLM and a Gradio demo, and the technical report explains the block attention design. It is the wrong tool if you need a production OCR pipeline today, because the training code is still unchecked on the roadmap and the weights are a research checkpoint rather than a maintained release. Before adopting it, read the requirements file and note the CUDA 12.8 extra index and the pinned torch 2.8.0+cu128 build, and try the Hugging Face Spaces demo before committing a GPU to it.

## FAQ

### What is MinerU-Diffusion?

It is an ECCV 2026 research implementation of a diffusion-based framework for document OCR, the official code for the paper Rethinking Document OCR as Inverse Rendering via Diffusion Decoding. The model is 2.5B parameters and is published on Hugging Face and ModelScope.

### How does block-wise diffusion decoding differ from autoregressive decoding?

Autoregressive decoding produces text left to right with each token depending on the previous ones. Diffusion decoding starts from masked tokens and refines them under visual conditioning, with black tokens confirmed, red tokens updated and yellow tokens still masked. The block-attention mask lets tokens attend bidirectionally within a block while attending causally to all preceding blocks, so refinement is parallel inside a block while the coarse structure stays autoregressive across blocks.

### What speed improvement does the README report?

The TL;DR states up to 3.2x faster decoding with block-wise diffusion and uncertainty-driven curriculum learning, while improving robustness and reducing reliance on language priors. The Performance section reports up to 3.26x TPS compared with MinerU2.5, with a configurable accuracy and throughput trade-off through threshold control.

### Can I train MinerU-Diffusion myself?

Not with this repository. Releasing the training code is an unticked item on the project's roadmap, alongside the MinerU-Diffusion-V2 release. The completed items are the V1 model release, SGLang support, the Nano-vLLM adaptation for single-GPU inference and the Gradio-based interactive demo.

### What are the system requirements for MinerU-Diffusion?

The requirements pin a CUDA 12.8 stack with an extra index for the pytorch cu128 wheels, torch 2.8.0+cu128, torchvision 0.23.0+cu128, transformers 4.52.1 and flash-attn 2.8.3, with Python 3.12 recommended in a Conda environment. SGLang server installation is excluded from the requirements and documented separately in docs/sglang/README.md.

## Sources

- [Issues](https://github.com/opendatalab/MinerU-Diffusion/issues)
- [License: MIT](https://github.com/opendatalab/MinerU-Diffusion/blob/main/LICENSE)
- [opendatalab/MinerU-Diffusion on GitHub](https://github.com/opendatalab/MinerU-Diffusion)
- [Project website](https://arxiv.org/pdf/2603.22458)
- [README](https://github.com/opendatalab/MinerU-Diffusion/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opendatalab-mineru-diffusion