MiniCPM-OCR 1.0 (1.3B) is the first OCR-specific model in the MiniCPM-V/o family. It focuses on text-centric document understanding β text, tables, formulas, charts, seals, and structured information extraction β and balances quality against speed on real-world captures.
π SOTA document parsing: 93.68 on Real5-OmniDocBench, a benchmark for real-world document parsing, with leading results on OmniDocBench v1.6, Wild-OmniDocBench, and olmOCR-Bench. Handles Chinese and English documents and PDFs, including scans, curved pages, photographs, skewed pages, and recaptured documents.
β‘ Efficient inference. With DSpark decoding acceleration (BF16, GGUF) end-to-end processing efficiency improves by 55%. Throughput is about 1.49Γ PaddleOCR-VL-1.6 and 3.62Γ MinerU2.5 Pro.
π General recognition and information extraction: 54.7 on OCRBench v2, plus key information extraction (KIE) for downstream automation.
π οΈ Easy to deploy and develop: vLLM, SGLang, llama.cpp, and Ollama from day one, with quantized variants and multi-chip builds. Supports further fine-tuning, and ships a pip SDK, a full API, and agent workflows. Online demos: HF Spaces Β· CN Β· Official CN Β· Official Global.
Among the open-source OCR models compared, MiniCPM-OCR 1.0 reaches 1.2 pages/s and the highest equal-weight average score across OmniDocBench v1.6, Real5-OmniDocBench, Wild-OmniDocBench, and olmOCR-Bench.
Average score is the equal-weight mean of the four benchmarks. All models use accelerated configurations. Settings and reproduction: reproduction guide. Per-model throughput: model guide.
Each panel keeps its own benchmark's scores; higher is better. Scores from different benchmarks are not directly comparable. Test settings and reproduction steps are in the reproduction guide; per-benchmark discussion is in the model guide.
On an NVIDIA GeForce RTX 5090 with all 1651 OmniDocBench v1.6 images, image-level concurrency 1, and each system's accelerated configuration, MiniCPM-OCR 1.0 reaches 1.2 pages/s (relative throughput 1.00Γ; higher is faster).
Concurrency 1 is image-level: regions inside a page are still recognised in parallel. Real throughput also depends on page content, backend, concurrency, and hardware.
Full-page parsing runs as a two-stage pipeline orchestrated by the minicpm-ocr SDK. The two stages use separate models, run in separate environments, and may run on different machines:
Stage 1 β Layout detection (SDK environment). The PP-DocLayoutV3 layout model detects document regions β text, tables, formulas, charts, seals β and determines reading order; the SDK crops each region. It runs locally inside the SDK environment and requires PaddlePaddle / PaddleX.
Stage 2 β Region recognition (inference service). The SDK sends each cropped region over HTTP to a MiniCPM-OCR 1.0 inference service β served by vLLM, SGLang, llama.cpp, or Ollama β with a prompt matching the region type, then assembles the recognized content into the final Markdown / JSON in reading order.
Required before using either the CLI or Python API: deploy and start the OCR model service first, and wait until it is ready to accept requests. The SDK examples below are clients of that running service; they do not deploy or start the OCR model service automatically.
Use the official minicpm-ocr SDK to parse a local image or PDF. It detects layout with PP-DocLayoutV3, recognises each region, and saves structured JSON and Markdown in reading order.
Before running either the CLI or Python API, deploy and start a vLLM recognition service for openbmb/MiniCPM-OCR-1.0 following the deployment guide. The examples assume a service at http://127.0.0.1:8080, served model name minicpm-ocr, and an NVIDIA GPU for layout detection. Match the endpoint, backend, and device to your deployment. Configure the service to listen on port 8080 and serve the model as minicpm-ocr to use the examples unchanged.
The CLI automatically downloads PP-DocLayoutV3 to models/PP-DocLayoutV3_infer/ when needed. The final Markdown is saved to output/demo.md; structured JSON and per-page Markdown are kept in output/<run_tag>/results_json/ and output/<run_tag>/output/.
To parse a PDF, replace demo.png with its local path. Use --device cpu for CPU layout detection. Run minicpmvocr parse --help for all CLI options.
The model service described above must already be running before you execute this Python example. Set engine.server_url and engine.model_name to match that service.
ensure_layout_model() downloads the official layout model when it is missing. Results are written to output/<run_tag>/results_json/ and output/<run_tag>/output/. To parse a PDF, replace demo.png with its local path.
For a CPU layout detector, set layout.device to cpu. For the GGUF checkpoint served by llama.cpp, set engine.type to llamacpp and match the service context length with engine.max_model_len.
See the SDK API reference for configuration and document-level Markdown export.
LLaMA-Factory Β· ms-swift β data preparation, full-parameter SFT with the multimodal projector frozen, training, and evaluation (French handwritten text lines).
| Text-centric document understanding | Text block / Paragraph / Title / Page | Text Recognition: | Plain text
| Table | Table Recognition: | Table in HTML format(via SDK post-processing)
| Formula | Formula Recognition: | LaTeX
| Inline formula | Text Recognition: | LaTeX
| Seal | Seal Recognition: | Plain text
| Chart | Chart to Table: | Table in HTML format(via SDK post-processing)
| Structured information extraction | Specified fields | Extract the "field", .... Format the output as a JSON object with keys: "field", .... If an item is not in the image, use "###". | JSON
DSpark requires a matching main and draft model from the same release β do not mix draft weights with a different main checkpoint. See DSpark acceleration.
For OCR quality assessment (auto-accept, human-review routing, best-of-N across models), see MiniCPM-OCR Jev.