百度开源 Unlimited-OCR：长文档一次解析是看点，“无限”仍要打引号

百度在 2026 年 6 月 22 日发布开源项目 Unlimited-OCR，次日论文上线 arXiv，并同步登陆 ModelScope。项目也提供 Hugging Face 模型入口，README 给出了 Transformers 本地推理和 SGLang 服务化推理示例。

这件事的核心增量，不在于名字里的“Unlimited”。从公开材料看，它更像是把 DeepSeek-OCR 路线往前推一步：强调 one-shot long-horizon parsing，也就是在较长上下文里一次性处理单图、多页图片，或由 PDF 转成的页面图片。对做文档智能的团队来说，真正要评估的是长文档解析流程能否少切片、少拼接、少出错。

百度发布的是模型入口、论文和推理路径

Unlimited-OCR 目前呈现为开源研究项目，而不是商业产品发布。代码仓库链接到 Hugging Face 模型、arXiv 论文和 ModelScope 页面，并给出两类使用方式：直接用 Hugging Face Transformers 在 NVIDIA GPU 上推理，或用 SGLang 拉起 OpenAI 兼容接口做流式请求。

项目致谢了 DeepSeek-OCR、DeepSeek-OCR-2 和 PaddleOCR。这一点很关键：Unlimited-OCR 不是从零冒出的孤立方案，而是在近两年视觉语言模型处理文档的路线中继续加码。

技术卖点在“少分段”，限制也藏在示例里

传统 OCR 和文档解析常见流程是先切页、切块，再识别、还原版面、拼接结构。问题出在长 PDF 和复杂文档上：跨页表格、目录层级、脚注、图文关系，一旦被切碎，后处理会变重。

Unlimited-OCR 的卖点，是尝试让模型在更长视野中一次完成解析。这对需要处理年报、说明书、合同附件、论文扫描件的团队有吸引力，因为工程链条可能更短。

但公开 README 也给出边界：单图支持 gundam 和 base 两种配置；多页图片和 PDF 只使用 base。PDF 并不是原生直接读入，而是先用 PyMuPDF 按页转图片，再进入多页解析。示例上下文长度为 32768，也不能被理解成任意页数、任意长度、任意成本。

横向看，PaddleOCR 代表的是成熟 OCR 工具链，强在工程稳定和生态积累；DeepSeek-OCR 一类方案更强调视觉语言模型的端到端解析能力。Unlimited-OCR 的位置介于研究展示和开发者试用之间，它试图减少长文档处理中“切了再拼”的麻烦，但尚未证明自己在真实业务里更便宜、更快或更准。

适合技术团队试跑，不适合直接写进采购结论

最受影响的是 OCR/文档智能开发者，以及正在被多页 PDF 拖慢流程的企业技术团队。比如法务、金融、政企档案、科研文献处理场景里，团队通常要在版面恢复、表格抽取和跨页结构上投入大量规则工程。如果一次长上下文解析能稳定工作，后处理成本会下降。

现在还看不清的是三件事：不同语种和复杂版面的准确率，长 PDF 下的显存与延迟，以及并发服务时的单位成本。README 里出现了 concurrency、SGLang server 等示例参数，但这不能等同于大规模商用落地。

更现实的做法，是把 Unlimited-OCR 放进测试队列：选取团队手里最麻烦的 20 到 50 份长文档，与现有 OCR 流程、PaddleOCR 方案或自研解析链路做人工复核对比。若跨页结构明显更稳，再讨论替换；若只是单页识别相近，它的价值就会被推理成本抵消。