Baidu OCR runs all 270 pages of an 1899 pharmacopoeia in one pass, but gets stuck on 3 dense tables

An 1899 pharmacopoeia scan page: on the left is yellowed paper, on the right is the model’s re-laid-out text on a white background, with green boxes circling each entry block. On X, Maziyar Panahi put the entire 270-page Merck 1899 Manual of the Materia Medica into a single request and ran it on one A100. It took 45 minutes, with decoding at about 217 tokens/s. The last few pages were about as fast as the first page. Of the 270 pages, 262 were clean; 3 dense tables produced loops, and the page after the loop returned blank. In the pharmacopoeia, the cocaine entry lists morphine as an antidote. The 1899 dosage is not medical advice.

Baidu named this model family Unlimited OCR 2. It is open source, MIT-licensed, and has 3B parameters. The pain point it aims to solve is long-document parsing: in decoding, traditional attention has to scan an ever-longer KV cache for each new token, so as page count grows, latency and GPU memory rise together. KV cache can be thought of as the context cache retained during decoding. SR-SWA compresses the attention interaction between text and vision into a fixed-size working reference, for example 512 tokens, sparsely attends only to the most relevant visual regions on the current page, and releases KV cache that is no longer needed. The official claim is that per-step decoding latency and memory usage barely grow with document length.

In the official benchmark, Unlimited OCR 2 scores 84.6 overall, ahead of Qwen3.8-Max at 78.3; for 100-page documents, each decoding step is 7.0x faster than Full Attention and 5.6x faster than R-SWA; and parsing accuracy is maintained within 300 pages. It is SOTA on both MPDocBench and MarathonDocBench. The data comes from Baidu’s own model card and GitHub, not from an independent evaluation. Maziyar’s 270-page pharmacopoeia test adds another side: the speed curve is indeed flat, but the failure modes of real documents are not captured by benchmark averages.

Someone in the comments warned that releasing cache may still drop rare annotations. That concern is not unfounded. The hard part of long-document OCR is shifting from can it read at all to will it loop on dense tables. Three tables does not sound like much, but in scenarios such as archival digitization, financial reports, pharmacopoeias, and scanned medical records, one stuck table can leave an entire later page blank. The official service stack adds no-repeat n-gram and a page-count guard by default, available in SGLang and vLLM; llama.cpp does not have them, so community GGUF converter RX5950XT explicitly writes in the model card that a very small number of pages may loop and that -n should be used to limit output.

Do not assume local deployment will be smooth either. Someone converted Unlimited OCR 2 to GGUF: Q8_0 is 2.92GiB, Q4_K_M is 2.01GiB, and the vision projector is 787MiB. But it requires patching llama.cpp; the mainline currently supports only v1, and LM Studio and Ollama cannot load it directly. The converter tested running v2 as v1: a 3-page document became garbled starting from page 2, with character similarity of 25.4%; full attention plus ordinary RoPE gave only 5.6%. This is not something a different quantization file will fix.

Baidu has clearly done the accounting for long-document parsing: fixed working set, release KV cache, and keep latency and memory from growing linearly with page count. This direction is right. Maziyar’s test also shows that a single request for 270 pages can already produce usable results, at the cost of 3 dense tables. The next thing to examine is whether failed pages can be located, retried, skipped, or handed to another model to fill in. A few tenths higher on an average score is less useful than clearly explaining the failed pages. If you have a scan that no one wants to touch, do not first ask whether the model can read it; first ask on which page it will start looping.