Most document tools hand you a finished transcript and ask you to trust it. MiniCPM-OCR does something rarer: it reads the document, then a second model checks the reading, region by region, and tells you which parts still need a human eye. ModelBest and OpenBMB announced the MiniCPM-OCR series as open source on October 31, 2026. The series pairs a 1.3 billion parameter document parser, MiniCPM-OCR 1.0, with a 2 billion parameter correctness checker, MiniCPM-OCR Jev (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01). Together they turn document digitization into a review queue: reliable regions pass automatically, and only uncertain ones reach a person.
Key Takeaways
MiniCPM-OCR 1.0 is a 1.3 billion parameter open source model that parses Chinese and English documents, PDFs, scans, and photographs into text, tables, and formulas.
MiniCPM-OCR Jev is a 2 billion parameter checker that scores OCR output region by region from 0 to 1, so pipelines can auto-accept reliable regions and route the rest to review.
The parser reports 93.68 on Real5-OmniDocBench and 54.7 on OCRBench v2, with throughput of 1.217 pages per second on a single RTX 5090, all vendor-reported figures to treat with care.
Both models are released under the Apache License 2.0, including code, documentation, and weights, and run locally through vLLM, SGLang, llama.cpp, and Ollama.
Jev works with output from any OCR engine, not just MiniCPM-OCR 1.0, so teams can add a quality check without replacing their current parser.
The launch arrived in two beats. The repository went public on GitHub on October 27, 2026, and the joint ModelBest and OpenBMB announcement followed on October 31, 2026. By November 1, 2026, the repository had gathered 719 stars and 48 forks, with 112 commits (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01).
What Is MiniCPM-OCR?
Optical character recognition (OCR) is the task of turning pictures of text into machine-readable text. Document parsing goes further: it recovers structure as well, so tables stay tables, formulas stay formulas, and reading order survives. MiniCPM-OCR is a family of models for efficient document parsing and text recognition, and MiniCPM-OCR 1.0 is its first OCR-specific model in the MiniCPM-V family (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01). It handles Chinese and English documents and PDFs, including scans, photographs, curved pages, skewed pages, and screen-captured documents.
The model covers more than plain paragraphs. It reads text, tables, formulas, charts, and seals, and it supports key information extraction, pulling named fields from invoices, IDs, and financial statements (ModelBest and OpenBMB announcement).
Aspect | MiniCPM-OCR series |
|---|---|
Announced | October 31, 2026, by ModelBest and OpenBMB |
Repository public | October 27, 2026 |
Models | MiniCPM-OCR 1.0 (1.3B parser) and MiniCPM-OCR Jev (2B checker) |
Languages | Chinese and English |
License | Apache License 2.0 for code, documentation, and weights |
Local backends | vLLM, SGLang, llama.cpp, Ollama |
Repository, November 1, 2026 | 719 stars, 48 forks, 112 commits |
How the Parser Works
A document pipeline has three jobs: find the regions, read them, and reassemble them in order. MiniCPM-OCR 1.0 follows that shape. A layout model detects regions and reading order. The recognition model reads each cropped region. Results are assembled into Markdown in reading order, with tables converted to HTML and formulas kept as LaTeX, according to independent analysis of the release.
Speed comes from a decoding accelerator called DSpark. With DSpark decoding acceleration, the project reports an end-to-end processing efficiency improvement of 55 percent (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01). That is a vendor figure, not a guarantee for every document.
Meet Jev, the Checker
MiniCPM-OCR Jev is an OCR correctness decision model for text, formulas, and tables. Given an image and its corresponding OCR result, it returns a quality score from 0 to 1 to help select reliable results and locate content that needs review (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01). A higher score means the candidate is more likely correct. Jev does not re-read the page from scratch: it compares the original region crop against the candidate text and an image rendered from that candidate, so it can judge output from any parser.
That design enables three ways of working. First, threshold auto-acceptance: score every region, pass the ones above your threshold, and send the rest to a reviewer. Second, best-of-N selection: let several parsers read the same region and keep the highest-scoring candidate. Third, batch selection across blocks, assembling a whole document from the best candidates in reading order, as described in independent analysis of the release. The threshold is not set-and-forget: the project's own chart shows thresholds between 0.984 and 0.995 producing review-free shares from 35 percent to 85 percent depending on document type. Tune it on your own documents.
One detail matters before deployment. The scoring service returns a verdict alongside the score, and only scored means the model actually ran. Other failures return fixed values that must not be read as low scores, according to independent analysis of the release. A pipeline that ignores the verdict will silently treat a broken request as a failed document.
For example, a finance team scanning supplier invoices could auto-accept every region scoring above its threshold and send only low-scoring totals and dates to a reviewer. That turns a full manual check into a short exception queue. Consider a university library digitizing a thesis archive: the same routing lets staff focus on damaged pages and handwritten notes, not clean pages the model already read correctly.
How This Article Was Checked
The methodology for this article was straightforward: start from the project's README and the joint announcement, cross-check every headline number against independent analysis, and label vendor-reported figures as such. Where sources framed a number differently, such as the MinerU2.5 Pro configuration behind the 3.62 times figure, this article reports both configurations.
What the Benchmarks Say, and What They Do Not
On the vendor's numbers, MiniCPM-OCR 1.0 scores 93.68 on Real5-OmniDocBench, a benchmark built around hard real-world captures, and 54.7 on OCRBench v2 for general OCR ability (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01). Independent analysis adds the fuller picture: 92.39 on Wild-OmniDocBench, 96.51 on OmniDocBench v1.6, and 82.7 on olmOCR-Bench, for an equal-weight average of 91.32 across the four parsing benchmarks (Flowtivity analysis). The lead over the next model that reports all four, Xiaomi-OCR-0 at 90.93, is 0.39 points: a lead, not a rout.
Jev's numbers are stronger in relative terms. With only 2 billion parameters, it reaches an AUROC of 93.6 on JevOCRBench, ahead of a 35 billion parameter rival at 90.1 and near a 397 billion parameter model at 93.8 (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01). AUROC is a standard measure of how well a scoring system separates correct results from incorrect ones. Across output from four different OCR engines, Jev's AUROC ranges from 91.9 to 93.4, supporting the claim that it generalizes across parsers.
Two caveats belong with the praise. First, every benchmark figure here is vendor-reported, and the repository's own benchmark file marks several rows as pending confirmation (Flowtivity analysis). Second, the vendor does not report a CHAOS-Bench score for its own model, while every other model in its comparison table has one. A team choosing an OCR engine should run its own documents through the demo and the free API before trusting any chart.
How Fast Is It?
OpenBMB measured throughput on one NVIDIA GeForce RTX 5090, using all 1,651 images in OmniDocBench v1.6 at image-level concurrency of 1, with each system accelerated. MiniCPM-OCR 1.0 reached 1.217 pages per second: 1.49 times PaddleOCR-VL-1.6 at 0.818 pages per second and 3.62 times MinerU2.5 Pro at 0.336 pages per second in its Advanced configuration (Flowtivity analysis). The project reports approximately the same ratios on its own README (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01).
Read the fine print before sizing a queue. The 3.62 times figure is against MinerU2.5 Pro in its Advanced configuration; against its Standard configuration at 0.531 pages per second, the gap is 2.29 times. The closest rival, GLM-OCR at 1.179 pages per second, is within 3 percent of MiniCPM-OCR 1.0 (Flowtivity analysis). At concurrency 8 on the same card, throughput rises to 2.133 pages per second, roughly 7,700 pages an hour, but real throughput will move with page content, backend, concurrency, and hardware.
How to Run MiniCPM-OCR
Start with the repository's skill files, which walk a coding agent through setup, model download, and a first parse, for both the parser and Jev (OpenBMB/MiniCPM-OCR, GitHub, retrieved 2026-11-01). For local deployment, the parser supports vLLM, SGLang, llama.cpp, and Ollama from day one, with GGUF, AWQ, and GPTQ quantized builds published at release. The combined footprint is about 3.5 billion parameters, which fits on a single 24GB GPU, and GGUF builds allow CPU-only runs (Flowtivity analysis).
Expect installation friction on a first deployment. The project's FAQ documents real failure modes. CUDA 13 needs a driver at version 580 or newer. The SDK and inference environments need at least 20GB of disk. Parsing hangs unless vLLM is started with a specific trust flag for multimodal keyword arguments (Flowtivity analysis). Day-0 hardware adaptation covers AMD, Arm, Intel, and NVIDIA, plus AI and edge chips through the FlagOS stack, including Apple Mac on Arm (ModelBest and OpenBMB announcement). Nothing in the pipeline requires a cloud call.
Who Should Use It, and Who Should Not
MiniCPM-OCR 1.0 fits if your documents are Chinese or English, if a meaningful share arrives as photos or scans rather than clean PDFs, if the data cannot leave your network, and if you want review routing rather than a single trust-me output. It is a poor fit if you need broad multilingual coverage out of the box, already run a cloud OCR service with a service-level agreement, or if the degradation cases that CHAOS-Bench measures are central to your workload. The vendor has not published its own score there.
The sleeper play is Jev on its own. Because it scores candidates from any parser, a business can keep its current OCR engine and add a 2 billion parameter checker on top, delivering a review queue without a migration. For a different trade-off, our Baidu Unlimited OCR 2 article covers a long-document parser that reads a whole book in one pass, rather than checking quality region by region.
Frequently Asked Questions
Is MiniCPM-OCR free? Yes. The entire project is released under the Apache License 2.0, including code, documentation, and weights. Your costs are the hardware you run it on, or the free API and demo. For what open source means in practice, see our What Is Open Source? explainer.
What is the difference between MiniCPM-OCR 1.0 and Jev? MiniCPM-OCR 1.0 is the parser: it reads documents into text, tables, and formulas. Jev is the checker: it scores a parser's output region by region from 0 to 1, so you know which regions to trust and which to send to a reviewer. Jev does not perform OCR itself.
Can Jev check output from a different OCR engine? Yes. Jev compares a region image against a candidate OCR result, so it works with output from MiniCPM-OCR 1.0, GLM-OCR, PaddleOCR-VL-1.6, Xiaomi-OCR-0, and other parsers.
Can I run MiniCPM-OCR on my own hardware? Yes. Both models run locally through vLLM, SGLang, llama.cpp, or Ollama, with quantized GGUF, AWQ, and GPTQ builds. The pair totals about 3.5 billion parameters and fits on a single 24GB GPU, and GGUF builds allow CPU-only runs. Budget at least 20GB of disk.
Should I replace my current OCR stack with MiniCPM-OCR? Not on benchmarks alone. Run your own documents through the demo first. Tune a Jev threshold on a small batch. Check the failure modes that matter to you, especially multilingual coverage and CHAOS-Bench-style degradation, where the vendor has not published its own score. If you only need a quality check, adding Jev to your existing parser is the smaller, safer change.
The Bottom Line
MiniCPM-OCR is not the most spectacular AI release of the week, and that is its strength. A 1.3 billion parameter parser reads messy scans. A 2 billion parameter checker admits which regions it is unsure about. Together they solve a costly unglamorous problem: a wrongly parsed invoice line flowing into a ledger and being treated as fact. The benchmarks are promising, the caveats are public, and the Apache License 2.0 release means any team can test the pair first. Start with the GitHub repository and the joint ModelBest and OpenBMB announcement, or read the Indonesian version of this article.