长文档 OCR 新王者 Unlimited-OCR:3B 小模型打爆全场

Unlimited-OCR：3B 小模型，一次性吃掉 40+ 页 PDF 的长文档 OCR 新范式

一句话版：这不是又一个“能 OCR 的大模型”，而是一个把长文档 OCR 工程问题彻底打通的、真正可以落地的端到端方案。

1. 为什么又需要一个「Unlimited」OCR？

做过长文档知识库、RAG 或文档中台的同学，大概率都踩过这些坑：

• 每页单独 OCR，后处理重新拼装：段落错序、跨页表格断裂、页眉页脚乱入正文。

• 多模块管线（检测-识别-版面分析-结构重建）：模型越叠越多，调参和容错地狱。

• 想上端到端 DocVLM，又被长序列的二次注意力、KV Cache 炸显存劝退。

传统 Transformer 自注意力的复杂度是 O(n2)O(n^2)O(n2)，序列长度翻倍，时间和显存直接翻四倍，长文档场景基本是「能跑就不错了」，谈不上优雅。 Unlimited-OCR 走的是另一条路：

• 模型只有 3B 参数（有效激活约 500M）。

• 用创新的 R-SWA（Reference Sliding Window Attention） 解决长上下文「记不住」的问题。

• 用 DeepEncoder 做 16× 视觉压缩，从源头上解决长文档图像 token 爆炸。

• 一次前向就能解析 40+ 页 PDF，而不是“逐页跑 + 离线拼接”。

更关键的是，它在 OmniDocBench v1.6 上拿到 93.92% 的端到端文档理解 SOTA，文本编辑距离降到 0.038，对公式和表格尤其友好。

2. Unlimited-OCR 到底是什么？

官方一句话定位：

迎接单次长时程解析的时代

核心信息（偏工程视角）：

• 模型规模：约 3B 参数，BF16 权重，激活约 500M。

• 能力范畴：端到端文档解析（文本、表格、公式、布局整体理解）。

• 上下文长度：官方配置到 32768 token，配合 R-SWA 可以稳定吃下 40+ 页 PDF。

• 推理形态：

• HuggingFace Transformers 本地推理。

• SGLang 部署为 OpenAI 风格 Chat Completions API。

开源资源：

• GitHub：<https://github.com/baidu/Unlimited-OCR>

所以，你可以把它当成：

• 一个可直接部署的 长文档 OCR 专用 DocVLM；

• 也是一个对现有知识库、RAG 系统几乎零侵入即可「升级成长文档一把梭」的组件。

3. R-SWA：把 Sliding Window Attention 用到极致的「人类式抄写」

3.1 先复习一下 SWA 在长序列里干了什么

标准自注意力：每个 token 看全局，复杂度 O(n2)O(n^2)O(n2)。 Sliding Window Attention（SWA） 的思路是：

• 每个 token 只看自己两侧固定窗口大小 www 的邻居。

• 复杂度变成 O(n⋅w)O(n \cdot w)O(n⋅w)：对 n 线性，对 w 线性。

• 堆多层 SWA 后，有效感受野 ≈ L⋅wL \cdot wL⋅w（L 是层数），可以间接覆盖长距离依赖。

SWA 已经被广泛用在各种长上下文 LLM 里，用来让 KV Cache 从「炸死你」变成「还能用」。 但在文档 OCR 上，单纯 SWA 有两个硬伤：

• 跨页 / 跨段的远距依赖（比如长公式、跨页表格）容易被切断。

• 对一些“锚点信息”（页眉、页脚、章节标题）无法做稳定的长程对齐。

3.2 R-SWA 的直觉：像人类一样抄长文档

官方的描述很形象：

模型在生成时，只看「原始文本」和「刚刚抄过的几行」，像人一样抄长文档。

可以粗暴理解为：

SWA + 参考通路（Reference） = R-SWA

在具体实现上，它仍然保持局部窗口的线性复杂度，但通过「Reference 路径」给模型一个全局 anchor，例如原始页面特征、历史关键信息等。这样一来：

• 局部窗口负责当前 token 周围的细节一致性（行内、邻近段落）。

• Reference 通路负责跨页、跨段、全局结构的一致性。

工程含义是：

• KV Cache 大小和计算复杂度 依然近似线性，不会像全注意力那样炸。

• 模型不会再出现典型 SWA 的「只记得局部，看不见远处」问题，特别在长 PDF 中，能稳定保持章节 / 表格 / 公式跨页的一致性。

如果你平时玩 LLM 长上下文，R-SWA 可以当成是：

• 介于「只用 SWA」和「加周期性全局注意」之间的折中；

• 通过“人类抄写式” reference 机制，在保持结构简单的前提下，实现更强的全局感知。

4. DeepEncoder：先把视觉 token 压到 1/16，再谈长文档

长文档 OCR 的另一个老大难问题，是视觉 token 数量：

• 一页 300dpi 的 A4 PDF，切成 patch 很容易就是几千甚至上万个视觉 token。

• 多页拼起来，Transformer 还没开始“理解”，显存已经顶满。

Unlimited-OCR 的做法是加了一个专门为长文档设计的 DeepEncoder，把视觉特征先压一遍，做到大约 16× 的压缩。 这里的关键点是：

• 不只是简单 pooling，而是结合布局线索，尽量保留：

• 表格网格线、单元格边界。

• 公式结构、上下标对齐。

• 列表层级、缩进、章节结构这些 layout cue。

• 这样一来，后面的 R-SWA 注意力层面对的是「压缩后的结构 token」，而不是原始高分辨率 patch。

• 既节省了显存和算力，又不给表格/公式/结构理解挖坑。

从 VLM 设计视角看，这其实是把“Layout-aware Visual Pooling”内置成了一个标准组件。 对工程师来说意味着：你不再需要在上游手搓一堆表格检测、版面分析模块，再想办法 hack 到 LLM 里。

5. 性能：3B 模型打穿端到端文档 SOTA

几个硬指标值得单独拎出来说：

• 模型规模：3B 参数，激活约 500M。

• OmniDocBench v1.6：93.92%，端到端文档理解 SOTA。

• 文本编辑距离：0.038，公式、表格部分改进显著。

• 推理性能：

• 在保持接近常数级显存的情况下，比前一代方案快约 35%。

• 单次前向稳定处理 40+ 页长文档，延迟随页数近似线性增长，而不是二次爆炸。

这些指标对落地的意义：

• 硬件侧：很多场景可以从“大卡 + 大模型”降级到“中卡 + 3B BF16 模型”，成本立刻可见。

• SLA 侧：文档变长只是线性变慢，很容易做扩容策略和队列调度。

• 质量侧：跨页表格、长公式、附录编号这些过去最容易翻车的地方，端到端模型天然更稳，不需要你写一堆规则硬拼接。

6. 实战上手效果

可以看到速度相当快而且是连续解析，实时结果生成

7. 和现有方案怎么配合 / 取代？

7.1 和传统 OCR 管线

适合直接替代的场景：

• 长报告、年报、招股书、说明书、论文集这类「结构复杂 + 页数多」的文档。

• 之前靠 PaddleOCR / Tesseract 做检测+识别+版面分析再手搓规则拼表格的项目。

适合共存的场景：

• 超大规模批量短文档（比如发票、送货单），传统轻量 OCR 仍然成本更低。

• 对实时性要求极高、单页简单的场景。

7.2 和通用 VLM / LLM

大模型的优势是「多任务 + 多模态 + 复杂推理」，但在专用长文档 OCR上：

• 通用 VLM 容易「能看懂但抄不准」，结构化输出不稳定，格式经常乱。

• Unlimited-OCR 属于对文档场景高度对齐的专用 DocVLM：

• DeepEncoder：为文档视觉优化。

• R-SWA：为长文档高效注意优化。

• 解码约束：为文本抄写 / 结构输出优化。

比较自然的架构是：

• 下游问答 / RAG / Agent：继续用通用 LLM（DeepSeek, Qwen, GPT 等）。

• 上游文档解析：统一收敛到 Unlimited-OCR，产出结构化文本 / Markdown / 中间 schema。

8. 对工程 / 产品的启发

从 Unlimited-OCR 的设计，可以提炼出几个对我们做系统设计有用的思路：

1. 先把视觉压缩和注意力结构写对，再谈模型规模  3B + 高效结构，能完成很多以前认为需要几十 B 的事情。

2. 长文档不必死磕「全局注意」  通过 R-SWA 这类「参考式」注意力 + 合理的训练范式，完全可以在近似线性复杂度下拿到全局一致的结果。

3. 部署统一用 Chat Completions 是条好路  SGLang + OpenAI 接口，把所有模型变成「兼容 OpenAI」之后，上层只写一次编排逻辑，以后换模型等价于改 environment config。

4. 把文档解析当成一个独立产品能力，而不是 OCR 子模块  Unlimited-OCR 的设计把「长文档端到端解析」提升到和 LLM/RAG 同一个层级，这对很多企业知识中台是一个很重要的观念转变。

如果你觉得这篇文章对你有帮助，也欢迎给我一个三连击：点赞、转发和在看；如果可以，再帮我点一个⭐️。谢谢你看到这里，我们下篇再见。