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 上每秒做完几页。
(c) 图的横轴是激活参数，纵轴是基准分。实线连的是帕累托前沿。570M 这个点上，jina-ocr-v1 精度和吞吐两个都位于帕累托前沿。
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 解耦。
因此，推测解码产出的文本与主模型直接自回归贪心生成完全一样：只提速，不降质。
输出格式统一为 Markdown，表格使用 HTML 结构，公式使用 LaTeX 语法。
预训练语料混合了主流公开 OCR 数据集（olmOCR-mix、FinePDFs、LightOnOCR、MMTab、UniMER 等），并针对性补充了高难度真实排版源，例如 Europeana 历史报纸、美国国会图书馆缩微文献和 NARA 档案。清洗时先用规则过滤掉死循环与重复退化内容，再用高精度视觉大模型做单次前向重打标。
为什么必须引入合成数据（JinaOCRSynth）？
真实文档里的复杂公式和深层表格分布太稀疏了。在强化学习（RL）阶段，如果直接用自然页面做采样探索（rollout），绝大多数样本根本碰不到几个结构奖励项，梯度直接停滞。JinaOCRSynth 专门在合成页面中高密度塞入结构化表格和公式，并自带单元测试断言，给训练提供充足信号。
后训练流程由监督微调（SFT）、长尾劣化页面鲁棒性微调以及 GRPO 强化学习交替迭代。GRPO 阶段的奖励函数由多个确定性可验证项相乘得出：
总奖励是各项乘法，这相当于一票否决：任何一项得零分，整页产生的梯度就直接清零。
- 对大部分检查项（文本、公式、表格），我们都设置了底线分（floor score），允许局部扰动，避免单项偶发失误毁掉整页更新。
- 唯独重复惩罚坚决不设下限：因为自回归模型很容易靠陷入死循环复读来投机“刷高”局部文本重合度。只要出现这种退化死循环，直接给零分一票否决。
每轮迭代会产生一批候选检查点。我们用自动化 agent 在固定评测预算下搜索最佳模型融合（checkpoint merge）配比；优胜模型暴露出的错误案例，直接驱动下一轮数据的针对性采集。FastMTP 草稿头放在整个训练循环的最后，直接在最终定型的验证器上完成拟合。
评测结果
在 olmOCR-Bench 上，jina-ocr-v1 拿到 83.4 分，比基座 DeepSeek-OCR 高出 7.4 分，也超过了 8B 规模的 olmOCR-2。
这里说明一下 Hdr/Ftr（页眉/页脚）这一列：该基准的设计偏向剔除边角杂质，越是主动省略页眉页脚的模型得分越高；老老实实整页转录的系统在这项上反而会扣分。
在 OmniDocBench v1.6 评测中，jina-ocr-v1 以 570M 激活参数拿到 91.14 分，各项指标全面领先 DeepSeek-OCR-2，也超过了参数大得多的 Qwen3-VL-235B。
在 L4 上的推测解码实测
测试环境：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 协议开源。