OCR 的新战场是耐力

百度在 GitHub 上发布了 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 摘要 把压力说得很直接：LLM 式解码器可以利用语言先验，但输出序列变长后，KV cache 的内存消耗会上升，生成速度也会变慢。论文提出的方案是 Reference Sliding Window Attention，也就是 R-SWA，用它替换解码器中的注意力层，让解码过程中的 KV cache 保持恒定。摘要还称，在 32K 最大长度下，这套设计可以单次前向转写几十页文档。

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

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 把页面转成图片，再把这些图片送入多页解析。

SGLang 让它更像基础设施

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

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

开源信号也值得注意

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

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

我的结论

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

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