Baidu Unlimited OCR 2 Is a Finite Budget for Long Document Parsing

The failure that actually costs money

The expensive failure in document AI is rarely a misread word on page one. It is a heading that loses its parent, or a table that starts on one page and finishes on the next, after a pipeline has already sawed the file into polite little chunks.

That cut is what an agent inherits. A credit agreement, a 10-K excerpt, a bid package: if the heading tree collapses, or a pricing table splits, the system downstream is reasoning over a damaged document object. In AI automation for sales and procurement (RFP binders, security questionnaires, contract review), that is a workflow defect, not a formatting nit. A demo in which an agent “reads the contract” is only as reliable as the object it was handed.

Baidu has open-sourced a model aimed at that cut. Unlimited OCR 2 is a vision-language OCR system it describes as 3.34 billion parameters, built to take ordered page images (books, filings, reports running into the hundreds of pages) and return structured output in one request: text, tables, formulas, figures, headings, and reading order. Weights are published under the MIT license as baidu/Unlimited-OCR-2. Code is in the GitHub repo baidu/Unlimited-OCR.

Unlimited is a product name. The spec is a budget.

The method is described as “unlimited-horizon” parsing within a finite context window.

Finite is the word that matters. Baidu lists a maximum position length of 131, 072 tokens. Treat that as a configuration ceiling, not a length the release has shown the model can fill with a finished transcript. The working set of references is finite. On Baidu’s account, encoding cost and total runtime still rise as pages pile up. What stays nearly flat, on that same account, is the latency and memory of each decoding step, not the time to finish the job.

What the line was already doing

The published configuration follows a DeepSeek-OCR-style layout. A SAM ViT-B encoder plus CLIP-L feeds a 12-layer mixture-of-experts decoder, the kind that routes each token to a handful of specialist sub-models instead of activating every parameter. Each token goes to 6 of 64 experts, plus 2 shared experts. That recipe is not an active-parameter count. Baidu has not published one for version 2.

Do not borrow the earlier figure. The DeepSeek-OCR paper names its decoder DeepSeek3B-MoE-A570M, about 570 million parameters active per token. The first Unlimited-OCR, which materials around this release date to June 2026, was reported as roughly 3 billion total parameters and about 0.5 billion active, a continued-training extension of DeepSeek-OCR, not a model grown from a blank slate. Those are lineage facts. They are not a confirmed activation count for Unlimited OCR 2.

The lineage does explain the problem this work has been chewing on. DeepSeek-OCR compressed the input: turn a page into a few hundred vision tokens instead of thousands. Its paper reports about 97 percent OCR precision when text tokens stay within 10 times the vision tokens, and about 60 percent at a 20-times compression, plus a production claim of more than 200, 000 pages a day on a single A100-40GB. Useful, and beside the point once the model starts writing. Each new word looks back over a longer transcript. Chunking the PDF was the engineering workaround.

Two attention rules, not one renamed

The first Unlimited-OCR attacked that output-side growth with R-SWA, Reference Sliding Window Attention. In a technical note on that release, Masayuki Abe describes the rule cleanly: each generated token keeps full access to the visual tokens and the prompt, and only a short tail of recently written output, 128 tokens by default. Older generated text is dropped from a fixed queue. Picture a clerk who keeps the original filing on the desk and glances only at the last line they typed. The page stays sharp. The transcript already produced does not have to be reread in full.

Abe puts that model’s context cap at 32, 000 tokens, with a realistic range of several dozen pages. On OmniDocBench v1.5, figures he reports from that model’s comparison put Unlimited-OCR at 93.23 overall, ahead of DeepSeek-OCR 2 at 89.17 and a far larger Qwen3-VL 235B at 89.15. Strong on the page-level test it published. Not a hundred-page system. Those numbers are not results for version 2.

SR-SWA (Sparse Reference Sliding Window Attention) is the change claimed for version 2, and it is a different rule. Where the first model kept every visual reference, Baidu’s description of SR-SWA compresses text-visual attention into a fixed working set, so the cost of each decode step stays nearly flat as the document grows. The original filing is no longer held in full at every step. A selected stack is.

How big is that stack? The config pairs a 128-token local window with a top-16 selection over 32-token blocks, and 16 times 32 is 512, which matches the model card’s example budget. A second description says the decoder attends to 512 reference tokens and a 128-token local window. Do not add those figures, and do not pick one, without reading the config.

The budget the name hides

Multi-page mode, on Baidu’s config, costs 273 image tokens per page. A 100-page packet is 27, 300 input tokens before the model writes a word. Generated text spends the same 131, 072-token budget the name obscures.

The rest is multiplication, not a measured cutoff. At 273 tokens a page, 400 pages are 109, 200 image tokens, leaving on the order of 22, 000 for the prompt and everything the model emits. At 480 pages, image tokens alone are 131, 040, which nearly fills the listed ceiling. Baidu’s attention demo counts input image tokens only. One request is an API shape. It is not evidence that a few hundred pages plus a full structured transcript fit inside the window.

Weights in BF16 are about 6.7 GB. Baidu says inference runs on one CUDA GPU in BF16, and it tested on an NVIDIA A800-80GB. A small weight file is not a small job. Activations, the cache, and page encoding still have to fit, and on Baidu’s account they grow with the document even when each decode step does not. Baidu also warns that a default bias setting can trigger a 462 MiB allocation and run out of memory. Size a pilot to the card they used, not to the checkpoint in isolation.

A smaller drop, on a chart you cannot audit

Every score that follows is Baidu’s, taken from a chart image, and not independently replicated. The chart does not disclose the evaluation protocol, whether other models were allowed to chunk, or what context each was given. The names below are printed as chart labels: Qwen3.8-Max, Gemini-3.8-Flash, DeepSeek-4.1-Flash, GLM-5.3-Flash, Kimi-K3, and the rest. They do not reliably match the product names on a typical vendor list. A public release of MarathonDocBench was not locatable in the October 2026 materials around this announcement. Unlimited-OCR’s 0.0 on that bench should not be read as “worst.” The chart does not say whether that zero is a measured score or a run that never completed. A 32, 000-token ceiling on the predecessor makes a zero plausible. Plausible is not a verification.

So these are the MarathonDocBench overall scores on Baidu’s chart, names as printed. Baidu reports first place against nine other models:

  • Unlimited OCR 2: 77.1
  • Kimi-K3: 33.7
  • Gemini-3.8-Flash: 28.6
  • Qwen-3.8-Flash-Next: 27.8
  • Gemini-3.1-Pro Preview: 27.0
  • Qwen3.8-Max: 22.9
  • Minimax-M3: 18.0
  • DeepSeek-4.1-Flash: 12.3
  • GLM-5.3-Flash: 7.5
  • Unlimited-OCR: 0.0

On the shorter bench, MPDocBench, Baidu reports 84.6 overall, with the models labeled Qwen3.8-Max at 78.3 and Qwen-3.8-Flash-Next at 77.4 next among the scores it cites. The same model’s drop between the two benches is 7.5 points, from 84.6 to 77.1. Qwen3.8-Max, on that chart, falls from 78.3 to 22.9.

A public parse set, MPDocBench-Parse, is cited as arXiv 2605.22100 and described as 433 documents and 3, 246 pages. Baidu’s 84.6 is an overall on a chart labeled MPDocBench. Nothing in the release shows that 84.6 is the score on that public set. Exact page counts behind “hundreds, ” the languages, and the document types on MarathonDocBench are not independently published.

On the shorter bench, the lead is thinner than an overall suggests. Baidu’s chart puts Unlimited OCR 2 at 94.8 on text and 89.4 on formulas, against 94.3 and 89.2 for the model labeled Qwen3.8-Max. Skip the “best OCR on a page” reading. The claim that matters is that accuracy falls less when the document gets long, and that claim is also the least checkable one in the release.

The sub-scores Baidu published, MPDocBench then MarathonDocBench, run like this. Text: 94.8 / 89.6. Formulas: 89.4 / 87.9. Reading order: 92.3 / 85.3. Tables: 87.8 / 74.8. Heading hierarchy, measured with TEDS, a tree-similarity score for structure: 60.1 / 48.2. Figure detection, an F1 on the same chart, sits at 72.9 / 71.8.

Heading hierarchy is the lowest of those scores, and it was never high. Tables drop 13 points, steeper than the 7.5-point overall drop. Figure detection barely moves, and a steady F1 near 72 is still a mediocre one. Stable is not good. If the automation depends on “this covenant sits under Article IV, and the table continues from page 87, ” those are the numbers to stare at. An average can look healthy while the skeleton of the document softens.

What an operator actually runs

Name the object before you name the model. Baidu describes the return as structured output covering text, tables, formulas, figures, headings, and reading order. The model card indicates one PAGE marker per input page. It does not publish a schema (markdown, JSON, HTML, or otherwise) that an integration can assume. The predecessor, in Abe’s account, emitted Markdown plus layout information. Version 2’s card does not restate that contract in those words. Inspect the payload an agent would actually consume before anyone wires a workflow to it.

Baidu’s suggested path splits by job size. Hugging Face Transformers is the quick test. A single-page call, infer, uses dynamic tiling (high-resolution slicing of one page, called gundam mode in this stack). infer_multi sends every page in one request and is meant to keep context across pages, which is the point of not chunking.

Serving is a different procurement conversation. The path uses a customized Baidu build of SGLang, a model-serving stack, not the public upstream package. The example handles 10 pages per window and reuses the tail of the previous window’s key-value cache, the running memory of tokens already computed. Smaller windows cut peak memory. They also weaken cross-page merging. The feature you came for is what you trade away to fit the GPU you have.

Loading requires trust_remote_code=True, which executes Python from the repository at load time. That is a supply-chain decision. It is not a checkbox on a shared runner because a notebook said so.

The MIT license and a single-GPU inference claim make a pilot cheap relative to a closed document API. Run it on the documents that already embarrass the current system (multi-page tables, nested headings, formulas) and score those fields yourself. A chart does not retire a chunk-and-stitch pipeline. A scored pilot on the failures you already have might.

Questions worth asking first

  • Is Unlimited OCR 2 actually unlimited?

    No. The listed context cap is 131, 072 tokens, and that figure is a configuration ceiling, not a demonstrated working length. The reference set is finite, and on Baidu’s account encoding plus total runtime still grow with page count. “Unlimited-horizon” is a claim about keeping per-step decode cost nearly flat inside that window, not a blank check on length or compute.

  • How is this different from the first Unlimited-OCR?

    The predecessor used R-SWA: full access to visual tokens and the prompt, plus a short tail of recent output, inside a 32, 000-token cap and a realistic range Abe describes as several dozen pages. SR-SWA, as Baidu describes version 2, sparsifies the visual references themselves into a fixed working set. The active parameter count for version 2 has not been published, and the earlier 0.5 billion active figure does not transfer.

  • Is attention simply capped at 512 tokens?

    Not cleanly. A 512-token budget matches a top-16 selection over 32-token blocks, paired in the config with a 128-token local window. Another description puts 512 reference tokens beside that 128-token window. Do not add those figures, and do not fold them into one, without reading the config.

  • Did it win the long-document benchmarks?

    On Baidu’s own chart, it places first: 84.6 on MPDocBench and 77.1 on MarathonDocBench, with a much smaller drop than the models listed beside it. Those scores are not independently verified. A public MarathonDocBench release was not locatable as of October 2026, and the chart does not show whether baselines could chunk. On text and formulas in the shorter bench, the margin over the model labeled Qwen3.8-Max is a few tenths of a point.

  • Where does quality still slip?

    Heading hierarchy is the weak spot, at 60.1 and 48.2 TEDS on the two benches. Tables fall from 87.8 to 74.8. Figure F1 stays near 72 to 73, which is steady and still mediocre. Text, formulas, and reading order hold up better. If the workflow is structure, not transcription, the average will flatter the model.

  • Will a few hundred pages fit in one request, output included?

    Not automatically. At 273 image tokens per page, image tokens alone approach the 131, 072 cap well before a full structured transcript has room. At 480 pages they nearly fill it, and that is arithmetic, not a measured limit. One request is how multi-page inference is designed to be called. It is not a guarantee that input plus output fit.

  • What does the model actually return, and which fields should you score?

    Baidu describes structured output covering text, tables, formulas, figures, headings, and reading order, and the model card indicates one PAGE marker per input page. It does not publish a schema you can assume is markdown, JSON, or anything else. Before this replaces a chunk-and-stitch pipeline, score heading hierarchy and tables that cross a page break on your own filings, the fields that already fail, and the ones the chart shows softening.

  • What should a business check before this touches a workflow?

    That loading the weights runs repository code. That the serving path is Baidu’s custom wheel, not the public SGLang package. That a 10-page window saves memory and can hurt cross-page merges. And that a default bias setting can allocate 462 MiB and run out of memory. Then score your own filings on headings and split tables. The license makes that pilot easy. The chart does not make it optional.

0