Baidu released Unlimited OCR 2 on October 27, 2026, opening its document-parsing model under the MIT license. The release targets a specific bottleneck: extracting structured content from hundreds or thousands of pages without making every new output token increasingly expensive to generate. Open weights and inference instructions are available through the model’s Hugging Face page.
Baidu says the model parsed all seven Harry Potter books, totaling more than 3,600 pages, in a single request. Its announcement also describes cross-page table merging, paragraph continuation, and structured output containing layout elements such as headings, tables, formulas, and images.
The useful technical detail is what Baidu calls unlimited-horizon parsing. Unlimited OCR 2 limits the visual references involved in each decoding step, so a growing document need not produce an equally growing attention workload. That is a narrower, more practical claim than the name might suggest: a thousand-page document still takes time to read and transcribe.
What “Unlimited-Horizon” Actually Means
Unlimited OCR 2 builds on the first version’s Reference Sliding Window Attention, or R-SWA. According to the Baidu team’s paper, that earlier approach maintained a constant key-value cache but continued computing attention over visual tokens from all pages. The cache stores intermediate attention information that a decoder can reuse as it generates more text.
That left a scaling problem. Even with a bounded cache, consulting an expanding collection of page-image tokens could make each decoding step more expensive.
The second version introduces Sparse Reference Sliding Window Attention, abbreviated SR-SWA. The paper describes two parts:
- Page Gate narrows each query’s visual references to relevant pages while accounting for relationships between pages.
- Token Sieve selects top-k remote token buckets to retain useful longer-range visual references without attending densely to everything.
The model card describes a fixed-size working reference set, giving 512 tokens as an example. That number describes active references, not a 512-token limit on the document or its output.
The mechanism suits transcription: while producing text from one part of a document, the decoder usually needs concentrated visual information from that area, plus selected references elsewhere. It should not need to repeatedly inspect every preceding page.
Bounded Steps Still Add Up
Baidu describes nearly constant per-step decoding latency and memory usage as documents grow. The important unit is one decoding step, not an entire document.
If a longer document requires ten times as many output tokens, stable per-token decoding costs would still mean roughly ten times the decoding work, assuming comparable content and unchanged conditions. Image conversion, page encoding, storage, and service overhead also remain part of the job.
My view is that this distinction makes the release more useful to assess. The architectural promise is to avoid an escalating cost per generated token. It is not a promise that a 3,600-page book collection will finish as quickly as a short report.
Sparse transcription also should not be confused with keeping every page equally available for arbitrary whole-document reasoning. The published mechanism prioritizes relevant visual references as parsing proceeds.
What Baidu’s Benchmarks Show
Baidu reports the following results in its announcement and technical paper:
| Reported result | Scope |
|---|---|
| 84.6 on MPDocBench | Multi-page document parsing |
| 77.1 on MarathonDocBench | Hundred-page-scale document parsing |
| 7.0× per-step speedup over full attention | Hundred-page-scale comparison |
| 5.6× per-step speedup over R-SWA | Hundred-page-scale comparison |
| More than 3,600 pages in one request | Baidu’s seven-book demonstration |
These are vendor-reported results. MarathonDocBench is also a benchmark introduced by the Baidu team. This article analyzes the published documentation; the scores, speedups, and book demonstration have not been independently reproduced in the supplied evidence.
The speed figures are particularly easy to overread. A 7.0× per-step speedup against full attention is not an end-to-end claim that every PDF will finish seven times faster. It measures a particular part of inference at the reported document scale.
For enterprise adoption, the more consequential claim may be cross-page structure. A table split between two pages can require substantial repair after ordinary page-by-page extraction. Baidu says Unlimited OCR 2 can recognize that continuation and output one merged table, along with paragraphs reconnected across page breaks.
I would prioritize those cases in an evaluation. Accepting thousands of pages is valuable, but preserving row alignment, reading order, and paragraph boundaries determines whether the output is usable downstream.
How to Try Unlimited OCR 2 With Transformers
The model card offers two inference paths: Transformers for quick tests and SGLang for serving.
Baidu documents its Transformers setup with Python 3.10 on an NVIDIA A800 with 80 GB of memory. That is the published test configuration, not a stated minimum GPU requirement.
The installation command is:
pip install torch==2.13.0 torchvision pillow transformers==4.52.1 huggingface-hub==0.36.0 \
tokenizers==0.21.4 addict==2.4.0 einops==0.8.2 easydict==1.13
This installs the documented framework versions and supporting libraries. The following example loads the tokenizer and model, selects bfloat16 weights, and moves the model to a CUDA GPU:
import torch
from transformers import AutoModel, AutoTokenizer
model_name = "baidu/Unlimited-OCR-2"
tokenizer = AutoTokenizer.from_pretrained(
model_name,
trust_remote_code=True,
)
model = AutoModel.from_pretrained(
model_name,
trust_remote_code=True,
use_safetensors=True,
torch_dtype=torch.bfloat16,
).eval().cuda()
The trust_remote_code=True setting permits execution of custom code supplied with the model. Review that code before enabling it, especially when processing confidential documents.
For multi-page inference, provide page images in reading order:
pages = [f"your_doc/page_{i}.jpg" for i in range(1, 8)]
text, num_tokens = model.infer_multi(
tokenizer,
image_files=pages,
output_path="output/multi",
save_results=True,
)
This example names seven JPEG files, submits them together, and requests saved results. It follows the documented interface; it is not a PDF-loading example. Prepare the page images first.
The model card says infer_multi constructs the parsing prompt automatically and encodes each page as one global view, called base mode. Sending the pages together gives the model cross-page context.
Single-page inference uses a different default:
text = model.infer(
tokenizer,
image_file="your_doc/page_1.jpg",
output_path="output/single",
save_results=True,
)
That path uses dynamic tiling, called gundam mode. Consequently, comparing a single-page result with the same page inside a multi-page request also compares different image-encoding modes. I would keep that distinction visible when investigating small text or dense layouts.
SGLang Reveals How Long-Document Serving Works
The serving documentation makes an important distinction: one document request can be processed through multiple page windows internally.
Baidu recommends SGLang for serving and specifies a customized wheel:
sglang-0.5.20.dev13+g75b9b06b02-py3-none-any.whl
Its setup instructions use a Python 3.10 environment and install PyMuPDF for PDF-to-image conversion:
uv venv --python 3.10
source .venv/bin/activate
uv pip install wheel/sglang-0.5.20.dev13+g75b9b06b02-py3-none-any.whl
uv pip install pymupdf==1.27.2.2
uv pip install fastokens==0.3.2
Frequently Asked Questions
3 questions
1Does “Unlimited” Mean Constant Processing Time?
No. Baidu’s claim concerns nearly constant cost per decoding step. Longer documents still require more page processing and output generation.
