长文档OCR推理缓存优化与吞吐提升实践

一、问题的起点：长文档为何越读越慢

在将扫描档案、产品手册、合同卷宗等材料批量转为可检索文本时，很多团队都会遇到一个反直觉的现象：单页识别明明很快，但一旦把几十页甚至上百页的PDF丢进流水线，整体耗时便急剧上升，显存占用也水涨船高。要理解这一现象，需要回到视觉OCR模型的基本工作方式。

当前主流的文档解析模型，通常会把每一页图像切分成若干视觉token，再与文本token一起送入解码器。模型在生成每一个文字时，都需要参考此前保留的上下文信息。即便已经通过滑动窗口等策略限制了“最近保留多少文字token”，只要每一页的视觉信息仍然持续参与注意力计算，需要处理的状态量就会随着页数增加而不断累积。换句话说，页数越多，缓存越厚，单步推理的负担越重。

这种累积效应在工程上表现为两个直接后果：

• 显存压力持续攀升：键值缓存（KV Cache）随序列长度线性增长，长文档场景下极易触碰显存上限，导致无法单序列处理完整文档，只能反复截断或分片。
• 吞吐下降、队列堆积：单序列推理变慢后，批量任务的排队时间被拉长，后续的检索、问答等下游功能只能等待解析环节完成。

因此，长文档解析的核心矛盾并不在“能不能识别一页”，而在于“能否在有限资源下持续、稳定地把整本材料读完”。

二、优化思路：页面筛选与视觉信息筛选

针对上述矛盾，一条可行的技术路径是：控制每一步真正参与计算的信息量，而不是让全部历史页面无差别地参与注意力。具体而言，可以从两个维度做筛选。

2.1 页面级筛选

并非每一页都对当前解码步骤同等重要。通过页面筛选机制，模型可以在解码时优先参考与当前生成内容相关性更高的页面，降低远距离、低相关页面的权重。这样做的直接收益是：单步需要加载和计算的视觉token数量被压下来，KV缓存的峰值占用随之下降。

2.2 视觉信息筛选

在单页内部，视觉token也并非全部必要。版面中的空白区域、重复水印、装饰性元素等，对文字识别的贡献有限。视觉信息筛选可以在token层面做精简，进一步压缩每一步的注意力计算规模。

2.3 分块衔接与缓存释放

当文档长度超过单次可处理范围时，通常需要分块处理。简单的分块会带来边界信息丢失的问题——上一块末尾与下一块开头之间的上下文被切断，影响识别连贯性。一种更稳妥的做法是：相邻分块保留一页重叠，用重叠区域复用边界信息，同时在块处理完成后释放不再活跃的缓存。这样既保证了跨块语义的衔接，又避免了缓存无限增长。

可以用一段伪代码来示意这种分块与缓存管理逻辑：

def parse_long_document(pages, block_size=8, overlap=1):
    results = []
    cache = None
    start = 0
    while start < len(pages):
        end = min(start + block_size, len(pages))
        block = pages[start:end]
        # 若存在上一块缓存，仅保留重叠页对应的状态
        if cache is not None and overlap > 0:
            block = pages[start - overlap:end]
        output, cache = model.decode(block, past_cache=cache)
        # 释放非重叠部分的缓存，仅保留最后一页用于衔接
        cache = trim_cache(cache, keep_last=overlap)
        results.append(output)
        start = end
    return merge(results)

这段逻辑的关键在于两点：重叠保留保证边界不丢信息，缓存裁剪保证内存不随页数无限膨胀。

三、缓存下降与吞吐提升的工程含义

在一组单序列推理的对照测试中，峰值KV缓存从47.00GB降至1.77GB。这个数字之所以值得关注，是因为它改变的不只是“能不能跑”，而是“能怎么跑”。

3.1 显存压力缓解带来的部署弹性

缓存占用大幅下降后，单张加速卡可以容纳更长的序列，或者在同一张卡上并行处理更多请求。对于长期运行文档解析任务的团队，这意味着：

• 长文档不必再被强行切碎到很小的片段，减少了拼接与对齐的复杂度；
• 并发路数可以上调，单位时间内的处理能力增强；
• 部署时的资源预留更宽松，调度策略有更大回旋空间。

3.2 吞吐提升对批量任务的价值

另一组16路并发测试中，吞吐量从360 TPS提升到1315 TPS，约为原来的3.65倍。需要强调的是，这是特定测试条件下的吞吐对照，不代表单个文件的端到端时延会等比例缩短。单个文件实际等待时间仍取决于文件内容复杂度、版面质量、部署方式与批处理策略。

但对批量解析服务而言，吞吐提升的意义是明确的：单位时间能输出更多内容，任务队列有机会更快消化。对于需要把大量历史档案、手册、报告集中入库的场景，解析环节不再是整条流水线的瓶颈，下游的检索与问答功能可以更早拿到可用数据。

3.3 成本换算需谨慎

缓存降幅与吞吐提升是技术指标，不能直接等同于“少用多少机器、省多少钱”。实际成本取决于文档平均页数、并发需求、硬件利用率、识别质量要求等多重因素。合理的做法是：拿一批具有代表性的真实文档做对比测试，测量总耗时、峰值显存、识别准确率与部署成本，再决定是否调整技术栈。

四、能力边界：它不是什么“全新能力”

一个容易被夸大的点是“终于能识别一本厚书”。事实上，多页PDF的解析能力在行业常见技术方案中早已具备，并非某项新技术独有的突破。评估这类优化的价值，应当放在长文档解析的资源消耗与处理效率这一维度上，而不是把“能读厚书”当作新能力来宣传。

同样重要的是，单组缓存与吞吐对照，并不能说明某个方案已经全面超越现有OCR工具。如果企业当前使用的工具在速度、准确率、稳定性上已经满足需求，是否替换需要综合比较以下指标：

对比维度	关注点
总耗时	包含排队、推理、后处理、重试的端到端时间
识别质量	字符准确率、版面还原、表格与公式处理
部署成本	硬件需求、并发能力、运维复杂度
集成成本	与现有流水线、存储、检索系统的对接难度

仅凭一张缓存对照表就决定替换，是不充分的。

五、一个必须正视的取舍：全局结构信息

在长文档处理能力提升的同时，报告的限制部分也明确承认了一个当前局限：稀疏注意力机制没有保留全局文档信息，对标题层级等文档整体结构的理解仍受限制。

这意味着什么呢？对于以“逐页文字提取”为目标的场景——比如把扫描件转成可检索文本、把手册内容灌入知识库——这一局限影响相对可控。但如果任务需要理解文档的章节树、标题层级、跨页表格的语义关联，稀疏注意力可能无法提供完整的全局视图。此时，可能需要在后处理阶段引入版面分析、结构重建等补充手段，或者对超长文档采用“先分块解析、再结构化合并”的策略。

六、给工程团队的落地建议

结合上述分析，如果你正在为长文档解析的显存与吞吐问题寻找优化路径，可以按以下步骤推进：

1. 先测基线：用真实文档测出当前方案的峰值显存、单序列最大页数、批量吞吐与端到端时延。
2. 定位瓶颈：确认瓶颈是在推理缓存、批处理调度，还是后处理与存储环节。
3. 小范围验证：在具有代表性的文档集上对比优化前后的总耗时与识别质量，不要只看单一指标。
4. 关注结构需求：如果业务依赖标题层级、跨页表格等全局结构，提前评估稀疏注意力的局限，准备好结构重建的补充方案。
5. 渐进式替换：即使优化效果明显，也建议按流量比例灰度切换，持续监控准确率与资源占用。

长文档解析的工程挑战，本质上是在有限资源下持续处理超长序列的问题。缓存优化与吞吐提升提供了更宽松的资源边界，让更多文档有机会在可接受的时间内完成入库；但与此同时，全局结构理解的取舍、实际部署的成本核算，仍需要每个团队结合自身场景做出判断。技术指标是决策的输入，而不是决策本身。