传统OCR的”失忆式”工作模式

过去处理一份50页的PDF，标准流程是：模型识别第1页，结束，清空状态；识别第2页，结束，清空状态……如此循环50次。每一页都像一次重新开始，上一页的排版上下文、术语用法、段落衔接被完全丢弃。

这种For-loop范式依赖外部调度器把碎片结果拼接成完整文档。问题在于：跨页表格会被截断，页眉页脚重复出现却无法去重，脚注与正文关联丢失，多页图表的连续编号被打断。对于学术论文、法律合同、财务报告这类强结构化文档，这些缺陷直接影响解析质量。

Unlimited-OCR的解法：单次前向传播

Unlimited OCR在32K上下文限制下，将数十页文档的视觉token一次性送入模型，通过单次前向传播完成全部页面的连续转录。模型在第1页建立的排版理解、术语记忆会自然延续到第40页，不存在页面间的状态重置。

在内部长文档测试集中，40页以上场景的编辑距离仍低于0.11，Distinct-35达到96.90%——这意味着模型在长程生成中没有陷入循环重复，文本多样性保持稳定。

输出越长，显存越爆

端到端OCR模型用LLM作解码器，每生成一个token都要把它的Key和Value存入KV Cache。假设视觉token与文本token压缩比为1:10，那么1万个视觉token（约20-30页文档）完整解码需要输出超过10万个token。KV Cache随输出长度线性增长，显存占用没有上限。

这不是优化问题，是架构层面的根本限制。在标准多头注意力（MHA）下，输出10万个token意味着每一步解码都要回看全部历史，注意力计算量随序列长度平方级增长。实际表现就是：处理到第10页时显存溢出，程序崩溃。

R-SWA：将无限增长变成有界常数

百度提出的Reference Sliding Window Attention（R-SWA）将注意力分为两段。参考段包含视觉token和prompt，全局可见但不参与状态转移——视觉特征只编码一次，此后静止不变。解码滑动窗口宽度固定为128，每生成一个新token就驱逐最早的KV。

结果：解码侧KV Cache规模始终限定在固定容量内，不随输出长度增加。无论解析5页还是40页，显存占用恒定。这和人抄书时的认知状态一致——原书始终在眼前，但只记得最近写下的几个字。

越往后越卡，长文档解析不可用

即使显存够用，速度问题依然致命。标准MHA下，每一步Flash Attention kernel的调用延迟随解码步数线性增加。处理到第20页时，单步延迟可能是第1页的数倍。更糟的是，当KV Cache长度跨越GPU内存对齐边界时，会出现延迟骤降的”悬崖效应”。

这意味着：长文档解析不仅慢，而且越往后越慢。对于需要批量处理数百份文档的企业场景，这种速度退化直接导致处理时间不可预测。

恒定延迟：从头到尾一样快

R-SWA将解码侧KV Cache限制在固定窗口内，每一步注意力计算量恒定。Flash Attention v3 kernel的调用延迟在整个解码过程中保持平稳，不存在随长度增长的趋势，也不会出现对齐边界的悬崖效应。

实测数据：输出6000个token时，DeepSeek OCR的吞吐量降至5822.87 TPS，Unlimited OCR维持在7847.71 TPS，领先35%。在单页场景下也快12.7%（5580 vs 4951 TPS）。

model = AutoModel.from_pretrained(
    ‘baidu/Unlimited-OCR’,
    trust_remote_code=True,
    torch_dtype=torch.bfloat16,
).eval().cuda()

# 多页文档一次性解析
model.infer_multi(tokenizer,
    prompt='<image>Multi page parsing.’,
    image_files=[‘page1.png’,’page2.png’,’page3.png’],
    image_size=1024, max_length=32768)