百度开源OCR突破页数极限：无限解码机制与视觉缓存管理技术解析

一、问题背景：超长文档解析的两道坎

传统OCR系统在处理数十页文档时表现尚可，但当页数攀升至数百甚至数千页时，两个工程瓶颈会迅速暴露。

第一道坎是注意力成本。 基于Transformer的文档解析模型通常采用全注意力机制，解码每一步都需要对全部历史视觉Token计算注意力权重。随着页数增长，视觉Token数量线性膨胀，单步解码的计算量随之线性上升，推理延迟不断累积，最终变得不可接受。即便模型能够“读完”整份文档，解码效率也会被拖垮。

第二道坎是显存占用。 为了支持跨页关联——比如第200页的表格引用了第3页定义的术语——模型必须保留前面所有页面的视觉KV Cache。几千页文档的视觉缓存堆在GPU显存里，峰值占用可达数十GB，直接导致单卡无法承载、并发能力被严重压缩。开发者面临的选择要么是截断文档牺牲精度，要么是堆硬件推高成本。

百度此次开源的OCR方案，正是针对这两个瓶颈给出了系统性的工程解法：稀疏视觉注意力控制单步计算成本，无限解码机制控制显存工作区大小。二者配合，使模型在超长文档场景下保持近乎恒定的单步开销与有限的显存占用。

二、稀疏视觉注意力：把算力花在值得看的地方

2.1 核心思路

全注意力的问题在于“一视同仁”——无论当前解码位置是否需要参考第1页的某个角落，模型都会对全部历史视觉Token分配注意力计算。但实际上，解码某一行文本时，真正相关的视觉信息往往集中在少数页面区域。

稀疏视觉注意力的思路是：让模型在每一步只关注少量关键Token，将有限的计算资源集中在值得关注的视觉信息上。具体而言，解码器在每一步通过轻量级的相关性评估，从历史视觉Token中筛选出与当前解码位置最相关的子集，仅对该子集执行完整的注意力计算。

2.2 效果与代价

这一机制的直接收益是单步解码的注意力计算成本保持近乎恒定——不随文档页数增长而增长。对于百页级文档，官方测试显示单步解码相比全注意力提速约7倍。更重要的是，这种提速不是以精度为代价换来的：在最长300页的评测范围内，解析精度保持稳定。

需要说明的是，稀疏注意力并非没有代价。筛选相关Token本身需要额外的轻量计算，跨页关联场景下模型偶尔仍需“翻回去参考”——即回退到较早页面的视觉信息。但相比全注意力每一步都扫描全部历史Token，这种按需检索的方式在整体上大幅降低了计算浪费。工程上的取舍在于：用一次轻量的相关性评估，换掉一次全量注意力计算，在长文档场景下收益显著。

三、无限解码机制：让显存里只保留有限工作区

3.1 稀疏注意力解决不了的问题

即便每步只关注少数Token，如果所有页面的视觉KV Cache一直驻留在GPU显存中，几千页下来显存依然会爆。稀疏注意力优化的是“算”，没有解决“存”。无限解码机制针对的正是存储侧。

3.2 分块处理与缓存复用

无限解码机制将整份文档拆成一块块相互有重叠的页面组，按顺序逐块处理。每个分块内部维护自身的视觉KV Cache；处理下一分块时，复用相邻分块边界页面的缓存，保证跨块上下文连续性；已经处理完毕且不再被后续分块引用的视觉KV Cache则被及时释放。

用伪代码示意其工作流程：

# 无限解码机制的简化逻辑示意
chunk_size = 8          # 每块包含的页数
overlap = 2             # 相邻块的重叠页数
cache_workspace = {}    # 视觉KV Cache工作区
for chunk_start in range(0, total_pages, chunk_size - overlap):
    chunk = pages[chunk_start : chunk_start + chunk_size]
    # 复用上一块尾部重叠页面的缓存
    reuse_boundary_cache(cache_workspace, chunk)
    # 对本块执行解码
    for page in chunk:
        decode_with_sparse_attention(page, cache_workspace)
    # 释放不再被后续块引用的缓存
    evict_stale_cache(cache_workspace, chunk_start + chunk_size - overlap)

关键设计在于重叠：相邻分块共享边界页面，使模型在切换分块时仍能看到前文尾部的视觉信息，避免跨块语义断裂。而释放策略确保显存中始终只维护有限的视觉缓存工作区，不随文档总页数增长。

3.3 实测数据

按照官方给出的测试数据：

• 单序列推理下，KV Cache峰值显存占用从47GB降至1.77GB，降幅约96%；
• 16并发场景下，端到端吞吐量从360TPS提升至1315TPS，提升约3.65倍；
• 百页级别文档，与全注意力相比单步解码提速约7倍；
• 最长300页评测范围内，解析精度保持稳定。

这组数据的工程含义很直接：原本需要多卡或截断文档才能处理的长文档任务，现在单卡即可承载；并发能力的提升则直接降低了单位文档的处理成本。

四、从长文本生成到超长视觉输入：优化重心的迁移

上一代方案已经在长文本生成的缓存优化上做了大量工作，并在开源社区积累了可观的下载量。这一代的推进方向是把瓶颈分析从“长文本生成时的缓存优化”进一步深入到“超长视觉输入的计算与显存管理”。

这两者的差异值得注意：长文本生成的Token序列是一维的，缓存管理相对直接；而超长视觉输入的Token来源于二维页面图像，具有空间结构和跨页关联，筛选“值得关注”的Token需要理解视觉布局与页面间的语义引用关系。无限解码机制中的分块重叠设计，本质上就是在视觉输入维度上重建一种“局部完整、全局连贯”的处理范式。

五、工程落地建议

对于准备在实际业务中采用此类方案的开发者，以下几点值得考虑：

分块大小的权衡。 分块越大，块内上下文越完整，但显存工作区也越大；分块越小，显存占用越低，但跨块边界信息损失的风险上升。建议根据文档类型（连续叙述型 vs 表格密集引用型）调整块大小与重叠页数。

稀疏注意力的相关性阈值。 筛选关键Token的策略需要与业务精度要求匹配。对精度敏感的场景可适当放宽关注Token数量，以计算换精度；对吞吐敏感的场景则可收紧。

并发与显存的联合调优。 无限解码机制使单序列显存占用大幅下降，释放出的显存可直接转化为并发数。实际部署时应以“显存工作区上限 × 并发数 ≤ 可用显存”为约束进行压测，找到吞吐拐点。

精度监控不可省略。 官方数据表明300页内精度稳定，但业务文档的版式分布各异，建议在自有数据集上对长文档尾部页面的解析质量做抽样验证，确认缓存释放策略不会影响远端页面的引用完整性。

六、结语

超长文档解析的瓶颈从来不只是模型能力问题，更是计算成本与显存管理的系统工程问题。百度此次开源的OCR方案，用稀疏视觉注意力把单步计算成本压到近乎恒定，用无限解码机制把显存占用收束到有限工作区，两者结合使“读尽千页而不为缓存所限”从愿景变成可复现的工程指标。对于需要处理合同、档案、技术手册等长文档场景的开发者而言，这套机制提供了清晰的优化思路与可参考的落地路径。