DeepSeek-OCR

把 OCR 重新定义成"视觉文本压缩"——一个 VLM 吃下整页文档，端到端输出

更新于 2026-08-06 · 2026/01/27 发布 OCR2

一句话定位

不叫 OCR，叫"上下文光学压缩"——重新审视视觉编码器的角色

DeepSeek 官方开源的视觉语言模型，用单一 VLM 端到端处理图片和 PDF 的文字识别。核心创新是 Contexts Optical Compression（上下文光学压缩）——从 LLM 中心视角研究 vision encoder 如何高效压缩视觉文本。不走传统 OCR 多模型串联路线，一个模型搞定版面、公式、表格、多语种。

核心数据

并发推理吞吐约 2500 tokens/s（单卡 A100-40G）。已被 vLLM 上游官方支持。

Contexts Optical Compression

传统 OCR 是"检测文字 → 识别文字"的流水线。DeepSeek-OCR 换了个视角：OCR 的本质是把图像里的文字信息，压缩成 LLM 能理解的 token 序列。既然如此，何不直接用 VLM 做端到端的"光学压缩"？

端到端 vs 多模型串联

技术特点

• vLLM 官方支持：已合入 vLLM 上游，支持 prefix caching、并发批处理
• N-gram Logits Processor：专用解码加速，ngram_size=30 / window_size=90，白名单 token 优化表格输出
• 双推理后端：vLLM（高吞吐生产）+ Transformers（研究灵活）
• 图像 + PDF 双模：流式输出图像 OCR，PDF 批量并发解析
• 批量评测支持：内置 benchmark 批跑脚本，方便在自有数据集上验证
• 环境要求：CUDA 11.8 + torch 2.6.0 + flash-attn 2.7.3，Python 3.12

vLLM 推理

# 环境：CUDA 11.8 + torch 2.6.0
from vllm import LLM, SamplingParams
from vllm.model_executor.models.deepseek_ocr import NGramPerReqLogitsProcessor
from PIL import Image

llm = LLM(model="deepseek-ai/DeepSeek-OCR",
          enable_prefix_caching=False,
          mm_processor_cache_gb=0,
          logits_processors=[NGramPerReqLogitsProcessor])

image = Image.open("doc.png").convert("RGB")
prompt = "<image>\n Free OCR."

output = llm.generate(
    [{"prompt": prompt, "multi_modal_data": {"image": image}}],
    SamplingParams(temperature=0.0, max_tokens=8192,
                   extra_args=dict(ngram_size=30, window_size=90),
                   skip_special_tokens=False))
print(output[0].outputs[0].text)

PDF 解析光谱：三层关系

DeepSeek-OCR vs MinerU：同为 VLM，路线有别

三者组合：成本最优架构

不要二选一，组合使用才是生产最优解：

谁该用它

• 扫描件密集型业务：历史档案数字化、纸质合同归档、发票批量处理——单一 VLM 端到端最简洁
• VLM-OCR 研究者：研究 vision encoder 在 OCR 中的角色，论文可复现
• 追求 MIT License 的商用项目：比 MinerU（附加条件）/ PDF-Extract-Kit（AGPL）更宽松
• 已有 vLLM 基础设施的团队：原生 vLLM 支持，无缝接入现有推理服务

需要权衡的点

• 硬件门槛高：需 A100-40G 级别 GPU，纯 CPU 完全不可行（这点不如 MinerU 有 pipeline 后端）
• 偏研究阶段：仓库仅 7 commits，无 CLI/API/WebUI 工程封装，需自行包装
• 无原生 Office 支持：只处理图像和 PDF，DOCX/PPTX/XLSX 需先转 PDF（MinerU 原生支持）
• 环境依赖重：特定 CUDA 11.8 + torch 2.6.0 + flash-attn，版本耦合较紧
• 生态单薄：无 MCP Server、无 RAG 框架集成，需自己接

未来空间

DeepSeek 品牌 + MIT License + 学术创新的组合很有杀伤力。"单一 VLM 吃天下"的路线如果精度持续领先，可能倒逼 MinerU 这类多引擎方案简化。但当前工程成熟度不足，更适合作为 MinerU VLM 后端的替代/竞品来评估，而非直接上生产。

一句话带走

OCR 的未来可能就是一个 VLM——DeepSeek-OCR 是这条路线的旗舰样本。

如果你的文档以扫描件为主、追求单模型简洁、能接受自己搭工程，DeepSeek-OCR 值得一试。若要开箱即用的完整产品，MinerU 仍是更稳的选择。最佳实践是让 pdf-inspector 先把简单的 PDF 过滤掉，再让两者处理真正需要 OCR 的部分。