Baidu Unlimited-OCR 3B: Single-Pass PDFs, MIT-Licensed

Baidu Unlimited-OCR is a 3B-parameter, MIT-licensed document-parsing model released on June 22, 2026, and it changes one specific thing about OCR pipelines: instead of chopping a PDF into pages, running each one separately, and stitching the output back together, it transcribes dozens of pages in a single forward pass — with a KV cache that stays flat no matter how long the output runs.

The release matters to operations teams, not just ML researchers. Every business that processes invoices, delivery documents, contracts, or scanned forms currently pays one of two taxes: a per-page cloud API bill, or the accuracy losses that come from page-by-page chopping in self-hosted stacks. A free, permissively licensed model that scores 93.23% on an independent benchmark — beating the DeepSeek-OCR baseline it was built from by 6.22 points — puts real pressure on both.

It also arrives wrapped in some hype worth correcting. Social recaps have circulated a claim that the model parses 100-page PDFs in one shot; the paper itself says dozens of pages, and independent technical coverage puts the practical ceiling near 40. This guide covers what actually shipped, the architecture in plain English, the honest benchmark picture, hardware requirements by precision tier, and the cost-versus-control math against cloud OCR APIs.

On June 22, 2026, Baidu published Unlimited-OCR as open weights on Hugging Face and GitHub under an MIT license — free commercial use, modification, and redistribution, no strings. The arXiv paper (“Unlimited OCR Works,” from a 17-author Baidu team) followed a day later, alongside a ModelScope listing. This is not breaking news; a month on, it is an adoption story. The official release log shows a Hugging Face Spaces demo on June 24, vLLM inference support on June 28, Baidu Cloud integration on July 3, and ms-swift training-framework support on July 21 — two days before this post’s publish date. In that window the repo has drawn tens of thousands of GitHub stars and the model card shows downloads in the millions, which is unusual traction for a task-specific 3B model.

Notably, Unlimited-OCR is not a from-scratch architecture. Baidu describes it as pushing DeepSeek-OCR “one step further,” and the repo’s acknowledgements credit DeepSeek-OCR, DeepSeek-OCR-2, and PaddleOCR directly. According to independent technical coverage, the model was continue-trained from a DeepSeek-OCR checkpoint for 4,000 steps — the visual encoder frozen, only the decoder trained — on roughly two million document samples. The innovation is a surgical attention-layer swap on a proven lineage, not a new model family.

Today’s standard OCR pipeline — cloud or self-hosted — chops a multi-page PDF into individual page images, runs the model on each page separately, then stitches the text back together. That workaround exists because of a memory problem: in a normal transformer decoder, every generated token is stored in a Key-Value cache that grows with output length. Transcribe a long document and the cache balloons, memory runs out, and generation slows to a crawl. Chopping avoids the blow-up but breaks anything that spans a page boundary — tables split mid-row, clause numbering, running totals on invoices.

Baidu’s fix is called Reference Sliding Window Attention (R-SWA), and the intuition is human. The paper observes that “Humans exhibit no such decline in efficiency during long-horizon copying tasks” — a person transcribing a document keeps the source page in view but only holds the last sentence or two of their own writing in mind. R-SWA does the same thing. Every generated token attends to two things: the reference — all visual tokens and the prompt, kept permanently accessible — and a sliding window of only the preceding ~128 output tokens. Everything older is evicted. The result is a KV cache whose size is bounded rather than growing linearly with output length, which is precisely what lets the model transcribe dozens of pages in one pass instead of one page at a time.

Two details make this practical at speed. First, the DeepEncoder — a SAM-ViT cascaded with a CLIP-ViT — applies 16× token compression, so a full 1024×1024 page becomes 256 visual tokens. Second, the authors position R-SWA as a general-purpose mechanism, not an OCR trick: the paper suggests the same fixed-reference, sliding-output pattern could apply to speech recognition and machine translation. That framing is worth noting for anyone watching where small-model efficiency research goes next — though those transfers are future work, not shipped results.

The headline number: 93.23% overall on OmniDocBench v1.5, against 87.01% for the DeepSeek-OCR baseline the model was trained from — a 6.22-point gain — and 89.17% for DeepSeek-OCR-2. On the newer v1.6 cut of the benchmark, the paper reports 93.92%, its top score in that comparison table. These figures come from the paper and were cross-reported identically by two independent technical write-ups.

Speed improved alongside accuracy. On the paper’s OmniDocBench throughput measurement in Base mode, Unlimited-OCR generates 5,580 tokens per second versus DeepSeek-OCR’s 4,951 — a 12.7% increase, with the paper noting the gap widens at longer outputs. (A separate benchmark cut measured at 6,144 output tokens shows larger margins; the two measurements come from different test conditions and shouldn’t be merged into one number.)

If you have seen this model in a newsletter or a social recap, you may have read that it parses 100-page PDFs in a single shot. It does not — and the primary sources never claimed it did. Baidu’s own paper states the model “can transcribe dozens of pages of documents in a single forward pass” under its standard 32K maximum context length. Independent technical coverage at byteiota is more specific: the 32K context limit means roughly 40 pages is the practical single-pass maximum today, a constraint the paper acknowledges, with 128K context planned as future work.

Where did the 100-page figure come from? As best we can trace it, a Hacker News commenter used “transcribing a 100-page PDF” as a generic illustration of why the KV-cache problem matters — an explanatory example about long documents in general, not a benchmark result. That framing got compressed into a capability claim as it moved through social recaps. It is a small case study in how model hype propagates: a plausible number detaches from its context and outruns the paper it supposedly describes.

The honest accuracy picture across document length, from the paper’s own long-document test set: at 20 pages in a single pass, edit distance is 0.0572 with a 99.89% Distinct-35 score (a repetition-robustness metric); at 40-plus pages, edit distance rises to 0.1069 with Distinct-35 at 96.90%. Translation: quality degrades measurably but stays usable at the ceiling. For a 40-page contract that would otherwise be chopped into 40 independent fragments, that is still a categorical improvement.

The second claim that needs qualifying: “runs on an 8GB GPU” is true only for the quantized build. Per a third-party hardware guide published two days after release (a single detailed source — treat the specifics as indicative rather than gospel), the full-precision BF16 model weighs about 6.78GB on disk and wants 12GB of VRAM minimum, with 24GB recommended for comfortable production use — RTX 4090 or A100 class. The 8GB figure applies to the 8-bit quantized GGUF build; a 4-bit build reportedly fits in 6GB.

Deployment support is broad for a month-old release. The official repo documents Hugging Face Transformers, vLLM (with official Docker images for CUDA 13.0 and CUDA 12.9/Hopper), and SGLang with an OpenAI-compatible API; aggregator coverage also mentions Ollama and llama.cpp support, and the model is listed on ModelScope and Baidu Cloud. If you are matching a model build to a GPU budget, the tier-matching framework in our open-weight self-hosting hardware guide applies here unchanged: pick the precision your hardware runs comfortably, then validate accuracy on your own documents before committing.

Here is the business decision underneath the architecture talk. The best-sourced cloud comparison point is Mistral OCR 4 — covered in our Mistral OCR 4 breakdown — at an official $4 per 1,000 pages on the standard API, or $2 per 1,000 with the batch discount. Unlimited-OCR’s weights cost nothing and carry an MIT license, so the entire trade is per-page billing versus hardware and operational ownership.

Read the middle column honestly. At 100,000 pages a year, the cloud bill is $200 to $400 — for most businesses, that is not a number worth building infrastructure to avoid. “Free” weights are not free to run: you pay in GPU hours, deployment work, and the ongoing operational attention a self-hosted service demands. On cost alone, the API wins at low and moderate volume, and it is not close.

The stronger argument for self-hosting is control. Invoices, proof-of-delivery documents, signed contracts, and condition reports are among the most sensitive artifacts an operations team touches — full of customer names, addresses, pricing, and signatures. A local model means none of that ever transits a third-party server, which matters in regulated industries, in client-confidentiality contexts, and for any team whose counsel has opinions about processor agreements. It is the same logic we laid out for self-hosted speech-to-text: the API is cheaper until data governance makes it expensive. And single-pass parsing adds a quality argument the per-page APIs structurally lack — documents whose meaning spans pages stay intact.

Credit to the paper: it does not oversell. The authors acknowledge that parsing is not truly unlimited — the 32K context still bounds the prefill, and prefill cost grows as pages accumulate despite the 16× visual compression. Multi-page mode runs in Base resolution only, so very small text can be missed on dense pages. And the R-SWA transfer to speech recognition and translation is a research direction, not a shipped capability.

The practitioner reaction adds a colder shower. The release drew a heavily engaged Hacker News thread, and the most-cited comment came from someone with a decade of skin in the game — the founder of document-parsing company Parseur:

Other commenters in the same thread pushed back on the idea that open-source OCR is even close to production-grade, arguing that commercial services like Amazon Textract remain the bar and that open tooling is still painful to operate and inconsistent in accuracy. That skepticism is earned. Benchmark scores measure performance on curated document sets; production document streams are full of skewed scans, handwriting, stamps, coffee stains, and forty vendors’ invoice formats. A 93.23% benchmark score is a reason to run a pilot, not a reason to delete your existing pipeline.

The right posture for an ops team is exactly the Parseur founder’s: optimistic, untested claims held at arm’s length. Pull a hundred real documents from your own workflow — the ugly ones — and measure. The model is free and the test costs an afternoon; that is precisely what MIT-licensed weights are for.

Zoom out and the trend is bigger than one model. Attention- efficiency research that lived in frontier LLM labs a year ago is now landing in 3B task models that a mid-sized company can run on a single workstation GPU. Document parsing — a category that commanded enterprise-software pricing for two decades — is being commoditized from below by MIT-licensed weights that are one attention-swap away from research checkpoints. The distance from open-weights release to official vLLM support was six days here. That pipeline speed, more than any single benchmark number, is the signal.

Projecting forward: the authors’ stated plan to extend context from 32K to 128K would push the single-pass ceiling from roughly 40 pages toward the length of genuinely long contracts and reports — at which point the “100-page PDF” claim stops being a myth and becomes a spec. Meanwhile, expect per-page API pricing to keep compressing; Mistral’s $2 batch tier already reads like a response to open-weight pressure, and every capable free model ratchets that pressure up. Neither projection is guaranteed — but both directions of travel are visible in the last month of data.

Wherever you land, the pattern to steal is the pipeline, not the model: documents in, structured data out, straight into the CRM or ERP without a human retyping line items. That integration layer — extraction rules, validation, exception handling, and the workflow around failures — is where document automation actually pays for itself, and it is the core of our CRM and automation engagements. If the build-versus-buy question spans more than OCR — model selection, hosting posture, data governance — that is the exact comparative evaluation our AI transformation work starts with.