Unlimited OCR 2 – 百度开源的无限页数文档解析模型，KV 缓存压到 1.77GB

Unlimited OCR 2 是百度于 2026 年 10 月开源的长文档解析模型，用稀疏参考滑窗注意力把文本与视觉的交叉计算收进固定 512 个 token 的参考集，页面从几十页加到上千页，单步解码耗时与显存占用都基本不变，适用于把整本年报、技术手册或扫描档案一次性转成结构化文本的场景。

Unlimited OCR 2 的核心能力

先看表里三处会改变用法的地方：峰值 KV 缓存 1.77GB，决定单卡能同时压住几份文档；并发吞吐写的是 16 路 1315 Token/s，决定批量要排多久；推理框架给了 Transformers 与 SGLang 两条路，决定部署形态。

一整本书可以一次交进去

页数不设上限，整份文档直接传进去，不用先拆章拆节。实测 884 页英文版《指环王》一次解析完成，耗时 42 分 56 秒，平均每页约 2.9 秒。做法是把文本与视觉之间的交叉计算收进一组固定 512 个 token 的参考集，页数增加时计算量不跟着线性上涨。单页解析的用法见下方卡片，两代的分工在页数上限这一项。

跨页的段落与表格自己接上

长文档最容易错在两页交界：段落被切一半、表格跨页断行。它把分块与衔接放在模型内部完成，相邻块之间重叠一页并复用上一块的 KV，实测在 884 页输入里做了 466 处跨页合并。使用者照旧提交整份文档，不必手工拆页再拼。

页数往上加，单卡显存不再跟着涨

长文档解析的瓶颈常在显存：参考序列越长，缓存越大，到某个页数就超出上限。它的峰值 KV 缓存压在 1.77GB，页数往上加时这一项不再同步抬升，官方给出的测试环境是单张 A800-80GB。要估算同一张卡的并发份数，按这个缓存的量级折算。显存偏紧时还有轻量路线可选，站内的 PP-OCRv6 把模型体量压在 1.5M 到 34.5M。

批量并发能把吞吐吃满

16 路并发下吞吐 1315 Token/s，靠的是每路都走那套固定长度的参考集：单路加页不会拖慢其他路。整批合同、档案扫描与出版物入库这类场景，吞吐比单份速度更决定排队时间。

Unlimited OCR 2 与同类文档解析模型的对比

四款都做文档转结构化，差别在长文档怎么处理、权重能不能拿到、按什么口径计费。下表只填各家官方页面能查到的项，未公布的留空说明。

差别集中在三处。产品定位上，只有 Unlimited OCR 2 把页数当作不设上限，实测 884 页连续解析，另外三款按单份文档或单页处理。开源协议上，前三款都是开源许可，Mistral OCR 4 闭源、权重不开放。计价方式上，前三款的成本就是硬件与运维，Mistral OCR 4 按页计费，页数越多单价越显形。

两点口径需注意：基准得分只在本篇的参评模型之间可比，TeleOCR 报的是 OmniDocBench v1.6 总分 96.87，与本文引用的 MPDocBench、MarathonDocBench 不是同一套题，不能横向拉齐。另外三款的开源范围与部署要求，站内的 TeleOCR、OvisOCR2 与 Mistral OCR 4 分别有记录。

上一代的 Unlimited-OCR 走的是端到端长文档路线，在当时已经把 DeepSeek-OCR 的思路往前推了一步，站内对那一版有单独一页记录。

Unlimited OCR 2 的应用场景与适用人群

它的价值出现在文档足够长的环节；只做单张票据或证件识别，轻量 OCR 更划算：

• 年报与招股书解析：几百页的表格与附注一次读完，省掉拆页与手工拼接。
• 技术手册与标准文档：跨页条款、延续表格能自动接上，便于后续检索。
• 扫描档案数字化：成批的历史卷宗、卷本转成结构化文本，再进知识库。
• RAG 语料预处理：长文档先转成带层级的文本，切分与召回都更稳。

适用人群：适合做文档智能、档案数字化与知识库建设的技术团队，以及需要批量处理长文档的服务端开发者；只识别发票、身份证等单页卡证的场景，用轻量模型成本更低。

Unlimited OCR 2 的使用方法

官方给了三条路径：先读仓库说明，再按 Transformers 或 SGLang 两条推理路线接入。批量解析走 SGLang，单份验证走 Transformers。

读仓库说明与依赖清单

1. 打开 官方仓库，先看 Release 段落确认版本日期，再对照 What’s New in 2 了解本次改动。
2. 核对许可：仓库标注 MIT，权重与代码同许可。
3. 确认评测脚本与两个基准的数据准备方式，避免拿不同基准的分数互相比较。

Transformers 路线：先验证单份文档

1. 按 README 建 Python 3.10 环境，装 torch 2.13.0、transformers 4.52.1 与 tokenizers 0.21.4。
2. 参考 README 的测试硬件口径，官方验证环境是单张 A800-80GB。
3. 先用一份几十页的文档验证，确认输出结构与页序对齐，再换长文档。

SGLang 路线：服务端批量解析

1. 按 README 装定制版 SGLang wheel，再用 --mem-fraction-static 0.7 预留显存占比，给权重与 KV 留出余量。
2. 长文档需要页窗调度，相邻窗口复用上一窗的 KV 尾部，这项在服务端默认开启。
3. 按 --max-prefill-tokens 2048 控制预填长度，再据并发数压测吞吐。
4. 批量评测可复用仓库自带的 infer 脚本，把每份文档作为单个请求提交。

三点需留意：长文档解析的显存开销大头在视觉 token，页数上去后要按并发数反推单卡能开几路；SGLang 路线需要定制 wheel，不能直接换官方发行版；跨页合并依赖相邻块重叠一页，切分参数改动后要重新验证衔接质量。

Unlimited OCR 2 的项目地址

• GitHub 仓库（README 与推理脚本）：https://github.com/baidu/Unlimited-OCR
• Hugging Face 模型页：https://huggingface.co/baidu/Unlimited-OCR-2

Unlimited OCR 2 的价格与开源情况

代码与权重都按 MIT 许可开放，不收取授权费用，也没有按页计费的设计。真实成本落在硬件与人力：官方验证环境是单张 A800-80GB，长文档批量处理还要按并发数配卡，显存与吞吐的平衡需要自己压测。

这与表里 Mistral OCR 4 的按页计费是两种成本结构：前者是一次性的硬件投入加运维，后者随处理页数线性增长。要在本地做长文档解析又不想自己调服务端，站内另有 Unlimited-OCR 一代的独立页面，可先用它验证效果。

Unlimited OCR 2 的常见问题