Jina AI发布jina-ocr-v1：基于DeepSeek-OCR微调的低

Jina AI @JinaAI_ 基于 DeepSeek-OCR 微调了 3.4B/A570M 端到端文档解析模型「jina-ocr-v1」 https://jina.ai/models/jina-ocr-v1/

一张低端 L4 GPU 即可部署，2.57 页/秒的吞吐数倍于同精度模型（chandra-ocr-2 仅 0.38、dots.mocr 0.55 页/秒），即便是精度更高的 Infinity-Parser2-Pro 也需要 H100 双卡才追到 0.47 页/秒；jina-ocr-v1 把整页文档一次性转为高质量 Markdown，在“解析质量”和“处理速度”这两个维度上都有很强表现。

核心思路：OCR 是“可预测的生成”，所以可以投机 OCR 输出的下一个 token 高度可预测（表格、公式的结构都是模式化的），这正是投机解码（speculative decoding）的理想场景。团队没有去堆模型规模，而把工程重心放在解码成本上（生产中真正花钱的部分）。这个定位决定了它后续的所有设计。

架构：小视觉开销 + 稀疏解码器 + 投机头 · 视觉端（约 3.8 亿参数）：SAM 阶段 + 16× 卷积压缩 + CLIP-L 阶段。一页 1024×1024 的图像只占 256 个视觉 token；开启 Gundam 动态分辨率后，每个额外 tile 只加约 100 token，单页上限约 1,156 token。视觉 token 少意味着送入解码器的内容少，解码快。 · 解码端：DeepSeek-3B MoE，总参数约 3.4B，但每个 token 只激活约 5.7 亿参数（64 路由专家 + 2 共享专家，top-6 路由）。 · FastMTP 投机头：这是最核心的改动。只用一个稠密 draft block 递归复用 K=3 步来起草草稿 token，再用贪心验证保留最长匹配前缀——结果与普通自回归解码完全无损一致。在 L4 上把解码速度翻倍（42.7 → 83.1 token/s，接受率 57.6%，平均每次验证提交 2.7 个 token）。

训练：三阶段后训练 + 稠密可验证奖励 基础数据来自 olmOCR-mix、FinePDFs、DoclingMatrix、UniMER 等，加上针对历史档案（Europeana、美国国会图书馆、NARA）的合成页面。后训练分三步：指令对齐 → 针对退化/困难文档的鲁棒性微调 → 带稠密可验证奖励的 GRPO（对公式、表格、结构做确定性检查并给部分得分）。这个“部分得分”的设计值得注意：OCR 输出很难全对或全错，稠密的奖励信号比 0/1 判断能提供更有效的学习梯度。

性能：精度第一梯队边缘，吞吐领先明显 · olmOCR-Bench 83.4：基础文本 99.9（并列最佳）、长小字 93.2、表格 88.8；短板是陈旧扫描件 42.6，古旧/严重退化文档仍需人工复核。 · OmniDocBench v1.6 综合 91.14：文本编辑距离 0.046、公式 CDM 93.28、表格 TEDS 84.68、阅读顺序编辑距离 0.142。 · 吞吐 2.57 页/秒（A100、并发 32）——约为 olmOCR-2 的两倍。对比中，Infinity-Parser2-Pro 精度更高（87.6）但每页要 2.13 秒且需 H100 双卡；chandra-ocr-2 精度 85.8 但吞吐仅 0.38 页/秒。jina-ocr-v1 在“质量-吞吐”帕累托前沿上占据了低价高吞吐的位置。

使用与局限 · 输入单页图像/PDF，输出 Markdown（含 LaTeX 公式、HTML 表格）；按设计丢弃页眉页脚和图片，跨页句子会接续，无文本时输出 null。 · 部署路径齐全：Transformers、vLLM（投机解码仅在 vLLM 可用，注意要用 "eagle" 而非 "mtp" 配置）、SGLang、Docker，以及 Jina 自家 OpenAI 兼容 API。 · 定位上是 Jina 文档工具链的一环：HTML 转 Markdown 用 ReaderLM-v2，解析结果检索用 jina-embeddings-v4。