OvisOCR2：0.8B击败流水线

0.8B 模型，把文档解析流水线压到了身后

阿里云在今天（2026 年 7 月 24 日）开源发布文档解析模型 OvisOCR2，并以 96.58 分刷新 OmniDocBench v1.6 榜单纪录。按照官方披露的结果，OvisOCR2 是首个在这一基准上超越流水线方法并登顶的端到端模型。

**OvisOCR2 是一个只有 0.8B 参数、可将文档图像直接转换为结构化 Markdown 的端到端文档解析模型。**它以 Qwen3.5-0.8B 为基础进行后训练，一次生成即可处理文本、公式、表格、视觉区域和自然阅读顺序，不再要求开发者分别部署版面分析、OCR、公式识别和表格恢复模型。

这次发布真正值得关注的地方不是“又一个 OCR 模型”，而是端到端路线第一次在 OmniDocBench v1.6 的综合分数上压过了传统流水线。根据IT之家对官方公告的转述，OvisOCR2 的综合得分达到 96.58，参数规模则仅为 0.8B。

不过，“端到端首次获胜”并不等于流水线已经过时。它更准确的含义是：对于一组标准化文档解析任务，单个生成式模型终于可以在综合质量上超过多个专用模型拼装而成的系统，同时将部署和维护复杂度压缩到更低水平。

文档解析不是把字认出来就结束

**文档解析是把 PDF、扫描件或文档截图转换为保留结构和阅读顺序的机器可用内容。**普通 OCR 主要解决“图片里写了什么字”，文档解析还要回答“标题属于哪一节”“左右两栏先读哪一栏”“公式和正文如何对应”“表格中的单元格是什么关系”等问题。

这一区别直接决定了企业知识库和 RAG 系统的上限。假设一篇双栏论文被 OCR 按照横向顺序逐行读取，左栏的一句话就可能和右栏的一句话拼在一起；即使每个字都识别正确，送入向量数据库的仍然是一段语义混乱的文本。

**RAG 是先检索外部资料、再由大模型生成答案的技术架构。**在 RAG 场景中，文档解析位于数据入口，解析阶段丢失的表头、章节层级和公式编号，后面的切分、向量化、召回与重排通常无法自动补回来。解析模型看似只是基础组件，实际上决定了知识库能否正确理解原始资料。

复杂表格是另一个典型难点。传统 OCR 可以识别“2025”“收入”“同比”等文字，却未必知道这些内容分别属于哪一行、哪一列；如果跨行和合并单元格关系恢复错误，模型最终可能把上一季度的收入归到下一季度名下。

因此，OvisOCR2 输出 Markdown 的意义并不只是格式整齐。Markdown 可以保留标题层级、列表、代码或公式块以及表格结构，也更容易接入文档切分器、搜索索引和大模型上下文，减少从视觉文档到下游应用之间的格式转换。

端到端究竟省掉了什么

**传统文档解析流水线是由版面分析、内容识别和结果拼接等多个模块串联而成的处理方案。**版面模型先找出标题、正文、图片和表格区域，OCR 模型再识别文字，公式与表格往往还要交给独立模型，最后通过规则恢复阅读顺序并合并输出。

流水线的优势是每个模块都可以独立替换和调试。某一批财务报表的表格识别效果不好，团队可以只升级表格模型；某类合同存在固定页眉，也可以直接加入规则过滤，而不用重新训练整个系统。

流水线的代价则是误差会逐级放大。版面分析一旦漏掉某个区域，后面的识别模型连补救机会都没有；版面框如果切断了一行公式，公式识别模型看到的就是残缺输入；最后的阅读顺序算法即使正确，也只能排列一组已经出错的内容块。

**端到端文档解析是由一个模型直接学习从页面像素到结构化结果的映射。**OvisOCR2 接收一张文档图像，在一次生成过程中输出符合自然阅读顺序的 Markdown，让文字识别、版面理解、结构恢复与内容排序在同一个训练目标下联合优化。

两条技术路线的差异可以概括为：

| 对比维度 | OvisOCR2 端到端方案 | 传统流水线方案 | |---|---|---| | 核心模型规模 | 0.8B 参数 | 通常由多个不同规模模型组成 | | 主处理链路 | 文档图像直接生成 Markdown | 版面检测、区域裁切、分类识别、规则拼接 | | 文本与结构 | 在同一次生成中联合处理 | 由不同模块分别处理后合并 | | 阅读顺序 | 模型直接生成自然阅读顺序 | 依赖版面结果与排序规则 | | 误差传播 | 可能出现生成遗漏或结构幻觉 | 容易发生上游错误向下游累积 | | 部署维护 | 主链路集中，组件更少 | 多模型、多服务和多套依赖 | | 问题定位 | 内部决策较难解释 | 可以逐模块检查中间结果 | | 规则定制 | 需要提示、后处理或再训练 | 更容易插入领域规则 | | OmniDocBench v1.6 | 综合得分 96.58 | OvisOCR2 已超过榜单中的流水线方法 |

端到端模型最大的产品价值是减少“胶水工程”。在企业部署中，困难往往不是把几个开源模型跑起来，而是处理模型版本、显存调度、图片裁切、坐标映射、超时重试和输出协议；模型越多，边界条件和维护成本就越多。

但端到端模型也把一部分可解释性换成了整体效果。流水线可以告诉开发者某张表失败在版面检测还是单元格恢复，生成式模型则可能直接漏掉一行内容、改写字符或输出结构合法但事实错误的 Markdown，排查起来更像在调试大语言模型。

0.8B 为什么能做到 96.58 分

**OvisOCR2 的核心策略不是扩大参数，而是用针对文档任务的数据与多阶段后训练压榨小模型能力。**官方信息显示，团队构建了真实文档与合成文档互补的数据引擎，并采用监督微调、强化学习、在线策略蒸馏和模型融合四个训练阶段。

真实文档负责提供自然分布。真实世界里的 PDF 存在扫描噪点、字体差异、复杂排版、低清图片和不规则表格，这些问题很难完全通过模板模拟，也是模型进入生产环境后必须面对的长尾输入。

合成文档负责定向补齐困难样本。OvisOCR2 团队重点合成了表格与公式交织、多栏版式以及长输出等场景，这种方式类似给模型安排专项训练：不必等待互联网上自然出现足够多的极端案例，而是主动控制版式、内容与难度。

**监督微调（SFT）是使用成对的输入与标准答案训练模型按目标格式输出。**在文档解析中，输入是页面图像，目标答案则可以是包含文本、公式和表格的 Markdown；SFT 先让模型掌握任务形式和基本输出规范。

**强化学习（RL）是利用奖励信号进一步优化模型行为的训练方式。**对于文档任务，奖励可以围绕内容准确性、结构完整性与格式约束设计，使模型不只模仿训练答案，还能朝着可评估的解析目标继续优化。

**在线策略蒸馏（OPD）是让较小模型在训练过程中持续学习更强策略行为的方法。**它的价值在于将更强模型或更优策略的能力压缩到 0.8B 模型中，而不要求部署时继续携带一个大参数教师模型。

模型融合则承担了整合不同训练阶段能力的作用。官方目前公开信息没有给出具体融合算法和各阶段增益，因此不能简单判断 96.58 分分别有多少来自数据、RL 或蒸馏，但四阶段流程至少说明，这不是仅靠扩大合成数据规模得到的结果。

0.8B 的参数规模尤其值得重视。文档解析是高频前置任务，企业可能需要连续处理数十万页历史资料；在效果接近时，紧凑模型通常更容易获得较低延迟和更高吞吐，也更适合私有化部署。不过，官方尚未同步披露固定硬件上的 tokens/s、单页延迟、峰值显存和批处理吞吐，因此目前还不能把“小参数”直接换算为具体成本优势。

96.58 分意味着什么，又不意味着什么

**OmniDocBench v1.6 是用于综合衡量文档解析能力的基准版本。**OvisOCR2 在这一版本上获得 96.58 分，证明端到端模型已经可以同时处理文本、公式、表格、视觉区域和阅读顺序，而不是只在单一 OCR 字符准确率上领先。

96.58 分最重要的信号是技术路线发生了变化。过去，团队选择端到端方案通常意味着用更简单的工程结构交换一部分精度；现在至少在 OmniDocBench v1.6 上，OvisOCR2 同时拿到了更简洁的链路和更高的综合分数。

96.58 分仍然不能替代生产验证。基准数据通常无法覆盖每家企业的印章、手写批注、工程图纸、竖排古籍、超大表格和内部模板，一套在公开榜单领先的模型，也可能在某个垂直行业输给经过多年规则积累的流水线系统。

当前公开信息还缺少几组关键数字：

• 不同语言、表格、公式和阅读顺序任务的分项成绩；
• 与第二名及最佳流水线方案之间的具体分差；
• 不同分辨率和页面尺寸下的精度变化；
• 单页延迟、吞吐量、首 token 时间与峰值显存；
• 超长页面、多页 PDF 和连续批处理的稳定性；
• 对模糊扫描、旋转页面、水印和手写内容的鲁棒性。

因此，OvisOCR2 可以被视为端到端路线的重要里程碑，但还不能仅凭一个综合分数宣布所有传统方案退出历史舞台。对于需要严格审计的金融、医疗和法律文档，结构校验、字段规则和人工复核仍然不可缺少。

Apache 2.0 开源，真正利好的是私有文档场景

**Apache 2.0 是允许使用、修改、分发及商业应用的宽松开源许可证。**OvisOCR2 采用 Apache 2.0 许可证发布，并兼容 vLLM 等主流推理框架，与 Qwen3.5 的推理生态衔接，这降低了开发者将模型接入现有服务的门槛。

开源对文档解析尤其重要。合同、病历、财务报表和内部研究材料通常不适合离开企业网络，自行部署可以让原始页面和解析结果停留在本地环境，也便于团队控制模型版本、日志保留与访问权限。

兼容 vLLM 的价值则在于工程复用。已经使用千问系列模型和 vLLM 的团队，可以沿用现有调度、批处理和监控体系，而不是为一套 OCR 专用运行时重新建设服务。不过，实际部署前仍需核对模型仓库中的依赖版本、图像预处理方式、许可证说明和推荐推理参数。

OvisOCR2 也可能改变文档 AI 项目的成本结构。过去一个完整系统需要分别评估版面、文本、公式和表格模块，现在团队可以先用一个 0.8B 模型建立统一基线，只对失败率较高的垂直场景增加规则或专用模型。

谁应该马上试，谁不必急着迁移

**正在搭建企业知识库、论文解析或 PDF 问答系统的团队最值得优先测试 OvisOCR2。**这些场景重视阅读顺序和 Markdown 结构，同时需要处理大量文档，端到端、小参数和可私有部署三项特征都能直接转化为工程收益。

已有成熟流水线的团队不必立刻全部重写。更稳妥的方式是建立一套包含真实业务文档的对照集，同时比较字段准确率、表格结构、公式还原、单页延迟、显存占用和人工修订时间，而不是只比较公开榜单总分。

高风险行业应当把 OvisOCR2 当成解析引擎，而不是事实来源。生成式模型可能输出格式完美但内容有误的结果，因此金额、日期、身份证明、医疗指标等关键字段仍需要原图定位、规则校验或双模型复核。

**OvisOCR2 的最大意义，是证明小型端到端模型不再天然等于低精度。**0.8B 参数、96.58 分和 Apache 2.0 开源放在一起，使它不仅是一个榜单模型，也可能成为企业文档解析的新默认基线。

这场胜利目前仍然带有限定条件：它发生在 OmniDocBench v1.6 上，生产性能数字也尚未完整披露。但对开发者来说，选择已经发生变化——过去要先问“需要拼多少个模型”，现在可以先问“一个 0.8B 模型是否已经够用”。

参考来源

• IT之家：阿里开源 0.8B 文档解析模型 OvisOCR2——汇总官方发布信息、OmniDocBench v1.6 成绩、训练方案与开源许可证。
• Hugging Face：OvisOCR2 模型检索页——用于查找模型仓库、模型卡、权重文件及后续版本更新，具体使用要求以仓库说明为准。