Unlimited-OCR：百度开源，单次前向传播解析数十页文档

Unlimited-OCR：百度开源，单次前向传播解析数十页文档

Seven
  2026-06-24 16:00 2026-06-24 16:00 创建   2026-07-14 00:18:15 2026-07-14 00:18:15 更新      2.1k 字  8 分钟  

6 月 22 日，百度在 GitHub 上开源了 Unlimited-OCR，一个 3B 参数的多语言文档解析模型。发布 48 小时内，GitHub 星标冲到 2800+，Hacker News 上拿到 419 分和 96 条讨论，HuggingFace 收获 169 个赞。更夸张的是，社区在两天内就搞出了 AMD ROCm 移植、FastAPI 服务封装、RAG 管线集成、甚至历史档案文档测试——这个速度在开源 OCR 领域很少见。

它解决的核心问题很简单：现有的端到端 OCR 模型（比如 DeepSeek-OCR）在处理长文档时，KV Cache 会随输出长度线性增长，显存越吃越多，速度越来越慢。Unlimited-OCR 用一种叫 R-SWA（参考滑动窗口注意力）的机制，让 KV Cache 在整个解码过程中保持恒定，从而实现「单次前向传播，解析数十页文档」。

Unlimited-OCR 概览

一、为什么需要 Unlimited-OCR

传统 OCR 流水线是「检测 → 识别 → 后处理」三段式，每段都是独立模型，错误会逐级累积。近两年，以 DeepSeek-OCR 为代表的端到端方案用视觉语言模型（VLM）直接「看图说话」，把三步合成一步，效果显著提升。

但端到端方案有一个结构性缺陷：KV Cache 线性增长。

当你用 LLM 做解码器时，每生成一个 token，它的 Key-Value 对就会被缓存下来，供后续 token 做注意力计算。对于一页文档，这没什么问题。但如果你要处理一份 50 页的 PDF，输出序列可能长达数万 token，KV Cache 会吃掉大量显存，生成速度也会逐 token 下降。

这就像抄写员的工作效率会随抄写页数增加而下降一样——人类不会这样，但 LLM 会。

Unlimited-OCR 的论文标题是「Unlimited OCR Works」，副标题是「Welcome the Era of One-shot Long-horizon Parsing」。它要解决的正是这个问题：让模型像人一样，无论抄多少页，效率都不下降。

二、R-SWA：参考滑动窗口注意力

R-SWA 是 Unlimited-OCR 的核心技术，全称 Reference Sliding Window Attention。它的设计思路很直观：

R-SWA 架构

对文档图像保持全局注意力，对生成的文本 token 只用滑动窗口。

具体来说：

  • 视觉编码器处理文档图像，输出 256 个 visual token，这些 token 始终参与后续的注意力计算（全局参考）
  • 解码器生成文本时，只对最近的 128 个 output token 做注意力（滑动窗口）
  • 更早的 output token 会被窗口「滑过」，不再参与计算

这个设计的妙处在于：visual token 的数量是固定的（256），output token 的窗口也是固定的（128），所以 KV Cache 的总量恒定不变，无论文档有多长。

论文中的实测数据验证了这一点：在 AMD Radeon PRO W7900（16GB 显存）上，从 1 页到 50 页，显存占用只增加了 0.2 GB——从 7.3 GB 到 7.5 GB，几乎是一条水平线。

三、技术细节

3.1 模型架构

Unlimited-OCR 基于 DeepSeek-OCR 架构，但把解码器中所有的注意力层替换成了 R-SWA。模型参数量 3B，最大输出长度 32,768 tokens。

3.2 两种推理模式

推理流程

模型提供两种图像处理配置：

  • Gundam 模式：base_size=1024, image_size=640, 启用裁剪。适合密集文档（表格多、字号小、排版复杂）
  • Base 模式：base_size=1024, image_size=1024, 不裁剪。适合单页清晰文档和多页 PDF

多页 PDF 只能用 Base 模式，因为裁剪会破坏跨页连贯性。

3.3 去重机制

模型使用 ngram 去重来防止重复生成：

  • 单图：ngram_size=35, ngram_window=128
  • 多图：ngram_size=35, ngram_window=1024

这是一个实用的工程技巧——纯靠注意力机制很难完全避免重复，加一层 ngram 约束能显著提升输出质量。

3.4 部署方式

支持两种部署方式：

本地 Transformers 推理（需要 NVIDIA GPU）：

1
2
3
4
5
6
7
8
9
from transformers import AutoModel, AutoTokenizer

model = AutoModel.from_pretrained('baidu/Unlimited-OCR', trust_remote_code=True)
model = model.eval().cuda()

model.infer(tokenizer, prompt='<image>document parsing.',
            image_file='doc.jpg', output_path='./output',
            base_size=1024, image_size=640, crop_mode=True,
            max_length=32768)

SGLang 服务化部署（OpenAI 兼容 API）：

1
2
3
4
5
6
python -m sglang.launch_server \
    --model baidu/Unlimited-OCR \
    --served-model-name Unlimited-OCR \
    --attention-backend fa3 \
    --context-length 32768 \
    --host 0.0.0.0 --port 10000

SGLang 方式会启动一个 OpenAI 兼容的 REST API，可以用标准的 chat/completions 接口调用，支持流式输出。

四、与同类模型对比

OCR 模型对比

模型 参数量 多页单次 KV Cache 许可证 显存需求
Unlimited-OCR 3B 数十页 恒定 MIT 16 GB
DeepSeek-OCR 4B 单页 线性增长 MIT 24 GB+
DeepSeek-OCR-2 3B 单页 线性增长 MIT 16 GB
PaddleOCR-VL-1.6 0.9B 单页 线性增长 Apache-2.0 4 GB
Mistral OCR 4 闭源 多页 未知 闭源 API $4/千页
Qianfan-OCR 4.7B 单页 线性增长 Apache-2.0 24 GB

Unlimited-OCR 的差异化优势很明确：它是唯一一个能在开源条件下实现 KV Cache 恒定的多页 OCR 模型。PaddleOCR-VL-1.6 虽然只有 0.9B 参数、显存需求最低，但只能单页处理。Mistral OCR 4 虽然也支持多页，但它是闭源 API，每千页收费 4 美元。

值得注意的是，PaddleOCR-VL-1.6 在 OmniDocBench 上拿到了 96.33 的 SOTA 分数——说明在单页精度上，小模型也能做到极致。Unlimited-OCR 的价值不在于单页精度更高，而在于长文档场景下的效率和成本优势。

五、社区生态

Unlimited-OCR 发布后的社区反应速度令人印象深刻：

社区生态

模型适配：

  • HuggingFace Transformers 正在添加原生支持（PR #46836）
  • MLX-VLM 已支持 Apple Silicon（macOS 上用 MPS 推理）
  • ROCm 移植已在 AMD W7900 上验证，56 tok/s，仅需 16GB 显存

应用集成：

  • Docling（IBM 的文档处理框架）正在添加 VLM Preset 支持
  • FastAPI 服务封装已有人做
  • RAG 管线集成（用 Unlimited-OCR 做视觉输入）

对比测试：

  • 有人在用历史档案文档（1966 年手写明信片、1919 年报纸）做对比测试，与 Claude Vision 和 Docling 对比

Hacker News 讨论焦点：

  • 「OCR 到底解决了没有？」——怀疑派认为传统 OCR 更快更便宜，实践派指出复杂版面（表格、多栏、中日韩文字）仍然是难题
  • R-SWA 被认为是「把工程实践中手动切片/分块的做法形式化了」
  • 与 Mistral OCR 4 的对比：开源 MIT vs 闭源 API，价格差 10 倍以上

六、局限性

  1. 仅支持 NVIDIA GPU 的 Transformers 推理：代码中 .cuda() 是硬编码的，不支持 CPU 或 MPS。虽然社区已有 ROCm 和 MLX 移植，但官方代码还没合入
  2. 没有官方 benchmark 分数：论文没有在 OlmOCRBench、OmniDocBench 等标准测试集上报告数字，与 Mistral OCR 4 的对比缺乏定量数据
  3. 单页精度未必最优：从参数量和架构设计看，Unlimited-OCR 的重点是长文档效率，单页精度可能不如专门优化的 PaddleOCR-VL-1.6
  4. 幻觉风险：和所有 VLM 一样，它可能会「编造」文档中不存在的内容，或者把英文翻译成中文——这在 Hacker News 讨论中被多人提到
  5. GIF 演示太大：官方的 long-horizon-ocr.gif 有 82MB，不适合直接嵌入网页

七、快速上手

最简单的上手方式是用 HuggingFace Transformers：

1
pip install torch transformers Pillow pymupdf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import torch
from transformers import AutoModel, AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained('baidu/Unlimited-OCR', trust_remote_code=True)
model = AutoModel.from_pretrained(
    'baidu/Unlimited-OCR', trust_remote_code=True,
    use_safetensors=True, torch_dtype=torch.bfloat16
).eval().cuda()

# 单页文档
model.infer(tokenizer, prompt='<image>document parsing.',
            image_file='invoice.jpg', output_path='./output',
            base_size=1024, image_size=640, crop_mode=True)

# 多页 PDF
import fitz, tempfile, os
doc = fitz.open('report.pdf')
pages = []
for i, page in enumerate(doc):
    path = f'/tmp/page_{i:04d}.png'
    page.get_pixmap(matrix=fitz.Matrix(4, 4)).save(path)
    pages.append(path)

model.infer_multi(tokenizer, prompt='<image>Multi page parsing.',
                  image_files=pages, output_path='./output',
                  image_size=1024, max_length=32768)

如果想用 SGLang 做服务化部署，官方仓库的 README 里有完整的启动命令和客户端代码。

八、相关链接

  • 标题: Unlimited-OCR：百度开源，单次前向传播解析数十页文档
  • 作者: Seven
  • 创建于 : 2026-06-24 16:00:00
  • 更新于 : 2026-07-14 00:18:15
  • 链接: https://blog.oneiseven.top/2026/06/24/Unlimited-OCR-百度开源单次解析数十页文档的OCR模型/
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论
目录
Unlimited-OCR：百度开源，单次前向传播解析数十页文档
  1. 一、为什么需要 Unlimited-OCR
  2. 二、R-SWA：参考滑动窗口注意力
  3. 三、技术细节
    1. 3.1 模型架构
    2. 3.2 两种推理模式
    3. 3.3 去重机制
    4. 3.4 部署方式
  4. 四、与同类模型对比
  5. 五、社区生态
  6. 六、局限性
  7. 七、快速上手
  8. 八、相关链接