Unlimited-OCR-2 vs Datalab: Cross-Page Parsing, Chandra, Surya and Our OCR Tests

A table that continues on the next page is not two unrelated tables. A paragraph cut by a page break is not necessarily a new paragraph. Yet many document pipelines extract each page independently and leave those relationships for another stage to repair.

That is the useful question behind Baidu’s Unlimited-OCR-2: can the parser retain document-level context rather than treating a PDF as a bag of page images? Its focus is long-document parsing, not simply another claim of better character recognition. The model card announces the second release on October 27, 2026 and describes ordered, multi-page inference in a single request. [1]

I inspected the model documentation, technical report and the exact Hugging Face Space you can try. I also submitted a synthetic English/Arabic page containing a table and a formula. The page worked. The two-page request did not: Hugging Face rejected the requested GPU duration before a successful parse. That distinction matters throughout this comparison.

Bottom line: Unlimited-OCR-2 deserves evaluation when cross-page structure is your bottleneck. It has not, in this review, demonstrated that it replaces Chandra, Surya, Falcon-OCR or a complete Datalab processing service.

1. What the linked Space actually is

The supplied link is a hosted Gradio application, not a separate model named after its interface. Its title is “Unlimited OCR Works 2 Studio”; the underlying model identifier is baidu/Unlimited-OCR-2. The Space includes single-page parsing, PDF rasterization, ordered multi-page parsing, token streaming and a rendered block view. The model card credits AK for creating the demo. [1][2]

Review snapshots:

Model documentation: c14071b549f4fcab10909f3c4acc6a2edb366947.
Space source: 78c27d176793811cf8b5e74b62ceb04dd773c29a.
Hosted test: the public Space on October 29, 2026. Its response does not attest a loaded weight revision, so the documentation pin is not a guarantee that I executed that exact checkpoint.

The demo loads the model onto its hosted GPU; this is not in-browser OCR. Uploading a document sends it to the Space’s server. MIT licensing does not turn a public upload into a private local operation. [1][2]

2. The architectural idea—and what “Unlimited” does not mean

Baidu’s report describes a DeepSeek-OCR-derived backbone with a DeepEncoder and an approximately 3B-parameter mixture-of-experts decoder, with roughly 500M activated parameters per token. The differentiator is Sparse Reference Sliding Window Attention (SR-SWA). A Page Gate selects relevant pages; a Token Sieve selects useful remote visual-token buckets, rather than attending indiscriminately to the entire growing document. [3]

The intended benefit is a bounded active reference set and more stable per-step decoding cost as document length grows. It does not mean that a longer book takes no additional total time, requires no storage, or can run on any GPU. Nor are activated parameters a direct GPU-memory requirement: inactive expert weights still need a storage/serving strategy. [1][3]

The reviewed demo is much more finite than the name:

It caps a document at 20 pages and slices longer page lists to that cap.
Its PDF endpoint rasterizes pages; uploading a PDF is not native PDF-text-layer extraction.
It applies a per-page output-token budget and GPU-duration reservations.
Long runs can stop and return partial content. A parse can report truncation; do not treat a nonempty response as proof that every page was captured. [2]

The model card’s long-document serving route uses a custom SGLang build and page-window controls. The Space’s own README is explicit: its Transformers backend does not perform unlimited-horizon decoding and is intended for small-scale testing. It is not simply the unlimited serving route behind a smaller upload form. I did not install that serving stack or reproduce its hundred-page behavior. [1][12]

Local setup also deserves a dependency review: the documented loaders use trust_remote_code=True, and the Space installs part of its inference stack at runtime to work around dependency conflicts. Pin and inspect custom model code and the serving environment before using confidential documents; a research demo is not a hardened production service. [1][2][12]

Baidu reports 7.0× and 5.6× per-step speedups against Full Attention and its earlier R-SWA setup at the hundred-page scale. These are the authors’ specific experimental comparisons, not speedups over Chandra or Datalab, and not a promise that an entire book finishes that much faster. [3]

3. What I actually tested

I created two clean, high-contrast 1100 × 850 synthetic raster pages. Neither contains a real customer, invoice, signature or private document. The first includes:

An English test identifier.
The Arabic sentence: “هذا مستند تجريبي لا يحتوي على بيانات شخصية”.
A four-column equipment table with two item rows and known values.
The formula E = m c^2.

I called the public single-page endpoint with mode=auto, an empty custom instruction and max_page_tokens=2048. I then attempted the two-page document endpoint with the same settings.

Single page: successful, with an output-cleanup caveat

The returned content preserved the complete Arabic sentence, the expected table cells and the formula as LaTeX. The service reported 234 generated tokens, 14.6 seconds and truncated=false; my client measured 17.112 seconds wall time for the call. These are observations from one run, not throughput, tail latency or an accuracy benchmark.

One implementation caveat: the Space derives truncated from the overall length stop, but the model’s per-page guard can force a page marker or EOS at its token cap. Thus truncated=false is not a completeness certificate; my confidence on this fixture comes from checking its expected text and cells, not from trusting that flag. [2][17]

The raw result included block labels and coordinates, an HTML table and a layout visualization. However, its field named markdown still contained block/control markers. A field name is not a guarantee of clean RAG input: normalize the output and validate table structure before indexing it.

Two pages: hosting restriction, not an OCR accuracy result

The request was rejected with a ZeroGPU duration error: the server requested 270 seconds, exceeding the allowance available to this request. I did not subscribe, bypass the restriction or claim a two-page success. The pinned app source reserves 180 seconds for a two-page document, whereas the live rejection said 270 seconds. I have not established the reason for that discrepancy; the rejection is a recorded observation, not a derivation from the source. [2]

This establishes a practical limitation of the public demo in my access context. It does not establish that the underlying model cannot parse two pages. It also means I have not demonstrated cross-page table merging, the feature that makes this model most interesting.

Reproducible evidence:

No Datalab API, local OCR model, difficult historical scan, handwriting collection or representative Arabic corpus was exercised in this test. The findings above cannot rank those alternatives.

4. Compare the right layers

Unlimited-OCR-2: document-level context

Its strongest reason to enter a shortlist is the ordered multi-page decoding design. Evaluate it on tables spanning page breaks, paragraph continuations and long reports. Inspect both completeness and the correctness of cross-page relationships—not just whether some recognizable text appears. The model is MIT-labelled, but GPU capacity, custom serving dependencies and operations are still your responsibility. [1][2][3]

Chandra OCR 2: complex document conversion

Chandra’s documented scope includes PDFs/images to Markdown, HTML and JSON with layout information, handwriting, forms, tables, equations and 90+ languages. Its packaging offers vLLM and Hugging Face inference routes. It is a strong candidate for a complex-document evaluation, not a guarantee that every cell or Arabic passage will be correct. [4]

Datalab’s recent benchmark uses an approximately 4.5B inference-parameter count for Chandra 2. This is not the 0.9B class: parameter accounting must identify what it includes. Datalab explains that its benchmark counts tied embeddings once and excludes multi-token-prediction heads. Do not infer VRAM from a marketing size alone. [7]

Surya OCR 2: smaller OCR, layout and table recognition

The current Surya documentation describes a 650M-parameter model handling OCR, layout/reading order and table recognition. It exposes structured block output including HTML, polygons/bounding boxes, confidence and error fields; serving options include vLLM and llama.cpp. [5]

That makes Surya a sensible smaller-model baseline before committing to a larger decoder. Its vendor-reported pages-per-second result depends on a named GPU and serving configuration; it is not a promise for a small VPS. It is also not evidence of Unlimited-style long-document joint decoding. [5]

Same-day update: Surya 2.5 is now available. Datalab released surya-ocr v0.23.0 on October 29, switching the default to datalab-to/surya-ocr-2.5, a 689M model. The release reports 1.7× Surya 2 throughput on one H100 and 85.9 on OmniParseBench; these are vendor results, not measurements from this review. The table interface also changes: 2.5 does not provide row/column geometry, and the release directs users who need the simple geometry mode back to Surya 2. Pin the model deliberately rather than assuming an upgrade preserves every output field. [13][19]

The 650M description above deliberately refers to the pinned Surya 2 checkpoint, not the newly released 2.5. I ran neither version locally.

Marker: a pipeline, not a competing weight file

Marker is a document-conversion system: PDF and other document formats to Markdown, JSON, chunks or HTML, with processing logic, image extraction and optional LLM assistance. It can use an existing text layer rather than forcing every document through the same expensive OCR route. [6]

Importantly, cross-page repair is not exclusive to Unlimited-OCR-2. Marker documents LLM-assisted cross-page table merging; Datalab’s managed pricing also lists cross-page merging as a beta add-on. The architectural distinction is joint decoding versus additional pipeline work—not “one can merge and the others cannot.” [6][8]

Marker can run locally, but --use_llm introduces a provider choice. The reviewed documentation defaults that option to a Gemini service; local OCR plus a remote correction model is not an all-local pipeline. Configure and audit the actual route. [6]

Datalab API: a managed system, not merely hosted public weights

The managed API combines models and processing steps. Datalab explicitly says the accurate route adds correction work beyond the bare Chandra model. Its service result should therefore not be attributed to the downloadable weights alone. [7]

Use it as a separate candidate when you want managed processing, structured extraction and less GPU maintenance. Compare the bill, retention settings, data-processing terms and operational guarantees as well as the output.

Falcon-OCR: our lightweight baseline

TII’s current Falcon-OCR card identifies a 270M-parameter early-fusion model, with the 1.5 weight update and text, table-HTML and formula-LaTeX output. Its Apache-2.0-labelled release makes it relevant when a small, permissively licensed component matters more than preserving a whole book’s context in one decoding run. [11]

Small does not mean adequate for every document, and OCR with a separate layout stage is a different configuration from direct end-to-end generation. Our earlier setup guide is a starting point, not a shared benchmark against this new Baidu release.

5. What the published scores can—and cannot—tell us

Datalab’s recent OmniParseBench article reports Chandra OCR 2 at 90.1 overall and Unlimited-OCR at 79.3. The latter is the first Unlimited-OCR, not Unlimited-OCR-2. The linked model/version must match before using a number in a comparison. [7]

The same article describes 16,288 pass/fail tests over 2,937 pages, with text, table and layout families. It is a Datalab-run evaluation that includes Datalab’s own products; the dataset and methodology are useful, but the provenance should remain visible. Its headline is not interchangeable with an olmOCR score. [7]

Baidu’s report instead emphasizes MPDocBench and MarathonDocBench, including hundred-page parsing; MarathonDocBench is introduced by the same team. Those results address a different task distribution from a conventional page-parser comparison. They are author-reported evidence, not my independent reproduction. [3]

Accordingly, this article does not declare an overall winner or construct a leaderboard by mixing:

Version-one scores with version-two claims.
Vendor-run results with independent hands-on testing.
Page-level extraction with document-level continuity.
Public weights with an API’s correction pipeline.
Different hardware, output budgets, prompts or failure-handling policies.

6. Licensing, cost and privacy change the decision

Licensing is not uniform across Datalab models

The reviewed Chandra card describes Apache-2.0 code, while its weights carry a modified OpenRAIL-M license. The actual weight license restricts non-personal/non-research use when the affiliated entity exceeds $2M in prior-year gross revenue or $2M in total funding, and separately restricts competing products/services. [4][9]

Surya’s reviewed weight license instead uses $5M revenue/funding thresholds, plus the competition restriction. Do not copy Chandra’s threshold onto Surya—or assume that Apache code licenses remove weight restrictions. Check the exact version and applicable commercial terms. This is a deployment checkpoint, not legal advice. [10]

Unlimited-OCR-2’s MIT label and Falcon-OCR’s Apache-2.0 label are simpler starting points, but they still require dependency and deployment review. Neither label pays for inference or certifies security. The demo’s PDF support uses PyMuPDF, available under AGPL or a commercial license: an MIT-labelled model does not make its entire deployment MIT. Review dependency obligations as well. [1][11][16]

Hosted API prices are processor prices

At the time checked, Datalab lists these base conversion rates per 1,000 pages:

Lite: $0.50.
Fast / balanced: $4.
Accurate: $10.

These are not quotes for every end-to-end workflow. Extraction, bounding-box options and cross-page merging can add work and charges; the latter is variable-priced beta functionality. Region, retention choices and plan terms also affect billing. A no-subscription tier does not mean unlimited free processing. [8]

I did not make a billable Datalab request or calculate a claimed cost advantage over self-hosting. Local cost includes the actual GPU, utilization, retries, monitoring and engineering time—not just a free model download.

Follow the document’s data path

Public Space: documents leave your device. Use non-sensitive fixtures unless the hosting terms and access controls satisfy your requirements.
Self-hosted weights: can support local inference, but inspect downloads, dependencies, logs, temporary files and any optional external correction service.
Managed Datalab API: the reviewed README describes opt-in zero retention. Security documentation says conversion results normally expire after about one day and describes training consent as opt-in; verify the account’s actual settings and contract. [14][18]
Datalab public Playground: this is a different boundary. Its terms permit storage and training with no opt-out, allow indefinite retention and forbid personal/health data uploads. Creating an account later does not retroactively change the terms for previous Playground uploads. Use synthetic material there. [15]
Marker with an LLM: choose the provider explicitly; the optional remote pass can change both privacy and cost. [2][6][8]

7. How this updates our earlier OCR coverage

Two existing articles are directly relevant:

Chandra OCR 2: complex tables, math and multilingual document intelligence. Keep it as the deeper capability/setup discussion. Treat its benchmark figures as dated, attributed results—not a permanent global ranking. The current licensing check must include both revenue and funding, the competition restriction, and the exact weight license. Also use the current datalab-to/chandra-ocr-2 identifier; the earlier article’s datalab-to/chandra reference points to the older checkpoint. [18]
Falcon-OCR: early fusion and local setup. Keep it as the lightweight alternative. Its introductory grouping of larger OCR models into a 0.9B–3B range and its approximately 0.9B Chandra table row were inaccurate for current Chandra 2; the current comparison above corrects that framing. A model’s size and a serving system’s total memory footprint are not interchangeable.

The addition here is document continuity, plus an explicit distinction between what I read, what the vendors measured and what I actually executed. None of the earlier guides or this smoke test establishes which parser is most accurate on your files.

PixelRAG’s screenshot retrieval is adjacent but different: retrieving a relevant page image is not the same acceptance test as extracting its cells, equations and reading order. It should not be folded into an OCR accuracy leaderboard.

8. A practical selection rule

My engineering shortlist would be:

Cross-page relationships are failing: evaluate Unlimited-OCR-2 on real continuations in an approved environment; do not use the free Space’s availability as a production SLA.
Complex layouts, forms and multilingual extraction: evaluate Chandra and, separately, the managed Datalab route.
A smaller structured OCR/layout baseline: evaluate Surya 2.5, retaining Surya 2 if you require its documented row/column geometry. Pin the chosen version.
A very small permissive OCR component: evaluate Falcon-OCR 1.5, including the layout configuration you actually need.
Mixed file formats and reusable processing stages: evaluate Marker before building those stages yourself.

Use the same held-out documents for every candidate, with ground-truth cells and cross-page links, Arabic reading order, formula checks, completeness checks, retry counts and an agreed cost budget. Include blanks, scans, noisy pages and failures; do not publish only attractive successes. Track a complete, correct document, not merely tokens per second.

The useful advance is not the word “Unlimited.” It is the attempt to preserve the relationships that make a document a document. Whether that advantage pays off is still something to measure on the documents you need to process.

Sources

[1] https://huggingface.co/baidu/Unlimited-OCR-2/blob/c14071b549f4fcab10909f3c4acc6a2edb366947/README.md — Unlimited OCR Works 2 model card [2] https://huggingface.co/spaces/baidu/Unlimited-OCR-2/blob/78c27d176793811cf8b5e74b62ceb04dd773c29a/app.py — Unlimited OCR 2 hosted Space implementation [3] https://huggingface.co/baidu/Unlimited-OCR-2/blob/c14071b549f4fcab10909f3c4acc6a2edb366947/Unlimited-OCR-2.pdf — Baidu Unlimited OCR Works 2 technical report [4] https://huggingface.co/datalab-to/chandra-ocr-2/blob/af93b47dba1b47b6640c86ccf487ed2260ab9a09/README.md — Datalab Chandra OCR 2 model card [5] https://huggingface.co/datalab-to/surya-ocr-2/blob/3b3d4cdf88d6928b0acdc75181b13206ea67c4a3/README.md — Datalab Surya OCR 2 model card [6] https://github.com/datalab-to/marker — Datalab Marker document conversion pipeline [7] https://www.datalab.to/blog/open-ocr-models-omniparsebench — Datalab vendor-run open OCR OmniParseBench comparison [8] https://www.datalab.to/pricing — Datalab managed API pricing [9] https://huggingface.co/datalab-to/chandra-ocr-2/blob/af93b47dba1b47b6640c86ccf487ed2260ab9a09/LICENSE — Chandra OCR 2 weight license [10] https://huggingface.co/datalab-to/surya-ocr-2/blob/3b3d4cdf88d6928b0acdc75181b13206ea67c4a3/LICENSE — Surya OCR 2 weight license [11] https://huggingface.co/tiiuae/Falcon-OCR/blob/0bc28f89c90fbe8bdb063097fab144d4ce4c19b5/README.md — TII Falcon OCR 1.5 model card [12] https://huggingface.co/spaces/baidu/Unlimited-OCR-2/blob/78c27d176793811cf8b5e74b62ceb04dd773c29a/README.md — Hosted Space limitations and dependency notes [13] https://github.com/datalab-to/surya/releases/tag/v0.23.0 — Surya 2.5 same-day release [14] https://documentation.datalab.to/platform/security — Datalab API results retention and training consent [15] https://www.datalab.to/terms/end-user-terms — Datalab public Playground terms [16] https://pymupdf.readthedocs.io/en/latest/about.html — PyMuPDF dependency licensing [17] https://huggingface.co/baidu/Unlimited-OCR-2/blob/c14071b549f4fcab10909f3c4acc6a2edb366947/modeling_unlimitedocr.py — Baidu model per-page token guard [18] https://github.com/datalab-to/chandra/blob/b20d54d94e53b32211c98408620edef63e99a4ec/README.md — Current pinned Chandra checkpoint and managed platform [19] https://huggingface.co/datalab-to/surya-ocr-2.5/blob/00c843e9cae45611dca0a6dc2c9bbbf2dadaaed3/README.md — Surya OCR 2.5 pinned model card