先看个数字:一个 OCR 模型,主识别模型只有约 100 万参数,模型文件加起来约 18 MB,不用 GPU,也不用装 PyTorch。这篇就简单说说 Datalab 10 月 13 日发布的 Indra OCR:成绩怎么样、速度到底快多少、谁值得用。
它是个啥
模型卡上的原话是:
“Indra OCR is a 1M-parameter OCR model that reads up to 49 pages per second on CPU. It turns PDFs and images into markdown, plain text, or JSON with boxes”
说白了,就是一个纯 CPU 跑的 OCR 包,能把 PDF 和图片转成 markdown、纯文本,或者带坐标框的 JSON,开发方是 Datalab。
几个基本信息(截至 10 月 16 日):
• 主识别模型 rec.onnx 约 100 万参数,模型文件合计约 18 MB
• 跑在 ONNX Runtime 上,不需要 PyTorch
• PyPI 最新版本 0.3.2
官方成绩:先说好,这些都是自报的
下面的分数全部来自 Datalab 的模型卡和博客,测的是 Datalab 自己做的 OmniParseBench,目前没有找到第三方复现。
| 模型 / 模式 | headline | text |
|---|---|---|
| Indra OCR 默认 | 62.1 | 41.3 |
Indra OCR 开 --math | 66.8 | — |
| PaddleOCR PP-OCRv6 small(纯文本模型) | — | 35.8 |
| Tesseract | — | 19.3 |
| PP-StructureV3 | 58.4 | 55.6 |
中文子集上,官方报的是 Indra 64.7,PP-OCRv5 mobile 65.4,PP-StructureV3 68.4。
挺难得的一点是,官方自己把弱项也摆出来了:不开 --math 时,PP-StructureV3 的 text 成绩(55.6)比 Indra(41.3)高;中文子集上它也排在两个 Paddle 方案后面;手写只有约 8%,老旧扫描件约 20%。
速度到底快多少
官方的说法:同一台 32 核 x86 机器(无 GPU)、同一批 300 页,每核一个 worker、OCR 模式、默认设置下,Indra OCR 约 49 页/秒,是 PaddleOCR PP-OCRv6 small 纯文本模型的 11.5 倍、Tesseract 的 16.9 倍。所以”快 11 倍”说的是 32 核吞吐量,比的是 PP-OCR 纯文本模型。单页中位延迟约 228 ms 是在 4 个 vCPU 上测的。
个人测试:X 上的 @manateelazycat 说自己测了一下,Indra OCR 默认只快 1.24 倍,他深度优化后快 2.97 倍,并说经 AI 分析,“快 11 倍是 32 个线程叠加的数据”(原帖)。他没有公开测试方法,所以这只能算一份个人测试。
两边其实不完全矛盾:官方的倍数带着 32 核这个前提,个人测试的条件不一样。看到”快 11 倍”的时候,先问一句是在多少核上测的。
王先生自己也测了一遍。机器是一台 i5-12490F(6 核 12 线程)的 Windows 11 台式机,跑的是 indra-ocr 0.3.2,测试文件是一篇 14 页、带文本层的英文论文。先说清楚:这次只测了速度和内存,没测识别准确率,也没和 PaddleOCR 放在同一台机器上对比。
| 场景 | 端到端耗时(含启动) |
|---|---|
| 14 页 PDF,默认模式 | 约 3.2 秒,约 4.3 页/秒 |
14 页 PDF,强制 OCR(--mode ocr) | 约 7.1 秒,约 2 页/秒 |
| 单页 PDF | 3.5–5.5 秒 |
| 14 帧多页 TIFF | 约 43 秒 |
- 大约三分之一是启动成本。14 页 3.2 秒里,进程池启动就占了 1.1–1.5 秒,所以零散地一页一页调用最不划算,空白页也要 3.2 秒左右。少于 4 页的文档不会开并行,能攒成一批就攒成一批。
- 核数不是越多越好。这台 6 核机器上开 8 个 worker 最快,开到 12 个反而回退。王先生的建议是把
--cores设成 6–8,别超过逻辑核数。 - 多页图片先转成 PDF。图片输入不走进程池,同样 14 页内容,TIFF 要 43 秒,PDF 强制 OCR 只要 7 秒左右。
- 调 dpi 基本不影响速度。150、200、300 dpi 的耗时都在 7 秒上下(准确率这次没测)。
- 内存:默认 12 个 worker 时约 1.6 GB,强制 OCR 约 2.2 GB。
- 中文 Windows 有两个编码坑:
--math会直接报错退出,设PYTHONUTF8=1就好了;把结果输出到 stdout 再重定向到文件,遇到特殊字符也会崩,用--out指定输出文件,或者设PYTHONIOENCODING=utf-8。
说白了,在王先生这台 6 核机器上,默认模式处理一份带文本层的 PDF 确实挺快;这次没和 PaddleOCR 同机比,所以对”快 11 倍”下不了结论。
能读什么,读不了什么
按 GitHub README,扫描件和图片的 OCR 支持:
• 拉丁文(约 50 种语言)、西里尔文、希腊文、天城文、孟加拉文 • 简体和繁体中文
读不了的:日文、韩文、阿拉伯文、泰文的扫描件,还有竖排文字(比如繁体中文报纸那种)。
X 上 @Gorden_Sun 也说它处理不了复杂表格和手写(原帖),和官方自报的手写弱项对得上。
怎么装
需要 Python 3.10 及以上:
pip install indra-ocr谁可以试、谁先不用管
简单说:手里有大量拉丁文或中文印刷体的 PDF、只有 CPU、想把 OCR 塞进 RAG 或文档解析管线的,可以去试试;要处理复杂表格、手写、日韩文或竖排的,先不用管,现在它不擅长这些。王先生的建议是,别只看”快 11 倍”,拿你自己的文档在你自己的机器上跑一遍再决定。
王先生平时用的是 MinerU。这次没把两者放在一起比准确率,所以先不下谁更好的结论,后面有机会再拿同一批文档对一对。
还有一点要提醒:代码是 Apache-2.0,但模型权重用的是修改版 OpenRAIL-M,研究、个人使用和融资或营收低于 2000 万美元的初创公司可以免费用,不能用来和 Datalab 的 API 竞争,更大规模的商用要另外买授权。准备放进自己产品里的,先把许可证看完。
项目地址再贴一次:
- GitHub:https://github.com/datalab-to/indra
- Hugging Face:https://huggingface.co/datalab-to/indra-ocr
你现在做文档解析用的是什么 OCR 方案?评论区聊聊,王先生也想抄抄作业。
今天就简单说到这儿,王先生下篇见。