baidu/Unlimited-OCR 模型介绍：长文档 OCR 的新选择

最近百度开源了一个新的 OCR 模型：baidu/Unlimited-OCR。

它不是传统意义上「识别一张图片里的文字」的轻量 OCR 工具，而是更偏向 长文档解析：把论文、报告、书籍、扫描 PDF 这类多页文档，尽量完整地转成可读、可编辑、可继续处理的文本或 Markdown。

如果你关心的是 PDF 转 Markdown、长文档 OCR、本地私有化文档解析，那么这个模型值得放进候选列表。

它解决的不是单页 OCR，而是长文档解析

传统 OCR 很多时候处理的是单张图片：截图、证件、发票、表单、票据。

但真实文档解析经常更麻烦：

• 一份 PDF 有几十页，甚至上百页。
• 页面里有多栏排版、表格、标题、脚注、引用。
• 内容里可能混有中文、英文、公式、代码、图注。
• 用户希望拿到的不是一堆孤立文本框，而是一份结构尽量完整的 Markdown。

这就是 baidu/Unlimited-OCR 更擅长的方向。它更像一个「文档转写模型」，目标不是只把字识别出来，而是尽量保留文档的阅读顺序和结构。

官方论文《Unlimited OCR Works》把它定位为 One-shot long-horizon parsing：一次性处理较长范围的文档解析任务，而不是只围绕单页图片做识别。

参考：

• Hugging Face: baidu/Unlimited-OCR
• GitHub: baidu/Unlimited-OCR
• 论文: Unlimited OCR Works

核心亮点：长输出时更稳

长文档 OCR 的一个关键问题是：输出越长，推理越慢，显存占用越高。

很多多模态模型在处理长文档时，前面几页看起来还不错，后面就开始变慢、丢结构、重复、漏内容，或者因为上下文和 KV cache 压力变大而变得不稳定。

baidu/Unlimited-OCR 的一个重要设计，是论文里提到的 Reference Sliding Window Attention。简单理解，它希望在长输出过程中控制 KV cache 的增长，让解码阶段的缓存压力保持得更稳定。

这让它的重点不只是「识别得准」，还包括「长文档能不能持续输出」。

对实际使用来说，这个方向很重要。因为 PDF 解析最怕的不是第一页识别失败，而是长文档跑到一半开始崩、漏、乱。

模型规模和显存要求

baidu/Unlimited-OCR 是一个 3B MoE 模型，论文和官方说明里提到推理时激活参数约为 0.5B。

这意味着它不像一些大体量多模态模型那样需要很高显存门槛。按照 vLLM 官方 recipe 的说法，单张 8GB 以上显存的 GPU 就可以做 BF16 推理。

参考：

• vLLM Recipe: baidu/Unlimited-OCR

更实际的显存建议可以这样看：

所以，如果你只是本地测试，8GB 显卡可以尝试；但如果目标是稳定跑长 PDF，我更建议从 16GB 显存开始。

原因很简单：模型本身能跑，不代表你的真实任务一定舒服。图片分辨率、页数、max_tokens、并发、vLLM 的 KV cache 预留，都会影响实际显存占用。

Benchmark 表现不错，但要看自己的文档

官方论文在 OmniDocBench 上给出了很强的结果。

在 OmniDocBench v1.5 上，论文表格里的 overall 分数是 93.23；在 v1.6 上是 93.92。同表里也对比了 DeepSeek-OCR、DeepSeek-OCR 2、Qianfan-OCR、Logics-Parsing-v2 等模型。

这说明它在公开文档解析 benchmark 上是很有竞争力的。

但 OCR 领域有一个老问题：benchmark 好，不等于你的文档好。

真实文档里常见的问题包括：

• 低清扫描。
• 页面歪斜。
• 水印遮挡。
• 表格线不清晰。
• 双栏、三栏混排。
• 图片压缩严重。
• 手写批注。
• 公式、脚注和页眉页脚混杂。

这些都会显著影响结果。因此它适不适合你，最终还是要拿自己的样本集横测。

适合哪些场景

我会优先把 baidu/Unlimited-OCR 放到这些场景里试：

1. PDF 转 Markdown

这是它最值得尝试的场景。

尤其是论文、报告、电子书、白皮书、说明书这类结构化长文档，如果你希望把它们转成 Markdown，再接 RAG、知识库、搜索索引或二次编辑，Unlimited-OCR 很适合进入候选。

2. 本地私有化文档解析

很多文档不方便上传云 OCR，例如合同、内部报告、财务资料、技术文档。

如果你有本地 GPU，并且愿意自己部署推理服务，它比云 OCR 更可控。

3. 长文档批处理

如果你的任务不是偶尔识别一张图，而是持续处理大量 PDF，那么它的长输出设计、vLLM 支持和相对较低显存门槛会比较有吸引力。

4. OCR + RAG 前处理

很多 RAG 项目的第一步不是向量检索，而是把 PDF 变成可用文本。

文档解析质量差，后面的切分、召回、问答都会被拖累。Unlimited-OCR 可以作为 RAG ingestion pipeline 的一个 OCR / parsing 组件来测试。

不太适合哪些场景

它也不是万能的。

如果你的需求是下面这些，未必需要上 baidu/Unlimited-OCR：

1. 简单截图 OCR

比如识别一张界面截图、一小段文字、几行英文报错。

这种任务用系统 OCR、PaddleOCR、Tesseract、云 OCR，甚至很多通用多模态模型都够了。上长文档模型可能反而麻烦。

2. 发票、证件、表单字段抽取

Unlimited-OCR 更偏「转写和解析」，不是专门的结构化票据模型。

如果你要的是发票号码、金额、税号、身份证号、合同字段等稳定抽取，通常还需要后接结构化抽取模型、规则校验或业务模板。

3. 对部署复杂度零容忍

它是一个需要工程化部署的模型。官方示例会涉及 Transformers、vLLM、SGLang、prompt 格式、推理参数等。

如果你想要的是一个点开网页上传 PDF 就能用的产品，它不是开箱即用的 SaaS。

4. 需要强 SLA 的生产 OCR

刚开源的新模型，生态、问题反馈和最佳实践还在积累。生产环境要谨慎灰度，不能只看论文分数就直接替换现有链路。

和 PaddleOCR、DeepSeek-OCR 怎么看

如果按定位粗略分：

• PaddleOCR：传统 OCR 工具链成熟，适合检测、识别、版面分析、结构化任务组合。
• DeepSeek-OCR：多模态 OCR 路线，适合 OCR 与语义理解结合的场景。
• baidu/Unlimited-OCR：更强调长文档解析和长输出稳定性，适合 PDF / 多页文档转 Markdown。

所以它不是简单替代谁，而是补上了一个很明确的位置：长文档 OCR / 文档解析。

如果你的主任务是「图片里有什么文字」，它未必是最轻的选择。

如果你的主任务是「把一份几十页 PDF 变成可读 Markdown」，它就很值得试。

使用时要注意的细节

实际部署时，有几个点要特别注意：

1. Prompt 格式要按官方来
   vLLM recipe 提到，prompt 必须以 <image> 开头，否则可能出现空输出。

2. 不要盲目拉高 max_tokens
   长文档需要足够输出长度，但 max_tokens 太大也会增加显存和延迟压力。

3. 先控制图片分辨率
   PDF 页转图片时，DPI 太低会影响识别，太高会增加计算量。需要在清晰度和成本之间调参。

4. 保留失败样本集
   OCR 系统要长期维护一批困难样本：低清、歪斜、水印、复杂表格、多栏排版。每次升级模型都用这些样本回归。

5. 结构化任务要后处理
   如果最终目标是字段抽取，不要只依赖 OCR 输出。最好接 JSON schema 抽取、规则校验和人工抽检。

我的结论

baidu/Unlimited-OCR 是一个很值得关注的开源 OCR 模型，但它最强的地方不是普通截图识别，而是 长文档解析。

它的优势很清晰：

• 长文档转写能力强。
• 公开 benchmark 表现不错。
• 3B MoE、推理激活约 0.5B，显存门槛相对友好。
• 8GB 显存可试，16GB 更适合稳定跑长 PDF。
• 支持 Transformers、vLLM、SGLang 等推理方式。
• MIT License，方便开源和商业项目评估。

它的限制也很清晰：

• 模型较新，生态还在积累。
• 部署和参数调试需要工程经验。
• 不一定适合简单 OCR 或强结构化票据抽取。
• 真实效果必须用自己的文档集验证。

如果你的目标是「把 PDF、论文、报告、书籍转成 Markdown，再进入知识库或 RAG」，baidu/Unlimited-OCR 值得优先测试。

如果你的目标只是识别几张截图或做发票字段抽取，它未必是最省事的选择。

选型建议很简单：长文档解析可以试它，普通 OCR 不必盲目上它，生产替换前一定要用自己的样本集横测。