What happened
Developer Efrain Garay tested Baidu’s Unlimited-OCR 2 locally on an RTX 4070 Ti SUPER with 16 GB of VRAM, comparing it with Datalab’s Chandra 2 and Marker, DeepSeek-OCR, Tesseract, and Unlimited-OCR version 1. The test followed Baidu’s October 27 release of Unlimited-OCR 2, a 3.3B-parameter, MIT-licensed model whose documentation describes SR-SWA sparse attention as keeping decoding latency and memory footprint nearly constant as document length grows.
The benchmark used two kinds of material. One was a typeset PDF of the opening of Don Quixote, including a degraded scan-like variant. The other was a selection of 20 text-heavy, image-free pages from the September 2026 Monetary Policy Report of the Central Bank of Chile. All systems read the same page images rendered at 144 dpi. Garay measured character error rate after applying the same normalization to every output, and ran one request at a time with a GPU lock. He also committed hypotheses and measurement amendments before most of the associated runs.
On the real report, Unlimited-OCR 2 produced a median character error rate of 0.12%, versus 0.31% for Chandra 2. The author treats that comparison as a tie because the bootstrap confidence interval for their paired difference reaches zero. The model did outperform Marker at 2.51%, DeepSeek-OCR at 3.12%, and Tesseract at 0.51% on that corpus. The result was not simply a clean-text result: on six of 20 report pages, DeepSeek-OCR returned fewer than 90% of the reference characters, while Unlimited-OCR 2 did so on one page.
The long-context result was less favorable. In the Transformers implementation, reported peak memory rose from 7.5 GB at 10 pages to 11.1 GB at 40 pages and the process ran out of memory at 80 pages. Baidu’s modified SGLang path behaved differently: time per token remained roughly flat at about 4.2 milliseconds, but its 10-page window mode hung in this setup. A single-window request for 40 pages returned only 24 pages without an error, which the author attributes to the server’s auto-truncate behavior. The test author notes that the GPU was shared and that the SGLang problem may be environment-specific.
What the archive adds
This is a new fact on a known story. Our release note on Unlimited-OCR 2 covered Baidu’s 3B-class MIT-licensed release and its any-length parsing claim. A related note placed it among DeepSeek-OCR, PaddleOCR, and Baidu’s first Unlimited OCR release. The independent test adds a concrete 16 GB operating boundary and a silent-output-loss failure mode.
Trend signal
No supplied pattern is a genuine fit. This is primarily a measurement of a document-model implementation and its deployment limits, rather than evidence for a broader New Runtime pattern.
Why now
The test was conducted immediately after the October 27 release, when the product’s central claim—near-constant decoding memory and latency over document length—could be checked against a common local-GPU constraint. That timing matters because early adoption decisions may otherwise be made from model cards and short quality demonstrations rather than long-document operating behavior.
Connections to other events
The release context matters because Unlimited-OCR 2 is positioned as a successor in a line that includes DeepSeek-OCR and Baidu’s prior Unlimited OCR work. The comparison shows that a newer document model can improve extraction quality without making its long-context execution path operationally dependable on a particular self-hosted machine.
Why it matters
For teams building document ingestion systems, OCR quality is only one acceptance criterion. A model that produces low character error on sampled pages can still fail the workflow if a longer request exhausts GPU memory, stalls, or returns an incomplete document without a visible error. The last case is particularly consequential: a downstream retrieval, compliance, or extraction system may treat the partial output as complete.
This benchmark does not establish that Unlimited-OCR 2 is unsuitable for production or that SGLang is generally unreliable. It does establish a useful engineering posture for self-hosted OCR: test the exact runtime, hardware, request size, and truncation defaults that will operate in production. For a 16 GB deployment, document-length policy and output-completeness checks should be first-class design decisions rather than post-processing details.
What happens next
- Self-hosted OCR teams will add explicit page-count and output-completeness checks around long-document jobs. (3 months, 70%). Watch for: wrappers that compare requested, processed, and returned pages.
- Further community tests will separate model quality claims from runtime-specific memory behavior. (6 months, 65%). Watch for: benchmarks across GPU sizes and inference back ends.
Limits and uncertainty
This is one independent benchmark on one RTX 4070 Ti SUPER environment, not a vendor-wide or hardware-wide certification. The real-document quality result covers 20 selected pages from one Chilean central-bank report; it does not establish accuracy across handwriting, dense tables, forms, multilingual documents, or image-heavy PDFs. The benchmark uses character error rate, which does not fully assess layout preservation or structured extraction quality. The author also reports that the GPU was shared and explicitly cautions that the SGLang failure may be specific to the environment. The results therefore bound a configuration, not the model’s maximum possible performance.
Skill to build now
Create a long-document acceptance test for the OCR stack you actually deploy. Include a known page count and reference text where possible, record peak VRAM and latency by document length, and reject a job when returned pages or extracted-character totals fall unexpectedly below the input. Run the same fixture through the intended inference backend, not only through a notebook or a one-page smoke test.
Reader takeaway
Unlimited-OCR 2 was highly accurate in this local comparison, tying Chandra 2 on the tested real report. But a strong OCR score does not validate the operational claim implied by its name: on this 16 GB setup, long documents exposed memory exhaustion, a hanging window mode, and silent partial output. Treat completeness and resource behavior as part of OCR correctness.
Open question
Can Baidu’s recommended SGLang path reproduce constant-memory long-document processing on a clean dedicated environment while reliably reporting truncation or incomplete output?