Datalab 發布了 Marker v2，這是對其開源文件轉換管線的全面改寫。Marker 可將 PDF、圖片、PPTX、DOCX、XLSX、HTML 及 EPUB 檔案轉換為 markdown、JSON、HTML 或分塊格式——這些輸出格式可作為檢索增強生成（RAG）系統、LLM 訓練資料準備及企業知識管線的直接輸入，而解析精確度直接決定下游模型效能。Datalab 團隊圍繞近期數月發布的三個元件重建了該工具：Surya OCR 2、一個 2000 萬參數的快速版面模型，以及一個比前一版本快 3 倍的重建版 pdftext 引擎。

核心基準測試結果來自 olmOCR-bench，這是由 Allen AI（Ai2）建立的第三方基準測試。Marker v2 的平衡模式整體達到 76.0%，在原生數位 PDF 上達到 83.5%，在單張 B200 GPU 上維持每秒 2.9 頁的處理速度。這一吞吐量超過 MinerU 管線後端的 5 倍以上，後者得分為 72.7%，處理速度為每秒 0.54 頁。Docling 在同一測試框架下的得分為 50.3%，處理速度為每秒 2.1 頁。

Marker v2 的新功能

Marker v2 引入了三種轉換模式：

• 平衡模式（Balanced） — 由 Surya VLM 處理版面分析，當嵌入文字品質不佳時觸發整頁重新 OCR。這是品質最高的模式，針對 GPU 進行了優化。在 olmOCR-bench 上達到 76.0%。
• 快速模式（Fast） — 結合輕量級 rf-detr/onnx 版面偵測器與 pdftext，使用最少且精準的 VLM 呼叫。得分 66.6%，成本大幅降低。
• –disable_ocr — 純文字層提取，完全不使用 VLM 呼叫。完全在 CPU 上執行。得分 43.6%，速度 23.7 頁/秒。

模式選擇現已預設具備裝置感知能力：在 GPU 上使用平衡模式，在 CPU/MPS 上使用快速模式，可透過 –mode 手動覆寫。完整的 CPU 支援是第二項結構性變更——快速模式搭配 –disable_ocr 不需要 GPU 也不需要推論伺服器，但 2000 萬參數的版面模型仍能在 CPU 上解析欄位、表格和標題。

第三項架構變更驅動了吞吐量數據。多個輕量級 CPU 工作程序共享單一 Surya 推論伺服器，由父程序管理它們之間的 VLM 並行量。因此，吞吐量隨伺服器容量擴展，而非受單一程序的 VRAM 限制。Datalab 報告，平衡模式在同一硬體上維持約 2.9 頁/秒，而單一串流速率約為 0.3 頁/秒。

升級前有幾項值得注意的重大變更。現已需要 Python 3.10 以上版本。套件管理從 Poetry 遷移至 uv，以 hatchling 作為建置後端，但 pip install marker-pdf 保持不變。結構化提取轉換器和提取器已被移除；Datalab 引導使用者改用託管 API 或 –use_llm 工作流程。

基準測試方法論

評分基準測試使用 Ai2 的 olmOCR-bench，包含 1,403 個 PDF，約有 8,400 個通過/失敗單元測試，涵蓋數學公式渲染、表格結構、閱讀順序、頁首頁尾和舊式掃描件。整體分數為 8 個類別的巨集平均值，使用官方 olmOCR-bench 檢查器計算。吞吐量數據代表在單一 B200 主機上的持續並行頁/秒，而非單一串流延遲。

關於資料來源：olmOCR-bench 是 Ai2 的第三方基準測試，但所有分數和吞吐量數據均來自 Datalab 自行的測試執行。所有結果均可透過 Marker 儲存庫中的開放測試框架重現，該框架包含 MinerU、Docling 和 LiteParse 的競爭對手執行器以及 Marker 自身的執行器。這些數據反映的是單一基準測試的文件組合在單一硬體配置上的表現，因此在其他文件集上的結果可能不同。評估團隊應針對自身的文件集執行測試框架，以獲得有意義的比較。

Marker v2 vs MinerU

MinerU 的管線後端是架構上最接近的對應工具，兩者都讀取 PDF 文字層並選擇性地執行 OCR。在整體分數上，Marker 平衡模式以 76.0 對 72.7 領先。在原生數位文件上，兩者實際上打平：83.5 對 83.3。

有意義的差距在於吞吐量。Marker 平衡模式維持 2.9 頁/秒，而 MinerU 為 0.54 頁/秒——在更高準確度的同時達到 5.4 倍的差距。Marker 快速模式維持 7.4 頁/秒，約為 MinerU 管線速率的 13.7 倍，但代價是得分比 MinerU 低 6.1 分。

MinerU 還提供 VLM 後端，Datalab 指出其得分高於管線後端。該後端採用全頁 VLM 方法，未包含在此比較表中。評估 MinerU 的團隊應單獨對該選項進行基準測試。

Marker v2 vs Docling

Docling 在 GPU 管線中呈現最大的效能差距。Marker 平衡模式在整體上以 76.0 對 50.3 領先，在原生數位文件上以 83.5 對 64.0 領先，同時執行速度也更快：2.9 頁/秒對 2.1 頁/秒。Datalab 指出，Docling 是使用其預設管線進行評估的，該管線在原生數位頁面上使用文字層，在圖片區域使用 OCR。

Docling 的優勢在於治理和格式廣度，而非原始準確度。其程式碼庫採用 MIT 授權，源自 IBM Research，並作為 LF AI & Data Foundation 的專案託管。其支援的輸入格式不僅限於文件，還包括音訊和電子郵件。

Marker v2 vs LiteParse

LiteParse 由 LlamaIndex 團隊開發，是一個基於 Rust 的文件解析器，運作在根本不同的軸線上。在 CPU 上，其整體得分為 22.4，關閉 OCR 時為 20.4，而 Marker 的純 CPU 模式為 43.6。然而，LiteParse 在關閉 OCR 時的吞吐量為 1721 頁/秒——約為 Marker CPU 模式的 73 倍，這是一個明確的速度優先於結構的權衡。

Marker 的快速模式搭配 –disable_ocr 在 CPU 上執行 2000 萬參數的版面模型，仍能恢復文件結構，這解釋了為何其得分超過純文字傾印的兩倍以上。LiteParse 缺乏版面模型，在非線性文件版面上表現不佳。

Marker v2 vs 全頁 VLM 層級

Datalab 團隊強調，Marker 被設計為管線而非 VLM，指出這是不同類別的工具。這一區別具有實際意義：全頁 VLM 透過大型模型端到端處理每個文件影像，達到更高的準確度，但會產生隨規模累積的每頁運算或 API 成本。像 Marker 這樣的管線將任務分解為更便宜的專用階段，以犧牲峰值準確度換取吞吐量和成本控制。在此評估中，Datalab 的託管 Chandra 2 得分為 85.8，而透過 API 呼叫的 Gemini Flash 3.5 得分為 76.4。Datalab 的 Chandra 儲存庫還在一個單獨的表格中將 Ai2 的 olmOCR 2 定位於 82.4，dots.ocr 1.5 定位於 83.9。對於掃描件、數學密集頁面和達到最高準確度，VLM 層級仍然優於所有列出的管線。

值得注意的是，Marker 的平衡模式將差距縮小到僅落後 Gemini Flash 3.5 整體 0.4 分，並且在原生數位文件上以 83.5 對 79.1 的幅度超越它——且不需要逐頁 API 呼叫。

各類別行為分析

所選模式會影響失敗特徵，而不僅僅是整體分數。數學公式渲染是最顯著的差異化因素：快速模式從 PDF 文字層讀取方程式，而非使用 VLM-OCR，導致 arXiv 數學分數從 83.9 降至 23.4，而 –disable_ocr 在該類別中按設計得分 0.0。在兩個數學類別之外，舊式掃描件是每個模式中最弱的分項，最高僅達 43.2。

授權條款

四個系統的授權條款差異顯著，這對商業團隊有直接的影響——特別是因為文件解析通常服務於受監管的工作流程，其中來源可追溯性和授權合規性是可稽核的要求：

• Marker：程式碼採用 Apache 2.0 授權。模型權重使用修改版的 AI Pubs OpenRAIL-M 授權——對研究、個人使用和融資/營收低於 500 萬美元的新創公司免費。超過該門檻，商業使用權重需要付費授權。
• MinerU：現由 MinerU 開源授權管轄，基於 Apache 2.0 並附加額外條件。超過 1 億月活躍用戶或 2000 萬美元月營收需要單獨的商業授權，且基於其構建的線上服務必須披露此事實。
• Docling：MIT 授權，模型授權在其原始套件中單獨追蹤。
• LiteParse：開源，來自 run-llama，LlamaParse 定位為處理困難文件的付費雲端選項。

使用情境考量

基準測試分數本身並不能決定正確的工具。文件集類型、可用硬體、授權層級和所需輸出格式都是決策因素。大規模處理原生數位 PDF 的團隊可能會發現頂尖管線之間的準確度差異很小，而處理掃描文件、數學公式密集的學術論文或混合格式文件集的團隊則會看到更大的差異。團隊應根據自身的文件集和營運條件評估每個解析器。

所有基準測試和吞吐量數據均附有 Marker 儲存庫中可重現的 benchmarks/ 測試框架。

關鍵參考資源

• Marker v2 GitHub 發布頁面
• Datalab Marker v2 部落格文章
• X 上的公告
• olmOCR-bench 儲存庫 (Ai2)

來源：MarkTechPost