Unlimited-OCR 实测：one-shot 多页 PDF 解析是否真的强

/research/unlimited-ocr-web-test-report-shareable.md

生成时间：2026-06-23 版本：脱敏分享版

这次测试的目标不是看单张图片 OCR 能不能识别，而是验证 Unlimited-OCR 官方真正有区分度的路径：PDF 多页 infer_multi() / one-shot long-horizon parsing。测试方式是把这个路径接入一个本地 Web UI，然后用真实 PDF 文档跑一轮，对比 one-shot 多页解析和逐页循环解析的差异。

一句话结论

Unlimited-OCR 的 one-shot 多页路径确实可用，14 页 PDF 能一次性解析成功，文本覆盖率很好；但在这轮测试里，它没有比“同一个模型逐页循环解析”明显更快。

它的工程价值是真的：能把多页 PDF 一次性交给模型做连续解析，并输出结构化 Markdown。但如果只看短 PDF 或单页图片，它不会给人一种“肉眼震撼、碾压普通 OCR”的体验。

测试结论

这轮测试可以分成两层看。

第一，官方最强路径跑通了。Web UI 对 PDF 默认使用 one_shot，后端实际调用 model.infer_multi()，而不是把 PDF 拆成一页一页循环 OCR。测试用 Unlimited-OCR 官方技术报告的 14 页版本，300 DPI 渲染，one-shot 解析成功：

pages: 14
elapsed_seconds: 159.078
infer_seconds: 156.913
output_tokens: 13493
result_chars: 39891
norm_ratio: 0.9579
token_coverage: 0.9902

这说明它不是 README 里的纸面功能，而是能在本地 GPU 环境里跑通“多页 PDF 一次性连续解析”。

第二，这轮测试没有复现出 one-shot 相对逐页循环的明显速度优势。2 页、5 页、10 页测试里，one-shot 和 page-loop 耗时非常接近；10 页时 one-shot 反而略慢：

10页 one_shot: 110.796s
10页 page_loop: 104.142s

这不等于官方论文是错的。官方强调的强项主要是相对 DeepSeek-OCR 这类标准注意力解码器：长输出时，Reference Sliding Window Attention（R-SWA）可以避免 KV cache 随生成长度持续增长。这轮 baseline 是“同一个 Unlimited-OCR 模型逐页调用”，不是 DeepSeek-OCR 原始 full-attention baseline，所以不能用它来复现论文里的 35% 长输出吞吐优势。

实现了什么

测试用 Web UI 做了两个路径：

pdf_strategy=one_shot
PDF 先渲染成多页图片，然后一次性调用 model.infer_multi()。这是官方多页长文档路径，也是默认选项。

pdf_strategy=page_loop
PDF 先渲染成多页图片，然后逐页调用 model.infer()，最后拼接 Markdown。这个路径保留为 baseline。

Web UI 支持：

图片上传：普通单图 OCR。
PDF 上传：默认 one-shot 多页解析。
PDF baseline：可以切换到 page-loop 逐页解析。
结果显示：保留原始 Markdown source，不强行渲染成 HTML。
元数据展示：页数、DPI、渲染耗时、推理耗时、总耗时、输出 tokens 等。

后端返回的关键健康信息类似：

{
  "pdf_supported": true,
  "pdf_strategies": ["one_shot", "page_loop"],
  "default_pdf_strategy": "one_shot",
  "max_pdf_pages": 20,
  "pdf_dpi": 300,
  "has_infer_multi": true
}

测试方法

测试文档使用 Unlimited-OCR 官方仓库中的技术报告 PDF，并切分为 2、5、10、14 页版本。

质量对比使用 PDF 内嵌文本作为 reference，做两个轻量指标：

norm_ratio：将 OCR 输出和 PDF 原文归一化后，用文本相似度估算整体接近程度。
token_coverage：reference 中长度大于 2 的 token，有多少能在 OCR 输出中找到。

这不是严格 OCR benchmark，但足够判断：

是否能跑通多页；
是否出现大面积漏页；
是否发生明显重复或跑偏；
one-shot 与逐页循环在同一服务里的大致速度差异。

性能与输出规模

case	strategy	pages	elapsed_seconds	infer_seconds	output_tokens	result_chars	ok
paper2	one_shot	2	13.638	13.326	1258	2640	True
paper2	page_loop	2	12.466	12.173		2653	True
paper5	one_shot	5	40.367	39.596	3722	12313	True
paper5	page_loop	5	39.775	39.017		12318	True
paper10	one_shot	10	110.796	109.191	9550	31151	True
paper10	page_loop	10	104.142	102.664		31177	True
paper14	one_shot	14	159.078	156.913	13493	39891	True

可以看到，one-shot 确实能处理 14 页，但在 2/5/10 页上没有比 page-loop 快。10 页时，one-shot 慢了约 6.65 秒。

文本相似度

case	strategy	expected_chars	result_chars	norm_ratio	token_coverage
paper2	one_shot	3835	2640	0.9799	0.9936
paper2	page_loop	3835	2653	0.9809	0.9936
paper5	one_shot	13583	12313	0.9851	0.9921
paper5	page_loop	13583	12318	0.9852	0.9921
paper10	one_shot	28947	31151	0.9408	0.9879
paper10	page_loop	28947	31177	0.9417	0.9885
paper14	one_shot	38455	39891	0.9579	0.9902

文本覆盖率整体很好，说明没有明显漏页。10 页相似度下降，主要来自公式、引用、检测框标记、版面结构和文本顺序差异；不是 OCR 完全失败。

这是否证明它“像官方说的那么强”

只能说：部分证明。

这轮测试证明了：

infer_multi() 可用，不是 README 里的纸面接口。
14 页 PDF one-shot 成功，没有中途断页、服务崩溃或明显重复失控。
输出质量可用，token coverage 接近 0.99。
Web UI 可以把官方最强路径作为默认 PDF 路径。

但这轮测试没有证明：

one-shot 比逐页循环更快。
Unlimited-OCR 比 DeepSeek-OCR 原始标准注意力模型快 35%。
它在 40 页、100 页这种更长文档上仍然稳定。
它比 PaddleOCR、MinerU、Qwen-VL、Gemini 等系统更适合所有文档。

关键原因是：这次 baseline 是 same model + page_loop，而不是官方论文中的 DeepSeek-OCR full-attention baseline。Unlimited-OCR 的 R-SWA 优势主要体现在“长输出时 KV cache 不随生成长度增长”，不是必然体现在“同一模型 one-shot 比逐页循环快”。逐页循环每页都短，反而可能因为任务拆小而更稳。

我的使用判断

我会把它定位为：本地长 PDF 到 Markdown 的实验型工作台。

适合使用的场景：

需要把 PDF 转成 Markdown；
想保留标题、表格、段落和大致阅读顺序；
文档不方便上传到第三方云服务；
能接受几十秒到几分钟的等待；
想测试多页连续解析能力。

不适合把它当默认万能 OCR 的场景：

只是截图里几行字；
追求秒级响应；
只需要纯文本；
需要稳定批量生产；
需要对扫描书籍、低清晰度图片做严肃归档。

后续值得补的测试

如果要继续判断它是不是真的强，下一步应该补三组测试：

对照 DeepSeek-OCR 原模型
这是复现官方性能 claims 的关键。

对照 PaddleOCR / MinerU
这能回答“作为普通文档 OCR 工具，它是不是更好用”。

跑 20 页 / 40 页 / 更长文档
重点观察耗时曲线、重复输出、后半段质量下降、显存峰值。

当前这轮的结论已经足够指导使用：Web UI 默认走 one-shot 是合理的，因为这是官方最强路径；但 page-loop 必须保留，因为短文档上它并不弱，甚至略快。