Baidu Unlimited-OCR 怎么验收：从单图到 PDF 多页解析的检查清单
面向动手验证的 Baidu Unlimited-OCR 指南：梳理 Transformers、SGLang、vLLM 三条路径，以及单图、多页、PDF 转图、重复输出和布局质量的验收方法。
部署前先建立可追溯的验收基线：项目仓库给出代码与许可，README列出 Transformers、vLLM 和 SGLang 的运行路径，论文解释长时程解析设计。第三方样例只能说明值得测试，不能替代自己的硬件和文档回归。
安装 Unlimited-OCR 后，最先要验证的不是“终端有没有跑完”，而是输入、输出、版式和重复控制是否形成可复现链路。OCR 模型一旦进入真实文档流，失败往往不出现在第一张干净截图，而出现在第十页之后的表格、页眉噪声、跨页编号和长输出重复里。
因此，动手试用时不要把它当成普通命令行 OCR。更稳妥的方式，是把单图、多图、PDF、服务化接口拆成四个阶段，每一阶段都有固定样本、固定参数和固定验收项。只要验收脚本不稳定，后面讨论效果、速度和成本都没有意义。
一、先钉住官方边界
官方 README 的 Transformers 示例写明测试环境是 NVIDIA GPU、Python 3.12.3、CUDA 12.9，并在示例中执行 model.eval().cuda()。这条信息要先写进自己的验证记录。社交传播里出现的“CPU 都能跑”不能替代官方环境说明，也不能直接变成上线承诺。
README 里的入口也很清楚：单图用 infer，多页或多图用 infer_multi。PDF 不是一个神秘输入类型，而是先用 PyMuPDF 把每页渲染成图片，再把图片路径列表传进去。最大输出长度示例是 max_length=32768，多页使用 base 配置，image_size=1024。这些参数决定了你的验收报告应该记录模型路径、图片尺寸、DPI、页数和输出长度。
二、单图验收：先看可复现，不看极限效果
第一张样本最好选干净、版式明确、字数适中的图片。目标不是展示模型多强，而是确认依赖、权重、显存、输入路径、输出目录和保存逻辑全都工作。单图配置里，README 提到 gundam 与 base 两种路径：gundam 使用 base_size=1024、image_size=640、crop_mode=True；base 使用 image_size=1024、crop_mode=False。不要把两套配置的结果混在同一个评测表里。
单图验收至少检查五件事：是否漏掉标题，段落顺序是否正确，表格是否保持行列关系，是否出现重复句，输出文件是否能被后处理程序读取。很多模型在视觉上看似识别成功，但 Markdown 层级、列表缩进和表格分隔符并不稳定。后续要进 RAG 或数据库时，这些细节比“肉眼看着差不多”重要得多。
三、多页验收：重点盯分页处
Unlimited-OCR 的项目定位是 One-shot Long-horizon Parsing，多页处理才是它与普通单页 OCR 拉开差异的地方。测试多页时，不要只看平均准确率。分页处才是高风险区域：上一页最后一行是否被截断，下一页开头是否被误接到页眉，表格是否丢失表头，编号列表是否重排，图注是否跑到错误段落。
建议准备一个 6 到 12 页的小 PDF，把页码边界附近的文本人工标注出来。验收时逐项核对：第 2 页开头是否接续第 1 页语义；跨页表格是否保留字段名；章节标题是否只出现一次；页眉页脚是否被过滤或至少不混入关键正文；引用编号是否仍然能回到原页。多页一次性处理的价值，只有在这些位置通过检查时才成立。
四、PDF 转图是质量的一部分
README 示例使用 PyMuPDF，并设置矩阵按 DPI 渲染页面。很多 OCR 误差并不是模型本身造成的，而是 PDF 转图阶段已经把小字、细线、表格边框和浅色批注处理坏了。DPI 太低会丢细节，太高会增加显存和输入处理压力。真实评测应该把 DPI 当成实验变量，而不是随手写死。
更好的目录结构是：input.pdf 保持不动，pages/ 保存按页渲染图片，raw-output/ 保存模型原始输出，normalized/ 保存后处理结果，report.json 记录模型、参数、页数、耗时、错误和人工检查结论。这样下一次升级模型、换 vLLM 或换 SGLang 时，才知道变化来自哪里。
五、SGLang 服务化验收不能只看 HTTP 200
SGLang 路线会启动 OpenAI-compatible /v1/chat/completions 服务。README 的启动参数包含 --context-length 32768、--enable-custom-logit-processor、--disable-overlap-schedule、--skip-server-warmup 等。请求端把图片转成 base64 data URL，并传入自定义 no-repeat n-gram logit processor。
验收服务时，HTTP 200 只说明接口有响应。还要检查流式输出是否完整，长输出是否提前断掉，重复控制是否生效，并发请求是否互相影响，超时后是否能重试。README 提到的 infer.py 支持图片目录或 PDF、并发请求、重试，这些能力更接近实际批处理场景。生产前至少要模拟一批文档排队，而不是只发一张图。
六、vLLM 路线适合吞吐测试，不适合跳过质量门禁
vLLM 路线的吸引力在服务化和吞吐，但它不会替你解决文档质量问题。官方 README 指向 vLLM recipe，并给出不同 GPU 平台的镜像：默认 CUDA 13.0 镜像，以及 Hopper/CUDA 12.9 镜像。选择镜像前要确认 GPU 架构、驱动、CUDA 兼容性和容器环境。
吞吐测试应该和质量测试分开。先用小样本确认输出正确，再逐步增加页数、并发、文档大小和队列长度。不要在质量还不稳定时直接压测，否则你只会得到“系统很快地产生了不可信文本”。OCR 服务真正的指标包括成功率、人工复核率、重复段落率、表格失败率、平均每页耗时、P95 延迟和失败重试成本。
七、用回归样本管理风险
每次发现错误，都应该把原始页、模型输出、正确答案和错误类型保存下来。错误类型可以分为：漏识别、错字、阅读顺序错误、表格结构错误、重复输出、跨页关系错误、噪声混入、输出截断。下一次更新依赖、切换推理后端或调整 DPI 时，先跑这组回归样本。
这类模型的风险不是“偶尔错一个字”这么简单。对合同、财报、审计材料、科研数据来说，错误如果进入知识库或数据库，后续检索会继续放大。验收脚本必须能阻止低质量输出自动入库。最简单的做法，是为每份文档生成一个质量分：关键字段命中、页码覆盖、表格通过率、重复率和人工抽检结果都写进去，低于阈值就转人工。
八、适合谁先试
适合先试的人群，是已经有 OCR 或文档解析流程、知道自己失败样本在哪里、并且有 GPU 环境可做本地或服务化验证的团队。比如知识库入库、PDF 报告解析、长说明书转 Markdown、扫描档案结构化、论文批处理和表格密集文档清洗。
不适合的场景也很明确：只想在低配机器上找一个便宜 OCR 替代品；没有真实样本，只想看传播效果；无法接受人工复核；文档里大量手写体、模糊扫描、遮挡或极端版式；业务需要 100% 自动化正确。Unlimited-OCR 给了长文档解析一个很有意思的方向，但工程验收仍然要靠自己完成。
最终结论很朴素：先用单图确认安装，再用多页确认分页关系，再用 PDF 批处理确认链路，再用 SGLang 或 vLLM 做服务化压力测试。每一步都有证据，Unlimited-OCR 才能从“能跑的模型”变成“能进入工作流的解析组件”。