# OCR 的新战场是耐力

**Summary:** 百度开源 Unlimited-OCR 的重点，不只是 OCR 又热了，而是它把长文档解析当成真正的考题。

- Canonical: https://markhuang.ai/zh/news/unlimited-ocr-endurance
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-06-23
- Section: News
- Tags: AI, OCR, 开源, 文档智能
- Source: [Baidu GitHub](https://github.com/baidu/Unlimited-OCR)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一台友好的 OCR 机器读取很长的文档流，旁边的编辑正在查看整理后的输出卡片](https://cdn.markhuang.ai/news/unlimited-ocr-endurance/hero.webp)

*这件事有意思的地方，不只是又多了一个 OCR 模型，而是问题重心正在从「读懂一页」移到「跨很多页仍然保持清醒」。*

百度在 GitHub 上发布了 [Unlimited-OCR](https://github.com/baidu/Unlimited-OCR)。项目 README 把它称为 "Unlimited OCR Works"，并用 "one-shot long-horizon parsing" 来描述方向。README 还写明：论文在 2026 年 6 月 23 日上线 arXiv，同一天模型也上了 ModelScope；项目在 6 月 22 日被介绍为继续推进 DeepSeek-OCR 的一步。

我的判断是，这个仓库真正值得看，不是因为 OCR 这个词本身又被拿出来讨论，而是因为它把问题放在了长文档上。真实的文档工作流很少是干净的单页演示。它们更像是一堆 PDF、页面图片、表格、重复页眉、超长输出、服务端约束，以及足够多会让脆弱解析器露馅的边角情况。

## 答案快照

| 问题       | 我的判断                                                                               |
| -------- | ---------------------------------------------------------------------------------- |
| 发生了什么？   | 百度为 Unlimited-OCR 开了 GitHub 仓库，并在 README 中链接了 Hugging Face、ModelScope 和 arXiv 论文。  |
| 为什么重要？   | 这个项目明确把目标放在长文档解析上，而不是只做单页 OCR。                                                     |
| 技术看点是什么？ | arXiv 摘要称，Unlimited OCR 使用 Reference Sliding Window Attention，让解码时的 KV cache 保持恒定。 |
| 现实门槛是什么？ | README 仍然是开发者向的设置：NVIDIA GPU、Python/CUDA 环境、Transformers 或 SGLang 推理，以及 PDF 转图片流程。 |

## 真正有意思的是耐力

最值得注意的不是项目名字，而是它强调的长程解析。OCR 当然要能从页面里读出文本，但更难、也更有价值的问题，是当输出越来越长、文档结构不断累积时，模型还能不能稳定地读下去。

项目链接的 [arXiv 摘要](https://arxiv.org/abs/2606.23050)把压力说得很直接：LLM 式解码器可以利用语言先验，但输出序列变长后，KV cache 的内存消耗会上升，生成速度也会变慢。论文提出的方案是 Reference Sliding Window Attention，也就是 R-SWA，用它替换解码器中的注意力层，让解码过程中的 KV cache 保持恒定。摘要还称，在 32K 最大长度下，这套设计可以单次前向转写几十页文档。

我不会把摘要里的说法当成生产环境保证。但作为方向，它瞄准的是正确问题。文档 AI 的瓶颈经常不在于能不能读一张裁好的收据，而在于面对很长、很重复、结构又很烦人的文档时，系统能不能坚持到最后。

![一个小型 AI 读取器处理很长的页面流，旁边的紧凑记忆盒保持整洁](https://cdn.markhuang.ai/news/unlimited-ocr-endurance/why-it-matters.webp)

*长文档 OCR 不只是识别问题，也是记忆和连贯性问题。*

## README 暴露了真实受众

这个项目不是给普通用户随手上传文件、马上拿结果的网页工具。README 的 Transformers 路线写的是在 NVIDIA GPU 上用 Hugging Face transformers 推理，并列出经过测试的环境：Python 3.12.3 加 CUDA 12.9。示例用 `AutoTokenizer` 和 `AutoModel` 加载 `baidu/Unlimited-OCR`，使用 safetensors、bfloat16，然后跑 CUDA 推理。

示例也把模型的工作方式摊开了。单张图片可以走较小的裁剪模式或 base 模式；多页和 PDF 解析使用 base 图像模式，参数里包括 `image_size=1024`、`max_length=32768`，以及禁止重复 n-gram 设置。处理 PDF 时，README 先用 PyMuPDF 把页面转成图片，再把这些图片送入多页解析。

> **Info:**
>
> 现实信息很清楚：开放权重和 MIT 许可很有意义，但它们不会自动消除集成工作。真正采用时，仍然要处理远程代码加载、GPU 服务、页面转换、输出校验和失败恢复。

## SGLang 让它更像基础设施

SGLang 这一段让我觉得，它不是单纯的 notebook 演示。README 展示了本地 SGLang wheel、以 `Unlimited-OCR` 名称启动的服务、32K 上下文长度、自定义 logit processor，以及通过 OpenAI-compatible API 发起的流式请求。仓库里的 `infer.py` 路径还支持图片目录和 PDF 输入，并带有输出目录与并发控制。

这很重要，因为 OCR 系统很少单独存在。它们通常挂在队列、API、文档库和人工复核流程后面。如果长文档解析要真的有用，服务化就必须是故事的一部分。我仍然会把当前仓库看成起点，而不是完整平台；但这个起点至少承认了真实部署会长什么样。

![工程师把发光的 OCR 引擎从研究台搬向更实用的部署工作台](https://cdn.markhuang.ai/news/unlimited-ocr-endurance/tradeoff.webp)

*令人兴奋的是能力本身，真正费力的是让这种能力离开 README 后仍然可靠。*

## 开源信号也值得注意

这个仓库是公开的，README 链接了 Hugging Face，也指向 ModelScope，并且采用 MIT 许可。这个组合有分量，因为 OCR 听起来无聊，但一旦企业把发票、合同、表格、扫描档案和内部报告交给它，它就会变成很关键的基础能力。

也正因为如此，我不想把它说过头。现有来源提供的是设置路径和研究框架，不是对所有脏文档类型的通用保证。接下来更值得观察的是现实问题：混合语言文档、密集表格、糟糕扫描件、页序错误、高并发下的延迟、跨 GPU 的内存表现，以及人工到底还要改多少输出。

![文档经过页面图片和服务器流水线后，审核人员正在检查 OCR 输出卡片](https://cdn.markhuang.ai/news/unlimited-ocr-endurance/workflow-risk.webp)

*对生产用户来说，模型只是系统的一部分；围绕它的流水线决定了输出能不能被信任。*

## 我的结论

Unlimited-OCR 是一条有用的新闻，因为它把 OCR 推向了真实文档工作的形态：长上下文、重复结构、服务端推理，以及必须经得起运营复核的输出。这比又一次宣称 OCR 被解决了更有意思。

我从百度这次发布里看到的教训是：文档 AI 正在变成一项耐力运动。读懂一页只是入场券。跨很多页仍然保持连贯，同时控制内存和服务成本，才是下一场真正有意义的战斗。