• 人工智能
• 大模型
• OCR
• 多模态
• 计算机视觉

MiniCPM-OCR-Jev 是 OpenBMB 开源的2B 参数 OCR 正确性判定模型：给它一张文本、公式或表格的局部图片，加上一个候选 OCR 识别结果，它返回一个0~1 的分数——分数越高，说明这个识别结果越可能正确。本文是一份面向新手的MiniCPM-OCR-Jev 部署清单，把 vLLM、SGLang、Ollama、llama.cpp、FlagOS 五种后端部署方式一次讲清，帮你用最短路径选对方案。

🧭 一、3分钟认识 MiniCPM-OCR-Jev

先看它"小"在哪里、"强"在哪里：

它的架构思路很简单：从Qwen3.5-2B出发，保留视觉编码器和语言主干，把原来生成文本的输出头lm_head换成一个二分类头，专门学习"候选结果是否正确"。在 config.json 中可以看到problem_type: single_label_classification这一关键配置——它决定了后端服务如何解析模型输出（输出分数而非文本）。

两个典型用法（详见 README.md）：

• 🛡️自动筛查：给每个区域的识别结果打分，超过阈值的自动放行，剩下的转人工复核，大幅减少人工量；
• ⭐多模型择优（best-of-N）：让多个 OCR 引擎解析同一区域，用 Jev 给每个候选打分，自动选出最优结果。

📦 二、模型文件清单：哪种格式配哪种后端？

部署第一步是选对模型文件。官方提供四种格式（对照表见 README.md）：

本仓库即 BF16 原始版本，核心文件包括：

• model.safetensors —— 模型权重
• config.json —— 模型结构配置（model_type: qwen3_5）
• chat_template.jinja —— 对话/多模态输入模板（含图片占位符）
• tokenizer.json、tokenizer_config.json —— 分词器
• preprocessor_config.json —— 图像预处理参数

如果习惯从代码仓库获取文件，可以克隆：

git clone https://gitcode.com/OpenBMB/MiniCPM-OCR-Jev

🚀 三、五大后端部署全对比

官方为每种后端都提供了独立部署文档，总入口见 README.md 的 Quick start 表格。一张表先建立全局认知：

3.1 vLLM 部署：高并发在线服务首选

vLLM 是目前生产环境最常见的选择，官方文档单独覆盖了带渲染器和不带渲染器两种服务配置：

• 带渲染器：你只提供"原始区域图 + 候选文本 + 区域类别（text / formula / table）"，服务内部自动把候选文本渲染成对照图片，链路最简单；
• 不带渲染器：需要调用方自行提供渲染后的候选图片。

⚠️ 关键提醒：无论哪种配置，拿到响应后先检查verdict字段，再看score——只有verdict为scored才代表模型真正完成了打分。前置检查失败、渲染失败或前向计算失败时返回的是固定值，不能当作"模型判它分数低"来解读（见 README.md）。

3.2 SGLang 部署：高吞吐批处理的好搭档

SGLang 擅长把大批量请求组织成高效的调度，官方提供独立的 SGLang 部署指南。如果你的场景是"每天几百万个区域要批量打分"，SGLang 的吞吐表现通常是重点考察对象。用法上与 vLLM 类似：启动服务 → 发起打分请求 → 校验verdict。

3.3 Ollama 部署：新手最简单的路径

想在本地 5 分钟内跑起来看看效果？选 Ollama。它的定位就是一条命令出结果：拉取模型、加载权重、暴露 API 全部自动化，特别适合：

• 验证模型效果是否符合预期
• 在单卡开发机上做 POC 原型
• 非运维人员快速上手

代价是吞吐与并发能力弱于 vLLM / SGLang，生产环境建议切换前两者。

3.4 llama.cpp 部署：GGUF 量化，CPU 也能跑

llama.cpp 路线需要先准备GGUF 格式的量化权重（官方单独发布了 GGUF 版本）。它的最大优势是资源需求低：量化后的 2B 模型在纯 CPU 或入门级 GPU 上也能完成判定任务，适合边缘设备、内网离线环境或对成本敏感的小批量场景。

注意：GGUF 是量化格式，精度会有轻微损失。判定模型的分数是连续值，量化带来的漂移通常可接受，但上线前仍建议用自己的业务数据对比 BF16 版本抽查。

3.5 FlagOS 部署：国产多芯片环境

FlagOS 路线面向多芯片、异构算力环境（如国产 AI 芯片集群）。如果你的基础设施不是 NVIDIA GPU，或者需要在一套软件栈下调度多种芯片，FlagOS 是官方给出的部署选项，官方文档中给出了独立的多芯片部署指南。

🎯 四、三步选对你的后端

按下面的顺序做减法，30 秒就能定方案：

1. 算力是什么？CPU / 低显存 →llama.cpp + GGUF；国产芯片 →FlagOS；NVIDIA GPU → 继续下一步。
2. 目的是什么？个人试用、POC →Ollama；生产高并发在线服务 →vLLM；大批量高吞吐打分 →SGLang。
3. 显存紧不紧？紧张时把 BF16 换成AWQ / GPTQ（W4A16）量化格式，vLLM 即可加载，显存占用显著下降。

✅ 五、上线前最后检查清单

• 请求中提供原始区域图 + 候选文本 + 正确的区域类别（使用带渲染器的服务时）
• 响应解析先判verdict == scored，再取score
• 在自己的业务数据上标定阈值——阈值越高自动放行越少，要同时监控"自动放行准确率"和"人工复核量"
• 多模型择优场景下，确保同一区域的多个候选使用相同的裁剪范围和内容边界（Jev 只负责在现有候选中挑选，结果上限受候选质量约束，见 README.md）
• 使用其他 OCR 引擎或新文档类型时，先小样本验证泛化效果

📌 写在最后

MiniCPM-OCR-Jev 用 2B 的参数量做到了超越多个更大模型的 OCR 判定精度（93.6 vs 90.1），而且五种后端覆盖了从"一条命令试用"到"多芯片生产集群"的全部场景。模型权重、代码与文档均基于Apache License 2.0发布，可自由用于商业项目。

仓库核心文件速查：README.md（能力与部署入口总览）、config.json（模型结构）、generation_config.json（生成参数）、chat_template.jinja（多模态输入模板）。

• 人工智能
• 大模型
• OCR
• 多模态
• 计算机视觉