百度开源 Unlimited OCR 2：KV 缓存压缩 96%，超长文档连续解析的技术拆解

一、长文档 OCR 的真正瓶颈：不是识别精度，而是显存

文档 OCR 技术发展至今，单页识别精度已经达到相当可用的水平。真正的工程难题出现在”连续处理”这个场景上：当输入从一张图变成一本几百页的书、一套上千页的文集时，模型面临的约束从”认得准不准”转变为”跑不跑得动”。

这个约束的核心是 KV 缓存。在自回归解码过程中，模型需要为已处理过的每个 token 保留键值对（Key/Value），以便后续步骤做注意力计算时复用。可以把它理解为模型边读边记的”小抄”：读的页数越多，小抄越厚。厚到一定程度，显存就被撑爆了。

更麻烦的是，传统解码方式下，KV 缓存的增长与输入长度近似线性。一篇百页级文档，如果把所有页面的视觉 token 缓存同时驻留在显存中，峰值占用可以达到数十 GB 量级——这个数字已经超过不少开发机的整机内存容量，而模型权重、激活值等其他开销还要另算。对于需要批量处理文档的服务端场景，这意味着单卡并发度极低，单位推理成本居高不下。

百度此次开源的 Unlimited OCR 2，正是针对这一瓶颈给出的系统性解法。其技术报告披露的一组对比数据颇具说服力：在百页级单序列测试中，峰值 KV 缓存占用从标准解码方案的 47GB 降至 1.77GB，绝对降幅约 96%。缓存被压到了一个近似常数的水平，文档页数不再线性推高显存需求。

二、从”全程摊开”到”按需回看”：SR-SWA 的设计逻辑

要理解这次优化的价值，先要看上一代方案留下的问题。

上一代 Unlimited OCR 已经通过滑动窗口注意力（SWA）类机制，把推理阶段的 KV 缓存做了大幅削减，从而具备了多页文档连续解析能力。但它在”回看”环节仍有冗余：当模型需要参考先前页面信息时，所有输入页面的视觉信息依旧要参与注意力计算。文档越长，参与计算的信息越多，而其中相当一部分与当前正在识别的那几行文字毫无关系——典型的”陪跑”计算。

Unlimited OCR 2 提出的稀疏参考滑动窗口注意力机制（SR-SWA），思路借鉴的是人类抄书时的行为模式。人手抄书时，视线主要聚焦在当前正在抄写的那一页；只有遇到需要前后对照的内容（比如术语定义、图表编号、跨页表格），才会回头翻查相关页面。没有人会一边抄写，一边把整本书的所有页面同时在脑中摊开。

SR-SWA 把这一直觉转化为计算规则：

• 局部聚焦：当前解码步骤主要关注滑动窗口内的邻近视觉 token，保证识别连贯性；
• 稀疏参考：当需要跨页参照时，按相关性从历史页面中选取少量关键页面/视觉片段参与注意力，而非全量回看；
• 重复计算削减：被选中的参考信息才进入注意力计算，未被选中的页面缓存不参与当前步运算。

这一机制带来的直接收益是：单步解码的计算量与”当前窗口 + 少量参考”相关，而不是与”全部历史页面”相关。文档继续变长时，计算开销不会随之水涨船高。

三、持续解码：让缓存增长脱离文档长度

仅有稀疏注意力还不够。如果解码框架本身仍要求保留所有历史 KV，显存占用依旧会随页数累积。Unlimited OCR 2 配合的持续解码机制解决了”存”的问题。

其核心思想可以概括为分层管理：

1. 窗口内缓存常驻：当前滑动窗口覆盖的视觉 token 的 KV 保持完整，保障局部识别质量；
2. 历史信息压缩/淘汰：滑出窗口的历史页面不再以完整 KV 形式驻留，而是按稀疏参考策略保留可检索的索引或压缩表示，需要时再取用；
3. 单步开销恒定：由于每步只处理窗口内 token 与少量参考 token，单步解码的显存与算力开销基本恒定，与已读页数解耦。

用伪代码表达其循环结构，大致如下：

# 概念示意：持续解码下的单步处理流程
for step in decode_steps:
    window_tokens = get_sliding_window(current_page, window_size)
    ref_tokens = sparse_reference(
        query=current_state,
        history_index=compressed_history,   # 压缩后的历史索引
        top_k=ref_budget                    # 稀疏参考预算
    )
    kv = concat(window_tokens.kv, ref_tokens.kv)   # 仅这两部分参与注意力
    output = attention_decode(current_state, kv)
    compressed_history.update(current_page, strategy="compress")  # 滑出即压缩

正是”窗口常驻 + 稀疏参考 + 历史压缩”三者叠加，才把峰值缓存从 47GB 量级压到 1.77GB 量级。需要注意的是，1.77GB 仅指 KV 缓存部分，模型权重等开销需另行计算；但关键在于，这部分开销不再随页数增长而膨胀，工程上才有了”页数无上限”的可行性。

四、能力边界与工程价值

从公开信息看，Unlimited OCR 2 的验证场景颇具代表性：连续识别并转写七部系列小说、合计 3600 页以上，以及三本书、1200 余页、数十万字的中文长文本，全程连续处理不中断。这类测试覆盖了长文档 OCR 的两个关键维度——跨页上下文依赖（章节标题、人物名、术语的一致性）与超长序列稳定性（不因序列过长而崩溃或显著退化）。

对开发者而言，这套方案的价值体现在几个层面：

• 服务端吞吐：KV 缓存降低两个数量级，意味着同等显存下可显著提升并发文档数或支持更长输入，直接改善单位推理成本；
• 端侧/边缘可行性：1.77GB 级别的缓存占用，使长文档连续解析在显存受限的环境中具备讨论空间；
• 架构可复用性：SR-SWA 与持续解码属于通用解码优化思路，可迁移至其他需要长序列视觉-语言联合建模的场景，如长视频理解、多页表格解析、合同/档案批量数字化等。

需要客观指出的是，”页数无上限”是工程意义上的表述——实际可处理长度仍受模型位置编码外推能力、精度衰减、内存带宽等综合因素制约。缓存压缩解决的是显存墙，不等于所有长序列质量问题自动消失。

五、实践建议：如何评估与接入

对于考虑在业务中落地长文档 OCR 的团队，建议从以下维度做验证：

1. 峰值显存实测：在自己的文档长度分布下测量峰值 KV 占用，而非只看单点数据；注意区分缓存占用与端到端显存占用。
2. 跨页一致性抽检：重点检查术语、编号、表格跨页续接等依赖上下文的字段，这是长文档 OCR 与单页 OCR 的质量分水岭。
3. 吞吐-精度权衡：稀疏参考的预算（参考页面数/ token 数）是可调参数，预算越小缓存越省、但跨页依赖强的文档可能掉点，需按业务文档类型调优。
4. 批处理策略：即使单序列缓存被压缩，批量场景仍建议结合动态批处理与长度分桶，避免长短序列混批造成的填充浪费。

该项目已在 Hugging Face 与 GitHub 以开源形式发布，开发者可直接获取模型与推理代码进行本地评测。对于正在构建档案数字化、出版物转写、票据/合同批量解析等长文档处理管线的团队，Unlimited OCR 2 提供的”常数级缓存”思路，比单纯的精度指标更值得纳入技术选型考量。