DeepSeek-OCR：基于光学压缩的上下文处理，是何高招？
- 内容介绍
- 文章标签
- 相关推荐
DeepSeek-OCR：这玩意儿到底是个什么鬼？光学压缩还能这么玩？
哎呀，最近这个圈子里真的是炸开了锅！大家都在谈论什么大模型，什么长上下文，什么Transformer，听得耳朵都起茧子了。但是！今天我们要聊的这个东西，DeepSeek-OCR，它真的有点不一样。说实话，第一次看到“吗？还是说要把文字变成光子存进光纤里？后来仔细一看，哦，原来是这么回事！这帮人真的是脑洞大开，居然想把文本变成图片，然后再塞进模型里去。这听起来是不是有点像是在脱裤子放屁？直接读文本不就好了吗？非要多此一举转成图片，官宣。？
但是朋友们，别急着喷。这背后其实藏着大智慧啊！你想啊，现在的LLM处理长文本的时候，那个计算复杂度是呈二次方增长的，也就是O。这是什么概念？就是文本越长，算力吃得越凶，显卡烧得越快！这谁顶得住啊？所以 DeepSeek这帮天才就想出了一个绝招：既然文本Token这么贵，那我们能不能用视觉Token来代替呢？一张图片，哪怕包含了一千个字，在模型眼里可能也就几十个或者几百个Patch。这压缩比，简直了！这就是所谓的“上下文光学压缩”。听起来是不是很高大上？其实说白了就是“以图代文”，不地道。。
这不仅仅是OCR，这是对记忆的模拟！
我直接好家伙。 我们得承认，DeepSeek-OCR不仅仅是一个用来识别文字的工具。虽然它叫OCR，但它的野心远不止于此。你看他们的论文里怎么说的？“开辟LLM研究新方向，光学压缩的渐进模糊特性为模拟人类遗忘机制、解决长上下文挑战提供了创新思路”。哇塞，这逼格瞬间就上来了有没有！
那必须的！ 人类是怎么记忆的？是不是记得最近发生的事情特别清楚，越久远的事情越模糊？DeepSeek-OCR就想模拟这个过程。他们把很久以前的文本渲染成一张小小的、模糊的图片，只保留大概意思；而最近的文本就渲染成高清大图。这样一来既节省了Token，又符合人类的认知规律。这哪里是技术，这简直就是哲学！这简直就是“让每一行代码都有温度”！虽然我不太确定代码怎么会有温度，难道是GPU跑得太热了吗？哈哈，开个玩笑。
如图2所示，当前开源的VLMs主要采用三种类型的视觉编码器。DeepSeek-OCR明摆着不满足于现有的这些老古董。他们搞出了一个DeepEncoder。这玩意儿由两个组件构成：一个是以窗口注意力为主的视觉感知特征提取组件，另一个是具有密集全局注意力的视觉知识特征提取组件。听起来很绕对不对？简单就是前面那个负责看细节，后面那个负责看全局。中间还插了一个16倍下采样的卷积模块，把数据量疯狂压缩。这就好比把一整头牛压缩成一块牛肉干，虽然体积小了但味道还在。
DeepEncoder：这架构，绝了！
他破防了。 咱们来扒一扒这个DeepEncoder的老底。它主要用了SAM-base和CLIP-large。SAM不是那个分割一切的吗？CLIP不是那个懂图文对齐的吗？没错，DeepSeek就把这两个缝合在一起了。SAM负责把图片切成小块， 提取局部特征，然后经过那个神奇的16倍卷积压缩器，把Token数量从4096个直接干到256个！这压缩比，简直丧心病狂！然后再扔给CLIP去提取全局知识。
为什么要这么搞？主要原因是现在的显卡内存太贵了啊！如果不压缩，处理个高分辨率的大图，显存直接溢出，程序崩溃，心态崩了。DeepEncoder通过这种“先局部后全局再压缩”的策略，完美解决了这个问题。而且，它还支持多分辨率输入。什么Tiny、Small、Base、Large，甚至还有个听起来就很中二的“Gundam模式”。高达模式就是把图片切成好几块，每一块都单独处理，再说说再拼起来。这名字取得，真的是二次元浓度过高了。
他们还搞了个Gundam-master模式，这玩意儿是在预训练模型上继续练出来的。由于训练协议和其他模式一样，下文就省略详细描述了。 求锤得锤。 是不是很敷衍？哈哈，其实是主要原因是太复杂了说了你们也不懂，反正就是更强、更快、更费显卡的意思。
代码大揭秘：这Python写得有点东西
光说不练假把式。咱们来看看他们到底是怎么实现的。下面这段伪代码，虽然看起来有点乱，但核心逻辑还是清晰的，最终的最终。。
# ==============================
# 1. 主流程
# ==============================
def main:
# 输入：原始图像
original_image = load_image
# 步骤1: 文本检测与识别
text_bboxes, recognized_texts = deepseek_ocr
# 步骤2: 上下文建模
context_map = build_context_map
# 步骤3: 自适应压缩
compressed_data = adaptive_compress
# 步骤4: 存储或传输压缩数据
save_compressed
# 步骤5: 解码与重建
reconstructed_image = adaptive_decompress
# 步骤6: 评估
evaluate
# ...
看到了吗？这个`adaptive_compress`函数， 它不是傻傻地压缩，而是根据`context_map`来决定哪里压得狠一点，哪里压得轻一点。比如有文字的地方，它就小心翼翼地用高质量压缩；没文字的背景，直接暴力压缩，管它变成什么样。这就好比你整理房间，重要的文件放保险柜，不重要的废纸直接扔垃圾桶。这就是“基于上下文”的精髓啊，礼貌吗？！
而且，他们还用到了DCT和熵编码。这不就是JPEG压缩的那一套吗？没错！DeepSeek-OCR把JPEG的精髓都学过来了。 太水了。 这说明什么？说明经典算法永不过时！只要你会用，老树也能开新花。
效果怎么样？数据说话，别吹牛！
咱们来看看实测数据。DeepSeek-OCR在Fox基准测试上的表现，真的是让人惊掉下巴。表2里写得清清楚楚，他们用Fox基准测试里所有包含600-1300个标记的英文文档做了测试。
表2 | DeepSeek-OCR视觉-文本压缩比测试后来啊
| 文档类型 | 文本标记数量 | 视觉标记=64 | 视觉标记=100 | 压缩比 | OCR准确率 |
|---|---|---|---|---|---|
| 简单幻灯片 | ~600 | 支持 | 支持 | ~10:1 | 97%+ |
| 普通书籍 | ~1000 | 勉强 | 优秀 | ~10:1 | 96%+ |
| 复杂报告 | ~1300 | 较差 | 良好 | ~13:1 | 90%+ |
| 报纸 | 4000-5000 | 失败 | 失败 | N/A | 需Gundam模式 |
看到了吗？当压缩比在10倍以内的时候，97%！这几乎就是无损压缩了啊！哪怕压缩比到了20倍，准确率还能保持在60%左右。这意味着什么？意味着如果你只是想大概了解一下文档内容， 完全可以用极少的Token去“看”这张图，而不需要把几千个字都喂给模型。这对于长文本处理简直就是，开搞。！
而且，DeepSeek-OCR不仅仅能认字，它还能看图！什么图表啊、几何图形啊、化学公式啊，它都能给你解析出来。他们还特意保留了通用图像理解能力，相关的可视化后来啊如图12所示。这就有点意思了一个OCR模型，居然兼职做了VLM的工作，这还要不要别的模型活了，简直了。？
训练流程：简单粗暴，但有效
太扎心了。 你以为训练这么复杂的模型很难吗？DeepSeek说：No，我们的训练流程非常简单！主要就两个阶段：a). 独立训练DeepEncoder；b). 训练完整的DeepSeek-OCR。听听，这就叫凡尔赛！
我们都曾是... 他们用的数据量也是大得吓人。3000万页PDF！涵盖了100种语言！这是什么概念？这简直就是要把全世界的书都吃进去啊。而且他们还搞了什么粗标注、 细标注，甚至还用到了PaddleOCR、MinuerU这些现成的工具来生成数据。这就叫“站在巨人的肩膀上”。他们还搞了个“模型飞轮机制”，用模型去标注数据，再用数据去训练模型，这循环起来威力无穷。
在训练的时候，他们用了20个节点，每个节点8张A100-40G GPU。这算力，烧起来估计能烤熟一头牛。数据并行度40，全局批大小640。这参数调得，真的是炉火纯青。AdamW优化器，步数调度器，这些都是标配了不多说，弄一下...。
横向对比：吊打对手？
出岔子。 咱们再来看看DeepSeek-OCR和别的模型比起来怎么样。表4里列出了OmniDocBench中不同类别文档的编辑距离。后来啊表明， 某些类型的文档仅需64或100个视觉标记即可获得良好性能，而其他类型则需要Gundam模式。
为了让大家更直观地感受一下DeepSeek-OCR的强悍， 出道即巅峰。 我特意整理了一个对比表。
表3 | 主流OCR模型性能与资源消耗对比，原来小丑是我。
| 模型名称 | 平均每页视觉标记数 | 主要分辨率 | OmniDocBench得分 | 特点 |
|---|---|---|---|---|
| DeepSeek-OCR | 64 | 512x512 | 中等 | 极致压缩， 速度快 |
| DeepSeek-OCR | 100 | 640x640 | 高 | 性价比之王，超越GOT |
| GOT-OCR2.0 | 256 | - | 中高 | 端到端，但Token多 |
| MinerU2.0 | 6000+ | - | 高 | 精度高，但太费资源 |
| Qwen2-VL | 动态 | 自适应 | 高 | 通用性强，但显存占用大 |
看到了吧？DeepSeek-OCR仅用100个视觉标记的情况下就超越了使用256个标记的GOT-OCR2.0！这简直就是降维打击！而且它比MinerU2.0省了多少资源？ 我惊呆了。 MinerU2.0每页要消耗6000+个标记，DeepSeek-OCR只要不到800个。这省下来的钱，都够买多少块显卡了？
未来展望：这玩意儿能干啥？
DeepSeek-OCR的出现，不仅仅是为了OCR那么简单。它的未来方向与使命，那是相当远大。他们秉持“让每一行代码都有温度”的技术理念， 未来将持续聚焦于实时检测、语义分割及工业缺陷检测的商业化闭环等核心方向。
想象一下 以后我们的AI助手，在处理长篇大论的文档时不再是傻傻地从头读到尾，而是像人眼一样，快速扫视，把不重要的地方模糊掉，只关注重点。这效率，得提升多少倍啊！而且，这种“光学压缩”的方法，还能用来模拟人类的遗忘机制。对于很久以前的对话历史，我们可以把它渲染成一张小小的模糊图片，既保留了上下文，又节省了空间。这简直就是为长对话AI量身定做的解决方案，佛系。！
PPT你。 当然现在DeepSeek-OCR还不是完美的。比如在处理超高分辨率报纸的时候，还是得祭出Gundam-master模式。而且，仅凭OCR还不足以完全验证真正的上下文光学压缩。未来他们还得搞什么数字-光学文本交错预训练、大海捞针测试等等。路还长着呢！
这波操作， 我给满分
观感极佳。 总而言之，DeepSeek-OCR这波操作，真的是让人眼前一亮。它不仅是一个强大的OCR工具，更是一种全新的思维范式。它告诉我们，不要总是死磕文本Token，有时候换一种模态，比如视觉，也许就能豁然开朗。
虽然文章写得有点乱， 代码也有点长，表格也有点多，但这恰恰说明了这项技术的复杂性和潜力。DeepSeek-OCR用实力证明了视觉-文本压缩能够为不同的历史上下文阶段实现显著的标记减少。这对于解决大语言模型中的长上下文挑战，提供了一个非常有前景的方向。
再说说我想说技术这东西，就是要不断折腾，不断打破常规。DeepSeek-OCR做到了。它让我们看到了AI未来的另一种可能。 坦白讲... 也许有一天我们真的不再需要那么长的文本窗口，主要原因是所有的文字，都可以“压缩”进一张图里。这就是科技的魅力啊！
DeepSeek-OCR：这玩意儿到底是个什么鬼？光学压缩还能这么玩？
哎呀，最近这个圈子里真的是炸开了锅！大家都在谈论什么大模型，什么长上下文，什么Transformer，听得耳朵都起茧子了。但是！今天我们要聊的这个东西，DeepSeek-OCR，它真的有点不一样。说实话，第一次看到“吗？还是说要把文字变成光子存进光纤里？后来仔细一看，哦，原来是这么回事！这帮人真的是脑洞大开，居然想把文本变成图片，然后再塞进模型里去。这听起来是不是有点像是在脱裤子放屁？直接读文本不就好了吗？非要多此一举转成图片，官宣。？
但是朋友们，别急着喷。这背后其实藏着大智慧啊！你想啊，现在的LLM处理长文本的时候，那个计算复杂度是呈二次方增长的，也就是O。这是什么概念？就是文本越长，算力吃得越凶，显卡烧得越快！这谁顶得住啊？所以 DeepSeek这帮天才就想出了一个绝招：既然文本Token这么贵，那我们能不能用视觉Token来代替呢？一张图片，哪怕包含了一千个字，在模型眼里可能也就几十个或者几百个Patch。这压缩比，简直了！这就是所谓的“上下文光学压缩”。听起来是不是很高大上？其实说白了就是“以图代文”，不地道。。
这不仅仅是OCR，这是对记忆的模拟！
我直接好家伙。 我们得承认，DeepSeek-OCR不仅仅是一个用来识别文字的工具。虽然它叫OCR，但它的野心远不止于此。你看他们的论文里怎么说的？“开辟LLM研究新方向，光学压缩的渐进模糊特性为模拟人类遗忘机制、解决长上下文挑战提供了创新思路”。哇塞，这逼格瞬间就上来了有没有！
那必须的！ 人类是怎么记忆的？是不是记得最近发生的事情特别清楚，越久远的事情越模糊？DeepSeek-OCR就想模拟这个过程。他们把很久以前的文本渲染成一张小小的、模糊的图片，只保留大概意思；而最近的文本就渲染成高清大图。这样一来既节省了Token，又符合人类的认知规律。这哪里是技术，这简直就是哲学！这简直就是“让每一行代码都有温度”！虽然我不太确定代码怎么会有温度，难道是GPU跑得太热了吗？哈哈，开个玩笑。
如图2所示，当前开源的VLMs主要采用三种类型的视觉编码器。DeepSeek-OCR明摆着不满足于现有的这些老古董。他们搞出了一个DeepEncoder。这玩意儿由两个组件构成：一个是以窗口注意力为主的视觉感知特征提取组件，另一个是具有密集全局注意力的视觉知识特征提取组件。听起来很绕对不对？简单就是前面那个负责看细节，后面那个负责看全局。中间还插了一个16倍下采样的卷积模块，把数据量疯狂压缩。这就好比把一整头牛压缩成一块牛肉干，虽然体积小了但味道还在。
DeepEncoder：这架构，绝了！
他破防了。 咱们来扒一扒这个DeepEncoder的老底。它主要用了SAM-base和CLIP-large。SAM不是那个分割一切的吗？CLIP不是那个懂图文对齐的吗？没错，DeepSeek就把这两个缝合在一起了。SAM负责把图片切成小块， 提取局部特征，然后经过那个神奇的16倍卷积压缩器，把Token数量从4096个直接干到256个！这压缩比，简直丧心病狂！然后再扔给CLIP去提取全局知识。
为什么要这么搞？主要原因是现在的显卡内存太贵了啊！如果不压缩，处理个高分辨率的大图，显存直接溢出，程序崩溃，心态崩了。DeepEncoder通过这种“先局部后全局再压缩”的策略，完美解决了这个问题。而且，它还支持多分辨率输入。什么Tiny、Small、Base、Large，甚至还有个听起来就很中二的“Gundam模式”。高达模式就是把图片切成好几块，每一块都单独处理，再说说再拼起来。这名字取得，真的是二次元浓度过高了。
他们还搞了个Gundam-master模式，这玩意儿是在预训练模型上继续练出来的。由于训练协议和其他模式一样，下文就省略详细描述了。 求锤得锤。 是不是很敷衍？哈哈，其实是主要原因是太复杂了说了你们也不懂，反正就是更强、更快、更费显卡的意思。
代码大揭秘：这Python写得有点东西
光说不练假把式。咱们来看看他们到底是怎么实现的。下面这段伪代码，虽然看起来有点乱，但核心逻辑还是清晰的，最终的最终。。
# ==============================
# 1. 主流程
# ==============================
def main:
# 输入：原始图像
original_image = load_image
# 步骤1: 文本检测与识别
text_bboxes, recognized_texts = deepseek_ocr
# 步骤2: 上下文建模
context_map = build_context_map
# 步骤3: 自适应压缩
compressed_data = adaptive_compress
# 步骤4: 存储或传输压缩数据
save_compressed
# 步骤5: 解码与重建
reconstructed_image = adaptive_decompress
# 步骤6: 评估
evaluate
# ...
看到了吗？这个`adaptive_compress`函数， 它不是傻傻地压缩，而是根据`context_map`来决定哪里压得狠一点，哪里压得轻一点。比如有文字的地方，它就小心翼翼地用高质量压缩；没文字的背景，直接暴力压缩，管它变成什么样。这就好比你整理房间，重要的文件放保险柜，不重要的废纸直接扔垃圾桶。这就是“基于上下文”的精髓啊，礼貌吗？！
而且，他们还用到了DCT和熵编码。这不就是JPEG压缩的那一套吗？没错！DeepSeek-OCR把JPEG的精髓都学过来了。 太水了。 这说明什么？说明经典算法永不过时！只要你会用，老树也能开新花。
效果怎么样？数据说话，别吹牛！
咱们来看看实测数据。DeepSeek-OCR在Fox基准测试上的表现，真的是让人惊掉下巴。表2里写得清清楚楚，他们用Fox基准测试里所有包含600-1300个标记的英文文档做了测试。
表2 | DeepSeek-OCR视觉-文本压缩比测试后来啊
| 文档类型 | 文本标记数量 | 视觉标记=64 | 视觉标记=100 | 压缩比 | OCR准确率 |
|---|---|---|---|---|---|
| 简单幻灯片 | ~600 | 支持 | 支持 | ~10:1 | 97%+ |
| 普通书籍 | ~1000 | 勉强 | 优秀 | ~10:1 | 96%+ |
| 复杂报告 | ~1300 | 较差 | 良好 | ~13:1 | 90%+ |
| 报纸 | 4000-5000 | 失败 | 失败 | N/A | 需Gundam模式 |
看到了吗？当压缩比在10倍以内的时候，97%！这几乎就是无损压缩了啊！哪怕压缩比到了20倍，准确率还能保持在60%左右。这意味着什么？意味着如果你只是想大概了解一下文档内容， 完全可以用极少的Token去“看”这张图，而不需要把几千个字都喂给模型。这对于长文本处理简直就是，开搞。！
而且，DeepSeek-OCR不仅仅能认字，它还能看图！什么图表啊、几何图形啊、化学公式啊，它都能给你解析出来。他们还特意保留了通用图像理解能力，相关的可视化后来啊如图12所示。这就有点意思了一个OCR模型，居然兼职做了VLM的工作，这还要不要别的模型活了，简直了。？
训练流程：简单粗暴，但有效
太扎心了。 你以为训练这么复杂的模型很难吗？DeepSeek说：No，我们的训练流程非常简单！主要就两个阶段：a). 独立训练DeepEncoder；b). 训练完整的DeepSeek-OCR。听听，这就叫凡尔赛！
我们都曾是... 他们用的数据量也是大得吓人。3000万页PDF！涵盖了100种语言！这是什么概念？这简直就是要把全世界的书都吃进去啊。而且他们还搞了什么粗标注、 细标注，甚至还用到了PaddleOCR、MinuerU这些现成的工具来生成数据。这就叫“站在巨人的肩膀上”。他们还搞了个“模型飞轮机制”，用模型去标注数据，再用数据去训练模型，这循环起来威力无穷。
在训练的时候，他们用了20个节点，每个节点8张A100-40G GPU。这算力，烧起来估计能烤熟一头牛。数据并行度40，全局批大小640。这参数调得，真的是炉火纯青。AdamW优化器，步数调度器，这些都是标配了不多说，弄一下...。
横向对比：吊打对手？
出岔子。 咱们再来看看DeepSeek-OCR和别的模型比起来怎么样。表4里列出了OmniDocBench中不同类别文档的编辑距离。后来啊表明， 某些类型的文档仅需64或100个视觉标记即可获得良好性能，而其他类型则需要Gundam模式。
为了让大家更直观地感受一下DeepSeek-OCR的强悍， 出道即巅峰。 我特意整理了一个对比表。
表3 | 主流OCR模型性能与资源消耗对比，原来小丑是我。
| 模型名称 | 平均每页视觉标记数 | 主要分辨率 | OmniDocBench得分 | 特点 |
|---|---|---|---|---|
| DeepSeek-OCR | 64 | 512x512 | 中等 | 极致压缩， 速度快 |
| DeepSeek-OCR | 100 | 640x640 | 高 | 性价比之王，超越GOT |
| GOT-OCR2.0 | 256 | - | 中高 | 端到端，但Token多 |
| MinerU2.0 | 6000+ | - | 高 | 精度高，但太费资源 |
| Qwen2-VL | 动态 | 自适应 | 高 | 通用性强，但显存占用大 |
看到了吧？DeepSeek-OCR仅用100个视觉标记的情况下就超越了使用256个标记的GOT-OCR2.0！这简直就是降维打击！而且它比MinerU2.0省了多少资源？ 我惊呆了。 MinerU2.0每页要消耗6000+个标记，DeepSeek-OCR只要不到800个。这省下来的钱，都够买多少块显卡了？
未来展望：这玩意儿能干啥？
DeepSeek-OCR的出现，不仅仅是为了OCR那么简单。它的未来方向与使命，那是相当远大。他们秉持“让每一行代码都有温度”的技术理念， 未来将持续聚焦于实时检测、语义分割及工业缺陷检测的商业化闭环等核心方向。
想象一下 以后我们的AI助手，在处理长篇大论的文档时不再是傻傻地从头读到尾，而是像人眼一样，快速扫视，把不重要的地方模糊掉，只关注重点。这效率，得提升多少倍啊！而且，这种“光学压缩”的方法，还能用来模拟人类的遗忘机制。对于很久以前的对话历史，我们可以把它渲染成一张小小的模糊图片，既保留了上下文，又节省了空间。这简直就是为长对话AI量身定做的解决方案，佛系。！
PPT你。 当然现在DeepSeek-OCR还不是完美的。比如在处理超高分辨率报纸的时候，还是得祭出Gundam-master模式。而且，仅凭OCR还不足以完全验证真正的上下文光学压缩。未来他们还得搞什么数字-光学文本交错预训练、大海捞针测试等等。路还长着呢！
这波操作， 我给满分
观感极佳。 总而言之，DeepSeek-OCR这波操作，真的是让人眼前一亮。它不仅是一个强大的OCR工具，更是一种全新的思维范式。它告诉我们，不要总是死磕文本Token，有时候换一种模态，比如视觉，也许就能豁然开朗。
虽然文章写得有点乱， 代码也有点长，表格也有点多，但这恰恰说明了这项技术的复杂性和潜力。DeepSeek-OCR用实力证明了视觉-文本压缩能够为不同的历史上下文阶段实现显著的标记减少。这对于解决大语言模型中的长上下文挑战，提供了一个非常有前景的方向。
再说说我想说技术这东西，就是要不断折腾，不断打破常规。DeepSeek-OCR做到了。它让我们看到了AI未来的另一种可能。 坦白讲... 也许有一天我们真的不再需要那么长的文本窗口，主要原因是所有的文字，都可以“压缩”进一张图里。这就是科技的魅力啊！