AREX Feed Article
Indra OCR 1.1 发布：1M 参数主模型在 32 核 CPU 上约 44 页/秒，Paruchuri 称与 3.4B 参数的 DeepSeek-OCR-2 相差 4 分以内
10 月 19 日 16:18 UTC（北京时间 10 月 20 日 0:18），Datalab 创始人 Vik Paruchuri 在 X 上宣布 Indra OCR 1.1 发布。帖子列了四条：1M 参数的主 OCR 模型、CPU 上 44 页/秒；在 OmniParseBench 上与 3.4B 参数的 DeepSeek-OCR-2 相差 4 分以内；比 Tesseract 快 15 倍且更准；80+ 语言和手写支持。
Datalab 的 1.1 博客给出了更细的数字：44 页/秒是在 32 核 x86、无 GPU 的机器上跑 300 张 OmniParseBench 页面得到的 43.9 页/秒；默认模式的总分是 66.7，开启 --math 后是 71.4。 OmniParseBench 的公开数据卡片把 DeepSeek-OCR-2 列为 75.2；把 1.1 的两个分数分别与它相减，71.4 差 3.8 分，66.7 差 8.5 分。 也就是说，按这组公开数字，能落进「4 分以内」的是 --math 模式的 71.4，而 --math 默认关闭。这些基准分数都来自 Datalab 自己的运行；本文引用的 1.1 数据均出自 Datalab。
44 页/秒是在 32 核、无 GPU 的机器上测的
Datalab 的测法是：同一台 x86 机器（AMD EPYC Genoa）、没有 GPU、300 张 OmniParseBench 页面、OCR 模式、每个核心一个单线程工作进程。32 核时 Indra OCR 1.1 跑到 43.9 页/秒，4 核 6.2、8 核 11.9、16 核 23.7。Tesseract 5 在同一台机器上是 2.92 页/秒，PaddleOCR 的 PP-OCR 文本模型是 4.28 页/秒，于是有了 15 倍和 10 倍的说法。
图上就是这组对比：Indra 43.9 页/秒，Tesseract 2.9，PaddleOCR 4.3，PaddleOCR 的完整文档管线 PP-StructureV3 不超过 0.18。图表由 Datalab 发布，数据也是 Datalab 自己跑的。
44 页/秒是这种机器和这种页面集上的数字。Datalab 的 README 还说明：在其他 x86 容器类型上，32 核实测是 25～51 页/秒；同一份代码的中位延迟在不同运行之间还会差约 15%。单页延迟则是另一组数：4 个 vCPU（虚拟核）上一页中位 212 毫秒，开 --math 后 357 毫秒。
「更准」也要看口径：在 Datalab 的 OmniParseBench 文本分上，Indra 46.7，Tesseract 19.3；但 Tesseract 只输出行，不输出表格和版面，所以它的 headline 是空的，不能和 Indra 的 66.7 直接比。15 倍是吞吐比，不是精度比。
「4 分以内」对应的是默认关闭的 --math
1.1 的博客给出一张 1.0 对 1.1 的表：headline（总分）从 62.3 升到 66.7，开 --math 从 67.0 升到 71.4；文本分从 41.4 升到 46.7，表格从 56.3 升到 61.1，版面从 89.1 升到 92.2。--math 默认关闭；它先用一个小分类器找出含数学的行，再用第二个识别器写成带 LaTeX 的文本。代价是慢：4 个 vCPU 上一页 357 毫秒，比默认的 212 毫秒多约七成；32 核吞吐下降约 38%。表格分还会从 61.1 降到 59.6，因为表格里的一些数字被当成数学读了。
OmniParseBench 是 Datalab 自己做的基准：16,288 个通过/不通过测试，覆盖 2,937 页、2,343 份文档、92 种语言；headline 是文本、表格、版面三类测试的平均。数据集和评分器公开，可以复跑。DeepSeek-OCR-2 的模型卡标的是 3.39B 参数。 数据卡片把它列为 75.2 的 headline，文本 64.2、表格 70.0、版面 91.4；卡片还注明，开放权重模型是在各自的主机上、按厂商推荐的默认设置跑的，Indra 那一行跑在 CPU 上。
所以 44 页/秒和「4 分以内」不是同一配置：前者是默认 OCR 模式，后者要用更慢的 --math。两组分数来自 Datalab 的不同页面，未必是同一次运行，不能当成一次严格的同条件对比；但它们是发布帖之外目前可公开核对的口径。
手写通过率 25.2%，80+ 语言的分数并不齐
1.0 是 10 月 13 日发布的（GitHub 上的版本号是 0.3.x），当时的发布重点是 49 页/秒、纯印刷体、没有手写；六天后，1.1 的增量包括手写、语言覆盖和任意角度。 1.0 不读手写，1.1 在 OmniParseBench 的手写测试上从 8.3% 升到 25.2%；博客展示了一封连笔信，说 1.0 把它读成一张碎片表格，1.1 能读出每个词。但 25.2% 意味着约四分之三的手写测试仍没过；Datalab 自己在 README 里写得更直白：手写页能读，但读得不好，在留出的手写页上大约只能对三分之一的词，连笔和浅铅笔最差。
图上这封连笔信是 Datalab 用来展示 1.1 手写能力的样本；它说明的是清晰连笔的个例，不是 25.2% 的总体通过率。
语言方面，1.0 只能 OCR 拉丁、西里尔、希腊、天城文、孟加拉文和中文；1.1 把阿拉伯、希伯来、日文、韩文、泰文、老挝文、高棉文、缅甸文、僧伽罗文、印度各脚本、格鲁吉亚文、亚美尼亚文和埃塞俄比亚文加进了扫描件识别。Datalab 在 95 种语言的留出印刷页上测了字符 F1（越高越好）：83 种达到 0.90 以上，67 种达到 0.95 以上。分脚本看，提升很大但高低不平：希伯来文 26.7→80.0（30 个测试）、泰文 28.2→87.2（39 个）、亚美尼亚文 46.7→100（60 个）、希腊文 44.2→55.8（104 个）、马拉雅拉姆文 37.5→65.0（40 个）。测试少的脚本，一个测试就能让分数动 2～8 分，Datalab 自己在博客里也这么提醒。
「任意角度」也有类似的限制：1.1 能把最多 45 度的倾斜页拉直，把横放和倒放的页转正；OmniParseBench 的旋转测试从 25.3% 升到 50.3%，大约一半仍未过。复杂表格、老旧扫描和变音符号仍在限制清单里：合并单元格、多级表头会丢结构；退化扫描测试 29.5%；捷克语、土耳其语、库尔德语（Kurmanji）等变音符号多的语言，可能把某个字母写成相近的变音符号。
中文方面，Datalab 在 OmniDocBench 的 1,651 页中英文页面上测了 OCR 模式：中文文本编辑距离（越低越好）从 0.292 降到 0.237，英文从 0.110 升到 0.114，略差；表格 TEDS（表格结构相似度）从 0.436 升到 0.466；被误判为表格的中文页从 493 页里的 129 页降到 89 页。
1M 是主识别器，整条默认流水线 7.3M
Paruchuri 的「1M 参数」指的是主识别模型。Datalab 的 README 写得更细：主识别器 rec.onnx 约 1.25M 参数，所有默认模型加起来 7.3M；默认下载约 76 MB，其中 30 MB 是网络、46 MB 是给不确定行做二次判断的语言模型。可选的数学模型另算。对比之下，DeepSeek-OCR-2 是 3.39B 参数。「1M」不是整条管线的参数总量，发布帖的措辞是「main OCR model」，严格说没有错。
整条流水线跑在 ONNX Runtime 上，不依赖 PyTorch，也不需要 GPU；pip install indra-ocr 后第一次运行会从 Hugging Face 下载模型。它先做行检测和版面分块，再由一个行分类器把每行送到四个识别器之一：拉丁/西里尔/希腊/手写的 rec.onnx、中日韩的 rec_cjk.onnx、阿拉伯/希伯来等的 rec_rtl.onnx、以及印度各脚本和东南亚脚本的 rec_world.onnx；不确定的行再交给语言模型复读。数字版 PDF 如果文本层通过检查，就直接读文本层，只对缺的部分做 OCR。
输出可以是 markdown、纯文本或 JSON；JSON 里带每行的框、置信度、版面块的标签和阅读顺序、每页的耗时。命令行工具（CLI）和本地 viewer（查看器）都在包里，viewer 会把框和阅读顺序画在页面上。
代码是 Apache 2.0；权重是修改过的 OpenRAIL-M：研究、个人使用、融资或营收低于 2,000 万美元的初创公司免费，但不能用于与 Datalab 的 API 竞争，超出这些范围需要商业授权。所以「开源发布」在代码层面成立，在权重层面是有条件的。
公告 18 分钟后的 1.1.1
1.1.0 的 GitHub 发布页时间是 10 月 19 日 14:49 UTC；Paruchuri 的帖子是 16:18 UTC；1.1.1 在 16:36 UTC 发出，离帖子 18 分钟，离 1.1.0 不到两小时。 这个修复对应 GitHub issue #11：10 月 19 日 00:02 UTC 提交，报告 indra-ocr 0.3.2 在默认 auto 模式下把 Chrome 打印的阿拉伯语文本层读成字母倒序，而且每行置信度还是 1.0，输出里看不出问题；issue 在 16:44 UTC 关闭。
1.1.1 没有换模型，主要改了文本层的信任逻辑。根据，有些 PDF 生产者（包括 Chrome）会把阿拉伯字母部分按视觉顺序存储，文本层读出来就是字母倒序；1.1.1 不再信任这种文本层，转去 OCR 页面。Datalab 给出的 Chrome 打印页词召回率从 0.17 升到 1.00（阿拉伯语）、0.25 升到 0.89（波斯语）、0.22 升到 0.95（普什图语）、0.28 升到 0.98（乌尔都语）。