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

这一切始于我需要一个可以高效运行在我的4090笔记本GPU上的快速OCR替代品。我需要一个可以日复一日在后台运行纯粹在本地处理一批客户文档直到全部完成的东西。我需要一个可以提供文字、格式、表格和图片就像90%需要OCR的人一样的东西。我不需要每个单词的确切坐标但我需要OCR快速且准确。所以……我开始准备我感兴趣的OCR模型清单并开始开发一些快速简陋的基准测试和实现。1、许可证的坟场在写一行推理代码之前我必须精简候选名单。而砍刀不是技术性的它是法律性的。最好的开源OCR模型很少是真正开源的。像一半的模型实际上并不是以任何有意义的方式开源。它们是GPL-3.0或AGPL-3.0这意味着一旦你将它们集成到产品中你的整个代码库就受到copyleft义务的约束。我的决定淘汰名单很残酷MarkerPDF转markdownGPL-3.0。出局。SuryaOCR 布局GPL-3.0。出局。MinerU2.5常规自回归版本AGPL-3.0。出局。GLM-OCR依赖API需要云端密钥。出局。PaddleOCRApache 2.0这很好但没有布局检测。它只提取文本。就这样。没有表格没有结构不理解什么是标题什么是脚注。出局。GOT-OCR2Apache 2.0学术上有趣但社区采用率低没有令人信服的理由将其包含在其他人之上。出局。DoclingIBMMIT许可证实际上是宽松的但它试图做所有事情PDF、DOCX、PPTX、XLSX、HTML、图片、LaTeX。太臃肿了。当目标不是我赢而是你输的时候Docling试图在所有方面都赢却没有优化任何方面。顺便说我喜欢docling……但现在出局。幸存下来的四种具有真正宽松许可证MIT或Apache 2.0并且有足够技术含量值得基准测试的方法。2、四位竞争者以下是入选的内容MinerU-Diffusion25亿参数MIT扩散解码器。它不是从左到右生成token而是掩蔽一切然后根据置信度分数迭代地解掩蔽。使用一个名为nano_dvlm的自定义引擎一个专为该模型的块级扩散去噪构建的轻量级vLLM类似实现。不能在标准vLLM上运行因为解码策略与自回归生成根本不同。LightOnOCR10亿参数Apache 2.0黑马。最新的新人。一个小型模型声称在OlmOCR-Bench上达到最先进的准确度同时比Chandra小9倍。标准自回归解码器可以在原版vLLM上运行。有一个bbox变体可以输出嵌入图片的边界框。LiteParseMIT根本不是一个模型。一个基于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笔记本GPU16GB显存。不是数据中心里的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-Diffusion2.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完美地做到了trtd哮喘/td/tr trtd● 是 ○ 否/td/tr trtd慢性咳嗽/td/tr trtd○ 是 ● 否/td/tr它正确区分了填充圆圈●和空圆圈○在一个扫描的、编辑过的医疗表格上。模型理解这是一个表格将其表示为表格并保留了每个复选框状态的语义意义。这真的不是你期望从一个1B模型得到的。但我们就在这里。7、表格测试学术论文有表格。复杂的表格有合并单元格、下标、上标和脚注。arxiv论文的一页有一个14行的比较表带有跨多个方法类别的rowspan单元格。LightOnOCR生成了一个完整的HTML表格带有正确的thead、tbody、tr、td rowspan2每个数字都正确。表格在浏览器中完美呈现。每列对齐。每个小数点到位。相比之下MinerU-Diffusion以OTSL开放表格结构语言输出表格fcel、ecel、lceltoken需要后处理才能变成可用的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 transformers5.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。我不得不安装fnmNode版本管理器安装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-tools13、那么你实际应该用什么这是我的观点。你应该做你舒服的事情。如果你需要从文档中快速、准确地提取文本不关心布局坐标LightOnOCR。它是最小的模型最快的模型产生最干净的输出。通过vLLM在Docker容器中提供服务然后继续你的生活。如果你需要页面上每个块的布局坐标文本、表格、图表、方程MinerU-Diffusion用于布局检测步骤然后将裁剪的块传给LightOnOCR进行实际文本提取。两全其美。如果你处理原生文本PDF不是扫描图片并需要亚秒级延迟LiteParse。它不是在传统意义上做OCR它是在读取PDF的嵌入文本。当文本存在时没有什么比它更快。如果你在看Chandra等待他们的vLLM服务器部署成熟或者使用更大的GPU。该模型有潜力完整的布局检测每个块都有边界框但HuggingFace本地推理路径在66秒/页上还不适合生产。如果你即将将其中任何一个集成到产品中先检查许可证。一半的OCR生态系统是GPL-3.0。另一半才真正可用。原文链接4个最强本地OCR模型实测对比 - 汇智网