摘要总结

💡DeepSeek-OCR采用“看图识字”的机制替代传统大模型“逐字阅读”的机制，在超长文本（比如读长文档、读书等）场景，实现保证内容识别精度的前提下，让算力成本降低将近10倍，并极大的提升模型计算效率、改善记忆负载；所以这次又是一次“降本增效”的升级。

以上是对DeepSeek-OCR的一个快速理解，这篇文章，我不去关注这项技术多牛逼和以及怎么实现的等相关的问题，更多的是站在产品经理实用的角度去理解DeepSeek-OCR，我将重点理解清楚如下几个问题：

1.DeepSeek-OCR到底解决了哪些目前存在的行业问题和痛点？与传统OCR的区别？

2.DeepSeek-OCR的性能和表现数据如何？

3.从应用层的角度看DeepSeek-OCR将影响哪些应用场景？

4.技术社区和专家观点评价

5.DeepSeek OCR将带来哪些行业思考？

6.企业和AI应用怎么使用？

1.AI应用领域目前存在的行业痛点

在实际的AI应用场景中，特别是办公场景，相信大家有大量的应用场景是跟文档（包括PDF和word文档等）有关的，比如阅读文档、基于文档的内容生成等，大模型在文档处理这个领域的技术，会影响到相当多的AI应用和使用场景，因此这个领域的痛点，也是一个普遍存在的行业痛点。

只要是做过跟文档处理相关的 AI 应用的朋友，都会知道文档处理是一个充满技术挑战的难题。以 AI 快研侠在实现 AI生成报告的场景为例，我们主要遇到了如下3个问题：

文档内容识别和信息提取问题

大家平时提交给大模型和AI应用的大部分文档里面，有很多是以PDF或者Word的格式存在的，通常这些文档里面可能不仅仅只有文字，还可能存在图片、图表、表格等比较复杂的内容。

这些内容大模型是无法直接识别和理解的，通用大模型目前只能处理文本信息的内容，所以现有的AI读文档的应用，实现机制大部分是只提取文档中的文本内容，然后把它们提交给大模型用于内容生成，而其中的图片、表格、图表这些基本上会被忽略，这就很容易导致信息丢失从而影响AI应用的效果的问题。

可是如果想要去识别这些信息，现有的方式主要是通过OCR和多模态大模型来处理，将信息提取转来转换成文本之后交给大模型，然而，这种方式的识别成本非常高，除了面向企业的应用场景有可能会使用之外，普通面向C端的产品基本不太可能使用这种方式来实现。

生成成本巨大和处理时间很长的问题

基于文档生成的场景还有一个普遍存在的问题，就是生成成本巨大的问题，比如大家随便上传几个文档，可能字数就会超过十几万字，和AI聊天的场景等不同的是，生成一篇长文的时候，其token的消耗很容易就会达到百万级别的消耗，所基于文档生成的场景也是一个非常消耗成本的应用场景。

因为处理的文件数量和字数比较多，所以也通常导致了模型需要很长时间去处理的问题，最后导致的结果就是生成文本的时候，用户需要更多的等待时间，从而影响用户的体验。

超长文本情况下，大模型出现失忆的问题会更严重

大家都知道，大模型存在上下文长度的窗口，一旦输入的内容太长，大模型就很容易出现失忆的情况，相信大家也经常会遇到，在使用chatgpt类产品用于文档对话问答的情况下，常常会出现对话了几轮之后模型就出现了失忆的情况，所以，失忆的问题也是AI应用场景经常需要面临的挑战。

2. DeepSeek OCR 如何解决以上的行业问题？

1.DS-OCR采用将文本“画”成图像再压缩读取的方式解决内容识别问题

对于文档内容识别的问题，DeepSeek OCR采用了光学压缩的机制来实现，该机制的实现方式是：

  1. 它先把长篇的文字内容“绘制”成一张（或多张）图像。
  2. 然后，利用视觉模型（后文会提到的 DeepEncoder）把这张信息量巨大的图像，压缩成极少数的“视觉 token”（你可以理解为“视觉信息单元”）。
  3. 最后，语言模型（解码器）再从这些高度浓缩的视觉 token 中，把原文解码并恢复出来。

这个方式相比传统OCR的识别方式，可以做到在保证识别率精度的情况下，把识别成本进一步压缩的更低，DeepSeek-OCR 的实验数据显示，**在 10 倍压缩率下（例如，把一篇 1000 个词的文章压缩成 100 个视觉 token），原文的恢复率高达 97%**，几乎做到了无损。

对于AI应用开发者来说，相当于我们拥有了一种成本更低的方式去解决文档识别的问题，因此对于AI应用层来说，DeepSeek-OCR是我们听到的福音；

2.“看图阅读”的方式极大提升信息处理效率，也降低了生成成本

光学压缩的方式，简单一点理解，就是用少量视觉token表示大量文本token，以此来大幅降低后续语言模型处理时的计算开销。

前面也提到，用这种方式实现的情况下，同样处理比如1000个文本token对应长度的内容（比如1700个汉字），之前的大模型处理的方式需要阅读1000个文本token，而视觉压缩的方式，只需要阅读100个视觉token，因此信息处理量明显下降，处理的效率大幅提升，同时也降低了生成成本。

通俗一点理解，这种方式的意义在于，它让AI从“逐字阅读”（处理海量的文本 token）转变为“看图阅读”（处理极少的视觉 token）。这就好比你看书时，不是一个字一个字地读，而是一眼扫过去就抓住了整页的核心内容，信息处理的效率得到了根本性的提升。

值得注意的是，前面部分节省的是OCR的成本，如果AI应用开发者放弃了支持图片和图表等信息识别的能力，这部分成本也没啥区别，但是文本处理部分是一定会发生的，Deepseek-OCR目前的机制，意味着可以让应用开发者在处理文本部分的成本就直接大幅下降（可能是降低10倍）。

3.改善大模型失忆的问题

前面提到，大模型失忆的主要问题是因为输入内容过长，超过了上下文长度而导致的，DeepSeek OCR 目前的实现方式直接通过视觉压缩的方式，可以把文本token的长度压缩10 倍，因此，这对于改善大模型失忆的问题大有裨益。

以下通过一张表清晰的对比为了解决文档识别的应用场景问题，传统的技术方案和DeepSeek-OCR方式的差异：

技术方案 OCR识别成本 大模型处理文本内容的成本 处理效率和大模型失忆问题
传统方案：（直接提取文本+OCR识别图表图片等转成文本）→将文本提交给大模型 传统OCR的识别成本贼贵，普通AI应用开发者基本用不起，也很难免费提供给用户使用 采用逐字阅读的方式，比如1000个文本可能需要处理1000个文本token 处理时间很久，且容易导致大模型失忆
DeepSeek OCR：将内容压缩成视觉token→视觉token解码 在保证97%的无损识别的情况下，大幅的降低识别成本 采用看图阅读的方式，将1000个文本token压缩成100个视觉token，处理成本更低 处理时间可能压缩10倍，改善大模型失忆问题。

一句话总结而言，DeepSeek OCR 让相当多的AI应用开发者在处理文档技术问题的时候，以更低的成本解决内容内别的问题，同时还降低了大模型文本输入的成本，提升响应的效率，以及环节了超长文本下大模型的失忆问题。

2.DeepSeek-OCR的性能和表现数据如何？

1.识别精度表现：10倍压缩的情况下，几乎无损精确识别

除了压缩成本等相关的问题，大家对于DeepSeek-OCR更加高度关注的是其识别精度的问题，目前在大家相对比较认可的Fox 基准测试（一个专门测量在不同压缩率下的精确文本匹配能力的测试）中，测试结果显示：

当使用 100 个视觉 token（作为压缩预算）时：

  1. 对于包含 600-700 个文本 token 的页面，压缩成100个视觉token的时候（约 6.7 倍压缩），模型精度高达 98.5%。
  2. 对于包含 900-1000 个文本 token 的页面（约 9.7 倍压缩），模型精度依然保持在 96.8%。
  3. 这说明在 10 倍左右的压缩率下，模型几乎是“无损”的。

当把压缩预算降低到 64 个视觉 token（意味着压缩率更高） 时，模型的表现如下：

  1. 精度会随着压缩率的增加（即页面上的字数变多）而下降。
  2. 当压缩率达到 19.7 倍时（处理 1200-1300 文本 token），精度会降至 59.1%。
  3. 这符合直觉：给的“信息预算”越少，能承载的原文信息就越有限。

表格：Fox [21] 基准测试中视觉-文本压缩率测试

Text Tokens Vision Tokens = 64 (Precision / Compression) Vision Tokens = 100 (Precision / Compression) Pages
600-700 96.5% / 10.5x 98.5% / 6.7x 7
700-800 93.8% / 11.8x 97.3% / 7.5x 28
800-900 83.8% / 13.2x 96.8% / 8.5x 28
900-1000 85.9% / 15.1x 96.8% / 9.7x 14
1000-1100 79.3% / 16.5x 91.5% / 10.6x 11
1100-1200 76.4% / 17.7x 89.8% / 11.3x 8
1200-1300 59.1% / 19.7x 87.1% / 12.6x 4

2.性能表现：达到SOTA，在OmniDocBench上表现优异

在业界公认的权威基准测试 OmniDocBench 上，deepseek-ocr取得了 SOTA（State-of-the-Art，即业界顶尖）的性能。

  1. 它用最少的 toke达到了顶尖的性能，也就是说可以使用最少的算力开销，实现精准的识别效果；
  2. 仅用 100 个视觉 token/页，就超过了同样优秀的 GOT-OCR 2.0（使用了 256 token）。
  3. 使用了不到 800 个视觉 token，就优于了平均使用近 7000 token/页 的 MinerU 2.0。

3.生产效率：单A100每天可处理超20万页

这个模型不仅效果好，而且“跑得快”。在生产环境中，单块 A100-40G 的 GPU 每天可以生成（处理）超过 20 万页的训练数据。这意味着它具备了大规模商业化落地的高吞吐量能力。

3.DeepSeek-OCR将影响哪些应用场景的发展？

宽泛一点讲，所有跟文档识别相关的应用场景，都会受益，个人认为，重点受益的场景主要包括如下：

  1. **办公文档的处理和生成场景：**比如AI阅读文档和报告，AI生成文档与报告，DeepResearch等应用领域；
  2. 纸质档案电子化：政府、银行、医院、图书馆的海量历史档案、病历、卷宗，可以被快速电子化并实现检索。
  3. 实时证件识别：在机场、酒店、银行柜台，自动识别身份证、护照、银行卡，实现自动填表和身份核验。
  4. 法律/知识产权检索：快速处理扫描版的判决书、专利说明书，用于法律检索和分析。
  5. 风控与打假：自动比对合同、发票、仓单上的关键字段，或者识别车牌、集装箱号，用于防伪和风险控制。

4.技术社区和专家观点评价

1.硅谷热议，被誉为“AI的JPEG时刻”

模型一经发布，就因为它 3B（30亿）参数的“小”规模、带来的指数级效能变革以及“大道至简”的设计思想，在硅谷引发了热议。

  1. 有人认为它甚至开源了谷歌 Gemini 商业机密的核心思路。
  2. 特斯拉前AI总监 Karpathy（卡帕西）也称赞其“图像比文字更适合 LLM 输入”。
  3. 行业内将其称为“AI的JPEG时刻”，意思是它像 JPEG 压缩图像一样，为 AI 处理和存储记忆开辟了一条全新的、高效的路径。

2.DeepSeek将模型连同权重开源，实现“把贵的东西做成白菜价”

DeepSeek 团队延续了他们一贯的风格，将这个强大的模型连同权重一起开源了。这相当于“把贵的东西做成白菜价”，让所有开发者都能享受到这项技术红利，这对于整个 AI 领域，特别是文档处理（Document AI）方向，是实用且重要的一步，所以也获得了广大AI应用开发者的好评；

3.争议：10倍压缩97%精度，需在实际工作负载中验证

DeepSeek 宣称的“10 倍压缩 97% 精度”是在特定基准（Fox）上测试的，这个声明是否能在用户实际的、五花八门的工作负载中同样成立，还需要大量的实践来验证。

4.争议：OCR是否已“基本解决”？

社区对于“OCR 是否已经被 LLM 基本解决了”这个问题，存在巨大争议：

  1. 正方观点（如 pietz）：认为 OCR 基本解决了。例如 Gemini 2.5 Flash Lite 已经能以极低成本（1000 页/$0.20）处理多种 OCR 任务。
  2. 反方观点（如 cahaya, carschno, mormegil）：坚决反驳。
  • 复杂表格：LLM 在转换包含多层标题、合并单元格、复选框的复杂表格时，仍然会频繁失败。
  • 手写体识别（HTR）：HTR 仍然非常困难。LLM 在处理手写体时，经常会“幻觉”出看似正确但与原文完全无关的内容。而像 transkribus.eu 这样的专用工具表现好得多。

有开发者（breadislove）认为，端到端的 OCR（即模型一步到位完成所有事）仍然“极其棘手”。在实际工程中，组合式的流水线（先做布局检测 -> 再做阅读顺序判断 -> 最后再做 OCR）效果往往更好。

5.挑战：Karpathy指出的不对称性、成本和生态问题

Karpathy 本人也指出了“以图为入”的几个挑战：

  1. 不对称性：用户输入可以是图像（压缩），但模型的输出（生成）仍然需要是文本。因为让 AI 生成一张逼真的、包含特定文字的图像，本身还是一个未解决的难题。
  2. 计算开销：图像编码（如 DeepEncoder）本身的计算开销是不容忽视的。
  3. 可编辑性：文本一旦被“图像化”，就失去了可编辑性。
  4. 生态兼容性：现有的 AI 工具链（如 RAG、向量数据库）都是围绕文本 token 构建的，如何与这种新型的视觉 token 兼容，是一个巨大的工程问题。

五.DeepSeek OCR将带来的行业思考

1.使用图像作为LLM输入可能比传统文本更高效

特斯拉前AI总监Karpathy评论：使用图像作为LLM输入可能比传统文本更高效，他的观点甚至挑战了“文本 token 是标准输入”这一常规假设，并暗示了“语言模型”（Language Model）未来可能会向更通用的“信息处理模型”（Information Processing Model）进化，而视觉（图像）可能是比文本更通用的信息载体，其中的原因包括：

  1. 一个图像patch可包含多个字符

  2. 传统的文本输入，一个 token（计算单元）通常只代表“一个词的一部分”。

  3. 而在图像输入中，一个视觉 token（例如一个图像 patch）可以代表“一页的一部分”，这个“部分”里可能天然就包含了多个单词或字符。

  4. 图像天生支持粗体、颜色、布局等视觉元素 纯文本输入会丢失大量信息。例如，“加粗”、“红色”、“标题字体”、“段落布局”，这些信息在纯文本中要么丢失了，要么需要用 HTML 或 Markdown 这样的额外标记（markup）来描述。而图像输入天生就“看”到了这些视觉元素，信息更丰富。

  5. 图像输入可使用更强的双向注意力

  6. 文本生成（解码）通常使用“自回归因果注意力”（只能看前面的内容）。

  7. 而图像编码（理解）可以使用“双向注意力”（可以同时看前后左右的内容），这种机制的理解能力通常更强。

2.突破LLM“内存限制”，使AI能处理数百页超长上下文

这项技术的潜力在于，它有望突破 LLM 的“内存限制”。当 AI 能够以极高压缩率处理信息时，它就有可能用更少的算力去处理以往无法想象的超长上下文，比如几百页的财报或一整本小说。

3.未来构想：AI可将旧记忆存储为图像，实现高效信息归档

一个有趣的未来构想是，AI 可以将“旧的记忆”（即久远的上下文）存储为图像，以此来实现高效的信息归档。

4.“用光学压缩模拟人类遗忘机制”，更好的解决计算资源的问题

这个构想进一步被比作人类的“遗忘曲线”，模拟了自然的记忆和遗忘过程：

  1. 近期上下文被视为“高保真记忆”，系统会将其保存为高分辨率图像（信息保真度高，压缩率低）。
  2. 远期上下文被视为“低密度记忆”，系统会将其压缩为更模糊的图像（信息密度低，压缩率高，token 消耗少）。
  3. 这种“文本遗忘”机制，是平衡无限上下文信息和有限计算资源的一个早期研究方向，未来可能带来巨大突破。

六.企业如何部署和使用？

DeepSeek-OCR 不仅仅是一个研究模型，它提供了清晰的使用和部署路径。

1.DeepEncoder支持多种具有固定token预算的“原生分辨率”模式

模型提供了多种“档位”供开发者选择，让你可以根据需求平衡成本和性能。这些被称为“原生分辨率”模式：

  1. **Tiny (微小档)**：512x512 分辨率，压缩为 64 tokens。
  2. **Small (小档)**：640x640 分辨率，压缩为 100 tokens。
  3. **Base (基础档)**：1024x1024 分辨率，压缩为 256 tokens。
  4. **Large (超大档)**：1280x1280 分辨率，压缩为 400 tokens。

2.DeepEncoder还支持“动态分辨率”模式（Gundam）

除了固定档位，它还支持一种更强大的“动态分辨率”模式（Gundam），这种模式会混合平铺的“局域视图”（看清细节）和“全局视图”（看清整体布局）。

  1. 这种模式会产生更多的 token，例如 + 256 tokens（n在2-9之间）。
  2. 这些模式允许开发者根据页面的复杂度，灵活地平衡 token 预算（即成本）和性能。

表格：DeepEncoder 的多分辨率支持

ft-type=“table” data-size=“normal” data-row-style=“normal”>

h> Native Resolution Dynamic Resolution
Mode Tiny Small / Base / Large
Resolution 512 640 / 1024 / 1280
Tokens 64 100 / 256 / 400
Process resize resize / padding / padding

3.官方建议

1.对于典型文档（报告、书籍），建议从Small模式（100 tokens）开始测试

在实际评估时，官方给出了建议：

  1. 对于绝大多数典型文档（如报告、书籍），建议从 Small 模式（100 tokens） 开始测试。这个档位在成本和精度上取得了最好的平衡。
  2. 模型发布了明确的 token 预算模式，从 64 tokens (Tiny) 到 400 tokens (Large) 以及复合的 Gundam 模式，PM 可以根据业务场景的复杂度来选型。

2.对于包含密集小字体或极高token数的页面，应使用Gundam模式

如果你的业务场景非常极端，比如页面上塞满了密密麻麻的小字体，或者单页的 token 数极高，那么应该使用 Gundam 模式。Gundam 模式结合了全局和局域视野，并提供了明确的 token 预算，专为复杂场景设计。

3.通过二次模型调用（需提示词），模型能对复杂结构的内容进行深度解析和推理

需要注意的是，该模型还可以支持图表、几何图形、化学公式等复杂元素的深度解析和推理，通常需要通过“二次调用”并配合特定的提示词（Prompt）来实现，具体可以后续大家需要的时候详细体验和关注，其中包括：

  1. Markdown 识别：能处理模糊的电子书页面，并将其转换为结构化的 Markdown 格式。
  2. 深度解析（Deep Parsing）：它能通过自动推理和纠错，来修正初步识别的结果。比如，如果初步识别漏掉了字母，它可以通过上下文推理进行修复。

同时官方也提供了一些提示词示例如下：

  1. 文档（带布局）：\n<|grounding|>Convert the document to markdown.
  2. 无布局 OCR：\nFree OCR.
  3. 图表解析：\nParse the figure.
  4. 内容定位：\nLocate <|ref|>xxxx<|/ref|>

4.模型已开源，Hugging Face和GitHub提供了部署指引

模型的部署门槛相对较低：

  1. DeepSeek 在 GitHub 上提供了快速部署指引，并在 Hugging Face 上开源了模型。
  2. 它提供了一个经过测试的、可立即使用的设置（Python 3.12.9, CUDA 11.8, PyTorch 2.6.0, Flash Attention 2.7.3），以及适用于普通 GPU 的 6.67 GB 分片，这大大降低了工程师的设置成本。
  3. 安装环境前提为 cuda11.8 + torch2.6.0，并需要安装 vllm-0.8.5 和 flash-attn==2.7.3。
  4. 推理支持 vLLM（推荐，用于图像、PDF 和批量评估）和标准 Transformers (HF) 两种方式。
  5. vLLM 方式下，直接运行 run_dpsk_ocr_image.py 或 run_dpsk_ocr_pdf.py 即可。
  6. Transformers 方式下，使用 AutoModel.from_pretrained 加载 deepseek-ai/DeepSeek-OCR 即可。

以上为我站在产品经理角度，对于当下大家热评的DS OCR的一些理解和观点，更多有深度的研究分析，请大家使用“AI快研侠(www.kuaiyanai.com)”，一个用AI生成研究报告的产品。