Baidu Open-Sources Unlimited OCR 2: A 3B Model That Parses Hundreds of Pages in a Single Pass

Baidu open-sources Unlimited OCR 2, a 3B MIT-licensed model using SR-SWA to parse 100+ pages in one pass.
Baidu has open-sourced Unlimited OCR 2, a 3B-parameter MIT-licensed OCR model that can parse hundreds of pages in a single request. Traditional long-document OCR struggles with VRAM and decoding costs that grow linearly with page count. Unlimited OCR 2 uses SR-SWA attention to keep per-step decoding cost nearly constant and scores 77.1 on MarathonDocBench. Its 3B scale and MIT license lower barriers to enterprise integration, though independent testing is still needed.
Baidu has open-sourced Unlimited OCR 2, a 3B-parameter OCR model under the MIT license, whose core selling point is the ability to parse hundreds of pages of documents in a single request. According to MarkTechPost, the model uses an SR-SWA attention mechanism to keep per-step decoding cost nearly constant, and it scores 77.1 on MarathonDocBench.

Where long-document OCR hits its bottleneck
Traditional OCR models face two levels of problems when processing long documents. First, memory and VRAM usage grow linearly with page count, so beyond a few dozen pages you often need to split the input and run inference in batches. Second, computation during decoding inflates with context length—the more pages, the slower each generation step.
These limits mean that so-called "long-document support" often degrades in engineering practice into "paginate + stitch results together," which adds system complexity and tends to introduce errors at the seams between pages. Unlimited OCR 2 is trying to solve this structural bottleneck rather than simply enlarging the context window.
KV Cache (key-value cache) is a core mechanism in autoregressive decoding for large models: to avoid recomputing the keys and values of all historical tokens every time a new token is generated, the inference system caches these intermediate results and reuses them in subsequent steps. Its VRAM footprint is proportional to the context length processed so far, so when handling long documents, VRAM keeps growing with page count—one of the main bottlenecks of traditional long-document OCR. Breaking this limit requires keeping the cache size from growing without bound with input length, for example by using a sliding window to discard expired cache entries or by replacing the full cache with a fixed-size compressed state—which is precisely the core problem that Unlimited OCR 2's claim of "nearly constant per-step decoding cost" aims to solve.
SR-SWA: keeping decoding cost flat
The model's key design is the SR-SWA attention mechanism. The report notes that it keeps the cost of each decoding step nearly flat—in other words, the per-step cost of processing the hundredth page is close to that of processing the first page, rather than accumulating as page count rises.
The practical deployment significance is this: one-shot parsing of long documents goes from "theoretically feasible" to "usable in engineering." For teams handling contracts, financial reports, archives, scanned books, and similar scenarios, completing an entire document's parsing in a single request can significantly simplify pipeline design.
It should be noted that the source material only provides a qualitative description and a benchmark score; it does not disclose the specific implementation details of SR-SWA, VRAM usage curves, or latency data at different page counts. Actual performance still needs to be verified against the official code and independent reproductions.
Sliding Window Attention (SWA) is a type of sparse attention mechanism: each position in the sequence attends only to a fixed number of tokens within its nearby window rather than to all historical tokens, thereby reducing attention computation complexity from quadratic growth with sequence length to linear growth. The "SR" in SR-SWA may refer to variants such as "State/Recurrent" or "Selective Routing," used to preserve global information across windows on top of the sliding window. Its engineering significance is that during decoding there is no need to recompute attention over the entire generated context; per-step cost depends only on the fixed window size, so processing the hundredth page costs roughly the same as processing the first. The trade-off is that long-range dependencies must be maintained through a state-passing mechanism outside the window, and if implemented poorly this could affect the accuracy of cross-page textual associations.
The combination of 3B parameters and the MIT license
Unlimited OCR 2 is 3B parameters in scale and MIT-licensed. This combination is worth noting: 3B sits in the common "deployable on a single GPU" range, while the MIT license permits commercial use, modification, and redistribution with few restrictions.
For developers, this means it can be embedded directly into enterprise internal document processing systems without worrying about license contagion or commercial licensing issues. Compared with some open-source OCR projects that use custom or restrictive licenses, MIT is a clearer signal.
The MIT license is one of the most permissive open-source licenses, requiring only that the copyright notice and license notice be retained. It allows users to freely use, copy, modify, merge, publish, distribute, sublicense, and even sell commercially, and it does not require derivative works to adopt the same license (i.e., it has no copyleft contagion). By contrast, the GPL family requires derivative works to be open-sourced as well, while some custom licenses may restrict commercial use, require authorization requests, or set user-scale thresholds. For a component like document OCR that needs to be embedded in enterprise intranet systems, MIT means enterprises can modify the model code without having to disclose their own business logic, significantly reducing legal risk. Note, however, that the license covers only the code and weights; the compliance of training data sources still needs separate assessment.
77.1 on MarathonDocBench
The report mentions that the model scores 77.1 on MarathonDocBench. Judging by its name, MarathonDocBench is an evaluation benchmark aimed at long documents, and this score is the only concrete performance metric in the source material.
A single benchmark score is not enough to settle the whole question. The real quality of long-document OCR also depends on layout complexity, the proportion of tables and formulas, scan quality, multilingual mixed content, and other factors. 77.1 can serve as a starting point for horizontal comparison, but when selecting a model you should still run small-scale validation on your own document types.
OCR evaluation benchmarks typically measure how close recognition results are to annotated text using edit distance or character/word-level accuracy (such as CER and WER), and some benchmarks also incorporate dimensions such as layout reconstruction and reading-order correctness. The difficulty with long-document benchmarks is the high annotation cost and the fact that cross-page associations (headers and footers, cross-page tables, continued paragraphs) are hard to score automatically, so scores are highly sensitive to the distribution of the test set. A single benchmark score of 77.1 cannot tell you how the model performs on receipts, handwriting, vertically typeset ancient books, or low-quality scans; in horizontal comparisons you should also confirm whether the compared models use the same input resolution, whether pagination is allowed, and whether the evaluation set is public and reproducible.
Impact on document intelligence workflows
If "parsing a hundred pages in a single request" holds up reliably in real scenarios, the impact goes beyond the OCR step itself. Many current document intelligence pipelines use a serial structure of "OCR → chunking → retrieval/extraction," and the chunking strategy is often constrained by OCR's page limit. When OCR no longer needs pagination, downstream layout understanding and structured extraction can operate in a more complete document context, and the way cross-page tables, cross-page clauses, and header/footer associations are handled will change accordingly.
From the open-source ecosystem perspective, an MIT-licensed long-document OCR model with a moderate parameter scale has the potential to become a foundational component in document processing toolchains. Whether Baidu's open-sourcing this time can build a community ecosystem depends on code quality, inference efficiency optimization, and the pace of ongoing maintenance—none of which is yet covered in the source material.
Summary
Unlimited OCR 2's positioning is clear: use SR-SWA to solve the problem of long-document decoding cost growing with page count, and use 3B parameters plus the MIT license to lower the barriers to deployment and commercial use. The MarathonDocBench score of 77.1 provides a comparable baseline. For teams building document intelligence systems, this is a new option worth including in their evaluation scope, but before deployment they still need to run real tests against their own document distributions.
One-line Summary
Baidu open-sources Unlimited OCR 2, a 3B-parameter, MIT-licensed model that uses SR-SWA to parse a hundred pages in a single pass.
Paragraph Summary
Baidu has open-sourced Unlimited OCR 2, a 3B-parameter OCR model under the MIT license whose core selling point is parsing hundreds of pages of documents in a single request. The article notes that traditional long-document OCR faces a dual bottleneck: VRAM usage and decoding cost both grow linearly with page count, which often reduces "long-document support" in engineering practice to paginated processing. The model uses an SR-SWA attention mechanism to keep per-step decoding cost nearly constant and scores 77.1 on MarathonDocBench. Its 3B parameter scale fits within single-GPU deployment, and the MIT license permits commercial use and modification, lowering the barrier to enterprise integration. The article also cautions that the source material provides only qualitative descriptions and a single benchmark score, with no implementation details, VRAM, or latency data, so independent testing is needed before deployment.
Related articles

Cursor AI in Practice: Weighing Efficiency Gains Against Costs in an AI IDE
An in-depth look at Cursor AI IDE's interface layout, four modes (Agent/Plan/Debug/Ask), model selection, and Git context integration, with hands-on demos weighing subscription costs against going direct to Claude.

Free Landing Page Design Rules Library: A Practical Guide for Claude Code and Cursor
A free landing page design skill for Claude Code and Cursor: MIT licensed, nearly 9,000 stars, asks about offer/audience/action before planning 12 sections with hard font and spacing constraints.

Cursor Keeps Writing Wrong Code? The Problem May Be Context, Not Prompts
Cursor keeps writing wrong code? The problem may be context, not prompts. Learn how to supply relevant files, full error messages, and expected results, plus a plan-first, small-step, test-driven workflow to reduce AI coding errors—while remembering code review remains the developer's job.