A scanned book is a strange object for a language model. Every page is easy. The problem is that there are three thousand of them, and the model has been trained to hold the whole thing in view.
Most document systems solve this by cutting the book into slices, parsing each slice, and stitching the results back together. The seams are where the errors live: a table that starts on page 41 and ends on page 42, a footnote that refers to a chart two pages earlier.
Baidu's answer, published on 27 October, was to change what the model looks at rather than how much it can hold.
Key takeaways
- Baidu released Unlimited OCR 2, an open-weight (开源权重) document parser, on 27 October under an MIT licence with about 3.3 billion parameters.
- Its sparse reference sliding window attention caps the visual context each decoding step can consult, so cost per step stops growing with page count.
- Baidu demonstrated it on all seven Harry Potter books, over 3,600 pages, parsed in a single pass.
- It reports 84.6 on MPDocBench and 77.1 on MarathonDocBench — the second is a benchmark Baidu built itself.
- The idea generalises beyond OCR: long-context cost is a design choice, not a law of attention.
What was released
Unlimited OCR 2 is the second generation of a model Baidu's ERNIE team shipped in June. The first version used a reference sliding window to keep the decoder's KV cache bounded, which pushed its ceiling to a few dozen consecutive pages. That was enough to top GitHub's trending list and to get shared by Yann LeCun, but not enough for a bound report or a scanned archive.
The new model changes the attention mechanism rather than the window size. Baidu calls it SR-SWA — sparse reference sliding window attention. A page gate first narrows each query's visual reference from the entire document down to the pages likely to matter, while still modelling cross-page position. A second stage pulls in the highest-scoring visual token buckets to catch long-range dependencies, the way a person copying a manuscript glances back only when a sentence refers to something earlier.
The point is that the reference set is bounded. Decoding step one thousand costs about what decoding step ten costs.
Why that is the interesting part
Document parsing (文档解析) is usually framed as an accuracy problem. It is mostly a cost problem.
Full attention over a long document grows quadratically, and even linear-attention approximations keep a cache that grows with length. Both make long documents expensive in a way that scales with the thing you are trying to process. If your unit cost rises with page count, "unlimited pages" is a marketing phrase, not a product.
Baidu's claim is narrow and checkable: at hundred-page scale, one decoding step is about seven times faster than full attention and about 5.6 times faster than the previous generation's sliding window. Not a claim about total runtime, and not a claim about quality. A claim about the slope.
A model whose per-step cost is flat can still be slow overall, because you still take one step per token. What changes is that the tenth hour of a job costs no more than the first.
The demonstration is the checkable part
The demo Baidu chose is deliberately concrete: all seven Harry Potter novels, more than 3,600 pages, in a single pass.
Fiction is not a representative workload — it is a long document with consistent typography and no tables. But the demo is falsifiable in a way most are not: either the model consumes 3,600 pages or it does not.
Baidu reports 84.6 on MPDocBench, a multi-page parsing benchmark, and 77.1 on MarathonDocBench, which it describes as covering hundred-page documents. It says both are state of the art among end-to-end parsers, ahead of Qwen3.8-Max, Gemini-3.8-Flash, GLM-5.3-Flash and DeepSeek-4.1-Flash.
The benchmark they wrote themselves
A careful reader should slow down here.
Baidu released MarathonDocBench alongside the model. The company is entitled to build a benchmark for a gap nobody else was measuring — hundred-page documents are genuinely under-tested — but a benchmark published alongside the model it crowns is evidence of a claim, not proof of one.
The general-purpose vision models in that comparison score between roughly 7 and 34 on MarathonDocBench. That spread says more about the task than about those models: hundred-page parsing is a different problem from page parsing.
MPDocBench is the more informative number, because it is an existing multi-page benchmark with published baselines rather than one written for this launch. Even there, the comparison table is Baidu's, and the harness is Baidu's.
Honest limitations
I have not run this model. Everything quantitative here comes from Baidu's announcement, its published comparisons, or the Hugging Face listing, and the 3.3 billion parameter figure is the checkpoint's stated size rather than something I measured.
The speed claims are per decoding step at hundred-page scale; total wall-clock time on your hardware, with your page sizes and your image resolution, will differ. No independent group has reproduced the benchmark scores. MarathonDocBench is new and vendor-authored, so its rankings should be read as a first data point rather than a standard.
The Harry Potter demonstration is a single workload with clean typography. Invoices, handwritten notes, multi-column academic papers and degraded scans are where document models usually fail, and none of those appears in the headline demo. Baidu says it will present more at its Baidu World event on 12 November; that is where the harder cases should be examined.
What readers can do now
- If you process long PDFs, test the boundary rather than the average: a table that spans a page break, a footnote that points backwards. That is where chunk-and-stitch pipelines fail and where this class of model is claiming an advantage.
- Ask vendors for cost per thousand pages, not tokens per second. Flat per-step cost only becomes a saving when it survives your document mix.
- The weights are open and MIT-licensed. Run a hundred pages of your own worst documents before believing any benchmark, including this one.