在之前的文章的评论区里，有人建议试一试MinerU。其实在去年7月MinerU刚发布的时候，我就尝试过，但是印象中效果非常差，根本没法实际使用。

正好我的电脑里还存有当时配置好的虚拟环境，又重新试了一下，结果印证了我的记忆。由于问题实在太多，我就不放截图了，只是罗列一下它的问题：

• 完全不能识别公式中的汉字
• 所有多行公式无法换行
• 经常漏识别公式的一部分（如最后的字母、特殊符号如平行等）
• 经常无法识别分式
• 偶尔会漏识别公式
• 经常识别不出特殊符号（如相似）
• 偶尔识别错误字母（例如p识别成Φ）
• 中英文混合的情况，不能识别英文之间的空格
• 偶尔汉字识别错误
• 偶尔公式后面多出东西（把公式的一部分重复识别成了文字）
• 偶尔多行公式排版错误（$$后不换行直接跟文字）
• 偶尔行间公式排版错误（错误使用\$）
• 经常错误识别标点符号（例如逗号识别成双引号），经常漏识别标点符号

这些问题导致识别得到的结果错误非常多，已经到了不可用的地步。

不过看官方仓库里的说明，新版的MinerU使用vLLM部署之后能有90+的准确率，我决定再试一下。

由于使用vLLM部署比pipeline模式的准确率高很多，加之8G显存够用了，因此我直接使用vLLM方式进行部署。

安装也很简单：

1
2

uv venv --seed --python python3.13
uv pip install "mineru[all]"

此时的MinerU版本是2.6.4

接下来就可以使用了：

1

uv run mineru -p input/test.pdf -o output -b vlm-vllm-engine

进一步的配置选项可以参看官方选项，默认配置对于我来说就可以使用了。

这样临时使用一下还可以，但如果要大量文件需要识别，每次都会花大量时间在模型的加载上。这时可以使用server模式进行部署和调用。首先运行vllm-server：

1

uv run mineru-vllm-server

然后在另一个终端里运行

1

uv run mineru -p input/test.pdf -o output -b vlm-http-client -u http://localhost:30000

即可。

2. 和PaddleOCR-VL的对比

在下面的对比图片中，左侧是MinerU的结果，右侧是PaddleOCR-VL的结果。

2.1. 速度

同样是识别小蓝本（共8本），耗时33分21秒，比PaddleOCR-VL慢了约17%。

2.2. 优势

MinerU没有出现PaddleOCR-VL中的公式错行现象，基本上能够正确识别公式的位置。

另外，MinerU对于特殊数学符号（如平行、相似等）的识别准确率要高于PaddleOCR-VL和DeepSeek-OCR。

2.3. 劣势

虽然最新的MinerU和最初的版本相比，前面列出的问题大部分都得到了解决，但是还有一部分被部分继承了下来。

例如，简单的文字识别错误：

简单的字母识别错误：

简单的标点识别错误：

另外，MinerU还出现了图片分割不准确的情况：

这个问题PaddleOCR-VL和DeepSeek-OCR从来没有出现过。

2.4. 共同的问题

MinerU和PaddleOCR-VL都在同一类地方栽了。类似下图，

识别的结果如下：

可以看到，二者都不能正确区分题目的序号和公式部分。

而DeepSeek-OCR能够正确处理：

3. 总结

如果让我给这几个OCR模型进行排行的话，大致是

DeepSeek-OCR ≳ MinerU 2.6 (vllm) > PaddleOCR-VL >> PaddleOCR (V3)

DeepSeek-OCR的优势在于排版最好，但是在识别一些复杂公式（如重分式）的时候可能会出问题（感觉是识别之后被改了）。

最大的劣势是模型还是偏大，模型参数本身超过6G，因此我没有办法在本地使用vLLM加速推理，只能使用Transformers进行推理（同时需要借用一部分内存），因此速度相比后两个慢很多。

MinerU的公式识别整体是最好的，但是会犯一些弱智的错误（比如经常识别不了字母p）。

前面两个基本上不分伯仲，关键是看注重哪方面。

PaddleOCR-VL的最大问题在于公式混合排版的输出顺序有问题。

上面两个都可以在本地（8G显存）使用vLLM进行加速，因此速度都是可用的。

PaddleOCR就连基本的退化问题都没有解决。

另外，PaddleOCR对于表格的识别也比PaddleOCR-VL差很多。