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

MonkeyOCRv2团队 投稿 
量子位 | 公众号 QbitAI

从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