Model reference · open weights

MiniCPM-OCR-Jev

NEW · this week LLMs openbmb Vision + text 4 builds Open weights 2 dl/mo

MiniCPM-OCR-Jev is an open-weight language model from openbmb. MiniCPM-OCR-Jev-AWQ (AWQ) weighs 2.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.

  • MiniCPM-OCR-Jev is a 2.2B parameter image-text-to-text model developed by openbmb for assessing the quality of OCR results in text, formula, and table regions.
  • It returns a score from 0 to 1 to indicate the likelihood that a candidate OCR result is correct, supporting automatic screening or selection among multiple models.
  • The model supports English and Chinese, features a 262144 token context length, and is released under the Apache 2.0 license.

Summary of the openbmb/MiniCPM-OCR-Jev model card, 2026-10-28. The estimate below is for another build of the family.

What it is

Released byopenbmb
Released2026-10-23
Parameters2.2B
VRAM2.4 GB for the weights

What it runs on

Memory and cards for MiniCPM-OCR-Jev-AWQ (AWQ)

2.4 GBweights, file size
12 MBcache per 1K tokens
39 MBfixed state per request
2.1 GBruntime overhead, at least
262,144 tokenscontext max
CardRequests at onceContext maxMemory
8K each32K each
RTX 3060 12 GB5116all 256K11.6 GB
RTX 4060 Ti 16 GB7824all 256K15.4 GB
RTX 3090 24 GB13542all 256K23.4 GB
RTX 4090 24 GB13542all 256K23.4 GB
RTX 5090 32 GB19060all 256K31.0 GB
L40S 48 GB28289all 256K44.0 GB
A100 80 GB527166all 256K78.2 GB
H100 80 GB490155all 256K78.1 GB
RTX PRO 6000 Blackwell 96 GB602190all 256K93.8 GB
DGX Spark (GB10) 128 GB unified699221all 256K107 GB
H200 141 GB918290all 256K138 GB
B200 180 GB1000+376all 256K176 GB
Memory needed at each load
Requests at once8K tokens each32K tokens each
14.6 GB4.9 GB
55.1 GB6.7 GB
85.6 GB8.0 GB
166.7 GB11.5 GB
328.9 GB18.6 GB
6413.4 GB32.7 GB

One card, with vLLM's small-card settings.

Builds

Sizes, precisions & builds

BuildParamsPrecisionWeightsSmallest setup
MiniCPM-OCR-Jev ↗ 2.2BBF16 4.4 GBRTX 3060 12 GB
MiniCPM-OCR-Jev-gguf ↗
15 builds: IQ3_XS 1.0 GB … F16 3.8 GB
GGUF 1.3 GBRTX 3060 12 GB
MiniCPM-OCR-Jev-GPTQ ↗ 2.2BGPTQ 2.4 GBRTX 3060 12 GB
MiniCPM-OCR-Jev-AWQ (above) ↗ 2.2BAWQ 2.4 GBRTX 3060 12 GB

From the model card

What openbmb says about MiniCPM-OCR-Jev

Read the model card

GitHub · Usage

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

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.

  • 🛡️ A small model that beats larger ones: at only 2B parameters, decision AUROC (×100) on JevOCRBench is 93.6, above JEV-35B-A3B (90.1) and close to Qwen3.5-397B-A17B (93.8).
  • 🧩 Stable generalization: on parses from MiniCPM-OCR 1.0, GLM-OCR, PaddleOCR-VL-1.6, and Xiaomi-OCR-0, AUROC (×100) stays in 91.9–93.4.

Architecture

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.

ItemDescription
Assessment unitOne text / formula / table region plus its candidate OCR result
Original region imageThe crop from the document
Candidate contentOCR text and an image rendered from that text
OutputScore 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.

Evaluation Results

The table below reports overall and per-category AUROC (×100) on JevOCRBench. Higher values indicate better discrimination between correct and incorrect parsing results.

Discrimination across OCR models

OCR modelMiniCPM-OCR 1.0GLM-OCRPaddleOCR-VL-1.6Xiaomi-OCR-0
AUROC (×100)92.791.993.493.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.

Automatic screening to reduce human review

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.

Selecting across models to improve parsing quality

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.

Examples

The figure below compares the original image with candidates 1 and 2, showing how MiniCPM-OCR Jev scores text, formula, and table candidates.

Quick start

DeploymentGuide
Cloud APISingle-candidate scoring, best-of-N, batched best-of-N (stub — being written)
Docker / local SDKEnvironment, rendering options, service startup
vLLM backendService configuration with and without a renderer
SGLangDeployment guide
llama.cppGGUF deployment guide
OllamaDeployment 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.

Pipeline integration

  1. Keep page/region ids, original region images, region categories, and candidate text while parsing.
  2. Submit image + category + candidate text (renderer service), or image + rendered image (renderer-less service).
  3. Check status, associate scores with candidates, apply your threshold, and compare candidates within each region when several models are in play.
  4. Emit selected results in the original reading order and keep pending regions for reviewers.

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).

Fine-tuning

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.

© 2026 AxForge · EU-hosted AI infrastructure Pricing Docs Trust Privacy Terms