Nemotron Parse 2.0 對比 olmOCR：兩項工作，皆名為解析

2026年8月3日，NVIDIA 在 Hugging Face 上發布了一個新的文件解析模型，而且沒有告訴任何人。NVIDIA-Nemotron-Parse-2.0 是一個 0.9B 的視覺編碼器-解碼器，其模型卡宣稱與 2026 年 2 月的前代相比，在多語言和圖表感知方面有所飛躍；它落入了與 olmOCR 相同的生態系統角落——更精確地說，是 olmOCR-2-7B-1025，來自艾倫人工智慧研究所的 7B 線性化器，這款模型已悄悄成為將 PDF 轉換為 LLM 訓練資料的預設方式。把這說成正面交鋒本身就是個陷阱：這兩個模型都被描述為「文件解析」，但它們返回不同的產出、餵養不同的管線，而且它們的基準測試數字從未真正對上。真正的問題是，你雇用解析器來做的，是兩件工作當中的哪一件。

這兩件文物

Nemotron Parse 2.0 是一個版面語意引擎。輸入頁面影像與任務提示詞後，它會回傳文字，並在其上疊加一層語意層：每個區域的版面類別（標題、章節、圖說、表格、圖表、頁首、頁尾、註腳、參考文獻條目）、每個區域的邊界框，以及它們之間的閱讀順序——另外可選擇以 Markdown 作為上層的序列化格式。olmOCR 2 是一個線性化器。它接受相同的頁面，回傳乾淨、線性化的 Markdown，並附帶簡短的 YAML frontmatter，記錄頁面層級的中繼資料，例如主要語言、旋轉校正，以及頁面是否為表格或圖表。沒有邊界框、沒有類別、沒有幾何資訊：一次處理，文字依文件順序輸出。

產物決定任務。如果你的流程需要將事實引用回頁面的某個區域、在掃描檔上標示表格，或為文件智慧提取版面語意，你就需要幾何——這就是 Nemotron Parse 2.0 的輸出空間。如果你在建構訓練資料，或要餵給只消費 token 的文字 LLM，幾何只是雜訊，線性化的 markdown 才是完全正確的選擇——這就是 olmOCR 的整體設計。你可以用獨立的偵測器將版面偵測附加到 olmOCR 的輸出上，也可以丟棄 Nemotron Parse 2.0 的邊界框、只保留 markdown，但每個模型都是為了讓其中一種任務成為原生能力而打造的。

沉默之船：repo 顯示了什麼，又有哪些尚未證實

2026年8月3日，NVIDIA-Nemotron-Parse-2.0 出現在 Hugging Face 上，沒有公告、沒有部落格文章，也沒有 NIM 套件。能確知的只有該儲存庫。它是一個 0.9B 的視覺編碼器-解碼器：基於 NVIDIA 的 C-RADIO 骨幹建構的 ViT-H 影像編碼器、一個輕量級一維卷積適配器，以及一個十層 mBART 風格解碼器。詞元器擴充了約 20,000 個詞條，總數約達 72,000 個，明確是為了更有效率的多語言支援；模型卡將圖表感知解析列為首要功能，透過新的 class_Chart 詞元實現，此外還有一系列表格序列化格式（LaTeX、HTML、markdown、JSON、階層式 JSON、CSV）。隨附兩個可選的 logits 處理器：一個用於停止重複的結構化輸出，另一個用於在表格裁切上強制套用表格結構。建議的輸入解析度範圍約從 1024×1280 到 1664×2048，生成長度上限為 9,000 個詞元；模型卡列出 Transformers、vLLM、SGLang 和 Docker Model Runner 作為執行環境，支援 Ampere、Hopper、Blackwell 和 Turing 硬體。

然而，這些宣稱都是 NVIDIA 自己的說法，且沒有一項經過獨立重現驗證。模型卡報告 ParseBench 總體分數為 0.6391（高於 v1.2 的 0.5782）、MOSCAR 多語言 OCR 的 BoC-F1 為 0.9102（高於 0.4410）、IndicVisionBench 的 ANLS-character 為 0.7203（高於 0.0612），以及 OmniDocBench 手寫子集在文字編輯距離上從 0.9739 改善至 0.3395。這些是最大的躍升，卻也是最缺乏驗證的部分：ParseBench 是 NVIDIA 自家的評測套件，尚無第三方以獨立語料庫執行過 Parse 2.0。未獲確認的不止於分數——目前沒有託管推論服務（模型卡聲明該模型尚未由任何推論供應商部署）、沒有定價，兩者也皆未公布時程。

olmOCR 2：所有人早已以它為衡量標準的現任者

olmOCR 是發明這個類別現今所爭論之基準的模型。olmOCR-2-7B-1025 於 2025 年 10 月 22 日發布，是一個 7B 參數的視覺語言模型，基於 Qwen2.5-VL-7B-Instruct，在 270,000 頁的 olmOCR-mix-1025 語料庫上進行微調，隨後透過 GRPO 強化學習，針對自動化「單元測試」獎勵進行改良——這些確定性檢查用於確認表格是否保持結構、公式是否精確轉錄、閱讀順序是否維持。這套單元測試框架後來成為 olmOCR-Bench，包含約 1,400 份 PDF 與超過 7,000 項檢查，並已成為業界事實上的標竿：Marker、MinerU 以及十餘個商業 OCR 模型現在都在其上發布成績。olmOCR 2 本身在那裡獲得 82.4 的總分，比先前版本高出約 4 分，也高於 AI2 在同一頁面上引用的 Marker（76.1）與 MinerU（75.8）分數。

olmOCR 也是這組配對中較成熟的選項。它採用 Apache-2.0 授權，其權重在過去一個月內已被下載約 218,000 次，而 olmOCR 工具包在 vLLM 後端上處理大規模的渲染、旋轉與重試——AI2 的批次估算將管線成本定在租用 GPU 上每百萬頁約 176–190 美元，而 FP8 版本在單張 H100 上每秒可運行約 3,400 個輸出 token，速度快到發布文章中引述「不到 2 美元即可處理 10,000 頁」。其取捨在於語言：olmOCR 是明確針對英文數位化印刷品所建置並進行基準測試的，其模型卡也將其標註為英文。Nemotron Parse 2.0 的整個賣點則恰恰相反——它所宣稱的優勢集中在 CJK 與印度系文字（Indic scripts）上。

顯示權衡取捨的六列

兩個模型都是開放權重，兩者都能在 Transformers、vLLM 或 SGLang 上運行，且兩者目前都可自行託管。就選擇兩者時重要的考量維度而言：

• 大小 — Nemotron Parse 2.0 為 0.9B；olmOCR 2 為 7B。參數量約為八倍，VRAM 最低需求也約為八倍。

• 輸出 — Nemotron Parse 2.0 返回文字、版面類別、邊界框、閱讀順序和 Markdown；olmOCR 2 返回帶有 YAML 元資料區塊的線性化 Markdown。

• 多語言 — Nemotron Parse 2.0 宣稱對 CJK 與印度語系有強大支援（MOSCAR 0.9102、IndicVisionBench 0.7203，廠商回報）；olmOCR 2 則以英文為優先。

「旗艦分數 — Nemotron Parse 2.0 報告 ParseBench 分數 0.6391（NVIDIA 自行發布、未經稽核）；olmOCR 2 在 olmOCR-Bench 上得分 82.4（AI2 自行發布，十個月來獲社群反覆使用）。」

• 授權 — Nemotron Parse 2.0 根據 NVIDIA 開放模型授權（NVIDIA Open Model License）發布；olmOCR 2 則為 Apache-2.0。

• 已發布 — Nemotron Parse 2.0 於 2026 年 8 月 3 日未經預告即推出；olmOCR 2 則於 2025 年 10 月 22 日發布，並附有發布文章。

這個決定實際上會造成衝擊的三個地方

{{1}}規模與延遲。{{/1}}0.9B 解碼器的服務成本遠低於 7B VLM：所需 GPU 更小、VRAM 更少、同一硬體上每秒可處理的頁面更多，而且當你按 GPU 時間付費時，每頁成本也更低。如果你已經具備 GPU 基礎設施，而且語料庫很大，每月就會出現實質差異。olmOCR 自己的數據顯示，FP8 量化可以讓 7B 模型達到多快的速度——但要達到這些數字，仍需要 H100 等級的 GPU；Nemotron Parse 2.0 的硬體門檻則是 Ampere 世代的顯示卡。

多語言。這是最不對稱的一行。Nemotron Parse 2.0 專門為多語言 OCR 將其 tokenizer 擴充了大約 20,000 個詞條，而且其模型卡所宣稱的性能提升主要集中在印度系文字和 CJK。olmOCR 2 沒有這樣的宣稱——它的語言標籤是英文。如果你的語料庫是印地語、坦米爾語、孟加拉語、日語或混合文字，Nemotron Parse 2.0 的數據才是值得測試的，正因為它們是廠商報告的最新數據。

服務的現實。olmOCR 2 已滿十個月，其工具鏈平淡無奇，但這是一件好事。Nemotron Parse 2.0 才推出五天，其服務面明顯還很新：vLLM 需要一個支援 Nemotron Parse 遠端程式碼的建置版本，緊綁的輸出頭會導致某些 vLLM 0.20 建置出錯（儲存庫附帶一個執行時期修補程式），而且 tokenizer.json 帶有序列化的填充至 9,000 個 token——在修補之前，某個服務堆疊遇到一個六 token 的提示詞擴展成 54,000 個 token ID。這些都不是致命的，但這正是你在使用新模型時預期會遇到的那種摩擦。

為您的管線挑選一個。

如果您正在建構 LLM 訓練資料，或為英文文件建置高吞吐量的文字擷取管線，請選擇 olmOCR 2。您會獲得成熟的工具組、Apache-2.0 授權、業界現今衡量的標竿，以及一條經過充分驗證的批次處理路徑。其公認的弱點是語言覆蓋範圍。

如果您的管道需要幾何能力——版面類別、邊界框，以及用於接地檢索或文件智慧的閱讀順序——或者您的語料庫以印度語系、中日韓或手寫頁面為主（這些是它宣稱的優勢所在），請選擇 Nemotron Parse 2.0。0.9B 的模型規模讓週末測試的成本很低，即使您不確定也值得一試。其公認的失敗模式是：規格表上的每個數字都是 NVIDIA 自家數據，在獨立評估下可能會有所變動。

如果你的輸入大多是以英文為主的原生數位 PDF，而你只需要乾淨的 markdown，那麼 olmOCR 2 是風險較低的預設選擇。如果你已經自行託管，而且多語言或版面基礎的使用案例確實存在，那麼 Nemotron Parse 2.0 是更有趣的選擇——在投入之前，先在你自己的頁面上測試看看。

避免解析器選擇成為鎖定

文件管道包含一個解析器階段，接著是 LLM 階段；一旦實際流量成形，解析器通常是最便宜的環節——真正讓成本隨規模成長的，是將解析後的 markdown 轉成摘要、結構化記錄或答案的 LLM。這正是路由層所改變的階段。OrcaRouter 將 200 多個模型放在單一 API 後面，以供應商牌價計費且不另加價，因此供應商降價當天立即生效；自動故障轉移也能避免單一供應商效能衰退拖住批次作業。本次比較中的兩個解析器都不在我們的目錄上——兩者的模型卡都聲明它們未由任何推論供應商部署，所以這是個自行託管的決定——但讓解析器與你的模型技術堆疊保持解耦，正是路由在下游端帶來的價值：將 Nemotron Parse 2.0 換成 olmOCR 2，或換回來，都不必動到任何一個整合，因為 LLM 層始終留在同一個單一金鑰 API 之後。

常見問題

哪個模型在基準測試中勝出？

兩者都不是——這些數據並非直接對比。Nemotron Parse 2.0 報告了 ParseBench、MOSCAR、IndicVisionBench，以及 OmniDocBench 的手寫子集，這些都是 NVIDIA 自家的基準，且沒有一項經獨立重現。olmOCR 2 報告了 olmOCR-Bench，這是 AI2 自家的基準，業界其他參與者現在也都以此發布結果。沒有第三方在相同的語料庫上跑過這兩個模型，因此任何直接的「贏家」說法都只是推斷。就趨勢而言：olmOCR 的數據歷經十個月的社群使用考驗；Nemotron Parse 2.0 的數據則是新的，可能還會變動。

Nemotron Parse 2.0 在處理非英語文件上真的更好嗎？

這就是宣稱——約 20,000 個 token 的詞彙擴充，加上 MOSCAR 達到 0.9102 與 IndicVisionBench 達到 0.7203，兩者皆為供應商報告的數據，且相較 v1.2 都有大幅提升。olmOCR 2 並未做出多語言宣稱，且被標記為英文。但在獨立評測出爐之前，請將 Nemotron Parse 2.0 的多語言成果視為有前景但未經證實，並在依賴它們之前，先在你自己的 Indic 或中日韓（CJK）頁面上進行測試。

我需要為其中一個使用更大的 GPU 嗎？

是的，它會追蹤尺寸差異。Nemotron Parse 2.0 的 0.9B 模型可安裝在普通的 Ampere 世代顯示卡上，而且在您既有硬體上，是每頁成本更低的選擇。olmOCR 2 的 7B VLM 則需要更大的 GPU；根據 AI2 的說法，其 FP8 版本在 H100 上每秒可產生約 3,400 個輸出 token。

哪一個比較適合 RAG 預處理？

這取決於你的檢索器需要什麼。如果你要將答案對應回頁面區域、需要版面類別，或想將表格和圖表作為獨立單元來索引，Nemotron Parse 2.0 的邊界框和類別原生就能滿足這些需求。如果你的 RAG 技術棧僅需處理乾淨文字，且語料庫為英文，olmOCR 2 的線性化 Markdown 已獲驗證、更為簡單，並有成熟工具鏈作為後盾。

重點

NVIDIA 本週默默推出了一款真正的解析器，沒有告知任何人；AI2 十個月前就推出了類似產品，並為這個類別樹立了標竿。當你需要版面語意、多語言支援，或是在預算有限的情況下進行手寫文字擷取時，Nemotron Parse 2.0 是更合適的選擇——而它數據最未經驗證的領域，恰恰就是它聲稱佔優勢的領域。當你需要大規模線性化英文文件文字，並希望使用一套已穩定運行十個月的工具鏈時，olmOCR 2 是更合適的選擇。兩者目前都未在任何環境中實際部署，所以無論如何這都是自架主機的決策；最省錢的做法，就是同時在你最困難的頁面上運行這兩套系統，觀察各自在哪裡失靈。