百度在这一天放出一篇技术报告《Unlimited OCR Works: Welcome the Era of One-shot Long-horizon Parsing》,登上 HuggingFace 当日论文榜(arXiv 提交日 6 月 22 日)。它要解决的是 DeepSeek OCR 这类「视觉编码器 + 语言模型解码器」端到端 OCR 的一个结构性痛点:用 LLM 解码器能借助语言先验提升识别质量,但输出序列越长,KV cache 越大——显存随之膨胀、生成速度随之变慢。人抄一整本书不会越抄越慢,这类模型却会。Unlimited OCR 的做法是把解码器里所有注意力层换成新提出的 Reference Sliding Window Attention(R-SWA),让 KV cache 在整个解码过程中保持恒定大小,从而在 32K 的最大长度内,用一次前向把数十页文档一次性转写出来。
发生了什么
这是一篇定位为「把 DeepSeek OCR 再往前推一步」的工作,基线就是 DeepSeek OCR,关键改动只有一处:注意力机制。
传统自回归解码里,每生成一个 token 都要回看此前全部 token 的 Key/Value,KV cache 随输出长度线性增长。文档解析恰恰是「输出极长」的任务——一页密集文本就能产出上千 token,几十页叠加,后段生成会被前段拖得越来越慢、越来越吃显存。
R-SWA 把注意力拆成两类对象区别对待:
- 对参考 token(视觉编码出的页面 token + 提示词 token,共 m 个):每个输出 token 始终关注其全部,确保「原文」这一信息源永远在视野里、不被滑掉;
- 对输出 token(已经生成的转写内容):只关注最近的 n 个(默认 n=128),更早的输出滑出窗口。
于是 KV cache 被钉死在 m+n 这个常数上,与已经生成了多少页无关。论文把这套机制类比成「人类解析时的工作记忆」:盯着原文,只在脑中保留最近写过的一小段,而不是把已经誊抄的所有内容都记在心里。作者还强调 R-SWA 是通用机制,不止用于 OCR,语音识别(ASR)、翻译等长序列生成任务同样适用。
编码侧则沿用 DeepSeek OCR 的高压缩 DeepEncoder:16 倍 token 压缩,一张 1024×1024 的页面只编码成约 256 个视觉 token——这是「一次塞进数十页」在输入端能成立的前提。模型规模为 3B 总参数 / 0.5B 激活参数的 MoE 架构,训练用约 200 万份文档 OCR 样本(单页与多页约 9:1),跑 4000 步、batch size 256、最大序列长 32K,硬件为 8×16 张 A800;训练用 Megatron-LM,推理支持 SGLang 与 Transformers。代码与权重已开源到百度的 GitHub 仓库(baidu/Unlimited-OCR),并提供 HuggingFace、ModelScope、vLLM 等多种部署路径。
关键数据 / 技术细节
在通用文档解析基准 OmniDocBench 上,Unlimited OCR 相对 DeepSeek OCR 基线全面提升,并拿下端到端 SOTA:
| 指标(OmniDocBench v1.5) | DeepSeek OCR 基线 | Unlimited OCR | 变化 |
|---|---|---|---|
| 总分 | 87.01 | 93.23 | +6.22 |
| 文本编辑距离(越低越好) | 0.073 | 0.038 | −0.035 |
| 公式 CDM | 83.37 | 92.61 | +9.24 |
| 表格 TEDS | 84.97 | 90.93 | +5.96 |
在更新的 OmniDocBench v1.6 上,总分 93.92,微弱领先 Qianfan-OCR 的 93.90,作者称这是端到端 SOTA。
长程解析是这套机制真正的卖点,编辑距离随页数增长的退化被压得很缓:
| 文档页数 | 编辑距离(越低越好) |
|---|---|
| 2 页 | 0.0362 |
| 20 页 | 0.0572 |
| 40+ 页 | 0.1069 |
也就是说,即便解析 40 页以上,编辑距离仍低于 0.11,且 Distinct-35 约 97%(衡量输出不退化为重复内容的指标)——这正是固定 KV cache 想换来的东西:长度增加,质量不塌。效率上,OmniDocBench 实测吞吐 5580 TPS,高于 DeepSeek OCR 的 4951 TPS(约快 12.7%);当输出达到约 6000 token 时,DeepSeek OCR 的速度比 Unlimited OCR 慢约 35%——输出越长,固定 cache 的速度优势越明显。
需要说明的是,上述数字目前均来自论文本身(技术报告 + arXiv 摘要,数据一致),尚无第三方在同一基准上的独立复现;OmniDocBench v1.6 上对 Qianfan-OCR 仅 0.02 分的领先,差距在统计意义上接近持平,「SOTA」更多是排位而非代差。这些待外部验证之处,下文观点里会单独点出。
为何重要
这件事的意义不在「OCR 又涨了几个点」,而在它给端到端文档解析提供了一条把长度成本解耦的工程路径。
第一,它直击 DeepSeek OCR 范式的命门。DeepSeek OCR 把 OCR 重构为「视觉压缩 + LLM 解码」,优点是语言先验带来识别质量,代价是 KV cache 随输出膨胀——这让它在「整本书、整份合同、整篇财报」这类超长文档上吃力。R-SWA 用「参考全看、输出滑窗」把 cache 钉成常数,等于在不放弃语言先验的前提下,拆掉了长度这道天花板。对要处理几十上百页 PDF 的场景(法律、财务、科研文献、档案数字化),这是从「能不能跑完」到「跑得稳又快」的差别。
第二,机制比模型更值得关注。R-SWA 不是又一个堆参数的 OCR 模型,而是一个可迁移的注意力设计:任何「输入是固定参考、输出是超长序列」的任务都可能套用——长文翻译、长音频转写、长文档摘要。如果它在 OCR 之外被验证有效,影响面会比一个 OCR SOTA 大得多。
第三,高压缩编码器是被低估的另一半。一页 1024×1024 只占约 256 token,意味着输入端本就为「一次塞进几十页」预留了空间;R-SWA 解决的是输出端。两者配合,才让「one-shot long-horizon parsing(一次性长程解析)」这个标题成立。换句话说,这是 DeepSeek OCR 高压缩思路的一次顺势延伸,而非另起炉灶。
我们的判断:Unlimited OCR 真正的价值是把「输出长度」从端到端 OCR 的成本曲线里基本解耦出来——这比 6 分的基准提升更重要。过去这类模型「越往后越慢越吃显存」,本质是自回归 + 全量 KV cache 的结构税;R-SWA 用「参考全看、输出只看最近 128」把这笔税降成常数。对真实文档场景,「解析第 40 页和第 2 页一样快、一样准」的工程意义,远大于排行榜上多零点几分。
但有三个 caveat 必须摆出来。其一,所有亮眼数字目前都自报、未经第三方复现。技术报告和 arXiv 摘要内部一致,但 OmniDocBench v1.6 对 Qianfan-OCR 仅领先 0.02 分,说「端到端 SOTA」站得住,说「拉开差距」则言过其实——这更像在密集竞争区里探出半个身位。其二,「输出只关注最近 128 个 token」是有代价的设计。OCR 大多是局部转写、对超长程上下文依赖弱,所以滑窗损失小;但论文宣称 R-SWA 通用、可迁移到翻译/ASR——这些任务里跨远距离的语义一致性(指代、术语统一、篇章连贯)恰恰更吃远程注意力,128 的窗口在那些场景未必够。把「OCR 上有效」直接外推成「通用有效」,需要更多任务上的证据,现在还只是作者的 claim。其三,真实世界的难点未必落在基准里。手写体、复杂版式、跨页表格、多栏混排、低质量扫描——这些 OmniDocBench 覆盖有限的场景,才是文档解析最痛的地方,固定 cache 在这里是否依然稳,要看实测。
还有一层结构性观察:这是百度在 DeepSeek 开创的「视觉压缩 OCR」路线上做增量,而不是另立范式。它说明 DeepSeek OCR 的思路正在被快速吸收、迭代,端到端 OCR 的竞争重心正从「识别准不准」转向「长文档跑得稳不稳、省不省」。谁能把「一次解析整本书」做到又快又准又便宜,谁就拿到文档数字化这块大蛋糕的入口——而开源(MIT/CC BY 4.0、多框架部署)会让这条路线扩散得更快。
接下来看什么
- 第三方复现:是否有独立团队在 OmniDocBench v1.5/v1.6 上复现 93.23 / 93.92,以及与 Qianfan-OCR 0.02 分的领先是否经得起重测。
- R-SWA 的跨任务验证:论文宣称它通用于 ASR、翻译等长序列任务,等待这些场景的实证——尤其是远程语义一致性是否被 128 窗口拖累。
- 滑窗大小的敏感性:n=128 是默认值,更长文档或更强上下文依赖的任务下,窗口该取多大、质量/成本如何权衡。
- 真实文档场景的稳健性:手写、复杂版式、跨页表格、低质扫描等长尾上的表现,以及长程解析时编辑距离低于 0.11 能否复现。
- 生态落地速度:开源后社区在 vLLM/SGLang/ModelScope 上的部署反馈、实际推理成本,以及是否被集成进文档处理产品。