[Question]: what's the difference in MINERU_BACKEND

[ZTurboX]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (Language Policy).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

Describe your problem

I have deploy the mineru with mineru-vllm-server --host 0.0.0.0 --port xxxx and mineru-api --host 0.0.0.0 --port xxx
what's the difference in MINERU_BACKEND=pipeline|vlm-transformers|vlm-vllm-engine|vlm-mlx-engine|vlm-vllm-async-engine|vlm-http-client? And how to select MINERU_BACKEND in pdf parsing ?

[dosubot]

Here’s a breakdown of the MINERU_BACKEND options and how to choose for PDF parsing:

• pipeline: The default. Uses a traditional multimodel pipeline for document parsing, including PDFs. Handles PDF-to-image conversion internally. Good for most local CPU/GPU setups.
• vlm-transformers: Uses HuggingFace Transformers vision-language models. Suitable if you want to leverage transformer-based VLMs for parsing.
• vlm-mlx-engine: Faster, but requires Apple Silicon and macOS 13.5+. Not for Linux or Windows.
• vlm-vllm-engine: Uses a local vLLM engine and requires a local GPU. Only accepts images—if you pass a PDF directly, you’ll get empty output or errors. You must rasterize PDFs to images yourself before processing. No internal PDF-to-image or layout/table reconstruction. Not recommended for direct PDF parsing unless you handle conversion yourself.
• vlm-vllm-async-engine: Asynchronous vLLM engine, new in MinerU API. Theoretically supported but not as officially tested as the others.
• vlm-http-client: Lets you connect to a remote MinerU vLLM server (e.g., mineru-vllm-server) via HTTP. RAGFlow can run on CPU, and parsing is offloaded to the remote GPU server. Handles PDF-to-image conversion internally. Recommended for remote deployments and leveraging GPU resources.

For PDF parsing, use pipeline for local, all-in-one setups, or vlm-http-client if you want to offload parsing to a remote mineru-vllm-server (set MINERU_SERVER_URL to the server address). Avoid vlm-vllm-engine unless you’re prepared to convert PDFs to images yourself. The other options are more specialized or less tested. MinerU integration is still experimental, so stick to the officially documented backends for best results.

Here’s a quick decision flow:

graph TD
    A["Do you want to parse PDFs locally?"] -->|Yes| B["Use pipeline"]
    A -->|No, want to use remote GPU server| C["Use vlm-http-client and set MINERU_SERVER_URL"]
    C --> D["mineru-vllm-server handles PDF-to-image"]
    B --> E["pipeline handles PDF-to-image"]
    A -->|Want to use local vLLM GPU, but only have images| F["Use vlm-vllm-engine (images only)"]

Loading

References:

• Backend option details and usage
• Remote PDF parsing setup
• Backend differences and PDF parsing caveats
• Officially tested backends and troubleshooting

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[ZTurboX]

@dosu in Miner document the backend for parsing pdf support:
pipeline: More general.
vlm-auto-engine: High accuracy via local computing power.
vlm-http-client: High accuracy via remote computing power(client suitable for openai-compatible servers).
hybrid-auto-engine: Next-generation high accuracy solution via local computing power.
hybrid-http-client: High accuracy but requires a little local computing power(client suitable for openai-compatible servers).

why not ragflow support hybrid-auto-engine and hybrid-http-client

[dosubot]

RAGFlow doesn't currently support the hybrid-auto-engine or hybrid-http-client backends because these options were proposed in pull requests that were ultimately closed or rejected—they were never merged into the main codebase, so they're not available in any release. The maintainers have focused on keeping only tested and stable backends like pipeline and vlm-http-client, mainly to reduce maintenance burden and ensure production readiness. There's an open (but not merged) pull request to add hybrid-auto-engine, so support may come in the future, but it's not available yet. There's no evidence of any work on hybrid-http-client for RAGFlow at this time. For now, stick to the officially documented backends and keep an eye on updates if you need hybrid support source source source source.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[yongtenglei]

Hi, @ZTurboX

Please use mineru, version 2.7.0. It's challenging to keep up with all the changes in MinerU. It would be more than welcome if you could add and test any features from MinerU that you'd like but aren't currently supported by RAGFlow yet.

Cheers.