Baidu Unlimited-OCR-2: A 3B MIT-Licensed Model That Parses Hundred-Page Documents in One Request Baidu released Unlimited-OCR-2, a roughly 3B-parameter OCR model under the MIT license that parses documents of any length in a single request, according to the model card on Hugging Face. The version adds Sparse Reference Sliding Window Attention (SR-SWA), which limits text-to-visual attention to a small fixed-size set of working references — 512 tokens in the example given — so per-step decoding cost stays bounded as documents grow. Baidu claims state-of-the-art results on MPDocBench and MarathonDocBench, but the scores appear only in a leaderboard image rather than in text, leaving the claim unverified until tested on a user's own pages; the README lists a 2026/10/27 release date and recommends a customized SGLang wheel for serving. Baidu has released Unlimited-OCR-2, a roughly 3B-parameter, MIT-licensed OCR model designed to read very long documents in one pass. The model card on Hugging Face https://huggingface.co/baidu/Unlimited-OCR-2?ref=explainx says the new version adds Sparse Reference Sliding Window Attention SR-SWA , a change meant to keep decoding time and memory close to flat as a document grows. That follows the June release we covered in Baidu's Unlimited-OCR: one-shot long-horizon document parsing https://explainx.ai/blog/baidu-unlimited-ocr-one-shot-long-horizon-parsing-2026 . If you build retrieval pipelines, contract review tools or any workflow that turns scanned PDFs into text, this is worth a test run, with one caveat up front: Baidu claims state-of-the-art results, but the scores appear only in an image, not in text. Treat the claim as unverified until you try it on your own pages. TL;DR: Unlimited-OCR-2 at a glance | Question | Answer | |---|---| | Who made it? | Baidu | | Size | About 3B parameters, Safetensors BF16 | | License | MIT | | What is new in v2? | SR-SWA: sparse reference sliding window attention | | Goal | Parse documents of any length in one request within a fixed context window | | Benchmarks claimed | State of the art on MPDocBench dozens of pages and MarathonDocBench hundred-page documents | | Are numbers published in text? | No, only a leaderboard image | | How to run | Transformers with remote code, or a customized SGLang wheel recommended for serving ; vLLM and Docker Model Runner are also listed | | Release date in the README | 2026/10/27 | | Links | Hugging Face https://huggingface.co/baidu/Unlimited-OCR-2?ref=explainx , GitHub https://github.com/baidu/Unlimited-OCR?ref=explainx , paper arXiv 2606.23050 https://arxiv.org/abs/2606.23050?ref=explainx | Why long-document OCR is hard for language-model decoders Classic OCR pipelines split a page into regions, recognize characters, then reassemble layout. A newer family of end-to-end models, such as DeepSeek-OCR, instead encodes the page image and lets a language model decode the text, tables and formulas directly. The language model's priors help with ambiguous characters and with structure. The cost shows up on long inputs. A decoder keeps a key-value cache of everything it has produced, and that cache grows with output length. Longer documents mean more memory and slower generation per token. The Unlimited-OCR paper, arXiv 2606.23050 https://arxiv.org/abs/2606.23050?ref=explainx , puts the problem this way: humans do not slow down while copying a long text, but these decoders do. If you want the memory background, our piece on DeepSeek's KV cache reduction https://explainx.ai/blog/deepseek-v4-1-flash-kv-cache-hbm-reduction-september-2026 explains why the cache dominates serving cost. The first Unlimited-OCR replaced the decoder's attention with Reference Sliding Window Attention R-SWA , which, per the paper, keeps the cache size constant while decoding. Combined with a high-compression image encoder, it could transcribe dozens of pages in one forward pass within a 32K maximum length. The authors released code and weights. What SR-SWA changes in version 2 The README describes SR-SWA as limiting text-to-visual attention to "a small, fixed-size set of working references," with 512 tokens given as an example. Because that set does not grow with document length, the per-step cost stays bounded. The card's headline is "From Long- to Unlimited-Horizon Parsing": parse a document of any length within a finite context window. In plain terms: when the model writes the text for page 40, it does not need to attend to everything it saw on pages 1 through 39. It looks at a bounded set of references on the page images that matter for the current spot, plus recent text. That is a bet that OCR is mostly local, which is a sensible bet for transcription, though it may matter for cases such as a footnote on page 80 that refers back to a table on page 3. The model card does not give a detailed v1 versus v2 comparison, so we cannot say how much SR-SWA improves speed or accuracy over the earlier R-SWA release. The paper we could read covers the first version, not this one. A document sheet unfolding into tidy green rows, illustrating Unlimited-OCR-2 long document parsing How to run Unlimited-OCR-2 The model card documents two main routes. Transformers quick tests The card says it was tested with torch 2.13.0 and transformers 4.52.1 on an NVIDIA A800 80GB, with Python 3.10: python from transformers import AutoModel, AutoTokenizer import torch name = "baidu/Unlimited-OCR-2" tok = AutoTokenizer.from pretrained name, trust remote code=True model = AutoModel.from pretrained name, trust remote code=True, use safetensors=True, torch dtype=torch.bfloat16 .eval .cuda Multi-page: the whole document in one request text, n = model.infer multi tok, image files= "p1.jpg", "p2.jpg" , output path="out", save results=True Single page gundam tiling by default text = model.infer tok, image file="p1.jpg", output path="out", save results=True Note trust remote code=True : the repository runs custom code on load, so read it first or run it in an isolated environment. That habit matters more now that models and agents increasingly run with real access to machines, as the Cohere report on Qwen3.8-Flash-Next https://explainx.ai/blog/cohere-qwen3-8-flash-next-beijing-bucket-upload-attempt-open-weight-agent-sandbox-2026 shows. SGLang recommended for serving For serving, the card recommends a customized SGLang wheel plus PyMuPDF for converting PDFs to images, then sglang.launch server with the unlimited-ocr chat template. It also lists memory-tuning flags and a page-window setting for very long documents. Requests go to the OpenAI-compatible /v1/chat/completions endpoint, with images sent as base64 data URLs and a prompt that repeats the page placeholder for each page followed by "Multi page parsing." The card lists vLLM and Docker Model Runner as local-app options too. Because the SGLang wheel is customized, plan to pin its version rather than mixing it with your existing deployment. If you already run SGLang, see our note on its plugin system and vendor kernels https://explainx.ai/blog/sglang-plugin-system-sgl-nvidia-mega-sgl-amd-mono-vendor-kernels-2026 for how quickly that project changes. How it compares with other open OCR models We cannot give you a head-to-head table, because Baidu publishes no text scores and we have not run the model. What we can do is place it among recent open document models we have covered: | Model | Angle | Our coverage | |---|---|---| | Unlimited-OCR-2 Baidu | About 3B, MIT, whole-document single request via SR-SWA | This post | | Unlimited-OCR v1 Baidu | R-SWA, dozens of pages in 32K | June post https://explainx.ai/blog/baidu-unlimited-ocr-one-shot-long-horizon-parsing-2026 | | LightOnOCR-3 | Open-weight OCR, ParseBench results | LightOnOCR-3 https://explainx.ai/blog/lightonocr-3-parsebench-open-weight-ocr-2026 | | LlamaIndex OCRIA | 1.4B document parser with ParseBench claims | OCRIA claims https://explainx.ai/blog/llamaindex-ocria-1-4b-document-parsing-model-parsebench-87-4-llamaparse-claims-2026 | | Indra OCR | 1M-parameter CPU model | Indra OCR https://explainx.ai/blog/indra-ocr-datalab-1m-parameter-cpu-49-pages-per-second-how-to-try-2026 | | MinerU 3.4 | Parsing toolkit for RAG and agents | MinerU 3.4 https://explainx.ai/blog/mineru-3-4-document-parsing-rag-agents-2026 | Different benchmarks ParseBench, MPDocBench, MarathonDocBench make cross-model comparisons unreliable. The honest summary: if your documents are hundreds of pages and you want one-request parsing with bounded memory, Unlimited-OCR-2 is aimed squarely at you. If you parse single invoices, a smaller model may be cheaper. Claimed vs verified | Claim | Source | Status | |---|---|---| | About 3B parameters, MIT license | Model card, README | Stated on both; not independently checked | | SR-SWA keeps per-step cost near flat | Model card, README | Design claim; no measurements published in text | | State of the art on MPDocBench and MarathonDocBench | Model card, README | Shown only in a leaderboard image; no numbers in text | | Dozens of pages in a 32K context v1 | Paper | Stated by the authors for the first release | | Release date October 27, 2026 | README release log | The log lists it later than other entries; treat the exact date with care | How to test it in an afternoon 1. Pick three document types you actually have: a clean digital PDF, a scan with tables, and something awkward such as multi-column pages or formulas. 2. Run each through the Transformers example, then through the SGLang route with a 50 to 100 page file. 3. Watch peak GPU memory and tokens per second as the page count grows. Flat curves are the whole point of SR-SWA. 4. Compare the output with your current OCR on a sample you can check by hand: table cell alignment, footnote placement, and any place where the model might skip or repeat text. Repetition is a known failure mode for decoder-style OCR. 5. Look for cross-page references. Because attention is bounded, check whether tables that span pages are stitched correctly. Who should try it first, and what could go wrong The best-fit users are teams whose inputs are long and uniform: legal bundles, financial filings, technical manuals, scanned books and archives. For them, the cost of stitching per-page output back together is real, and a model that holds one document in one request removes that stitching step. There are four failure modes worth planning for, none of which the model card measures in text. - Drift over long outputs. Even with a flat cache, a model that writes tens of thousands of tokens in one go can lose its place. Spot-check the last pages of a long document, not just the first. - Repetition loops. Decoder-style OCR models can fall into repeating a row or phrase, especially in dense tables. The earlier release inherited repetition-suppression settings from the DeepSeek-OCR lineage, and you should look for similar controls in the inference arguments. - Layout fidelity. Output format matters as much as character accuracy. If you need Markdown tables or structured fields, test that the model reproduces them consistently across pages. - Hardware assumptions. The tested GPU is an NVIDIA A800 with 80 GB. Smaller cards may need the memory-tuning flags the card lists, and we have not seen published numbers for consumer GPUs. If any of those matter to you, keep your existing OCR in the loop as a fallback for the first few weeks and compare outputs automatically on a sample of pages. What this means if you build with documents - Cost: a fixed memory footprint makes capacity planning simpler. You can size GPUs for the window, not for the longest document. - Pipeline design: one-request parsing removes page-batching glue code and the seams where tables break across batches. - License: MIT is permissive, which matters for commercial retrieval products. - Risk: custom wheels, remote code and a single-vendor benchmark. Pin versions, sandbox the first run, and build your own evaluation set. Bottom line Unlimited-OCR-2 is a credible, openly licensed attempt to make long-document OCR cheap and predictable, from a lab that shipped the first version only four months ago. Whether SR-SWA delivers on accuracy as well as memory is the open question, and Baidu has given the community the weights, code and a paper to find out. We will add an update here if independent benchmarks appear. Related reading: Specifications reflect the Hugging Face model card and GitHub README as read on October 27, 2026, and may change.