Unlimited-OCR: Whole-PDF Parsing in One Forward Pass, on an 8GB GPU

Quick verdict

Use Unlimited-OCR when the document, not the page, is the unit of work. Every practical local OCR pipeline until now — including very good ones — processes a PDF as a stack of independent page images and stitches the text back together afterward. That works, but cross-page context dies at every boundary: tables split across pages, section numbering, running footnotes. Unlimited-OCR's pitch, and the reason it kept posting millions of Hugging Face downloads in its first weeks, is that it decodes the whole stack as one sequence with unified context. Baidu's own model card frames the goal as taking "Deepseek-OCR one step further," and the repo doesn't hide the lineage — the decoder code literally ships as modeling_deepseekv2.py alongside the DeepEncoder-derived vision stack.

What it is not: the easiest local OCR install, or the per-page accuracy king. GLM-OCR holds that crown (94.62 on OmniDocBench V1.5, per Z.ai), pulls straight from Ollama, and at 0.9B parameters runs on hardware far below this model's floor. If your workload is screenshots, single scans, or invoices, start there — our local document scanner guide covers that whole pipeline. Come to Unlimited-OCR for long reports, books, filings — anything where you want the model to read the document the way you do, in order, start to finish.

Specs at a glance

All figures below are from the official Hugging Face model card, the repo's config.json, and the arXiv paper — none are our measurements.

How "unlimited" actually works (and what it doesn't mean)

The "unlimited" refers to the KV cache, not the context window. When a normal decoder transcribes a long document, its key-value cache grows with every generated token — memory climbs, speed sinks, and very long outputs eventually fall apart. The paper's contribution, Reference Sliding Window Attention (R-SWA), keeps that cache constant-size throughout decoding. In the authors' words, the model "can transcribe dozens of pages of documents in a single forward pass under a standard maximum length of 32K."

In practice the multi-page flow looks like this, per the model card: PyMuPDF renders each PDF page to an image at 300 DPI, the pages go in together under the <image>Multi page parsing. prompt in Base mode (1024px, crop_mode=False), and the decoder writes the whole document out as one stream. Single images instead use "Gundam" mode — 640px tiles with cropping — which spends more visual tokens per page for higher fidelity on a lone scan.

The honest fine print: 32,768 tokens is still a hard budget shared by the visual input and the transcribed output. "Dozens of pages" is Baidu's own ceiling for one pass — a 300-page book still needs chunking, it just needs it every few dozen pages instead of every page. That is a real, order-of-magnitude improvement in how much unified context your pipeline gets; it is not literally infinite, whatever the name implies.

vLLM setup (recommended)

The Docker command in the quick-answer box above is the entire server setup. Baidu ships dedicated vLLM images — vllm/vllm-openai:unlimited-ocr (CUDA 13.0) and vllm/vllm-openai:unlimited-ocr-cu129 for Hopper GPUs — so there is no dependency wrangling on the server side. Three flags in that command are load-bearing, and the recipe is explicit about all of them: --logits_processors registers the per-request n-gram filter, --no-enable-prefix-caching, and --mm-processor-cache-gb 0. Don't trim them.

On the client side, two things trip almost everyone. The prompt must literally begin with <image>, and you must pass skip_special_tokens: False plus the n-gram arguments per request. Condensed from the recipe's client example:

from openai import OpenAI

client = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1", timeout=3600)

response = client.chat.completions.create(
    model="baidu/Unlimited-OCR",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "<image>document parsing."},
            {"type": "image_url", "image_url": {"url": "page-1.png"}},
        ],
    }],
    max_tokens=8192,
    temperature=0.0,
    extra_body={
        "skip_special_tokens": False,
        "vllm_xargs": {"ngram_size": 35, "window_size": 128},
    },
)

Why the ceremony? Long verbatim transcription is exactly the workload where greedy decoding loves to lock into repetition loops, and a no-repeat window is the standard cure — every official path (vLLM, Transformers, SGLang) configures the same filter, with the window widened from 128 to 1024 tokens for multi-page runs. If vLLM itself is new to you, start with our complete vLLM setup guide — this model is a normal vLLM serve once the image is pulled.

Transformers & SGLang

For scripting a folder of PDFs without running a server, use the Transformers path with Baidu's pinned versions: torch==2.10.0 and transformers==4.57.1. The model loads with trust_remote_code=True (the architecture lives in the repo, not in the transformers library) and exposes a custom infer() method — this is the repo's own quickstart, trimmed:

from transformers import AutoModel, AutoTokenizer
import torch

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()

model.infer(
    tokenizer,
    prompt='<image>document parsing.',
    image_file='your_image.jpg',
    output_path='out/',
    base_size=1024, image_size=640, crop_mode=True,   # "Gundam" single-image mode
    max_length=32768,
    no_repeat_ngram_size=35, ngram_window=128,
    save_results=True,
)

For PDFs, the repo ships a converter that renders pages at 300 DPI via PyMuPDF (pymupdf==1.27.2.2 is in the pinned requirements) and an infer_multi() entry point that runs the whole stack in Base mode (image_size=1024, crop_mode=False) with ngram_window=1024. The stack is tested on Python 3.12.3 + CUDA 12.9 — respect the pins; trust_remote_code models are exactly where a casual pip install -U transformers breaks things.

SGLang is the third official path — and the fussiest. The repo bundles its own SGLang dev wheel (a stock pip install sglang won't do), and the launch command below is verbatim from the README, including --enable-custom-logit-processor, which is how the n-gram filter engages on this runtime. The FlashAttention-3 backend wants a recent NVIDIA GPU:

# from a clone of github.com/baidu/Unlimited-OCR:
uv pip install wheel/sglang-*.whl        # the dev wheel bundled in the repo
uv pip install kernels==0.11.7 pymupdf==1.27.2.2

python -m sglang.launch_server \
    --model baidu/Unlimited-OCR \
    --served-model-name Unlimited-OCR \
    --attention-backend fa3 \
    --page-size 1 \
    --mem-fraction-static 0.8 \
    --context-length 32768 \
    --enable-custom-logit-processor \
    --disable-overlap-schedule \
    --skip-server-warmup \
    --host 0.0.0.0 --port 10000

Unless you already run SGLang, the vLLM Docker route is less friction here — the dedicated image exists for this model, the SGLang path does not get one. Our SGLang vs vLLM comparison covers when the trade flips.

Unlimited-OCR vs GLM-OCR vs DeepSeek-OCR

Short version: GLM-OCR for pages, Unlimited-OCR for documents, DeepSeek-OCR is the research ancestor both trade against. Facts below are from each project's Hugging Face card and repo; benchmark figures are each vendor's published numbers, not ours.

One row deserves emphasis: Baidu publishes no head-to-head accuracy table on the model card. What the card does carry is a self-score on llamaindex ParseBench (46.17 mean, 86.81 on text content) with no competitors alongside it, and acknowledgements thanking "Deepseek-OCR, Deepseek-OCR-2, and PaddleOCR for their valuable models and ideas" — the comparative claims live in the paper, not in a reproducible card table. If your decision hinges on per-page accuracy, GLM-OCR's published OmniDocBench numbers are the strongest verifiable claim in local OCR right now, and you should run both models on ten of your documents before committing a pipeline — that costs an afternoon and settles it better than any leaderboard. For general question-answering over documents (rather than transcription), a full VLM like Qwen3-VL is the different tool for that different job — our local vision tasks guide maps which model class fits which task.

Honest limitations

• •"Unlimited" is bounded at 32K per pass. The constant-size KV cache is real engineering, but visual input and text output still share a 32,768-token budget. Dozens of pages per pass — Baidu's phrasing — not hundreds.
• •No published accuracy comparison from Baidu. The card ships deploy instructions plus one self-score (llamaindex ParseBench, 46.17 mean) — no competitors in the table. Until third parties publish head-to-heads, treat accuracy-vs-GLM-OCR as an open question you answer on your own documents.
• •No official Ollama or quantized builds. BF16 on a ≥ 8GB NVIDIA card via vLLM/Transformers/SGLang is the supported story. Community GGUF/MLX conversions exist but sit outside the documented configs — the n-gram processor especially may behave differently there.
• •Pinned, fast-moving dependency stack. torch==2.10.0, transformers==4.57.1, trust_remote_code, a bespoke logits processor, and vLLM ≥ 0.25.0. Baidu iterates quickly (four ecosystem updates in its first month); expect version churn and re-read the repo before upgrading anything.
• •Fluent errors on degraded input. Like every neural OCR model, a blurry scan can yield confident, grammatical, wrong text instead of visible garbage. For legal or archival work, spot-check against the source. The traditional OCR stack fails more visibly, which is sometimes a feature.
• •No throughput numbers here — deliberately. Neither the card nor the recipe publishes tokens/sec or pages/min, and we haven't completed our own timed run yet. Anyone quoting precise speeds for this model right now is guessing; budget a pilot on your own GPU.

Frequently asked questions