Baidu Unlimited-OCR 真正解决的，是长文档 OCR 的分页断裂问题

Baidu Unlimited-OCR 以 MIT License 开源，并在官方 README 中把目标定义为 One-shot Long-horizon Parsing，同时提供 Transformers、vLLM、SGLang 三条推理路径。配套的 Unlimited OCR Works 论文进一步解释了长输出解析背后的设计。

Unlimited-OCR 的核心价值，不在于把 OCR 又包装成一次模型热闹，而在于它把一个老问题重新摆到台面上：长文档解析失败，常常不是单页识别能力太弱，而是分页之后上下文被切碎、版式关系被打散、后处理链路只能靠规则缝合。

过去处理几十页 PDF，常见流程是先把每页转成图片，再逐页 OCR，最后用脚本把结果拼回 Markdown、HTML 或 JSON。这个流程看起来稳定，实际问题很多。表格跨页时，上一页的表头和下一页的数据容易失去关系；合同附件里的编号在分页处断开；论文双栏的阅读顺序一旦被单页局部判断带偏，后面的 RAG 检索会引用一段看似完整、实则错位的文本。Unlimited-OCR 把卖点放在多页一次性处理和长视野解析上，正好击中了这个断裂点。

核心判断：先把它看成长文档解析模型，而不是万能扫描仪

官方论文把问题说得很明确：端到端 OCR 使用大语言模型解码器后，可以利用语言先验提升文本生成质量，但输出序列变长时，KV cache 会带来内存增长和生成变慢。Unlimited OCR 的路线，是在 DeepSeek OCR 这类视觉压缩编码器基础上，引入 Reference Sliding Window Attention，也就是 R-SWA，让解码阶段在长输出中维持近似常量的 KV cache，并降低注意力计算成本。

这意味着它真正想改善的是“长时程复制和解析”能力。官方描述称，在 32K 最大长度设置下，它可以把几十页文档放进一次前向解析。这里的关键词是文档解析、长视野、上下文连续，而不是“任何机器都能飞快跑”“复杂扫描件必然准确”。微信原文里提到的 CPU、下载量和社交媒体传播，只能当作传播信息；官方 README 的 Transformers 示例写明测试环境是 Python 3.12.3 加 CUDA 12.9，并且代码里调用 model.eval().cuda()，不能把它改写成官方 CPU 性能承诺。

分页痛点为什么值得单独讨论

OCR 工具最容易被低估的不是识别单个字，而是恢复文档结构。单页截图里，模型只需要判断局部布局；多页文档里，它还要理解标题层级、列表编号、跨页表格、图注延续、页眉页脚噪声和正文顺序。分页边界越多，后处理就越难。

把每页单独解析再拼接，会把文档理解拆成很多短任务。短任务有优势，便于重试、并行和定位错误；但它也天然缺少全局上下文。比如技术白皮书里的“图 3-2”可能在下一页继续解释，合同里的“本条款”指向上一页标题，招股书表格的单位说明可能只出现在表格第一页。逐页 OCR 可以识别文字，却不一定能保留关系。

Unlimited-OCR 的多页路径试图把这些关系留在一次模型上下文里。它不等于自动解决所有跨页关系，但至少让模型有机会同时看到多页图像和持续输出，而不是在页与页之间彻底失忆。对知识库入库、论文解析、财报抽取、说明书数字化来说，这个方向比单纯追求单页识别率更接近真实痛点。

README 暴露出的三条使用路线

第一条是 Transformers 路线，适合做本地验证和小规模实验。README 示例使用 AutoTokenizer.from_pretrained 和 AutoModel.from_pretrained 加载 baidu/Unlimited-OCR，单图调用 infer，多页或 PDF 调用 infer_multi。PDF 并不是直接喂给模型，而是先用 PyMuPDF 按页转成图片，再把图片列表交给 infer_multi。单图有 gundam 与 base 两种配置；多页和 PDF 使用 base，image_size=1024，max_length=32768。

第二条是 vLLM 路线。README 没有把全部部署细节展开，而是指向官方 recipe，并列出面向 CUDA 13.0 的默认镜像和 Hopper/CUDA 12.9 镜像。这条路线更适合需要服务化吞吐的团队，但前提是你熟悉 vLLM、镜像版本、GPU 平台差异和推理服务监控。把 OCR 模型放进 vLLM，不代表业务链路已经可用；输入预处理、结果落盘、失败重试和队列控制仍要自己设计。

第三条是 SGLang 路线。README 给出 uv 虚拟环境、SGLang 本地 wheel、kernels 与 PyMuPDF 安装，以及 python -m sglang.launch_server 的启动参数。服务暴露 OpenAI-compatible /v1/chat/completions，请求里需要把图片编码成 data URL，并启用自定义 no-repeat n-gram 处理器。这个细节很重要：长文档生成很容易出现重复片段，官方示例显式使用 no_repeat_ngram_size、ngram_window 或自定义 logit processor，说明生产链路不能只关心“能不能返回文本”。

布局保留的价值在下游，而不是截图好看

文档 OCR 的输出如果只是一长串纯文本，很多下游任务会立刻变难。RAG 需要章节边界和页码；合同审核需要条款编号；财务表格需要表头、单位和数据列关系；科研论文需要公式、图注、引用与正文分开。布局保留不是审美问题，而是后续系统能不能判断来源、引用证据和追踪错误的问题。

Unlimited-OCR 的“解析”比传统 OCR 更值得看的地方，也在这里。它不是只把图片里的字抠出来，而是希望输出更接近文档结构的内容。实际落地时，仍要检查输出格式是否满足自己的系统。比如 Markdown 标题层级是否稳定，表格是否可被解析，图注是否和图片位置对应，页码是否保留，空白页和扫描噪声是否被误当正文。

部署前先准备一组硬样本

评估这类模型，不能只拿宣传样例。建议准备四类文档：纯电子 PDF、扫描 PDF、复杂版式 PDF、表格密集或公式密集文档。每类选 5 到 20 份真实文件，人工标出最关键的检查点。检查点不需要覆盖每个字，但必须覆盖阅读顺序、跨页关系、表格结构、页码引用、标题层级和明显错字。

验证时可以分三层。第一层看单页：是否漏字、错字、乱码、重复输出。第二层看多页：分页处标题、表格和列表是否延续。第三层看业务：把输出放进知识库、合同审查或数据抽取流程，看引用、检索和人工复核是否变得更容易。只有第三层通过，才能说明它对业务有价值。

适用场景与不适用场景

它适合有 GPU 资源、文档量较大、且痛点集中在多页结构解析的团队。典型场景包括企业知识库入库、长 PDF 转 Markdown、论文或报告解析、扫描归档文件结构化、批量说明书处理。它也适合做 OCR 基线评测：把传统逐页 OCR、MinerU 类文档解析工具和 Unlimited-OCR 放到同一批样本上比较。

它不适合被当成低成本万能 OCR API。显存、速度、并发、输入页数和输出长度都需要实测。手写体、严重倾斜、低分辨率扫描、印章遮挡、双语混排、表格跨页、极长文档，都可能出现不可接受的错误。长上下文设计降低了一类成本，不等于消除所有资源瓶颈。

上线前的最低验收线

最小可行验收应该包括：记录模型版本和运行路径；固定 PyMuPDF 转图 DPI；保存输入图片列表；保留原始输出和后处理输出；统计重复段落；抽样检查跨页位置；对表格另做结构化校验；把失败样本标注成回归集。只要这些证据不存在，就不要把一次成功 demo 当成系统能力。

结论很清楚：Unlimited-OCR 值得试，但要按长文档解析工程来试。它的亮点是把多页文档放进更连续的模型视野，并尝试用 R-SWA 缓解长输出的 KV cache 压力；它的风险同样具体，主要落在硬件、长输出重复、复杂版式稳定性和业务验收上。把它纳入生产前，先用真实文档做回归评测，比追逐传播数字更可靠。