百度在OCR领域扔下了一颗炸弹
> 项目：百度 UnlimitedOCR（开源，MIT许可证） > 核心突破：R-SWA注意力机制 + DeepEncoder视觉压缩 > 发布时间：2026年6月22日
—
一个反直觉的结果
3B参数。500M激活。一次前向传播读完40页PDF。
而它的竞争对手呢？
| 模型 | 参数量 | OmniDocBench v1.5 |
|---|---|---|
| UnlimitedOCR | 3B（激活500M） | 93.23% |
| Qwen3-VL | 235B | 89.15% |
| Qwen2.5-VL | 72B | 87.02% |
| Gemini-2.5 Pro | 未公开 | 88.03% |
这不是”以小博大”。这是用正确的架构做正确的事，然后把堆参数的人甩在了身后。
—
长文档OCR的”失忆”难题
传统的端到端OCR模型有一个致命弱点：输出越长，越慢、越蠢。
原因很简单——标准的多头注意力机制（MHA）在解码时，每生成一个新token，都要把前面所有token的Key和Value存进KV缓存。这个缓存随着输出长度线性增长：
![\[C_{MHA}(T) = L_m + T\]](https://www.zhichai.top/wp-content/ql-cache/quicklatex.com-f95dc438b61fc7cb4f730f63225cb5f1_l3.svg "Rendered by QuickLaTeX.com")
– 
是输入（视觉token + prompt）的长度
– 
是已生成的输出长度
结果是：解析10页文档时速度还可以，到20页开始明显变慢，到40页要么爆显存，要么慢得令人发指。
工程上的 workaround 是什么？分页解析 + 结果拼接。 每页单独处理，最后把Markdown片段缝在一起。
但拼接带来新问题：跨页表格被切成两半、阅读顺序错乱、上下文信息丢失。你在第1页定义的缩写在第30页出现时，模型早忘了。
这就是OCR领域的”失忆”问题——模型不是真的在”读”文档，而是在逐页抄写，抄完一页清空记忆。
—
R-SWA：让KV缓存变成常数
UnlimitedOCR的核心创新是 Reference Sliding Window Attention（参考滑动窗口注意力）。
它的设计非常直觉化，甚至可以说”朴素”——但正是这种朴素，击中了问题的要害。
机制
每个新生成的token，只看两部分：
1. 全量参考：所有视觉token（原始文档图像）+ prompt——永远完整保留，因为这是识别的依据，不能丢 2. 滑动窗口：前面最近的128个输出token——超过128个的，直接遗忘
数学上：
![\[C_{R-SWA}(T) = L_m + min(n, T) leq L_m + n\]](https://www.zhichai.top/wp-content/ql-cache/quicklatex.com-89731100b7cea05ac8d63002f4ffa71e_l3.svg "Rendered by QuickLaTeX.com")
其中 
是滑动窗口大小。
无论输出多长，KV缓存被严格限制在一个常数范围内。
当 
时，缓存比例趋近于零。内存平坦，每步延迟平坦。
类比
想象你在抄一本书。
– 标准注意力：你每写一个字，都要回头重读前面写过的所有内容。写到第1000字时，你得翻回第1字开始核对。 – R-SWA：你眼睛始终盯着原文（全量视觉参考），但只记得刚写的最后一两行（128个token的窗口）。前面的内容？ trusting the process，继续写。
这不是”遗忘”——这是有选择的工作记忆管理。
—
DeepEncoder：16倍压缩的视觉信息
R-SWA解决了解码端的内存问题，但输入端还有一个挑战：40页PDF的图像数据量巨大。
UnlimitedOCR的解决方案是 DeepEncoder——一个级联的视觉压缩器：
1. SAM-ViT（窗口注意力）处理局部细节 2. CLIP-ViT（全局注意力）捕捉整体语义 3. 桥接层做16× token压缩
效果：一张1024×1024的PDF页面，被压缩到256个视觉token。
40页 × 256 = 10,240个视觉token，再加上输出token，完全可以在32K上下文窗口内一次性处理。
而且视觉token在R-SWA中不参与状态转移——它们作为”参考”被读取，但不会被写入KV缓存。这意味着原始图像信息的清晰度不会随着解码过程退化。
—
性能：不止于”能读”，而是”读得好、读得快”
准确度
| 指标 | DeepSeek OCR | UnlimitedOCR | 提升 |
|---|---|---|---|
| 综合得分 (v1.5) | 87.01 | 93.23 | +6.22% |
| 文本编辑距离 | 0.073 | 0.038 | 更接近原文 |
| 公式识别 CDM | 83.37 | 92.61 | +9.24% |
| 表格结构 TEDS | 84.97 | 90.93 | +5.96% |
| 阅读顺序 | 0.086 | 0.045 | 更准确 |
40页文档的编辑距离控制在0.11以下，Distinct-35高达97%——意味着几乎没有机械性复读。
速度
| 输出长度 | DeepSeek OCR | UnlimitedOCR | 差距 |
|---|---|---|---|
| 256 tokens | 7229 TPS | 7230 TPS | 持平 |
| 1024 tokens | 7423 TPS | 7841 TPS | +5.6% |
| 2048 tokens | 7167 TPS | 7881 TPS | +10.0% |
| 4096 tokens | 6430 TPS | 7905 TPS | +22.9% |
| 6144 tokens | 5823 TPS | 7848 TPS | +34.8% |
越长的输出，优势越明显。因为标准注意力的KV缓存随输出膨胀，而R-SWA保持恒定。
—
为什么是百度？为什么是现在？
几个值得注意的背景：
1. 技术路线：UnlimitedOCR基于DeepSeek OCR继续训练（4000步，冻结Encoder，只训Decoder），不是从零开始。这说明了什么？好的基座 + 精准的改动 = 巨大的提升。这不是堆算力的胜利，是架构设计的胜利。
2. 人才流动：核心贡献者之一署名”YY†”，行业观察者高度疑似前DeepSeek OCR团队负责人魏浩然——曾主导GOT-OCR 2.0和DeepSeek-OCR系列。如果属实，这是百度在顶尖技术人才争夺战中的一次关键收获。
3. 开源策略：MIT许可证、GitHub + HuggingFace同步发布、5天Star破万、登顶GitHub/HuggingFace四榜第一。百度在用行动证明：国产模型的开源竞争力正在快速追赶。
4. 商业逻辑：昆仑芯计划赴港上市（目标估值约500亿美元）。UnlimitedOCR的成功展示了自研芯片+自研模型的协同潜力。
—
更大的图景：R-SWA不只属于OCR
论文把R-SWA定位为 “通用解析注意力”（General Parsing Attention）——不只适用于OCR，还可扩展到：
– ASR（自动语音识别）：长音频转录 – 翻译：长文本连续翻译 – 任何需要”长输出、恒定内存”的生成任务
这是一个架构层面的贡献，不是OCR垂直领域的trick。
它揭示了一个更深层的设计原则：不是所有任务都需要全量历史上下文。 对于”从图像/音频到结构化文本”的映射任务，最近的局部上下文 + 全量原始输入参考，往往比无限累积的KV缓存更高效、更精准。
—
局限与诚实
UnlimitedOCR不是万能的：
– 32K上下文仍是硬上限——不是真正的”无限”，只是”在窗口内不失忆” – 长prefill仍存在：视觉token压缩了，但40页的prefill阶段仍然需要处理10K+ token – Base模式的多页限制：多页推理只能用Base模式（1024分辨率），Gundam模式（640分辨率+crop）仅限单页 – ASR/翻译迁移仍是未来工作，尚未验证
—
一个信号
AI行业正在经历一场从”越大越好”到”越对越好”的转变。
UnlimitedOCR用3B参数击败了235B的通用多模态模型，不是因为3B > 235B，而是因为：
专门为长文档解析设计的架构，在文档解析任务上，比通用架构更高效。
这个信号不只属于OCR。它属于所有正在被”通用大模型”挤压的垂直领域——当专用架构找到正确的切入点时，它可以以极小的成本实现超越。
对于开发者和研究者来说，这意味着：别只盯着参数量。盯着问题本身。
—
参考
– GitHub：https://github.com/baidu/Unlimited-OCR – HuggingFace：https://huggingface.co/baidu/Unlimited-OCR – 论文：https://arxiv.org/pdf/2606.23050 – 许可证：MIT – 核心创新：R-SWA（Reference Sliding Window Attention）
#OCR #文档解析 #百度 #开源 #长上下文 #注意力机制 #R-SWA #深度学习