先看证据
长文档的问题不只是页数多
百度发布的 Unlimited OCR 2，是一款面向长文档的开源视觉语言 OCR 模型。它接收按顺序排列的页面图像，输出文本、表格、公式、图形、标题层级和阅读顺序，目标是让书籍、文件和报告可以在一次请求中处理数百页。模型有 33.4 亿参数，最大位置长度为 131,072 个 token，权重采用 MIT 许可证发布。
一次接收很多页，难点不只在于把图像送进模型，还在于后续生成时如何处理不断变长的上下文。材料给出的多页配置是每页 273 个图像 token，100 页仅图像输入就约为 27,300 个 token，尚未计入生成文本。若每生成一个 token 都要对完整历史做注意力计算，历史越长，每一步解码要查看的内容越多。Unlimited OCR 2 的设计重点，正是改变这笔逐步累积的解码成本。
固定参考集改变了解码账单
模型采用 SR-SWA，即 Sparse Reference Sliding Window Attention。与每一步都查看完整 KV 缓存的全注意力不同，SR-SWA 将文本和视觉信息压到一组固定参考位置上，同时保留近期内容的局部窗口。模型卡以 512 个 token 作为参考集示例；配置中对应的是 128-token 局部窗口，以及从 32-token 区块中选择 top-16。换句话说，解码不再随着历史 token 数量增加而逐步扩大每一步要处理的注意力范围。
这不代表模型只看 512 个 token，也不等于整份文件只需要固定计算量。参考集和局部窗口是对注意力工作范围的约束，页面仍要经过视觉编码，输出也可能继续增长。材料明确指出，图像编码成本和总运行时间仍会随页数上升。因此，“每步解码成本近乎持平”描述的是一个关键环节的扩展特性，不应被解读成从输入到结果的端到端成本恒定；“unlimited-horizon”也是有限上下文窗口内的长程处理说法，而非无限上下文承诺。
分数显示长文档能力，也暴露结构短板
百度报告称，Unlimited OCR 2 在其测试的两个多页文档基准上，面对另外 9 个模型均排名第一。在 MarathonDocBench 上，它的总分为 77.1，材料列出的下一名 Kimi-K3 为 33.7。这个差距支持一个谨慎的判断：稀疏注意力不只是降低长上下文解码负担，在百度公布的比较中，也与较强的长文档解析成绩同时出现。
但总分容易遮住具体任务的短板。Unlimited OCR 2 在 MarathonDocBench 的标题层级 TEDS 子项得分为 48.2，是它在该基准上的最低子分；材料还指出，标题层级是两个基准上较弱的指标。对于只需要连续文本的场景，这类缺口可能不如页间遗漏显眼；对于要保留章节结构、生成可检索档案或继续下游处理的系统，标题层级错误会直接影响结果的可用性。上述榜单和分数来自百度自报，尚不能当作独立复现结论。
部署时要测的是整条管线
部署门槛看起来并不高：材料称模型在一张 CUDA GPU 上以 BF16 运行，百度使用 NVIDIA A800 80GB 测试，BF16 权重约 6.7 GB。代码示例通过 Transformers 加载模型，再调用 infer_multi 传入有序页面图像。对于服务部署，百度推荐使用定制版 SGLang，并在示例中采用每个窗口 10 页的 page-window scheduling。这个窗口安排提醒工程团队：即使模型支持长文档，也不意味着服务必须把所有页面同时作为一个不可拆分的负载来调度。
真正的上线判断需要把模型表现与工作流目标放在一起测。除了总分，还应检查页序、表格和公式、标题层级及阅读顺序是否满足下游用途，并记录页数增加后整条管线的耗时和资源变化。现有材料没有给出独立评测、不同硬件上的吞吐数据，也没有证明 131,072-token 上限下所有文件都能稳定处理。适合的结论不是“长文档 OCR 已解决”，而是 SR-SWA 提供了一种降低逐 token 解码扩张的工程方案；是否值得替换现有流程，仍要由目标文档、结构质量和端到端成本的实测决定。