2025年 10 月 20 号 DeepSeek 团队在 HuggingFace 开源 DeepSeek-OCR ,该模型主要用于探索一种名为“上下文光学压缩” (contexts optical compression) 的创新理念。该方法旨在解决大型语言模型 (LLM) 在处理长文本时面临的计算效率难题,通过将文本信息渲染成图像,利用视觉 Token 实现比原始文本 Token 更高效的压缩。

主要观点

  • 核心问题: 当前的大型语言模型 (LLM) 在处理长文本时,其计算复杂度会随文本长度呈二次方增长,导致效率低下。
  • 创新方案: 提出“上下文光学压缩”概念,即将文本内容转换为图像,利用视觉语言模型 (VLM) 进行处理。由于一张图像可以用远少于原始文本的视觉 Token 来表示,这种方法有望实现极高的信息压缩率。
  • 关键成果: 研发了 DeepSeek-OCR 模型作为此概念的验证。实验证明,该模型能在 9-10x 的压缩率下达到 96% 以上的文本解码精度。此外,DeepSeek-OCR 在主流的文档解析基准测试中,以最少的视觉 Token 消耗实现了端到端模型中的最佳性能 (state-of-the-art)。

关键细节

模型架构与创新

  • DeepSeek-OCR 组成: 模型由两部分构成:一个新颖的视觉编码器 DeepEncoder 和一个 DeepSeek-3B-MoE 解码器。
  • DeepEncoder 架构: 这是模型的核心创新。它串联了以窗口注意力为主的 SAM 模型和以全局注意力为主的 CLIP 模型,并通过一个 16x 的卷积压缩器连接两者。这种设计使得模型在处理高分辨率图像时,能有效控制计算内存和视觉 Token 的数量。
  • 多分辨率支持: DeepEncoder 支持多种分辨率模式(如 Tiny, Small, Base, Large, Gundam),使其能够灵活测试不同压缩比下的性能,并适应不同复杂度的文档。

性能评估

  • 视觉-文本压缩率研究: 在 Fox 基准测试中,DeepSeek-OCR 表现出色:
    • 9-10x 的压缩比下,解码精度超过 96%
    • 10-12x 的压缩比下,精度约为 90%
    • 即使在接近 20x 的高压缩比下,精度仍能保持在 60% 左右。
  • OCR 实践性能: 在 OmniDocBench 基准测试中,DeepSeek-OCR 的表现优于其他端到端模型:
    • 仅用 100 个视觉 Token,性能就超过了使用 256 个 Token 的 GOT-OCR2.0
    • 使用不到 800 个 Token (Gundam 模式),性能优于需要近 7000 个 Token 的 MinerU2.0

功能与应用前景

  • 多功能性: 除了基础的 OCR 功能,DeepSeek-OCR 还具备“深度解析”能力,能够处理文档中的图表、化学分子式、几何图形和自然图像。同时,它支持近 100 种语言的识别。
  • 未来展望: “上下文光学压缩”为解决 LLM 的长上下文处理难题提供了一个有前景的方向。未来,该技术可用于压缩对话历史,通过逐步降低旧信息的图像分辨率来模拟人类的“遗忘机制”,从而在保留关键信息的同时,大幅提升计算效率。

Andrej Karpathy 对 DeepSeek-OCR 的评价

我非常喜欢 DeepSeek-OCR 的新论文。这是一个很好的 OCR 模型(也许比 dots 差一点),是的,还有数据收集等等,但无论如何这不重要。

对我来说(尤其是一个内心是搞计算机视觉、暂时伪装成自然语言处理者的人)更有趣的部分是,对于 LLM 而言,像素是否是比文本更好的输入。文本 token 在输入端是否既浪费又糟糕。

也许 LLM 的所有输入只应该是图像会更有意义。即使你碰巧有纯文本输入,也许你更愿意先将其渲染出来,然后再输入:

  • 更多的信息压缩(见论文)=> 更短的上下文窗口,更高的效率
  • 显著更通用的信息流 => 不仅仅是文本,比如粗体文本、彩色文本、任意图像。
  • 输入现在可以轻松地、默认地使用双向注意力进行处理,而不是自回归注意力——这要强大得多。
  • 删除(输入端的)分词器(tokenizer)!!我早就抱怨过我有多不喜欢分词器。分词器很丑陋,是独立的,不是端到端的阶段。它“导入”了 Unicode、字节编码的所有丑陋之处,继承了大量历史包袱、安全/越狱风险(例如连续字节)。它使得两个肉眼看起来完全相同的字符在网络内部看起来是两个完全不同的 token。一个微笑的 emoji 看起来是一个奇怪的 token,而不是一个……真正的笑脸,及其像素,以及随之而来的所有迁移学习。分词器必须去掉。

OCR 只是众多有用的视觉 -> 文本任务之一。而文本 -> 文本任务可以被改造成视觉 -> 文本任务。反之则不行。

所以,也许用户的消息是图像,但解码器(助手的回应)仍然是文本。如何真实地输出像素……或者你是否想要这样做,这一点远没有那么明显。

现在我还得克制住去做一个只有图像输入的 nanochat 支线任务的冲动……

QA

为什么说“由于一张图像可以用远少于原始文本的视觉 Token 来表示,这种方法有望实现极高的信息压缩率”。一张图的 token 是多少,这些 token 等同于多少字

您提的这个问题非常棒,这正是 DeepSeek-OCR 这篇论文所探讨的核心创新点。下面我为您详细拆解这个概念。

简单来说,这句话的核心思想是:AI 模型处理信息的方式与人类不同。对于 AI 而言,将大量文本信息“编码”成一张图片,其处理成本(Token 数量)可能远低于直接处理这些文本本身。

我们来分步解释:

1. 一张图的 Token 是多少?

这取决于两个因素:图像分辨率模型架构

目前的视觉语言模型(VLM)通常使用一种叫做 Vision Transformer (ViT) 的架构。它的工作原理是:

  1. 分块 (Patching):将输入的图像切割成一个个固定大小的小方块(patches)。
  2. 编码 (Encoding):将每个小方块转换成一个“视觉 Token”。

所以,一张图的 Token 数量 = (图片宽度 / 小方块宽度) × (图片高度 / 小方块高度)

DeepSeek-OCR 为例:

  • 它使用的 SAM-base 编码器,小方块 (patch) 大小是 16x16 像素。
  • 当输入一张 1024x1024 像素的图片时,初始的视觉 Token 数量是: (1024 / 16) × (1024 / 16) = 64 × 64 = 4096 个 Token。
  • 关键一步DeepSeek-OCRDeepEncoder 架构中有一个 16倍压缩器,它会将这 4096 个 Token 进一步压缩成 4096 / 16 = 256 个 Token。

所以,对于 DeepSeek-OCR 来说,一张 1024x1024 的高分辨率图片最终只用了 256 个视觉 Token 来表示。

在论文的 Base 模式下,它使用的就是 256 个视觉 Token。在更低的 Tiny 模式(512x512 分辨率)下,它甚至只用 64 个视觉 Token

2. 这些视觉 Token 等同于多少字?

这正是“压缩率”的体现。视觉 Token 的数量是固定的(例如 256 个),但它所能代表的文字数量是可变的,取决于图片里“塞”了多少字。

我们再来看文本 Token:

  • 文本 Token 是由一个叫 Tokenizer 的工具生成的。
  • 它通常不是一个词对应一个 Token。对于英文来说,一个 Token 大约等于 0.75 个单词。对于中文,一个 Token 大约等于 0.6-0.8 个汉字

现在我们来做一个对比计算:

假设我们有一篇包含 1000 个英文单词的文档。

  • 作为文本处理

    • 需要的文本 Token 数量大约是 1000 / 0.75 ≈ 1333 个文本 Token。
  • 作为图像处理 (使用 DeepSeek-OCRBase 模式)

    • 我们将这 1000 个单词的文档内容渲染成一张 1024x1024 的图片。
    • 模型处理这张图片只需要 256 个视觉 Token

压缩率计算: 文本 Token 数量 / 视觉 Token 数量 = 1333 / 256 ≈ 5.2 倍

这意味着,模型用处理 256 个 Token 的代价,完成了原本需要处理 1333 个 Token 的工作,实现了 5.2倍 的信息压缩。

论文中更极致的例子 (来自摘要中的 Table 2):

  • 当处理一篇包含 1200-1300 个文本 Token(约 900-975 个单词)的文档时,模型使用了 Tiny 模式。
  • Tiny 模式只使用 64 个视觉 Token
  • 此时的压缩率高达 1200 / 64 ≈ 19.7 倍

结论与比喻

您可以把这个过程理解成一个 ZIP 压缩包

  • 原始文本:一个包含很多文件的大文件夹(1333 个 Token)。
  • 渲染成的图片:一个被压缩后的 .zip 文件(256 个 Token)。
  • DeepSeek-OCR 的解码器:解压缩软件,它能读取这个 .zip 文件,并完美地还原出里面的所有文件。

因此,“一张图像可以用远少于原始文本的视觉 Token 来表示”这句话的含义是:视觉 Token 的数量由图像分辨率和模型结构决定,是相对固定的;而这张图像内可以承载的文本信息量却可以非常大。当图像中的文本非常密集时,视觉 Token 与文本 Token 的数量比就构成了极高的压缩率。

Q:“仅用 100 个视觉 Token,性能就超过了使用 256 个 Token 的 GOT-OCR2.0。 使用不到 800 个 Token (Gundam 模式),性能优于需要近 7000 个 Token 的 MinerU2.0。” 这句话没理解什么意思

您可以把 “视觉 Token 的数量” 理解为 “模型处理一张图片的计算成本”。Token 数量越少,代表模型处理图片的速度越快、占用的计算资源(如 GPU 显存)越少,运行成本也越低。

这句话的本质是在比较 效率效果

  • 效率:用了多少计算成本(视觉 Token 数量)。
  • 效果:OCR 识别的准确度(性能)。

现在我们把您提到的那句话拆成两部分来看:


第一部分:DeepSeek-OCR vs. GOT-OCR2.0

“仅用 100 个视觉 Token,性能就超过了使用 256 个 TokenGOT-OCR2.0。”

  • DeepSeek-OCR 的情况

    • 计算成本:它在 Small 模式下,将输入图片处理成 100 个 视觉 Token。
    • 产出效果:达到了一个很高的识别准确率。
  • GOT-OCR2.0 的情况

    • 计算成本:它需要将同一张图片处理成 256 个 视觉 Token。
    • 产出效果:它的识别准确率还不如 DeepSeek-OCR

结论DeepSeek-OCR 不仅更“省钱”(计算成本低了 2.5 倍多),而且干活还更“漂亮”(性能更好)。这证明了 DeepSeek-OCR 的视觉编码器 (DeepEncoder) 在提取和压缩信息方面的效率极高。


第二部分:DeepSeek-OCR vs. MinerU2.0

“使用不到 800 个 Token (Gundam 模式),性能优于需要近 7000 个 TokenMinerU2.0。”

这个对比更加惊人。

  • DeepSeek-OCR 的情况

    • 计算成本:在处理复杂或超高分辨率图片时,它启用 Gundam 模式,平均使用 795 个 视觉 Token。
    • 产出效果:达到了顶尖的 (state-of-the-art) 识别准确率。
  • MinerU2.0 的情况

    • 计算成本:为了处理同样复杂的图片,它需要生成接近 7000 个 (6790 个) 视觉 Token。
    • 产出效果:即便付出了如此巨大的计算成本,它的识别准确率依然被 DeepSeek-OCR 超越

结论:这里的效率差距是巨大的。DeepSeek-OCR 用了不到 MinerU2.0 九分之一的计算成本,就取得了更好的结果。

总结与比喻

您可以把这个过程想象成两位厨师做同一道复杂的菜:

  • MinerU2.0 像是一位“用料很猛”的厨师。他把一大堆(7000 份)原材料全都扔进锅里,希望能做出一道好菜,但因为处理不过来,最后味道只是一般。
  • DeepSeek-OCR 则是一位“技艺精湛”的厨师。他只挑选了最精华的核心食材(不到 800 份),通过高超的刀工和火候(先进的 DeepEncoder 架构),做出的菜肴味道却更胜一筹。

所以,这句话的核心意思是:DeepSeek-OCR 模型在处理文档图像时,不仅性能顶尖,而且计算效率极高,可以用远低于其他主流模型的计算成本,完成更高质量的识别任务。 这也直接证明了其“上下文光学压缩”理念的成功。