Baidu releases Unlimited OCR 2: parsing hundreds of pages per request, and what to verify first in SR-SWA and its custom inference stack
According to a MarkTechPost report dated October 26, 2026, Baidu released Unlimited OCR 2, a 3.34B-parameter model whose weights are published under the MIT license. It uses SR-SWA to compress attention onto a fixed reference set, supporting parsing of hundreds of pages in a single request, and reports 77.1 on MarathonDocBench.
What changed
According to a MarkTechPost report dated October 26, 2026, Baidu released Unlimited OCR 2, an OCR vision-language model for very long documents. Its weights are published on Hugging Face under the MIT license, with code hosted on GitHub, succeeding Unlimited-OCR from June 2026. The report says it has 3.34B parameters (activated parameter count not disclosed) and a maximum position length of 131,072 tokens; BF16 weights are about 6.7 GB, and Baidu tested it on a single NVIDIA A800-80GB. The architecture follows the DeepSeek-OCR style: a SAM ViT-B plus CLIP-L encoder feeding a 12-layer mixture-of-experts decoder that routes each token to 6 of 64 experts, plus 2 shared experts. The core change is SR-SWA (sparse reference sliding-window attention), which compresses text-vision attention onto a fixed working reference set; the report cites a model-card example scale of 512 tokens, with a configuration combining a 128-token local window and top-16 selection over 32-token blocks. The report says this makes per-step decoding latency and memory use nearly constant as documents grow, though image encoding and total runtime still rise with page count; in multi-page mode each page consumes 273 image tokens. On benchmarks, the report says Baidu tested on the public MPDocBench-Parse (433 documents, 3,246 pages) and on MarathonDocBench (hundreds of pages), and says it could not find a public release version of MarathonDocBench; according to Baidu's leaderboard chart, Unlimited OCR 2 scores 84.6 on MPDocBench and 77.1 on MarathonDocBench, where the comparison models top out at 33.7 and the previous Unlimited-OCR scores 0.0 on MarathonDocBench. All numbers are Baidu's own, and the report says they are presented only as a single chart image. The weakest sub-item is heading hierarchy (TEDS) at 48.2 on MarathonDocBench; the table item drops from 87.8 on MPDocBench to 74.8. On running it, the model card lists Transformers for quick testing (infer handles a single page, infer_multi parses all pages in one request), while the server side uses SGLang from Baidu's custom wheel rather than the upstream SGLang the report refers to; loading requires trust_remote_code=True, which executes Python code from the repository. The report also mentions that Baidu's example schedules 10 pages per window and reuses the previous window's KV tail, that smaller windows lower peak memory but weaken cross-page merging, and that the default bias setting may trigger a 462 MiB allocation and out-of-memory warnings. The report does not state what license the GitHub repository code uses.
What it means for developers
The implications for developers fall into several layers, most still needing independent verification. First, how you estimate memory and page limits changes: per the report, SR-SWA keeps per-step decoding cost from growing linearly with page count, so under a fixed memory budget the main constraint on pages per request is more likely to shift to image-encoding cost, KV tail occupancy and window scheduling rather than quadratic attention growth; this matters for high-page, low-interactivity offline batch jobs such as books, filing documents and annual reports. But the report also states total runtime still rises with page count, so gains are limited for online scenarios needing fast per-page returns. Second, there is inference-stack lock-in risk: the serving path is SGLang from Baidu's custom wheel, a difference the report describes as not the upstream SGLang, indicating a vendor branch needing separate maintenance; if a team's images, version pinning and rollback processes are built around a general inference framework, adoption means an extra dependency line to track. The model card also lists a Transformers path, usable as an entry point for functional validation, but it is not a production serving option. Third, distinguish licensing from security: weights under the MIT license are a permissive grant at the license level, not to be confused with merely open weights; however, the report only covers the weight license and does not state the GitHub repository code license, so code reuse should not be assumed MIT. Also, MIT covers the grant scope, not a security endorsement of code loaded via trust_remote_code=True, which executes repository Python code in-process; environments with audit requirements usually need code review and isolated execution first. Fourth, evaluation framing: the report shows small per-item gaps on MPDocBench, e.g. 94.8 vs 94.3 for text and 89.4 vs 89.2 for formulas, with gaps concentrated on the hundreds-of-pages MarathonDocBench; selection should be based on your own documents' page distribution, not overall score ranking. The weak heading hierarchy (48.2) and long-document tables (74.8) directly affect downstream quality of chapter trees and table ingestion, and need separate measurement on your own samples.
Integration and evaluation
The following are conditional suggestions, not reported facts. Decision one: whether to trade for long-document throughput with SR-SWA. The trigger is tasks often reaching hundreds of pages; if documents are usually under ten pages, the MPDocBench per-item gaps in the report are small and there is little reason to switch. A practical approach is to split your corpus into two tiers (under twenty pages and over one hundred pages), run infer_multi on the same-memory machine, and record peak memory, total time and per-page time curves for a single request; if per-page time in the hundred-page tier clearly rises with page count, the bottleneck has shifted to image encoding, and you should adjust window page count rather than keep increasing pages per request. Decision two: Transformers first or custom SGLang. The premise is whether your existing inference stack is compatible with the vendor wheel; if images and rollback processes cannot accept custom SGLang, use Transformers first for functional and accuracy validation, with a threshold of whether pages parsed per unit time on a single card can fill the batch window; if custom wheels are acceptable, stress-test the risks the report mentions: start from the example's 10 pages and gradually shrink the window while watching peak memory, and check whether the default bias's 462 MiB allocation causes out-of-memory, making "no out-of-memory failures" a hard pass condition. Decision three: set acceptance criteria for structured output separately. The report shows heading hierarchy at only 48.2 on long documents and tables dropping to 74.8; if downstream depends on chapter trees or table ingestion, prepare your own samples with heading-hierarchy and table annotations, measure these two items by page tier, then decide whether to add human review or post-processing rules. Decision four: make trust_remote_code=True a pre-launch check, running and reviewing repository code first in an isolated environment, and confirm the repository code license terms with Baidu before deciding on production. All these judgments should rest on error rates from your own labeled set, not vendor overall scores.
Limits and open questions
Almost all performance numbers in the report come from Baidu's own claims, and the report says they are presented only as a single leaderboard chart image, with no independently reproducible evaluation details; MarathonDocBench is described as a hundreds-of-pages benchmark, but the report explicitly says no public release version was found, so 77.1 and the comparisons with other models cannot be externally verified. The activated parameter count is not disclosed, so actual inference compute or throughput cannot be inferred. The report only covers single-card operation in BF16 with weights of about 6.7 GB and does not mention quantized versions, so whether it can be deployed on devices with less memory cannot be judged from the available information. As of this catalog check, the Unlimited OCR 2 version does not appear in KimiSeek's model catalog; the Transformers and custom SGLang mentioned in the report refer to self-deployment paths via the model repository and vendor materials, not to the model being available on KimiSeek, and the report mentions no vendor-hosted service or billing method. If a hosted service appears later, its availability and price should be based on its official documentation and pricing page, and prices may change. The report's notes on trust_remote_code=True, default bias possibly triggering out-of-memory, and custom SGLang all come from vendor materials and have not been verified by third parties; the GitHub repository code license is also not stated. The comparison model names and benchmark versions cited in the report are relatively new; this article only relays the self-reported data and does not represent independent testing.