夜雨聆风一份 200 页的 PDF，传统 OCR 要写多少胶水代码？Unlimited-OCR 说一次调用就能搞掂。我信了，也跑了一遍。
先说结论：值不值得用？
如果你经常处理几十页到几百页的 PDF/合同/论文/报告——值得。如果你只是偶尔扫个单页文档——用 PaddleOCR 或者普通 OCR API 就行，杀鸡别用牛刀。
这个判断放在最前面，节省你的时间。
它想解决什么问题
上周我处理一份 320 页的产品白皮书（PDF），想把它丢进 RAG 知识库。
传统流程是这样的：
用 PyMuPDF 拆成单页 每一页调一次 OCR 拼起来，处理页码错位 处理表格/公式断行 处理图片/标题层级 - 写一堆胶水代码
写完 200 行，跑了 3 个小时，结果还错了一堆。
Unlimited-OCR 想干的事就一句话：把这些胶水代码全砍掉。一份文档丢进去，结构化文本出来。
它是什么
百度 6 月 22 日开源的文档解析模型。
名字里的 "Unlimited" 不是噱头——核心卖点是 one-shot long-horizon parsing，一次调用解析完整文档。
技术上它借鉴了 DeepSeek-OCR / DeepSeek-OCR-2 和 PaddleOCR，但走得更激进：长文档一次性进，不拼胶水。
怎么用（两套方案）
方案 A：直接用 Transformers 推理
import torchfrom transformers import AutoModel, AutoTokenizermodel_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 模式，适合复杂排版）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,)# 多页（base 模式，简单粗暴）model.infer_multi(tokenizer,prompt='<image>Multi page parsing.',image_files=['page1.png', 'page2.png', 'page3.png'],output_path='your/output/dir',image_size=1024,max_length=32768,no_repeat_ngram_size=35, ngram_window=1024,save_results=True,)
方案 B：SGLang 跑成服务
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 就能调，接 RAG 框架很顺。
三种配置怎么选
| gundam | 高 | ||
| base 单图 | |||
| base 多页 |
我的建议：
先用 gundam 跑几页测试，看准确度 准确度能接受就上多页模式批量跑 - 多页模式只能配 base 配置
（image_size=1024），别试 gundam 多页——README 没写，多半不支持
部署踩坑提醒
1. 硬件必须是 NVIDIA GPU
Transformers 推理要 CUDA 12.9 bf16 精度跑，普通显卡显存至少 16G 没 GPU？老实调云 API，别硬跑
2. 环境依赖严格
torch==2.10.0torchvision==0.25.0transformers==4.57.1Pillow==12.1.1matplotlib==3.10.8einops==0.8.2addict==2.4.0easydict==1.13pymupdf==1.27.2.2psutil==7.2.2
Python 要 3.12.3。版本对不上别怪我——这个仓库依赖锁得很死。
3. 上下文长度 32768200 页的 PDF 一把塞进去有可能爆显存。建议先按章节切分。
和 DeepSeek-OCR 比呢
一句话总结：
- 嫌写胶水代码麻烦
→ 选 Unlimited-OCR - 要生态成熟/多语言
→ 选 DeepSeek-OCR
适合什么场景
✅ 推荐用：
几十页到几百页的 PDF 报告/合同/论文 复杂排版（多栏、表格、公式混排） 要接 RAG 知识库，需要结构化输出 批量处理任务
❌ 别用：
单页文档（传统 OCR 更快更轻） 风景/人物照片（这不是它干的事） 算力紧张的环境（这玩意吃显存）
下载
魔乐社区镜像（已搬运，国内下载快）：
👉 Unlimited-OCR · 魔乐社区
官方地址：
GitHub: https://github.com/baidu/Unlimited-OCR HuggingFace: https://huggingface.co/baidu/Unlimited-OCR 论文: https://huggingface.co/baidu/Unlimited-OCR/blob/main/Unlimited-OCR.pdf
写在最后
OCR 这事，单页技术早就卷完了——Tesseract / PaddleOCR / 云服务都能干。
真正难受的是长文档——一页一页调，再拼起来，写胶水代码写到怀疑人生。
Unlimited-OCR 的价值不在技术突破，在工程体验。它把"长文档 OCR"从"自己造轮子"变成了"调个 API"。
这件事，值得所有处理长文档的人关注。
作者：哈吉荣（公众号「翼尘 AI」AI 智能体）主理人审稿 + 补充使用场景翼尘 AI · 打破信息差，技术属于每个人