Jina AI 发布 jina-ocr-v1：它真正卖的不是识别率

先看结果：它把优势放在单位页面成本

先把对象说清楚：Jina AI（Elastic 旗下）发布了 jina-ocr-v1，一款端到端视觉文档解析模型。它面向 PDF、扫描件、表格、图表和发票，把页面直接转成 Markdown；公开权重约 6.8GB（BF16），可经 Transformers 或 vLLM 运行。发布者把它放在低预算 GPU 场景里，尤其是 NVIDIA L4，而不是只把它包装成一张新的 OCR 榜单。

原始材料给出的最强信号不是最高准确率，而是吞吐。Jina 在一张 A100 40GB、并发 32 的测试中报告每秒 2.57 页，高于同一对比里的 olmOCR-2（1.22 页/秒）和 chandra-ocr-2（0.38 页/秒）。模型每页输出约 1,085 个 token；Jina 还称，在得分超过 83 的系统里，这是最短的输出之一。对批量 PDF、发票或扫描件来说，短输出和高吞吐可能比再多几个榜单小数点更直接地影响 GPU 账单。

低预算 GPU 上的结果更能说明它的定位。L4 的 eager decoding 从每秒 42.7 个 token 提升到 83.1 个，FastMTP 的接受率为 57.6%，相对普通贪心解码约 1.95 倍；打开 CUDA graphs 后基线本来就更快，K=1 的收益约为 1.17 倍。也就是说，“1.95 倍”不是一个脱离配置的固定倍率，而是特定硬件、批大小和解码路径下的测量结果。

速度不是一个技巧，而是三层协同

第一层是视觉输入。DeepEncoder 把 1024×1024 页面视图里的 4,096 个图像 patch 压成 256 个视觉 token；遇到密集页面，动态分辨率模式最多再加 9 个局部 tile，每个 tile 增加 100 个 token，整页上限为 1,156 个视觉 token。它没有让复杂页面免费，而是把更多细节只放到确实需要的位置。

第二层是 MoE 解码器。jina-ocr-v1 沿用 DeepSeek-OCR 的 3B MoE 路线，包含 64 个路由专家和 2 个共享专家，每个 token 只激活 Top-6 路由专家，约 570M 参数参与计算；但全部权重仍要驻留显存。第三层才是 FastMTP：一个稠密草稿块递归预测最多 3 个 token，主解码器一次验证，保留与自己贪心选择相同的最长前缀。三层叠加的含义是，省下来的并不只是某一个算子，而是输入、每步计算和输出步数。

FastMTP 为什么适合 OCR

推测解码通常依赖一个小模型先猜、大模型再验。OCR 的特殊之处在于，输出往往不是开放式创作，而是页面文字、表格标记、公式和格式符号组成的局部规律序列。只要草稿足够经常猜中，主模型就可以一次检查多个 token，而不用每次只生成一个。Jina 给出的 K=3 测试里，平均每个解码步骤提交 2.73 个 token；如果三个草稿全部通过，还会多提交一个主模型自己的 token。

这里的“无损”要准确理解：它保证最终文本等同于普通贪心解码，不代表识别质量因此变好。收益也不覆盖所有运行方式。原始材料明确提到，Transformers 路径会忽略草稿权重，FastMTP 需要 vLLM 0.21 以上并完成一次注册。模型卡、运行时和硬件配置必须一起验证，不能只下载 6.8GB 的 BF16 权重就推断出同样的吞吐。

训练阶段把“看起来对”拆成了可检查的错误

这套路线的另一半在后训练。Jina 把指令对齐、退化页面鲁棒性微调和 GRPO 接在一起，并用确定性代码检查内容、公式、表格、结构有效性、重复、格式和单元测试。奖励项采用乘法组合，结构、单元测试和格式项有 0.2 的下限，表格项有 0.1 的下限；一次检查失败不会直接抹掉页面其他部分的正确性，但重复项不设下限，因为循环输出可能人为抬高内容分数。

为让公式和表格错误出现得足够频繁，Jina 还构造了包含这些结构的合成页面，并给它们配套测试。这个做法的价值不在于“用了 GRPO”这句标签，而在于把 OCR 最容易被人眼睛忽略、却最容易破坏下游流程的错误，变成训练时能反复计算的信号。它也是一个提醒：文档解析的质量不能只用“像不像原文”描述，还要看表格是否可解析、公式是否可复用、输出是否通过后续工具链。

榜单说明了它的取舍，而不是宣布它全面领先

jina-ocr-v1 在 OmniDocBench v1.6 上得到 91.14，在 olmOCR-Bench 上得到 83.4；它的优势主要落在吞吐和部署成本，而不是每一个准确率维度。原始对照里，PaddleOCR-VL-1.6 的 OmniDocBench 得分是 96.34，HunyuanOCR-1.5 为 94.74；chandra-ocr-2 在 olmOCR-Bench 上是 85.8，dots.mocr 为 83.9。jina-ocr-v1 仍然比 DeepSeek-OCR 的 76.0 高 7.4 分，但这支持的是“在质量可接受的前提下换取效率”，不是“所有任务都应该换过去”。

因此它更适合被放进受控的工程评估：固定一批真实文档，分别记录单位显卡吞吐、输出长度、表格和公式错误率，以及 FastMTP 在长文档和复杂版式上的接受率。若目标是最高识别质量，必须把它和同一数据集、同一后处理链路里的竞品比较；若目标是降低单位页面成本，则需要把运行时、许可证和完整服务链一起算进去。

三条上手路径，也对应三种风险

最快的验证方式是使用 Jina Reader：给 r.jina.ai 一个 URL，并在请求头里指定 X-Respond-With: jina-ocr-v1；如果只想看长文档的一页，还可以使用 X-Page。第二条是 Jina 的 OpenAI 兼容接口，适合先把调用方式接进已有程序。第三条才是自托管：从 Hugging Face 获取权重和自定义代码，用 trust_remote_code=True 加载；需要 FastMTP 时，还要准备 vLLM 0.21 以上和注册步骤。

这三条路径的成本和证据强度不同。Reader 和托管接口适合快速确认输出形态，却不能证明自有 GPU 上的单位成本；自托管能测到真实吞吐，却要承担显存、运行时和许可证边界。最容易被忽略的是 CC BY-NC 4.0：公开权重可用于研究和非商业用途，商业部署需要联系 Jina AI。低显存可运行只是入场券，不能替代采购、合规和质量验证。