Youtu-Parsing-Omni 深度评测：5B 参数 PDF 解析器值不值得上

腾讯开源了 Youtu-Parsing-Omni，一个 5B 参数的多模态解析模型，能把 PDF 页面图、表格、图表和扫描件转成结构化 JSON。模型卡显示它在 OmniDocBench v1.6 上拿到 96.96 分，排名第一，而第二名 TeleOCR 是 96.91——领先优势只有 0.05 分，但参数量是后者的四倍多。

Youtu-Parsing-Omni 与 MinerU、PaddleOCR-VL 的对比评测

如果你在维护 RAG 管线，这个模型仍然值得关注：它拥有榜单中最好的阅读顺序得分，为每个元素输出边界框，而且同一个 checkpoint 还能处理图表、音频和视频。但它也有不少坑——许可证排除欧盟，吞吐量数据缺失，benchmark 领先幅度极小。下面拆解它在 PDF、表格和图像上的实际表现、与 MinerU、PaddleOCR-VL 和 Marker 的对比，以及如何在本地用 vLLM 部署。

Youtu-Parsing-Omni 到底是什么

根据 Hugging Face 模型卡，这是一个 5B 参数（BF16）的模型，有分析文章统计为 5.33B、约 10.7 GB 权重。架构上由一个共享的 Youtu-Omni-Encoder 输入到 Youtu-LLM 解码器。它以自定义代码形式发布（标签 youtu_vita），因此调用时需要 trust_remote_code=True。权重、vLLM 插件和示例已经发布，代码托管在 TencentCloudADP/youtu-parsing 仓库。

此前的 Youtu-Parsing（2.5B，同一榜单 93.74 分）只能解析文档。Omni 版本新增了图像、图表、音频和视频支持，通过 --task 参数选择模式：

document：版面元素加边界框、文本、LaTeX 公式、OTSL 格式表格、Markdown 图表、Mermaid 流程图，以及阅读顺序
graphics_chart：图表转 Markdown 表格
graphics_flowchart：输出 Mermaid 代码
graphics_geometric：点、线、形状、测量值
natural_image、audio、natural_video、textrich_video：图像描述、带时间戳的 ASR、逐视频片段 OCR

每个任务返回一个带围栏的 JSON 块，包含 modality、subtype、elements（或 segments）和 global_description。坐标以 0–1000 网格的 token 形式表示，例如 <box><x_85><y_275><x_1000><y_1000></box>。

对 RAG 来说，边界框比 benchmark 分数更有价值。如果每个 chunk 都携带页码和边界框，就能向用户展示引用内容在原始文档中的确切位置。大多数纯文本解析器丢弃了这个信息。

与 MinerU、PaddleOCR-VL 和 Marker 的横向对比

以下数据来自腾讯模型卡，标注为 pipeline 的两行来自 OmniDocBench 官方榜单 v1.6。综合分计算公式为 ((1 − text edit) × 100 + table TEDS + formula CDM) / 3。

模型	参数量	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	–	–	–	–

前五名基本处于同一水平。TeleOCR 在文本编辑距离和表格 TEDS 上更好；OvisOCR2 和 PaddleOCR-VL 在公式上超过 Youtu，参数量不到 1B。如果主要解析数学密集型论文，0.9B 模型在公式上的表现更优，参数量却只有五分之一。

Youtu 真正领先的是阅读顺序，0.1104 是表中最佳，仅结构表格得分（TEDS-S 98.20）也是第一。阅读顺序差会导致 chunk 从第二栏中间开始、在脚注结束，这正是检索质量差异的来源。

Docling 没有出现在这些表中。OmniDocBench 将 Docling 列为工具但当前 v1.6 表未对其评分，模型卡也没有收录。Marker 1.8.2 有分数，78.44 对 96.96 差距很大，但要注意 Marker 可以在笔记本 CPU 上运行，而这个模型需要 CUDA GPU。

上述表格中的 Table TEDS 和 Formula CDM 是文档解析评测中的两个关键指标。TEDS（Tree-Edit-Distance-based Similarity，树编辑距离相似度）用于衡量表格结构还原的准确度，把表格看作树结构后计算预测与真值之间的编辑距离，取值 0–100，越高越好。TEDS-S 是其只评估结构（不含文本内容）的变体。CDM（Character Detection Matching，字符检测匹配）是公式识别指标，先做字符级检测再匹配，兼顾位置与符号正确性，同样是 0–100 分。Text Edit 则是归一化编辑距离，越低越好，反映纯文本转录的准确程度。理解这三个指标后就能明白，综合分只是它们的算术平均，单项上的差异可能被平均掩盖——这正是 Youtu 领先优势看起来微弱的原因。

为什么我不信任 0.05 分的领先

Youtu-Parsing-Omni 尚未进入 OmniDocBench 官方榜单。老版本 Youtu-Parsing 在榜上（93.74 分），其历史很有参考价值。在 GitHub issue #14 中，OmniDocBench 团队在 v1.5 上重新跑了 Youtu-Parsing，得到综合分 93.37，而腾讯内部数字是 93.22。综合分接近，但公式 CDM 差了约 2 分（91.22 对 93.19），表格 TEDS 反向差了约 2 分（93.10 对 91.15）。腾讯将差异归因于测试环境不同，称属正常波动。

子指标上 2 分的波动远大于标题中的 0.05 分领先。在第三方独立复现之前，榜单排名更应视为噪声。

OmniParsingBench 的数据同样有此问题。Youtu 平均 75.08，对 Gemini-3-Pro 的 77.44，在图表（95.02）和音频（78.08）上胜出，但在自然图像（62.84 对 69.73）和几何（74.33 对 85.43）上明显落后。该 benchmark 来自 Logics-Parsing-Omni 团队，但发布时没有完整评分工具包，腾讯自行编写并自行运行评分了所有模型，部分分数来自 LLM 评判。

吞吐量数据也缺失。仓库宣传老模型有 5–11 倍"Token Parallelism"加速，但 issue #12 确认该特性未集成到 vLLM。如果通过 vLLM 部署，不要指望这个加速。

需要区分两类榜单：leaderboard（官方榜单）只收录由评测方（OmniDocBench 团队）使用统一脚本独立跑出的结果，model card（模型卡）分数则通常由模型发布方自行运行得到。两者环境、依赖版本、后处理逻辑都可能不同，因此常出现数个点的偏差。本文中 Youtu-Parsing-Omni 的 96.96 分来自腾讯模型卡，尚未进入官方榜单，而老版本 Youtu-Parsing 的 93.74 分在榜上——这种"新版本只有自测分"的状态，使数字的横向可比性打折扣。实践中，看到模型卡宣称的榜首位置时，应先确认该分数是否已有第三方独立复现，否则只能当作参考。

许可证排除欧盟：先读 Section 0

许可证是自定义的 youtu-parsing 许可，而非 Apache 或 MIT。授权是永久、全球、免版税的，LICENSE 文件没有 MAU 门槛。但 Section 0 明确规定：

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

该条款在冲突时优先。如果你的用户或服务器在欧盟，构建之前先咨询法务。PaddleOCR-VL 或 MinerU 可能是更安全的选择。

本地运行需要多少显存

模型卡没有给出显存数字，但提供了 scripts/vllm.sh 中的启动配置：max-model-len 65536、gpu-memory-utilization 0.70、max-num-seqs 1、bfloat16。约 10.7 GB 权重下，16 GB 显卡的 70% 是 11.2 GB，留给 KV cache 的空间几乎没有。现实的最低配置估计是 24 GB 显卡。已有用户提出 GGUF 请求，模型树列出了两个量化版本（MLX 4-bit 和 8-bit，仅限 Apple 芯片），但尚无质量数据。

KV cache（键值缓存）是大模型推理时用于存储注意力机制中 Key 和 Value 张量的显存区域，用来避免自回归生成时重复计算历史 token。它的占用随上下文长度、批量大小和层数线性增长。当 max-model-len 设为 65536、gpu-memory-utilization 设为 0.70 时，权重占用大头，留给 KV cache 的空间被压缩，一旦上下文变长或并发请求增加就可能 OOM。max-num-seqs 控制同时处理的序列数量，设为 1 相当于牺牲吞吐换显存安全。gpu-memory-utilization 则是允许 vLLM 使用的显存比例，0.70 是保守值，但 16GB 卡上仍捉襟见肘。这些参数解释了为什么 24GB 是更现实的起点。

本地文档 OCR 部署步骤

vLLM 和 Transformers 路径锁定了不同的 Transformers 版本（5.2.0 对 5.10.2），需要各自独立的环境：

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


**`trust_remote_code=True`** 是 Hugging Face 生态中的安全开关。当模型使用自定义架构（如本文的 `youtu_vita` 代码）时，其建模代码不在 transformers 主库中，而是随模型仓库发布，加载时需要用这个参数显式允许执行仓库里的 Python 代码。它带来便利，也带来供应链风险：如果仓库被篡改或依赖漂移，远程代码会在你的环境里运行。因此模型卡推荐用 `--revision` 锁定到具体 commit hash，确保每次拉取的都是经过审核的同一份代码。生产管线中尤其应当如此，并配合隔离环境或容器，避免本地依赖与远程代码互相干扰。
# 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

这会启动一个兼容 OpenAI 的 API，地址为 http://127.0.0.1:8000/v1，模型名 Youtu-Parsing-Omni。模型读的是图像不是 PDF，所以要先栅格化：

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

自行调用 API 时，按模型卡示例设置：temperature=0.0、max_tokens=32768、chat_template_kwargs={"enable_thinking": False, "enable_parsing": True}、skip_special_tokens=False，以及 <|image_pad|> 和 <|end_of_text|> 的 stop token ID。每个任务的 prompt 在 prompts/youtu_parsing_omni.json 中，不要自己写——这些解析器只在一个精确 prompt 上训练过。

Transformers 路径要用 --revision 锁定 commit。模型卡因 trust_remote_code 而推荐这样做，生产环境更应如此，避免远程代码在管线运行中发生变化。

接入 RAG 管线的实践建议

推荐以下配置：

每页生成一个 JSON 文件，与源 PDF 放在一起。不要因为改了 chunker 就重新解析。
按模型给出的阅读顺序在 elements 上切分，而非固定 token 窗口。表格和公式保持完整 chunk。
在每个 chunk 的 metadata 中保存 page、0–1000 边界框和 subtype，以便引用时高亮源区域。
索引表格的 Markdown 版本，但保留 OTSL/HTML 用于展示。
从你自己最难的 PDF 中取 30 页样本，同时跑这个模型和 PaddleOCR-VL-1.6 再决定。benchmark 上它们差 0.62 分，但你的扫描发票不会长得像 OmniDocBench。

我的判断：如果你现在用 Marker 或纯文本提取器，多栏排版下答案质量崩溃，那么升级到前五名中任何一个模型的影响，远大于具体选谁。Youtu-Parsing-Omni 值得考虑的场景是需要边界框加阅读顺序，同时还想用一个模型处理图表和音频。如果只解析 PDF，1B 以下的模型给出几乎相同的分数，显存需求低得多，许可证也不排除欧盟。