注意力机制活了 7 年，终于有人动了它的底层逻辑

所有大模型都建立在同一个假设上：注意力机制是对的。

Transformer 架构统治了 7 年，MHA（多头注意力）是它的心脏。Q、K、V 三个矩阵算注意力分数，KV 缓存存历史上下文，生成越久缓存越大——这是天经地义的物理约束，没有人质疑过。

直到百度在 Unlimited OCR 里把 KV 缓存改成了一个溢洪道。

KV 缓存：大模型的水库问题

先理解一下标准注意力机制的内存模型。

生成第 1 个 token 时，KV 缓存里只有 1 组键值对。生成第 1000 个 token 时，有 1000 组。第 10 万个 token 时，10 万组。线性增长。这就像一个只有进水口没有出水口的水库——水位只会越来越高。

对聊天场景，这不是大问题。一段对话几千 token，KV 缓存占不了多少显存。但 OCR 不一样——一篇 40 页的文档，动辄几万甚至十几万 token 的输出。KV 缓存滚雪球式膨胀，内存先爆，速度再崩。

所以所有 OCR 模型都选择了同一条退路：逐页处理。把长任务切成短任务，每页独立推理，页间无记忆。

能用。但就像把一本小说拆成 40 个互不相干的摘要——信息在页与页之间断掉了。

R-SWA：给水库装上溢洪道

百度提出的 R-SWA（Reference Sliding Window Attention，参考滑动窗口注意力），做的事情用一句话概括：给 KV 缓存装一个固定容量的溢洪道。

每生成一个新 token，最老的那个 token 就被排出队列。队列长度始终恒定。1 万 token 的输出和 10 万 token 的输出，KV 缓存占用完全一样。

但这里有一个精妙的区分——不是所有 token 都被同等对待。

R-SWA 把 token 分成两类：参考 token（图像的视觉 token + 提示词）和输出 token（已生成的文本 token）。对参考 token，始终全量可见——原文永远不丢。对输出 token，只保留最近 128 个——该忘就忘。

这对应了一个非常直觉的认知模型：你在抄一本书，眼睛始终能看到原书（参考 token 全量可见），但手写的内容你只盯着最近几行（输出 token 滑动窗口）。早先写过的内容在认知中逐渐淡出，但原书始终在视野里。

落到实现上，Unlimited OCR 把所有注意力层全换成了 R-SWA。不是几层，是全部。这是一个激进的选择——意味着模型在每一个推理层都遵守「原文全可见、近输出可回看、远输出遗忘」的原则，从底层到顶层，一以贯之。

为什么这招以前没人用过

好问题。我一开始也不理解——既然滑动窗口这么自然，为什么 7 年来没人这么干？

答案藏在 OCR 任务的独特性里。

OCR 本质上是一个转录任务，不是推理任务。模型不需要「记住」第 3 页的内容才能处理第 30 页——它只需要始终「看得见」原文。输出侧的远端历史对当前生成几乎没有贡献，因为 OCR 的输出顺序严格对应图像的阅读顺序。

换句话说：OCR 是 R-SWA 的完美场景。输出 token 的远端依赖极弱，参考 token 的全量依赖极强——这恰好是滑动窗口注意力发挥最大优势的条件。

但在通用语言建模里，远端依赖是不可或缺的。一个故事开头埋的伏笔，到结尾才揭晓。如果滑动窗口把开头丢掉了，模型就断了线索。

所以论文末尾那句话特别值得玩味：「R-SWA 是通用解析机制，OCR 只是第一站。」

如果 R-SWA 能在 ASR（语音识别）和翻译中同样成立——转录任务天然具有「原文全可见、输出顺序依赖弱」的特性——那它的适用范围远不止 OCR。

DeepEncoder：另一个不可忽视的配角

R-SWA 解决了内存恒定的问题，但还差一环：视觉 token 的数量。

如果一张 1024×1024 的 PDF 页面编码成几千个视觉 token，那「参考 token 全量可见」就成了空话——全量可见意味着几千个 token 都要参与每一步注意力计算，复杂度 O(n) 还是会随页数增长。

DeepEncoder 在这里补上了关键一环。它把一张 1024×1024 的页面压缩到仅 256 个视觉 token，压缩率 16 倍。更关键的是，由于视觉 token 在 R-SWA 下不参与状态转移——它们永远驻留在「参考区」，不会被挤出队列——所以无论文档多长、页数多少，每页只有 256 个固定开销。

20 页文档 = 20 × 256 = 5120 个视觉 token。在 R-SWA 的参考区里，5120 个 token 的注意力计算量完全可以承受。40 页？10240 个。还是可控。

这就解释了为什么 Unlimited OCR 能在标准 32K 上下文里一次推理读完几十页——R-SWA 控住了输出侧的内存膨胀，DeepEncoder 控住了输入侧的 token 数量，两者配合，把长文档解析的内存瓶颈彻底拆掉了。

实测数据：不是理论漂亮，是真的能用

OmniDocBench v1.5，Unlimited OCR 93.23% vs DeepSeek OCR 87.01%，差 6.22 个百分点。这是总分的碾压。

但更有说服力的是效率数据。Flash Attention v3 的延迟测试里：

• DeepSeek OCR 的标准 MHA：解码步数增加，每步耗时稳步攀升。一条斜线往上走。
• Unlimited OCR 的 R-SWA：从头到尾一条水平线。纹丝不动。

输出 6144 个 token 时，Unlimited OCR 的 TPS 是 7847，DeepSeek OCR 已经掉到 5822。差距 35%。

20 页文档编辑距离 0.057。40 页以上 0.11。Distinct-35 高达 97%——几乎不重复输出。

公式 CDM 从 83.37 到 92.61。表格 TEDS 从 84.97 到 90.93。文本编辑距离从 0.073 到 0.038。

一个 500M 激活的 MoE 小模型，在 DeepSeek OCR 基础上仅继续训练 4000 步。论文称 R-SWA 对解析任务是「免费午餐」——训练成本几乎不增加，推理速度反而更快，内存恒定，效果全面提升。

我本来不太信「免费午餐」这种说法。但看完数据，不得不承认：对于转录类任务，R-SWA 确实接近免费。

那个署名 YY 的人

论文核心贡献者三位：Youyang Yin，Huanhuan Liu*（项目 leader），YY†（技术总监）。

两个人真名，技术总监两字母缩写。GitHub 致谢栏里 Deepseek-OCR 和 Deepseek-OCR-2 排前两位。

DeepSeek OCR 核心作者三人：魏浩然、孙耀峰、李宇琨。今年 4 月 V4 报告，魏浩然后面多了星号——已离职。三人中唯一公开离开的。

魏浩然履历：阶跃星辰出身→主导 GOT-OCR2.0→到 DeepSeek 搭起整条 OCR 线（DeepEncoder、MoE 解码器，一代到二代）→现在出现在百度的论文里，署名 YY。

从 GOT-OCR2.0 的端到端解析，到 DeepSeek-OCR 的视觉压缩，再到 R-SWA 的软遗忘注意力。同一个人，三个地方，一条从未断裂的技术脉络。他不是在换工作，他是在追同一个问题的终极解法。

论文展望里留了一句：下一步训到 128K 上下文，构建 prefill pool 让模型学会自动翻页。

R-SWA 不是 OCR 的终点。它是长程解析任务的一个新起点——而起点上的这个人，已经在这条路上走了三年。

GitHub：https://github.com/baidu/Unlimited-OCR

HuggingFace：https://huggingface.co/baidu/Unlimited-OCR