NVIDIA-Nemotron-Parse-2.0 vs PaddleOCR-VL：低调的挑战者 vs 经过验证的 SOTA

文档解析正处于一场开放权重SOTA竞赛的中间阶段，而两位参赛者并不在同一个赛道上。PaddleOCR-VL——来自百度PaddlePaddle团队的0.9B解析器——以96.33的综合得分位居OmniDocBench v1.6榜首，十个月内发布了三个版本，并聚集了OCR领域最大的生态系统。另一位参赛者NVIDIA-Nemotron-Parse-2.0于2026年8月3日出现在Hugging Face上，没有发布公告，没有托管端点，其模型卡上的数字除NVIDIA内部人员外，尚未有任何人验证过。这两组事实将问题变成了一个在位者之争：你会把管线中的解析阶段押注在哪个开放权重解析器上——是那个拥有公开排行榜记录的呢，还是那个悄悄发布、声称修复了所有其他人都难以应对的语言问题的那个？

构建页面解析器的两种方法

两款模型的参数量都在约0.9B，均为开放权重，并且都设计用于自托管。相似之处到此为止，因为两者的架构理念截然相反。

PaddleOCR-VL 是一个两阶段流程。布局模型 PP-DocLayoutV3 首先检测页面上的每个元素，对其进行分类，并预测阅读顺序。之后，PaddleOCR-VL 视觉语言模型——一个 NaViT 风格的动态分辨率视觉编码器，搭配百度轻量级 ERNIE-4.5-0.3B 语言模型——才识别每个区域：文本、表格、公式、图表。百度主张拆分的原因在于，将布局与识别分离，可以避免端到端模型在复杂的多栏页面上出现的幻觉和元素错位等失败模式。

NVIDIA-Nemotron-Parse-2.0 则押注相反方向：采用单一端到端模型。基于 NVIDIA C-RADIOv2 骨干网络构建的 ViT-H 视觉编码器，将特征馈送给一个十层的、类似 mBART 的解码器，整个系统一次性将页面图像直接映射为阅读顺序文本、边界框、语义类别和 Markdown。无需单独安装、调优或版本化管理布局阶段。

规格说明书相应内容如下：

• 架构 — PaddleOCR-VL：版面检测（PP-DocLayoutV3）加一个 0.9B 识别 VLM（NaViT 编码器 + ERNIE-4.5-0.3B）。NVIDIA-Nemotron-Parse-2.0：一个 0.9B 视觉编码器-解码器（ViT-H C-RADIOv2 + mBART 风格解码器）。

• 输出契约——两者都返回按阅读顺序排列的文本、每个区域的边界框和语义类别，以及 markdown。PaddleOCR-VL 为文本识别、表格识别、公式识别、图表识别、文本定位和印章识别添加了任务特定的提示词；Parse 2.0 将表格输出为 LaTeX、HTML、markdown、JSON 或 CSV，并在 2.0 版本中新增了专用的图表语义类别。

• 上下文 — PaddleOCR-VL 1.6 支持最多 131,072 个 token 的上下文；Parse 2.0 的卡片文档输入最高支持 2048×1664，输出上限为 9,000 个 token。

• 许可证 — PaddleOCR-VL 采用 Apache 2.0；Parse 2.0 采用 NVIDIA 开放模型许可证，其分词器采用 CC-BY-4.0。两者均允许商业使用。

基准测试问题：96.33% 对比一个无人能核实的数字

这就是对决不再是比较、而变成货源问题的部分。

PaddleOCR-VL 的当前版本 PaddleOCR-VL 1.6（2026 年 5 月 28 日发布）在 OmniDocBench v1.6 上报告了 96.33% 的成绩 — {{1}}该基准综合了文本、公式和表格识别以及阅读顺序预测{{/1}} — 并在 Real5-OmniDocBench 上达到 93.19%，{{2}}这是一个针对弯曲、倾斜和屏幕拍摄页面的鲁棒性变体，{{/2}}百度称其在此项上领先 Gemini-3-Pro 近四个百分点。这些是百度自己的数据，但该结果是在领域共享的公共基准上报告的，{{3}}因此可以与 MinerU 2.5-Pro、GLM-OCR 以及排行榜上的其他模型进行对比排名。{{/3}}

NVIDIA-Nemotron-Parse-2.0 在不同的测试套件上报告了一组不同的数字。ParseBench 综合得分为 0.6391，高于 v1.2 的 0.5782；MOSCAR 多语言 F1 为 0.9102，高于 0.4410；IndicVisionBench ANLS 为 0.7203，高于 0.0612；OmniDocBench Notes 手写体编辑距离从 0.9739 降至 0.3395。这些数字都是 NVIDIA 自己的，印在模型卡上，而且没有一项被独立复现过。ParseBench 是 NVIDIA 自己的测试套件；MOSCAR 和 IndicVisionBench 则是专业数据集。目前没有任何已发表的 Parse 2.0 在 OmniDocBench 综合基准（PaddleOCR-VL 在该基准上领先）上的运行结果，也没有 PaddleOCR-VL 在 ParseBench 上的运行结果。

所以，对于“谁得分更高”这个问题的诚实回答是：目前还没人知道——任何声称知道答案的人，其实都是在拿不同的标尺作比较。两者唯一的交集点在于 OmniDocBench Notes 上的手写识别：Parse 2.0 的卡片声称其编辑距离相对自家前代产品有大幅改进，但那是任务级指标，不是 PaddleOCR-VL 报告的综合得分。真正关键的不对称是结构性的：PaddleOCR-VL 的 96.33 是任何人都能查到的排行榜名次，而 Parse 2.0 的声称只是一个上线五天的代码仓库，没有任何第三方验证。

语言：覆盖范围与声称的差异

两个模型都以语言作为推介的开场，且两者都有故事——但故事的形态不同。

PaddleOCR-VL 的多语言能力已经交付：支持 109 种语言，并在多语言 OCR 最难啃的领域尤其深入——中文古籍、生僻汉字、印章识别、竖排文本，以及针对倾斜或折页页面的不规则文本框定位。正因如此，它成为了中文文档处理领域普遍采用的解析器。

NVIDIA-Nemotron-Parse-2.0 的故事是一个声称的增量。词表从 52,329 个 token 增长到 72,256 个 token，模型卡片将这一增长归因于多语言 OCR，并声称在中日韩（CJK）和印度文字上取得了最大增益。MOSCAR 分数从 0.44 升至 0.91、IndicVisionBench 从 0.06 升至 0.72，这些声称表明那些曾经无法解析的文字现在可以准确解析——据模型卡片称，涵盖孟加拉语、印地语、泰卢固语、泰米尔语以及其他六种印度语言。

哪一个更重要取决于你要解析什么。如果你的语料是中文或广义上的 CJK 文字，PaddleOCR-VL 是经过验证、有排行榜数据支持的选择，唯一真正的问题是你需要它的完整流程还是仅仅模型本身。如果你的语料偏向印度语系——孟加拉语、印地语、古吉拉特语、卡纳达语及其邻近语言——Parse 2.0 所声称的增量是它模型卡上最有趣的一个数字，而这种说法恰恰是那种要么在你的数据上得到复现、要么就崩溃失效的说法。目前还没有人在公开的印度语系基准测试上运行过 Parse 2.0。

成熟度差距才是真正的代价。

这两个模型都不按页收费——两者都是可自行部署的免费权重——因此重要的是运营成本，而在这方面差距很大。

PaddleOCR-VL 是一个成熟的平台。原生 vLLM 支持就在框架本身中（vllm/model_executor/models/paddleocr_vl.py，vLLM 0.11.1 或更高版本）；百度提供官方高性能部署，带有 FastAPI 网关、用于布局阶段的 Triton，以及用于 VLM 的 vLLM；还有社区 GGUF 量化；PaddleOCR-VL 1.5 增加了对 AMD ROCm 的当日支持；并且该模型已集成到大多数人已经在使用的工具中——RAGFlow、MinerU、Umi-OCR 和 OmniParser 都集成了它。从 1.5 升级到 1.6 零成本，因为架构未变。

NVIDIA-Nemotron-Parse-2.0 发布才五天，问题也随之显现。要部署它，需要一个支持 Nemotron Parse 远程代码的 vLLM 构建版本，在 A100/A10 级硬件上使用 Triton 注意力后端，外加四个额外依赖（albumentations、timm、open_clip_torch、einops）。该模型将输出头与解码器嵌入绑定在一起，除非应用 NVIDIA 自带的运行时补丁，否则某些 vLLM 构建版本会处理不当。此外，随附的 tokenizer.json 内置了 9000 个 token 的填充——一位 Dynamo 维护者在八月初就遇到了一个真实案例，一个简短提示词膨胀成了数万个 token ID。这些都不是致命问题，但都需要工程时间，而一个成熟稳定的平台从不需要这些。另外，2.0 没有托管端点，也没有列出 NIM 打包方案，因此自行托管是唯一选择。

速度：两者都很快，一个是声称的

对于页面解析器而言，吞吐量才是真正能变现的数字。PaddleOCR-VL 的标称数字是单张 A100 上约每秒 1,881 个 token，该数据在 v1.0 发布时提出，且仍为厂商报告值——这一速度足以让 0.9B 模型经常被用于高吞吐量 OCR 场景。NVIDIA-Nemotron-Parse-2.0 是 0.9B 端到端模型，因此它天生就快，而生态也已在进一步推进：截至 8 月 5 日，一个处于评审中的 vLLM pull request 支持利用 NVIDIA 随权重一同发布的辅助预测头进行投机解码，报告称在 ParseBench 的 1,005 页数据上，H100 的中位输出吞吐量在并发为 1、8、32 时分别提升 45.65%、40.85% 和 39.60%。该 PR 尚未合并，也未被复现——请将这些百分比视为方向性参考，而非可引用的基准。

谁应该选哪个

• 如果您需要一个本季度即可落地的解析阶段，请选择 PaddleOCR-VL：支持中文或多语种 CJK 文档，表格与公式提取达到 SOTA 水平，支持 vLLM 或 Docker 部署，并且拥有可在会议中展示的榜单成绩。这是低风险的生产选型，也是语料以 CJK 为主的用户的最佳答案。

• 选择 NVIDIA-Nemotron-Parse-2.0 的条件是：您已经自托管 Nemotron Parse 系列——2.0 是 API 形态相同的无缝升级——或者您的语料库以印度文字或手写内容为主，并且您想测试该卡片的增量是否可复现，又或者您想判断专门的图表语义类是否值得投入实际工程时间。请为早期采用者的摩擦预留预算，并且在您自己的评估完成之前，不要将生产路径押注在它上面。

• 如果你的流水线确实是“先解析器、后LLM”——大多数都是如此——那就走中间路线。解析器是一个阶段；负责总结markdown、提取字段或回答检索问题的模型则是另一个独立阶段，而这第二个阶段正是路由平台的价值所在。本次对比中的两个解析器都不在OrcaRouter上——两者都是自托管的开放权重模型——但它们外围的那一层正是OrcaRouter的用武之地：200多个模型通过单一API提供，按提供商的标价收费，0%加价，所以供应商降价当天即可生效；如果某家提供商性能下降，还能自动故障转移。这条建议的实操版本是：如果你打算用一个未经证实的解析器来押注整个流水线，就让它周围的一切都保持可替换，这样从Parse 2.0迁移到PaddleOCR-VL或换用另一个LLM，就只是一次路由变更，而不是重写。

底线

这里的抉择实际上不是两种模型之间的选择——而是公开记录与私下宣称之间的选择。PaddleOCR-VL 1.6 是久经验证的开源权重 SOTA：在 OmniDocBench v1.6 上达到 96.33，支持 109 种语言，拥有成熟的推理服务栈，以及围绕它构建的生态系统。NVIDIA-Nemotron-Parse-2.0 则是低调的挑战者：发布仅五天，未经公告，仅支持自托管，其模型卡宣称在多语言和手写识别方面有巨大提升，但无人验证过。96.33 和 0.6391 无法直接比较，假装可以比较，正是团队最终引用含义不同数字的原因。如果你今天就要上线，就选 PaddleOCR-VL。如果你的语料库测试的重点是多语言能力，那么这个低调的挑战者值得用一个周末在你的自有文档上做一次低成本评估——这类差距要么被复现，要么被证伪，而一次低调发布正是探明结果的最便宜方式。

常见问题

我今天能在同一个基准测试上比较PaddleOCR-VL和NVIDIA-Nemotron-Parse-2.0吗？

这没有实际意义。PaddleOCR-VL 的 96.33 来自 OmniDocBench v1.6 综合基准——该领域共享的公共基准——而 Parse 2.0 的数字则出自 ParseBench（NVIDIA 的自家测试套件）、MOSCAR、IndicVisionBench 以及 OmniDocBench 的一个手写子集，且全部是厂商自报结果。目前没有任何第三方在 OmniDocBench 综合基准上独立跑过 Parse 2.0，也没有任何人在 ParseBench 上跑过 PaddleOCR-VL。两者唯一的交集是 OmniDocBench Notes 上的手写测试，但即便在该项上，两个模型报告的也是不同类型的分数。在第三方用共同基准对 Parse 2.0 进行评测之前，这种比较无异于拿苹果跟橙子比。

哪个模型处理中文和其他CJK文档的效果更好？

截至目前，从证据上看，{{1}}PaddleOCR-VL{{/1}} 明显领先，毫无悬念。百度的模型原生面向中日韩（CJK）文字设计，在领域内排名所用的基准测试上保持着公开的 SOTA 成绩，并且在中文古籍、生僻字和印章识别方面拥有有据可查的优势。{{2}}NVIDIA-Nemotron-Parse-2.0{{/2}} 的模型卡声称相比 v1.2 在 CJK 和 Indic（印度系文字）上有大幅提升，但这些数字是厂商自报的，尚未经过独立测试。如果你需要解析这些文字，这个说法值得验证；但它目前还不是一个可以依赖的结果。

这两个模型都免费使用吗？我该如何运行它们？

两者都是允许商业使用的免费权重——PaddleOCR-VL 采用 Apache 2.0 许可证，Parse 2.0 采用 NVIDIA 开放模型许可证——但二者都不是路由平台上的托管 API，而且 Parse 2.0 完全没有托管选项。PaddleOCR-VL 可以原生运行在 vLLM 中、通过百度的官方 Docker 部署运行，也可以通过 PaddleOCR 网站和百度云 API 使用。Parse 2.0 必须自行托管，需要支持 Nemotron Parse 远程代码的 vLLM 构建版本，外加 tied-output-head 补丁和 tokenizer 修复。无论采用哪种方式，解析阶段都需要你自己负责；路由层增加的是其后的 LLM 阶段，在这一阶段，你希望可以自由切换模型，而无需重新设计整个流水线。