jina-ocr-v1：在低成本 GPU 上更快解析文档

魔搭ModelScope社区

8人浏览 · 2026-09-24 23:03:32

魔搭ModelScope社区 · 2026-09-24 23:03:32 发布

动图封面

HF 🤗 https://huggingface.co/jinaai/jina-ocr-v1
魔搭 🧙 https://modelscope.cn/models/jinaai/jina-ocr-v1
技术报告 📖 https://arxiv.org/abs/2609.03181
API 💻 https://jina.ai/models/jina-ocr-v1

Jina-OCR-v1正式开源！

这是一个总参数 3.4B，解码时每个 Token 仅激活 570M 的紧凑型端到端文档解析模型。在 OmniDocBench v1.6 (91.14) 与 olmOCR-Bench (83.4) 两大基准上，它均刷新了同级别最佳成绩；在 14 款主流端到端系统的吞吐实测中，它以 2.57 页/秒领跑全场。

在单张 NVIDIA L4 这样的低成本显卡上，通过专门设计的推测解码草稿头，生成速度 几乎翻了一倍，而且输出序列与标准自回归解码严格一致，完全无损。

团队延续了 DeepSeek-OCR 的紧凑视觉编码与 MoE 解码路线，重点做了两处改动：

FastMTP：用单个共享 dense block 递归前向 K=3 步生成候选 token，草稿参数量与前瞻深度解耦，不再随 lookahead 增长；
Dense Verifiable Rewards（GRPO）：每一项奖励都由确定性代码对照参考真值计算，并按部分正确程度分级给分，而非简单的 0/1 判定。

仅靠后训练改进，模型在 olmOCR-Bench 上就涨了 7.4 分，OmniDocBench 各细分维度也全面提升。

(a) 统计了单个视觉 Token 分摊的像素面积（对数坐标）：DeepEncoder 将 1024×1024 画面直接从 4,096 个 Patch 压缩至 256 个 Token，平均单 Token 承载 3,887 像素；相比之下，主流编码器单 Token 仅覆盖 783~1,022 像素。前置压缩比越高，多模态 Prefill 阶段的计算与自回归期间视觉上下文占用的 KV Cache 就越低。

(b) 图是单张 A100、并发 32，olmOCR-Bench 上每秒做完几页。

14 个系统在单张 A100、并发 32 下的实测对比：(a) 每秒输出 token 数、(b) 每页输出 token 数、(c) 每秒处理页数（即 a 除以 b）。

Surya OCR 2 每秒能吐出 3,760 个 token，看起来最快，但单页要写 3,568 个 token，算下来实际吞吐只有 1.05 页/秒；而 jina-ocr-v1 输出极其精炼，1,085 tokens/页，配合 2,792 tokens/s 的生成速度，端到端吞吐达到了 2.57 页/秒。

模型与训练

文档解析在实际生产中最烧钱的环节，就是长序列的逐 token 生成（自回归解码）。

DeepSeek-OCR 已经帮团队砍掉了前置开销：它用高压缩视觉编码器配紧凑 MoE 解码器，把视觉 token 和激活参数压到了极低水平。jina-ocr-v1 继承了这套底座，将优化重点直接对准剩下的自回归生成瓶颈。

上面是整体架构图。

DeepEncoder 与 MoE 解码器延续 DeepSeek-OCR：单页先生成 1024x1024 全局视图（压缩为 256 个视觉 token），再切出 n 个局部 tile（每个 tile 100 个 token）。FastMTP 头（橙色）通过单个共享稠密块递归前向，一次提出 K = 3 个候选 token 交给主解码器验证。

文档 OCR 有个天然优势：排版局部结构高度确定，预测难度低，天生适合做推测解码（Speculative Decoding）。

传统的多 token 预测（MTP）方案很笨重：每多看一步就要多挂一个独立 draft head，前瞻越远参数越膨胀。团队用 FastMTP 换了个思路。只用一个共享 dense block，靠 hidden state 反馈递归执行 K=3 步前向预测，参数量与 lookahead 解耦。

因此，推测解码产出的文本与主模型直接自回归贪心生成完全一样：只提速，不降质。

组件	规格
视觉编码器	DeepEncoder (~380M): SAM (80M) → 16x conv → CLIP-L (300M)
视觉 Token	256 @ 1024x1024 (Base); 256+100n, n ≤ 9 (Gundam, ≤ 1,156/page)
解码器	DeepSeek-3B-MoE：12 层，d = 1280，64 个路由专家 + 2 个共享专家，top-6
激活参数 / 总参数	~570M / ~3B（解码器）；< 1B / ~3.4B（整个模型）
词表	129,280
位置上限	32,768 (RoPE, θ = 106)
MTP 头	1 个共享稠密块，递归 K = 3 步（FastMTP）

输出格式统一为 Markdown，表格使用 HTML 结构，公式使用 LaTeX 语法。

预训练语料混合了主流公开 OCR 数据集（olmOCR-mix、FinePDFs、LightOnOCR、MMTab、UniMER 等），并针对性补充了高难度真实排版源，例如 Europeana 历史报纸、美国国会图书馆缩微文献和 NARA 档案。清洗时先用规则过滤掉死循环与重复退化内容，再用高精度视觉大模型做单次前向重打标。

为什么必须引入合成数据（JinaOCRSynth）？

真实文档里的复杂公式和深层表格分布太稀疏了。在强化学习（RL）阶段，如果直接用自然页面做采样探索（rollout），绝大多数样本根本碰不到几个结构奖励项，梯度直接停滞。JinaOCRSynth 专门在合成页面中高密度塞入结构化表格和公式，并自带单元测试断言，给训练提供充足信号。

后训练流程由监督微调（SFT）、长尾劣化页面鲁棒性微调以及 GRPO 强化学习交替迭代。GRPO 阶段的奖励函数由多个确定性可验证项相乘得出：

组件	信号	作用
内容	混合 LaTeX/HTML 上的归一化编辑距离	文本保真度
公式	公式字符串匹配	公式正确性
表格	TEDS、TEDS-S、表格编辑距离	结构还原
结构有效性	花括号配对、标签闭合、表格完整性	格式规范
单元测试	olmOCR 风格的存在性、顺序、数学与表格测试通过率	高密度反馈
重复与格式	重复惩罚、HTML 符合性	退化控制

总奖励是各项乘法，这相当于一票否决：任何一项得零分，整页产生的梯度就直接清零。

对大部分检查项（文本、公式、表格），团队都设置了底线分（floor score），允许局部扰动，避免单项偶发失误毁掉整页更新。
唯独重复惩罚坚决不设下限：因为自回归模型很容易靠陷入死循环复读来投机“刷高”局部文本重合度。只要出现这种退化死循环，直接给零分一票否决。

每轮迭代会产生一批候选检查点。团队用自动化 agent 在固定评测预算下搜索最佳模型融合（checkpoint merge）配比；优胜模型暴露出的错误案例，直接驱动下一轮数据的针对性采集。FastMTP 草稿头放在整个训练循环的最后，直接在最终定型的验证器上完成拟合。

评测结果

模型	参数	ArXiv	OldScans-Math	Tables	OldScans	Multi-col	LongTiny	Hdr/Ftr	Base	总分
Gemini 3 Flash	–	80.1	73.6	64.6	45.8	75.3	90.3	27.4	–	–
Qwen3-VL-235B	235B/22B	88.4	81.2	86.7	49.6	85.9	88.9	33.6	–	–
DeepSeek-OCR	3B/570M	77.5	74.5	77.3	33.1	67.3	83.0	96.1	99.3	76.0
dots.mocr	3B	85.9	85.5	90.7	48.2	85.3	81.6	94.0	99.7	83.9
olmOCR-2	8B	82.9	82.1	84.3	48.3	84.3	81.4	–	99.7	82.4
LightOnOCR-2	1B	89.6	85.6	89.0	42.2	84.8	91.4	19.7	99.6	83.2
chandra-ocr-2	4B	86.9	89.1	92.1	51.1	82.1	93.7	91.4	99.9	85.8
jina-ocr-v1	3B/570M	86.1	82.3	88.8	42.6	85.5	93.2	88.7	99.9	83.4

在 olmOCR-Bench 上，jina-ocr-v1 拿到 83.4 分，比基座 DeepSeek-OCR 高出 7.4 分，也超过了 8B 规模的 olmOCR-2。

这里说明一下 Hdr/Ftr（页眉/页脚）这一列：该基准的设计偏向剔除边角杂质，越是主动省略页眉页脚的模型得分越高；老老实实整页转录的系统在这项上反而会扣分。

方法	参数	总分 ↑	TextEdit ↓	FormulaCDM ↑	TableTEDS ↑	TableTEDS-S ↑	ROEdit ↓
Gemini 3 Flash	–	92.62	0.066	95.16	89.29	93.51	0.172
Qwen3-VL-235B	235B/22B	89.78	0.063	92.55	83.07	86.75	0.166
DeepSeek-OCR-2	3B/570M	90.25	0.050	91.84	83.89	87.75	0.144
HunyuanOCR-1.5	1B	94.74	0.039	94.50	93.67	94.71	0.129
PaddleOCR-VL-1.6	0.9B	96.34	0.033	97.53	94.76	97.10	0.128
jina-ocr-v1	3B/570M	91.14	0.046	93.28	84.68	89.01	0.142

在 OmniDocBench v1.6 评测中，jina-ocr-v1 以 570M 激活参数拿到 91.14 分，各项指标全面领先 DeepSeek-OCR-2，也超过了参数大得多的 Qwen3-VL-235B。

在 L4 上的推测解码实测

模式	k	输出Token/秒 ↑	加速比 S ↑	接受率	τ	c ↓
Eager	0	42.7	1.00x	–	–	1.00
Eager	1	64.0	1.50x	82.6%	1.83	1.22
Eager	2	77.9	1.82x	69.1%	2.38	1.30
Eager	3	83.1	1.95x	57.6%	2.73	1.40
Graph	0	158.3	1.00x	–	–	1.00
Graph	1	185.6	1.17x	82.9%	1.83	1.56
Graph	2	183.8	1.16x	69.3%	2.38	2.05
Graph	3	172.9	1.09x	57.9%	2.74	2.51

测试环境：olmOCR-Bench，单卡 NVIDIA L4，vLLM 0.20.1，并发 batch size = 1。τ 代表单次推测平均接受的 token 数（含验证带出的 bonus token）；c = τ/S 是单个推测步折算成多少步标准自回归。

这里有一条工程经验：基线自回归跑得越快，留给推测解码的边际收益空间就越窄。

先看 τ。k = 3 时，Eager 是 2.73，CUDA Graph 是 2.74，说明 draft head 质量根本不受运行环境影响。两边的最优前瞻步数却走到了两个极端，一个拉满 k=3 最快，一个退到 k=1 才快。

在 Eager 模式下（CPU 调度受限，主模型太慢）：原生自回归单步要 23.4ms，大半时间耗在 CPU 一遍遍发射 CUDA kernel。这时让 draft head 一次多带几个 token，等于少付几次发射税。所以激进推测最合适， k = 3 最优，加速 1.95x。
在 CUDA Graph 模式下（显存带宽受限主导）：Graph 打包了 kernel 发射，自回归单步耗时只需要 6.3ms（吞吐从 42.7 跃升至 158.3 tokens/s）。但推测解码由于有动态分支，依然要承担 9ms 的固定开销。此时多猜一步的成本已经比再生成一个 Token 更贵了，前瞻收益被严重摊薄。因此在 Graph 模式下，单步推测 k = 1 才是收益最高的最优解（1.17x）。

生产部署建议：无法使用 CUDA Graph 的环境（或轻量 Eager 实例）直接拉满 k = 3；已经跑通 CUDA Graph 环境下，只开 k = 1。

快速上手

最简单的调用方式是走 Jina Reader API。

直接把文档或网页 URL 传给 r.jina.ai，并附带对应请求头：Reader 会自动抓取、渲染并调用 jina-ocr-v1，直接返回 Markdown：

curl "https://r.jina.ai/https://example.com/document.pdf" \
  -H "Authorization: Bearer $JINA_API_KEY" \
  -H "X-Respond-With: jina-ocr-v1"

如果只要转录多页 PDF 中的某一页，加一个 X-Page 请求头即可。这两项开关在 Reader Web 控制台 https://jina.ai/reader/ 都支持可视化勾选。

若要直接调用模型，托管端点完全兼容 OpenAI 接口规范：

curl https://api.jina.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ***" \
  -d '{
    "model": "jina-ocr-v1",
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "Transcribe the provided document image into a clean Markdown format, preserving the natural reading order."},
        {"type": "image_url", "image_url": {"url": "https://example.com/document.png"}}
      ]
    }]
  }'

Document OCR
把扫描页、照片或 PDF 转成干净 Markdown，表格和公式一并带上。
团队准备了一个 demo，方便先 vibe check。
https://jina.ai/api-dashboard/document-ocr-test

若要在本地私有化部署，权重与自定义建模代码均托管在 Hugging Face，加载时指定trust_remote_code=True。启用 FastMTP 推测加速需要 vLLM 0.21 以上，且在启动引擎前注册一次架构：

import sys
from huggingface_hub import snapshot_download
from PIL import Image
from vllm import LLM

sys.path.insert(0, snapshot_download('jinaai/jina-ocr-v1'))
from deepseek_ocr_mtp import DEFAULT_OCR_PROMPT, register, vllm_llm_kwargs, vllm_sampling_params

register()
llm = LLM(**vllm_llm_kwargs('jinaai/jina-ocr-v1',
                            num_speculative_tokens=3,
                            mtp_heads=1,
                            mtp_recursive=True))

image = Image.open('document.png').convert('RGB')
outputs = llm.chat(
    [{'role': 'user', 'content': [{'type': 'image_pil', 'image_pil': image},
                                  {'type': 'text', 'text': DEFAULT_OCR_PROMPT}]}],
    sampling_params=vllm_sampling_params(max_tokens=4096),
)
print(outputs[0].outputs[0].text)

部署避坑提示：

显式指定 method="eagle"：FastMTP 草稿头是用递归隐状态反馈训练出来的。如果误用 vLLM 默认的 method="mtp"，引擎会在每步草稿时重新对齐目标特征，导致推测加速失效。团队的注册辅助函数已经默认处理好了这一点。
原生 Transformers 不会加速：如果仅通过 Hugging Face 的 transformers 库加载，只会执行主 MoE 解码器，FastMTP 草稿权重会被直接忽略。想要翻倍吞吐，请使用 vLLM。

模型同时支持表格和数学公式的逐元素提取、图像图注生成、文档 VQA（视觉问答）以及关键信息抽取，中英文双语均支持。

模型权重遵循 CC BY-NC 4.0 协议开源。