百度开源无限OCR，跑通长程解析，核心作者YY疑是来自DeepSeek

机器之心·2026年06月23日 18:45

百度 OCR 新模型拿下 SOTA：一次前向推理解析数十页文档

DeepSeek OCR 留下的一个问题，好像被人接上了。

昨天，我们在 HuggingFace 上刷到一个新开源模型，直接被惊艳到了。

它叫 Unlimited OCR，百度出的。

最吸引眼球的地方是，在标准最大上下文长度 32K 的条件下，它让 OCR 模型第一次能够一口气读完整本书。

注意，这不是逐页处理，不是 for-loop 式拆任务，也不是靠外部调度器把结果拼起来，而是真正意义上的一次前向推理直接完成数十页文档解析。

更绝的是，它不仅做到了，还做得相当好。在文档解析主流基准 OmniDocBench v1.5 上，Unlimited OCR 以 93.23% 的总分拿下端到端 SOTA，比 DeepSeek OCR 整整高出 6 个百分点。

看到这里，我们不免好奇：它到底是怎么做到的？于是翻开技术报告，结果越看越有意思。

因为 Unlimited OCR 并不是另起炉灶。恰恰相反，它直接构建在 DeepSeek OCR 的基础之上。

原因很简单：在视觉压缩这件事上，DeepSeek OCR 已经把事情做到相当极致。一张 1024×1024 的文档页面，经过 DeepEncoder 编码之后，最终只剩下 256 个视觉 token。即使放到今天看，这依然是一个相当激进的设计。

但之后，一个问题慢慢浮现 —— 如果输入侧已经压缩得这么狠，为什么此前的 OCR 模型还是很难真正处理长文档？

答案在解码端。视觉 token 压缩之后，模型生成的文本却不会凭空消失。随着输出越来越长，解码器里的 KV Cache 仍然会不断增长。输出越长，显存占用越高；历史越长，注意力计算越重；生成速度也会越来越慢。

这也是为什么过去的大多数 OCR 系统，最终都会退回到逐页解析的模式。因为再高效的编码器，也解决不了解码阶段不断膨胀的历史负担。

而 Unlimited OCR 的切入点，恰好落在这里。它没有重做编码器，而是把全部精力放在了解码阶段。项目界面上有一句很耐人寻味的话：「push DeepSeek-OCR one step further」。

看到这里的时候，我们专门回去翻了一遍 DeepSeek OCR，然后发现两者关注的，似乎正好是同一条技术路线上的两个不同环节。

DeepSeek OCR 解决的是输入侧的问题 —— 如何把高分辨率文档压缩成尽可能少的视觉 token。Unlimited OCR 解决的是输出侧的问题 —— 如何让模型在长时间生成过程中，不被不断膨胀的 KV Cache 拖垮。

一个发生在编码端，一个发生在解码端。单独看，两者各自成立，放在一起看，却意外地连贯。

更有意思的是，Unlimited OCR 技术报告对 DeepSeek OCR 的讨论频率相当高，整整高达 40 次。很多地方读起来完全不像是在做通常意义上的竞品对标，反而更像是在接着思路，继续往前推。

至于为什么会给人这种感觉，我们有一个大胆的猜测。

报告标题：Unlimited OCR Works
报告链接：https://huggingface.co/baidu/Unlimited-OCR/blob/main/Unlimited-OCR.pdf
项目地址：https://github.com/baidu/Unlimited-OCR
Hugging Face：https://huggingface.co/baidu/Unlimited-OCR

像人类一样抄书：Unlimited OCR 解决大模型的长程失忆症

要理解 Unlimited OCR 的意义，需要先回到传统 OCR 模型处理长文档的方式。

过去的 OCR 系统处理长文档，通常采用逐页解析的方式。模型识别第一页，结束；然后识别第二页，再结束；整个流程依赖外部程序一页一页调用模型。从模型能力本身看，它并没有真正连续地完成一次长程任务。每一页都像一次重新开始，上一页的解析状态被清空，模型并不真正知道自己正在完成一本书级别的连续转写。

这种 For-loop 范式，本质上依赖外部调度器（External Scheduler）来拼接结果。这相当于把一本完整的书拆成独立碎片，不仅割裂了语义连贯性，更是一种工程上的权宜之计（Engineering Workaround），而非迈向 AGI 的路径。

人类处理长程任务的方式，显然更接近另一种模式。

例如，一个人手抄一本书时，注意力并不会平均分配给整本书。你不会一边写当前这个字，一边完整回忆前面已经抄过的几百页内容。真实情况通常是：眼睛盯着原始书页，脑子里记住刚刚写下的一小段文字，然后把注意力放到下一个要写的字上。

受人类抄书过程的启发，百度提出了 Unlimited OCR。当一个人手抄一本书时，注意力通常集中在三个地方：原始书页、刚刚写下的一小段内容（通常只有几个字），以及接下来要写的那个字。

人类之所以能够连续抄完整本书、翻译数百页内容，或者转录数小时音频，并不是因为大脑完整保存了所有历史输出。相反，人并不会完整记住所有已经转写过的内容，而是会进行一种软遗忘（Soft Forgetting）。

正是受这一观察启发，百度提出了 Unlimited OCR。

Unlimited OCR 以 DeepSeek OCR 作为基线模型。它由 DeepEncoder 和混合专家架构（Mixture-of-Experts，MoE）组成，模型总参数量为 3B，其中激活参数为 500M，这是其保持高效率的底牌之一。

DeepEncoder 的突出优势在于出色的视觉 token 压缩能力。它能够在保留稳定光学文本特征提取能力的同时，大幅降低 prefill 阶段的 KV cache 占用。

除了 DeepSeek OCR 编码器，百度的创新是将标准多头注意力机制（MHA）替换为 R-SWA（Reference Sliding Window Attention）。借助这一新的注意力机制，只需要在原有参考 KV cache 𝑚 的基础上，增加一个宽度为 𝑛 的固定容量输出 KV 缓冲区，就可以实现长程解析。

R-SWA 如何稳住长程解码？

尽管 DeepEncoder 在输入侧已经实现了令人满意的视觉 token 压缩，但一次性解析整本书的真正瓶颈在于解码阶段。

假设视觉 token 与文本 token 之间的压缩比为 1:10，也就是说，一个视觉 token 大约可以解码出 10 个文本 token。那么，1 万个视觉 token，也就是约等于 1024×1024 分辨率下的 20 到 30 页文档，在完整解码时就需要输出超过 10 万个 token。

对普通 LLM 驱动的 OCR 模型来说，这会带来两个问题：

第一，KV cache 会不断增长。每生成一个 token，模型都要把它的 Key 和 Value 存下来，供后面 token 使用。

第二，注意力计算会越来越重。越到后面，模型要回看的历史越长，生成速度也就越慢。

为此，百度提出了参考滑动窗口注意力机制 R-SWA（Reference Sliding Window Attention），它把模型能看到的信息分成两部分。

第一部分是 Reference tokens，也就是参考信息。在 OCR 里，它主要包括视觉 token 和 prompt。可以把它理解成模型一直放在眼前的原始文档。

第二部分是最近生成的一小段输出 token，默认窗口大小是 128，也就是说，模型只保留最近 128 个输出 token 作为工作记忆。这恰好模拟了人类「只记得最近刚写下的几个字」的认知状态。

R-SWA 示意图。每个生成 token 都会关注所有参考 token，也就是 OCR 中的视觉 token，以及前面 𝑛 个输出 token，其中 𝑛 默认设为 128。与标准全注意力相比，R-SWA 在整个解码过程中都能保持恒定的 KV cache。与普通滑动窗口注意力（vanilla SWA）相比，R-SWA 将视觉 token 排除在状态转移之外，从而保留视觉 token 的保真度，避免视觉特征在长程过程中逐渐模糊。

因此，R-SWA 的核心逻辑可以概括为：原始文档始终可见，已经输出过的文本只保留最近一段。

这和人抄书很像，人抄书时，不会一边写当前这个字，一边回忆前面几百页全部内容。真正有用的是：原书还在眼前，刚刚写过的几个字还在脑子里，然后继续写下一个字。

这样一来模型不再需要随着输出变长而不断背负越来越大的历史缓存，解码阶段的计算开销和显存占用也就不会一路膨胀。下图直观展示了这一点： DeepSeek OCR 基线模型和 Unlimited OCR Works（图中记为 UOW）在 Flash Attention v3 内核上的单次调用耗时。

图中可以清楚看到，DeepSeek OCR 中的标准 MHA 内核会随着解码步数增加而产生越来越高的延迟；而在 Unlimited OCR 中，单次调用耗时基本保持恒定。这正是因为 Unlimited OCR 在 LLM 解码器的所有层中都采用了 R-SWA。

DeepSeek OCR 中出现的延迟尖峰，是因为 KV cache 长度跨过了某个对齐边界，导致数据传输效率突然下降；而采用 R-SWA 后，这个问题也不会出现。

此外，推理过程中的 GPU 显存使用也会呈现类似趋势：在原始 DeepSeek OCR 中，显存占用会线性增长；而在 Unlimited OCR 中，显存占用保持固定。

计算成本和内存占用的双重稳定，正是长程解析得以实现的关键。

Flash Attention v3 内核延迟随解码长度增加而变化的情况。

准确率没掉，长输出更稳，R-SWA 的长程解析跑通了

当然，注意力机制设计得再巧妙，最终还要实验来验证。除了主结果（前文 table 1），论文还在 OmniDocBench v1.5 的 9 类文档上做了细分类别分析，包括 PPT、学术论文、书籍、彩色教材、试卷、杂志、报纸、笔记、研究报告等。

细分类别分析：复杂版式下也没有掉队

如表 2 所示，与 DeepSeek OCR 相比，Unlimited OCR 在所有指标上都取得了明显且一致的提升。与 DeepSeek OCR 2 相比，Unlimited OCR 也保持了明显优势。

更关键的是，在 PPT、报纸、杂志、笔记这类复杂版式文档上，Unlimited OCR 也没有表现出劣势。这说明 R-SWA 的效果不是只适用于简单纯文本，而是可以覆盖更复杂的文档解析场景。

长程解析实验：一次性处理多页文档

长程解析是 Unlimited OCR 的一项新能力。

此前的模型难以实现这一点，主要有两个障碍：第一，过长的输出序列很容易超过最大 token 限制；第二，输出延迟会随着序列长度增加而上升，导致几十页文档的 OCR 解析越往后越慢。

实验中，百度构建了内部长文档测试集，按页数分为 2、5、10、15、20、40+ 页几组，测试模型在多页一次性 OCR 场景下的表现。

结果显示，Unlimited OCR 在同时输入 20 页时仍能保持较好效果；在 40+ 页场景下，编辑距离仍低于 0.11，Distinct-35 约为 97%（Distinct-n 可以理解为生成文本中 n-gram 的多样性指标，数值越高，说明模型越不容易陷入重复输出）。

输出越长，R-SWA 优势越明显

最后，论文比较了 Unlimited OCR 和 DeepSeek OCR 在不同输出长度下的 TPS，也就是每秒输出 token 数。

结果显示，当输出长度为 256 个 token 时，两个模型的推理速度几乎相同。但随着输出长度增加，DeepSeek OCR 的 TPS 会持续下降；当输出长度达到 6000 个 token 时，DeepSeek OCR 的速度已经比采用 R-SWA 的 Unlimited OCR 落后 35%。

这和前面 Figure 3 的 kernel latency 结果是一致的：标准 MHA 会随着 KV cache 变长而越来越慢；R-SWA 将输出侧 KV cache 限制在固定窗口内，因此解码开销不会随着输出长度持续膨胀。

一个大胆的猜测：百度把 DeepSeek 的研究员挖过来了？

咦？读完 Unlimited OCR 的技术报告，怎么有一种似曾相识的感觉。没错，它的技术风格、表达方式，都让人想起 DeepSeek OCR 的技术报告。

技术上自不必说，Unlimited OCR 直接构建在 DeepSeek OCR 的基础之上，对 DeepEncoder 等核心组件进行了进一步融合。同时，二者之间的这种近乎无缝的衔接，也让我们感觉，这不像是一次对开源项目的简单学习，而更像是在完整理解的基础上，继续向前推进，让该技术顺理成章地走入下一个阶段。

而在行文风格上，Unlimited OCR 报告给人一种故事性极强、想法颇为激进，同时又带有强烈探索色彩的感觉。而这种感觉，之前读 DeepSeek 技术报告的时候我们也曾领略过。

这就不得不让人大胆猜想：难道百度把 DeepSeek 的研究员挖过来了？

这也不是不可能。因为前段时间，的确有不少研究员从 DeepSeek 离职，比如 DeepSeek V4 技术报告里被「*」标出来的那些人，有些去向已知，如郭达雅去了字节跳动 Seed 团队、王炳宣去了腾讯混元 (Hunyuan) 团队。

但是还有一些人至今去向不明，如 OCR 系列模型作者魏浩然至今未公开披露去向。等等，百度不会把魏浩然挖来了吧？这也不是没可能，毕竟他在 DeepSeek 期间，是 OCR 系列模型的核心作者。

此外，在 HuggingFace 主页，我们还注意到致谢一栏写着：感谢 Deepseek-OCR、Deepseek-OCR-2。

虽然，Unlimited OCR 技术报告没有明确说明，但有一个署名「YY」的神秘作者。ta 是这份工作的「technical director」，通常来讲，这个角色要负责技术路线的整体把关，如果 ta 确实来自 DeepSeek，那么 Unlimited OCR 与 DeepSeek OCR 之间那种无缝衔接感便不再令人意外；同时，Unlimited OCR 技术报告的措辞也更像是在对自身先前研究进行反思与改进，而非一般意义上的竞品对标。