Unlimited OCR 2: Baidu’s Long-Document Breakthrough—and Its Real Limits

Key Takeaways

• Unlimited OCR 2 is Baidu’s document-parsing model, released on October 27, 2026. The official checkpoint is baidu/Unlimited-OCR-2.
• “Unlimited” describes its approach to processing long documents. It does not promise unlimited free uploads, infinite GPU memory, or unrestricted API usage.
• Evaluate complete documents, not just attractive sample pages. Missing pages, broken table continuations, and incorrect headings can matter more than isolated recognition errors.
• Published speedups require context. Faster token decoding does not translate directly into the same improvement in total PDF processing time.
• Start with the official resources and a representative test set. A successful demonstration is the beginning of an evaluation, not proof of production readiness.

Updated November 1, 2026.

What Is Unlimited OCR 2?

Unlimited OCR 2 is a vision-language model for converting document images into machine-readable content. Its central use case is extracting information across long documents while maintaining useful continuity between pages.

The practical problem is familiar: a paragraph continues onto another page, a table repeats its column headings, or a document contains hundreds of pages that need to be processed in order. A useful extraction system must preserve those relationships while producing complete output.

The starting points are the official GitHub repository, Hugging Face model page, and project-linked online demo. The model documentation provides both single-page and multi-page inference methods.

For developers, the relevant question is whether the model can produce more complete, usable documents at an acceptable operating cost. That requires measuring extraction quality, failure rates, and review effort together.

How Unlimited OCR 2 Handles Long Documents

The architecture combines two mechanisms:

• Sparse Reference Sliding Window Attention, or SR-SWA: Page Gate restricts visual candidates; Token Sieve selects relevant blocks.
• Unlimited-Horizon Decoding: overlapping page chunks reuse boundary information while inactive visual caches are released.

The engineering implication is that a document can advance through a bounded working area instead of requiring every page to remain equally active throughout generation.

Consider a book transcription workflow. Finishing page 180 should not require repeatedly examining every visual detail on pages 1–179. However, some nearby context may still be useful when a paragraph or table crosses a page boundary.

This design also explains why one document request can involve multiple internal processing windows. A unified user experience does not imply that the entire book occupies GPU memory simultaneously.

What “Unlimited” Actually Means

Three different limits must be separated:

A scalable attention mechanism does not remove the work of reading and transcribing additional pages. More output still requires more decoding steps, and larger inputs still require preparation and storage.

A useful planning equation is:

Total processing time =
  upload and queue time
  + PDF rendering
  + visual encoding and prefill
  + text decoding
  + output conversion and validation

Improving one component can substantially help without accelerating the entire pipeline by the same factor.

Unlimited OCR 2 Benchmarks: Where the Gains Appear

The technical paper reports these aggregate parsing scores; higher is better. They are author-reported results, not independent measurements.

The improvement is 22.70 points on MPDocBench, versus 0.10 on OmniDocBench v1.6. TeleOCR scores 96.91 on the latter, so Unlimited OCR 2 does not lead every benchmark.

The authors also report 7.0× and 5.6× per-step speedups over Full Attention and R-SWA, respectively, at the hundred-page scale. These compare attention approaches, not complete commercial OCR services.

For a purchasing or deployment decision, the useful interpretation is task-specific: test whether the gains address the documents that currently fail, require stitching, or consume disproportionate review time.

The Benchmark Caveat That Changes the Comparison

MarathonDocBench contains 100 documents, approximately 18,000 pages, and roughly 205,000 annotated layout elements. Its material includes mixed Chinese and English content and frequent cross-page structures.

Its evaluation notes disclose an important condition: competing general VLMs receive whole documents in a single request. Provider image limits, request limits, timeouts, or output ceilings can prevent completion. Failed documents remain empty predictions in the evaluation denominator.

Consequently, the results partly measure whether the delivery method can finish the requested document, alongside recognition quality. They do not establish that every competing model performs equally poorly when embedded in a carefully designed batching pipeline.

A fair internal comparison should therefore include:

• A whole-document request where supported.
• A practical page-batching baseline with reconstruction.
• The percentage of documents completed without intervention.
• Quality and cost for successfully completed documents.

Keep completion rate and accuracy separate. Otherwise, an impressive average can conceal a system that works beautifully on easy files and fails on difficult ones.

Which Workloads Should Evaluate It?

These are recommended evaluation priorities, not guarantees of performance.

For RAG, preserve provenance before optimizing chunk size. A useful retrieved passage should remain connected to its document, page, and surrounding section. Fluent text with missing provenance is harder to audit and correct.

For tables, inspect whether a value still belongs to the correct row and column. Recognizing every number is insufficient if the output shifts those numbers into the wrong records.

How to Try Unlimited OCR 2

For a browser demonstration, open the Baidu-hosted Hugging Face Space. Begin with a public document containing a known paragraph continuation or table boundary. The demo page is available as an entry point; successful inference and current quotas are not established here.

For local evaluation, follow the repository’s Transformers instructions. Its documented test environment uses Python 3.10, PyTorch 2.13.0, Transformers 4.52.1, and an NVIDIA A800 with 80 GB memory. That identifies a tested environment, not a published minimum requirement.

After installing the documented dependencies and loading model and tokenizer as shown in the README, the following example submits ordered page images:

from pathlib import Path

# Use zero-padded names: page_0001.png, page_0002.png, ...
page_paths = sorted(Path('pages').glob('page_*.png'))
if not page_paths:
    raise FileNotFoundError('No page images found in pages/')

text, token_count = model.infer_multi(
    tokenizer,
    image_files=[str(path) for path in page_paths],
    output_path='output/document',
    save_results=True,
)

print(text)
print(f'Generated tokens: {token_count}')

The example uses the documented infer_multi interface. It assumes the model is already initialized and the PDF has been rendered into page images.

Check ordering before inference. Ordinary alphabetical sorting can place page_10.png before page_2.png; zero-padding prevents that specific mistake.

Hardware, Serving, and Deployment Details

Do not size the GPU from the download alone. The published weight shards are approximately 5 GB and 1.69 GB. Those are file sizes, not a complete runtime memory budget. Leave room for visual processing, caches, temporary allocations, and concurrent requests.

Use the release-specific serving instructions. The project recommends SGLang for serving and documents a customized wheel. Treat that recipe as the integration reference rather than assuming any generic installation command provides equivalent functionality.

Track generation limits explicitly. The official evaluation client calculates output budgets and handles requests that exceed server limits. A long-document architecture still needs appropriate runtime budgets.

For a production pilot:

1. Begin with one request at a time. Establish memory and completion behavior before increasing concurrency.
2. Record input characteristics. Include page count, image dimensions, language, and document category.
3. Measure the full pipeline. Capture queue time, rendering time, first output, final output, and validation time.
4. Preserve raw output. Keep it alongside normalized Markdown so conversion errors can be distinguished from recognition errors.
5. Record model and runtime revisions. A changed checkpoint or dependency should not silently become part of an existing comparison.
6. Implement resumable jobs. Store document identifiers and completed stages so a timeout does not force unnecessary reprocessing.

The most useful operational metric is often cost per accepted document: infrastructure, retries, and human correction divided by documents that meet the quality threshold.

Common Failure Modes and How to Detect Them

Missing endings. A long output can appear successful while stopping before the final pages. Verify the final paragraph and inspect generation stopping conditions.

Duplicated content. Repeated headers are normal in source documents; repeated body paragraphs may indicate an extraction or reconstruction problem. Avoid deleting repetitions blindly.

Incorrect table continuation. Compare row counts, repeated column headings, and totals across page boundaries. A visually tidy Markdown table can still contain structural errors.

Lost heading hierarchy. The paper acknowledges limitations in retaining global document information, including heading structure.

Wrong page order. Validate the input sequence independently of the model. Incorrect ordering can produce plausible text that represents the wrong document structure.

Overaggressive image reduction. Test small text, subscripts, and dense tables when changing rendering resolution. Record both quality and processing cost rather than selecting a resolution from speed alone.

Treating Markdown as a finished spreadsheet. If a downstream workflow requires Excel, define cell types, merged-cell behavior, numeric validation, and workbook generation as separate acceptance criteria.

A Practical Evaluation Plan

Build a small test set that reflects actual usage. Include easy documents, difficult documents, and files that previously required manual repair.

For each document, record:

• Completion: Did every required page appear in the result?
• Critical text accuracy: Are names, identifiers, dates, and quantities correct?
• Structural accuracy: Are headings, paragraphs, formulas, and tables organized correctly?
• Continuity: Do paragraphs and tables reconnect correctly across pages?
• Performance: What are total latency, peak memory, and retry count?
• Review effort: How long does a person need to make the output acceptable?

Use both whole-document checks and detailed samples. Reviewing only the first page will miss failures that appear late in generation.

When comparing configurations, change one major variable at a time: rendering resolution, page window, output budget, or concurrency. Otherwise, a quality improvement may be incorrectly attributed to the model when it came from better inputs.

Pricing, Licensing, and Privacy

The official model repository lists the MIT license. Open model availability does not make hosted inference, GPU infrastructure, storage, or operational support free.

For a hosted service, verify the operator, processing location, retention policy, and current upload limits. The model name alone says nothing about those service-level arrangements.

For self-hosting, define retention for originals, rendered pages, extracted text, logs, and backups. Keeping inference under organizational control is useful only when the surrounding data handling is also intentional.

The documented loading path uses trust_remote_code=True. Hugging Face explains that custom model loading executes repository-provided modeling code and recommends reviewing that code and pinning a specific revision. Apply the same reviewed revision consistently when loading model components.

Frequently Asked Questions

Is Unlimited OCR 2 an unlimited free online OCR service?

The name identifies the model and its long-document processing approach. Any online service using it can impose separate quotas, page limits, and charges.

Does the benchmark score mean that percentage of characters are correct?

No. An aggregate document-parsing score combines different aspects of extraction. Use character-level or field-level checks when those are the outcomes the application needs.

Should it replace an existing OCR pipeline immediately?

Run a parallel evaluation first. Replacement makes sense when it improves acceptance rates, reduces correction effort, or lowers operating cost on representative documents.

Can it process confidential files safely?

That depends on deployment and data handling. Review the actual hosting environment and retention arrangements before sending confidential material.

Can it replace a document-question-answering system?

Treat extraction and answering as separate evaluation stages. First confirm that the source material was recovered correctly; then assess retrieval and answer quality against that material.

Conclusion

Unlimited OCR 2 deserves evaluation when long documents, page continuity, and extraction completion are recurring problems. Its value should be measured in usable documents delivered, not inferred from the word “unlimited” or a single speedup figure.

Start with the official demo or repository, select representative files, and compare completeness, structure, latency, and correction effort against the current pipeline. Those results will show whether it is a useful upgrade for the workload that matters.