一年从3B卷到0.xB：MonkeyOCRv2用0.7B拿下17语种文档解析开源第一

从 3B 的 MonkeyOCR，到 1.2B 的 MinerU、1.0B 的 HunyuanOCR、0.9B 的 PaddleOCR-VL 和 GLM-OCR，再到 0.7B、0.6B 的 MonkeyOCRv2股票科普，文档 OCR 正加速迈入小模型时代：模型越来越小，性能上限却一次次被重新定义。

△一年多时间里，文档 OCR 从 3B 快速进入 0.xB 区间。

一年前，3B 参数还可以被称为"轻量文档模型"。现在，这条线已经被推到了 0.xB。

在覆盖电子原生文档、拍照文档和 17 种语言的 MDPBench 上，MonkeyOCRv2-S 总参数只有0.6B，拿到82.5 分；0.7B版本进一步达到83.3 分。此前排名最高的开源模型 dots.mocr 有3B参数，得分为80.5。榜单中体量最小的两个模型，反而站到了开源结果的最前面。

这不是一个常见的"大力出奇迹"故事。更像是文档 OCR 在一年之内，突然重新想明白了一件事：模型不一定要继续变大，但每一部分参数必须知道自己究竟负责什么。

华中科技大学白翔团队给出的路线，不是把 3B 模型机械裁成 0.7B，而是重新分配系统职责：让前端视觉编码器先把字符、公式与版面看清，再让更小的语言模型负责组织和理解。

0.7B 反超 3B，真正减少的并不只是参数，而是后端语言模型替前端"猜"的工作量。

这场缩小，MonkeyOCR 先从自己身上开刀

时间回到 2025 年 6 月。第一代 MonkeyOCR 发布时，总参数为 3B。它没有让一个大模型从头到尾直接"看图写 Markdown "，而是把复杂文档解析拆成三个非常直观的问题：它在哪里？它是什么？它们之间如何组织？

这三个问题分别对应结构检测、内容识别和关系预测。原本需要多个工具串联完成的任务，被整理为 Structure-Recognition-Relation，也就是 SRR 三元组。它的价值不只是一个新结构，更像是给模型写下了一组简单明确的提示词：先找位置，再认内容，最后恢复阅读关系。

仅一个多月后，团队又推出 MonkeyOCR-pro-1.2B。官方项目记录显示，这个版本更轻、更快，并在部分准确率比较中超过此前 3B 版本。也就是说，模型做小并不必然等于能力缩水；当任务被拆得足够清楚，很多原本堆在大模型里的参数可能并没有被高效使用。

一年后，MonkeyOCRv2 继续把总参数压到 0.6B 和 0.7B。但这一次，团队不是继续拆解解析流程，而是在 SRR 三个问题之前，再补上一个更基础的问题：你真的看清了吗？

△第一代 MonkeyOCR 用三个问题拆解解析流程；MonkeyOCRv2 把问题进一步前移到视觉入口。榜单里最小的两个模型，站到了最上面

MDPBench 的开源模型列表，几乎记录了文档 OCR 快速变小的过程：3B 的 dots.mocr、1.2B 的 MinerU2.5-Pro、1.0B 的 HunyuanOCR-1.5、0.9B 的 PaddleOCR-VL 系列，再到 0.6B 和 0.7B 的 MonkeyOCRv2。

通常情况下，模型越小，性能越难维持。但在这张榜单上，0.6B 的 MonkeyOCRv2-S 得到 82.5 分，0.7B 的 MonkeyOCRv2-B 得到 83.3 分，反而超过 3B 的 dots.mocr（80.5）。其中 0.7B 版本在拍照文档上达到 81.7，在非拉丁文字上达到 82.1，说明优势不只来自规整 PDF 或常见拉丁文字。

更值得注意的是参数被放在了哪里。MonkeyOCRv2-B 由 0.1B 视觉编码器和 0.6B 语言模型组成；dots.mocr 则大约是 1.2B 视觉编码器加 1.8B 语言模型。前者总参数不到四分之一，视觉编码器更只有约十一分之一。

这并不是普通意义上的"剪枝"。它更像是重新画了一遍模型的分工图：视觉端负责尽可能提供干净、完整的页面证据，语言端不再承担大量补字、猜字和修复结构的工作。参数像预算，真正重要的不是总额有多大，而是钱花在了哪里。

△在 MDPBench 论文对比中，0.6B 和 0.7B 的 MonkeyOCRv2 占据开源结果前两名。在三个问题之前，先问一句：你真的看清了吗？

文档与普通照片有一个根本差异。识别一只猫时，毛色变化、姿态变化甚至局部遮挡，并不会改变"这是一只猫"；自然图像模型需要学会忽略这些不影响大意的变化。

文档恰恰相反。"王"和"玉"只差一个点，可能对应完全不同的人；o 与 0 只是宽高比有区别，代表的是完全不同的涵义。一条公式横线、一处上标、一个表格边界，都可能直接改变答案。

论文展示的一个案例很直观：信息图上实际写着" 700,000 "，多种通用视觉编码器却读成了" 100,000 "。模型也许仍然理解图片在讲一组统计数据，但真正决定答案的那个数字，已经在视觉入口处丢了。大语言模型再聪明，也无法准确推理一条自己从未收到的信息。

△页面上真实写着" 700,000 "，多种通用视觉编码器却把关键数字读成" 100,000 "。

MonkeyOCRv2 因此采用两种互补的预训练目标：图像到文本生成让模型学习"页面写了什么"，像素级文档重建则要求视觉 Token 仍然保留足以恢复字符笔画、公式符号和版面结构的信息。

用更通俗的话说，文本生成教模型理解内容，重建则逼着它别太快忘记页面长什么样。这里的重点并不是让 OCR 系统最终输出一张重建图，而是通过重建训练，让更小的视觉编码器在压缩页面时少丢一些真正决定答案的细节。

模型可以更小，但不能把小数点、笔画和阅读顺序也一起"瘦"掉。

给 0.1B 的"眼睛"，喂一亿张文档，并把训练资源摆到公共桌面

小视觉编码器之所以敢承担更重的任务，底气来自训练数据。团队构建的 MonkeyDoc v2 包含 1.13 亿张文档图像，覆盖 17 种语言；其中 800 万张是完整页面，另外 1.05 亿个是文字、表格、公式等细粒度文档元素。数据中约 6100 万来自真实世界文档，5200 万为合成样本。

完整页面负责教模型理解版面、阅读顺序和跨区域关系；裁剪元素则提供字符、公式与表格级别的密集监督。这些样本也不只是规整扫描件，还包括论文、书籍、报刊、财务报告、网页、手写笔记、历史文字和拍照文档。

17 种语言也不是把同一套版式翻译 17 遍。阿拉伯语要从右向左阅读，中文页面可能包含竖排、密集字段和复杂表格，不同文字系统拥有完全不同的字形、阅读方向和文档生态。模型要学的不只是更多字符，而是更多种"页面如何成立"的方式。

△MonkeyDoc v2 由 800 万张完整页面和 1.05 亿个细粒度元素组成，覆盖 17 种语言。

△17 种语言对应不同字体、阅读方向和真实文档形态，而不是同一种模板的多语言翻译。

团队开源了这套一亿级的文档图像数据。对文档解析领域而言，这一点并不常见：很多模型会发布权重和推理代码，但真正决定能力上限的预训练数据仍然不可见。研究者可以运行模型，却很难从相同起点重新训练，更难判断提升究竟来自结构设计、训练目标，还是一份外界无法获得的私有资源。

小模型的意义不只在于显存占用和部署成本。更重要的是，它让社区有机会重新比较：性能提升究竟来自哪里。过去的文档 OCR 榜单中，最终数字是公开的，训练数据、数据配比和后训练流程却常常不可见。表面上比较的是模型，实际混在一起的还有私有语料规模、人工标注成本、训练预算和系统工程能力。

据 Github 显示，MonkeyOCRv2 开放了独立视觉编码器、0.6B 与 0.7B 解析模型、文档理解模型、训练 / 推理代码、部署示例和在线 Demo、以及 MonkeyDoc v2 数据。代码和模型权重采用 Apache License 2.0。这意味着后来者不仅可以调用 0.7B 模型，还可以重新训练它、替换预训练目标、修改数据配比，甚至用更小、更简单的方法超过它。公开数据不能自动消除算力差异，却能让更多实验从相对一致的起点出发。

榜单第一终究会被刷新，但一套能让别人重新训练、质疑并超越的开放数据，可能对整个领域的发展起到正面影响。

小参数，不是只赢一张榜

如果 0.7B 只在 MDPBench 上表现突出，它仍然可能只是一个针对单项榜单调好的系统。视觉底座是否成立，更关键的检验是：同一套编码器换到不同任务里，是否仍然有效。

MonkeyOCRv2 被接入文字识别、公式识别、文字检测、文档篡改检测、重叠文字分割、文档解析和文档理解七类任务。这些任务的输出形式完全不同：有的输出文字序列，有的生成 LaTeX，有的预测检测框、像素掩码、结构化页面或问答答案。

结果显示，更换视觉编码器后，多类系统均获得稳定提升。在传统文字识别中，CRNN 的综合结果由 58.7 提升到 67.3；即使在已经接近饱和的常见 OCR 基准上，CRNN 平均仍提升 2.3 个百分点，PARSeq 也进一步提升 0.4 个百分点，并超过此前最佳方法。

△同一 MonkeyOCRv2 编码器迁移到七类文档任务，均带来绝对性能提升。

公式识别给出了更直观的"小模型反超大模型"。将原有视觉编码器替换为 MonkeyOCRv2-S 后，一个约 110M 参数的 UniMERNet-T，在总体精确匹配率上超过了 325M 参数的 UniMERNet-B。

在文字检测、文档篡改检测和重叠文字分割上，MonkeyOCRv2 还分别带来 3.3、7.5 和 5.3 个百分点提升。一个底座能同时改善识别、检测、分割、解析与理解，说明它学到的并不是某个解码器专用的技巧，而是一套可以被不同系统继续使用的文档视觉表示。

效率的下一问：压缩之后，还记得什么？

当同一套视觉编码器能够迁移到识别、检测、分割、解析和理解等不同任务后，问题自然会继续向前推进：既然文档模型可以做得更小，那么一页文档还能不能用更少的信息来表示？

这也是 DeepSeek-OCR 切入的方向。

2025 年 10 月，DeepSeek-OCR 提出光学上下文压缩，把效率问题的衡量单位从"模型有多少参数"，进一步推进到"一页文档需要多少视觉 Token "。其论文报告称，只使用 100 个视觉 Token 就能超过 GOT-OCR2.0；在少于 800 个视觉 Token 的条件下，也能超过平均使用 6000 多个 Token 的 MinerU2.0。

DeepSeek-OCR 追问的是：一页文档究竟可以被压缩得多小？

但文档被压缩之后，还存在一个更难回答的问题：那些 Token 究竟保留了什么？如果字符笔画、小数点、公式符号和阅读顺序已经在压缩过程中消失，后端语言模型输出的内容再合理，也可能只是依据上下文完成的补全。

MonkeyOCRv2 正是在这里提出了"重建即视觉记忆"。

它不是要求 OCR 系统最终重新画出一张页面，而是把重建作为一种训练约束：如果视觉 Token 仍然能够恢复页面中的字符笔画、字形轮廓和版面结构，就说明这些细节没有在编码过程中被轻易忘掉。

因此，视觉 Token 数量衡量的是一页文档被压缩到多小；而重建能力检验的，则是压缩以后还剩下多少可靠证据。

压缩解决效率，视觉记忆决定忠实性。

真正减少的，是模型不得不猜测的部分

从 MonkeyOCR 的 3B，到 MonkeyOCR-pro 的 1.2B，再到 MonkeyOCRv2 的 0.7B，这条路线并不是简单地给模型"减肥"，而是在不断重新划分各个模块的职责。

第一代 MonkeyOCR 用"在哪里、是什么、如何组织"三个问题拆解文档解析，让模型先定位、再识别，最后恢复阅读关系。DeepSeek-OCR 继续压缩一页文档所需要的视觉 Token；OvisOCR2 则借助强化学习和蒸馏，进一步挖掘 0.8B 模型的能力上限。

MonkeyOCRv2 补上的，是这些路线背后更基础的一环：无论模型和视觉 Token 被压缩到多小，视觉端都不能先忘记页面上真正写了什么。

这也是"重建即视觉记忆"真正想表达的内容。模型可以更小，Token 可以更少，但那个决定人名的点、改变剂量的小数点、区分公式含义的横线，以及决定阅读顺序的版面关系，不能在进入语言模型之前就被丢掉。

因此，文档 OCR 下一阶段赛马的核心，可能不再只是更大的 LLM、更少的参数或更低的 Token 数量，而是更高的能力密度：让每一部分参数承担更明确的任务，让视觉端提供更可靠的证据，让语言端把容量真正用于理解，而不是用于猜测和修补。最终交付的，不只是一个更高的分数，而是一套能够被复现、比较和继续改进的文档解析能力。

0.7B 反超 3B 值得记住的，也不只是少了 2.3B 参数。它提醒行业重新思考：如果错误能够在视觉入口处避免，为什么还要把它留到后端，再用更大的语言模型补救？

大模型让 AI 更会思考，而小模型时代要求它先少忘一点。压缩决定一页文档能装进多少 Token；视觉记忆决定这些 Token 是否值得相信。

"重建即视觉记忆"，或许才是 MonkeyOCRv2 留下的、比一次榜单第一更长久的命题。

GitHub：https://github.com/Yuliang-Liu/MonkeyOCRv2

论文：https://arxiv.org/abs/2607.11562

数据：https://modelscope.cn/datasets/zenosai/MonkeyDocv2

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！

—  完  —

【学术投稿】请在工作日发送邮件至：ai@qbitai.com，标题注明【投稿】，并告诉我们：你是谁，从哪来，投稿内容附上项目 / 主页链接，以及联系方式。

� �   我们会 ( 尽量 ) 及时回复你 : )

� � 点亮星标 � �

科技前沿进展每日见股票科普