Self-hosting
MiniCPM-OCR 1.0 + Jev: Self-Hosting SOTA Document Parsing, Verified
Verdict: OpenBMB's MiniCPM-OCR 1.0 is the rare release where the license is cleaner than the hype. A 1.3B-parameter parser claiming SOTA on Real5-OmniDocBench (93.68), an OCRBench v2 score of 54.7, day-one support for vLLM, SGLang, llama.cpp, and Ollama, and — unlike the license-minefields we covered last week (Hi3D's custom tollbooth, H3's $20M trigger clause) — plain Apache 2.0 for code, docs, and weights. The smarter play in the box is actually the sidekick: MiniCPM-OCR Jev, a 2B quality judge that scores OCR output region-by-region and nearly matches a 397B model at the task (AUROC 93.6 vs 93.8). If you run document pipelines, parse with the 1.3B model and let Jev auto-waive the clean pages; on legal documents the official review-free accuracy curves suggest most pages never need human eyes. My honest caveats: the benchmarks are the vendor's own numbers, and the oft-quoted "1.217 pages/second" figure doesn't appear in the README — treat it as marketing until you benchmark your own scans.
ModelBest released MiniCPM-OCR 1.0 (1.3B) and MiniCPM-OCR Jev (2B) on October 28, 2026, through the OpenBMB open-source program. The parsing model handles Chinese and English documents and PDFs — scans, photos, curved pages, skewed captures, recaptures — covering text, tables, formulas, charts, seals, and structured extraction. It is the first OCR-specific model in the MiniCPM-V/o family. is the release date stated across the official channels.
The benchmarks, verified against the README
The GitHub README claims a SOTA 93.68 on Real5-OmniDocBench plus leading scores on OmniDocBench v1.6, Wild-OmniDocBench, and olmOCR-Bench, and a SOTA 54.7 on OCRBench v2. Those two numbers are in the official text, so I stamp them verified-as-claimed — but they are still the vendor running the vendor's homework. The README also admits some radar-chart values "remain to be confirmed," which is a refreshing amount of honesty for a launch post.
On throughput, the DSpark decoding acceleration (shipped as both BF16 and GGUF weights) is claimed to improve end-to-end efficiency by 55%, with about 1.49× the throughput of PaddleOCR-VL-1.6 and 3.62× that of MinerU2.5 Pro. The Chinese-language announcement's "1.217 pages/second" figure does not appear anywhere in the official README — I'm citing it as a transcribed claim, not a verified one.
Jev is the interesting one
The parsing model is good; the judge model is the part I'd actually build a pipeline around. MiniCPM-OCR Jev takes an image plus its OCR output and returns a 0-to-1 quality score per region — it flags which parts of a parsed page look wrong rather than re-parsing anything. At 2B parameters it hits AUROC 93.6 on JevOCRBench, beating JEV-35B-A3B (90.1) and within a whisker of Qwen3.5-397B-A17B (93.8). The part that makes it pipeline-grade: the README reports consistent generalization (AUROC 91.9–93.4) when judging output from MiniCPM-OCR 1.0, GLM-OCR, PaddleOCR-VL-1.6, and Xiaomi-OCR-0 — so you can bolt it onto a parsing stack you already run.
The official "review-free accuracy" curves show accuracy at different auto-acceptance rates across legal documents, financial receipts, and complex documents. The public commentary rounds this to "85% of legal documents skip review," but the exact figure lives inside a chart image, not the text — treat the 85% as the vendor's story and calibrate the threshold on your own documents.
Self-hosting math
Deployment is where this release quietly wins. The 1.3B parser runs on vLLM, SGLang, llama.cpp, and Ollama from day one, with quantized and DSpark-GGUF variants published at launch — at this size, a single consumer GPU (or even CPU-plus-patience via llama.cpp) is plausible, though I haven't run it myself and won't pretend I did. There's a pip SDK (minicpm-ocr), a free hosted API on ModelBest's platform if you'd rather not self-host, and SKILL.md files written for coding agents to deploy and verify the stack autonomously. Apache 2.0 across the whole project means no MAU thresholds, no revenue triggers, no attribution clauses — a stark contrast to the Hi3D Open License and MiniMax's H3 community license I dissected last week.
Who should care: teams digitizing scan-heavy archives (the curved-page and recapture handling is the differentiator versus classic Tesseract-style stacks), RAG pipelines that need tables and formulas as structured text, and anyone already paying per-page cloud OCR fees on documents that never leave their compliance boundary. Who shouldn't: anyone expecting a 1.3B model to beat a 30B generalist on gnarly handwriting — the benchmark suite is document parsing, not penmanship.
against official sources: OpenBMB/MiniCPM-OCR GitHub README and LICENSE — Real5-OmniDocBench 93.68, OCRBench v2 54.7, DSpark +55% efficiency / 1.49× PaddleOCR-VL-1.6 / 3.62× MinerU2.5 Pro, Jev 2B AUROC 93.6 (vs JEV-35B-A3B 90.1, Qwen3.5-397B-A17B 93.8), cross-parser AUROC 91.9–93.4, vLLM/SGLang/llama.cpp/Ollama day-one support, Apache License 2.0 for code, documentation, and weights. Reported (transcribed): "1.217 pages/second" throughput and "85% legal-document review-free" figures from the vendor's Chinese-language announcement coverage; not present in the official README text.
Caveat (dated 2026-11-01): All benchmark scores are the vendor's own published numbers, not independently reproduced. VRAM footprint claims for consumer hardware are my inference from parameter count, not measurement. Accuracy is as of publication date — check the official repo for updates.
Related reading: Hi3D V1.0 license breakdown (the contrast case), H3-Regenerate self-hosting analysis, EdgeRock-4B constant-memory KV cache.