「NVIDIA-Nemotron-Parse-2.0 vs PaddleOCR-VL」標題卡:主標題「NVIDIA-Nemotron-Parse-2.0 vs PaddleOCR-VL」,副標題「低調挑戰者 vs 實證 SOTA」,描述「兩個開放權重頁面解析器 · 一場生產級賭注」,旁有兩份文件頁面的扁平插圖,含短文本行與彩色邊界框,其一標示為實證的現任者,另一標示為低調的新進者。OrcaRouter 標誌合成於右下角。
Guides & Insights

NVIDIA-Nemotron-Parse-2.0 對決 PaddleOCR-VL:低調挑戰者 vs 經實證的 SOTA

作者

Rowan Sterling

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

文件解析正處於開放權重 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,一次完成。沒有需要安裝、調整或版本管理的獨立版面階段。

Architecture diagram comparing two page-parsing designs: left panel 'PaddleOCR-VL — two-stage' flowing Layout (PP-DocLayoutV3 detects elements & reading order) to Recognize (ERNIE-4.5-0.3B VLM reads each region) to Output (markdown · boxes · classes); right panel 'NVIDIA-Nemotron-Parse-2.0 — end-to-end' flowing Encode (ViT-H C-RADIOv2 maps page to tokens) to Decode (mBART decoder emits text · boxes · markdown). OrcaRouter logo composited bottom-right.

規格表相應記載如下:

• 架構 — 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 Open Model License,其 tokenizer 採用 CC-BY-4.0。兩者皆允許商業使用。

Comparison scoreboard for PaddleOCR-VL 1.6 vs NVIDIA-Nemotron-Parse-2.0. PaddleOCR-VL rows: OmniDocBench v1.6 96.33 (SOTA), 0.9B two-stage, 109 languages shipped, released May 28 2026 (1.6), Apache 2.0, vLLM native + official Docker. Nemotron Parse 2.0 rows: ParseBench 0.6391 (vendor-only), 0.9B end-to-end, CJK/Indic deltas claimed, released Aug 3 2026 unannounced, NVIDIA Open Model, remote-code vLLM patches needed. Footer: 'PaddleOCR-VL scores per OmniDocBench v1.6; Nemotron Parse 2.0 figures vendor-reported, no independent run.' OrcaRouter logo composited bottom-right.

基準測試的問題:96.33% 對比一個無人能查證的數字

這是對決不再只是比較,而變成採購問題的部分。

PaddleOCR-VL 目前的版本 PaddleOCR-VL 1.6(發布日期為 2026 年 5 月 28 日)在 OmniDocBench v1.6 上報告了 96.33% 的成績——該基準是文字、公式與表格辨識加上閱讀順序預測的綜合評測——並在 Real5-OmniDocBench 上獲得 93.19%,這是針對彎曲、歪斜及螢幕翻拍頁面的穩健性變體,百度表示其領先 Gemini-3-Pro 將近四個百分點。這些是百度自己的數據,但它們是在該領域共同的公開基準上報告的,因此可以與 MinerU 2.5-Pro、GLM-OCR 以及排行榜上的其他項目進行排名。

The Hugging Face model card for nvidia/NVIDIA-Nemotron-Parse-2.0, showing the model description (document images into structured text, layout classes, bounding boxes, reading order), the roughly 20k-token vocabulary expansion over v1.2 for multilingual support plus chart-aware parsing, the nvidia-open-model-license tag, 0.9B params, and the note that the model isn't deployed by any inference provider.

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 在 PaddleOCR-VL 居冠的 OmniDocBench 綜合基準上的公開評測,也沒有 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宣稱的效能差異(delta)是它的規格卡上最引人注目的數字,而這正是那種要麼在你的資料上重現、要麼徹底崩潰的說法。目前還沒有人在任何公開的印度語系基準測試上跑過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)。該模型的輸出頭與解碼器嵌入綁定在一起,某些 vLLM 建置會處理不當,除非你加上 NVIDIA 隨附的執行時期修補程式。此外,隨附的 tokenizer.json 預設將填充(padding)內建為 9,000 個 token——一位 Dynamo 維護者在八月初就遇到實際案例,一個簡短提示詞暴漲成數萬個 token ID。這些都不是致命問題;但每一項都是成熟平台永遠不會要求的工程時間。此外,2.0 沒有列出任何託管端點,也沒有 NIM 套件,因此自架(self-hosting)是唯一選擇。

速度:兩者都快,一個聲稱

對頁面解析器來說,吞吐量才是真正變現的數字。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 時 45.65%、併發數 8 時 40.85%、併發數 32 時 39.60%。該 PR 尚未合併、也未經複現——請將這些百分比視為方向性參考,而非可直接引用的基準數據。

誰應該選哪個?

• 如果您需要一個本季度即可上線的解析階段,請選擇 PaddleOCR-VL:適合中文或 CJK 多語言文件、具備 SOTA 等級的表格與公式抽取、支援 vLLM 或 Docker 部署,並擁有可在會議中引用的排行榜成績。這是低風險的生產環境選擇,也是語料以 CJK 為主的任何人的最佳答案。

• 如果您已經自行託管 Nemotron Parse 系列,請選擇 NVIDIA-Nemotron-Parse-2.0 — 2.0 是可直接替換的升級版,API 結構相同 — 如果您的語料庫大量包含印度文字或手寫內容,且想測試該卡的差異能否重現,或想了解專用的圖表語義類別是否值得投入實際工程時間。請為早期採用者的摩擦做好預算,在您自己的評估完成之前,不要將生產路徑押注於此。

• 如果你的管線確實是「先解析器、後 LLM」——大多數情況正是如此——那就採取中間路線。解析器只是一個階段;負責摘要 Markdown、擷取欄位或回答檢索問題的模型是另一個獨立階段,而路由平台的價值正是在這第二個階段體現。本次比較中的兩個解析器都不在 OrcaRouter 上——兩者皆為自架的開放權重模型——但它們外圍的整合層正是 OrcaRouter 的用途所在:單一 API 背後串接 200+ 模型,按供應商列表價格計費,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文檔方面表現更好?

截至目前,就證據而言,PaddleOCR-VL 穩居首位,且差距明顯。百度的模型原生支援 CJK 文字,在該領域排名所用的基準上保持公開的 SOTA 成績,並在中文古文獻、生僻字與印章辨識方面有實證優勢。NVIDIA-Nemotron-Parse-2.0 的模型卡宣稱,相較於 v1.2,在 CJK 與印度系文字上有大幅進步;但這些數字為廠商自行回報,尚未經獨立測試。若你解析這些文字,此宣稱值得一測;但這還不是你能倚賴的結果。

這兩個模型都可以免費使用嗎?我該如何運行它們?

兩者皆為允許商業使用的免費權重——PaddleOCR-VL 採用 Apache 2.0 授權,Parse 2.0 採用 NVIDIA Open Model License——但兩者都不是路由平台上的託管 API,而且 Parse 2.0 完全沒有託管選項。PaddleOCR-VL 可原生在 vLLM 中運行,可透過百度官方 Docker 部署,也可經由 PaddleOCR 網站和百度雲端 API 使用。Parse 2.0 必須自行託管,需要使用支援 Nemotron Parse 遠端程式碼的 vLLM 版本,並加上 tied-output-head 修補程式與 tokenizer 修正。無論如何,解析階段都得由你自行負責;路由層所增添的是其後的 LLM 階段,而在那個階段中,你會希望擁有自由切換模型的彈性,不必重新改造整個流程。