---
area: "tech-engineering"
category: technology
companies_orgs:
- DeepSeek
date: '2025-10-22'
draft: true
guest: ''
insight: ''
layout: post.njk
media_books:
- LAION
- Wukong
- Fox基准
- OmniDocBench基准
people:
- 大飞
- Andrej Karpathy
products_models:
- GPT-4
- Claude
- DeepSeek-OCR
project: []
series: ''
source: https://www.youtube.com/watch?v=5C5pRcLFKys
speaker: Best Partners TV
status: evergreen
summary: DeepSeek最新开源的DeepSeek-OCR模型，提出了一种创新方法来解决大语言模型处理长文本的计算量痛点。它通过将文本转化为图像，再压缩为少量视觉token，实现了高达10倍的文本压缩率，同时保持97%的解码精度。文章详细介绍了其核心组件DeepEncoder和MoE解码器的巧妙设计，以及多分辨率支持、全面的数据引擎和分阶段训练策略。DeepSeek-OCR不仅在OCR性能上达到领先水平，更重要的是为未来大语言模型的超长上下文处理、记忆机制模拟和视觉-语言模型协同优化提供了全新思路。
tags:
- architecture
- canada
- code
- large-language-model
- long
- technology
title: DeepSeek-OCR：以视觉模态突破大语言模型长文本处理瓶颈
---
### 引言：长文本处理的痛点与DeepSeek-OCR的破局之道

在处理几万字的学术论文或电子书时，我们常常会遇到大型语言模型（**LLM**：Large Language Model，一种基于深度学习的语言模型）的两个棘手问题：要么提示序列长度超出上限，要么生成速度慢得让人失去耐心。这背后隐藏着**LLM**的一个根深蒂固的技术痛点：它们的计算量会随着文本序列长度的增加呈平方增长。简单来说，文本长度翻倍，计算量可能要翻四倍，这对硬件资源的消耗是毁灭性的。

今天我们要聊的这款模型，可能为解决这个长文本困局提供了一个全新的方向。它不是靠着堆砌更大的参数或更宽的上下文窗口，而是另辟蹊径，把文本变成图像，将视觉模态作为高效的压缩媒介。它就是来自DeepSeek最新开源的**DeepSeek-OCR**（DeepSeek最新开源的视觉语言模型），一款既能够做**OCR**（Optical Character Recognition: 光学字符识别技术），又能为**LLM**长上下文处理铺路的视觉语言模型。

### 核心思路：视觉模态作为文本压缩的桥梁

在具体介绍**DeepSeek-OCR**之前，我们先来考虑一个问题：有没有一种方式，能够在不减少文本信息量的前提下，减少输入到**LLM**的**token**（文本标记: 语言模型处理文本的基本单位）数量呢？DeepSeek团队想到了一个关键思路，那就是利用视觉模态的压缩特性。

大家可以想一下，一张包含1000个汉字的文档图片，如果把这些汉字转换成纯文本的**token**，数量可能要上千甚至更多。但是如果用图像格式存储，它的**视觉token**（Visual Token: 将图像信息编码后的离散表示）数量可能只有几百个。这意味着，通过文本到图像再到**视觉token**的路径，我们可能实现远超纯文本压缩的效率。而**OCR**恰好是连接视觉和文本的完美桥梁，因为**OCR**的本质就是把图像中的文字信息准确地转换成文本信息，这相当于完成了一次**视觉token**到文本**token**的解码过程。

如果我们能够让模型通过**OCR**任务，学会从少量**视觉token**中解码出大量文本**token**，那就证明视觉到文本的压缩是可行的。这也是为什么**DeepSeek-OCR**选择**OCR**作为核心任务，而不是普通的图像描述或者视觉问答的方式。

在这个思路下，**DeepSeek-OCR**的定位就不是一个单纯的**OCR**工具了，而是一个视觉到文本压缩的验证原型。它要回答三个核心问题：第一，**视觉token**能够把文本压缩到什么程度呢？第二，压缩后的**视觉token**还能准确地解码回文本吗？第三，这种压缩方式能够为**LLM**处理长文本提供实际的帮助吗？而接下来我们将会看到，**DeepSeek-OCR**不仅回答了这三个问题，还给出了超出预期的结果。

### DeepEncoder：高效视觉编码器的创新设计

首先，要想实现视觉到文本的压缩，核心在于要有一个足够高效的视觉编码器。它需要能够处理高分辨率的文档图像，同时输出尽可能少的**视觉token**，还要保持低的内存占用。但是DeepSeek的团队发现，当前主流的视觉模型中，三种常见的视觉编码器都存在明显的缺陷，无法满足这些需求。

第一种是**双塔式架构**（Dual-tower Architecture: 一种视觉模型架构，使用两个并行的编码器处理图像），代表模型是**Vary**（一种采用双塔式架构的视觉模型）。这种架构的思路是用两个并行的编码器来处理图像，增加视觉的词汇量，从而支持高分辨率的输入。它的优点是参数和激活内存可控，但是缺点也很致命，就是需要对图像进行两次预处理，这会大大增加部署的复杂度；而且在训练的时候，很难实现编码器的流水线并行，效率很低。

第二种是**基于瓦片（tile）的架构**（Tile-based Architecture: 一种视觉模型架构，将高分辨率图像分割成小块并行处理），代表模型是**InternVL2.0**（一种采用瓦片式架构的视觉模型）。这种架构的做法是把高分辨率图像分割成一个个小的瓦片，然后并行处理这些瓦片，以此来减少激活的内存。它的优势是能够处理极高分辨率的图像，但是问题在于，它的原生编码器分辨率很低，通常低于512×512，这就导致大的图像会被分割成大量瓦片，最终输出的**视觉token**数量非常多。比如一张4k分辨率的文档图，可能会被分成几十甚至上百个瓦片，**视觉token**的数量直接失控，根本达不到压缩的目的。

第三种是**自适应分辨率架构**（Adaptive Resolution Architecture: 一种视觉模型架构，直接处理全尺寸图像并支持灵活分辨率），代表模型是**Qwen2-VL**（一种采用自适应分辨率架构的视觉模型）。它采用了**NaViT范式**（Native Vision Transformer: 一种不分割图像，直接用基于patch的方式处理全尺寸图像的范式），不分割图像，直接用基于patch的方式处理全尺寸图像，支持灵活的分辨率。但是这种架构的问题在于，处理大图像的时候，激活内存会急剧增加，很容易导致GPU内存的溢出；而且训练时需要极长的序列长度，推理速度也会变慢。简单说，就是看着灵活，用着卡顿。

总结一下，双塔式难部署，瓦片式**token**太多，自适应分辨率内存不够。这三个坑让现有的视觉编码器无法满足高分辨率输入、低激活内存、少**视觉token**的三重需求。也正是因为这个原因，DeepSeek的团队才决定从零开始，设计一款全新的视觉编码器，也就是我们接下来要讲的**DeepEncoder**（DeepSeek-OCR中负责将图像转换为少量高效视觉token的视觉编码器）。

**DeepSeek-OCR**的整体架构非常清晰，分为两大部分：视觉编码器**DeepEncoder**和混合专家解码器**DeepSeek3B-MoE-A570M**（DeepSeek-OCR中用于将视觉token解码成文本的混合专家解码器）。前者负责把图像转换成少量、高效的**视觉token**，后者负责把这些**视觉token**解码成文本。我们先从最关键的**DeepEncoder**开始讲起。

**DeepEncoder**的核心目标有五个：分别是处理高分辨率输入、保持低激活内存、输出少量**视觉token**、支持多分辨率、参数规模适中。为了实现这些目标，它的结构设计非常巧妙，主要由三个部分串联而成：分别是基于**窗口注意力**（Window Attention: 一种注意力机制，在图像的局部窗口内计算注意力，降低内存消耗）的视觉感知模块**SAM-base**（Segment Anything Model base: DeepEncoder中基于窗口注意力的视觉感知模块）、16倍的**卷积压缩器**（Convolutional Compressor: DeepEncoder中通过卷积层实现视觉token数量压缩的模块），以及基于**全局注意力**（Global Attention: 一种注意力机制，捕捉整个图像的全局信息）的视觉知识模块**CLIP-large**（Contrastive Language-Image Pre-training large: DeepEncoder中基于全局注意力的视觉知识模块）。

我们先拆解一下这个结构的逻辑。首先是**SAM-base**，参数大约8000万。它的核心是**窗口注意力**，简单来说，就是把图像分成一个个小窗口，在每个窗口内部计算注意力，而不是在整个图像上计算。这种方式的好处是，即使处理高分辨率的图像，激活内存也能保持在较低的水平。比如一张1024×1024的图像，用16×16的**patch**分割，会产生4096个**patch token**（图像块标记: 将图像分割成小块后，每个小块对应的离散表示）。**SAM-base**用**窗口注意力**处理这些**token**时，内存压力很小。

但是，4096个**token**还是太多了，达不到压缩的目的。所以接下来是16倍**卷积压缩器**，这是**DeepEncoder**的核心压缩环节。它由两层卷积层构成，每一层的卷积核大小是3×3，步长是2，padding是1，通道数从256增加到1024。通过这两层卷积，4096个**token**会被压缩到4096除以16，也就是256个**token**。这个设计的关键在于，它在**窗口注意力**处理大量**token**和**全局注意力**处理少量**token**之间，搭建了一个高效的过渡，既保留了图像的细节信息，又大幅减少了后续模块的计算压力。

最后是**CLIP-large**，参数大约3亿。它的核心是**全局注意力**，能捕捉整个图像的全局信息，这对于理解文档的整体布局、上下文关联至关重要。因为前面已经通过**卷积压缩器**把**token**减少到256个，所以**CLIP-large**用**全局注意力**处理时，激活内存完全可控。这里有个细节需要注意，那就是**DeepEncoder**在使用**CLIP-large**时，移除了它原本的第一个**patch**嵌入层，因为**CLIP-large**的输入不再是原始图像，而是经过**SAM-base**和**压缩器**处理后的**token**。这个小改动让**CLIP-large**能够更好地适配整个流程。

整体来看，**DeepEncoder**的参数大约3.8亿，不算特别大。但是通过**窗口注意力**到**卷积压缩**，再到**全局注意力**的串联结构，完美解决了高分辨率、低激活、少**token**的三重需求。这也是**DeepSeek-OCR**能实现高效压缩的核心基础。

### 多分辨率支持：灵活适应多样化文档场景

除了基础结构，**DeepEncoder**还有一个非常实用的设计：多分辨率支持。因为实际场景中的文档图像，分辨率差异很大。比如一张手机拍的便签可能只有512×512，而一张扫描的报纸可能有4k甚至更高分辨率。如果只用一种分辨率处理，要么会浪费**token**，要么会丢失细节。

因此，**DeepEncoder**把分辨率模式分成了两类：原生分辨率和动态分辨率。我们先看原生分辨率，它包含四种子模式，对应不同的图像大小和输出**token**数量：
*   Tiny模式：512×512分辨率，输出64个**视觉token**，适合处理小尺寸的短文本图像，比如名片、便签。
*   Small模式：640×640分辨率，输出100个**视觉token**，适合处理普通的单页文档，比如A4纸扫描件。
*   Base模式：1024×1024分辨率，输出256个**视觉token**，适合处理包含复杂布局的文档，比如带表格的报告。
*   Large模式：1280×1280分辨率，输出400个**视觉token**，适合处理高分辨率的细节丰富的文档，比如带公式的学术论文。

这里有个关键点是，对于Tiny和Small模式，因为分辨率较小，模型会直接把图像resize到对应的尺寸，避免浪费**token**；而对于Base和Large模式，为了保留原始图像的宽高比，模型会用**填充（padding）**（在图像处理中，为了保持原始宽高比或达到目标尺寸，在图像边缘添加额外像素的操作）的方式，把图像补到对应尺寸。这时候就会出现有效**token**和实际**token**的区别。比如一张1024×512的图像，用Base模式处理时，会被填充成1024×1024，实际**token**是256个，但是有效**token**只有128个。论文中给出了有效**token**的计算公式，其中w和h是原始图像的宽和高。这个设计能让模型更高效地利用**token**资源。

再看动态分辨率，主要是为了处理超高清大图，比如报纸、多页拼接的文档。它的核心是瓦片+全局的组合模式，最具代表性的是**高达模式（Gundam mode）**（DeepEncoder中处理超高清大图的一种动态分辨率模式，结合瓦片和全局视图）和**高达大师模式（Gundam-master mode）**（高达模式的更高配置版本，用于处理更高分辨率的图像）。

**高达模式**的逻辑是把超高清图像分割成n个640×640的局部瓦片，再加上一个1024×1024的全局视图。所以总的**视觉token**数量是n×100 + 256，其中n的范围是2到9，避免分割过多导致**token**失控。比如一张3000×2000的报纸图像，可能会被分成4个局部瓦片，加上1个全局视图，总**token**数量是4×100 + 256 = 656个，远少于用原生模式处理时的**token**数量。而**高达大师模式**则是更高配置的版本，局部瓦片用1024×1024，全局视图用1280×1280，总**token**数量是n×256 + 400。不过因为**高达大师模式**的分辨率太高，训练时会影响整体速度，所以它不是和其他模式一起训练的，而是在预训练好的**DeepSeek-OCR**基础上，用额外数据继续训练得到的。

### DeepSeek3B-MoE-A570M：MoE解码器实现高效文本重建

有了高效压缩的**视觉token**，接下来还需要一个能把这些**token**准确解码成文本的解码器。**DeepSeek-OCR**选择的是激活参数为5.7亿的**DeepSeek3B-MoE-A570M**。为什么选择**MoE架构**（Mixture of Experts: 混合专家架构，一种神经网络结构，通过激活部分专家模块来提高效率和性能）？因为**MoE**有一个核心优势，在保持大模型性能的同时，能够降低推理时的计算量。普通的大模型在推理时需要激活所有参数，而**MoE**模型会把参数分成多个专家模块，推理时只激活其中一部分专家。

具体到**DeepSeek3B-MoE-A570M**，它总共有64个**路由专家（routed experts）**（MoE模型中根据输入动态选择激活的专家模块）和2个**共享专家（shared experts）**（MoE模型中所有输入都会激活的专家模块）。推理时只会激活其中6个**路由专家**和2个**共享专家**，激活的参数总量大约是5.7亿。这意味着，它能够达到3B参数模型的表达能力，但是推理速度却和500M左右的小模型相当。这对于需要大规模部署的**OCR**任务来说，是一个非常关键的优势。

解码器的核心功能是实现从压缩**视觉token**到文本**token**的映射。论文中用公式表示为这样子，其中Z是**DeepEncoder**输出的**视觉token**，X̂帽是重建的文本**token**，函数f_dec代表一个非线性映射。这个映射过程是通过**OCR**任务的训练来学习的，模型在训练中不断调整参数，让它从**视觉token**解码出文本，并且尽可能接近真实的文本标签。

这里有一个重要的猜想，那就是既然这种3B规模的**MoE**模型能够学好这个解码过程，那么更大规模的模型，比如70B、175B参数，通过专门的预训练优化，应该能够更轻松地掌握这个能力。这意味着，未来的**LLM**可能不需要直接处理海量的文本**token**，而是可以先把长文本转换成图像，用**DeepEncoder**压缩成少量的**视觉token**，再用自身的解码能力把**视觉token**转换成文本。这将会彻底改变**LLM**处理长文本的方式。

### 数据引擎：构建数十亿样本的高质量训练数据

当然，再好的架构也需要高质量的数据来训练。**DeepSeek-OCR**的团队构建了一套非常全面的数据引擎，涵盖了四种不同类型的数据，总规模超过数十亿样本。

第一种是**OCR** 1.0数据，主要对应传统的**OCR**任务，是数据引擎的核心。它又分为文档**OCR**和自然场景**OCR**。其中文档**OCR**数据是团队从互联网上收集了3000万页的多语言PDF文档，覆盖约100种语言，其中中文和英文占2500万页，其他小语种占500万页。为了兼顾效率和精度，他们做了两种标注：粗标注和细标注。粗标注是用**fitz工具**（一个用于从PDF文档中提取文本和布局信息的工具）直接从PDF中提取文本，主要用于教模型识别小语种文本；细标注则是用**PP-DocLayout**（一种文档布局分析工具）和**GOT-OCR2.0**（一种OCR模型）做精细化标注，包含文本的位置坐标和内容，共200万页中文和200万页英文。对于小语种，他们还采用了模型飞轮的方式生成标注，先用**fitz**切出小语种文本的**patch**，训练一个**GOT-OCR2.0**小模型，再用这个小模型给更多**patch**标注，最终得到60万样本。而自然场景**OCR**数据主要支持中文和英文，图像来自**LAION**（Large-scale Artificial Intelligence Open Network: 一个大型图像-文本数据集）和**Wukong数据集**（一个大型中文图像-文本数据集），用**PaddleOCR**（百度飞桨开源的OCR工具库）标注，各1000万样本。

第二种是**OCR** 2.0数据，对应更复杂的beyond text任务，比如图表解析、化学公式识别、平面几何解析。这些是传统**OCR**很难处理的，但是**DeepSeek-OCR**希望通过这些数据来提升模型的深度解析能力。

第三种是通用视觉数据，主要目的是让模型保留基本的通用视觉理解能力，而不是只局限于**OCR**任务。团队参考**DeepSeek-VL2**（DeepSeek团队的另一个视觉语言模型），生成了图像描述、目标检测、视觉定位等任务的数据，占总数据量的20%。这样做的好处是，未来如果研究者想基于**DeepSeek-OCR**做通用视觉任务，不需要从头训练，只需要在这个基础上微调即可。

第四种是纯文本数据，占总数据量的10%，主要用于保持模型的语言生成能力。这些数据是团队内部整理的，全部处理成8192个**token**的长度，和**DeepSeek-OCR**的训练序列长度保持一致。因为**OCR**任务不仅需要识别文本，还需要生成通顺的文本，纯文本数据能够确保模型在解码的时候，输出的文本符合语法和逻辑。

这四类数据按照7:2:1的比例混合，其中**OCR**数据70%、通用视觉数据20%、纯文本数据10%，这样既保证了**OCR**的核心精度，又拓展了复杂场景的处理能力，还保留了通用视觉和语言能力。

### 训练流程：DeepEncoder与整体模型的协同优化

在训练阶段，**DeepSeek-OCR**分为两个核心阶段：分别是**DeepEncoder**的独立训练和**DeepSeek-OCR**的整体训练。整个过程在自家的萤火平台上完成。

第一阶段，**DeepEncoder**的独立训练。因为**DeepEncoder**是整个模型的压缩核心，它的性能直接决定了后续解码的精度，所以需要先单独优化。团队用了一个稠密的语言模型来训练**DeepEncoder**，训练数据包括所有的**OCR** 1.0和**OCR** 2.0数据，再加上从**LAION**数据集中采样的1亿通用图像数据。训练参数设置为：批大小1280，优化器采用**AdamW**（Adaptive Moment Estimation with Weight Decay: 一种带有权重衰减的自适应矩估计优化器），学习率5e-5，学习率调度器采用**余弦退火**（Cosine Annealing: 一种学习率调度策略，学习率随训练步数按余弦函数曲线下降），训练轮次为2轮，序列长度4096。这个阶段的目标是让**DeepEncoder**学会把图像高效地压缩成**视觉token**，同时保留足够的文本信息。

第二阶段是**DeepSeek-OCR**的整体训练。当**DeepEncoder**训练完成后，就需要把它和**MoE**解码器结合起来，进行端到端的训练。这个阶段的训练配置更复杂，也更注重效率。其中，硬件资源使用了20个节点，每个节点8张A100-40G GPU，总共160张A100。训练采用**流水线并行（PP）**（Pipeline Parallelism: 一种分布式训练策略，将模型层分割到不同的设备上并行计算），把整个模型分成4个部分：**DeepEncoder**的**SAM-base**和**卷积压缩器**放在PP0，参数冻结；**DeepEncoder**的**CLIP-large**放在PP1，参数解冻；**MoE**解码器的12层中，6层放在PP2，另外6层放在PP3，参数全部解冻。同时还采用了**数据并行（DP）**（Data Parallelism: 一种分布式训练策略，将数据分割到不同的设备上并行计算），并行度为40，全局批大小为640。优化器依然采用的是**AdamW**，初始学习率3e-5，学习率调度器采用基于步数的调度（step-based）。训练速度方面，纯文本数据的训练速度是每天900亿**token**，多模态数据的训练速度是每天700亿**token**。另外，前面提到的**高达大师模式**是在整体训练完成后，用600万采样数据继续训练得到的，训练协议和整体训练一致。

### 实验验证：DeepSeek-OCR的卓越性能

一款模型的好坏，最终还要靠实验数据来验证。**DeepSeek-OCR**的团队在两个权威基准上做了全面的评估：用来测试视觉-文本压缩比的**Fox基准**（Fox Benchmark: 一个专门用于测试文档理解和视觉-文本压缩比的数据集），和用来测试实际**OCR**性能的**OmniDocBench基准**（OmniDocBench Benchmark: 一个权威的文档解析基准），并且还做了定性研究，结果都非常亮眼。

首先在**Fox基准**上，10倍压缩仍能保持97%的精度。**Fox基准**是一个专门用来测试文档理解的数据集，包含多种布局的英文文档。团队选择了其中文本**token**数量在600-1300之间的100页文档，用**DeepSeek-OCR**的分词器来处理真实文本，然后测试Tiny和Small两种原生分辨率模式下的解码精度。

实验结果显示：
*   在Tiny模式（64个**视觉token**）下：
    *   当文本**token**数量在600-700时，压缩比约10.5倍，解码精度96.5%；
    *   当文本**token**数量在900-1000时，压缩比约15.1倍，解码精度85.9%；
    *   当文本**token**数量在1200-1300时，压缩比约19.7倍，解码精度59.1%。
*   在Small模式（100个**视觉token**）下：
    *   当文本**token**数量在600-700时，压缩比约6.7倍，解码精度98.5%；
    *   当文本**token**数量在900-1000时，压缩比约9.7倍，解码精度仍有96.8%；
    *   当文本**token**数量在1200-1300时，压缩比约12.6倍，解码精度87.1%。

这些数据揭示了三个关键结论：
1.  10倍压缩是一个甜点区。当压缩比在10倍以内时，解码精度能稳定在96%以上，几乎接近无损压缩的效果。这意味着，未来如果我们把长文本转换成图像，用**DeepEncoder**压缩10倍后输入给模型，模型能够准确解码出原始文本，而**token**数量减少到原来的1/10，这会极大降低模型的计算压力。
2.  即使压缩到20倍，仍然有实用价值。当压缩比接近20倍时，精度大约60%。这个精度虽然不算高，但是对于长文本摘要、关键词提取这类不需要逐字准确的任务，已经足够使用。而且论文中提到，实际精度可能更高，因为测试时模型输出格式和真实标签的格式存在差异，如果排除这些格式差异，精度会提升5%-10%。
3.  压缩比超过10倍后精度下降的原因主要有两个：一是长文档的布局更复杂，**视觉token**难以完全保留布局信息；二是512×512或640×640的分辨率对于1200个以上的文本**token**来说，文字会变得模糊，导致细节丢失。第一个问题可以通过统一布局渲染解决，第二个问题则可以通过更高分辨率的模式缓解，这也为后续的优化指明了方向。

我们再来看**OmniDocBench基准**，它是当前最权威的文档解析基准之一，包含多种类型的文档，评估指标是**编辑距离（Edit Distance）**（衡量两个字符串之间差异的指标，数值越小表示差异越小，性能越好），数值越小，说明模型输出的文本和真实标签的差异越小，性能越好。团队在这个基准上，把**DeepSeek-OCR**和两款主流**OCR**模型做了对比，分别是**GOT-OCR2.0**和**MinerU2.0**（一种主流OCR模型）。核心对比维度是平均**视觉token**数量和**编辑距离**，目标是看**DeepSeek-OCR**能否用更少的**token**达到更好的性能。

结果非常惊艳：
*   当使用100个**视觉token**（Small模式）时，**DeepSeek-OCR**的**编辑距离**远低于需要256个**视觉token**的**GOT-OCR2.0**。
*   当使用400个**视觉token**时，**DeepSeek-OCR**的**编辑距离**和当前最先进的模型相当。
*   当使用不到800个**视觉token**时，**DeepSeek-OCR**的**编辑距离**低于**MinerU2.0**。

如果再更细致地看不同文档类型的表现，幻灯片只用64个**视觉token**，**编辑距离**就很低。书籍、财务报告用100个**视觉token**就能达到很好的性能，因为这些文档的文本**token**数量通常在1000以内，压缩比在10倍以内，精度有保障。而报纸就需要**高达模式**甚至**高达大师模式**，因为报纸的文本**token**数量通常在4000-5000，远超10倍压缩的范围，需要更多**token**来保留细节。

这些结果证明，**DeepSeek-OCR**不仅在压缩比上有优势，在实际**OCR**性能上也处于当前领先水平。它不是一个为了压缩而牺牲精度的模型，而是在压缩的同时提升或保持精度的模型，这对于实际应用来说至关重要。

### 超越OCR：深度解析与多语言、通用视觉能力

除了定量数据，团队还做了大量定性研究，展示了**DeepSeek-OCR**超越传统**OCR**的能力，主要包括三个方面：

第一是深度解析能力。传统**OCR**只能识别文本，而**DeepSeek-OCR**能对文档中的复杂元素进行结构化解析。比如能够把折线图、柱状图转换成HTML表格，并且包含具体的数值；还能把图像中的化学公式转换成**SMILES格式**（Simplified Molecular Input Line Entry System: 一种用文本字符串表示化学分子结构的方法）；甚至能识别几何图形中的线段、端点坐标、线段类型，并且用结构化的格式输出。即使对于文档中插入的自然图像，**DeepSeek-OCR**也能生成详细的描述，包括物体、颜色、位置关系等等。

第二是多语言识别能力。**DeepSeek-OCR**支持近100种语言的**OCR**，包括中文、英文、阿拉伯语、僧伽罗语等。对于小语种文档，它既能输出纯文本，也能输出包含布局信息的文本。比如阿拉伯语的报纸，模型能准确识别从右到左的文本顺序；僧伽罗语的宗教文献，模型能识别复杂的字符结构。这得益于**OCR** 1.0数据中丰富的多语言样本。

第三是通用视觉理解能力。虽然**DeepSeek-OCR**的核心是**OCR**，但是它保留了**VLM**（Vision-Language Model，视觉语言模型）的通用视觉能力。比如能够详细描述图像的内容，包括物体、场景、细节；能够定位图像中的物体，并输出边界框坐标；能够根据文本参考，在图像中找到对应的位置；甚至能够识别古诗《将进酒》的图像，准确输出文本，并且能理解其中的语义。

需要注意的是，**DeepSeek-OCR**没有经过**监督微调SFT**（Supervised Fine-Tuning: 一种模型训练方法，使用标注数据对预训练模型进行微调），所以它不是一个聊天机器人，需要通过特定的提示词来激活这些能力。但是即使如此，这些能力已经远超传统**OCR**，展示了它作为多功能文档处理工具的潜力。

### 未来展望：长文本处理的变革性方向

通过前面的实验，我们已经看到**DeepSeek-OCR**在视觉-文本压缩上的潜力。但是更重要的是，这个技术思路能为**LLM**的长文本处理带来哪些改变呢？团队在论文的讨论部分，提出了几个非常有启发性的方向。

第一个方向是模拟人类的记忆遗忘机制。人类的记忆有一个特点，就是近期的记忆清晰，远期的记忆模糊，这是一种自然的信息压缩。而**DeepSeek-OCR**的视觉到文本压缩，恰好能模拟这个过程。比如，对于近期的对话历史或文本片段，可以用高分辨率图像渲染，生成较多的**视觉token**，解码精度高；对于远期的对话历史或文本片段，逐渐降低图像分辨率，生成较少的**视觉token**，解码精度降低；对于极远期的信息，甚至可以进一步压缩，只保留关键词或摘要。这种方式不仅能大幅减少模型的**token**消耗，还能让模型的记忆更符合人类的认知规律。比如在多轮对话中，模型不需要记住所有轮次的完整文本，只需记住近期的详细内容和远期的核心信息，这会让对话更加自然。

第二个方向是超长上下文的处理。当前**LLM**的上下文窗口上限一般是128k或256k**token**。但是对于百万级、千万级**token**的文本，即使是最大的上下文窗口也无能为力。而视觉到文本的压缩，能够提供一种无限上下文的可能。比如把超长篇文本分成多个片段，每个片段渲染成图像，然后用**DeepEncoder**压缩成**视觉token**；当模型处理的时候，不需要加载所有文本**token**，只需加载压缩后的**视觉token**；如果需要查看某个片段的细节，再用**OCR**解码对应的**视觉token**，生成详细文本。这种压缩存储+按需解码的模式，可能是未来**LLM**处理超长篇文本的核心方案。

第三个方向是**LLM**与视觉模型的协同优化。目前**DeepSeek-OCR**是一个独立的视觉模型，但是未来的趋势是把视觉-文本压缩的能力融入到语言模型本身。在语言模型的预训练阶段，加入从文本到图像，到**视觉token**，再到文本的闭环任务，让语言模型直接学会压缩和解码；然后在语言模型处理长文本的时候，能自动把文本转换成图像，用内置的视觉编码器压缩成**token**，再进行后续处理；这种方式不需要额外的视觉模型，还能让语言模型的长文本处理能力更集成、更高效。

当然，这个技术思路也存在一些需要解决的问题。首先是分辨率与精度的平衡。目前当压缩比超过20倍时，精度会下降到60%左右，如何在更高压缩比下保持精度，是未来需要优化的重点。其次是复杂布局的处理。对于包含大量表格、公式、图表的复杂文档，如何确保**视觉token**能保留所有关键信息，避免解码时丢失结构，还需要进一步研究。最后是实时性。把文本转换成图像，再压缩成**视觉token**，这个过程会增加一定的延迟，如何优化这个流程，让它能实时处理，也是实际部署时需要解决的问题。

### 总结：DeepSeek-OCR的核心贡献与局限性

总结一下，**DeepSeek-OCR**虽然以**OCR**命名，但是它的价值远不止于**OCR**本身。它是一个视觉-文本压缩的验证原型，也是连接**LLM**和长文本处理的桥梁。它的核心贡献可以概括为三点：

第一，验证了视觉到文本压缩的可行性。通过**Fox基准**的实验，它证明了10倍压缩下能保持97%的解码精度，20倍压缩下能保持60%的精度，这为后续的研究提供了坚实的实验基础。

第二，提出了高效的视觉编码器**DeepEncoder**。通过**窗口注意力**到**卷积压缩**，再到**全局注意力**的结构，**DeepEncoder**解决了现有视觉编码器高分辨率、低激活、少**token**不能兼顾的问题，为视觉模型的编码器设计提供了新的思路。

第三，展示了强大的实际应用价值。在**OmniDocBench基准**上，它用更少的**token**超越了主流**OCR**模型；在生产环境中，单张A100-40G GPU每天能生成20万页的训练数据，20个节点每天能生成3300万页数据，这对于大规模的语言模型训练来说，是一个非常重要的数据引擎。

当然，**DeepSeek-OCR**也有它的局限性。它目前还是一个概念验证模型，还需要更多的实验来验证它在超长篇文本、更多语言、更复杂场景下的性能。团队在论文中也提到，未来会做更多的研究，比如数字到光学文本的交错预训练、大海捞针测试等等。但是无论如何，**DeepSeek-OCR**的出现为我们打开了一扇新的大门。它告诉我们，解决**LLM**的难题，不一定非要堆参数、扩窗口，有时候换个模态，换个思路，可能会有更大的突破。毕竟，就连**Andrej Karpathy**（安德烈·卡帕西: 知名人工智能研究员，特斯拉AI前负责人）也针对这篇论文提出，也许所有输入大模型的内容都应该是图像而不是文本。