MinerU 是一款高精度文档解析工具，支持 PDF、图片、DOCX、PPTX、XLSX 等多种格式。

它有三种解析后端：pipeline、vlm-engine、hybrid-engine。其中 vlm-engine 精度最高，但资源消耗也最夸张——跑一次解析，23GB 系统内存 + 14GB 显存被占满，解析完还不释放。

这篇文章记录 vlm-engine 为什么这么吃资源、其他后端的工作原理、以及什么时候该用哪个。

现象：一次解析拉满 23GB 内存 链接到标题

部署在 GPU 节点（RTX 4060 Ti 16GB）上的 mineru-api 容器，跑了几天后的资源占用：

资源 占用
mineru-api 容器内存 23.2 GiB / 31.34 GiB（74%）
GPU 显存 13.9 GiB / 16.38 GiB（85%）

容器内进程分布：

mineru-api 主进程 (Python):     RSS 15.6 GB
VLLM::EngineCore:               RSS 7.4 GB
multiprocessing fork 子进程:     ~1.5 GB 合计

GPU 上 VLLM 模型占 ~12GB，其余是 llama-server 等共存服务。

VLM 引擎的工作原理 链接到标题

vlm-engine 的处理流程（来自 mineru/backend/vlm/vlm_analyze.py）：

  1. 用 pypdfium2 打开 PDF
  2. 每页渲染为 PIL 图片
  3. 图片批量送入 VLLM 加载的 VLM 模型（MinerU2.5-Pro-2605-1.2B）
  4. 模型做视觉理解：识别布局、图文关系、表格结构
  5. 输出结构化 Markdown（保留阅读顺序）

核心代码路径：

images_list = load_images_from_pdf_doc(
    pdf_doc, start_page_id=window_start, end_page_id=window_end,
    image_type=ImageType.PIL, pdf_bytes=pdf_bytes,
)
images_pil_list = [image_dict["img_pil"] for image_dict in images_list]
window_results = predictor.batch_two_step_extract(
    images=images_pil_list, image_analysis=image_analysis,
)

即使 PDF 是数字版（有内嵌文本），vlm-engine 仍然渲染为图片再识别。这不是传统 OCR（逐字识别），而是 VLM 理解整页布局后生成 Markdown，好处是图文混排保留得好，坏处是每页都要跑一次 VLM 推理。

为什么显存/内存不释放 链接到标题

ModelSingleton 是单例模式，模型加载后永久缓存：

class ModelSingleton:
    _instance = None
    _models = {}

    def get_model(self, backend, model_path, server_url, **kwargs):
        key = (backend, model_path, server_url)
        if key not in self._models:
            vllm_llm = vllm.LLM(**kwargs)  # 加载到显存
            self._models[key] = predictor   # 永不释放
        return self._models[key]

VLLM 本身就是常驻服务设计——模型保持热状态，下次请求直接复用，避免冷启动。要释放只能重启容器：

docker compose restart mineru-api

各文件格式的解析方式 链接到标题

格式 VLM 模式处理方式 资源消耗
PDF（数字版） 每页渲染为图片 → VLM 视觉理解 高
PDF（扫描版/图片版） 同上（自动检测） 高
图片（jpg/png） 直接送入 VLM 高
DOCX 原生解析（不转图片） 低
PPTX 原生解析（3.1.0+） 低
XLSX 原生解析（3.1.0+） 低

Office 文件从 3.0 版本起走独立 office 后端，不经过 VLM，速度比"先转 PDF 再解析"快数十倍。

三种后端对比 链接到标题

pipeline（快速稳定，无幻觉） 链接到标题

使用 CPU + ONNX 运行时做版面检测和 OCR（PP-OCRv6），不加载任何 GPU 模型。资源占用极低，纯 CPU 也能跑。精度在 OmniDocBench v1.5 上达到 86.2 分，超过上一代 VLM 模型。

流程：版面检测 → OCR 文字识别 → 阅读顺序排序 → Markdown 输出。

vlm-engine（最高精度） 链接到标题

通过 VLLM 加载 MinerU2.5-Pro-2605-1.2B 视觉语言模型，每页做视觉理解。精度最高（尤其复杂排版），但需要 ~12GB 显存 + ~23GB 系统内存，速度也最慢。

hybrid-engine（折中方案） 链接到标题

先用原生文本提取（对数字 PDF）或 OCR 获取文字内容，再将复杂部分（表格、公式、图片）交给 VLM 补充理解。精度接近 vlm-engine，资源消耗更低（~7.7GB 显存，无需额外系统内存用于 VLM）。

从 3.3 版本起新增 effort 参数：medium 速度提升 35-220%，high 启用图片/图表分析。

对比总表 链接到标题

特性 pipeline vlm-engine hybrid-engine
GPU 显存 0 ~12 GB ~7.7 GB
系统内存 低 ~23 GB ~15 GB
速度 快 慢（每页跑 VLM） 中
精度 一般 最高 高
适用场景 数字 PDF、纯文本 扫描件、复杂排版 多语言、混合文档

结论 链接到标题

  • 数字版 PDF / 纯文本：用 pipeline，免费、快速、够用
  • 扫描件 / 复杂排版：用 vlm-engine，精度优先
  • Office 文件：自动走原生解析，无需纠结后端
  • 长期运行注意内存，建议定期重启 mineru-api 容器释放缓存