MinerU on 海光 Z100

报告不把不同档位、不同冷热状态和不同页数混成一个“速度排名”。

• 冷态：新进程，包含 import、模型加载和首次执行。
• 暖态：同一进程复用已加载模型。
• Flash 与 Basic/pipeline 质量不同，不直接比较质量等价吞吐。

统一运行时闭包

CentOS 7 的 glibc 2.17 无法直接加载部分 wheel。两套环境都复用同一个原则：

module purge
module load compiler/gcc/12.2.0 compiler/dtk/26.04

<GLIBC_2_28_LD_SO> \
  --library-path "<GLIBC_LIB>:<GCC_LIB>:<DTK_LIBS>:<SYSTEM_LIBS>" \
  <VENV>/bin/python "$@"

sitecustomize.py 同时把 multiprocessing spawn worker 指向该 launcher，避免子进程掉回系统 glibc。

3.4.4 的价值不在“版本旧”，而在已经完成质量、稳态吞吐、背压、重试和故障恢复验证。

4.0.7 使用独立 venv、模型目录和配置，不覆盖 3.4.4。新版以 tier 表达质量，以 small_backend 和 vlm.engine 表达实际引擎。

实验环境配置

MinerU             4.0.7
DocVortex          0.5.1
ONNX Runtime       1.20.1
Torch              2.7.1 + DTK 26.04
torchvision        0.22.0 + DTK 26.04
Transformers       5.17.0
NumPy              1.26.4
OpenCV             4.11.0

官方 llama.cpp Linux wheel 要求 glibc 2.34，当前用户态运行时仅到 2.28。 Standard / Advanced 因此使用隔离补丁暴露源码中已有的 Transformers backend。

性能瓶颈不是单页算子，而是“每个任务新建 Python + 加载全部模型”。

ONNX Runtime CPU 线程配置

Torch / Z100

同一 GOC PDF、第 1–2 页、8 CPU、27 GB；DCU 路径均使用 1 张 Z100。

• CPU 模型阶段几乎不变；4.0.7 冷启动优势来自 import、预处理和输出链。
• DCU 冷态 4.0.7 更慢，但暖态降到 2.64 秒 / 2 页。
• 跨版本输出协议不同，因此总耗时是应用级比较，不是纯 kernel benchmark。

适配器实现

# 3.4.4
mineru-drop push <PDF_OR_DIRECTORY>

# 4.0.7
mineru-drop --remote-root mineru4-drop push <PDF_OR_DIRECTORY>

# 通用
mineru-drop [--remote-root ...] status --batch <BATCH_ID>
mineru-drop [--remote-root ...] retry  --batch <BATCH_ID>
mineru-drop [--remote-root ...] fetch  --batch <BATCH_ID>

长文档默认 128 页以内整篇，超过后按 96 页分块。少量长文档优先 1 个 worker， 避免多个 worker 各自承担一次模型冷启动；大量文档再扩到 4 个 worker。

推荐路由

原生文本，只需索引        → 4.0.7 Flash
需要最终 Markdown / JSON  → 3.4.4 pipeline
必须使用 4.x schema       → 4.0.7 Basic
极复杂页面、人工复核      → Standard / Advanced

最小复现约束

• 登录节点准备依赖和模型；计算节点离线运行。
• module 必须在 venv 之前加载。
• 主进程与 spawn 子进程必须共用 glibc 2.28 launcher。
• Slurm 脚本必须传递真实工作负载退出码。
• 4.0.7 ONNX Runtime 1.20.1 使用重打标签 wheel，只能在外部 glibc 2.28 下运行。

已知限制