Unlimited OCR 2 parses a whole PDF in one call, and one setting decides whether you can trust it
Unlimited OCR 2 read a 59-page guide in 3 min 44 s, 4.2% off its text, with page tiles off. With tiles on: 38.1%.
Same model, same card, same 59 pages. With the authors' default image setting, the run took 6 min 45 s and came back 38.1% off the PDF's own text. With one flag changed, crop_mode=false, it took 3 min 44 s and came back 4.2% off. The model is Unlimited OCR 2, a document parser Baidu released under MIT. It takes a whole PDF in one request instead of one page at a time, so text that crosses a page break can stay connected. For anyone who turns PDFs into data for search or an assistant, that is the part page-by-page tools get wrong. What you can do with it: parse long reports and manuals on a single 16 GB card, as long as you switch the page tiles off.
Pages 46 to 54 alone, one card. Left, the default tiles. Right, one view per page: six times faster, no repeated sentence.
A parser that reads a document, not a pile of pages
Most PDF pipelines split the file into pages, read each one alone and glue the text back together. Anything that crosses a page break gets cut. A table that spans two pages becomes two tables, and the second has no header.
Unlimited OCR 2 reads several pages together. Showing a model many pages at once is usually expensive, since every page is a picture. Baidu's trick, per the model card, is to keep only a fixed number of image pieces in view however long the document is. By the authors' account, each new word costs about the same on page 3 as on page 300.
The model is small, 6.7 GB on disk. The license allows commercial use. Credit goes to Baidu's team, led by core contributors Shu Wei, Jingjing Wu and Qunyi Xie, who built on their first Unlimited OCR and on DeepSeek-OCR. They also shipped a patched build of SGLang, the open serving framework, with a full recipe. Our part was packaging that server behind an API and testing it on a real document.
What our test found
IRS Publication 15, the US employer's tax guide, is 59 pages, public domain, with paragraphs crossing page breaks on most pages and one table running from page 46 to page 52. We sent the whole PDF in one request on one RTX 4090, a 24 GB gaming card on our cloud, and scored the output against the PDF's own text layer: the share of characters you would have to change, 0% meaning identical.
The setting that matters is how each page is shown to the model. The default cuts every page into zoomed-in tiles on top of one overview picture. crop_mode=false shows only the overview.
| 59-page PDF, one request | Page tiles (default) | One view per page |
|---|---|---|
| RTX 4090, whole document | 6 min 45 s | 3 min 44 s, 15.8 pages/min |
| Distance to the PDF's text | 38.1% | 4.2% |
| RTX 2000 Ada 16 GB, real card | not run on all 59 pages | about 10 and a half minutes, 4.23% |
On running text both modes were good: leave the table pages out and both sat around 2.4% off, two or three characters in every hundred. The gap is the table. In tile mode, page 46 squeezed eight rows into one cell, then wrote one sentence, "Taxable if wages subject to social security tax and Medicare tax", 1,508 times. A looper pedal nobody switched off. Pages 47, 50 and 52 came back empty. Pages 46 to 54 sent alone looped the same way, so this is model behaviour, not a memory accident.
With one view per page, the table came back as HTML in seven pieces, one per page. The difference from a page-by-page parser is the tags: five of the six joins carry a tag that marks the piece as a continuation. Those tags are what a program needs to stitch it back into one.
A small card holds up. A real RTX 2000 Ada, a 16 GB workstation card that draws 70 watts, read the whole guide with one view per page at 5.6 pages a minute, peaking at 13.8 GB. Its quality matched the 4090's.
Who should care
- Teams that parse long reports, manuals or contracts where tables and paragraphs cross pages. One request per document returns text, positions and cross-page tags under a license that allows commercial use.
- Anyone with long tables. Set
crop_mode=false, then check the numbers on the table pages: five of them were still 20% to 46% off. - Anyone who keeps tiles on. Keep the default 10-page windows and count the pages that come back. In tile mode, one window for the whole document ran out of room and stopped mid page 27 without an error.
- Teams on small cards. 16 GB was enough for a document like ours.
On InferenceKey there is no ready-made support for this model, because it needs Baidu's patched server. We wrote a custom backend, a short Python file that installs and runs it on your GPU machine, and your app calls it the way it calls OpenAI's chat API. It was ready in 61 to 143 seconds with the files cached.
The honest limit, once: this was one English document of 59 clean digital pages, read once per setting, so scans are untested and the hundreds of pages the authors target are their claim, not our measurement.
The full test
The Research post has the per-page scores, the VRAM ladder, the platform rough edges and the SDK example. Read the full Unlimited OCR 2 test.