MiniCPM OCR 是什么：13亿参数的端侧文档识别套件

它是什么：面壁智能给文档识别单开的一条线

MiniCPM OCR 是面壁智能 OpenBMB 在 2026 年 10 月 28 日发布的文档识别套件，隶属 MiniCPM-V 系列，权重开放。官方把识别模型叫 MiniCPM-OCR 1.0，说它是 MiniCPM-V/o 家族里首个专门为 OCR 训练的模型。一句话概括：一个 1.3B 的识别模型，加一个 2B 的验收模型，前者负责把字读出来，后者负责判断读得对不对。

两个成员分工很清楚。MiniCPM-OCR 1.0 吃文档图片或裁出来的区域，输出文字、表格、公式、图表和印章内容，也能直接按你指定的字段做关键信息抽取。MiniCPM-OCR Jev 拿到原图区域和一份候选识别结果，给出一个 0 到 1 的分数，分数越高，越可能是对的。

关键规格：两个模型都不大

识别模型是 13 亿参数，在 MiniCPM-V 4.6 的基础上做 OCR 专项训练，视觉部分是 SigLIP 编码器，语言部分是 Qwen3.5。视觉 token 做了 4 倍压缩，单张图最多切 9 片，缩放分辨率 448。这几个数字合起来的意思是：喂图的开销被压住了，整体体量够小，官方也因此给了 AWQ、GPTQ、GGUF 等量化版本，AWQ 版权重从约 2.42 GiB 降到约 1.74 GiB。主打语言是中文和英文，上下文长度官方没有单独公布，官方示例的服务命令里把最大长度设成了 40960。

Jev 是 2B 参数，从 Qwen3.5-2B 训练而来，把输出头换成二分类头，只回答"这段识别结果对不对"，覆盖文字、公式、表格三类区域。两个模型的代码、权重和文档都用 Apache 2.0 协议，可以免费商用。

能力和成绩：官方自测，有高有低

成绩都是 OpenBMB 自己公布的。识别模型在 OmniDocBench v1.6 上是 96.51，Real5-OmniDocBench 是 93.68，Wild-OmniDocBench 是 92.39，olmOCR-Bench 是 82.7，OCRBench v2 是 54.7，CHAOS-Bench 是 29.78。Real5 和 Wild 偏向真实拍摄的文档，扫描件、弯曲页、歪斜页、翻拍件都在范围内，这是官方最想强调的场景。官方说，在它选取的开源 OCR 模型里，四项文档解析基准的等权平均分排在前面，但完整对比表里并非每项都拿到最高：TeleOCR 在 OmniDocBench v1.6 上是 96.91，chandra-ocr-2 在 olmOCR-Bench 上是 85.8。

速度方面，官方在一张 RTX 5090 上跑完 OmniDocBench v1.6 的 1651 张图，并发为 1，用各家的加速配置，MiniCPM-OCR 1.0 是每秒 1.2 页。官方说吞吐约为 PaddleOCR-VL-1.6 的 1.49 倍、MinerU2.5 Pro 的 3.62 倍；配上 DSpark 草稿模型做解码加速，端到端效率提升 55%。这是特定硬件和配置下的数，换了显卡或页面类型，结果会变。

Jev 的成绩也值得看一眼。官方在 JevOCRBench 上报告它的判别 AUROC 为 93.6，对比的 JEV-35B-A3B 是 90.1，Qwen3.5-397B-A17B 是 93.8。换成 MiniCPM-OCR 1.0、GLM-OCR、PaddleOCR-VL-1.6、Xiaomi-OCR-0 四家的解析结果来判，AUROC 落在 91.9 到 93.4 之间，说明它不挑识别模型。不过官方自己也提醒，这是在特定样本和组合上的结果，换了文档类型要重新验证。

怎么用、多少钱

最省事的是 pip 装 minicpmvocr SDK，它负责整页流程：读取 PDF 或图片，用 PP-DocLayoutV3 版面模型切出区域和阅读顺序，把区域并发送给识别模型，最后拼成 Markdown，表格转成 HTML，公式保持 LaTeX。想自己搭服务，官方给了 vLLM、SGLang、llama.cpp、Ollama、Transformers 和多芯片的 FlagOS 部署指南，vLLM 下一条 serve 命令就能起来。官方在线体验有国内和海外两个入口，代码仓库是 OpenBMB/MiniCPM-OCR。

费用上，官方卡片标注的是免费 API，没有给出按量计费的价格；本地部署则只取决于你的显卡，权重本身不收费。要长期大量调用云端接口，以平台文档为准。Jev 的云 API 说明页在官方模型卡里还标着正在补写，想接入的话，先看 Docker 或 SDK 的部署教程更稳。

和谁比：快是卖点，精度互有胜负

对上一代，需要说清楚的是它们不是同类：MiniCPM-V 4.6 是通用视觉模型，OCR 只是其中一项能力，MiniCPM-OCR 1.0 是在它之上专门为文档任务训练的，官方没有公布两者的逐项对比。对同档竞品，官方强调的是吞吐，比 PaddleOCR-VL-1.6 和 MinerU2.5 Pro 快，而精度上和 TeleOCR、chandra-ocr-2 各有高低。AI主线的看法是，这类模型选型别只盯一个榜单分数，速度、部署门槛和你自己的文档类型，往往比第三位小数更决定体验。

适合谁，坑在哪

做文档解析、票据录入、合同归档的开发者，值得拿自己的一批样本跑一遍，尤其是扫描质量参差、中英混排的场景。需要私有化部署的团队，Apache 2.0 加量化版本，门槛比较友好。想做自动验收的，可以让 Jev 打分，设一个阈值，高分的自动通过，低分的转人工，也可以让多个 OCR 模型各识别一遍，由 Jev 挑得分最高的那份，不过官方说明它只能在已有候选里选，质量受限于候选本身。

坑也有几处。整页流水线的成绩包含了版面模型，不能直接当成单个识别模型的成绩。语言以中英文为主，其他语种需要自己微调，官方给了 LLaMA-Factory 和 ms-swift 的法语手写示例。关键字段抽取的结果是模型生成的文本，进下游之前要解析 JSON 并校验。输出被截断时，官方的提示是调大 token 预算。DSpark 加速要求主模型和草稿模型来自同一版本，混用会出问题。