baidu/Unlimited-OCR

如果你现在要把一份 300 页扫描件拆成单页、逐页 OCR、再把 Markdown 重新拼起来，还要祈祷顺序没乱，Unlimited-OCR 针对的正是这条流水线。它是发布了权重和推理代码的 OCR 模型，不是对现成引擎的封装。对多数读者来说，真正要判断的是：长文档的承诺在自己手头的文档上是否成立，以及服务端的部署能否适配自己的硬件。

解决什么问题

你手里有一份长 PDF 或扫描合集，想要得到结构化文本：页序、表格、页眉、阅读顺序都不能丢。常见做法是把文件切成页图、逐页送进识别器、再人工拼回结果，这样跨页结构和版面上下文都会丢失，拼接胶水代码反而成了长期维护的负担。Unlimited-OCR 改变的是处理单位：README 给出了一次请求解析整本书的演示，并附了回放作为可视化 项目说明。你得到的是连续的一份解析结果，而不是一堆页级输出，这正是它的核心价值。

有什么不同

第二代引入了 Sparse Reference Sliding Window Attention（SR-SWA），README 说它把文本-视觉注意力压缩到固定规模的参考窗口，例如 512 个 token，从而让每一步解码的延迟和显存占用基本不随文档变长而变化。README 将其表述为消除二次方注意力开销和显存瓶颈，而这正是今天迫使人们分页处理的约束。Hacker News 六月讨论中有评论者把它理解为把注意力分成全局参考和局部生成两条路径，KV cache 不再线性增长 评论者解释。

代价落在局部窗口的宽度上。另一位评论者没读完整论文，但担心图像输入本身 token 消耗很大，局部生成窗口偏小，希望至少有 4096 token 左右 窗口顾虑。这是读者的个人判断，不是项目方的结论，但它指出了一个值得实测的问题：保住全局结构的同时，局部细节是否会退化。README 还记录了针对超长文档的页窗口调度开关，会复用上一个窗口的 KV 尾部，所以实际使用时“无限”是通过服务端的窗口机制实现的 部署细节。

谁值得试

适合：手里有长篇、版面复杂的文档（书籍、合同、手册、档案扫描），已经有 GPU 推理环境，并且想扔掉自己写的分页合并逻辑的团队。Transformers 路径被描述为原生、适合快速测试，SGLang 路径推荐用于正式服务，因此可以先验证模型效果，再搭服务。

不适合：想要一个开箱即用的托管 OCR 接口的人，或者只处理短小单图、用更小的识别器更简单的人。没有合适 GPU 的读者也不适合，因为文档给出的快速测试环境以 80GB A800 为参照，服务路径本身就需要一台服务器。

使用条件与边界

快速测试路径记录了 Python 3.10，以及固定版本的 torch、transformers、tokenizer 和 huggingface-hub，并注明在 NVIDIA A800-80GB 上测试过 环境说明。服务路径需要 uv 虚拟环境、仓库自带的定制 SGLang wheel，以及用 PyMuPDF 把 PDF 转成图片。这些版本锁定和定制 wheel 是主要的接入成本：你需要自己管理环境，而不是 pip 安装一个稳定包。

模型还在多处发布，权重同时上了 Hugging Face 和 ModelScope，另有百度云 OCR 的接入方式 模型权重。带 remote code 的权重意味着加载路径执行了什么需要你自行过目。锁定版本之外的长期维护情况，现有材料不足以判断。

HotRepo 点评

2026-10-28 该项目为 29,384 stars，当日 +504，这是唯一一次被记录到的日榜观察 当日观察；同日它发布了面向超长文档解析的 MarathonDocBench，并新增 ModelScope 与百度云渠道 发布记录。2026-06-23 的 Hacker News 讨论获得 496 分、110 条评论 讨论，说明关注度，但不能说明输出质量。仅有一个上榜日期，无法判断热度能否持续。采用前，用自己的扫描件把它的长文档输出和逐页流程的结果比一比。