jina-ocr-v1 - 面向高效部署的端到端文档解析 OCR 模型

jina-ocr-v1 是 jinaai 发布的一个端到端文档解析模型，在 Hugging Face 上的任务类型标注为 image-text-to-text，使用 transformers 框架。据项目自述，它的目标是在一个「高效的服务点」上提供高质量 OCR：把文档图像直接转写成结构化文本（默认是 Markdown），而不是先做版面检测、再做文字识别、最后拼接的多段式流水线。它适合需要批量处理扫描件、PDF 页面、票据或手写稿，并且对推理成本敏感的开发者与团队；也适合只想调一个托管接口、不想自己部署模型的用户。

维护者与状态

该模型由 jinaai 维护，仓库托管在 Hugging Face。创建时间为 2026-09-01，最后更新时间为 2026-09-18。截至 2026-09-22 的数据读取时间，近 30 天下载量为 2615，点赞数为 139。事实表中没有给出正式 release 信息，因此这里不对版本节奏做任何推断，具体权重与代码状态以仓库当前快照为准。

主要能力

以下能力均来自项目自述（README / 模型卡），并非第三方评测结论。

• 端到端文档解析：据项目说明，模型直接接收文档图像并输出文本，默认提示词要求转写为干净 Markdown 并保持自然阅读顺序。
• 骨干结构：项目自述其建立在 DeepSeek-OCR 之上，继承两个面向效率的组件——DeepEncoder 视觉塔，用 256 个视觉 token 表示 1024×1024 的全局视图，并辅以动态局部切片；以及一个 3B 参数的混合专家（MoE）解码器，每 token 约 570M 激活参数。
• FastMTP 推测解码：据项目说明，在骨干之上增加了一个 FastMTP 推测解码头，把一个稠密草稿块在 K=3 个预测步上递归共享；贪心验证接受最长的 token 相等前缀，从而在构造上保持验证器的贪心输出序列不变。项目自述该加速路径仅在 vLLM 后端可用。
• 提示词可控：README 给出了推荐默认提示词，以及一套更严格的评测用提示词，后者要求把公式转为 LaTeX、把表格转为 HTML、去掉页眉页脚与图形内容、保留参考文献与脚注，并读取自然手写。
• 多种调用形态：项目自述提供本地脚本、Jina Reader、OpenAI 兼容的托管接口以及 Playground 等入口。

需要强调的是，模型卡中列出的 OmniDocBench v1.6、olmOCR-Bench 分数与吞吐数字属于项目自述的评测结果，本栏目未做复现，也不对其准确性下结论。

使用入口

模型仓库地址为 jinaai/jina-ocr-v1。

据项目说明，仓库同时提供模型权重与加载所需的定制代码，需要以 trust_remote_code=True 方式加载，没有单独的安装包。本地运行可用一个脚本覆盖两种后端：

python example.py --backend transformers --image document.png
python example.py --backend vllm --image document.png

Transformers 路径需要安装 transformers、torch、torchvision、Pillow，每次调用处理一张 PIL 图像；项目提醒 eos / pad 来自 generation_config.json，不要另传新的 GenerationConfig。vLLM 路径据项目说明需要 vLLM ≥ 0.21，并在 LLM(...) 之前先调用一次 register()，同时把快照目录加入 sys.path，以便工作进程导入 deepseek_ocr_mtp。此外项目自述还有 Jina Reader、OpenAI 兼容的 chat/completions 接口与 Playground 三种托管方式，均使用同一套 API key。

许可与限制

许可证为 cc-by-nc-4.0。这是一个带有非商业限制的许可协议，使用前请自行确认你的场景是否落在许可范围内，并以仓库中的许可声明为准。

项目自述中提到的已知限制与前置条件包括：Transformers 路径下 generate() 只跑 3B MoE 解码器，不启用 FastMTP，加载时 mtp_module.*、mtp_embed_tokens.* 等键会被忽略；FastMTP 加速仅在 vLLM 后端生效，且需要一次性注册架构。托管接口在冷启动时可能返回 HTTP 503，项目建议等待 30–60 秒后重试。多页文档在 Reader 路径下需要用 X-Page 头指定单页（从 1 开始计数）。这些都属于项目自述的适用边界，实际表现请以你自己的文档与部署环境为准。