Baidu Unlimited-OCR-2 Explained: Open-Source Document Parsing for Hundreds of Pages in One Pass

Quick Answer

Baidu's open 3B document parser reads hundreds of pages in one pass: 84.6 on MPDocBench, 77.1 on MarathonDocBench (vendor-reported, preliminary).

On October 27, 2026, Baidu open-sourced Unlimited-OCR-2, the second generation of its document parsing model: 3B class, MIT license, with code and weights on GitHub and Hugging Face (baidu/Unlimited-OCR-2). It targets a concrete problem: contracts, filings, and whole books running dozens to hundreds of pages — how to read them in one pass without breaking cross-page tables, footnotes, and references. The first generation (June 2026) handled dozens of consecutive pages; the second, with SR-SWA sparse attention, parsed all seven Harry Potter books — over 3,600 pages — in a single run in Baidu's demo. Two caveats up front: every benchmark figure here is vendor-reported (preliminary), with no independent reproduction yet; and “any page count” means the mechanism is no longer capped by page count, not that total cost stops growing — image encoding and total runtime still scale with pages.\n\nDisclaimer: this site is not affiliated with Baidu. This article is product-technology reporting and analysis, not procurement, deployment, or investment advice. Scores are vendor-reported and marked preliminary; hardware and hosting details follow official pages and may change.

1. What it is: a second-generation long-document parser, open-sourced two days ago

Get the timeline right so the two generations do not blur. Unlimited-OCR generation one shipped on June 22, 2026, building on the DeepSeek-OCR approach, using reference sliding window attention (R-SWA) to stretch parsing from single pages to dozens of consecutive pages. Unlimited-OCR-2 shipped on October 27, 2026, with the Hugging Face model page created on October 26; code and weights are open, with hosted access on Baidu AI Cloud and the Baidu AI Open Platform. Written on October 29, this term is two days old — there is no staleness question.\n\nThe model card facts: 3B class (about 3.3B by weight count), image-text-to-text, MIT license, about 6.2GB of BF16 weights, a 131,072-token context window shared by input and output, and about 273 image tokens per page. Inference comes in three flavors: Transformers for quick experiments, SGLang as the officially recommended serving route, and community vLLM support; official testing used a single NVIDIA A800 with 80GB. Two honest notes: no quantized build exists on the platform yet, so budget VRAM for the full weights plus activations and cache; and CPU inference works but gets much slower on long documents — do not run hundreds of pages on CPU.

2. The SR-SWA mechanism: every decoding step looks at a fixed 512 reference tokens

Why is long-document parsing hard? Under ordinary attention, each new token attends to everything written so far, so the KV cache and per-step compute grow with page count — cost breaks before accuracy does. The traditional workaround, parsing page by page and stitching results, breaks exactly where documents are most connected: tables spanning pages, paragraphs continuing across a break, footnotes and references pointing pages apart.\n\nSR-SWA (Sparse Reference Sliding Window Attention) caps the look-back: each decoding step attends to a fixed working set — a 128-token local window plus 16 blocks of 32 tokens selected by relevance, 512 remote reference tokens in total. A page gate first narrows each query's visual reference from the whole document to the relevant pages, then the highest-scoring token blocks fill in long-range dependencies. With the reference set fixed, per-step decoding latency and memory stay nearly constant as documents grow; combined with Unlimited-Horizon Decoding, the model handles documents of any length inside a finite context window. That is the real meaning of Baidu's “truly unbounded parsing within a finite window” slogan: the mechanism is unbounded, not the window.

3. Our own math: 3,600 pages are 7.5 windows, so “unbounded” is about mechanism, not window size

These figures are computed here from the model card's public parameters (recomputed), not quoted. At 273 image tokens per page: 100 pages cost 27,300 tokens, 300 pages cost 81,900, and 3,600 pages cost 982,800. The window holds 131,072 tokens, so 300 pages of image tokens leave about 49,172 tokens for output — at that scale the window itself still fits. But 982,800 tokens for 3,600 pages are about 7.5 windows; no window holds that. The demo passes in one run because of the fixed-reference mechanism from the previous section, not because the window is big.\n\nThe same math punctures a common misreading: nearly flat per-step cost does not mean flat total cost. Image encoding happens page by page, so total runtime still grows with page count; what is capped is the per-step attention penalty, not the machine's overall memory or time. Budget by that rule and the trap disappears: doubling pages roughly doubles total time, without the tail effect of each step getting slower as the document grows. And if your documents are under 30 pages, ordinary approaches are already enough — there is no reason to pay for “unbounded” at all.

4. Benchmarks: all vendor-reported, marked preliminary, no independent reproduction

Methodology first, scores second. MPDocBench is a multi-page parsing benchmark at the dozens-of-pages scale: Unlimited-OCR-2 scores 84.6 overall, about 6.3 points ahead of Qwen3.8-Max at 78.3, with Gemini-3.8-Flash at 76.2. MarathonDocBench is a new hundred-page benchmark (103–300 pages) Baidu introduced with this release: Unlimited-OCR-2 scores 77.1, against 33.7 for the next model, Kimi-K3 — a gap of about 43 points — while generation one scores 0. That zero is itself informative: hundred-page documents are essentially out of reach for the previous mechanism. One Chinese report gives the unrounded MarathonDocBench figure as 77.06, the same score at different rounding; this article uses 77.1 throughout.\n\nThe speed figures come from the same vendor source: in a 100-page setting, SR-SWA decodes each step 7 times faster than full attention and 5.6 times faster than generation one's R-SWA. All of this must stay labeled: Baidu's own measurements, no third-party reproduction, and MarathonDocBench is Baidu's own new benchmark, so the “home exam” caveat applies. Until independent evaluations appear, treat these scores as evidence of direction and magnitude, not as measured conclusions for a procurement case.

5. Selection guide: 30–300 pages is the sweet spot; under 30 pages it is unnecessary; at thousands of pages, budget total time

Three tiers. Tier one, documents under 30 pages — contracts, reports, papers: ordinary OCR or general vision models are enough, cross-page breakage is not a major issue, and there is no reason to switch for “unbounded” capability. Tier two, 30–300 pages — research reports, filings, prospectuses, manuals: this is Unlimited-OCR-2's sweet spot. One input keeps cross-page context, per-step cost does not tail off with page count, about 6.2GB of BF16 weights run on a single card, and the MIT license is commercially friendly — a direct fit for RAG and agent document ingestion. Tier three, thousand-page books and archives: the mechanism can do it — the 3,600-page demo proves that — but budget by total runtime (image encoding is per page) and spot-check cross-page tables and footnotes on your own document types first, since the reported benchmarks' document mix may not match your archive.\n\nDeployment suggestion: validate format and cross-page behavior on tens of pages with Transformers first, then move to SGLang for serving; before batching long documents, run one end-to-end 300-page timing test rather than trusting the per-step speedup multiple. Review scores (preliminary, from public sources, not our own testing): mechanism credibility high (multiple sources agree on the 512-token reference set, 128-token local window, and 16×32 remote blocks); benchmark-lead credibility medium (vendor figures, no independent reproduction, and MarathonDocBench is a home benchmark); local-deployability credibility high (weight size, inference routes, and test hardware are consistent across sources).

6. Sources and disclaimer

Sources (verified 2026-10-29):\n1) https://github.com/baidu/Unlimited-OCR — official repo: [2026/10/27] release of Unlimited OCR 2;\n2) https://huggingface.co/baidu/Unlimited-OCR-2 — official model page: MIT license, 3B class, Transformers and SGLang inference routes;\n3) https://letsdatascience.com/news/baidu-open-sources-unlimited-ocr-2-for-single-pass-long-docu-e22e3bc9 — release date, SR-SWA mechanism, MPDocBench 84.6, MarathonDocBench 77.1, 7x and 5.6x per-step speedups at 100 pages, 3,600-page Harry Potter demo;\n4) https://aiweekly.co/alerts/baidu-open-sources-unlimited-ocr-2-for-100-page-documents — 512-token reference set, 128-token local window, 16x32 remote blocks, Kimi-K3 33.7, Qwen3.8-Max falling to 22.9 on the long set;\n5) https://alphasignal.ai/news/baidu-open-sources-unlimited-ocr-2-to-parse-hundred-page-documents-at-once — 6.7GB BF16 weights figure, 131,072-token window, A800 test hardware, 273 tokens per page;\n6) https://cpu3d.com/zh/ainews/novaya-model-unlimited-ocr-2-image-text-to-text/ — Hugging Face page created 2026-10-26, 3.3B parameters, 6.2GB repo, no quantized build yet;\n7) https://alfw.ai/article/baidu-unlimited-ocr-2-marathon-benchmark/ — the caveat on the “unbounded” claim: flat per-step cost is not flat total cost; image encoding and total runtime still grow with page count.\n\nDisclaimer: this site is not affiliated with Baidu. This article is product-technology reporting and analysis, not procurement, deployment, or investment advice. Benchmark scores are vendor-reported, marked preliminary, and not yet independently reproduced; hardware and hosting details follow official pages and may change.

Side by side: Unlimited-OCR-2 vs page-by-page stitching vs general vision models vs generation one

Approach	Pages per pass	Cross-page context	Per-step cost vs pages	License and access
Unlimited-OCR-2 (Baidu)	Hundreds of pages; 3,600+ in demo	Kept, single input	Nearly flat (fixed 512 reference tokens)	MIT, open on GitHub and Hugging Face
Unlimited-OCR, generation one	Dozens of consecutive pages	Kept within R-SWA reference window	Grows with reference window	MIT, open
Page-by-page OCR, stitched	Unlimited (batched)	Breaks at joins: cross-page tables, footnotes, references often lost	Fixed per page, plus stitching cost	Mostly traditional OCR toolchains
General vision model, whole book as input	Limited by context window	Kept inside window, truncated beyond	KV cache and per-step cost grow with pages	Mostly closed API or large weights

MPDocBench overall scores (vendor-reported, preliminary)

★ Unlimited-OCR-284.6

Qwen3.8-Max78.3

Gemini-3.8-Flash76.2

数据来源：Sources: Baidu's reported benchmark figures (consistent across multiple reports, 2026-10-29); no independent reproduction yet, for order-of-magnitude reference only

Frequently Asked Questions

Can Unlimited-OCR-2 really read an “unbounded” number of pages?

Mechanically yes, cost-wise no. SR-SWA fixes each decoding step's reference set at 512 tokens, so per-step latency and memory stop growing with page count — the demo passed 3,600 pages in one run. But image encoding still happens page by page, so total runtime grows with pages, and overall memory does not stand still either. Read it as “no longer capped by page count per step,” not as “pages are free.”

What hardware does local Unlimited-OCR-2 need?

About 6.2GB of BF16 weights; official testing used a single NVIDIA A800 with 80GB. Large-VRAM consumer cards can run it by the weight math, with room left for activations and cache. Transformers fits quick experiments, SGLang is the officially recommended serving route, and community vLLM support exists; no quantized build is available yet, and CPU inference gets much slower on long documents.

Are the 84.6 and 77.1 scores trustworthy?

Only as reference for now. Both figures are vendor-reported, marked preliminary, with no independent reproduction; MarathonDocBench is also Baidu's own new benchmark, so the home-exam caveat applies. Use them to judge direction and magnitude, not to argue a procurement case, until independent evaluations appear.

What changed from generation one?

The mechanism. Generation one used R-SWA reference sliding windows and handled dozens of consecutive pages, scoring 0 on hundred-page MarathonDocBench. Generation two switches to SR-SWA sparse references, compressing the reference set into a fixed 512 tokens, pushing the page ceiling from dozens to the 3,600-plus-page demo and lifting MPDocBench to 84.6.