作者：来自 Elastic jina.ai/reader
一个 34 亿参数的混合专家文档解析器，每个 token 仅激活 5.7 亿个参数。它读取页面图像，并通过单次处理返回包含文本、公式、表格和阅读顺序的 Markdown。jina-ocr-v1 是一个拥有 34 亿参数、每次激活 5.7 亿参数的 视觉语言 模型，在 OmniDocBench v1.6 上得分 91.1，在 olmOCR-Bench 上得分 83.4。
我们发布了 jina-ocr-v1，这是一个 34 亿参数 的文档解析器，每个 token 约有 5.7 亿个激活的解码器参数 。它在 OmniDocBench v1.6 上获得 91.14 分 ，在 olmOCR-Bench 上获得 83.4 分 ；在 2.57 页/秒 的速度下，它是我们测试的 14 个系统中页面吞吐量最高的系统。在 NVIDIA L4 上，其推测解码头几乎可以将解码速度提高一倍，同时保持无损解码。
该模型基于 DeepSeek-OCR 的压缩视觉编码器和混合专家解码器，并在此基础上增加了两项改进。FastMTP 草稿头递归应用一个模块，执行三步预测，因此草稿参数不会随着深度增加。训练后阶段采用密集型可验证奖励，每项检查都是针对参考结果运行的确定性代码，并且每项检查都会进行评分。在这一基础架构之上，训练后阶段使 olmOCR-Bench 的得分提高了 7.4 分，并改善了 OmniDocBench 的每一项指标。
三个决定部署成本的维度。
(a) 每个视觉 token 对应的像素数，采用对数刻度。DeepEncoder 将一个 1024×1024 的视图从 4,096 个图像块压缩为 256 个 token，因此每个视觉 token 对应 3,887 个像素；相比之下，采用 28 到 32 px 图像块的编码器每个视觉 token 对应 783 到 1,022 个像素。
(b) olmOCR-Bench 上的页面吞吐量，使用一块 A100，并发数为 32。
(c) 基于激活参数量的基准测试总体表现，采用对数刻度，其中实线连接 Pareto 最优系统。 jina-ocr-v1 在激活 5.7 亿参数时同时位于两条前沿线上。
在 olmOCR-Bench 上对相同的 14 个系统进行测试，使用一块 A100，并发数为 32，分别按照 (a) 每秒输出 token 数、(b) 每页输出 token 数以及 (c) 每秒页面数进行排名，其中每秒页面数是前两项的比值。Surya OCR 2 以每秒 3,760 个 token 的速度在每秒输出 token 数方面领先，但每页输出 3,568 个 token，每秒完成 1.05 页。 jina-ocr-v1 将每秒 2,792 个 token 与每页 1,085 个 token 相结合，达到每秒 2.57 页。
模型与训练
长输出是导致文档解析解码成本高昂的主要原因。DeepSeek-OCR 通过压缩视觉编码器和紧凑型混合专家解码器消除了大部分这类成本，而 jina-ocr-v1 继承了这两项设计，并针对剩余的自回归瓶颈进行优化。
架构。DeepEncoder 和 MoE 解码器沿用了 DeepSeek-OCR 的设计，一个页面生成一个 1024×1024 的全局视图，对应 256 个视觉 token，此外还有 n 个局部图块，每个图块包含 100 个 token。FastMTP 头以橙色显示，通过一个共享的草稿模块提出 K = 3 个 token，由解码器进行验证。
OCR 输出近似确定性，并且具有局部结构，这使其非常适合采用推测解码。通常的构建方式是在每个预测深度附加一个草稿头，因此草稿参数量会随着模型向前预测的步数增加而增长。FastMTP 使用一个单独的稠密模块递归执行 K = 3 步。验证器会贪心地检查每个预测结果，并接受草稿模型与验证器一致的最长前缀，因此最终提交的序列与验证器的贪心序列完全一致，推测解码只会改变输出所需的时间。
| 组件 | 规格 |
|---|---|
| 视觉编码器 | DeepEncoder（约 3.8 亿）：SAM（8,000 万）→ 16x 卷积 → CLIP-L（3 亿） |
| 视觉 token | 1024x1024 下 256 个（Base）；256+100n，n ≤ 9（Gundam，每页 ≤ 1,156 个） |
| 解码器 | DeepSeek-3B-MoE：12 层，d = 1280，64 个路由专家 + 2 个共享专家，top-6 |
| 激活参数 / 总参数 | 约 5.7 亿 / 约 30 亿（解码器）；< 10 亿 / 约 34 亿（整个模型） |
| 词汇表 | 129,280 |
| 位置限制 | 32,768（RoPE，θ = 106） |
| MTP 头 | 1 个共享稠密模块，递归执行 K = 3 步（FastMTP） |
模型规格。解码器输出 Markdown，其中表格使用 HTML，公式使用 LaTeX。
训练数据来自包括 olmOCR-mix、FinePDFs、LightOnOCR、MMTab 和 UniMER 在内的公开 OCR 数据集，同时还加入了 Europeana 报纸、美国国会图书馆（Library of Congress）文字记录以及 NARA 养老金档案等刻意选择的高难度数据源。基于规则的过滤器会删除退化循环和重复数据，视觉语言处理流程则会对这些高难度数据源重新标注。我们还专门合成页面，原因只有一个：在自然页面中，公式和表格奖励项只适用于极少量样本，因此大多数 rollout 都不会携带结构信号。JinaOCRSynth 为每个页面填充可评分的公式和表格，并随之提供单元测试。
训练后阶段包括监督对齐、针对退化页面的鲁棒性 微调 以及 GRPO，并在外层循环的多个轮次中重复执行。GRPO 奖励由多个可验证项相乘得到，每一项都通过确定性代码与参考转录结果进行比较计算。
| 组件 | 信号 | 作用 |
|---|---|---|
| 内容 | 混合 LaTeX/HTML 上的归一化编辑距离 | 文本保真度 |
| 公式 | 公式字符串匹配 | 公式正确性 |
| 表格 | TEDS、TEDS-S、表格编辑距离 | 结构恢复 |
| 结构有效性 | 括号平衡、标签闭合、表格完整性 | 格式规范性 |
| 单元测试 | 通过 olmOCR 风格的存在性、顺序、数学公式和表格测试的比例 | 密集反馈 |
| 重复与格式 | 重复惩罚、HTML 一致性 | 退化控制 |
乘法式奖励组合。大多数项都设置了下限，因为在乘法组合下，一项检查失败就会让原本正确的页面失去梯度。重复项没有设置下限，因为退化循环是最容易人为抬高内容得分的失败模式。
每一轮都会留下一个候选检查点池。一个 agent 在固定的评估预算下搜索合并配置，并使用单元测试和编辑距离检查对其进行评分；所选合并中的错误会推动下一轮数据收集。最后才训练草稿头，训练所使用的验证器就是循环最终选出的验证器。
结果
| 模型 | 参数量 | 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 列用于测试文本缺失情况，并会对省略页眉和页脚的结果给予更高评价，因此忠实转录整页内容的模型在这一项上的得分会较低。
| 方法 | 参数量 | 总体 ↑ | 文本编辑距离 ↓ | 公式 CDM ↑ | 表格 TEDS ↑ | 表格 TEDS-S ↑ | 阅读顺序编辑距离 ↓ |
|---|---|---|---|---|---|---|---|
| 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 在仅激活 5.7 亿参数的情况下达到 91.14 分，在每一项指标上都领先于 DeepSeek-OCR-2 ，并超过了参数规模大得多的 Qwen3-VL-235B。
L4 上的推测解码
| 模式 | k | 输出 tok/s ↑ | 加速比 S ↑ | 接受率 | τ | c = τ/S ↓ |
|---|---|---|---|---|---|---|
| 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 |
FastMTP 在 olmOCR-Bench、NVIDIA L4、 vLLM 0.20.1、批量大小为 1 的条件下运行。τ 是每个推测步骤提交的平均 token 数，其中包括额外的 bonus token；c = τ/S，是一次推测步骤以一次自回归步骤为单位的成本。测试使用的设备与上述数据所使用的设备不同。
草稿质量与执行模式无关，因为在 k = 3 时，Eager 模式下的 τ 为 2.73，而在 CUDA graphs 下为 2.74。基线则有所不同。CUDA graphs 将自回归解码速度从每秒 42.7 个 token 提高到每秒 158.3 个 token，而一次推测步骤的开销保持在约 9 ms，因此其成本从 1.40 个自回归步骤上升到 2.51 个自回归步骤。收益取决于其所替代的验证器步骤的成本，因此在 Eager 模式下最佳深度为 k = 3，而在 CUDA graphs 下最佳深度为 k = 1。
开始使用
最快的运行方式是使用 Jina Reader。将 URL 指向 r.jina.ai，并添加一个标头：Reader 会获取页面或 PDF，对其进行渲染，在结果上运行 jina-ocr-v1，然后返回 Markdown。无需部署，无需编写图像处理流程，并且使用与平台其他部分相同的 API key。
bash
`
1. curl "https://r.jina.ai/https://example.com/document.pdf" \
2. -H "Authorization: Bearer $JINA_API_KEY" \
3. -H "X-Respond-With: jina-ocr-v1"
`AI写代码添加 X-Page 可以转录多页文档中的单个页面。这两个参数都位于 Reader API 编辑器中，切换开关后会自动为你写入标头。
如果要直接访问模型，托管端点与 OpenAI 兼容，只需要从 jina.ai 获取一个 API key。
arduino
`
1. curl https://api.jina.ai/v1/chat/completions \
2. -H "Content-Type: application/json" \
3. -H "Authorization: Bearer ***" \
4. -d '{
5. "model": "jina-ocr-v1",
6. "messages": [{
7. "role": "user",
8. "content": [
9. {"type": "text", "text": "将提供的文档图像转录为整洁的 Markdown 格式，同时保留自然阅读顺序。"},
10. {"type": "image_url", "image_url": {"url": "https://example.com/document.png"}}
11. ]
12. }]
13. }'
`AI写代码
如果要自行部署，模型权重和自定义建模代码都包含在同一个 Hugging Face 仓库中，并通过 trust_remote_code=True 加载。FastMTP 需要 vLLM 0.21 或更高版本，并且需要在引擎启动之前进行一次性架构注册。
python
`
1. import sys
2. from huggingface_hub import snapshot_download
3. from PIL import Image
4. from vllm import LLM
6. sys.path.insert(0, snapshot_download('jinaai/jina-ocr-v1'))
7. from deepseek_ocr_mtp import DEFAULT_OCR_PROMPT, register, vllm_llm_kwargs, vllm_sampling_params
9. register()
10. llm = LLM(**vllm_llm_kwargs('jinaai/jina-ocr-v1',
11. num_speculative_tokens=3,
12. mtp_heads=1,
13. mtp_recursive=True))
15. image = Image.open('document.png').convert('RGB')
16. outputs = llm.chat(
17. [{'role': 'user', 'content': [{'type': 'image_pil', 'image_pil': image},
18. {'type': 'text', 'text': DEFAULT_OCR_PROMPT}]}],
19. sampling_params=vllm_sampling_params(max_tokens=4096),
20. )
21. print(outputs[0].outputs[0].text)
`AI写代码有一个细节决定了加速效果能否显现。该辅助函数使用 method="eagle" 注册该头，因为 FastMTP 是通过递归隐藏状态反馈进行训练的，而默认的 method="mtp" 会让每个草稿步骤都重新以目标模型为基础。Transformers 路径仅运行 MoE 解码器，并忽略 MTP 权重。
该模型还支持表格和公式的元素级转录、图注生成、文档 VQA 和关键信息提取，并支持英语和中文。模型权重以 CC BY-NC 4.0 许可发布。
结论
在仅激活 5.7 亿参数的情况下，jina-ocr-v1 位于两个基准测试的参数量与准确率前沿线上，并且在我们测量的系统中具有最高的页面吞吐量。两个因素实现了这一效果，而且都不需要更大的模型：对每项可验证检查给予分级奖励，以及针对最终验证器训练的草稿头。
输出长度值得进一步关注。token 吞吐量和页面吞吐量对系统的排名方式不同，而输出长度与解析质量相互独立，因此可以单独优化简洁性。在所有得分超过 83 分的系统中，jina-ocr-v1 的输出最短。