百度的OCR又升级了，文心Unlimited OCR 2正式发布并开源！
这次，它直接挑战一口气读完整套小说。
7部《哈利·波特》，从《魔法石》到《死亡圣器》，连续识别、转写，3600+页一路读到最后。
换成《三体》全集，同样能一口气读完，三本书1200+页，几十万字，中间也不带喘的。
不过，连着读这么多页，模型得先过一道关：显存。
文档越长，推理时需要保留的中间信息（KV缓存）就越多——可以理解为模型边读边记的小抄，页数越多，小抄越厚。小抄厚重，不光占地方，翻起来也慢。
在技术报告的百页级单序列测试中，文心Unlimited OCR 2给出了一组对比：
峰值KV缓存占用从标准解码（将所有页面的视觉缓存同时保留在显存中）的47GB降至1.77GB，一口气减少了约96%。
47GB是什么概念？比不少笔记本电脑的整机内存还大。而这还只是KV缓存，模型权重等其他开销另算。
它的上一代Unlimited OCR，已经凭借多页文档连续解析能力，在开源社区积累了相当的人气：累计下载量超过1000万，在GitHub上收获约2.86万Star。
从社区制作在线Demo，到支持SGlang推理，围绕它的适配也在持续推进。
到了第二代，升级重点在于连续处理更长文档的同时，把计算和缓存负担降下来。
为此，文心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，谁拿来工作啊……
当然是用来看小说了！
OCR 3.0时代，来了
当然，从几页材料到整本书，OCR需要解决的问题也在发生变化。
技术报告中，团队将文档解析的演进概括为OCR 1.0、2.0和3.0三个阶段。
早期的OCR更像一条分工明确的流水线：先找到文字的位置，再识别其中的内容，最后整理版面和输出结果。如果涉及多页解析，通常是一页一页处理，然后把结果拼接起来，这就是OCR 1.0。
不同模块各司其职，但前一步的错误，也可能一路传到后面——一个环节打喷嚏，后面全感冒。
到了OCR 2.0，视觉语言模型开始直接从页面图像生成解析结果，减少多个模块之间的交接。第一代Unlimited OCR，就把这种端到端解析扩展到了数十页文档。
AI生成
当文档从数十页增加到几百页，连续解析既要保证前后内容衔接，也要控制计算和缓存开销。
文心Unlimited OCR 2通过按需参考与分块解码，让模型处理更多页面时，不必让每一步的计算范围随页数扩大，也不必一直保留所有页面的视觉缓存。
团队将这一步称为OCR 3.0：把持续处理整份文档作为新的技术目标——一口气，不分页，无限解析，永不宕机。
而且吧，这个目标，还有个二次元版本。
Unlimited OCR Works这个名字，本身致敬的是《Fate/stay night》中的「无限剑制」，也就是Unlimited Blade Works。
《Fate/stay night》动画官网首页
在原作设定里，这是一种叫作「固有结界」的魔术，施展后，会展开一片插满无数刀剑的特殊空间。
上一代发布后，Hugging Face用户Snarcy发现了这个命名梗，索性把经典咏唱改成了OCR版本。
到了第二代，团队还真把这段改写收进了技术报告的引言，并保留了Snarcy的署名。
于是，翻开这份讨论注意力机制和显存开销的报告，开篇你将看到这样一段咏唱：
Pixels are my body, and tokens are my blood.
像素为身，而Token为血。
I have parsed over a thousand pages.
我已阅尽千余页文档。
Unknown to KV cache.
不为KV Cache所限，
Nor known to context limits.
不为上下文长度所缚。
So, as I pray： Unlimited OCR Works
故而，我在此祈愿：Unlimited OCR Works。
从47GB降到1.77GB，「不为KV缓存所限」这句，还真没白唱。
也是老中二了。
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
🌟 点亮星标 🌟
科技前沿进展每日见
