菜单
English articles本文暂无译文
积墨AI

积墨AI

百度开源无限上下文OCR:三百页文档一次解析,显存占用骤降至1.77GB

当企业需要将数百页的招股书、设备手册或历史档案数字化时,传统OCR方案往往显得力不从心。它们通常采用逐页处理模式,将文档拆解为单页图像依次识别,再拼接结果。这种方式不仅效率低下,更致命的是跨页信息的割裂——表格被截断、段落首尾分离、页眉页脚错位频发。更困扰开发者的是,模型每处理一页就会遗忘上一页的内容,导致三百页的文档在模型眼中变成了三百个毫无关联的碎片。2026年10月27日,百度开源的Unlimited-OCR 2试图从根本上解决这一问题:让模型像人类一样,以整本而非单页为单位阅读文档。

从逐页处理到无限上下文

理解这一突破需要回顾OCR技术的发展脉络。早期的流水线式OCR依赖多个独立模型分别处理版面检测、文字识别、表格识别等环节,模块间的误差会逐级累积,端到端精度受限。此后出现的端到端视觉语言模型将整页图像直接转换为Markdown输出,消除了流水线中的中间环节,单页识别能力大幅提升。然而这类模型存在一个根本性限制:它们的记忆范围仅限于当前页面。要处理多页文档,只能在外部循环中反复调用模型,每处理一页便清空上下文重新开始。这种设计使得三百页文档在模型眼中变成了彼此孤立的三百个独立任务,跨页结构信息的丢失不可避免。

Unlimited-OCR 2的核心创新在于SR-SWA(稀疏参考滑动窗口注意力)机制,它的设计灵感源自人类抄书时的视觉习惯。当人们手工抄写长文档时,视线通常只聚焦在正在抄写的当前页、刚刚写下的几行文字,以及偶尔翻阅的参考页——这是一种天然的稀疏注意力模式。SR-SWA正是将这一行为模式翻译为注意力掩码:页面门机制通过学习判断每个查询token属于哪一页,从而将检索范围从整本文档收缩至当前页及其相邻页面;令牌筛机制则从候选块中进一步筛选出与当前查询最相关的16个块,每个块32个token,加上固定的局部窗口128个token,总计640个token构成实际参与计算的上下文。这套机制使得注意力预算与文档总长度完全解耦,无论文档是十页还是三百页,每个token实际处理的token数量恒定为640个。

长文档解析的成败,不在上下文窗口的大小里、不在参数量级里,而在每一次注意力计算的精准取舍里。

“行业观察”
积墨 AI 核心产品

积墨 AI 智能体开发平台

快速搭建具备商业价值的 AI 智能体,支持复杂工作流编排、50+ 主流模型接入与私有化部署。

稀疏注意力的工程智慧

稀疏注意力解决了计算量问题,但三百页文档的视觉KV缓存仍需完整预填充,这部分显存占用高达47GB。Unlimited-OCR 2引入的无限视野解码机制将文档按固定页数切分为多个段落,相邻段落通过共享边界页的KV来实现跨段连续性。以每10页为一个段落为例,第一段处理完成后释放除边界页外的所有KV,第二段直接复用边界页的缓存继续推理,GPU显存中始终只保留一个完整段落的缓存数据。这套方案将单序列推理峰值KV Cache从47GB压缩至1.77GB,降幅达26.6倍;在16路并发场景下,吞吐量从360 TPS提升至1315 TPS,提升3.6倍。效率曲线在30页至300页区间几乎保持水平,而主流视觉语言模型的延迟则随页数增长呈线性甚至超线性上升。

性能基准与实用价值

在新建的MarathonDocBench基准测试中(100篇100-300页文档,含20.5万个标注版式元素),Unlimited-OCR 2取得77.06分,而第二名Kimi-K3仅有33.74分——这意味着现有模型在超长文档场景下并非略微落后,而是几乎没有建立有效的解析能力。在中等长度文档的MPDocBench上,Unlimited-OCR 2达到84.59分,领先Qwen3.8-Max达6.3分,其中跨页表格识别指标T-Table TEDS高达89.54分。更值得关注的是单页能力的保持:在OmniDocBench v1.6上取得94.02分,与前代版本基本持平,证明稀疏化改造并未以牺牲细粒度识别为代价。该模型已在Hugging Face开源,采用MIT许可可商用,提供Transformers快速验证和SGLang生产部署两种接入方式,配套详细的部署参数调优指南。

Unlimited-OCR 2的意义不仅在于刷新长文档OCR的性能榜单,更在于其方法论的示范价值:与其追求越来越大的上下文窗口,不如深入理解模型在实际任务中真正需要访问哪些信息。这一思路可推广至语音识别、机器翻译等输入为长参考、输出为长序列的任务类型。三百页一次读完,仅仅是开始。

#稀疏注意力机制#SR-SWA#长文档OCR#KV Cache优化#视觉语言模型#文档解析
分享文章

相关文章推荐

试用咨询
企业微信二维码

扫码添加企业微信