KV Cache被压成常数！OCR开源新王：页数没上限，缓存砍96%

为此，文心Unlimited OCR 2提出稀疏参考滑动窗口注意力机制SR-SWA，让模型按需选取相关页面和视觉信息，减少重复计算。

配合持续解码机制，模型能够连续处理超长文档，单步解码开销也不会随着文档变长而水涨船高。

目前，文心Unlimited OCR 2已在Hugging Face和GitHub正式开源。

开源地址：

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

HuggingFace：https://huggingface.co/baidu/Unlimited-OCR-2

拆解核心技术：SR-SWA怎么少算，分块解码怎么少存

连续读完几百万字、3600+页的《哈利波特》全集，文心Unlimited OCR 2究竟是怎么做到的？

它借鉴的，其实是人类抄书的思路。

人手抄书时是什么流程？看一段、抄一段，眼睛主要盯着正在抄的那一页；只有遇到需要前后对照的地方，才回头翻一翻相关页面。

抄书这件事，人类比模型更早就想明白了：没人会一边抄《论语》，一边在脑子里同时把《论语》全部页数摊开一起看。

但上一代Unlimited OCR不是这么干的：虽然通过R-SWA已大幅降低推理阶段的KV缓存，但再回看的过程中，所有输入页面的视觉信息依旧都要参与注意力计算。

文档越长，算的信息越多，而其中相当一部分，跟当前正在识别的那几行字压根没关系——典型的「陪跑」。

△SR-SWA借鉴人类抄书时的局部聚焦方式

顺着人类抄书的思路，文心Unlimited OCR 2引入了稀疏参考滑动窗口注意力机制（SR-SWA）。

它的筛选分两层：先把需要参考的页面筛出来，再从筛出来的页面里挑出真正相关的局部信息，把无关计算挡在门外。

从整体架构看，文心Unlimited OCR 2延续了上一代的基础设计。

△文心Unlimited OCR 2整体架构

书页图像先进入DeepEncoder，被转成模型能处理的视觉Token——可以理解成一组记录页面内容与版面特征的数据卡片。

接着，语言模型根据这些卡片，一步一步生成识别结果。

关键变化就发生在语言模型内部：上一代采用的参考滑动窗口注意力机制（R-SWA），在这一代升级为SR-SWA。

架构图中左下方展示的，就是SR-SWA的两层筛选过程。

第一层是Page Gate，管「该看哪几页」。

它根据模型当前解析到的位置，把候选视觉信息收拢到相关页面范围内，不让无关页面来凑热闹。

放到抄书的场景里，就像读到某一页时，先找到与这一页相关的几个页面，而不是从头翻遍整本书。

第二层是Token Sieve，管「这一页里该看哪几行」。

选对页面只是第一步：即使在这些页面中，也不必让所有视觉Token都参与计算。Token Sieve会再做一次筛选，从页面里挑出与当前内容更相关的视觉信息块，以捕捉长距离视觉依赖关系。

架构图右侧展开了这一过程：先用各个信息块的简要表示算出相关性，再通过TopK挑出得分最高、数量固定的信息块。

挑完之后，模型仍然会去看这些块中的具体视觉信息，而不是只看个摘要。

两层机制配合，让模型既能在长文档中找到相关页面，又能减少每一步需要处理的视觉信息，从而提升长文档解析效率。

△Token Sieve细节

筛选出的视觉信息，还会与图中的Local Window（局部滑动窗口）一起参与解析。

这个窗口大小固定，装着最近的上下文，并随着生成过程一路向前平移，负责让模型顺着刚才的内容往下写。

信息块数量固定，局部窗口大小也固定，每一步需要参考的信息量就被框住了——文档再长，这一步还是这么多活儿。不会出现「书越厚、每写一个字越费劲」的情况。

SR-SWA负责的是每一步少算点；而显存里到底要留多少信息，则是另一个问题。

每页图像经过编码，都会变成一组视觉Token。模型生成解析结果时要参考它们，因此会存下对应的KV缓存，供后续计算复用。

如果一次性读入整份文档，再把所有页面的视觉缓存都留在显存里，页数越多、占的地方越大。

更麻烦的是：哪怕这些页面根本没参与当前计算，只要缓存没释放，它们照样占着显存不走。这就好比抄书时把每页草稿都摊在桌上，一页不扔——桌子再大也不够用。

所以，少算一些，还得配合少存一些。

文心Unlimited OCR 2为此引入了无限解码机制（Unlimited-Horizon Decoding Paradigm），通过分块处理控制缓存占用。

△分块解码示意图

这套机制把文档划成大小可控的页面块，依次解析。相邻两块重叠一页，上一块的最后一页，也是下一块的起点——一枚现成的书签。

进入下一块时，模型直接复用这页重叠页的视觉KV缓存，同时保留上一段输出末尾的文本缓存，让前后内容接得上。其余已经用不上的页面视觉缓存，就及时释放，腾出显存。

这样一来，显存里需要保留的视觉缓存，就被压在当前处理块的规模内。处理完一块，留下衔接所需的信息，再开下一块——不必让整份文档的视觉缓存从头到尾占着位子。

*SR-SWA负责减少每一步的计算，无限解码机制负责控制缓存占用。两者配合，才能让模型持续解析超长文档。 884页《指环王》42分钟读完，缓存降到1.77GB 技术讲了这么多，我们也想亲眼看看效果：直接丢给它一份884页的英文版《指环王》。

大约42分56秒后，解析完成。884页输入，对应884页输出，平均每页耗时约2.9秒。 差不多是一集电视剧的功夫，「中土世界」就走完了一整趟。 这么长的文档，处理到后面，识别效果还能跟得上吗？ 我们特意抽查了第600页和第750页的正文：识别文本与原文一致。翻到第750页还能一字不差，说明模型没在前面「读嗨了」。

整个任务中，系统还标记了466处跨页合并。比如接近书末的第873至874页，被分页硬生生截断的句子，也在输出中重新接了回去。

实测展示了整本书连续解析的过程，技术报告则回答了另外三个问题：需要多少缓存、能有多快、识别质量又如何。 在百页级基准MarathonDocBench上，团队把标准解码与Unlimited-Horizon Decoding摆在一起做了对比。 单序列推理时，采用分块处理和边界缓存复用后，峰值KV缓存占用从47GB降至1.77GB，减少约96%。*

原本需要同时留在显存里的大量页面信息，现在可以分批处理、及时释放。这里的1.77GB仅指KV缓存，模型权重等其他显存开销另计。

省缓存之外，报告还测了多份文档同时处理时的表现。

在另一项16路并发测试中，采用这套解码方式后，端到端吞吐量从360提升至1315Token/秒，约为标准解码的3.65倍。

△解码方式对比：单序列峰值KV缓存与16路并发吞吐量

对需要批量处理年报、技术手册的服务来说，这两项变化都有实际意义：显存占用降下来，同样一块卡就能塞进更多活儿；并发跑起来，单位时间内输出的内容也更多。

用户也不需要操心了，照旧提交整份文档，分块和衔接由模型在内部完成，省掉了手动拆文件、分批提交再拼接的麻烦。

更快、更省之外，解析质量也得守得住。

MPDocBench考察的是多页文档的解析质量：面对数十页长的文档，模型既要准确识别内容，也要还原文档结构。

这项测试中，文心Unlimited OCR 2取得了84.59的综合得分。

为了进一步测试百页级文档，团队还新建了MarathonDocBench。它包含100份文档，每份103至300页。不少段落和表格会延续到下一页，专门考验模型能否把前后内容正确衔接起来。

在这套更长、更刁钻的基准上，文心Unlimited OCR 2取得了77.06的综合得分。两项评测中，它的综合得分均为报告所列参评模型中的最高值。

△出自技术报告：多页文档解析评测结果

长文档处理速度的变化同样明显。在报告的百页级测试中，SR-SWA的单步解码速度分别达到Full Attention（全注意力机制）的7.0倍、上一代所用R-SWA的5.6倍。

看曲线更直观：随着文档变长，前两种方案的单步解码耗时一路往上爬，而SR-SWA的单步耗时几乎是条水平线。

这意味着，模型每生成一个Token所需的时间，不会因为输入页数增加而明显变长——书越厚，但写字的速度不变。

△不同文档长度下的单步解码延迟

对比上一代，文心Unlimited OCR 2的单页综合得分基本持平。

真正拉开差距的地方，出现在文档变长之后：能连续处理的页面更多，跨页内容认得更准，长文档解析的计算和缓存开销同步下降。

至于大家怎么用嘛……

你可以输入几百页的年报，或者一本厚厚的技术手册。

尤其是扫描件：先交给模型连续解析、转成文字，再去检索信息、核对内容，也能少折腾不少拆页和手工拼接的活儿。

不过，这么强的OCR，谁拿来工作啊……