百度开源 Unlimited OCR：一次推理搞定几十页文档，DeepSeek-OCR 的天花板被捅破了

昨天刷 Hacker News 的时候看到一个项目直接冲到了首页第一，430 多分——百度开源了一个叫 Unlimited OCR 的模型。说实话第一反应是"百度开源？认真的？"。点进去看了下论文和代码，发现这东西确实有点东西。

简单说就是：它解决了 OCR 领域一个老大难问题——文档越长，模型越慢。传统方案处理长文档要么拆页要么分批，Unlimited OCR 用了一种新的注意力机制，能在 32K 上下文内一次性处理几十页文档，而且速度不掉。

OCR 的老问题：文档一长就拉胯

做过 OCR 的都知道，用大模型做文档识别效果确实好，尤其是 DeepSeek-OCR 出来之后，端到端的方案把传统 pipeline 打得找不着北。但有个要命的问题：输出序列越长，KV cache 越大，推理速度越慢。

想象一下你让一个实习生抄一份 50 页的报告。抄前 5 页的时候还挺利索，到第 20 页开始速度明显下降，到第 40 页基本就是在磨洋工了。因为每抄一行都要回头看看前面写了什么，避免重复，看得越多负担越重。

大模型做 OCR 也是这个道理。decoder 在生成每一行文字的时候，要 attend 到前面所有生成过的 token。10 页文档可能有几万个 token，注意力计算量是 O(n²) 的，到后面直接爆炸。

人就不会这样。你抄东西的时候不需要把前面抄过的所有内容都记在脑子里，只需要记住"当前这页在说什么"就够了。Unlimited OCR 就是模拟了这个机制。

R-SWA：让大模型学会"选择性失忆"

Unlimited OCR 的核心创新是 Reference Sliding Window Attention（R-SWA），翻译过来大概叫"参考滑动窗口注意力"。

传统 Transformer decoder 的注意力是全局的——每个 token 都能 attend 到所有之前的 token。R-SWA 把这个改了：

1. 固定大小的 KV cache：不管文档多长，KV cache 始终保持一个固定大小。不会随着输出增长而膨胀。
2. 滑动窗口：decoder 只关注最近生成的一段 token（窗口内的），而不是全部历史。
3. 参考机制：关键的上下文信息（比如当前页的内容）通过 encoder 压缩后作为"参考"注入，不占用 KV cache 空间。

这个设计的妙处在于：它利用了 DeepSeek-OCR encoder 的高压缩率。encoder 已经把图像内容压缩成了一组紧凑的 token，decoder 不需要反复回看原始图像信息，只需要基于 encoder 的压缩输出 + 滑动窗口内的近期生成就能工作。

论文里给了个数据：在标准 32K 最大长度下，Unlimited OCR 能一次性处理几十页文档。而且因为 KV cache 恒定，处理第 1 页和第 30 页的速度基本一样。这就很离谱了。

R-SWA 技术细节：为什么 KV cache 能恒定

这部分稍微深入一点，聊聊 R-SWA 的具体机制。不想看技术细节的可以跳过。

传统 Transformer decoder 的注意力计算是这样的：每生成一个新 token，都要计算它和所有之前 token 的注意力权重。如果有 N 个 token，每一步的计算量是 O(N)。生成 M 个 token 的总计算量就是 O(M²)。这就是为什么越长越慢。

R-SWA 的做法是把注意力分成两部分：

滑动窗口部分：decoder 只 attend 最近 W 个 token（比如 W=256）。这部分的 KV cache 大小固定为 W，新的 token 进来，老的 token 就被丢弃。计算量从 O(N) 变成了 O(W)，恒定的。

参考部分：encoder 输出的压缩表示作为"参考"注入到每一层 attention 中。这些参考 token 不占用 KV cache，而是直接作为 attention 的 key/value 输入。相当于告诉 decoder "这是当前页面的内容，别忘了"。

两者结合的效果是：decoder 既能记住当前处理的内容（通过参考 token），又能保持最近生成的上下文（通过滑动窗口），而且总资源消耗恒定。

打个比方：你抄东西的时候，左手按着当前要抄的那一页（参考），右手记着刚才写的最后几行（滑动窗口）。前面抄过的页面翻过去就翻过去了，不用一直盯着看。

论文还提到一个叫 ngram_window 的参数，从代码里可以看到单页用 128、多页用 1024。这个参数控制的就是滑动窗口的大小。多页场景需要更大的窗口，因为跨页的上下文依赖更多。

另外还有一个 no_repeat_ngram_size=35 的防重复机制。这个挺有意思——说明模型在长序列生成时确实会有重复输出的倾向（这是 LLM 的通病），所以用 ngram 约束来强制打断重复模式。35 这个值意味着如果检测到连续 35 个 token 构成了之前出现过的 ngram，就禁止继续生成这个模式。

和 DeepSeek-OCR 的关系

Unlimited OCR 不是从零开始做的，它明确说了是以 DeepSeek-OCR 为 baseline 进行改进。GitHub 的描述写得很直白："aiming to push DeepSeek-OCR one step further"。

改动主要集中在 decoder 部分——把所有 attention layer 替换成了 R-SWA。encoder 部分基本沿用 DeepSeek-OCR 的设计，保留了高压缩率的优势。

所以你可以把 Unlimited OCR 理解成"DeepSeek-OCR 的长文档特化版"。短文档两者差别不大，但文档一长（超过 10 页），差距就出来了。

另外论文提到 R-SWA 不只是能用在 OCR 上，它是一种通用的 parsing 注意力机制，理论上也能用在 ASR（语音识别）、翻译等序列到序列的任务上。不过目前开源的只有 OCR 模型。

怎么用

项目提供了两种推理方式：Transformers 和 SGLang。

Transformers 方式（适合单卡）

import torch

from transformers import AutoModel, AutoTokenizer

model_name = 'baidu/Unlimited-OCR'

tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)

model = AutoModel.from_pretrained(

    model_name,

    trust_remote_code=True,

    use_safetensors=True,

    torch_dtype=torch.bfloat16,

)

model = model.eval().cuda()

# 单张图片，两种模式：gundam（裁剪模式）和 base（不裁剪）

model.infer(

    tokenizer,

    prompt='<image>document parsing.',

    image_file='your_image.jpg',

    output_path='your/output/dir',

    base_size=1024, image_size=640, crop_mode=True,

    max_length=32768,

    no_repeat_ngram_size=35, ngram_window=128,

    save_results=True,

)

注意两个模式的区别：

• gundam 模式：base_size=1024, image_size=640, crop_mode=True，会把大图裁成小块分别处理再合并，适合单页高分辨率文档
• base 模式：base_size=1024, image_size=1024, crop_mode=False，不裁剪直接处理，适合多页文档

多页 PDF 处理

这个才是重头戏。把 PDF 转成图片再批量处理：

import tempfile, fitz  # PyMuPDF

def pdf_to_images(pdf_path, dpi=300):

    doc = fitz.open(pdf_path)

    tmp_dir = tempfile.mkdtemp(prefix='pdf_ocr_')

    mat = fitz.Matrix(dpi / 72, dpi / 72)

    paths = []

    for i, page in enumerate(doc):

        out = os.path.join(tmp_dir, f'page_{i+1:04d}.png')

        page.get_pixmap(matrix=mat).save(out)

        paths.append(out)

    doc.close()

    return paths

model.infer_multi(

    tokenizer,

    prompt='<image>Multi page parsing.',

    image_files=pdf_to_images('your_doc.pdf', dpi=300),

    output_path='your/output/dir',

    image_size=1024,

    max_length=32768,

    no_repeat_ngram_size=35, ngram_window=1024,

    save_results=True,

)

SGLang 部署（适合生产环境）

如果要搞成服务跑在生产环境，可以用 SGLang 部署成 OpenAI 兼容的 API：

uv venv --python 3.12

source .venv/bin/activate

uv pip install wheel/sglang-0.0.0.dev11416+g92e8bb79e-py3-none-any.whl

uv pip install kernels==0.11.7

uv pip install pymupdf==1.27.2.2

启动服务器：

python -m sglang.launch_server \

    - -model baidu/Unlimited-OCR \

    - -served-model-name Unlimited-OCR \

    - -attention-backend fa3 \

    - -page-size 1 \

    - -mem-fraction-static 0.8 \

    - -context-length 32768 \

    - -enable-custom-logit-processor \

    - -disable-overlap-schedule \

    - -skip-server-warmup \

    - -host 0.0.0.0 \

    - -port 10000

然后就可以用标准的 OpenAI API 格式发请求了，支持流式输出。

实际体验的一些坑

先说结论：效果确实不错，但踩坑也是真的踩。

依赖版本很新：要求 torch==2.10.0、transformers==4.57.1，这些版本都比较新。我本地的环境是 torch 2.5，直接装会报版本冲突。建议用 uv 或者新建一个虚拟环境专门搞。

显存需求：bfloat16 加载大概需要 16-20GB 显存（取决于模型具体大小）。单张 4090（24GB）应该能跑，但处理长文档的时候显存峰值可能会涨。如果显卡不够，可以试试 SGLang 的量化方案。

SGLang 版本很特殊：注意 SGLang 不是直接 pip install sglang，项目提供了一个本地 wheel 文件 sglang-0.0.0.dev11416+g92e8bb79e-py3-none-any.whl。这个是基于特定 commit 构建的，可能包含了 R-SWA 的支持。用官方 PyPI 版本的 SGLang 可能跑不起来。

no_repeat_ngram_size 参数：代码里用了 no_repeat_ngram_size=35 来避免重复生成。这个值比较大，说明模型在长文档场景下确实容易出现重复输出的问题。如果发现输出有重复段落，可以适当调大这个参数。

PDF 转图片有损：PDF 先转成 300 DPI 的图片再 OCR，这个过程中会丢失一些矢量信息（比如文字的精确边缘）。对于纯文字文档影响不大，但如果 PDF 里有很精细的图表或公式，建议提高 DPI 到 600。

和其他 OCR 方案的对比

说说我自己的判断。

vs PaddleOCR：PaddleOCR 是百度自家的传统 OCR 方案，pipeline 模式（检测 + 识别 + 后处理）。速度快、部署简单，但对复杂版式（表格嵌套、多栏、公式混排）处理得不好。Unlimited OCR 是端到端方案，复杂版式天然优势。

vs DeepSeek-OCR：前面说了，Unlimited OCR 是 DeepSeek-OCR 的改进版。短文档差别不大，长文档 Unlimited OCR 优势明显。如果你的场景经常要处理 10 页以上的文档，选 Unlimited OCR。如果只处理单页或几页，DeepSeek-OCR 也够用。

vs GPT-4o / Claude 的视觉能力：这些闭源模型的 OCR 能力也很强，但成本高、有隐私顾虑、不适合大批量处理。Unlimited OCR 开源免费，本地部署数据不出门。

vs 传统 OCR 工具（Tesseract 等）：不在一个时代。Tesseract 对版式干净的英文文档还行，中文、复杂版式、手写体基本没法看。大模型时代了，别再用 Tesseract 了。

适用场景

我觉得这个模型最适合这些场景：

• 批量文档数字化：公司有一堆扫描件要转成结构化文本，几十页几百页的那种
• 学术论文处理：PDF 论文转 Markdown，保留公式和表格结构
• 发票/合同处理：金融场景下的批量文档解析
• 档案数字化：图书馆、档案馆的历史文档数字化项目

不太适合的场景：

• 实时 OCR（比如摄像头识别）：大模型推理还是太慢，不如轻量方案
• 纯数字/条码识别：杀鸡用牛刀
• 显卡资源紧张的环境：至少需要一张 16GB+ 的卡

常见问题

Q：需要多大的显卡？ A：bfloat16 精度下大概需要 16-20GB 显存。单张 RTX 4090（24GB）能跑，但处理长文档时峰值可能会涨到接近上限。如果显卡只有 12GB（比如 4070 Ti），可以试试量化版本，但目前官方没有提供量化权重，需要自己搞。

Q：和 PaddleOCR 什么关系？ A：技术上有关联（都出自百度），但定位完全不同。PaddleOCR 是传统 pipeline 方案（文字检测 → 文字识别 → 后处理），轻量、快速，适合嵌入式和实时场景。Unlimited OCR 是大模型端到端方案，重、慢，但效果好、能处理复杂版式。两者不是替代关系，是不同场景的不同选择。

Q：能处理中文吗？ A：能。百度做的模型，中文支持是基本功。从代码示例看，prompt 用的是英文（document parsing.），但输出会根据文档语言自动识别。实际效果等我测了再补充。

Q：能处理手写体吗？ A：论文没明确说手写体的效果。但端到端大模型通常对手写体的识别能力比传统方案强，因为它能利用语言模型的上下文理解来纠正识别错误。具体效果得测。

Q：能处理表格和公式吗？ A：从 DeepSeek-OCR 的能力推断，表格和公式应该支持，但准确率取决于文档质量。扫描件的表格线如果断断续续，识别效果会打折扣。LaTeX 公式的识别是大模型的强项，应该问题不大。

Q：支持哪些语言？ A：论文没详细列，但从 arXiv 分类（cs.CV + cs.CL）和百度的技术背景推断，中英文肯定是支持的。其他语言得看训练数据覆盖。

为什么百度要开源这个

说实话，百度在开源方面一直比较"选择性"。PaddlePaddle、PaddleOCR 开源得早，但核心的大模型（文心一言系列）一直没开源。这次 Unlimited OCR 开源，我觉得有几个可能的原因：

1. 学术影响力：论文发在 arXiv 上，开源代码能增加引用量和学术影响力
2. PaddlePaddle 生态：项目依赖了 PaddlePaddle 的一些组件，开源能带动生态
3. 竞争策略：DeepSeek-OCR 开源了，百度不做点回应说不过去
4. 实际影响有限：OCR 模型不像大语言模型那样有商业敏感性，开源出去不伤筋动骨

不管动机是什么，对开发者来说是好事。多一个高质量的开源 OCR 方案，选择更多。

安装踩坑记录

我实际装的时候遇到了几个问题，记一下：

问题 1：PyMuPDF 版本冲突 pymupdf==1.27.2.2 这个版本比较新，如果系统里有老版本的 pymupdf 或者 fitz，会冲突。建议直接 pip install pymupdf==1.27.2.2 --force-reinstall。

问题 2：trust_remote_code 加载模型的时候必须加 trust_remote_code=True，因为模型代码里有自定义的 R-SWA 实现。不加会报错说找不到对应的 attention 类。

问题 3：模型下载 模型在 HuggingFace 上（baidu/Unlimited-OCR），国内下载可能比较慢。项目也提供了 ModelScope 的镜像（PaddlePaddle/Unlimited-OCR），国内用户建议用这个。

# 用 ModelScope 下载（国内更快）

from modelscope import AutoModel, AutoTokenizer

model_name = 'PaddlePaddle/Unlimited-OCR'

性能基准和对比数据

论文里给了不少 benchmark 数据，我挑几个关键的说。

在标准文档 OCR 测试集上，Unlimited OCR 和 DeepSeek-OCR 的短文档性能基本持平（差距在 1% 以内）。但在长文档场景下（20 页以上），Unlimited OCR 的吞吐量是 DeepSeek-OCR 的 2-3 倍，因为它不需要反复处理增长的 KV cache。

内存方面，处理 30 页文档时 DeepSeek-OCR 的 KV cache 可能涨到 40GB+（单卡放不下），Unlimited OCR 始终保持在 8-10GB 左右。这个差距在实际部署中很关键——意味着你可以用更便宜的卡跑更长的文档。

不过要注意，这些数据都是论文自己报的。实际效果还得看真实场景的测试。论文的测试集和你的实际文档可能差距很大。我后面会拿中文论文和发票做个实测。

和 AI Agent 的结合

这个模型如果放到 AI Agent 的工作流里，能做的事情就多了。

比如搞一个文档处理 Agent：丢一堆 PDF 进去，Agent 自动 OCR → 结构化 → 提取关键信息 → 生成摘要。之前用 DeepSeek-OCR 的话，长文档需要分批处理再拼接，逻辑比较复杂。Unlimited OCR 一次搞定，Agent 的代码能简化不少。

再比如 RAG（检索增强生成）的文档预处理：把 PDF 丢给 Unlimited OCR 转成 Markdown，然后切块、embedding、存向量库。之前这个环节用 PaddleOCR 的话，表格和公式经常识别错，导致后续的切块和检索效果很差。用大模型 OCR 能保留更多结构信息。

我自己的场景是维护 totb0311.site 的时候经常需要从 PDF 技术文档里提取信息写文章。之前用 pymupdf 提取文字，遇到扫描件就傻眼了。如果搞个 Unlimited OCR 的 pipeline，扫描件也能自动转文本，效率应该能提升不少。

开源社区的反应

Hacker News 上 430 分，评论区讨论挺热烈的。主要几个观点：

支持派："终于有人认真做开源 OCR 了，PaddleOCR 用了很多年该升级了。" 质疑派："百度开源的动机值得怀疑，可能是为了推 PaddlePaddle 生态。" 实用派："管他什么动机，效果好就行。先试试再说。"

GitHub 上一天之内 3000+ star，说明社区对高质量开源 OCR 方案的需求确实很大。之前 DeepSeek-OCR 开源的时候也是类似的热度。

有意思的是评论区也有人提到了 GOT-OCR（另一个开源 OCR 方案），但 GOT-OCR 的 star 数和社区活跃度明显不如这个。可能是因为百度的品牌效应加上 HN 的传播加成。

一点想法

OCR 这个方向看起来不性感，但它解决的是一个很实际的问题：让机器能读懂人类世界里的文字。不管是扫描件、照片、PDF 还是手写笔记，第一步都是"看懂"。

Unlimited OCR 的 R-SWA 机制其实解决的是一个更通用的问题：如何在固定资源下处理任意长度的序列。这个思路如果能推广到其他任务（翻译、语音、视频理解），想象空间就大了。

论文里也提到了这点，说 R-SWA 是"通用的 parsing 注意力机制"，不只是 OCR。但目前只开源了 OCR 模型，其他方向的效果还得等后续验证。

3000 多个 star，Hacker News 430 分，说明社区对这个方向是有需求的。大模型的能力越来越强，但怎么在有限资源下发挥最大效能，R-SWA 给出了一个有意思的答案。

后面我打算拿几个实际的 PDF 测试一下效果，尤其是中文论文和表格密集的文档，到时候再写一篇实测对比。

具体计划：

• 测试 1：一篇 30 页的中文论文（arXiv 风格，公式+图表混排）
• 测试 2：一份 50 页的商业合同（扫描件，有骑缝章那种）
• 测试 3：一组发票图片（不同格式、不同语言）
• 对比方案：DeepSeek-OCR、GPT-4o 视觉、PaddleOCR

每个测试都会记录识别准确率、处理时间、显存占用。感兴趣的话先关注一下，结果出来了第一时间发。

对了，项目还提供了批量推理的脚本 infer.py，能自动启动 SGLang 服务器并发处理。如果你的场景是大批量文档处理，建议直接用这个脚本，比自己写循环方便多了。

有啥问题评论区聊。

• 项目地址：github.com/baidu/Unlimited-OCR*

• 论文：arXiv:2606.23050*

• 本文写于 2026 年 6 月 24 日*