Youtu-Parsing-Omni In-Depth Review: Is a 5B-Parameter PDF Parser Worth Deploying?

Title

Youtu-Parsing-Omni In-Depth Review: Is a 5B-Parameter PDF Parser Worth Deploying?

Meta Description

Tencent open-sources Youtu-Parsing-Omni, a 5B-parameter multimodal PDF parser that tops OmniDocBench v1.6 at 96.96 points—but leads second place by only 0.05. A deep dive comparing MinerU, PaddleOCR-VL, and Marker, plus license EU restrictions, VRAM needs, and RAG pipeline integration.

Article Content

Tencent has open-sourced Youtu-Parsing-Omni, a 5B-parameter multimodal parsing model that turns PDF page images, tables, charts, and scanned documents into structured JSON. The model card shows it scoring 96.96 on OmniDocBench v1.6, ranking first, while runner-up TeleOCR scores 96.91—a lead of just 0.05 points, yet with more than four times the parameter count.

If you're maintaining a RAG pipeline, this model is still worth a look: it has the best reading-order score on the leaderboard, outputs bounding boxes for every element, and the same checkpoint also handles charts, audio, and video. But it has plenty of pitfalls—the license excludes the EU, throughput data is missing, and its benchmark lead is razor-thin. Below is a breakdown of its real-world performance on PDFs, tables, and images, how it compares to MinerU, PaddleOCR-VL, and Marker, and how to deploy it locally with vLLM.

What Exactly Is Youtu-Parsing-Omni

According to the Hugging Face model card, this is a 5B-parameter (BF16) model, which analysis articles cite as 5.33B with roughly 10.7 GB of weights. Architecturally, a shared Youtu-Omni-Encoder feeds into a Youtu-LLM decoder. It ships as custom code (tag youtu_vita), so calling it requires trust_remote_code=True. Weights, the vLLM plugin, and examples have been released, with code hosted in the TencentCloudADP/youtu-parsing repository.

The earlier Youtu-Parsing (2.5B, 93.74 on the same leaderboard) could only parse documents. The Omni version adds image, chart, audio, and video support, with modes selected via the --task parameter:

• document: layout elements plus bounding boxes, text, LaTeX formulas, OTSL-format tables, Markdown charts, Mermaid flowcharts, and reading order
• graphics_chart: charts to Markdown tables
• graphics_flowchart: outputs Mermaid code
• graphics_geometric: points, lines, shapes, measurements
• natural_image, audio, natural_video, textrich_video: image captions, ASR with timestamps, per-video-segment OCR

Each task returns a fenced JSON block containing modality, subtype, elements (or segments), and global_description. Coordinates are expressed as tokens on a 0–1000 grid, e.g. <box><x_85><y_275><x_1000><y_1000></box>.

For RAG, bounding boxes matter more than benchmark scores. If every chunk carries a page number and a bounding box, you can show users exactly where the citation appears in the original document. Most text-only parsers throw this information away.

Head-to-Head Comparison with MinerU, PaddleOCR-VL, and Marker

The data below comes from Tencent's model card; the two rows labeled as pipeline come from the official OmniDocBench leaderboard v1.6. The overall score is computed as ((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 essentially at the same level. TeleOCR is better on text edit distance and table TEDS; OvisOCR2 and PaddleOCR-VL beat Youtu on formulas with fewer than 1B parameters. If you mainly parse math-heavy papers, a 0.9B model performs better on formulas while using one-fifth the parameters.

Where Youtu genuinely leads is reading order, at 0.1104 the best in the table, and its structure-only table score (TEDS-S 98.20) is also first. Poor reading order means chunks start mid-column-two and end at a footnote—exactly where retrieval quality differences come from.

Docling doesn't appear in these tables. OmniDocBench lists Docling as a tool but the current v1.6 table doesn't score it, and the model card doesn't include it either. Marker 1.8.2 has a score; 78.44 versus 96.96 is a big gap, but note that Marker can run on a laptop CPU, whereas this model needs a CUDA GPU.

Table TEDS and Formula CDM in the table above are two key metrics in document parsing evaluation. TEDS (Tree-Edit-Distance-based Similarity) measures how accurately table structure is reconstructed—treating the table as a tree and computing the edit distance between prediction and ground truth, scored 0–100, higher is better. TEDS-S is its variant that evaluates structure only (excluding text content). CDM (Character Detection Matching) is a formula recognition metric that performs character-level detection first, then matching, accounting for both position and symbol correctness, also scored 0–100. Text Edit is normalized edit distance, lower is better, reflecting pure text transcription accuracy. Understanding these three metrics makes it clear that the overall score is just their arithmetic mean, and differences in individual items can be masked by averaging—which is exactly why Youtu's lead looks so thin.

Why I Don't Trust a 0.05-Point Lead

Youtu-Parsing-Omni hasn't yet entered the official OmniDocBench leaderboard. The older Youtu-Parsing is on it (93.74), and its history is instructive. In GitHub issue #14, the OmniDocBench team re-ran Youtu-Parsing on v1.5 and got an overall score of 93.37, versus Tencent's internal figure of 93.22. Overall scores were close, but formula CDM differed by about 2 points (91.22 vs. 93.19), and table TEDS differed by about 2 points in the opposite direction (93.10 vs. 91.15). Tencent attributed the discrepancies to different test environments, calling them normal fluctuations.

A 2-point fluctuation on submetrics is far larger than the 0.05-point lead in the headline. Until an independent third-party reproduces it, the leaderboard ranking should be treated as noise.

The OmniParsingBench data has the same problem. Youtu averages 75.08 versus Gemini-3-Pro's 77.44, winning on charts (95.02) and audio (78.08), but clearly trailing on natural images (62.84 vs. 69.73) and geometry (74.33 vs. 85.43). That benchmark comes from the Logics-Parsing-Omni team, but no complete scoring toolkit was released at publication—Tencent wrote its own and scored all models itself, with some scores coming from LLM judgments.

Throughput data is also missing. The repository advertises 5–11× "Token Parallelism" speedup for the older model, but issue #12 confirms that feature isn't integrated into vLLM. If you deploy via vLLM, don't count on that speedup.

It's important to distinguish two types of score sources: a leaderboard (official ranking) only includes results independently run by the evaluator (the OmniDocBench team) using a unified script, whereas a model card score is typically obtained by the model publisher running it themselves. Environments, dependency versions, and post-processing logic can all differ, so discrepancies of several points are common. In this article, Youtu-Parsing-Omni's 96.96 comes from Tencent's model card and hasn't entered the official leaderboard, while the older Youtu-Parsing's 93.74 is on it—this state of "only self-reported scores for the new version" undermines the horizontal comparability of the numbers. In practice, when you see a model card claiming the top spot, first confirm whether that score has been independently reproduced by a third party; otherwise it's only a reference.

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, royalty-free, and the LICENSE file has no MAU threshold. But Section 0 explicitly states:

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

That clause takes precedence in case of conflict. If your users or servers are in the EU, consult legal before building. PaddleOCR-VL or MinerU may be safer choices.

How Much VRAM Does It Need to Run Locally

The model card doesn't give VRAM figures, but provides the launch config in scripts/vllm.sh: max-model-len 65536, gpu-memory-utilization 0.70, max-num-seqs 1, bfloat16. With roughly 10.7 GB of weights, 70% of a 16 GB card is 11.2 GB, leaving almost no room for KV cache. A realistic minimum is a 24 GB card. Users have already requested GGUF support; the model tree lists two quantized versions (MLX 4-bit and 8-bit, Apple silicon only), but no quality data yet.

KV cache (key-value cache) is the VRAM region used during large model inference to store the Key and Value tensors from the attention mechanism, avoiding recomputation of historical tokens during autoregressive generation. Its footprint grows linearly with context length, batch size, and number of layers. When max-model-len is set to 65536 and gpu-memory-utilization to 0.70, weights take the lion's share, compressing the space left for KV cache—so OOM can occur once context grows longer or concurrent requests increase. max-num-seqs controls how many sequences are processed simultaneously; setting it to 1 trades throughput for VRAM safety. gpu-memory-utilization is the fraction of VRAM vLLM is allowed to use; 0.70 is a conservative value, yet still tight on a 16GB card. These parameters explain why 24GB is a more realistic starting point.

Local Document OCR Deployment Steps

The vLLM and Transformers paths pin different Transformers versions (5.2.0 vs. 5.10.2), requiring separate environments:

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


**`trust_remote_code=True`** is a security toggle in the Hugging Face ecosystem. When a model uses a custom architecture (such as the `youtu_vita` code here), its modeling code isn't in the transformers main library but ships with the model repository, and loading requires explicitly allowing execution of the repository's Python code via this parameter. It brings convenience but also supply-chain risk: if the repository is tampered with or dependencies drift, remote code runs in your environment. That's why the model card recommends pinning to a specific commit hash with `--revision`, ensuring that every pull is the same reviewed code. This is especially important in production pipelines, paired with isolated environments or containers to prevent local dependencies and remote code from interfering with each other.
# 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

This starts an OpenAI-compatible API at http://127.0.0.1:8000/v1, with the model name Youtu-Parsing-Omni. The model reads images, not PDFs, so you need to rasterize first:

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

When calling the API yourself, follow the model card example: temperature=0.0, max_tokens=32768, chat_template_kwargs={"enable_thinking": False, "enable_parsing": True}, skip_special_tokens=False, and the stop token IDs for <|image_pad|> and <|end_of_text|>. Each task's prompt is in prompts/youtu_parsing_omni.json—don't write your own; these parsers were only trained on one exact prompt.

The Transformers path should pin the commit with --revision. The model card recommends this because of trust_remote_code, and production environments should do so even more, to avoid remote code changing mid-pipeline.

Practical Advice for Integrating into a RAG Pipeline

The following configuration is recommended:

1. Generate one JSON file per page, stored alongside the source PDF. Don't re-parse just because you changed the chunker.
2. Split elements by the reading order the model provides, not by fixed token windows. Keep tables and formulas as intact chunks.
3. Store page, the 0–1000 bounding box, and subtype in each chunk's metadata, so citations can highlight the source region.
4. Index the Markdown version of tables, but retain OTSL/HTML for display.
5. Take a 30-page sample from your own hardest PDFs and run both this model and PaddleOCR-VL-1.6 before deciding. They differ by 0.62 points on benchmarks, but your scanned invoices won't look like OmniDocBench.

My take: if you currently use Marker or plain text extractors and answer quality collapses on multi-column layouts, upgrading to any of the top five will matter far more than which one you pick. Youtu-Parsing-Omni is worth considering when you need bounding boxes plus reading order, and also want to handle charts and audio with a single model. If you only parse PDFs, sub-1B models deliver nearly identical scores, need much less VRAM, and their licenses don't exclude the EU.

One-line Summary

Tencent open-sources the 5B Youtu-Parsing-Omni, topping the document parsing leaderboard by a sliver—but EU licensing and VRAM are major traps.

Paragraph Summary

Tencent has released Youtu-Parsing-Omni, a 5B-parameter multimodal parsing model that tops OmniDocBench v1.6 at 96.96 points but leads the 1.2B TeleOCR by only 0.05. Its real value lies in the best reading-order score on the table and per-element bounding box output, which matter practically for RAG citation traceability, plus one checkpoint that handles charts, audio, and video. The article also flags several risks: the model hasn't entered the official leaderboard, and the gap on submetrics versus other models may exceed the thin headline lead; the throughput speedup isn't integrated into vLLM; the custom license explicitly excludes the EU; and a 16GB GPU can barely run it, making 24GB the realistic threshold. The author recommends it only when you need bounding boxes and reading order, and want one model covering multiple modalities—for pure PDF use cases, sub-1B models offer better value.