MinerU on Hygon Z100

Results from different MinerU modes, warm and Cold run runs, and document lengths are not combined into a single speed ranking.

• Cold run: New process, including import, model loading and first execution.
• Warm: Reuse the loaded model in the same process.
• Flash and Basic/pipeline provide different output quality, so their throughput is not compared as if the results were quality-equivalent.

3.1 Unified runtime entry point

CentOS 7's glibc 2.17 cannot directly load some wheels. Both environments reuse the same principle:

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 also directs multiprocessing spawn workers through the same launcher, preventing child processes from falling back to the system glibc.

The case for 3.4.4 rests on completed validation of output quality, steady-state throughput, backpressure, retries, and failure recovery—not simply on its being the older version.

MinerU 4.0.7 uses a separate virtual environment, model directory, and configuration; it does not overwrite the 3.4.4 installation. In 4.x, tier specifies the quality level, while small_backend and vlm.engine select the underlying inference engines.

5.1 Experimental environment configuration

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

The official Linux llama.cpp wheel requires glibc 2.34, while this user-space runtime provides glibc 2.28. Standard and Advanced therefore use isolated patches to expose the Transformers backends already present in the source tree.

The performance bottleneck is not the single-page operator, but "create a new Python + load all models for each task".

6.1 ONNX Runtime CPU thread configuration

6.2 Torch on Z100

Both runs use the same document PDF (pages 1–2), 8 CPU cores, and 27 GB of memory. Each DCU run uses one Z100 card.

• CPU model stage is almost unchanged; 4.0.7 cold-start advantage comes from import, preprocessing and output chain.
• DCU the 4.0.7 cold run is slower, but warm drops to 2.64 seconds / 2 pages.
• The versions use different output protocols, so total runtime is an application-level comparison, not a kernel-only benchmark.

9.1 Adapter implementation

# 3.4.4
mineru-drop push <PDF_OR_DIRECTORY>

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

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

Documents of up to 128 pages are processed as one batch; longer documents are split into 96-page chunks. For a small number of long documents, use one worker to avoid repeated model Cold run starts. Scale out to four workers for larger batches.

10.5 Recommended workflow

Native text; indexing only       → 4.0.7 Flash
Final Markdown / JSON required   → 3.4.4 pipeline
4.x schema required              → 4.0.7 Basic
Complex pages; manual review     → Standard / Advanced

11.1 Minimum reproduction requirements

• The login node prepares dependencies and models; the computing node runs offline.
• module must be loaded before venv.
• The main process and the spawn child process must share the glibc 2.28 launcher.
• Slurm scripts must pass real workload exit codes.
• 4.0.7 ONNX Runtime 1.20.1 uses relabeled wheel and can only run under external glibc 2.28.

11.2 Known limitations