百度开源超长文档OCR技术解析：从注意力稀疏化到显存恒定

一、长文档解析的真实困境

OCR技术发展至今，单页或数页文档的识别精度已相当成熟。但当输入从“一页纸”变成“一本书”，问题性质就发生了根本变化——瓶颈不再是单个字符的识别准确率，而是模型在超长视觉序列上的计算效率与显存占用。

以一部数千万字符的长篇作品为例，若将其逐页编码为视觉Token，序列长度会迅速膨胀到数十万甚至上百万量级。标准全注意力机制下，每一步解码都需要对所有历史视觉Token计算注意力权重，计算成本随页数线性甚至超线性增长；同时，所有页面的视觉KV Cache必须常驻显存，几千页累积下来，单序列占用数十GB显存并非夸张。这意味着即便算力充足，显存墙也会先把长文档任务拦在门外。

百度此次开源的超长文档OCR方案，正是围绕“计算成本”与“显存占用”这两个核心矛盾展开的系统性设计。其技术灵感来源颇为朴素：人类抄写一本厚书时，目光始终聚焦当前页，遇到跨页关联才偶尔翻回前文参考，而不会每抄一句就重读全部已抄内容。这一直觉被转化为两项关键机制——稀疏参考滑动窗口注意力与无限解码机制。

二、SR-SWA：让注意力只落在“值得看”的视觉Token上

2.1 滑动窗口不是新概念，难点在于“参考”的取舍

滑动窗口注意力本身在长序列建模中已有广泛应用，其基本思想是限制每个Token只能关注局部窗口内的历史信息，从而把注意力计算复杂度从序列长度的平方级降为线性级。但直接套用到多页文档OCR上会遇到一个现实问题：跨页语义关联是客观存在的。表格跨页续接、段落跨页衔接、章节标题与后续内容的指代关系，都要求模型在必要时“回看”更早的页面。

因此，百度团队提出的SR-SWA（Sparse Reference Sliding Window Attention，稀疏参考滑动窗口注意力）并非简单的固定窗口截断，而是两级筛选结构：

• 页面门控：先在最粗粒度上缩小需要参考的页面范围。模型根据当前解码位置与页面级特征，判断哪些历史页面与当前页存在潜在关联，将候选范围从“全部历史页”压缩到“少数相关页”。
• Token筛选器：在页面门控给出的候选区域内，进一步从视觉Token块级别挑出最相关的部分。最终参与注意力计算的Token数量被控制在有限预算内。

这种“先选页、再选块”的级联筛选，使得单步解码的注意力计算成本不随文档总页数增长而显著上升，而是保持近乎恒定。换句话说，模型读第1页和读第300页时，单步解码的开销处于同一量级——这是长文档场景能够“读到底”的前提。

2.2 稀疏不等于信息丢失

值得强调的是，稀疏化的目标不是丢弃信息，而是把有限的计算资源集中到当前决策真正需要的视觉证据上。页面门控负责保证“不漏页”，Token筛选器负责保证“不漏块”，两级机制共同构成一个可学习的、内容驱动的参考范围选择过程。从技术报告披露的评测结果看，在最长300页的评测范围内，解析精度保持稳定，说明这种稀疏参考策略在显著降低计算量的同时，并未牺牲长文档理解的可靠性。

三、无限解码机制：把显存占用从“随页数增长”变为“恒定工作区”

3.1 KV Cache才是长文档的真正显存杀手

即便注意力计算已经被稀疏化，另一个问题依然存在：所有页面的视觉KV Cache如果一直堆在显存中，几千页下来照样吃不消。官方给出的数据很能说明问题：单序列推理下，KV Cache峰值显存占用原本高达47GB；16并发场景下，端到端吞吐量仅为360 TPS。显存瓶颈直接限制并发能力，也限制了可处理的文档长度上限。

3.2 重叠分块 + 边界缓存复用 + 过期缓存释放

无限解码机制的核心思路是把整份文档拆成一块块相互有重叠的页面组，按顺序流式处理：

1. 分块：将长文档切分为若干页面组，相邻组之间保留重叠页面，以确保跨块边界的语义连续性不被切断。
2. 复用：处理新分块时，复用相邻分块边界页面的视觉KV Cache，避免重复编码与重复计算。
3. 释放：一旦某个分块的视觉缓存不再被后续解码需要，立即释放对应显存。

其效果可以概括为：模型一路往下读，显存里始终只需要维护一个有限的视觉缓存工作区，而不是整本书的完整缓存。官方测试数据显示，单序列推理下KV Cache峰值显存从47GB降至1.77GB；16并发场景下端到端吞吐量从360 TPS提升至1315 TPS。显存占用降低约一个数量级，吞吐量提升约3.6倍——这两个数字共同决定了长文档OCR能否真正进入生产可用状态。

3.3 性能随文档长度的变化趋势

官方还测试了文档长度不断增加时的表现：在百页级别，与全注意力方案相比，单步解码提速约7倍；在最长300页的评测范围内，解析精度依然保持稳定。这意味着该方案的收益并非只在极端长文档上才体现，而是在百页级这一常见企业文档场景中就已经具备明显优势。

四、工程视角：这套方案解决了哪些落地问题

从开发者与企业用户的角度看，该方案的价值可以归纳为三个层面：

• 成本可控：显存占用从数十GB降到GB级，意味着长文档解析可以在更小规格的加速卡上运行，单位文档的推理成本显著下降。
• 并发可用：吞吐量提升数倍，使批量文档处理（如合同归档、档案数字化、长报告解析）具备实际排队处理能力，而不是单任务串行等待。
• 长度可扩展：计算成本与显存占用不再随页数线性膨胀，文档长度上限从“显存能装下多少页”转变为“业务需要读多少页”。

在典型实现中，这类流式解码的伪代码逻辑大致如下：

# 伪代码示意：重叠分块流式解码
cache = None
for chunk in split_document(pages, overlap=K):
    if cache is not None:
        # 复用上一分块边界页面的视觉KV Cache
        cache = reuse_boundary_cache(cache, chunk)
    output, cache = decode(chunk, cache, attention=sr_swa)
    cache = release_unused_cache(cache)  # 释放不再需要的缓存
    yield output

需要说明的是，上述代码仅为机制示意，具体接口与参数以官方开源实现为准。其工程含义是清晰的：长文档解析从“一次性装入全部页面”的全量模式，转变为“按块流式处理、缓存滚动复用”的流水线模式。

五、从技术报告彩蛋看开源策略

值得注意的是，该方案并非首次亮相。上一代超长文档OCR模型已在开源模型社区积累了超过千万次下载量，说明长文档解析是真实且广泛的需求。此次2.0版本把优化重心从长文本生成时的缓存管理，进一步深入到超长视觉输入的计算与显存管理，属于沿着同一技术主线的纵深推进。

技术报告结尾还埋了一个颇有意思的彩蛋：一段致敬经典视觉小说咏唱文的改编文字，以“像素为身，Token为血”开篇，表达“已阅尽千页，不为KV Cache所限，亦不为上下文长度所缚”的技术愿景。据披露，这个创意最早来自开源社区开发者对上一代模型的二次创作，开发团队看到后很喜欢，最终将其收录进2.0技术报告。这一细节从侧面反映出该方案与开发者社区之间的良性互动——开源不仅是代码释放，也是技术文化与使用者共创的过程。

六、小结与展望

百度此次开源的超长文档OCR方案，技术路径可以概括为“两级稀疏 + 流式缓存”：SR-SWA通过页面门控与Token筛选把单步注意力成本压到近乎恒定，无限解码机制通过重叠分块与缓存回收把显存占用压到有限工作区。两者结合，使百页级文档获得约7倍解码提速，300页范围内精度保持稳定，单序列KV Cache峰值从47GB降至1.77GB，16并发吞吐从360 TPS提升至1315 TPS。

对开发者而言，这套方案提供了一个可复用的工程范式：面对超长视觉输入，不必在“全注意力保精度”与“截断窗口省显存”之间二选一，而是可以通过内容驱动的稀疏参考与滚动缓存管理，同时拿到可接受的精度与可落地的成本。随着长文档理解在合同审查、档案数字化、研究报告解析等场景中的需求持续增长，这类面向“长度极限”的系统级优化，其价值会越来越体现在生产环境的真实账单与吞吐数字上。