Unlimited OCR 2: Performance, Local Deployment, and How It Compares

Baidu released Unlimited OCR 2 on October 27, 2026: an open-source, MIT-licensed 3.34B-parameter vision-language model built to parse very long documents — books, filings, and reports of hundreds of pages — in a single request. Its headline change is a new attention scheme called SR-SWA that keeps the cost of each decoding step nearly flat as documents grow. In Baidu's own benchmarks it leads both multi-page document-parsing tests the team reports, including a new hundred-page benchmark where the next-best model scores less than half as well. Deployment-wise, the model card documents a straightforward Transformers path for quick tests and a customized SGLang wheel for serious serving, with the first tests run on an 80 GB NVIDIA A800.

This article walks through what the model actually is, how SR-SWA works, what the benchmarks do and don't prove, what the documented deployment path requires, and how it compares with other open OCR models. One framing note up front: every performance number below is self-reported by Baidu — there is no independent benchmark in this piece, and where a figure comes only from a chart, we say so.

Key takeaways

• Unlimited OCR 2 is Baidu's second-generation long-document OCR model: 3.34B total parameters (MoE), MIT license, released October 27, 2026 on Hugging Face, ModelScope, and Baidu Cloud.
• SR-SWA (Sparse Reference Sliding Window Attention) compresses attention over ultra-long documents into a fixed ~512-token working reference set, so per-step decoding latency and memory stay nearly constant as page count grows.
• Self-reported results: 84.6 on MPDocBench and 77.1 on MarathonDocBench — versus 33.7 for the next model on the hundred-page benchmark. Heading hierarchy is its weakest skill (48.2 on MarathonDocBench).
• Local deployment is documented on one CUDA GPU (tested on A800-80GB, BF16 weights ≈ 6.7 GB): Transformers with trust_remote_code=True for quick tests, a customized SGLang wheel for serving at scale.
• Against rivals: DeepSeek-OCR-2 (3.39B, Apache 2.0) and PaddleOCR-VL-1.6 (0.96B, Apache 2.0) are credible alternatives, but neither appears on Baidu's two benchmarks, so the comparison rests on design and ecosystem, not measured scores.

What Is Unlimited OCR 2?

Unlimited OCR 2 is a document-parsing vision-language model from Baidu's ERNIE team. You feed it ordered page images; it returns structured text — paragraphs, tables, formulas, headings, and reading order. It is the successor to Unlimited-OCR, which Baidu presented in June 2026 as an attempt to "push DeepSeek-OCR one step further," and it inherits that lineage: the architecture keeps a DeepSeek-OCR-style layout, and the model card explicitly credits DeepSeek-OCR, DeepSeek-OCR-2, and PaddleOCR as inspirations.

The v2 release landed on October 27, 2026, alongside MarathonDocBench, a new benchmark the team built specifically for hundred-page-scale parsing. The technical report, Unlimited OCR Works 2, followed on arXiv on October 29. The team frames the release as "pioneering the OCR-3.0 era" — their tagline, not an independent verdict.

Under the hood, per a config-level review published by MarkTechPost, the model pairs a SAM ViT-B plus CLIP-L image encoder with a 12-layer mixture-of-experts decoder, where each token routes to 6 of 64 experts plus 2 shared experts — the decoder design the DeepSeek-OCR paper called DeepSeek3B-MoE-A570M. In multi-page mode, each page costs 273 image tokens. Weights and code are on Hugging Face, with mirrors on ModelScope and Baidu Cloud, a community demo on HF Spaces, and — already — twelve community quantizations for llama.cpp, Ollama, and LM Studio.

Source: baidu/Unlimited-OCR-2 model card on Hugging Face (huggingface.co), accessed November 2, 2026.

How SR-SWA Removes the Long-Document Bottleneck

The problem SR-SWA solves is quadratic attention cost. Full attention grows quadratically with sequence length, and during decoding every new token must scan a longer key-value cache. Because Unlimited OCR 2 encodes each page as 273 image tokens, a 100-page document adds roughly 27,300 input tokens before the model writes a single output token — and the scan gets slower with every page.

SR-SWA stands for Sparse Reference Sliding Window Attention. Instead of letting every token attend to the entire ultra-long sequence, it compresses text-visual attention interactions into a fixed-size set of working references — 512 tokens in the documented example. The config pairs a 128-token local window (what the model is literally transcribing right now) with a top-16 selection over 32-token blocks (what it keeps as global context). The paper describes the inspiration as human book transcription: you look only at what you're transcribing, plus a bounded memory of what came before, rather than re-reading every previous page.

The result the model card claims: per-step decoding latency and memory footprint stay nearly constant regardless of document length. At hundred-page scale, the paper reports a 7.0× per-step speedup over full attention and 5.6× over R-SWA, the attention scheme used in v1. That's what makes "unlimited-horizon parsing" possible inside a finite 131,072-token context window: the horizon is unbounded in pages, not in a single step's compute.

Two honest counterweights. First, "nearly constant per-step cost" is not "constant total runtime" — image encoding and overall processing still rise as pages grow. Second, "unlimited" operates within that context window and the page-window scheduling the serving stack uses; it's an engineering claim about scaling behavior, not a promise of instantaneous hundred-page transcription.

Illustrative diagram created for this article; it depicts the mechanism conceptually, not measured behavior. Left: every token attending to every page. Right: a 128-token local window plus a fixed ~512-token reference set.

How Well Does It Actually Perform?

Short answer: by Baidu's own measurements, state of the art on both multi-page benchmarks the team reports — with the strongest showing exactly where other models collapse, at hundred-page scale, and one clearly weak sub-skill. All numbers in this section come from Baidu's leaderboard and paper; MarkTechPost notes some figures appear only as a chart image, and no independent party has reproduced them yet.

On MPDocBench, which uses documents of dozens of pages, Unlimited OCR 2 scores 84.6, ahead of Qwen3.8-Max at 78.3 and Qwen-3.8-Flash-Next at 77.4. On MarathonDocBench — the team's new hundred-page benchmark — it scores 77.1, with the next-best model, Kimi-K3, at 33.7 and Gemini-3.8-Flash at 28.6.

The degradation gap is the more telling comparison. Unlimited OCR 2 loses 7.5 points moving from dozens-of-pages to hundreds-of-pages documents. Qwen3.8-Max falls from 78.3 to 22.9 — a 55-point collapse. The predecessor Unlimited-OCR, without SR-SWA, scores 0.0 on MarathonDocBench: the v1 mechanism simply doesn't survive hundred-page documents. That contrast is the strongest signal in the release, though it's also exactly the comparison the vendor chose to publish.

Sub-scores (MPDocBench / MarathonDocBench), from Baidu's chart via MarkTechPost:

Text and formula extraction are excellent on both scales. Tables hold up reasonably well (74.8 on the hundred-page benchmark). Heading hierarchy is the weak spot — 48.2 on MarathonDocBench is the model's lowest sub-score — so documents whose structure depends on deeply nested headings deserve extra validation. Also worth noting: single-metric margins on MPDocBench are thin (Qwen3.8-Max scores 94.3 on text and 89.2 on formulas, essentially level with v2), so the "SOTA" claim really rests on the long-document results.

Source: arXiv abstract page for 'Unlimited OCR Works 2' (arxiv.org/abs/2610.39308), accessed November 2, 2026.

Running Unlimited OCR 2 Locally

Everything in this section is documentation-based — from the model card and GitHub README, not from our own runs. The model card documents two supported paths: Transformers for quick tests and SGLang for serving, tested on an NVIDIA A800-80GB.

Quick tests with Transformers

The Transformers path targets single-machine experiments. The documented environment pins Python 3.10, torch 2.13.0, transformers 4.52.1, huggingface-hub 0.36.0, and tokenizers 0.21.4. Loading the model requires trust_remote_code=True — worth pausing on, because that flag executes Python code shipped in the model repository. For an MIT-licensed model from a major vendor that's a normal trade-off, but it is a supply-chain trust decision you're making.

Two inference modes are documented. infer() handles a single page with dynamic tiling (called "gundam mode"), useful for high-resolution pages. infer_multi() parses every page of a document in one request — the prompt is built as <PAGE><image> repeated per page plus "Multi page parsing." — so the model can use cross-page context, which is the whole point of a long-document model. Output keeps one <PAGE> marker per input page, in order.

Serving with the customized SGLang wheel

For serving, the card recommends SGLang — but not the upstream package. You install a customized Baidu wheel (sglang-0.5.20.dev13+g75b9b06b02) plus PyMuPDF for converting PDF pages to images. That's a real operational consideration: you're pinned to a vendor fork of a fast-moving inference framework, and upgrades are on Baidu's release cadence, not SGLang's.

The documented configuration encodes several hard-won memory lessons:

• Page windows: very long documents are scheduled in 10-page windows (gundam or base mode), with the KV tail of the previous window reused. Smaller windows lower peak memory but hurt cross-page merging, because blocks that continue across a window boundary lose their context.
• --mem-fraction-static 0.7: the documented stable value. 0.75 leaves too little headroom at 32+ concurrent requests.
• --max-prefill-tokens: drives a temporary tensor of roughly [tokens, context/32], so memory grows linearly with it — dropping 4096 to 2048 halves that peak. The largest --cuda-graph-bs-prefill bucket must equal this value, or oversized batches silently fall back to eager execution.
• CUDA graph concurrency: the default full_prefill_max_req of 8 makes 16/32-way concurrency fall back to eager mode; the documented config raises it to 64.
• The SAM bias OOM trap: the built-in default chunk cap (512) for the SAM attention bias allows a single ~462 MiB allocation that can OOM the process. Setting SGLANG_OPT_UOCR_SAM_REL_POS_BIAS_MB=64 is documented as equivalent with a much lower peak. PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True further reduces fragmentation failures.

The serving API contract

Once the server runs, you talk to an OpenAI-compatible /v1/chat/completions endpoint with base64-encoded page images. The documented request pattern: temperature 0, a no-repeat n-gram logit processor (n-gram size 35; window 1024 for multi-page, 128 for single-page) to suppress repetition, max_tokens set to tokens-per-page × page count (the example uses 8,000 per page, with a 20,000 per-page output cap), and PDFs converted to images at 300 dpi before submission.

Lighter paths and availability

Not everyone needs the full serving stack. The Hugging Face page already lists twelve community quantizations usable with llama.cpp, Ollama, and LM Studio, plus a Docker Model Runner one-liner. The model is mirrored on ModelScope and Baidu Cloud, and the ms-swift community added fine-tuning support on October 28. One honest gap: outside the A800-80GB test setup and the ~6.7 GB BF16 weight footprint, no minimum VRAM is documented — budget for activation memory, page batches, and the framework itself, and verify on your own hardware.

How It Compares With Other Open OCR Models

The honest comparison table, assembled from MarkTechPost's cross-reference of each model's Hugging Face page plus Baidu's chart:

Read the benchmark rows carefully: DeepSeek-OCR-2 and PaddleOCR-VL-1.6 don't appear on Baidu's two benchmarks at all, so "first place" means first among the nine models Baidu chose to chart — self-reported, remember. What the table does support: v2 is the only model in this set with a documented mechanism aimed at hundred-page parsing, and its measured drop (7.5 points) across document scales is small where competitors' collapse.

For choosing between them: if your task is one-shot parsing of long documents — book archives, hundred-page filings, multi-page reports for RAG pipelines — Unlimited OCR 2 is the only one of these models designed and benchmarked for exactly that. For lightweight, single-page extraction at scale on modest hardware, a 0.96B model like PaddleOCR-VL-1.6 is a rational choice with a permissive license and its own mature tooling. If you're already invested in the DeepSeek ecosystem, DeepSeek-OCR-2 keeps you there. And if you need long-document parsing under an Apache 2.0 license specifically, that alone rules the MIT-licensed Baidu models out.

Limitations to Weigh Before You Deploy

Before treating any number above as a purchase decision, the caveats that matter:

• Everything is self-reported. No independent benchmark of Unlimited OCR 2 existed in our sources. The strongest results are on MarathonDocBench — a benchmark introduced by the same team that built the model, released the same day (October 27, 2026).
• Some numbers are chart-only. Several leaderboard figures are visible only as chart images rather than tables in the paper, which makes precise verification harder.
• Heading hierarchy is weak. At 48.2 on MarathonDocBench, the model's lowest sub-score, structure-heavy documents may need post-processing.
• Operational strings attached. The serving path pins you to a customized SGLang wheel, and even the Transformers path runs repository code via trust_remote_code=True. Both are trust decisions, not just convenience settings.
• Undisclosed internals. Active parameter count for v2 isn't published, and minimum VRAM beyond the A800-80GB test configuration isn't documented.

The Bottom Line

Unlimited OCR 2 is the most credible open-source option today if your problem is specifically "parse a very long document, in one pass, with structure intact" — and the self-reported numbers suggest the margin over alternatives is largest exactly there. The SR-SWA mechanism is a real architectural answer to the quadratic-cost wall that made hundred-page OCR impractical, and v1 scoring 0.0 on the same benchmark makes the generational jump concrete.

But the evidence base is entirely the vendor's. If you're evaluating it, the productive next step is a small, controlled bake-off on your own documents: a heading-heavy report, a table-dense filing, a hundred-page PDF representative of your workload — against your current parser, with your hardware, at your page lengths. The model's own documentation gives you everything needed to run that test in an afternoon; the benchmarks give you a hypothesis to test, not a conclusion to trust.