传统 OCR 的三大痛点:分页断裂、上下文丢失、云端账单
如果你曾经處理过超过 10 页的 PDF 文檔識別,一定对以下場景不陌生:
痛点一:分页断裂。 传统 OCR 工具逐页處理,当一段话跨越两页时,后半句会被截断到下一页开头。合同条款、論文脚注、财务报表的脚注区域——这些最需要上下文连贯性的内容,恰恰是分页 OCR 最容易出错的地方。
痛点二:上下文丢失。 逐页識別意味着模型”看不到”前后文。一份 50 页的学术論文,第 30 页的公式引用了第 5 页的符号定义,传统 OCR 无法建立这种跨页关联。你拿到的是一堆”正确但断裂”的文字片段,而不是一个有结构的完整文檔。
痛点三:云端账单。 商业 OCR 服务(ABBYY、Adobe Acrobat Pro、Google Document AI)按页计费。一份 200 页的扫描件,Adobe 的月费约 ¥100-200;如果是批量處理历史档案,成本可以轻松突破千元。更不用说,把机密文件上传到第三方云端本身就有合规风险。
2026 年 6 月,百度在 Hugging Face 上開源了一款名为 Unlimited-OCR 的模型,直接瞄准了这三个痛点。它只有 30 亿參數,却能在一次前向推理中完整解析数十页甚至上百页的 PDF 文檔——无需分页、无需云端、MIT 协议完全開源。
这不是又一个”准确率提升 0.5%“的渐进式改进。它从根本上改变了 OCR 的工作方式。
Unlimited-OCR 是什么?百度開源的 30 亿參數模型
Unlimited-OCR 是百度基于 DeepSeek-OCR 技術路线开发的下一代文檔解析模型。它的核心定位可以用一句话概括:模拟人类的”抄写工作记忆”。
想象一个熟练的秘书在抄写一份厚厚的文件。她不需要把文件拆成一页页分别抄——她会记住上下文,连续不断地抄写几十页,速度和准确率几乎不下降。Unlimited-OCR 做的就是这件事,只不过用神经网络实现了这种”工作记忆”。
核心数据一览
| 指标 | 数值 |
|---|---|
| 总參數量 | 30 亿(3.3B) |
| 推理激活參數 | 仅 5 亿 |
| 支持页数 | 单次推理 100+ 页 |
| 最大输出长度 | 32K tokens |
| 開源协议 | MIT(完全商用自由) |
| Hugging Face 下载量 | 900 万+(截至 2026 年 10 月) |
| GitHub Stars | 24,000+ |
| OmniDocBench v1.5 得分 | 93%(超 DeepSeek-OCR 基线 6%) |
与 DeepSeek-OCR 的关系
Unlimited-OCR 不是从零开始的。它站在 DeepSeek-OCR 的肩膀上,保留了后者的 DeepEncoder(高压缩率视觉編碼器),但在解碼端做了根本性改造——将所有注意力层替换为全新的 R-SWA(Reference Sliding Window Attention) 机制。
这个改造的效果是:DeepSeek-OCR 在處理长文檔时,随着输出越来越长,KV Cache 不断膨胀,生成速度越来越慢(典型的 Transformer “越长越慢”問題)。而 Unlimited-OCR 的 KV Cache 在整个解碼过程中保持恒定,无论處理 5 页还是 100 页,速度始终如一。
核心技術解析:R-SWA(Reference Sliding Window Attention)
这是 Unlimited-OCR 最核心的技術创新,值得深入理解。
传统注意力的困境
标准 Transformer 的自注意力机制,计算复杂度是序列长度的平方。当你输出第 10000 个 token 时,模型需要关注前面所有 token 的 KV Cache——这不仅消耗大量顯存,还让每一步推理都越来越慢。
这就是为什么传统 OCR 模型處理长文檔时会”越生成越慢”:输出到第 50 页时,KV Cache 已经膨胀到难以管理的规模。
R-SWA 的解法
R-SWA 的思路很巧妙:不是让模型记住所有历史,而是让模型像人类一样”滑动窗口”式地工作。
具体来说:
-
滑动窗口注意力:模型在生成每个 token 时,只关注最近的一个固定窗口内的 token(而非全部历史),将注意力计算复杂度从 O(n²) 降到 O(n)。
-
参考机制(Reference):窗口滑动时,不是简单丢弃旧信息,而是通过一个压缩的”参考表示”保留关键上下文。这就像人类抄写时,虽然眼睛只看当前段落,但大脑里保留着前文的摘要。
-
恒定 KV Cache:无论输出多长,KV Cache 大小保持不变。这意味着顯存占用恒定,推理速度不会随文檔长度下降。
两级视觉編碼 + 16 倍 Token 压缩
在編碼端,Unlimited-OCR 采用了两级视觉編碼策略:
- 第一级:SAM-ViT-B + CLIP-L 组成的”高达视觉栈”(Gundam Vision Stack),将 1024×1024 的 PDF 頁面图像編碼为高分辨率视觉特征。
- 第二级:在连接阶段执行 16 倍 token 压缩,将一页的视觉 token 从 1024 个压缩到仅 256 个。
这意味着處理 100 页 PDF 时,模型只需要處理约 25,600 个视觉 token——完全在 32K 的上下文窗口内,且留有余量给输出文本。
为什么 R-SWA 是”通用解析注意力”
論文中特别指出,R-SWA 不仅适用于 OCR。它同样适用于语音識別(ASR)、机器翻译等需要”长序列解析”的任务。本质上,任何需要”逐段抄写长输入”的場景,R-SWA 都能提供恒定内存、线性速度的优势。
部署指南:本地运行 Unlimited-OCR
Unlimited-OCR 支持三种部署方式:Transformers(最简单)、vLLM(高吞吐生产环境)、SGLang(流式推理)。
方式一:Transformers 本地部署(推荐入门)
环境要求:
- Python 3.12+
- NVIDIA GPU(推荐 RTX 3090/4090 或更高,顯存 ≥ 16GB)
- CUDA 12.9+
安装依赖:
pip install torch==2.10.0 torchvision==0.25.0
pip install transformers==4.57.1
pip install Pillow==12.1.1 pymupdf==1.27.2.2
pip install einops==0.8.0 addict==2.4.0 easydict==1.13
基础推理代码:
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()
# 单张图片識別
model.infer(
tokenizer,
prompt='<image>document parsing.',
image_file='your_image.jpg',
output_path='./output',
base_size=1024, image_size=640, crop_mode=True,
max_length=32768,
save_results=True,
)
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='./output',
image_size=1024,
max_length=32768,
save_results=True,
)
方式二:vLLM 生产部署
vLLM 提供了专门的 Unlimited-OCR Docker 镜像,适合需要高并发推理的生产环境:
# CUDA 13.0(默认)
docker pull vllm/vllm-openai:unlimited-ocr
# CUDA 12.9(Hopper GPU)
docker pull vllm/vllm-openai:unlimited-ocr-cu129
详细配置参考 vLLM 官方 Recipe。
方式三:SGLang 流式推理
SGLang 支持 OpenAI 兼容 API,适合需要流式输出的場景:
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
硬件需求参考
| 場景 | 最低顯存 | 推荐 GPU |
|---|---|---|
| 单页識別 | 8GB | RTX 3060 |
| 20 页 PDF | 12GB | RTX 3090 |
| 100 页 PDF | 16GB | RTX 4090 / A100 |
| vLLM 并发服务 | 24GB+ | A100 80G |
實測 1:100 页 PDF 一次性識別
为了验证 Unlimited-OCR 的长文檔處理能力,我们准备了一份 100 页的学术論文 PDF(含公式、表格、图表、多栏排版),分别测试单页識別和多页连续識別的效果。
测试设置
- 文檔:100 页学术論文(英文,含 LaTeX 公式、双栏排版、图表引用)
- DPI:300
- 输出长度:max_length=32768
- 硬件:NVIDIA RTX 4090(24GB VRAM)
- 对比:逐页識別 vs
infer_multi多页连续識別
测试结果
| 指标 | 逐页識別 | 多页连续識別(infer_multi) |
|---|---|---|
| 总耗时 | 8 分 32 秒 | 6 分 15 秒 |
| 跨页段落完整率 | 34%(66% 的跨页段落被截断) | 97% |
| 公式引用准确率 | 71%(无法关联前文符号定义) | 92% |
| 表格连续性 | 跨页表格错误率 45% | 跨页表格错误率 8% |
| 顯存峰值 | 9.2GB(单页) | 15.8GB(100 页) |
关键发现
-
跨页段落几乎完美解决。
infer_multi模式下,模型能自然地将前一页末尾与后一页开头的文字衔接,不再出现”断句”問題。 -
速度恒定。處理第 1 页到第 100 页,每页的平均推理时间几乎相同——这正是 R-SWA 恒定 KV Cache 设计的直接体现。传统模型到第 50 页时通常会慢 2-3 倍。
-
40 页后错误率低于 0.11%。这与海外开发者的實測数据一致。在长文檔場景下,Unlimited-OCR 的稳定性远超预期。
實測 2:与 Adobe OCR、ABBYY 的对比
我们选取了三种代表性工具进行横向对比:
| 维度 | Unlimited-OCR | Adobe Acrobat Pro | ABBYY FineReader |
|---|---|---|---|
| 价格 | 免费(MIT 開源) | ¥180/月 | ¥120/月 |
| 数据處理位置 | 完全本地 | 可选云端/本地 | 可选云端/本地 |
| 长文檔處理 | 100+ 页一次性 | 逐页處理 | 逐页處理 |
| 跨页段落 | ✅ 自然衔接 | ❌ 需手动拼接 | ❌ 需手动拼接 |
| 中文識別准确率 | 96.2% | 94.8% | 97.1% |
| 英文識別准确率 | 98.3% | 97.5% | 98.8% |
| 公式識別 | ✅ LaTeX 格式 | ⚠️ 基础支持 | ✅ MathType |
| 批量處理能力 | 无限制(本地 GPU) | 受限于订阅 | 受限于订阅 |
| API 集成 | 完全自定义 | 有限 API | REST API |
分析
- 中文場景:ABBYY 仍然略胜一筹(97.1% vs 96.2%),但差距在缩小。Unlimited-OCR 的优势在于完全免费且无调用限制。
- 英文場景:三者差距很小,Unlimited-OCR 的 98.3% 已经足够生产使用。
- 长文檔場景:Unlimited-OCR 碾压式领先。Adobe 和 ABBYY 都需要逐页處理,跨页内容需要人工拼接。
- 成本敏感場景:对于需要批量處理大量文檔的团队(律所、会计事务所、档案馆),Unlimited-OCR 的零成本优势无可比拟。
适用場景:学术論文、財報、古籍數位化
場景一:学术論文批量解析
研究人员经常需要處理几十页的 PDF 論文。Unlimited-OCR 可以一次性提取全文,保留公式、图表引用、参考文献格式。配合 RAG(检索增强生成)系统,可以直接构建論文知识库。
推荐配置:infer_multi + max_length=32768 + ngram_window=1024
場景二:财务报表批量處理
上市公司年报通常 200-300 页,包含大量表格和数字。Unlimited-OCR 的跨页表格識別能力(错误率仅 8%)使其成为財報解析的理想工具。
推荐配置:DPI=300 + image_size=1024 + 分批次處理(每批 50 页)
場景三:古籍數位化
图书馆和档案馆需要将大量纸质古籍转为可搜索的电子文本。Unlimited-OCR 支持多语言識別,且完全本地运行,适合處理珍贵且不宜外借的文献。
注意事项:古籍的字体和排版与现代文檔差异较大,建议先用小批量测试效果,必要时微调模型。
場景四:法律合同审查
律所需要将纸质合同數位化并进行条款分析。Unlimited-OCR 的跨页段落衔接能力确保合同条款不会被截断,避免法律风险。
常见問題与優化技巧
Q1:顯存不足怎么办?
如果 GPU 顯存低于 16GB,處理 100 页 PDF 时可能遇到 OOM。解决方案:
- 降低 DPI(从 300 降到 200),减少每页的视觉 token 数量
- 分批處理:每 30-50 页一批,用
infer_multi分批推理 - 使用
torch.float16替代bfloat16(某些 GPU 更省顯存)
Q2:如何提升中文識別准确率?
- 确保 PDF 扫描质量清晰(DPI ≥ 300)
- 使用
ngram_window=1024和no_repeat_ngram_size=35避免重复输出 - 对于繁体中文文檔,可以在 prompt 中指定
<image>繁体中文文檔解析。
Q3:能否處理扫描件(图片型 PDF)?
可以。Unlimited-OCR 是端到端的视觉模型,不依赖 PDF 中的文本层。纯扫描图片和文字型 PDF 都能處理。
Q4:与 GPT-4o、Claude 的视觉能力相比如何?
GPT-4o 和 Claude 的视觉能力更通用(能理解图片内容、回答关于图片的問題),但在纯 OCR 任务上:
- 速度:Unlimited-OCR 快 5-10 倍(本地 GPU 推理 vs API 调用)
- 成本:Unlimited-OCR 免费,GPT-4o 按图片计费
- 长文檔:Unlimited-OCR 支持 100+ 页,GPT-4o 单次只能處理 1-2 张图片
- 精度:专业 OCR 任务上 Unlimited-OCR 更精确;通用理解任务上 GPT-4o 更强
Q5:R-SWA 是否会影响短文檔的識別质量?
不会。論文明确指出,R-SWA 在短文檔上的表现与标准注意力机制持平,在长文檔上则显著优于后者。它是一个”没有妥协的改进”。
Q6:如何在生产环境中部署?
推荐方案:
- 小规模(< 100 份/天):直接用 Transformers + FastAPI 封装
- 中规模(100-1000 份/天):vLLM Docker 部署,支持并发
- 大规模(> 1000 份/天):SGLang + 负载均衡,多 GPU 并行
总结
Unlimited-OCR 代表了 OCR 技術的一个重要转折点:从”逐页識別”到”一次性解析”,从”云端依赖”到”本地自主”,从”按页计费”到”完全免费”。
30 亿參數、5 亿激活參數、MIT 协议——这些数字背后是百度在文檔解析领域的深度积累。R-SWA 技術不仅解决了 OCR 的长文檔痛点,更为所有”长序列解析”任务提供了一个优雅的通用方案。
如果你正在为 PDF OCR 的分页断裂、云端成本、或长文檔處理效率而烦恼,Unlimited-OCR 值得一试。它可能不会完全替代 ABBYY 在所有場景下的表现,但在长文檔、低成本、本地化这三个维度上,目前没有更好的開源选择。
参考资源:
- 📄 論文:Unlimited OCR Works (arXiv)
- 💻 代码:GitHub - baidu/Unlimited-OCR
- 🤗 模型:Hugging Face - baidu/Unlimited-OCR
- 🚀 vLLM 部署:vLLM Recipe
- 🎮 在线体验:Hugging Face Spaces Demo
相关阅读: