MiniCPM-OCR-1.0, Xiaomi-OCR-0, and Unlimited-OCR-2: three domestic…

Side-by-side comparison of three OCR models newly released by Chinese teams

@OpenBMB @XiaomiTech_ @Baidu_Inc each released their latest OCR models: MiniCPM-OCR-1.0, Xiaomi-OCR-0, and Unlimited-OCR-2. All three have strong OCR capabilities but each has its own focus, so let's break them down.

MiniCPM-OCR-1.0 (1.3B) Built on MiniCPM-V 4.6: SigLIP + Qwen3.5 as the base, focused on Chinese/English document parsing quality × page throughput. Real5 - 93.68, OmniDoc v1.6 - 96.51, Wild - 92.39, olmOCR - 82.7, OCRBench v2 - 54.7, throughput 1.217 pages/s

Xiaomi-OCR-0 (0.8B) Built on Qwen3.5-0.8B-Base as the base, focused on single-page parsing + OCR-oriented understanding (VQA/KIE). Real5 - 95.24, OmniDoc v1.6 - 96.83, Wild - 87.94, five OCR-VQA leaderboards - all 83.2, throughput 0.724 pages/s

Unlimited-OCR-2 (3B/A0.5B) Built on DeepEncoder + MoE decoder, with v2 replacing all layers with SR-SWA as the base, focused on "one-pass reading" of ultra-long documents, and self-proposed MarathonDocBench. MPDocBench Overall - about 84.6, MarathonDocBench - 77.06, throughput 0.246 pages/s

How to choose (by scenario) · Single page/few pages, wanting quality and understanding (QA, field JSON), tight VRAM: look first at Xiaomi-OCR-0, smallest parameter count, Real5 / OmniDoc self-reported as among the strongest tier, and native KIE/VQA. · Batch pipelines, wanting pages/s, wanting SDK/quantization/QC closed loop: look first at MiniCPM-OCR-1.0, highest throughput in the same comparison, Wild + complete layout pipeline, Jev is suited to "pass through a gate after parsing". · Contracts/books/papers parsed in one pass, cross-page tables and text must not break: look first at Unlimited-OCR-2, it's a different track altogether; pitting its OmniDoc single-page score head-to-head against the other two isn't very meaningful.

# Breakdown of each model's selling points

MiniCPM-OCR-1.0: parsing pipeline + speed and engineering completeness Task scope is clearly stated: text, tables, formulas, charts, seals, KIE; the pipeline is model + PP-DocLayoutV3 + minicpmvocr SDK (layout first, then chunking, then Markdown assembly). On the vision side, 4× compression, scale_resolution 448, up to 9 tiles. Compared with Xiaomi: OmniDoc v1.6 slightly lower (96.51 vs 96.83), Real5 slightly lower (93.68 vs 95.24), but Wild clearly higher (92.39 vs 87.94), and the official notes that the Wild score includes SDK rotation correction, so be careful when comparing across models. OCRBench v2 54.7 is the "general recognition" number it emphasizes. Throughput leads in the OpenBMB same-comparison table; in the same table Xiaomi and Unlimited-OCR2 are about 0.59× / 0.20× of it respectively. Also comes with MiniCPM-OCR Jev: it doesn't parse, only judges right/wrong and gives a probability, for automatic pass / human review triage. Fine-tuning paths listed are LLaMA-Factory and ms-swift.

Xiaomi-OCR-0: small parameter count ties "parsing" and "reading comprehension" together Training claims about 170 million OCR-oriented samples: Q-Mask anchoring → OCR-oriented CPT → Mix-RL. The data engine uses multi-expert consensus (ETC), render-and-rejudge, and failure-driven synthesis; the expert pool names PaddleOCR-VL-1.5/1.6, MinerU2.5-Pro, GLM-OCR, TeleOCR, OvisOCR2, etc. Selling points: one set of weights covers full-page Markdown (tables in OTSL, formulas in LaTeX), region text/tables/formulas, and schema-based KIE. On benchmarks Real5 beats open-source models of the same tier; OCR-VQA five-leaderboard average 83.2, higher than same-size Qwen3.5-0.8B (72.9) and larger Qwen3.5-2B (80.9), still below Qwen3.5-4B (84.9); the report itself also says: understanding is more parameter-hungry than parsing. Handwriting/calligraphy Chronicles-OCR mature script style is about 73, on the same order as Seed 2.0 Pro (72). The community already has GGUF, but the official does not endorse quantized accuracy.

Unlimited-OCR-2: collapsing the "page loop" into a single forward pass The problem statement is clear: conventional end-to-end OCR loops page by page, and KV grows as output lengthens; a human copying a book only watches the current passage. v1 uses R-SWA (always sees all visual reference tokens, while the output side only slides a window over the most recent n, default 128), continued training on DeepSeek-OCR with about 2M document samples, a big gain over baseline on OmniDoc, and claims dozens of pages in one go. v2 adds SR-SWA: compressing text-vision interaction over ultra-long sequences into a fixed-size working reference (e.g., 512 tokens), making step-by-step decoding latency and VRAM approximately independent of document length; at the hundred-page scale it claims about 7.0× / 5.6× step-by-step speedup over Full Attention / R-SWA. It comes with MarathonDocBench (100–300 pages, denser cross-page text/tables), Overall 77.06; the shorter multi-page benchmark MPDocBench is about 84.6. For inference, single-page defaults to gundam dynamic chunking, multi-page base uses a global one-page-one-view; on the SGLang side there is page-window scheduling and a large number of VRAM knobs. The cost: it's on the slow side in the same "single-page throughput" race, and engineering depends on a custom serving stack, not as "out-of-the-box multi-backend" as MiniCPM.