Baidu Unlimited-OCR: The 3B Model That Reads 40 Pages in One Pass — What It Really Is (and What the Viral Post Gets Wrong)

Baidu's Unlimited-OCR is a real, free, MIT-licensed document model with about 3.3 billion parameters that reads roughly 40 pages of a document in a single pass and returns structured Markdown — tables, formulas and headings included. It does this with a trick called Reference Sliding Window Attention, which keeps the model's memory footprint flat no matter how long the output gets. The viral post about it is mostly right about the headline. It is wrong about the page counts some reposts claim, and it skips the two things that matter before you install it: it needs a GPU, and it is not the most accurate OCR model you can run.

What Unlimited-OCR is

Unlimited-OCR is an open-weight vision-language model from Baidu's ERNIE team, released on 22 June 2026 on GitHub and Hugging Face (baidu/Unlimited-OCR), under the MIT licence — free for commercial use, no API key, no account. The model card's own pitch line is "Welcome the Era of One-shot Long-horizon Parsing", and that phrase is the whole idea: instead of feeding a document to an OCR model one page at a time, you feed it dozens of pages at once and get back one structured document.

The numbers, checked fresh on 10 November 2026: 3,336,106,240 total parameters (Baidu calls it 3B-class), a single ~6.77 GB BF16 weight file, a 32,768-token context window, and a mixture-of-experts decoder with 64 routed experts, 6 active per token, plus 2 shared experts. The GitHub repository (github.com/baidu/Unlimited-OCR) has 31,057 stars and 3,325 forks, was created on 18 June 2026, and was last pushed on 9 November 2026 — it is actively maintained, not a one-off drop. On Hugging Face the model has 5,555,204 total downloads and 4,996 likes. The paper behind it, "Unlimited OCR Works", is on arXiv as 2606.23050.

What you actually do with it: give it a PDF (converted to page images) or a stack of page images, prompt it with <image>Multi page parsing., and it returns the whole document as Markdown — text, tables, formulas, headings — in one forward pass. A single page uses the prompt <image>document parsing. instead. The model was built by continuing training from a DeepSeek-OCR checkpoint and swapping the decoder's attention mechanism for the new R-SWA design, which is where the "unlimited" part comes from.

What the viral post gets right — and where it stops

The viral post is right that this model exists, that it is free and open-weight, and that the multi-page trick is real. Here is where the reposts go past the evidence:

Correction 2 — "The KV cache doesn't grow" checks out. This is the model's central design claim and it is real by construction: Reference Sliding Window Attention keeps the key-value cache at a constant size while the model generates output, instead of letting it grow with every token. The section below explains how, in plain language.

Correction 3 — "3-billion-parameter" is fair. The config counts 3.34 billion parameters in total; Baidu labels it 3B-class. The viral post's number is honest.

Correction 4 — "Completely free, open-weight, MIT" is true. MIT licence, open weights, no API key, commercial use allowed. This one needs no correction.

Correction 5 — The accuracy numbers floating around online are not in the model card. Claims like "93% accuracy" or "error rate under 0.11% on 40+ pages" appear in social posts and secondary write-ups, but they are not in the model card, the README or the paper abstract. Do not treat them as facts. The only benchmark on the model card is ParseBench: a mean score of 46.17, with text content at 86.81.

Correction 6 — It is not the accuracy leader. The accuracy crown on OmniDocBench V1.5 belongs to GLM-OCR at 94.62. Unlimited-OCR's edge is different: it is the only model in its class that treats the whole document, not the page, as the unit of work. If your job is one perfect page, another model may serve you better; if your job is a 40-page contract, this one is built for it.

Correction 7 — It needs a GPU, and there is no official Ollama build. The official vLLM recipe needs at least 8 GB of VRAM for BF16 inference, independent sizing guides put the practical minimum around 12 GB and recommend about 24 GB for production, and 6–8 GB is only reachable with 4/8-bit GGUF quantisation. There is no official Ollama build — community GGUF builds exist, but Ollama users should not expect a one-command install. This is not a "runs anywhere" tool.

How R-SWA works, simply

Every language model remembers what it has already written by storing keys and values — the KV cache — for each token it has processed. In a normal model, that cache grows with every token generated: a 30,000-token document means 30,000 tokens' worth of memory, and the longer the output, the more memory it eats. That is why long documents usually have to be chopped into pages and processed one at a time.

Reference Sliding Window Attention changes the deal. Instead of keeping everything, the model keeps a fixed-size window of recent tokens, plus a compact reference summary of what came before. The window slides forward as generation continues, but its size never grows — so memory stays flat no matter how long the output gets. That is the whole trick, and it is why Baidu can call the model "Unlimited": the output length is no longer bounded by the memory of the machine it runs on, only by the 32,768-token context window.

The trade-off is honest and worth stating. A sliding window means the model does not hold every earlier token in full detail — it holds the recent window in full and the rest as a compressed reference. For document parsing that is a good deal: a table on page 3 does not need to be re-read in full while the model writes page 30. But it is a design choice with consequences, and it is one reason the model is not the accuracy leader on single-page benchmarks: it is optimised for the long horizon, not the single perfect page.

The numbers, honestly

Unlimited-OCR's adoption is genuinely fast. It passed 1 million Hugging Face downloads in its first two weeks and hit the top-3 trending models; the GitHub repository passed 10,000 stars within five days of release. As of 10 November 2026 it has 5,555,204 total Hugging Face downloads, 4,996 likes, and 31,057 GitHub stars with 3,325 forks. Those are real, checkable numbers — and they are the reason the model is worth writing about at all.

The performance numbers need the same honesty. The only benchmark on the model card is ParseBench, where Unlimited-OCR scores a mean of 46.17 and 86.81 on text content. ParseBench is a document-parsing benchmark, not a general OCR leaderboard, and a mean of 46.17 is a long way from a perfect score — it tells you the model is good at extracting text and structure, and weaker on the harder parts of parsing (layout, formulas, tables). The viral post's "understands complex documents" is fair as a description; the circulating "93% accuracy" figures are not verified anywhere in the official material and should be ignored.

On hardware, the honest sizing is: 8 GB of VRAM minimum for the official BF16 vLLM route, about 12 GB minimum and about 24 GB recommended for production use, or 6–8 GB with 4/8-bit GGUF quantisation. A modern gaming GPU clears the minimum; a laptop without a discrete GPU does not run it at all. That is the real barrier to entry, and it is the reason this model lives on servers and workstations rather than on every laptop.

Unlimited-OCR vs DeepSeek-OCR vs PaddleOCR-VL vs GLM-OCR

Four models, four different jobs. The table keeps only what is verified — a dash means the figure is not in the official material, not that it does not exist.

The pattern is the point. Unlimited-OCR is the only model in this comparison that treats the document as the unit of work. Everything else in the table is a page tool. That is why the comparison that matters is not "which model scores highest on one page" but "which model fits the document you actually have". A 200-page filing and a single scanned invoice are different jobs, and they want different models.

Setup: vLLM and Transformers

Two official routes exist — vLLM for serving, Transformers for a quick script. Both need a CUDA GPU. The vLLM route uses Baidu's official Docker image and needs vLLM 0.25.0 or newer:

docker pull vllm/vllm-openai:unlimited-ocr

For Hopper GPUs (CUDA 12.9) use the matching image instead:

docker pull vllm/vllm-openai:unlimited-ocr-cu129

The full deployment recipe — server flags, the custom logit processor and the n-gram settings — lives in the official vLLM recipe at recipes.vllm.ai/baidu/Unlimited-OCR. Follow it rather than guessing flags: the n-gram logit processor is part of the official path, not an optional extra.

The Transformers route is the fastest way to try one document. Install the tested stack (Python 3.12.3, CUDA 12.9) and load the model:

pip install torch==2.10.0 transformers==4.57.1 Pillow==12.1.1 pymupdf==1.27.2.2 einops==0.8.2

from transformers import AutoModel, AutoTokenizer

model_name = 'baidu/Unlimited-OCR'
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,
)
model = model.eval().cuda()

One page, then the whole document. Single-page parsing uses the gundam config; multi-page parsing uses base and the infer_multi call:

model.infer(
    tokenizer,
    prompt='<image>document parsing.',
    image_file='your_image.jpg',
    output_path='your/output/dir',
    base_size=1024, image_size=640, crop_mode=True,
    max_length=32768,
    no_repeat_ngram_size=35, ngram_window=128,
    save_results=True,
)

model.infer_multi(
    tokenizer,
    prompt='<image>Multi page parsing.',
    image_files=['page1.png', 'page2.png', 'page3.png'],
    output_path='your/output/dir',
    image_size=1024,
    max_length=32768,
    no_repeat_ngram_size=35, ngram_window=1024,
    save_results=True,
)

SGLang is the third official route, with its own server command and an OpenAI-compatible API on port 10000; the model card documents it in full. Whichever route you take, do not skip the n-gram setting: the official paths configure no-repeat n-gram filtering with size 35, and without it long documents degenerate into repetition — the model starts repeating itself instead of moving on to the next page.

Use cases: where the document is the unit of work

Unlimited-OCR earns its keep wherever the job is a document, not a page. Contracts and legal files: a 30-page agreement parsed in one pass keeps cross-references, defined terms and clause numbering in one output, instead of thirty separate files you have to stitch together. Financial filings and annual reports: tables that span pages and footnotes that refer back to earlier sections stay in context. Long research reports and theses: headings, formulas and tables come out as structured Markdown you can feed straight into a retrieval system or a language model. Archives and digitisation: a box of scanned reports becomes searchable text in bulk, one document per call.

The common thread is that the value is in the whole, not the parts. If you only ever need one page — a receipt, an ID card, a single invoice — a page-by-page model is simpler, often more accurate, and cheaper to run. Unlimited-OCR is for the jobs where splitting the document into pages is itself the problem: where a table continues across a page break, where a footnote on page 2 explains a figure on page 28, and where the output has to read as one document, not forty fragments.

Limitations — the honest list

• Accuracy is not the crown. ParseBench mean 46.17; GLM-OCR leads on OmniDocBench V1.5 at 94.62. If single-page accuracy is the whole job, another model wins.
• It needs a GPU. At least 8 GB of VRAM for the official BF16 vLLM route, about 12 GB minimum and about 24 GB recommended for production, or 6–8 GB with 4/8-bit GGUF. No discrete GPU, no run.
• No official Ollama build. Community GGUF builds exist, but there is no one-command Ollama install from Baidu.
• The n-gram processor is not optional. Skip the no-repeat n-gram filtering (size 35) and long documents degenerate into repetition.
• Heading hierarchy is a known weak spot. The v2 authors themselves flag document heading structure as an area the original model handles weakly — v2 improves it.
• Forty pages is the v1 ceiling. Longer documents need chunking or the v2 model. Do not expect one pass to eat a 200-page filing on v1.
• It is young. Released June 2026, at version 1.0 in effect, with 94 open issues on GitHub as of November 2026. Expect rough edges and breaking changes between releases.

Security and privacy

The privacy story is the strongest argument after the price. Unlimited-OCR is self-hosted: the weights run on your GPU, and your documents never leave your machine. No API key, no account, no cloud upload, no per-page billing. For contracts, medical records, financial filings and anything under a non-disclosure agreement, that is a real difference from cloud OCR services — the document stays where you put it.

Two honest caveats. First, "open weight" means the weights are auditable, not that they have been audited: no independent security review of the model code has been published, and the Transformers path runs with trust_remote_code=True, which executes code from the model repository — read it before you run it, as you should with any remote code. Second, the MIT licence covers the model; it does not cover what you do with it. Parsing documents you do not have the right to process is your responsibility, not the model's.

Unlimited-OCR-2: what changed

There is already a successor, and it matters for anyone choosing between the two. Unlimited-OCR-2 was released on 27 October 2026 (Hugging Face: baidu/Unlimited-OCR-2, repository created 26 October 2026). Same 3B size, same MIT licence, same team — but the attention mechanism is now Sparse R-SWA (SR-SWA), and the page ceiling jumps from about 40 to 100–300 pages in a single request. As of 10 November 2026 it has 467,937 downloads and 670 likes, and its paper is arXiv 2610.39308.

The original model's repository now documents v2 on its main branch; the v1 instructions live on the UnlimitedOCR1.0 branch. That is worth knowing before you follow a tutorial: if the README you are reading talks about 300 pages, you are reading the v2 docs, not the v1 ones. For new projects, v2 is the obvious starting point unless you have a specific reason to pin v1 — but v1 is the model the viral post is about, and its 40-page limit is the number that belongs in the headline.

Frequently asked questions

Is Baidu Unlimited-OCR really free?

Yes. It is open-weight under the MIT licence: free for commercial use, no API key, no account, no per-page billing. You pay only for the GPU you run it on.

How many pages can it parse in one pass?

About 40 pages for v1. The 100–300 page figure belongs to Unlimited-OCR-2, released in October 2026. Do not mix the two up.

Does the KV cache really stay constant?

Yes, by design. Reference Sliding Window Attention keeps a fixed-size window plus a compressed reference, so memory does not grow with every generated token. Output length is bounded by the 32,768-token context window, not by memory.

Can I run it on my laptop?

Only with a discrete GPU: at least 8 GB of VRAM for the official BF16 route, or 6–8 GB with 4/8-bit GGUF quantisation. A laptop without a discrete GPU cannot run it, and there is no official Ollama build.

Is it more accurate than other OCR models?

No — and Baidu does not claim otherwise. GLM-OCR holds the accuracy crown on OmniDocBench V1.5 at 94.62, and Unlimited-OCR's own model-card benchmark is ParseBench at a mean of 46.17. Its edge is multi-page single-pass parsing, not top accuracy.

Should I use v1 or v2?

Use v2 for new projects: same 3B size and MIT licence, but 100–300 pages per pass instead of about 40, with better heading handling. Use v1 only if you have a reason to pin the original release — and remember the v1 instructions now live on the UnlimitedOCR1.0 branch.

Sources

• Hugging Face — baidu/Unlimited-OCR (model card, README, inference code)
• GitHub — baidu/Unlimited-OCR (repository, releases)
• arXiv — "Unlimited OCR Works" (2606.23050)
• Spheron — Deploy Baidu Unlimited-OCR on GPU Cloud
• Local AI Master — Unlimited-OCR model profile
• Mer.vin — Baidu Unlimited-OCR-2 parses 300-page documents in one pass