Unlimited OCR 2：长文档解析，分步降低内存占用

1. 仅参考必要信息，复用页面分组

原有 Unlimited OCR 旨在保持文本工作内存恒定，但文档越长，每个生成步骤就越需要重新参考所有页面的视觉信息。新模型通过仅选择相关信息的稀疏参考滑动窗口注意力（SR-SWA）减轻这一负担。它不再同等程度地回顾整份文档，而是聚焦于与当前页面相关的部分参考信息。

另一种顺序处理方式则减轻了将整份文档持续驻留于 GPU 内存的负担。它将文档分成边界页面重叠的分组，复用保存边界先前计算结果的 KV 缓存，并释放当前分组之外的缓存。虽然只接收一次请求，内部却像翻书一样，仅将所需分组保留在内存中。

2. 按顺序一次传入页面图像

开发者可用 Transformers 快速试用，也可在服务运行中采用百度推荐的 SGLang。按顺序传入多个页面图像文件，即可在一次请求中解析整份文档，并利用页面之间的上下文。

以下是仓库中的多页示例。

pages = [f"your_doc/page_{i}.jpg" for i in range(1, 8)]

text, num_tokens = model.infer_multi(tokenizer, image_files=pages,
                                     output_path="output/multi", save_results=True)

百度在 Python 3.10 和 PyTorch 2.13.0 环境中进行了测试。

测试使用的模型库为 Transformers 4.52.1，GPU 为 NVIDIA A800 80GB。

模型的原始输出不是 Markdown，而是区分文档元素的结构化块字符串。仓库中的后处理工具会整理页面标记、标题层级、表格和坐标，将其转换为评测用 Markdown。

3. 百页评测得分高于对比模型

百度公开的 MarathonDocBench 包含 100 份长度为 103~300 页的文档，以及约 20 万个标注了位置和类型的布局元素。综合得分不仅评估文字识别，还涵盖表格、公式、阅读顺序及跨页结构等。据公司公布的数据，Unlimited OCR 2 得分为 77.06，高于对比模型中最高的 Kimi-K3 的 33.74。

表：MarathonDocBench 综合得分

条件：MarathonDocBench 的 100 份文档（103~300 页），技术报告表 2 中各模型的评测结果，以公司公布数据为准

单位：得分（%）

关键在于，这一结果来自跨页句子和表格丰富的评测。据公司公布的数据，在另一项最多涉及 30 页的 MPDocBench 评测中，该模型的综合得分为 84.59。

4. 通过页面分组降低内存占用，将运行负担转向配置与转换

据公司公布的数据，在百页规模下，逐步生成结果的解码速度为全注意力的 7.0 倍、先前参考方式 R-SWA 的 5.6 倍。这是在将页面图像拆分为小块（tile）进行处理的 Gundam 模式下，以一次处理的输入数量即批大小为 3、每页生成 1,024 个 token 测得的结果。

同一报告的 MarathonDocBench 测量显示，单次请求的 KV 缓存峰值内存占用从标准解码的 47.00GB 降至顺序分组处理的 1.77GB。公司公布，在 16 个并发请求条件下，吞吐量从每秒 360 个 token 增至 1,315 个 token。

开发者可以在一次请求中提交长文档，并降低 GPU 内存负担。相应地，在服务集成时，需要根据文档调整页面分组大小和输出预算，并将结构化输出转换为所需格式。

5. 侧重长文档处理，而非单页最高得分

据公司公布的数据，在单页评测中，下列两个对比模型的得分更高。这体现了与长文档处理不同的选择标准。

表：单页综合得分

条件：技术报告表 3 中的 OmniDocBench v1.6 评测结果，以公司公布数据为准

单位：得分（%）

较小的页面分组可降低峰值内存占用，但跨边界块的上下文可能被切断，从而影响合并质量。报告解释，稀疏注意力无法保留整份文档的信息，因此在标题层级等文档级结构理解方面也存在局限。

Unlimited OCR 2 通过抑制随文档长度增长的逐步计算负担，着重将多页解析转变为基于单次请求的服务。