Baidu Unlimited-OCR 不是又一个 OCR Demo，而是文档 AI 基础设施的一次信号

把 Unlimited-OCR 纳入产品架构，需要分别评估可维护性、服务化和模型能力。官方仓库提供 MIT 许可的代码，README公开 Transformers、vLLM 与 SGLang 接入面，Unlimited OCR Works 论文则给出长时程解析的技术依据。

Unlimited-OCR 的关键价值，不是“百度开源了一个 OCR 模型”这件事本身，而是它释放了一个更大的信号：文档 AI 正在从单页识别工具，转向长文档解析基础设施。企业真正需要的不是把图片里的字抠出来，而是把几十页材料变成可引用、可检索、可复核、可进入业务系统的结构化内容。

这个判断会影响产品设计。你如果把 Unlimited-OCR 当成一个普通 OCR API，就会只问价格、速度和准确率；如果把它当成文档智能管线的一块底座，就会同时关心页间上下文、版式恢复、长输出成本、GPU 服务化、错误回归和人工复核。两种视角得到的系统完全不同。

文档 AI 的瓶颈从来不是“识字”这么简单

过去几年，OCR 产品常常把卖点放在识别率上。但进入 LLM 应用以后，识别率只是第一关。知识库需要稳定分块，智能问答需要引用来源，合同审查需要条款层级，财务分析需要表格结构，企业搜索需要保留标题、页码和上下文。只输出一坨文本，很多下游任务都会变成补锅。

这也是长文档 OCR 重新变重要的原因。LLM 应用不缺“读一张图”的能力，缺的是把一整份资料读成可以被机器继续使用的结构。如果每页都单独处理，跨页表格、章节延续、编号列表和图注关系就容易断开。后处理脚本能修一部分，但规则越堆越多，系统越脆。

Unlimited-OCR 把目标放在 One-shot Long-horizon Parsing，说明它意识到文档不是很多张孤立图片，而是一段连续信息。这个方向本身就值得产品经理和工程团队重视。

R-SWA 背后的产品含义

论文提出的 Reference Sliding Window Attention，简称 R-SWA，表面看是注意力机制优化，产品上对应的是长输出成本问题。端到端 OCR 使用 LLM 解码器后，输出越长，传统注意力里的 KV cache 压力越大，速度也容易下降。对几十页文档来说，这不是学术细节，而是能不能批量处理的关键。

Unlimited OCR 的设计目标，是在长时程解析里维持常量 KV cache，并降低注意力计算成本。它不保证所有场景都便宜，也不代表普通 CPU 可以稳定承担生产负载；它说明团队正在从模型结构层面处理长文档成本。对文档 AI 基础设施来说，这比单次 demo 更重要。

企业采用这类模型时，应该把 R-SWA 理解成一个方向性优势，而不是采购承诺。真正需要回答的是：在自己的 GPU、自己的文档页数、自己的并发量下，P50、P95、显存峰值、失败率和人工复核率分别是多少。没有这些数字，任何“长文档一次性解析”都还只是潜力。

三条推理路径对应三种产品阶段

Transformers 路线适合研发验证。它直接加载 baidu/Unlimited-OCR，单图跑 infer，多页跑 infer_multi，PDF 先用 PyMuPDF 转图片。这个阶段要解决的是模型能不能在本机跑、输出是否可信、参数如何影响结果。不要急着做平台化，先把回归样本跑透。

SGLang 路线适合把模型放进内部服务。README 的 SGLang 示例启动 OpenAI-compatible 接口，使用 /v1/chat/completions，并通过自定义 no-repeat n-gram 处理器控制重复。它更接近真实应用，因为业务系统通常不会直接调用 Python 对象，而是通过 HTTP、队列、重试和日志接入。

vLLM 路线适合进一步评估吞吐和部署标准化。README 指向官方 vLLM recipe，并提供不同 CUDA/GPU 平台的镜像。对已有推理平台的团队来说，这意味着 Unlimited-OCR 可以被纳入更熟悉的服务框架；但输入预处理、PDF 转图、输出结构化和质量门禁仍然需要业务侧负责。

一个文档 AI 产品应该怎样接入它

更合理的架构不是“用户上传 PDF，模型返回文本，然后结束”。应该拆成六层：文件接入、页面渲染、模型解析、结构归一、质量评估、人工复核或入库。Unlimited-OCR 主要覆盖模型解析层，并影响结构归一层。其他层如果缺失，模型越强，错误进入系统的速度也越快。

文件接入层要保存原件、哈希、页数和权限。页面渲染层要记录 PyMuPDF 版本、DPI 和输出图片。模型解析层要记录推理后端、参数、耗时和原始输出。结构归一层要把 Markdown、表格、页码和标题层级整理成稳定格式。质量评估层要计算重复率、空页率、页覆盖率、表格通过率和关键字段命中。人工复核层要把低置信文档拦下来。

这套链路听起来重，但文档 AI 进入生产后一定会走向这里。没有证据链的 OCR 输出，很难被审计；没有回归样本的模型升级，很容易引入隐形退化；没有人工复核通道的全自动解析，在合同、财务和医疗场景里风险过高。

不要被传播数字带偏

微信原文里出现了下载量、社交推荐、CPU 相关表述，这些信息能解释它为什么快速出圈，但不能替代技术验收。官方 README 的 Transformers 路线明确以 NVIDIA GPU/CUDA 环境作为测试条件，GitHub latest release endpoint 返回 404，也不应该编造正式 release 版本号。文章、产品页和销售材料最容易犯的错误，就是把传播热度改写成工程能力。

正确写法应该保守：模型权重和代码公开，仓库为 MIT License；README 显示支持 Transformers、vLLM、SGLang；官方论文提出 R-SWA，用于缓解长输出中的 KV cache 与计算成本；多页一次性解析是核心卖点；实际速度、显存和复杂文档表现必须按本机和业务样本测试。

适合做成哪些产品能力

第一个方向是企业知识库入库。很多知识库失败不是问答模型弱，而是文档摄取质量差。Unlimited-OCR 可以作为长 PDF、扫描件和图文混排材料进入向量库前的解析层，前提是输出必须保留页码、标题和段落关系。

第二个方向是专业文档工作台。法律、财务、科研和工程团队需要边看原文边看结构化结果，允许人工修正。这里的核心体验不是“自动完成”，而是快速定位模型错在哪里，并把修正反馈到回归集。

第三个方向是批量归档和搜索。历史扫描件、说明书、报告和会议材料可以被统一解析，进入全文搜索或知识图谱。这个方向最关心吞吐、失败重试和低成本人工抽检。

不适合怎样包装

不要把它包装成“无需硬件门槛的免费 OCR 神器”。不要承诺手写体、严重模糊扫描、极端表格和超长文档都能 100% 正确。不要把一次长 PDF 成功解析，扩展成所有 PDF 都能一次解决。不要把 vLLM 或 SGLang 接口存在，误解成生产级文档平台已经完成。

更务实的定位，是把它看成文档 AI 基础设施里的新候选组件。它可能减少分页断裂，可能改善长文档解析成本，也可能在复杂样本上暴露新的错误模式。产品团队要做的，是用真实文档、真实指标和真实人工复核流程，把这些可能性逐步变成可用能力。

结论是：Baidu Unlimited-OCR 的意义不在营销层面的“又一个 OCR 爆款”，而在工程层面的长文档解析范式。它提醒所有做文档 AI 的团队，下一阶段的竞争不只是识别几个字，而是谁能把长文档稳定变成可信数据。能做到这一点，OCR 才会从工具功能变成基础设施。