How Does MiniCPM-OCR Score Against Other Open OCR Models?
MiniCPM-OCR leads four of six benchmarks against 15 open OCR models and runs fast, but charts, reading order and footers still trip it up.
For Engineering and IT
How does MiniCPM-OCR score against other open-source OCR models?
OpenBMB's MiniCPM-OCR ranks first on four of the six benchmarks in its published comparison of 15 open-source OCR models. It is close to the leaders on OmniDocBench and olmOCR, and it pulls ahead on the harder benchmarks. Its efficiency chart also shows it scoring about the same as the best model while processing more pages per second than almost every other model listed. Hands-on tests show real gaps, though, especially with charts, reading order and footers.
TL;DR
- MiniCPM-OCR tops four of six benchmarks in a table that lines up 15 open-source OCR models.
- On OmniDocBench and olmOCR the margin is small, so those two are close races rather than clear wins.
- The efficiency chart puts it in the top right corner: error score near the best model, with higher pages-per-second than nearly all rivals.
- A hands-on tester found strong printed text, formulas and Chinese documents, but chart values, column order and dropped footers need checking.
- Setup is heavy. One tester spent three to three and a half hours on installation, though the running model used under 4 GB of VRAM.
- Treat the benchmark lead as a reason to test it on your own documents, not as proof it will beat every alternative on them.
What do the two benchmark views show?
The release comes with two views of the same comparison. Both are worth reading, because they answer different questions.
| View | What it shows | Takeaway for MiniCPM-OCR |
|---|---|---|
| Efficiency chart | Open-source OCR models plotted by speed and by error score, across four benchmarks | Top right corner. Roughly the same accuracy as the best model, with more pages per second than almost all others |
| Six-benchmark table | 15 OCR models scored on six benchmarks | First place on four of the six |
| Six-panel breakdown | One panel per benchmark, top models ranked in each | Leads several panels, including OCRBench |
The efficiency chart matters most if you run OCR at volume. A model that is a fraction behind on accuracy but much faster can cost less to operate. A model that matches the best accuracy and is also faster removes that tradeoff, and that is the claim the chart makes.
One caveat on the efficiency chart: it aggregates across four benchmarks, not all six. It tells you about speed against error in general, not about any single document type.
Where does it lead, and where is it only close?
The creator who walked through the table described two tiers. On OmniDocBench and olmOCR, MiniCPM-OCR is close to the competition. On the other benchmarks, which he called the harder ones, it leads clearly. The panel view names OCRBench among the benchmarks where it ranks first. The transcript also mentions two others by names I could not verify from the audio, so check the model card for the exact list.
This split matters for how you read the headline. OmniDocBench and olmOCR are the benchmarks many people already use to compare document parsers. A narrow gap there means the model is competitive, not dominant. The clearer wins come on benchmarks that are tougher, and "tougher" is where an OCR model's weaknesses usually show up.
The exact per-benchmark scores were not available in the material I reviewed. If you need the numbers, take them from OpenBMB's model card and repository rather than from secondhand summaries.
How do the hands-on results qualify the scores?
Benchmarks average over many pages. A single messy page can behave very differently. A set of informal tests on a locally run copy shows where the averages hide problems.
| Test document | What worked | What failed |
|---|---|---|
| Handwritten physics formulas to LaTeX | Fractions, integrals, subscripts, square roots and formula order | Misread symbols (momentum P read as rho), a wrong subscript, an extra equal sign |
| Dual-axis semiconductor chart | Four summary cards, peak export figure, lead time | Table values were off by a factor of 10 against the chart axis |
| 1974 newspaper front page | Headlines, most small body text, old typeface, photo caption | Merged neighboring columns, dropped a sidebar into the middle of an article, some misread words |
| Plain invoice | All text and line items, including product IDs | Dropped the word "invoice" and the thank-you footer |
| Multilingual image, flipped | English text | Arabic and Urdu failed, Indonesian came out as English |
| Chinese supply contract with seal | Body text nearly perfect, clauses and contract number | One wrong character in the seal text |
Three patterns stand out.
Charts are approximations. The model estimated values from bar heights and got the scale wrong. If your pipeline turns charts into tables, do not trust the numbers without checking them against the axis.
Reading order is the weak point on dense layouts. Text recognition on the newspaper was strong. Structure was not. Column merging and misplaced sidebars are the kind of error that character-level accuracy metrics can miss, and they can wreck downstream use such as search or summarization.
Footers get dropped. The tester saw this on the invoice and noted that Baidu's Unlimited OCR and a few other models did the same. It looks like a shared habit across this model class rather than a one-off.
None of this contradicts the benchmark lead. It narrows what the lead means. The model can rank first and still need a human check on handwriting, non-Latin scripts beyond Chinese and English, and complicated layouts.
How fast is it, and what does it take to run?
On a chart image, the tester saw output in under 10 to 20 seconds and called the speed fine but not lightning fast. That is a single-image impression on one 48 GB VRAM machine, not a throughput benchmark. The efficiency chart is the better evidence for pages per second.
Memory use was modest. The model ran locally on under 4 GB of VRAM.
Installation was the painful part. The tester described it as much harder than Unlimited OCR:
- Clone the repository.
- Create an environment with many dependencies.
- Install PaddlePaddle GPU, which is used to get document structure right.
- Meet several OS prerequisites.
- Build the vision-language and language-model components, which took roughly one to two hours.
- Serve the model with vLLM.
All of that took about three to three and a half hours. Budget for it if you plan a trial.
Is MiniCPM-OCR worth testing against your own documents?
Probably yes, if you process printed text, formulas or Chinese documents at volume. The combination of top-tier benchmark results, small memory footprint and high pages per second is unusual. The first impression from hands-on use matches that: a fast, small, capable parser that is strong on printed text, formulas and Chinese documents.
It is a weaker fit if your documents are handwritten, multilingual beyond English and Chinese, chart-heavy, or laid out in tight columns. In those cases, run a sample set through it and a couple of the other models on the table, and compare structure as well as text. The comparison also shows why a six-benchmark lead should not replace testing on your own files.
Frequently Asked Questions
How many models and benchmarks does the MiniCPM-OCR comparison cover?
The table lines up 15 open-source OCR models across six benchmarks. MiniCPM-OCR ranks first on four of them. A separate efficiency chart covers four benchmarks and plots speed against error score.
Does MiniCPM-OCR beat other models on OmniDocBench and olmOCR?
It is close to the top on both, but the margins there are small. Its clearer leads come on the harder benchmarks in the table, such as OCRBench.
What are MiniCPM-OCR's main weaknesses?
Hands-on tests found wrong values when converting charts to tables, jumbled reading order on a dense newspaper page, and dropped footers on an invoice. Handwritten symbols and scripts such as Arabic and Urdu also needed correction or failed.
How much GPU memory does MiniCPM-OCR need?
The tester's local run used under 4 GB of VRAM, on a machine that had 48 GB available. Setup is the bigger cost, since it involved PaddlePaddle GPU, a one to two hour build and serving through vLLM.
Topics
Useful for
How we source, write, and correct our articles. Editorial standards
