AI
Jina-OCR-v1：3.37B MoE 文件解析模型、FastMTP 與實際部署限制
Jina-OCR-v1 以 DeepSeek-OCR 為骨幹，約 3.37B 總參數、每 token 啟用約 570M，加入 FastMTP 後主打低成本文件解析。本文查核官方 benchmark 條件、非商業授權、custom code 風險，並納入評論區對繁中、手寫、表格、圖表與公式的實測疑問。
2026年9月20日4 分鐘閱讀👁 5
OCR / Document AI / Efficient Inference
Jina-OCR-v1：3.37B 總參數、每 token 約啟用 570M 的文件解析模型
Jina AI 以 DeepSeek-OCR 為骨幹，加入 FastMTP 投機解碼與可驗證獎勵後訓練，主打低成本 GPU 的文件轉 Markdown。官方報告 OmniDocBench v1.6 為 91.14、olmOCR-Bench 為 83.4；但 2.57 pages/s 是單張 A100、concurrency 32 的吞吐量，不等於單頁延遲，也不是所有硬體都能達到。
模型與官方主張
jinaai/jina-ocr-v1 是端到端文件解析模型，可把掃描頁面、PDF 頁面、表格與公式轉成結構化文字。Hugging Face API 顯示權重共有 3,372,238,080 個 BF16 參數；其 3B MoE decoder 每個 token 約啟用 570M 參數。這是「稀疏啟用」，不是整個模型只有 570M，也不代表記憶體占用等同 570M 模型。
| 項目 | 查核結果 | 解讀 |
|---|---|---|
| 架構 | DeepEncoder＋3B MoE decoder，約 570M active/token | 總權重仍約 3.37B；顯存、載入與分發成本不能只看 active parameters |
| FastMTP | 共享一個 draft block，遞迴預測 K=3；greedy verification | 官方稱維持 greedy output sequence；目前 FastMTP 路徑主要走 vLLM |
| OmniDocBench v1.6 | 91.14 overall | 論文與 model card 一致；Hugging Face API 標示該 metric verified:false |
| olmOCR-Bench | 83.4 overall，較 DeepSeek-OCR backbone +7.4 | 仍屬作者團隊公布結果，需用自己的文件集複測 |
| 吞吐量 | 2.57 pages/s | 條件是單張 A100、concurrency 32、olmOCR-Bench；不是一般桌機或單請求延遲 |
| L4 加速 | FastMTP 相較 greedy autoregressive decoding 接近 2× | 是相對加速描述，不等於 L4 也有 2.57 pages/s |
| 授權 | CC BY-NC 4.0 | 非商業授權；商業使用需聯絡 Jina AI |
為什麼快
- 視覺壓縮：1024×1024 全局視圖由 4,096 patches 壓成 256 visual tokens，另加動態局部 tiles。
- MoE 稀疏啟用：總模型約 3.37B，但每 token 約啟用 570M decoder 參數。
- FastMTP：draft head 每步先提出多個候選 token，再由主模型驗證可接受的最長前綴，降低逐 token 解碼成本。
- 後訓練：結合 instruction alignment、困難文件 robustness fine-tuning，以及對公式、表格與結構提供部分分數的 dense verifiable rewards。