百页 PDF 一次读完？百度开源 Unlimited-OCR
百度开源 3B MoE 文档解析模型 Unlimited-OCR，主打多页长文档和有界解码缓存。这里给出本地单图、多页 PDF 的上手路线，也核对百页解析、93.92 分和硬件成本的真实边界。
一份几十页的合同、论文或扫描报告，传统 OCR 常常按页处理。每页单独识别后，还要重新拼接标题层级、表格、公式和上下文。
百度最近开源了 Unlimited-OCR，想把多页文档放进同一次长程解析。它是一个总参数约 30 亿的 MoE 模型，每个 token 激活约 5 亿参数，输出可以直接保存为 Markdown 。
项目发布一个月左右，GitHub Star 已超过 1.7 万。传播最广的说法是“一次吃下上百页 PDF，KV Cache 恒定”。方向确实有意思，但公开证据没有这么夸张：论文展示的长文档评测到 40+ 页，模型仍受 32K 上下文限制。
项目地址：github.com/baidu/Unlimited-OCR
它怎么处理长文档
Unlimited-OCR 由 DeepEncoder 和 MoE 解码器组成。 1024×1024 的页面会被压缩成 256 个视觉 token，多页图像经过编码后形成固定的视觉前缀。
解码器使用 R-SWA，也就是 Reference Sliding Window Attention 。每个新输出 token 都能看到完整的文档视觉前缀，同时只保留最近一段生成文本。默认窗口是 128 个 token 。
这能控制长输出阶段的缓存增长。输入文档固定后，解码侧 KV Cache 填满窗口便不再继续膨胀。总缓存仍会随着输入页数增加，因为所有视觉前缀都要留着。“KV Cache 永远恒定”少了这个前提。
模型有两种图像模式：
Gundam：动态裁切，适合单张高分辨率文档；Base：每页 1024×1024，适合真正的多页联合解析。
先看清三个热门数字
93.92 分来自官方论文
Unlimited-OCR 在 OmniDocBench v1.6 的 Overall 指标中报告 93.92 。 v1.5 的 93.23 相比 DeepSeek-OCR 的 87.01 高 6.22 个点。
这些成绩来自项目论文，仓库没有附完整评测脚本、预测文件或运行日志，目前不能视为独立复现结果。文章里的模型对比也应标成官方自测。
40+ 页错误率是内部测试
论文在 40+ 页组报告编辑距离 0.1069，符合“低于 0.11”的传播说法。不过测试集由团队内部构建，没有公开文档清单和逐样本结果。
多页统一缩放到 1024×1024 后，小字容易丢失。页数越多，合同脚注、论文引用和双栏小字号越值得单独检查。
上百页仍是能力主张
论文写到可以一次预填几十到上百页，但公开长文档表格只报告到 40+ 页。当前上下文长度也是 32768，输入页数继续增加后，视觉 token 终究会塞满上下文。
所以标题里的“百页一次读完”先打问号。它已经证明了多页长程解析的可行性，100 页稳定产出还需要公开样本、显存数据和第三方复现。
最稳的第一次运行
这个项目目前是研究预览，没有带安装向导的桌面 OCR 软件。官方 Transformers 路线测试于 Python 3.12.3 、 CUDA 12.9 和 NVIDIA GPU，没有公布最低显存。
先从单张清晰文档图片开始，别一上来就塞整本 PDF 。
1. 建立隔离环境
git clone https://github.com/baidu/Unlimited-OCR.git
cd Unlimited-OCR
python3.12 -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 \
matplotlib==3.10.8 einops==0.8.2 \
addict==2.4.0 easydict==1.13 \
pymupdf==1.27.2.2 psutil==7.2.2
依赖组合比较新，已有生产环境不要直接原地升级。单独建虚拟环境或容器更稳。
2. 用一张图片验证模型
创建 run_one.py：
import torch
from transformers import AutoModel, AutoTokenizer
model_id = "baidu/Unlimited-OCR"
tokenizer = AutoTokenizer.from_pretrained(
model_id, trust_remote_code=True
)
model = AutoModel.from_pretrained(
model_id,
trust_remote_code=True,
use_safetensors=True,
torch_dtype=torch.bfloat16,
).eval().cuda()
model.infer(
tokenizer,
prompt="<image>document parsing.",
image_file="test.jpg",
output_path="./outputs",
base_size=1024,
image_size=640,
crop_mode=True,
max_length=32768,
no_repeat_ngram_size=35,
ngram_window=128,
save_results=True,
)
运行：
mkdir -p outputs
python run_one.py
先检查标题、段落、表格、公式和阅读顺序，再测试小字、倾斜扫描件、中英混排和带水印的页面。 README 没有公布正式语言清单，“多语言”标签不能代替自己的样本测试。
3. 再试两三页联合解析
多页要调用 infer_multi()，并切到 Base 模式：
model.infer_multi(
tokenizer,
prompt="<image>Multi page parsing.",
image_files=["page1.png", "page2.png", "page3.png"],
output_path="./outputs",
image_size=1024,
max_length=32768,
no_repeat_ngram_size=35,
ngram_window=1024,
save_results=True,
)
PDF 需要先用 PyMuPDF 转成页面图片，再把图片列表交给 infer_multi()。推荐按 2 页、 5 页、 10 页逐步增加，同时记录峰值显存、总耗时、输出是否截断和跨页标题是否连续。
仓库里的 infer.py --pdf 容易让人误会。源码明确把 PDF 每页转成图片，再逐页并发请求，最后写出 page_0001.md 这类文件。它适合批量跑页，却不能用来证明“整本一次解析”。要测试 One-shot 多页能力，使用 infer_multi()。
vLLM 和 SGLang 留到第二阶段
项目已经支持 vLLM，并提供专用 Docker 镜像：
docker pull vllm/vllm-openai:unlimited-ocr
SGLang 路线能启动 OpenAI 兼容接口，也能批量并发处理目录或 PDF 。仓库附带的是开发版 wheel，依赖多、 GPU 要求高，初次部署先把并发从默认 8 降到 1。
README 的服务命令监听：
0.0.0.0:10000
这会暴露到所有网卡，示例也没有认证和 TLS 。只在本机使用时，把 host 改为 127.0.0.1；需要内网服务时，再加反向代理、鉴权、防火墙和上传大小限制。合同、证件和内部报告尤其不要裸奔在公网端口上。
适合谁
需要把合同、论文、财报和扫描报告转成结构化 Markdown 的团队，最值得关注。多页上下文能帮助恢复跨页标题和连续段落，公式、表格也在官方评测范围内。
做 RAG 、知识库和文档数据清洗的开发者，也可以把它放在解析入口，先输出 Markdown，再做分块和索引。上线前仍要抽样核对页码、脚注、金额、日期和表格单元格。
只有 CPU 、 Mac 或普通办公电脑的用户暂时不适合本地折腾。官方路径面向 NVIDIA CUDA，没有最低显存数据，也没有一键桌面包。想先看效果，可以用 Hugging Face Space 或百度云，但敏感文件会离开本机，费用和隐私规则也要另外确认。
本地开源不等于零成本
GitHub 代码和 Hugging Face 模型卡目前都标为 MIT，可以本地部署，省掉按页调用 OCR API 的费用。模型下载、 NVIDIA GPU 、显存、电力、存储和维护依然要算账。
Transformers 示例还使用了 trust_remote_code=True，模型仓库里的 Python 代码会在本机执行。生产环境应锁定模型 revision 、审查远程代码，并放进隔离容器。 SGLang 开发版 wheel 也缺少签名和 SBOM，别直接装进承载敏感凭据的宿主机。
Unlimited-OCR 最值得观察的是长输出效率和多页连续解析。目前适合做技术验证，也适合拿自己的合同、论文和扫描件认真测一轮。等到最低显存、语言覆盖、 100 页公开样本和第三方 benchmark 都补齐，再谈替换生产 OCR 会更稳。
你最想拿它测试哪类长文档：合同、论文、财报，还是扫描书籍？