How to Run MiniCPM-OCR 1.0 Locally: VRAM and Test Results
How to run OpenBMB's MiniCPM-OCR 1.0 locally with vLLM, what VRAM it needs, and how it handled formulas, charts, newsprint, invoices and Chinese contracts.
For Engineering and IT
How do you run MiniCPM-OCR 1.0 locally?
You run it as two pieces. First, serve the 1.3B-parameter openbmb/MiniCPM-OCR-1.0 model with vLLM (SGLang, llama.cpp and Ollama also work). Second, install the minicpm-ocr SDK with pip install "minicpm-ocr[all]" on Python 3.10+, which handles layout detection and sends each region to the model service. In one hands-on test the model used under 4 GB of VRAM, but the install took about three and a half hours.
TL;DR
- MiniCPM-OCR 1.0 is a 1.3B-parameter OCR model from OpenBMB, built on MiniCPM-V 4.6 with a SigLIP vision encoder and a Qwen3.5 language model.
- A tester running it through vLLM saw under 4 GB of VRAM in use, on a machine that had 48 GB available.
- The install was the hard part: a repo clone, a large environment, PaddlePaddle GPU, OS prerequisites, a vLLM build of 1 to 2 hours, and about 3 to 3.5 hours in total.
- On real documents it was strong on printed text, formulas structure and a Chinese contract, but weak on chart numbers, old newspaper reading order, and non-Latin scripts in a rotated image.
- OpenBMB reports 93.68 on Real5-OmniDocBench and 54.7 on OCRBench v2, with throughput of 1.2 pages/s on an RTX 5090. Those are vendor numbers.
- Treat it as a fast first-pass parser and proofread symbols, handwriting and layout-heavy pages.
What is MiniCPM-OCR 1.0?
MiniCPM-OCR 1.0 is the first OCR-specific model in OpenBMB's MiniCPM-V/o family. It targets text-centric document understanding: text, tables, formulas, charts, seals, and key information extraction. Primary languages are Chinese and English.
| Item | Detail |
|---|---|
| Parameters | 1.3B |
| Base | MiniCPM-V 4.6, trained for OCR |
| Components | SigLIP vision encoder plus Qwen3.5 language model |
| Visual tokens | 4x compression, scale resolution 448, up to 9 slices |
| Serving backends | vLLM, SGLang, llama.cpp, Ollama |
| Layout model | PP-DocLayoutV3 |
OpenBMB also publishes a DSpark variant (BF16 and GGUF) with decoding acceleration. The company says it improves end-to-end processing efficiency by 55%.
How does the parsing pipeline work?
Full-page parsing is a two-stage pipeline orchestrated by the minicpm-ocr SDK.
- Layout detection. PP-DocLayoutV3 finds regions (text, tables, formulas, charts, seals), determines reading order, and the SDK crops each region. This stage runs in the SDK environment and needs PaddlePaddle and PaddleX.
- Region recognition. The SDK sends each crop over HTTP to the MiniCPM-OCR inference service with a prompt matched to the region type. It then assembles Markdown or JSON in reading order.
The two stages can run in separate environments or on different machines. That split explains why the install feels heavy. You are setting up a Paddle-based layout stack and a vLLM serving stack, not one model.
The model service must be running before you call the SDK. The official examples assume a server at http://127.0.0.1:8080 serving the model name minicpm-ocr:
minicpmvocr parse demo.png \
--backend vllm \
--server-url http://127.0.0.1:8080 \
--model minicpm-ocr \
--device cuda:0 \
--set run.run_root=output \
--output output/demo.md
The CLI downloads PP-DocLayoutV3 automatically when needed. Use --device cpu for CPU layout detection, and swap in a PDF path to parse a PDF.
How hard is the install, and how much VRAM does it use?
Harder than most OCR models. The tester compared it unfavorably with Baidu's recently covered "unlimited OCR" model. The sequence was: clone the repo, build an environment with many dependencies, install PaddlePaddle GPU so the structure output is right, add OS prerequisites, build vLLM (1 to 2 hours depending on hardware), then launch the server. Total time was roughly 3 to 3.5 hours on a 48 GB VRAM machine.
Once running, the model showed under 4 GB of VRAM use. That figure came from a single observation of the setup, so treat it as a ballpark. Layout detection, batch size and context settings will shift it. The small footprint still means the recognition model itself fits on modest consumer GPUs.
Speed was acceptable. A chart image finished in roughly 10 to 20 seconds in that test, which the tester called good but not lightning fast. OpenBMB's own throughput figure is 1.2 pages/s on an RTX 5090 across all 1651 OmniDocBench v1.6 images at image-level concurrency 1. It says real throughput depends on content, backend, concurrency and hardware.
How accurate is MiniCPM-OCR on real documents?
The tester ran six documents. Results were mixed, and mostly consistent with how OCR models behave in general: text is strong, structure is where errors creep in.
| Document | What worked | What failed |
|---|---|---|
| Handwritten physics formulas | Clean LaTeX structure: fractions, integrals, subscripts, roots, formula order | Symbol errors: momentum p read as rho, a wrong subscript, a spurious equal sign between fractions |
| Dual-axis semiconductor chart | Four summary cards read correctly, including the 620 billion peak export and 26 week lead time | Table values off by a factor of 10 against the billions axis (4100, 3500 and so on) |
| 1974 New Zealand Herald front page | Headlines, most small body text, old typeface, photo caption | Merged neighboring columns in the Darwin story, a sidebar dropped mid-article, misread place names |
| Plain invoice | All text and line items correct, including product IDs | Dropped the word "Invoice" and the thank-you footer |
| Rotated multilingual page | English handled well despite the flipped orientation | Arabic and Urdu failed; Indonesian came out as English-style text |
| AI-generated Chinese supply contract | Body text near perfect, including clauses and contract number; seal text picked up | One wrong character in the seal, partly due to garbled generated imagery |
Three patterns stand out:
- Charts are approximations. Values estimated from bar heights are not reliable. Do not use them as data without checking the axis.
- Reading order on dense old print is the weak spot. Character recognition held up, but column merging and sidebar placement did not.
- Footers get dropped. The tester noted that other OCR models also miss invoice footers.
The non-Latin result matches the model card, which lists Chinese and English as primary languages. Do not expect Arabic or Urdu to work well.
How does it compare on benchmarks?
OpenBMB claims leading results on OmniDocBench v1.6, Real5-OmniDocBench, Wild-OmniDocBench and olmOCR-Bench. Specific numbers from the model card:
- 93.68 on Real5-OmniDocBench, a real-world document parsing benchmark.
- 54.7 on OCRBench v2.
- The highest equal-weight average across the four parsing benchmarks among the open-source models compared.
- With DSpark, throughput about 1.49x PaddleOCR-VL-1.6 and 3.62x MinerU2.5 Pro.
The tester walked through OpenBMB's comparison of 15 OCR models across six benchmarks. In that table MiniCPM-OCR led on four. Rivals were ahead on OmniDocBench and olmOCR-Bench, but MiniCPM-OCR was close on those. It led clearly on the harder sets, including Wild-OmniDocBench and OCRBench. The model card says scores from different benchmarks are not directly comparable, and OpenBMB publishes a reproduction guide. These are first-party results, and newer versions of several rival models exist, so a fresh head-to-head would be worth running on your own documents.
Is MiniCPM-OCR worth running locally?
It is if your documents are printed, Chinese or English, and you want structured Markdown or JSON from a small model. The sub-4 GB footprint, the multiple serving backends (including llama.cpp and Ollama) and the clean results on the invoice and the Chinese contract are real advantages.
It is a poorer fit if you need exact numbers from charts, faithful reading order on degraded newsprint, support for Arabic or Urdu, or unreviewed handwriting transcription. Plan a proofreading step for anything where a swapped symbol matters. If the multi-hour install is a dealbreaker, the hosted demos on Hugging Face Spaces and OpenBMB's platform let you test your own files first.
Frequently Asked Questions
What hardware do I need for MiniCPM-OCR 1.0?
The recognition model is 1.3B parameters, and one test observed under 4 GB of VRAM in use. The SDK examples assume an NVIDIA GPU for layout detection, though the CLI also accepts --device cpu for that stage. OpenBMB's speed figures come from an RTX 5090.
Does MiniCPM-OCR support languages other than English and Chinese?
Chinese and English are the primary languages. In testing, a rotated page with Arabic and Urdu failed, and Indonesian was rendered in an English-style output. Latin-script languages may partly work, but verify output before relying on it.
Can I use something other than vLLM?
Yes. The model card lists vLLM, SGLang, llama.cpp and Ollama as supported backends from day one, plus quantized variants. The DSpark release also ships GGUF weights for llama.cpp-style use.
How accurate is it on charts and handwriting?
Not exact. In the test, handwritten formulas kept correct LaTeX structure but had symbol errors. A dual-axis chart produced table values off by a factor of 10. Use both outputs as drafts that need review.
Topics
Useful for
How we source, write, and correct our articles. Editorial standards
