4个最强本地OCR模型实测对比

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI工具导航 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

这一切始于我需要一个可以高效运行在我的4090笔记本GPU上的快速OCR替代品。我需要一个可以日复一日在后台运行，纯粹在本地处理一批客户文档直到全部完成的东西。我需要一个可以提供文字、格式、表格和图片（就像90%需要OCR的人一样）的东西。我不需要每个单词的确切坐标，但我需要OCR快速且准确。

所以……我开始准备我感兴趣的OCR模型清单，并开始开发一些快速简陋的基准测试和实现。

1、许可证的坟场

在写一行推理代码之前，我必须精简候选名单。而砍刀不是技术性的；它是法律性的。

最好的开源OCR模型很少是真正开源的。像一半的模型实际上并不是以任何有意义的方式开源。它们是GPL-3.0或AGPL-3.0，这意味着一旦你将它们集成到产品中，你的整个代码库就受到copyleft义务的约束。

我的决定：淘汰名单很残酷

• Marker（PDF转markdown）：GPL-3.0。出局。
• Surya（OCR + 布局）：GPL-3.0。出局。
• MinerU 2.5（常规自回归版本）：AGPL-3.0。出局。
• GLM-OCR：依赖API，需要云端密钥。出局。
• PaddleOCR：Apache 2.0，这很好，但没有布局检测。它只提取文本。就这样。没有表格，没有结构，不理解什么是标题什么是脚注。出局。
• GOT-OCR2：Apache 2.0，学术上有趣，但社区采用率低，没有令人信服的理由将其包含在其他人之上。出局。
• Docling（IBM）：MIT许可证，实际上是宽松的，但它试图做所有事情：PDF、DOCX、PPTX、XLSX、HTML、图片、LaTeX。太臃肿了。当目标不是我赢，而是你输的时候；Docling试图在所有方面都赢，却没有优化任何方面。顺便说我喜欢docling……但现在出局。

幸存下来的：四种具有真正宽松许可证（MIT或Apache 2.0）并且有足够技术含量值得基准测试的方法。

2、四位竞争者

以下是入选的内容：

MinerU-Diffusion（25亿参数，MIT）：

扩散解码器。它不是从左到右生成token，而是掩蔽一切，然后根据置信度分数迭代地解掩蔽。使用一个名为nano_dvlm的自定义引擎（一个专为该模型的块级扩散去噪构建的轻量级vLLM类似实现）。不能在标准vLLM上运行，因为解码策略与自回归生成根本不同。

LightOnOCR（10亿参数，Apache 2.0）：

黑马。最新的新人。一个小型模型，声称在OlmOCR-Bench上达到最先进的准确度，同时比Chandra小9倍。标准自回归解码器；可以在原版vLLM上运行。有一个bbox变体，可以输出嵌入图片的边界框。

LiteParse（MIT）：

根本不是一个模型。一个基于Node.js的PDF文本提取器，带有可选的Tesseract OCR回退用于图片密集页面。当可用时直接从PDF的内部结构提取文本，不可用时回退到OCR。需要Node.js，这很烦人，但Python包装器使其可以忍受。我以为可以用它作为第一遍来处理带有嵌入XML数据的PDF。简单快速的提取。

Chandra（约30亿参数，Apache 2.0）：

来自制作Surya和Marker的同一团队（datalab-to）。完整的布局检测，每个块都有边界框。输出markdown、HTML和结构化块。可以通过HuggingFace transformers本地运行，也可以通过vLLM服务器运行。

3、设置竞技场

测试环境：

单个NVIDIA RTX 4090笔记本GPU，16GB显存。不是数据中心里的H100。不是多GPU设备。一台笔记本。这很重要，因为大多数基准测试都是在实际没人使用的硬件上运行的。

每种方法接收相同的输入：

PDF页面以200 DPI渲染，最长维度限制在1540px。这种标准化很关键。如果你让一种方法以300 DPI渲染，另一种以150 DPI渲染，你不是在比较模型；你是在比较预处理流水线。

测试文档：

扫描的医疗记录（30页编辑过的诊所笔记、入院表格、药物清单、手术史）和一篇来自arxiv的学术论文（33页双栏布局、表格、LaTeX方程、图表）。

医疗记录是OCR最坏的情况。从纸上扫描。编辑栏覆盖患者数据。小字体。混合布局：有时是带复选框的结构化表格，有时是自由文本临床笔记，有时是药物表格。如果它在这里有效，它就到处有效。

4、MinerU-Diffusion实际上如何解码？

在看数字之前，快速了解一下为什么MinerU-Diffusion在架构上很有趣。这不是通常的transformer生成token的故事。

传统的OCR模型从左到右生成文本：

预测token 1，反馈回去，预测token 2，两者都反馈回去，预测token 3。顺序的。慢的。如果token 47错了，token 48到200可能也错了，因为它们基于一个错误的条件。

MinerU-Diffusion做了不同的事情。它从一个32个掩蔽token的块开始。每个位置都是未知的。然后它运行模型，同时获得每个位置的置信度分数，解掩蔽高置信度位置，在更新后的序列上重新运行模型。重复直到一切都被解掩蔽。

就像填纵横字谜，你先做简单的线索，然后用那些字母解决更难的。并行、迭代、自我纠正。

但总有一个但是。

标准的vLLM推理服务器不知道如何处理这个。vLLM期望自回归解码：一次一个token，从左到右，KV缓存单调增长。扩散解码需要自定义掩蔽逻辑、重新掩蔽策略、置信度阈值和块级去噪循环。这些在标准vLLM中都不存在。

所以MinerU-Diffusion附带了自己的引擎nano_dvlm，一个实现扩散特定采样逻辑的精简推理引擎。它有批处理、KV缓存和调度器，但这是自定义代码。这意味着你不能只是vllm serve就完事。

5、3.7秒能买到什么？

现在是重头戏。

四种方法，同一份扫描的医疗记录，第一页。一个密集的入院表格，包含诊所标题、预约原因、药物清单、手术史和家族史。

速度：

LightOnOCR，那个1B模型，是最快的基于GPU的方法。比MinerU-Diffusion（2.5B）快近3倍，比Chandra（~3B）快18倍。在笔记本GPU上。GPU利用率只有26%，意味着它甚至没有全力以赴。

哦！

但如果输出是垃圾，速度毫无意义。让我们看看每个模型实际产生了什么。

LightOnOCR输出：

### 预约原因

1. 交通事故：2025年10月11日
2. 随访：颈椎、腰椎
3. 患者今天在[已编辑]医疗中心、[已编辑]办公室接受治疗。

### 当前用药

**服用中**
- 环苯扎林HCl 10毫克片剂 1片 睡前需要时 口服 每天一次
- 美他沙酮800毫克片剂 1片 口服 每天三次
- 加巴喷丁400毫克胶囊 1粒 口服 每天一次

干净的markdown。正确的标题。项目符号列表。没有重复。每个药物名称拼写正确。编辑字段干净地标记为[已编辑]。

MinerU-Diffusion输出（同一页）：

当前用药
服用中
- 环苯扎林HCI 10毫克片剂 1片 睡前需要时 口服 每天一次
• 美他沙酮800毫克片剂 1片 口服 每天三次
...
• Nab nonprofitsone 750毫克片剂 按指示 口服

两个问题立即跳出来。首先，"Nab nonprofitsone"应该是"Nabumetone"（萘丁美酮）。那是幻觉。那个2.5B扩散模型看着扫描文本，被字体渲染搞糊涂了，发明了一个不存在的词。在医疗记录里。药物名称很重要的地方。

其次，整个药物清单出现了两次。模型将同一内容区域检测为两个独立的布局块，并分别提取了它。

LiteParse输出（同一页）：

+ 环苯扎林HCI 10毫克片剂 1片 睡前需要时 口服 每天一次
        800毫克片剂 1片 口服 每天三次
+ 加巴喷丁400毫克胶囊 1粒 口服 每天一次

原始的空间文本。用+符号代替项目符号。"美他沙酮"完全缺失，因为文本提取在那一行失败了。缩进保留了页面的物理布局，这很忠实但没有后处理就无法使用。

Chandra输出：

捕获了页面完全不同的部分（生命体征、检查发现、带ICD代码的评估），同时漏掉了整个上半部分。每页66秒，它不只是慢；它在读什么上也不可靠。

6、单选按钮和1B的优势

这是真正让我惊讶的发现。医疗记录页面上有一个入院表格，带有检查表："既往病史"后跟25+种情况，每个都有填充或未填充的单选按钮表示是或否。

LightOnOCR完美地做到了：

<tr><td>哮喘</td></tr>
<tr><td>● 是 ○ 否</td></tr>
<tr><td>慢性咳嗽</td></tr>
<tr><td>○ 是 ● 否</td></tr>

它正确区分了填充圆圈（●）和空圆圈（○），在一个扫描的、编辑过的医疗表格上。模型理解这是一个表格，将其表示为表格，并保留了每个复选框状态的语义意义。

这真的不是你期望从一个1B模型得到的。但我们就在这里。

7、表格测试

学术论文有表格。复杂的表格，有合并单元格、下标、上标和脚注。arxiv论文的一页有一个14行的比较表，带有跨多个方法类别的rowspan单元格。

LightOnOCR生成了一个完整的HTML表格，带有正确的<thead>、<tbody>、<tr>、<td rowspan="2">，每个数字都正确。表格在浏览器中完美呈现。每列对齐。每个小数点到位。

相比之下，MinerU-Diffusion以OTSL（开放表格结构语言）输出表格：<fcel>、<ecel>、<lcel> token，需要后处理才能变成可用的HTML。技术上正确但需要一个LightOnOCR不需要的转换步骤。

8、布局坐标呢？

这是MinerU-Diffusion真正擅长而LightOnOCR不足的一个领域。

MinerU-Diffusion运行两阶段流水线：

首先，布局检测为页面上的每个块（文本、表格、方程、页眉、页脚、图片）生成边界框。然后，为每个检测到的块提取内容。你得到一切的坐标。

LightOnOCR的bbox变体

Bbox变体只为嵌入的图片和图表输出坐标。文本块、表格、标题？没有坐标。文本被美妙地提取出来，但你不知道它在页面的哪里。

如果你的下游流水线需要将提取的文本链接回特定页面区域（用于文档理解、空间推理或视觉接地），MinerU-Diffusion的布局检测在这四种方法中是无与伦比的。如果你只需要文本，LightOnOCR胜出。

9、vLLM冒险

让LightOnOCR通过vLLM运行是它自己的传奇。模型太新了，稳定的vLLM Docker镜像（0.11.0）从未听说过LightOnOCRForConditionalGeneration。不在它的模型注册表中。甚至通过通用的TransformersForMultimodalLM回退也不行。但我认为那是我的错。使用过时的vLLM（在我过去2年的其他工作流中一直运行，因为"没坏就别修"的心态）。

解决方法：拉取最新的Docker镜像（0.18.0），构建一个自定义Dockerfile强制升级transformers到5.4.0，然后它就能工作了。一个Dockerfile，三行：

FROM vllm/vllm-openai:latest
RUN pip install --no-cache-dir --force-reinstall "transformers>=5.4.0"

另一方面，MinerU-Diffusion永远不能使用标准vLLM。它的扩散解码需要自定义的nano_dvlm引擎。句号。这不是临时限制；这是架构性的。只要模型使用块级掩蔽去噪而不是自回归token生成，标准vLLM就永远不会支持它。

10、大规模吞吐量

单页基准测试对延迟比较有用。但处理30+页呢？我决定只比较两个主要竞争者。LightOnOCR和Miner-U-diffusion bbox。

LightOnOCR处理30页扫描医疗记录：

总共203秒（平均每页6.8秒）。大多数页面花3-5秒。四页有密集表格的页面飙升到23-25秒，可能达到了最大token限制。

LightOnOCR处理33页学术论文：

总共143秒（平均每页4.3秒）。更干净的布局和更少的视觉伪差意味着整体处理更快。

作为背景，MinerU-Diffusion（批处理）在相同的医疗记录上平均10.5秒/页；大约慢2倍。这是在启用批处理优化的情况下。没有它，你看到的是15.6秒/页。

11、怪癖

每个模型都有。以下是亮点：

MinerU-Diffusion在一页上幻觉出了俄语文本。字符串"St эксперт"出现在输出中，而应该是"Stabbing"。模型的训练数据显然包括了俄语医疗文档，当视觉信号模糊（微小的扫描文本）时，它调用了错误的语言模型先验。

LightOnOCR忠实地转录了从EHR系统打印的页面页脚中嵌入的file:///C:/Users/路径。这对OCR工具来说是正确行为：转录你看到的。但这意味着你需要后处理来过滤水印和打印伪差。

LiteParse需要Node.js。在2026年。对于一个Python项目。Python包装器通过子进程调用Node.js CLI。我不得不安装fnm（Node版本管理器），安装Node 22，全局安装npm包，然后在脚本中配置PATH检测，这样Python才能找到lit二进制文件。它作为原型工作了；然后一切崩溃了！（实际上它工作得不错，但设置很痛苦。）

Chandra将一个约3B的模型加载到GPU内存中，在单页上运行推理66秒，只捕获了一半的页面内容。HuggingFace本地后端显然不是预期的部署路径；他们期望你使用他们的vLLM服务器。但在单个16GB GPU上，你无论如何都无法运行他们的vLLM服务器并获得像样的吞吐量。

12、不是大小的问题，是训练数据的问题

真正的故事不是1B模型击败了2.5B模型。这经常发生。真正的故事是如何击败的。

LightOnOCR不只是更快地提取文本。它产生了结构上更优的输出：正确的markdown层次结构、清晰的标题级别、正确呈现的表格结构、保留语义意义的表单元素。一个1B模型不应该知道●表示"选中"，○表示"未选中"在一个扫描的入院表格上。但它知道，因为训练数据和训练后的RLVR（可验证奖励的强化学习）正好专注于这些文档理解任务。

MinerU-Diffusion的并行扩散解码确实是创新的。在架构上，它比这个比较中的任何其他东西都更有趣。但如果模型在扫描的医疗记录上幻觉药物名称，解码器的创新就没有帮助。解码器不是瓶颈；视觉编码器和训练数据才是。

代码在这个仓库 https://github.com/mandar-karhade/OCR-tools

13、那么你实际应该用什么？

这是我的观点。你应该做你舒服的事情。

• 如果你需要从文档中快速、准确地提取文本，不关心布局坐标：LightOnOCR。它是最小的模型，最快的模型，产生最干净的输出。通过vLLM在Docker容器中提供服务，然后继续你的生活。
• 如果你需要页面上每个块的布局坐标（文本、表格、图表、方程）：MinerU-Diffusion用于布局检测步骤，然后将裁剪的块传给LightOnOCR进行实际文本提取。两全其美。
• 如果你处理原生文本PDF（不是扫描图片）并需要亚秒级延迟：LiteParse。它不是在传统意义上做OCR；它是在读取PDF的嵌入文本。当文本存在时，没有什么比它更快。
• 如果你在看Chandra：等待他们的vLLM服务器部署成熟，或者使用更大的GPU。该模型有潜力（完整的布局检测，每个块都有边界框），但HuggingFace本地推理路径在66秒/页上还不适合生产。
• 如果你即将将其中任何一个集成到产品中，先检查许可证。一半的OCR生态系统是GPL-3.0。另一半才真正可用。

原文链接: Which Small vLLM OCR Model Is the Best For Private Use in 2026?

汇智网翻译整理，转载请标明出处