Alan West

Posted on Oct 12 Originally published at blog.authon.dev

Youtu-Parsing-Omni vs MinerU and PaddleOCR-VL: Is a 5B PDF Parser Worth It?

#ai #machinelearning #rag #opensource

Tencent just open-sourced Youtu-Parsing-Omni, a 5B model that turns PDF page images, tables, charts and scans into structured JSON, and its model card puts it at #1 on OmniDocBench v1.6 with 96.96. The runner-up, TeleOCR, scores 96.91. So the headline win is 0.05 points, and the winner is about four times bigger than the 1.2B model it beat.

I still think it's worth your attention if you run a RAG pipeline. It has the best reading-order score in that table and outputs a bounding box for every element, and the same checkpoint handles charts, audio and video too. I went through what Youtu-Parsing-Omni extracts from PDFs, tables and images, how it scores against MinerU, PaddleOCR-VL and Marker, the license clause that rules out the EU, and how to serve it locally with vLLM.

What Youtu-Parsing-Omni actually is

The model card lists 5B parameters in BF16 (the explainx writeup counts 5.33B and roughly 10.7 GB of weights). One shared "Youtu-Omni-Encoder" feeds a Youtu-LLM decoder. It ships as custom code (tagged youtu_vita), so you need trust_remote_code=True. The weights, a vLLM plugin and examples landed in October 2026, and the code lives in TencentCloudADP/youtu-parsing.

The older Youtu-Parsing (2.5B, 93.74 on the same table) only parsed documents. Omni adds images, charts, audio and video, and you pick a mode with --task:

document: layout elements with boxes, text, LaTeX formulas, tables in OTSL, charts as Markdown, flowcharts as Mermaid, plus reading order
graphics_chart: chart to Markdown table
graphics_flowchart: Mermaid code
graphics_geometric: points, lines, shapes, measurements
natural_image, audio, natural_video, textrich_video: captions, ASR with timestamps, OCR per video segment

Every task returns one fenced JSON block with modality, subtype, elements (or segments) and global_description. Coordinates are tokens on a 0–1000 grid, like <box><x_85><y_275><x_1000><y_1000></box>.

For RAG, the boxes matter more than the benchmark. If every chunk carries a page number and a box, you can show the user the exact region a citation came from. Most text-only parsers throw that away.

Youtu-Parsing-Omni vs MinerU, PaddleOCR-VL and Marker

These numbers come from Tencent's model card, except the two pipeline rows, which come from the official OmniDocBench leaderboard (v1.6). Overall is ((1 − text edit) × 100 + table TEDS + formula CDM) / 3.

Model	Params	Overall ↑	Text Edit ↓	Formula CDM ↑	Table TEDS ↑	Reading Order ↓
Youtu-Parsing-Omni	5B	96.96	0.0271	96.80	96.79	0.1104
TeleOCR	1.2B	96.91	0.0267	96.59	96.82	0.1184
OvisOCR2	0.8B	96.47	0.0265	97.49	94.58	0.1120
PaddleOCR-VL-1.6	0.9B	96.34	0.0326	97.53	94.76	0.1278
MinerU2.5-Pro	1.2B	95.75	0.0360	97.45	93.42	0.1200
Gemini-3-Pro	–	92.91	0.0640	95.99	89.15	0.1650
GPT-5.2	–	86.59	0.1140	88.21	82.95	0.1930
MinerU-Pipeline 3.4.0	–	86.47	–	–	–	–
Marker 1.8.2	–	78.44	–	–	–	–

The top five are basically tied. TeleOCR has better text edit distance and table TEDS. OvisOCR2 and PaddleOCR-VL beat Youtu on formulas while being under 1B parameters. If you parse math-heavy papers, a 0.9B model wins on formulas with under a fifth of the parameters.

Where Youtu does lead is reading order. 0.1104 is the best in the table, and its structure-only table score (TEDS-S 98.20) is also top. Bad reading order is what produces chunks that start mid-sentence in column two and finish in a footnote. That's where I'd expect the difference to show up in retrieval.

Docling isn't in any of these tables. OmniDocBench lists Docling as a tool but its current v1.6 table doesn't score it, and the model card leaves it out too. If you came here hoping for Youtu vs Docling numbers, I couldn't find any. Marker 1.8.2 does have a score, and 78.44 against 96.96 is a large gap. Keep in mind that Marker can run on a laptop CPU and this model needs a CUDA GPU.

Why I don't trust a 0.05-point OmniDocBench lead

Youtu-Parsing-Omni is not on the official OmniDocBench leaderboard yet. The older Youtu-Parsing is (93.74), and the history behind that entry is useful. In issue #14, the OmniDocBench team re-ran Youtu-Parsing on v1.5 and got 93.37 overall. Tencent's internal number was 93.22. The overall scores are close, but formula CDM differs by about 2 points (91.22 vs 93.19) and table TEDS by about 2 in the other direction (93.10 vs 91.15). Tencent put the gap down to different testing environments and called it normal variation.

A 2-point swing on sub-metrics is far bigger than the 0.05 lead in the headline. Treat the leaderboard order as noise until someone re-runs it independently.

The OmniParsingBench numbers have the same caveat. Youtu averages 75.08 against Gemini-3-Pro's 77.44, wins on charts (95.02) and audio (78.08), and loses clearly on natural images (62.84 vs 69.73) and geometry (74.33 vs 85.43). The benchmark comes from the Logics-Parsing-Omni team, but it shipped without a complete scoring toolkit, so Tencent wrote its own and ran and scored every model itself. Part of the score comes from an LLM judge.

There are also no throughput numbers. The repo advertises a 5–11x speedup from "Token Parallelism" for the older model, but issue #12 confirms it isn't integrated into vLLM. If you serve through vLLM, don't count on that speedup.

The license excludes the EU: read section 0 first

The license is a custom "youtu-parsing" license, not Apache or MIT. The grant is perpetual, worldwide and royalty-free, and the LICENSE file has no MAU threshold. Section 0 says:

Youtu-Parsing IS NOT INTENDED FOR USE WITHIN THE EUROPEAN UNION.

It also says that clause prevails in any conflict. If your users or your servers are in the EU, talk to legal before you build on this. PaddleOCR-VL or MinerU might be the boring, safer pick for you.

How much VRAM does Youtu-Parsing-Omni need?

The card gives no VRAM figure. What it does give is the launch config in scripts/vllm.sh: max-model-len 65536, gpu-memory-utilization 0.70, max-num-seqs 1, bfloat16. With about 10.7 GB of weights, 70% of a 16 GB card is 11.2 GB, which leaves almost nothing for KV cache. My estimate is that a 24 GB card is the realistic floor for the default script. Someone has already opened a GGUF request, and the model tree lists two quantizations (MLX 4-bit and 8-bit, so Apple silicon only), but I haven't seen any quality numbers for them.

How to run Youtu-Parsing-Omni for local document OCR

The vLLM and Transformers paths pin different Transformers versions (5.2.0 vs 5.10.2), so give each one its own environment:

git clone https://github.com/TencentCloudADP/youtu-parsing.git
cd youtu-parsing/youtu_parsing_omni

# Python >= 3.10, CUDA GPU
bash scripts/setup_env.sh                 # vLLM serving
# bash scripts/setup_env.sh --transformers  # separate venv for Transformers

MODEL=tencent/Youtu-Parsing-Omni DATA_ROOT=/path/to/media GPU=0 bash scripts/vllm.sh

That serves an OpenAI-compatible API at http://127.0.0.1:8000/v1 under the model name Youtu-Parsing-Omni. The model reads images, not PDFs, so rasterize first and put the pages under DATA_ROOT:

pdftoppm -r 150 -png report.pdf /path/to/media/report/page
for p in /path/to/media/report/page-*.png; do
  python examples/infer_vllm.py --task document --media "$p"
done

If you call the API yourself, copy the settings from the card's raw example: temperature=0.0, max_tokens=32768, chat_template_kwargs={"enable_thinking": False, "enable_parsing": True}, skip_special_tokens=False, and stop token IDs for <|image_pad|> and <|end_of_text|>. The prompt text for each task is in prompts/youtu_parsing_omni.json. Don't write your own; these parsers are trained on one exact prompt.

On the Transformers path, pin a commit with --revision. The card recommends it because of trust_remote_code, and I'd do it anyway. You don't want remote code changing underneath a production ingest job.

Using Youtu-Parsing-Omni in a RAG pipeline

Here's the setup I'd try:

One JSON file per page, stored next to the source PDF. Never re-parse just because you changed the chunker.
Chunk on elements in the model's reading order, not on fixed token windows. Keep tables and formulas as whole chunks.
Store page, the 0–1000 box and subtype as metadata on each chunk, so citations can highlight the source region.
Index the table's Markdown, but keep the OTSL/HTML around for display.
Run a 30-page sample from your own worst PDFs through this and through PaddleOCR-VL-1.6 before deciding. On the benchmark they're 0.62 apart. Your scanned invoices won't look like OmniDocBench.

My take: if you're on Marker or a plain text extractor and your answers fall apart on multi-column layouts, the jump to any model in that top five will matter much more than which one you pick. Youtu-Parsing-Omni is worth considering if you need boxes plus reading order and also want charts and audio from one model. If you only parse PDFs, the sub-1B models give you almost the same scores for much less VRAM, and their licenses don't exclude the EU.

What do you use to turn PDFs into clean text for RAG right now, and what keeps breaking? Tables, two-column papers, scanned forms? I'm especially curious whether anyone has run a VLM parser against Docling on real documents and found it worth the GPU.

DEV Community