MiniCPM-OCR 1.0: A Free 3.5B Pair That Reads Messy Scans And Flags Its Own Mistakes

Last Updated: 28 October 2026

On 27 October 2026, OpenBMB released MiniCPM-OCR 1.0, a 1.3B model built only for reading documents, plus a companion checker called MiniCPM-OCR Jev. A post by @sudoingX about the launch chart drew 11,516 views, 243 likes and 286 bookmarks in its first day, and the GitHub repository collected 83 stars within 24 hours of going public. The Hugging Face weights had already been downloaded 791 times by the time this post was written.

The reason to care is not the benchmark chart. It is that a 1.3B parser and a 2B checker together total about 3.5B parameters, which means document intake is now one of the few AI jobs where a small local model is unambiguously the right call. When a business can parse contracts, invoices and receipts on hardware it owns, and score every region so it knows which parts a person still has to check, the document pipeline stops being a leap of faith.

What is MiniCPM-OCR 1.0?

MiniCPM-OCR 1.0 is a 1.3B parameter vision-language model specialised for document parsing and text recognition, released by OpenBMB under Apache 2.0. According to the model card, it is the first OCR-specific model in the MiniCPM-V family, trained for OCR on top of MiniCPM-V 4.6, and it pairs a SigLIP vision encoder with a Qwen3.5 language model. It reads text, tables, formulas, charts and seals, and can pull named fields straight out of an image for downstream automation. Its primary languages are Chinese and English.

The architecture is deliberately narrow. Visual tokens are compressed four times at a resolution of 448 pixels with up to nine slices, which keeps the token count low enough for a small model to run quickly. The parsing pipeline is not one model but three parts: the recognition model, the PP-DocLayoutV3 layout model, and the minicpmvocr SDK that orchestrates them. The SDK and the inference service run in separate Python environments and can sit on different machines, which is worth knowing before you plan a deployment.

The workflow is straightforward. The SDK reads a PDF, PNG or JPG and rasterises PDF pages. PP-DocLayoutV3 detects document regions and reading order, then crops them. The crops go to the recognition service concurrently, and the results are assembled into Markdown in reading order, with tables converted from OTSL to HTML and formulas kept as LaTeX. Region type is set by the prompt: Text Recognition:, Table Recognition:, Formula Recognition:, Seal Recognition: or Chart to Table:.

What is MiniCPM-OCR Jev?

MiniCPM-OCR Jev is a 2B OCR correctness decision model. Given one region image and a candidate OCR result for that region, it returns a score from 0 to 1, where a higher score means the candidate is more likely correct. It is trained from Qwen3.5-2B with the vision encoder and language backbone retained, and the language model's output head replaced by a binary classification head that learns whether a candidate is right or wrong. It works on output from any parser, not just MiniCPM-OCR 1.0.

The input is unusual and worth understanding. Jev does not read the page and re-OCR it. It receives the original region crop, the candidate text, and an image rendered from that candidate text. That means it is comparing what the page shows against what the parser claims, rather than guessing independently. The practical consequence is that Jev can only choose among candidates that exist: if every parser missed a table cell, Jev has nothing better to pick.

There are three ways to use it. First, threshold auto-acceptance: score every region, pass the ones above your threshold, and send the rest to a human reviewer. Second, best-of-N within a region: let several parsers read the same crop and keep the highest-scoring candidate. Third, batch selection across blocks, so a whole document is assembled from the best candidates in reading order. According to OpenBMB's model guide, a higher threshold typically reduces the share of results that pass automatically, so the accuracy of auto-accepted regions and the volume of human review have to be watched together.

One operational detail matters more than it looks. The service returns a verdict alongside the score, and only scored means the model actually ran. Precheck, rendering or forward-pass failures return fixed values that must not be read as low scores. A pipeline that ignores the verdict will silently treat a broken request as a failed document.

What do the benchmark numbers actually say?

MiniCPM-OCR 1.0 reports 93.68 on Real5-OmniDocBench, 92.39 on Wild-OmniDocBench, 96.51 on OmniDocBench v1.6, 82.7 on olmOCR-Bench and 54.7 on OCRBench v2. Across the four parsing benchmarks it reports, its equal-weight average is 91.32. The only other model in the vendor's table that reports all four is Xiaomi-OCR-0, at 90.93, so the lead on the combined score is 0.39 points. On the standard OmniDocBench v1.6 it sits 0.32 points behind Xiaomi, not the 0.4 quoted in the launch thread.

Model	Real5-OmniDocBench	Wild-OmniDocBench	OmniDocBench v1.6	OCRBench v2
MiniCPM-OCR 1.0	93.68	92.39	96.51	54.7
Xiaomi-OCR-0	92.73	92.06	96.83	47
PaddleOCR-VL-1.6	93.188	91.49	not reported	35.2
GLM-OCR	not reported	90.4	not reported	45.5
MinerU2.5-Pro	not reported	90.06	not reported	29.1
HunyuanOCR-1.5	88.542	87.01	94.74	45

The headline claim holds where it matters most for messy real-world input. Real5-OmniDocBench is built around hard captures, and Wild-OmniDocBench is built around uncontrolled ones, which is where phone photos of contracts at an angle and curved book pages land. MiniCPM leads both, by 0.95 and 0.33 points respectively. Its biggest margin is on OCRBench v2, where 54.7 sits 7.7 points ahead of Xiaomi and 19.5 ahead of PaddleOCR-VL-1.6.

Two gaps are worth stating plainly. The vendor does not report CHAOS-Bench for its own model, while every other model in the table has a value, including Xiaomi at 17.84 and MinerU at 13.9. And the machine-readable benchmark file that ships in the repository marks the MiniCPM, Paddle, GLM and MinerU rows as pending_confirmation, with a note that unresolved scores remain null. That is unusually honest housekeeping for a launch, but it does mean the table is not yet final.

How fast is it, and where does the 3.62x come from?

OpenBMB measured parsing 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's accelerated configuration. MiniCPM-OCR 1.0 reached 1.217 pages per second. That is 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. At concurrency 8 on the same card it reaches 2.133 pages per second, a 1.75 times speedup, which works out to roughly 7,700 pages an hour.

The comparison needs one clarification the launch thread left out. The 3.62 times figure is against MinerU2.5 Pro in its Advanced configuration. Against the Standard configuration at 0.531 pages per second, the gap is 2.29 times. Both are real, but a buyer sizing a queue should know which one they are being quoted. GLM-OCR is the closer rival: at 1.179 pages per second it is within 3 percent of MiniCPM, so "fastest" here is a nose, not a gulf.

OpenBMB is also candid about what the throughput test does not settle. The model guide states that "the exact timing boundaries remain to be documented", and that concurrency 1 is image-level only, meaning regions inside a page still run in parallel. Real throughput will move with page content, backend, concurrency and hardware. The numbers are directionally useful, not a service-level guarantee.

Why region-level confidence changes a document pipeline

Most OCR tools return one answer per page and leave the reader to decide whether to trust it. Jev changes the shape of that output: every region carries a score, so a pipeline can be split into three lanes. Regions above the threshold proceed automatically. Regions below it go to a person. Regions where several parsers disagree get re-picked by score. According to OpenBMB's evaluation, Jev-based re-picking of low-confidence blocks gains up to 0.38 points of parsing quality over each model parsing every block on its own.

The routing behaviour is the part that changes operating cost. On the vendor's review-free chart, thresholds between 0.984 and 0.995 produced review-free shares from 35 percent to 85 percent depending on whether the documents were legal contracts, financial receipts or complex mixed pages. That spread is the whole argument for tuning a threshold on your own documents rather than adopting a default: the same model, the same threshold, very different amounts of human review depending on what you feed it.

In our client work, the failure that costs money is never a badly parsed page sitting on its own. It is a wrongly parsed invoice line that flows into a quote or a ledger and is treated as fact downstream. A checker that names the suspect region turns that from a silent error into a visible queue item, and that is worth more than a benchmark point or two.

Can you run the pair locally?

Yes, and that is the point. Both models are Apache 2.0, including weights, code and documentation. The parser supports vLLM, SGLang, llama.cpp and Ollama from day one, with GGUF, AWQ and GPTQ builds published at release. The combined footprint is about 3.5B parameters, which fits comfortably on a single 24GB GPU, and the GGUF builds let the same pipeline run on CPU-only hardware when a GPU is not available. Nothing in the pipeline requires a cloud call.

The honest caveat is installation friction. The FAQ documents a long list of real failures: CUDA 13 needs a driver at 580 or newer, FlashInfer's first-run JIT needs nvcc on Blackwell cards including the 5090, the SDK and inference environments together need at least 20GB of disk, parsing hangs unless vLLM is started with --trust-request-mm-kwargs, video input must be disabled for this workflow, and direct API output returns tables in OTSL format unless the SDK post-processes them. None of this is a dealbreaker, but a first deployment is an afternoon, not fifteen minutes.

On our own dual DGX Spark setup, where we run DeepSeek V4 Flash at about 60 tokens per second, memory bandwidth is the constraint that bites, not parameter count. A 3.5B pair is a rounding error next to that workload. That is why document intake is one of the few jobs where a small local model is clearly the right answer: the task is narrow, the output is checkable, and the data is exactly the kind a business does not want to hand to an API.

Should you replace your OCR stack with it?

The decision is narrower than the launch thread suggests. MiniCPM-OCR 1.0 is the right choice if your documents are Chinese or English, if a meaningful share arrive 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 not the right choice if you need broad multilingual coverage out of the box, if you 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, because 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 the OCR engine it already runs and add a 2B checker on top. That is a smaller change than a full migration, it needs no re-indexing of the pipeline, and it delivers the review queue without asking anyone to trust a new parser on day one. For most teams, that is the cheaper and more defensible first step.

What would we test before recommending it to a client?

We have not run MiniCPM-OCR on client documents yet, so the benchmark table is the evidence base for now, and every number in it is vendor-reported. Before recommending it, we would run three checks. First, a real throughput test on our own hardware, because the published figure is one RTX 5090 at image concurrency 1 and our Sparks will behave differently. Second, a threshold sweep on the client's own document types, since the vendor's review-free chart shows the share of auto-accepted regions moving from 35 percent to 85 percent by document type. Third, a best-of-N test against the parser the client already uses, because that is where Jev earns its place without a migration.

Frequently asked questions

What is MiniCPM-OCR 1.0?
MiniCPM-OCR 1.0 is a 1.3B parameter open-weight model from OpenBMB, released under Apache 2.0, built specifically for document parsing and text recognition. It handles text, tables, formulas, charts and seals in Chinese and English, and it works as part of a three-part pipeline with the PP-DocLayoutV3 layout model and the minicpmvocr SDK.

How accurate is MiniCPM-OCR 1.0 compared with PaddleOCR-VL and MinerU?
On OpenBMB's published numbers, MiniCPM-OCR 1.0 scores 93.68 on Real5-OmniDocBench against 93.188 for PaddleOCR-VL-1.6, and 92.39 on Wild-OmniDocBench against 90.06 for MinerU2.5-Pro. On OCRBench v2 it scores 54.7 against 35.2 for Paddle and 29.1 for MinerU. All of these are vendor-reported results.

What is MiniCPM-OCR Jev and how does it work?
Jev is a 2B correctness decision model that takes one document region, a candidate OCR result for it, and an image rendered from that text, then returns a score from 0 to 1. Scores above your threshold are auto-accepted and the rest go to human review, or the highest-scoring candidate across several parsers is selected. It reaches AUROC 93.6 on JevOCRBench.

Can I run MiniCPM-OCR locally so documents never leave my network?
Yes. Both models are Apache 2.0 and support vLLM, SGLang, llama.cpp and Ollama, with GGUF, AWQ and GPTQ builds published at release. The pair totals about 3.5B parameters and fits on one 24GB GPU, and the GGUF path allows CPU-only deployment. No part of the pipeline requires a cloud service.

Is MiniCPM-OCR free for commercial use, and what languages does it support?
The model weights, code and documentation are released under Apache 2.0, which permits commercial use. Out of the box the parser covers Chinese and English. Other languages require fine-tuning, and OpenBMB publishes a worked French handwriting fine-tuning tutorial with LLaMA-Factory and ms-swift.