Unlimited-OCR: The OCR Project That Tries to Read the Whole Document at Once

The end of the OCR assembly line

Unlimited-OCR is interesting because it attacks a tired assumption: that document reading must happen in stages. Traditional OCR chops a PDF into pages, detects text regions, recognizes characters, and then tries to stitch the result back together. That pipeline works, but it is fragile, especially when layout is dense, pages are many, or the structure matters as much as the text.

Baidu’s pitch is sharper than “better OCR.” The repo frames the task as one-shot long-horizon parsing, which is a different mental model entirely. Instead of treating each page as an isolated unit, it tries to keep the document in view as a continuous reading problem.

That is why the project lands as a category shift. It is not saying the old pipeline is useless. It is saying the old pipeline is the wrong abstraction when a document’s meaning lives across pages.

Why “unlimited” is the right word

The name points to context, not magic. The repo’s research framing and implementation details suggest a system built to sustain long outputs and long inputs, with a context window in the 32K range and a serving stack tuned for extended document runs. That matters when the input is not a receipt or a single scan, but a manual, a legal packet, or a book-length PDF.

This is the core promise: keep the model oriented while the document keeps going. In classic OCR, the danger is local accuracy with global amnesia. In Unlimited-OCR, the challenge is the opposite. Maintain continuity without spiraling into repetition or losing fine detail.

What the repo actually ships

The repository is not a training playground. It is a deployment layer around a model that mostly lives elsewhere. The local code is compact and practical: infer.py orchestrates inference, wheel/ ships a custom sglang wheel, and assets/ holds examples and visuals. The heavy lifting comes from the model and serving stack.

That stack is telling. Python sits on top of PyTorch, Hugging Face tooling, PyMuPDF for PDF rasterization, and sglang for structured generation and serving. In other words, the repo behaves more like a specialized document inference service than a classic OCR library you import and call.

# Simplified flow implied by infer.py
pdf_pages = pdf_to_images("report.pdf")
encoded_images = [encode_image(page) for page in pdf_pages]
payload = {
    "prompt": "Parse this document.",
    "images": encoded_images,
}
response_stream = client.chat.completions.create(
    model="Unlimited-OCR",
    messages=[payload],
    stream=True,
)
text = collect_stream_silent(response_stream)

That last step is the tell. The output arrives as a stream, not as a neat OCR table. The repo is managing generation, not just recognition.

The hidden trick is not OCR, it is streaming generation

Once you look at the data flow, the project stops looking like image preprocessing and starts looking like LLM serving. PDF pages are rasterized, encoded, pushed into an API payload, and then consumed by sglang. The model emits tokens continuously, and the surrounding code keeps the whole session coherent.

This matters because the output is only useful if the model can keep its place. Long documents fail in subtle ways. They repeat headings, drift in numbering, or lose track of sections. Unlimited-OCR treats those failures as generation problems, not just vision problems.

PDF -> PyMuPDF images -> base64 payload -> sglang server -> streamed tokens -> structured output

Gundam mode is the tell

The dual-mode inference setup is where the repo gets concrete. Base mode uses a broad view. Gundam mode introduces cropping and higher-resolution handling for dense pages. That is the tradeoff you would expect if the system has to read footnotes, tables, formulas, and tiny text without collapsing the whole page into blur.

The name sounds playful, but the logic is serious. A single coarse view is not enough for many documents. Gundam mode exists because long-horizon parsing still needs local fidelity.

# Conceptual shape of the dual-mode setup
if mode == "gundam":
    base_size = 1024
    image_size = 640
    crop_mode = True
else:
    image_size = 1024
    crop_mode = False

Why repetition control matters more than it sounds

The logit processor is one of the smartest signals in the repo. DeepseekOCRNoRepeatNGramLogitProcessor is a boring name for an important fix. In long-document generation, repetition is not just annoying. It is a collapse in state.

If the model starts looping, it is usually telling you it has lost track of where it is in the document. A no-repeat n-gram constraint cannot solve every failure mode, but it can keep a long parse from degenerating into echoes.

What Unlimited-OCR replaces, and what it does not

It is tempting to say this makes classic OCR obsolete. It does not. Tesseract, PaddleOCR, EasyOCR, and cloud APIs still have clear advantages in cost, maturity, deployment simplicity, and page-by-page extraction. They are often easier to slot into ordinary document workflows.

Unlimited-OCR wins when the task is not just reading text, but preserving document-level coherence. That makes it a better fit for long PDFs, archive ingestion, and RAG systems where structure, section order, and cross-page continuity are the real prize.

So the honest comparison is not better versus worse. It is narrower versus broader. Classic OCR is still the simpler tool for simple jobs. Unlimited-OCR is for when the document has become too large, too structured, or too context-dependent for the old assembly line to handle gracefully.