百度开源OCR新突破：千页文档解析的显存与算力优化实践

一、问题背景：当OCR遇上“厚书”

传统文档解析模型大多在单页或数十页量级上设计和评测。一旦输入扩展到数百乃至数千页，两个瓶颈会同时暴露：

• 注意力成本随页数增长：全注意力机制下，解码每一步都要对全部历史视觉Token计算注意力，单步成本随文档长度线性甚至超线性上升，推理延迟不可接受。
• 视觉KV Cache持续膨胀：所有页面的视觉特征缓存常驻显存，几千页累积下来可达数十GB，单卡无法承载，多卡切分又带来通信与调度开销。

百度此次开源的文心Unlimited OCR 2，正是围绕这两个瓶颈展开：一方面让模型“只翻该翻的页”，另一方面让显存“只用该用的部分”。官方测试显示，数千页的系列长篇与千页级全集可在单序列下连续解析，多页文档基准测试取得SOTA表现，同时KV Cache峰值显存从47GB降至1.77GB，16并发端到端吞吐量从360 TPS提升至1315 TPS。

二、核心思路：像人抄书一样分配注意力

团队的技术灵感来自一个朴素场景：人抄一本厚书时，目光始终落在当前页；遇到跨页关联（如跨页表格、续写的段落），偶尔翻回去参考几页——但绝不会每抄一句就把前面所有页重读一遍。

这一直觉对应两个设计目标：

1. 参考范围是稀疏的：当前解码步只需回溯少量相关页面，而非全部历史。
2. 参考对象是细粒度的：即便锁定到某几页，也应从中筛选出真正相关的视觉Token块，而不是整页纳入计算。

由此引出两项关键机制：SR-SWA（稀疏参考滑动窗口注意力）与无限解码机制。

三、SR-SWA：两级筛选把注意力“收窄”

SR-SWA采用“先粗后细”的两级筛选结构：

第一级：页面门控（Page Gating）
先缩小需要参考的页面范围。模型根据当前解码状态判断哪些历史页面可能与当前内容相关，将候选集从“全部历史页”压缩到“少数候选页”。这一步决定了注意力的页面级稀疏性。

第二级：Token筛选器（Token Selector）
在候选页面内部，进一步挑出最相关的视觉Token块。页面内的版面元素（标题、表格、图注、正文）信息密度差异很大，Token级筛选让计算资源集中在真正值得关注的视觉信息上。

两级筛选叠加后，单步解码的注意力计算成本可以保持近乎恒定——不随文档总页数增长而膨胀。这也是“页数极限”得以突破的前提：模型的计算开销与“当前需要参考多少内容”相关，而与“文档一共多长”解耦。

值得注意的是，这里存在精度与效率的权衡：候选页面范围设得越窄，速度越快，但跨页强关联场景（如跨页表格拼接、跨章节引用）可能漏检。官方的评测结论是，在最长300页的评测范围内解析精度保持稳定，说明页面门控的召回设计在实用区间内是可靠的。

四、无限解码：让显存只维护“工作区”

即便每步只关注少数Token，若所有页面的视觉缓存一直堆在显存里，几千页依然吃不消。无限解码机制从缓存管理层面解决这个问题，其要点可概括为三步：

1. 重叠分块：将整份文档拆成相互有重叠的页面组，按顺序处理。重叠区保证跨块边界处的上下文连续，避免分块切断跨页语义。
2. 边界缓存复用：相邻分块复用边界页面的视觉缓存，避免重复计算，同时维持块与块之间的信息衔接。
3. 及时释放：对已经不再需要的视觉KV Cache主动释放，显存中始终只保留有限的“视觉缓存工作区”。

用一个简化的伪代码示意其调度逻辑：

# 概念示意：分块流式解码
cache = VisualKVCache()          # 有限工作区
for group in split_with_overlap(pages, size=N, overlap=M):
    # 复用上一块的边界页缓存
    cache.reuse_boundary(prev_group.tail_pages)
    for page in group:
        tokens = encode_page(page, cache)      # SR-SWA 稀疏参考
        decode_step(tokens, cache)
    cache.release_outdated()                    # 释放不再需要的KV

效果直接体现在资源指标上：单序列推理下KV Cache峰值显存从47GB降至1.77GB；16并发场景下端到端吞吐量从360 TPS提升至1315 TPS。显存占用的下降不仅意味着单卡可处理更长文档，也意味着同等硬件下可以承载更高并发。

五、性能表现与工程意义

官方公布的测试维度覆盖了长度扩展性与精度稳定性：

• 百页级别：与全注意力相比，单步解码提速约7倍。
• 最长300页评测范围：解析精度保持稳定，未因稀疏化出现明显退化。
• 超长输入：数千页级输入可在单序列下完成解析，验证了“近乎恒定单步成本”的设计目标。

从工程视角看，这组数据的价值在于三点：

1. 成本可预期：单步解码成本与文档长度解耦，使长文档任务的延迟预估变得简单。
2. 显存可规划：固定大小的工作区让部署时的显存预算不再随输入长度剧烈波动。
3. 吞吐可扩展：显存释放出的空间直接转化为并发能力，提升单位硬件的处理效率。

六、从上一代到2.0：瓶颈的持续前移

上一代Unlimited OCR已在开源模型社区积累了超过千万次下载，验证了长文档解析的真实需求。2.0版本的推进方向很明确：从长文本生成时的缓存优化，进一步深入到超长视觉输入的计算与显存管理——前者主要处理序列维度的KV增长，后者还要面对视觉Token本身的高信息密度与二维结构。

技术报告中还收录了一段致敬经典作品咏唱风格的文字，以“像素为身，Token为血”描述模型不受KV Cache与上下文长度所缚的设计目标。这一创意的源头是开源社区开发者对上一代模型的二次创作，开发团队将其收录进正式报告，也侧面反映了开源协作对技术传播的推动作用。

七、实践建议

对于计划在自有系统中落地长文档解析能力的开发者，以下几点值得参考：

• 按场景调参：页面门控的候选范围应结合文档类型调整。合同、论文等跨页关联弱的文档可收窄窗口；表格密集、跨页续写多的文档需适当放宽，必要时对边界页做强制保留。
• 分块大小与重叠量：分块过小会增加调度开销与边界复用次数，过大则削弱缓存释放的效果。建议以“单块处理时间稳定、边界语义不断裂”为调优目标。
• 监控工作区水位：将视觉缓存工作区的占用率纳入监控告警，避免长尾文档触发显存尖峰。
• 精度回归测试：稀疏化机制引入后，应针对跨页表格、跨章节引用等强关联场景建立回归集，防止召回不足带来的静默错误。

长文档OCR的竞争，正在从“单页识别准不准”转向“千页输入下算得省不省、稳不稳”。百度文心Unlimited OCR 2给出的答案是：用页面级与Token级的双层稀疏把注意力收窄，用重叠分块与缓存释放把显存压平——让模型读得完，也读得起。