百度Unlimited OCR 2开源：3.34B模型百页文档77.06分，显存降26倍

百度 ERNIE 团队在 10 月 27 日开源了 Unlimited OCR 2，3.34B 参数的文档解析模型，一次请求可读完上百页文档，MarathonDocBench 拿下 77.06 分，第二名 Kimi-K3 只有 33.74 分。它的关键设计 SR-SWA 稀疏参考滑窗注意力，把每步解码要看的视觉参考压到固定 512 个 token，配合分块复用 KV 缓存，峰值显存从 47.00 GB 压到 1.77 GB，单卡 A800-80GB 就能跑。

这篇把技术报告里的账算清楚：模型长什么样、SR-SWA 到底省在哪、长文档衰减有多明显、以及落地时有哪些坑。

从 OCR-2.0 到 OCR-3.0：这一代改了什么

传统 OCR 是多段流水线，先检测版面块再逐块识别，误差会沿流水线累积。OCR-2.0 把它压成一个视觉语言模型，直接把文档图像转成结构化文本。百度的上一代 Unlimited OCR 属于 OCR-2.0 的多页版本，用 R-SWA 参考滑窗注意力把文本历史压成固定窗口，但有个隐患始终没解决，解码时它仍然要在所有页面的视觉 token 上做注意力。文档越长，可视上下文越大，每一步解码的成本就越高。

Unlimited OCR 2 换掉了这个底座。官方把这一代称为 OCR-3.0，核心理由是长文档解析从几十页推到了几百页量级，而且每步开销基本不随长度变化。上一代 Unlimited-OCR 在 6 月 22 日发布，这次是它的第二代，代码和权重分别在 GitHub 与 Hugging Face 上放出，协议是 MIT。

仓库 GitHub star 数已经接近两万九千，fork 三千余个，属于开源 OCR 里热度最高的一档。模型卡标注的定位很直接，长文档解析的 SOTA，同时也是少见的能把百页级解析塞进单卡的开源方案。

SR-SWA 怎么把成本压平

整个设计的出发点是一个类比。人抄书时并不会把整本书一直摆在注意力中心，而是抄到第几页就看第几页，需要跨页引用时才回头瞥一眼。百度把这个稀疏性翻译成了两级路由结构。

第一级是 Page Gate。它把每个 query 的视觉参考范围从整篇文档收窄到指定的目标页面，同时给 token 位置做了分解，把位置拆成页级坐标和页内坐标两部分。页级坐标用一个交替的 0 到 1 的模式编码，页内坐标单调递增，这套处理是为了在页数增长时不让位置编码维度爆炸。

第二级是 Token Sieve。它在 Page Gate 给出的候选块里做 top-k 选择，路由打分用 entmax 产生稀疏分布，选中的块被赋予一个均值中心化的对数先验偏置，直接参与注意力 logits 计算。因为这个偏置在计算图里，解析任务的梯度能直接回传到路由模块，不需要额外的 KL 蒸馏损失做辅助监督。

落到具体配置上，稀疏块大小 32 token，远程选块 top-k 为 16，局部窗口 128 token。三者拼起来正好是官方所说的 512 个工作参考 token。模型最大位置长度 131072，每页固定消耗 273 个图像 token，一份百页文档就是 27300 个输入 token，而每步解码的延迟和显存几乎不随页数变化。

架构与配置：3.34B 里只有 500M 在动

模型继承自 Unlimited OCR 的骨干，以 DeepSeek-OCR 为基础，视觉侧是 SAM ViT-B 配合 CLIP-L 的 DeepEncoder，解码侧是 12 层混合专家结构。总参数 34.3 亿，每 token 激活 5 亿。64 个路由专家加 2 个共享专家，每个 token 走其中 6 个路由专家。隐藏维度 1280，词表 129280，BF16 权重约 6.7 GB。

训练侧的数据规模是 200 万份多页文档加 1000 万份单页文档，伪标签分别来自 MinerU2.5-Pro 和 PaddleOCR-VL-v1.6，再叠加合成文档生成管道补足版面多样性。后训练在 25 台 8 卡 H800 节点上跑了一个 epoch，全局批大小 1600，最大序列长度 64K，冻结了 DeepEncoder 与 aligner 只训 LLM，AdamW 优化器加余弦退火，初始学习率 2.5e-4，框架用的是 MS-Swift。

MarathonDocBench：77.06 分意味着什么

评测分两个层次。MPDocBench 覆盖最多 30 页的文档，MarathonDocBench 是这次新提出的基准，专门针对百页级解析，包含 100 份文档，页数跨度 103 到 300 页，标注了 20.5 万个版面元素，跨页表格和跨页文本的出现频率远高于 MPDocBench。指标覆盖正文编辑距离、公式 CDM、表格 TEDS、图形 F1、读序编辑距离，外加跨页专用的 T-TextEdit 与 T-TEDS。

百页级这个尺度上，差距被彻底拉开。Unlimited-OCR 2 是 77.06 分，Kimi-K3 33.74，Gemini-3.8-Flash 28.61，Qwen-3.8-Flash-Next 27.83，Gemini-3.1-Pro Preview 26.97，Qwen3.8-Max 22.93，MiniMax-M3 17.97，DeepSeek-4.1-Flash 12.34，GLM-5.3-Flash 7.51。上一代 Unlimited-OCR 因为 40 页的输入上限，没有资格出现在这张表上。

长文档衰减这一列才是真正的分水岭。Qwen3.8-Max 在三十页档位是 78.30 分，掉到百页档只剩 22.93 分，掉了 55 分。Unlimited OCR 2 从 84.59 掉到 77.06，只掉 7.5 分。前一代 Unlimited-OCR 在 MarathonDocBench 上是 0.0 分，因为根本跑不进去。

分项看，Unlimited OCR 2 的弱项也很清楚。标题层级识别是它的短板，Heading TEDS 只有 48.20 分，MPDocBench 上是 60.10 分，都低于自己其他分项。表格 TEDS 74.81，公式 CDM 87.93，图形 F1 71.79，读序编辑距离 0.147。跨页表格 T-TEDS 71.11 是全场最高，跨页正文 T-TextEdit 0.123 同为全场最低。

单页能力没有因为稀疏注意力被牺牲。OmniDocBench v1.6 上它拿到 94.02 分，和上一代的 93.92 几乎持平，在这一档排在 TeleOCR 96.91、OvisOCR2 96.47 之后，优于 Qianfan-OCR 93.90、Logics-Parsing-v2 93.33、FireRed-OCR 93.26，也高于 DeepSeek-OCR 2 的 90.25 和 dots.ocr 的 90.77。这一项对手是 DeepSeek-OCR 2、腾讯 WeVisOne-VL 那类多模态开源模型，比的已经不是单一文档题，而是复杂排版下的文字与图形混排还原能力。

效率账：47 GB 压到 1.77 GB 是怎么做到的

SR-SWA 只解决注意力范围，还有个显存问题要处理。标准解码会保留所有页面的视觉 KV 缓存，文档一长显存就线性涨到溢出。Unlimited-Horizon Decoding 范式把长文档切成带 1 页重叠的分块，顺序处理，每块复用上一块共享边界页的 KV 缓存，处理完的块立即释放。

延迟曲线的测量条件是 Gundam 模式、批大小 3、每页生成 1024 token。全注意力会随文档增长持续上升，R-SWA 因为远程视觉范围仍随序列增长而有累积延迟，SR-SWA 则把每个 query 的有效注意力范围钉死，所以从短文档到百页文档的每步延迟基本是一条平线。官方也给了失败点，超过 223 页时对比模型开始报错失败，Unlimited OCR 2 没有出现这类断点。

落地时的四个坑

部署分两条路。Transformers 路径适合快速验证，环境要求 Python 3.10、torch 2.13.0、transformers 4.52.1，模型需要 trust_remote_code 加载。单页走 infer 函数，默认用 gundam 动态切图；整份文档走 infer_multi，所有页面在一次请求里解析并保留跨页上下文。SGLang 路径是官方推荐的生产方案，用的是百度定制 wheel 而不是上游版本，版本号 sglang-0.5.20.dev10。

这里有几个明确的配置注意事项。页窗口默认 10 页，跨页内容在窗口边界被切断会削弱合并效果，窗口开小能压峰值显存但代价在这。SAM 注意力的 chunk 上限默认 512，会触发一次约 462 MiB 的额外分配导致显存耗尽，改成 64 效果等价但峰值更低。mem-fraction-static 设为 0.75 在 32 以上并发时余量不够，0.7 才稳。max-prefill-tokens 会驱动一个约为 tokens 乘 context 除 32 的临时张量，从 4096 降到 2048 能把该峰值减半。官方示例里还有一个 ngram 抑制的定制 logit processor，多页场景窗口设 1024，单页场景 128。

官方自己列了两条局限。训练数据的多样性仍偏有限，后继还需扩数据。稀疏注意力不保留全局文档信息，这对标题层级这类文档级结构的理解形成直接限制，标题 TEDS 只有 48.20 分就是这件事的后果，未来的方向是引入线性注意力这类每 token 计算量恒定的结构来补全局信息。

三类使用场景的实测对照

做长合同、招股书、研报解析的团队，MarathonDocBench 的跨页表格 71.11 分和跨页正文 0.123 编辑距离是决定性指标，前者是当前开源方案里唯一能同时保住跨页文本与跨页表格结构的。Cloudflare Clairic 那类文档提取方案走的是路由加调用的路子，长文档吞吐上限和上下文成本都受制于调用链，和单模型一次读完的思路正好相反，两者的对比数据可以放在一起看。

做单页或短文档高精度的团队，OmniDocBench 94.02 分说明稀疏注意力没有牺牲局部识别精度，DeepSeek-OCR 2 的 90.25 分可以作为同体量参照。

做推理成本敏感场景的团队，5 亿激活参数、单卡 A800 可跑、MIT 协议这三条把门槛压到了单卡级别，不需要像一些多模态方案那样依赖多卡或专用推理框架的定制分支。

常见问题

Unlimited OCR 2 和上一代 Unlimited-OCR 的核心区别是什么？上一代用 R-SWA 限制文本历史，但解码时仍要关注所有页面的视觉 token，百页量级下每步成本随文档增长。Unlimited OCR 2 换成分层的 SR-SWA，用 Page Gate 收窄到目标页面，再用 Token Sieve 在候选块里做 top-16 选择，把每步有效注意力范围固定在 512 token 水平，因此百页文档的单步延迟基本不涨。

77.06 分能直接信吗？这些数字全部来自百度自己的技术报告，评测脚本和基准 MarathonDocBench 也都由同一团队构建，官方在仓库里明确提示这是自报结果。MarathonDocBench 目前还没有第三方复现，所以这个分数更适合当作模型能力的上限参考，而不是行业公认基准。横向对比可以看，长文档衰减从 Qwen3.8-Max 的 55 分收窄到 7.5 分这个趋势，与稀疏注意力的机制设计是自洽的。

用一张 A800-80GB 能跑多长的文档？模型本身最大位置长度 131072，每页固定 273 个图像 token。生产部署推荐用 SGLang 加页窗口调度，把页窗口设为 10 页并开启分块复用，峰值 KV 显存可以控制在 1.77 GB 附近。单卡可行，但显存余量取决于并发数，mem-fraction-static 建议保持 0.7。

小结

Unlimited OCR 2 把长文档解析的竞争焦点从精度换到了成本结构。它在百页级基准上以两倍以上的差距领先，开源方案里第一次出现能靠单个 3.34B 模型、单卡 A800 读完上百页并保住跨页结构的选项。对做文档智能的团队来说，值得关注的其实是它公开的三组可复算数字，131072 的位置上限、273 的每页 token 成本、1.77 GB 的峰值显存，这三个数直接决定了百页级文档能不能放进一张卡里。

相关阅读

• 腾讯 WeVisOne-VL 开源：4B 模型统一七类视觉任务
• MOSS-Image 深度：5B 模型排版 0.88，长文本 96.3 分
• Cloudflare 发布 Clairic：文档提取 AI 让代理链路快 3 倍
• DeepSeek V4.1 Flash 深度解读：8B 输入激活、KV Cache 缩 437 倍
• Kimi K3.1 Pro 发布：Terminal-Bench 4.0 拿 65.7%