❀
百度刚刚开源了 Unlimited-OCR：把几百页 PDF 扔进去，一次读完
你有没有试过把一份一百多页的扫描合同丢进 OCR 软件，然后看着它一页一页慢慢啃，啃到中间还经常卡住？
反正我是经历过。那种感觉就像是让一个人把一本书拆成单页、一张一张抄写、最后再拼起来——费时费力，还容易出错。
传统的 OCR 在短文档上表现不错，但一旦面对几十上百页的长 PDF，就开始露出疲态。页面之间的表格被切断、阅读顺序错乱、页眉页脚混进正文……你得多写一大堆后处理代码来缝补这些碎片。
百度在 6 月 18 日开源了一个叫 Unlimited-OCR 的模型，MIT 许可证，完全免费。
从名字就能看出来——它号称可以”无限”地一次性读完一整份文件，不管多少页。
截至今天，GitHub 上已经 4600+ 星了。我试用了一周，来聊聊它到底值不值得用。
❀
长文档 OCR 一直以来的痛点
先说说为什么传统的 OCR 碰到长文档就拉胯。
现在的 OCR 大多基于 Transformer 架构。这类模型的工作方式是：每生成一个输出词，都要”回头看”自己之前生成的每一个词。
文档短，没问题。文档一长——问题就来了：
- 内存线性增长：模型输出的内容越多，它需要记住的东西就越多
- 速度越来越慢：每生成一个新词，计算量都会增加
- GPU 根本扛不住：几十页的文档很快就撑爆显存
所以大多数系统干脆放弃一次性处理，改成”读一页 → 清空内存 → 读下一页 → 再清空”。这当然能用，但也带来了新问题：跨页的表格被切断、阅读顺序错乱、页面间的逻辑关系丢失。
百度论文里有一句话特别直接：“现有模型甚至无法在单次前向传播中解析十页文件。”
❀
Unlimited-OCR 的解法：像人一样阅读
百度的研究团队问了一个很有意思的问题：人是怎么抄写长篇文档的？
你肯定不会每写一个字就把前面写过的所有字重新读一遍。你会：
- 把原文档放在面前
- 瞥一眼刚刚写完的那几个字
- 然后写下一个字
仅此而已。前面的内容会自然从你的工作记忆中淡出。
Unlimited-OCR 的核心创新 —— R-SWA（Reference Sliding Window Attention，参考滑动窗口注意力机制） —— 模仿的就是这个过程。
它做了一件很简单但又很聪明的事：
传统 OCR vs Unlimited-OCR
- 原文图像：传统 ✅ / Unlimited ✅
- 最近生成内容：传统 ✅ 不断累积 / Unlimited ✅ 只保留最近~128词元
- 所有历史内容：传统 ✅ 不断增长 / Unlimited ❌ 固定大小
关键点在于：原文图像的视觉表示永远不会退化或模糊，而已经输出的文本只保留一个小窗口。
这意味着什么？
文档越长，对比越明显——输出越多，但 KV 缓存大小不变，内存稳定，速度一致。
处理 40 页文件和 2 页文件，效率基本一样。
❀
核心参数速览
- 参数量：30 亿（BF16 精度，权重约 6GB）
- 上下文窗口：32768 token
- 许可证：MIT（可商用，零费用）
- 硬件门槛：8-12GB VRAM 的 NVIDIA GPU 即可运行
- 基准测试：OmniDocBench v1.5 得分 93%，比 DeepSeek-OCR 高出 6%
- 长文档吞吐量：提升约 35%
- 技术基础：基于 DeepSeek-OCR，保留了 DeepEncoder（1024×1024 图片压缩为仅 256 个视觉词元），解码器升级为 MoE + R-SWA
❀
怎么用？两条路
方案一：Hugging Face Transformers（适合集成到项目）
from transformers import AutoModel, AutoTokenizer
import torch
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,
torch_dtype=torch.bfloat16
).eval().cuda()
# gundam 模式：快速，适合密集页面
model.infer(tokenizer, prompt='document parsing.',
image_file='documento.jpg', base_size=1024,
image_size=640, crop_mode=True, max_length=32768)
两种模式可选：
- gundam 模式（
image_size=640, crop_mode=True）：快，适合文字密集页面 - base 模式（
image_size=1024, crop_mode=False）：全分辨率，复杂版面和多页文档更准
方案二：命令行批量处理
仓库自带的 infer.py 脚本可以直接处理文件夹中的图片和 PDF：
git clone https://github.com/baidu/Unlimited-OCR
cd Unlimited-OCR
python -m venv .venv && source .venv/bin/activate
pip install torch==2.10.0 torchvision==0.25.0 \
transformers==4.57.1 Pillow==12.1.1 pymupdf einops
python infer.py \
--image_dir ./examples/images \
--output_dir ./outputs \
--concurrency 8 \
--image_mode gundam
PDF 文件会自动通过 PyMuPDF 转成图片再识别，输出是干净的文本，可以直接喂给 RAG 系统。
❀
不用 GPU 也能试
手边没有 GPU？没关系，三条路可以走：
- 一、Hugging Face Space 在线演示
浏览器里直接上传一张图片或 PDF 就能看到结果，零安装。唯一的缺点是免费 Space 会休眠，首次加载需要等几秒唤醒。 - 二、Google Colab 或 Kaggle
用免费 T4 GPU 运行上面的 Python 代码，非常适合在自己的文档上验证效果。 - 三、本地安装
有一块 NVIDIA GPU（8GB VRAM 以上就行），几分钟装好依赖，数据永远不离开你的机器。
❀
对 RAG 工作流的实际意义
如果你在用 RAG 做文档问答，Unlimited-OCR 解决了一个很实际的痛点：减少了预处理那堆胶水代码。
以前处理一份多页 PDF 的流程是：逐页 OCR → 缝合文本 → 处理跨页表格 → 重建阅读顺序 → 切片 → 索引。
Unlimited-OCR 的思路变成了：整份文档一次性解析 → 直接切片索引。
少了一个”缝合”环节，就少了一个出错的地方。当然，它也不是万能的。30 亿参数在同世代 OCR 里不算大——Mistral OCR 4 支持 170 种语言，GLM-OCR 也有自己的优势。但 Unlimited-OCR 的长文档一次性解析能力，确实是目前最独特的一张牌。
❀
总结
百度 Unlimited-OCR 没有做什么玄乎的技术创新。它只是问了一个朴素的问题——人是怎么阅读长文档的——然后照着这个思路设计了一个更高效的注意力机制。
MIT 许可证、30 亿参数、6GB 权重、消费级 GPU 就能跑。
实操建议很简单：去 Hugging Face Space 的在线演示，拿你手头最长的 PDF 试一试，看看识别质量能不能满足你的需求。如果能，本地装一个，几行代码就能集成进你的文档流水线。
链接汇总：
- GitHub 仓库：github.com/baidu/Unlimited-OCR
- Hugging Face 模型：huggingface.co/baidu/Unlimited-OCR
- 在线演示：Hugging Face Spaces
- 论文：arxiv.org/abs/2606.23050
- ModelScope：国内镜像下载
