Baidu Unlimited-OCR: one long document in a single pass, on-prem

The core is a modified attention mechanism in the decoder that keeps memory constant. Classic transformer-based OCR models let the so-called KV cache grow with the length of the document. The longer the PDF, the more memory is needed, until at some point it no longer fits into a single processing run.

Unlimited-OCR replaces this component with Reference Sliding Window Attention (R-SWA). This keeps the KV cache constant, regardless of document length. That is exactly what the term one-shot long-horizon parsing means: a long document is read in a single pass, rather than being split into sections whose results are stitched together afterwards.

The training path is notable. The team did not start from zero but continued training the DeepSeek-OCR checkpoint: freezing the encoder and adapting only the decoder over around 4,000 steps. This puts the model in direct lineage with DeepSeek-OCR, which we have already placed in context within the stack discussion. Code and weights are open on GitHub.

The real problem with long documents is not the individual page, but the connection across pages. When a model cuts a 60-page document into ten-page blocks, exactly what matters in everyday B2B work gets lost: a table that runs across a page break, a clause that refers back to an earlier section, a line item whose reference figure sits twenty pages earlier.

A constant KV cache allows the entire document to be held in one context. Memory does not grow with length, so structure is preserved across all pages. It also gets faster along the way: Baidu reports 5,580 tokens per second in base mode against 4,951 for DeepSeek-OCR, and with an output limit of 6,000 tokens the gap is around 35 percent.

On accuracy, Unlimited-OCR scores 93.23 points on OmniDocBench v1.5, 6.22 above the DeepSeek-OCR baseline, and 93.92 on v1.6. These are the figures from the paper. On your own documents, what ultimately counts is how the model handles your tables, stamps and forms, not the average on a public test set. A related development is happening with sub-quadratic LLMs, which are making long context cheaper on-prem.

The benefit arises wherever long, structured documents need to become clean, searchable data. A few concrete examples:

• Contracts and framework agreements. Cross-references and appendices stay readable in context instead of breaking apart at block boundaries.
• Technical manuals and standards. Long documents with figures, tables and numbered sections processed in a single pass.
• Multi-page invoices and receipts. Cleanly extracted text is the preliminary step for structured downstream processing, for example towards e-invoicing.
• Archives and files. Holdings that until now only existed as scans become machine-readable without handing them to a cloud service.

In almost all cases, OCR is not the goal but the first step. Cleanly parsed text is the foundation for a knowledge base with RAG: the better the parsing, the better search later finds the right spot.

Not every document task needs classic text recognition, and that is a fair trade-off to weigh. There is now an entire branch that does not convert documents into text at all, but instead searches them as images, using models such as ColPali or ColQwen. We have described this OCR-free approach separately.

The rule of thumb that has proven itself for us:

• You need the actual characters (invoice amounts, contract clauses, structured extraction, handing off to another system): then there is little way around OCR, and a model like Unlimited-OCR is strong here.
• You need the right spot, not the full text (answering a question against a large body of documents, finding a figure again): then visual document search can be the more direct route.

Often it is both side by side. Unlimited-OCR makes the OCR part of this stack cheaper and more reliable on long documents.

A good benchmark score is a reason to test the model, not a reason to put it into production. Before I would put Unlimited-OCR into a client process, I would check four things:

🔸 German documents and handwriting. The benchmark figures say little about German forms, old files or handwritten notes. That belongs on its own test set made of real documents.

🔸 Tables and layout. With B2B documents, the fidelity of tables and columns determines the value. A direct comparison with your existing stack is worthwhile here.

🔸 Hardware and operation. 3B as an MoE with around 500M active parameters is realistic on-prem. What that concretely means in GPU memory and throughput needs to be measured before rollout, not estimated.

🔸 Licence and provenance. MIT permits commercial, on-premise use with no fine print. That the model's lineage traces back to one of the DeepSeek-OCR authors is a quality signal, but it does not replace your own testing.

What I actually find interesting about this release is less the model itself than the direction: long documents in a single pass, small enough for your own data centre, under a licence that restricts no one. This is exactly where document processing in the Mittelstand is becoming practical right now. Which of your documents would you run through first?