Model reference · open weights
MiniCPM-OCR-Jev is an open-weight language model from openbmb. MiniCPM-OCR-Jev (BF16) weighs 4.4 GB; the smallest configuration that runs it is RTX 3060 12 GB.
For self-hosting, compare this build's requirements below with the GPU you plan to rent.
Summary of the openbmb/MiniCPM-OCR-Jev model card, 2026-10-28
What it is
| Released by | openbmb |
|---|---|
| Released | 2026-10-23 |
| Parameters | 2.2B |
| VRAM | 4.4 GB for the weights |
What it runs on
| Card | Requests at once | Context max | Memory | |
|---|---|---|---|---|
| 8K each | 32K each | |||
| RTX 3060 12 GB | 36 | 11 | all 256K | 11.6 GB |
| RTX 4060 Ti 16 GB | 63 | 20 | all 256K | 15.4 GB |
| RTX 3090 24 GB | 121 | 38 | all 256K | 23.4 GB |
| RTX 4090 24 GB | 120 | 38 | all 256K | 23.4 GB |
| RTX 5090 32 GB | 175 | 55 | all 256K | 31.0 GB |
| L40S 48 GB | 268 | 84 | all 256K | 44.0 GB |
| A100 80 GB | 513 | 162 | all 256K | 78.2 GB |
| H100 80 GB | 475 | 150 | all 256K | 78.1 GB |
| RTX PRO 6000 Blackwell 96 GB | 587 | 186 | all 256K | 93.8 GB |
| DGX Spark (GB10) 128 GB unified | 684 | 216 | all 256K | 107 GB |
| H200 141 GB | 903 | 285 | all 256K | 138 GB |
| B200 180 GB | 1000+ | 371 | all 256K | 176 GB |
| Requests at once | 8K tokens each | 32K tokens each |
|---|---|---|
| 1 | 6.6 GB | 6.9 GB |
| 5 | 7.2 GB | 8.7 GB |
| 8 | 7.6 GB | 10.0 GB |
| 16 | 8.7 GB | 13.6 GB |
| 32 | 11.0 GB | 20.6 GB |
| 64 | 15.4 GB | 34.8 GB |
One card, with vLLM's small-card settings.
Builds
| Build | Params | Precision | Weights | Smallest setup |
|---|---|---|---|---|
| MiniCPM-OCR-Jev (above) ↗ | 2.2B | BF16 | 4.4 GB | RTX 3060 12 GB |
| MiniCPM-OCR-Jev-gguf ↗ 15 builds: IQ3_XS 1.0 GB … F16 3.8 GB |
GGUF | 1.3 GB | RTX 3060 12 GB | |
| MiniCPM-OCR-Jev-GPTQ ↗ | 2.2B | GPTQ | 2.4 GB | RTX 3060 12 GB |
| MiniCPM-OCR-Jev-AWQ ↗ | 2.2B | AWQ | 2.4 GB | RTX 3060 12 GB |
From the model card
MiniCPM-OCR Jev (2B) is an OCR quality-assessment model for text, formula, and table regions. Given a region image and a candidate OCR result, it returns a score from 0 to 1 — higher means the candidate is more likely correct.
MiniCPM-OCR Jev is a 2B OCR quality-assessment model for text, formula, and table regions. Given a region image and a candidate OCR result, it returns a score from 0 to 1 — higher means the candidate is more likely correct. Use it to auto-accept reliable regions, route the rest to human review, or pick the best result among several OCR models.
Trained from Qwen3.5-2B. The vision encoder and language backbone are retained, and the
language-model output head lm_head is replaced with a binary classification head that
learns whether a candidate is correct.
| Item | Description |
|---|---|
| Assessment unit | One text / formula / table region plus its candidate OCR result |
| Original region image | The crop from the document |
| Candidate content | OCR text and an image rendered from that text |
| Output | Score in 0–1; higher = more likely correct |
When calling the cloud API, the Docker image, or the SDK service with a built-in renderer,
supply the original region image, the candidate text, and the region category
(text / formula / table) — the service renders internally. A service without a renderer
requires you to supply the rendered image as well.
The table below reports overall and per-category AUROC (×100) on JevOCRBench. Higher values indicate better discrimination between correct and incorrect parsing results.
| OCR model | MiniCPM-OCR 1.0 | GLM-OCR | PaddleOCR-VL-1.6 | Xiaomi-OCR-0 |
|---|---|---|---|---|
| AUROC (×100) | 92.7 | 91.9 | 93.4 | 93.1 |
Same 200 samples drawn at random from JevOCRBench; four models parse them independently, every candidate is hand-labelled, then scored by MiniCPM-OCR Jev. Maximum gap 1.5 points.
Score the parsed result for each region and choose a threshold using samples from your application. Results above the threshold proceed automatically; the rest go to human review. A higher threshold typically reduces the number of results that pass automatically, so monitor both the accuracy of automatically accepted results and the volume of human review.
Use the same layout segmentation to have several OCR models parse each region. MiniCPM-OCR Jev scores the candidates for the same region, selects the highest-scoring candidate, and combines the selected results in reading order. If all candidates fall below the application threshold, the region can still be sent for human review.
Candidates for the same region must share the crop and content boundaries. Jev selects among existing candidates, so quality is bounded by their coverage and correctness.
The figure below compares the original image with candidates 1 and 2, showing how MiniCPM-OCR Jev scores text, formula, and table candidates.
| Deployment | Guide |
|---|---|
| Cloud API | Single-candidate scoring, best-of-N, batched best-of-N (stub — being written) |
| Docker / local SDK | Environment, rendering options, service startup |
| vLLM backend | Service configuration with and without a renderer |
| SGLang | Deployment guide |
| llama.cpp | GGUF deployment guide |
| Ollama | Deployment guide |
| FlagOS (multi-chip) | Deployment guide |
When a service has a built-in renderer (cloud API, Docker, SDK), check verdict before using
the score — only scored means model scoring actually ran. Fixed values returned for precheck,
rendering, or forward-pass failures must not be read as low model scores.
Use score for one candidate, score_best for best-of-N within a block, and score_best_batch
across blocks — see the API documentation (stub for now;
until it lands use the vLLM deploy guide for Jev).
ms-swift guide: data format, binary classificatio
Quoted from the model card on Hugging Face. The full card is behind the Hugging Face link above.