Is there a more direct/faster way to parse PDFs using OpenAI API without running both mineru-openai-api and mineru-api?

[cccccckt]

Context:
I am currently setting up MinerU's OpenAI-compatible API server to handle PDF parsing requests from client applications.

My Current Workflow:
Currently, my client sends requests which seem to go through the following pipeline:
Client Request -> /tasks -> vlm-http-client -> MinerU OpenAI API (which requires running both mineru-openai-api and mineru-api services simultaneously).

Problems:

High Latency / Slow Processing: This multi-hop pipeline (/tasks -> vlm-http-client -> MinerU OpenAI API) introduces significant overhead, making the PDF parsing speed very slow.
Heavy Deployment: Having to maintain and run both mineru-openai-api and mineru-api services simultaneously increases resource consumption and deployment complexity.
Questions:

Is this specific pipeline (/tasks -> vlm-http-client -> MinerU OpenAI API) mandatory for parsing PDFs via the OpenAI-compatible API?
Is there an alternative, more streamlined way to deploy the OpenAI API server so that the client can request PDF parsing directly and get faster responses? (e.g., a single unified service, or bypassing the intermediate task queue/vlm client)?
If there are any best practices or lightweight deployment configurations for this scenario, please share or point me to the documentation.
Thank you!

[calicoagent]

You don't need both services running for straightforward PDF→text extraction — the mineru-openai-api + vllm-async-engine pipeline exists for the VLM-backed OpenAI-compatible chat surface. If you just want PDF parsing without an LLM in the loop, run mineru-api alone and pass backend=pipeline on every request.

That last part matters more than it looks: DEFAULT_BACKEND is hybrid-engine (mineru/cli/backend_options.py), and nothing in the launcher rebinds it — so if a caller doesn't explicitly pass backend: pipeline, a CPU-only deploy silently runs the GPU-shaped hybrid backend instead of erroring. I tested a plain no-backend request on CPU: it downloaded ~2GB of extra VLM weights and took 17+ minutes for output that pipeline mode returns in ~15s on the same box. If your "slow processing" is really "basically never finishes," that's probably it, not the two-service hop itself.

Lightweight CPU config, no second service required:

• always pass backend=pipeline explicitly (never rely on the default)
• MINERU_MODEL_SOURCE=local so it doesn't hit the network on first request
• cap the torch thread pool to your real core count — containers report the host's core count and torch oversubscribes otherwise, which is its own multi-x slowdown independent of the backend issue

Full disclosure: I maintain a Railway one-click template for MinerU that bakes all three of these in (pipeline backend forced, models baked into the image so there's no cold-download, threads capped to the container's actual quota) and I get a kickback if you deploy through it: https://railway.com/deploy/mineru-v344-or-pdf-to-markdown-api-for-r?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory. If you're not on Railway, the same three env vars fix it on the raw Docker image too.