{"notes":[{"id":"deepseek/deepseek-ocr","category":"deepseek","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DeepSeek-OCR","subtitle":"一图胜千言","author":"Z. Yuan","paperDate":"2025-10-21","publishedOn":"2026-03-09","world":"external/deepseek-ocr","paperTitle":"DeepSeek-OCR: Contexts Optical Compression","paperUrl":"https://arxiv.org/abs/2510.18234","bibliography":{"title":"DeepSeek-OCR: Contexts Optical Compression","authors":["Haoran Wei","Yaofeng Sun","Yukun Li"],"url":"https://arxiv.org/abs/2510.18234","pdfUrl":"https://arxiv.org/pdf/2510.18234v1","codeUrl":"https://github.com/deepseek-ai/DeepSeek-OCR","preprint":{"id":"2510.18234","submittedOn":"2025-10-21","url":"https://arxiv.org/abs/2510.18234"},"publication":null,"citation":"@misc{deepseekdeepseekocr2025,\n  title = {{DeepSeek-OCR: Contexts Optical Compression}},\n  author = {Haoran Wei and Yaofeng Sun and Yukun Li},\n  year = {2025},\n  eprint = {2510.18234},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2510.18234}\n}\n","citationPath":"/content/papers/citations/deepseek/deepseek-ocr.66e8e5a7db8d.bib"},"thumbnail":{"src":"/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png","width":1288,"height":350},"locale":"zh-hans","path":"/content/papers/zh-hans/deepseek/deepseek-ocr.84ff24061e34.md","headings":[{"id":"定义问题","text":"定义问题","depth":2},{"id":"解决问题","text":"解决问题","depth":2},{"id":"整体架构","text":"整体架构","depth":3},{"id":"跟着一页-10241024-的图像走一遍","text":"跟着一页 1024×1024 的图像走一遍","depth":3},{"id":"解码器从压缩的表示中把字还原","text":"解码器：从压缩的表示中把字还原","depth":3},{"id":"数据与训练","text":"数据与训练","depth":3},{"id":"讨论","text":"讨论","depth":2},{"id":"压缩比实验fox-上的-100-页","text":"压缩比实验：Fox 上的 100 页","depth":3},{"id":"实际文档omnidocbench","text":"实际文档：OmniDocBench","depth":3},{"id":"光学压缩与遗忘","text":"光学压缩与遗忘","depth":3},{"id":"发布后的讨论","text":"发布后的讨论","depth":3},{"id":"结论","text":"结论","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"model-evaluation/linguistic-crutch","relation":"referenced","topic":""}]},{"id":"model-evaluation/linguistic-crutch","category":"model-evaluation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Linguistic Crutch","subtitle":"脑补的代价","author":"Z. Yuan","paperDate":"2026-01-07","publishedOn":"2026-02-21","paperTitle":"Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR","paperUrl":"https://arxiv.org/abs/2601.03714","bibliography":{"title":"Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR","authors":["Yunhao Liang","Ruixuan Ying","Bo Li","Hong Li","Kai Yan","Qingwen Li","Min Yang","Okamoto Satoshi","Zhe Cui","Shiwen Ni"],"url":"https://arxiv.org/abs/2601.03714","pdfUrl":"https://arxiv.org/pdf/2601.03714v2","codeUrl":null,"preprint":{"id":"2601.03714","submittedOn":"2026-01-07","url":"https://arxiv.org/abs/2601.03714"},"publication":null,"citation":"@misc{modelevaluationlinguisticcrutch2026,\n  title = {{Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR}},\n  author = {Yunhao Liang and Ruixuan Ying and Bo Li and Hong Li and Kai Yan and Qingwen Li and Min Yang and Okamoto Satoshi and Zhe Cui and Shiwen Ni},\n  year = {2026},\n  eprint = {2601.03714},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2601.03714}\n}\n","citationPath":"/content/papers/citations/model-evaluation/linguistic-crutch.af1f73a098b5.bib"},"thumbnail":{"src":"/content/papers/assets/3dfc834dee089d76acab6a1ce767b06c592ef84c6b48c2a5f79a7723f9cc3f09.png","width":644,"height":300},"locale":"zh-hans","path":"/content/papers/zh-hans/model-evaluation/linguistic-crutch.9d0e99160bb7.md","headings":[{"id":"定义问题","text":"定义问题","depth":2},{"id":"解决问题","text":"解决问题","depth":2},{"id":"让图像条件保持一致","text":"让图像条件保持一致","depth":3},{"id":"三种破坏方式","text":"三种破坏方式","depth":3},{"id":"另外两个测试","text":"另外两个测试","depth":3},{"id":"讨论","text":"讨论","depth":2},{"id":"句子一旦没了意思","text":"句子一旦没了意思","depth":3},{"id":"单词一旦不像单词","text":"单词一旦不像单词","depth":3},{"id":"其他模型呢","text":"其他模型呢？","depth":3},{"id":"问答与长上下文","text":"问答与长上下文","depth":3},{"id":"读这篇时要知道的事","text":"读这篇时要知道的事","depth":3},{"id":"结论","text":"结论","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"deepseek/deepseek-ocr","relation":"citing","topic":""}]}],"text":"看名字，这是一个 OCR 模型；读完摘要，会发现作者真正想问的是另一件事。\n\nLLM 处理长文本时，注意力的计算量会随长度的平方增长。一页文档如果有一千个文本 token，能不能把它拍成一张图，用一百个、甚至六十四个视觉 token 交给模型，再让模型把原文读回来？\n\n如果可以，图像就成了一种压缩文本的方式。作者把这个想法叫做**上下文光学压缩**（contexts optical compression），OCR 则是用来验证它的考场：输入是图像，答案是原文，对不对一比就知道。\n\n这篇是 DeepSeek-AI 在 2025 年 10 月 21 日上传 arXiv 的技术报告，本文依据 v1 阅读。权重与代码同步开源。\n\n## 定义问题\n\n作者在相关工作一节把问题问得很直接：一份一千个单词的文档，最少需要多少个视觉 token 才能解码回来？\n\n要回答这个问题，得有一个能调节视觉 token 数量的编码器。作者盘点了当时开源 VLM 常见的三种做法，各有缺点：\n\n1. **双塔式**，例如 Vary：另外并联一个 SAM 编码器来处理高分辨率。参数和显存还算可控，但图像要做两套预处理，训练时也不好做流水线并行。\n2. **切块式**，例如 InternVL2.0：把大图切成小块分别编码。能处理极高的分辨率，但原生分辨率通常低于 512×512，大图会被切得很碎，视觉 token 一下子就变多。\n3. **自适应分辨率**，例如 Qwen2-VL：直接在原图上切 patch。灵活性好，但大图的激活显存很高，视觉 token 一长，预填充与生成都会变慢。\n\n作者要的编码器有五个条件：能处理高分辨率、高分辨率下显存不爆、视觉 token 少、支持多种分辨率、参数量适中。现成的方案都无法全部满足，所以他们自己做了一个，叫 **DeepEncoder**。\n\n## 解决问题\n\n### 整体架构\n\n[![DeepSeek-OCR 架构图：输入页面切成 16×16 的 patch，经过由 SAM（局部注意力）、16 倍下采样卷积与 CLIP（全局注意力）组成的 DeepEncoder，再连同提示词交给 DeepSeek-3B MoE 解码器输出文本](/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png)](/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png)\n\n*原论文 Figure 3，取自 [**v1 PDF 第 5 页**](https://arxiv.org/pdf/2510.18234v1#page=5)，CC BY 4.0。左半部分虚线框内是 DeepEncoder，右边是解码器。*\n\n先从左往右看一遍：\n\n- **SAM**（8,000 万参数，ViTDet 架构）负责感知，主要使用局部的窗口注意力。\n- **Conv 16x** 是两层卷积，把 token 数降到十六分之一。\n- **CLIP**（ViT，3 亿参数）负责全局注意力，原本的 patch embedding 层被拿掉了，因为它的输入已经是前一段输出的 token。\n- **DeepSeek-3B** 是解码器，30 亿参数的 MoE，每次推理激活约 5.7 亿。\n\n整个 DeepEncoder 约 3.8 亿参数。这样排的道理在于：**token 很多的时候先只做便宜的局部注意力，压缩完再做昂贵的全局注意力**。\n\n### 跟着一页 1024×1024 的图像走一遍\n\n我们拿论文自己的例子，Base 模式下 1024×1024 的页面：\n\n1. SAM 以 16×16 像素为一块，得到 1024/16 × 1024/16 = 64×64 = **4,096** 个 patch token。这一段以窗口注意力为主，参数也只有 8,000 万，显存还扛得住。\n2. 卷积模块是两层 kernel 3、步长 2、padding 1 的卷积，通道数从 256 增加到 1024。每层把长和宽各减半：64×64 → 32×32 → 16×16，token 只剩 4,096 / 16 = **256** 个。\n3. 这 256 个 token 进入 CLIP 做全局注意力。256 个 token 两两之间的注意力，和 4,096 个相比，分数矩阵小了 256 倍。\n4. 解码器拿到这 256 个视觉 token 与提示词，自回归地输出文本。\n\n所以「一页变成多少个 token」，完全由输入分辨率决定：\n\n| 模式 | 分辨率 | 视觉 token | 处理方式 |\n| --- | --- | ---: | --- |\n| Tiny | 512×512 | 64 | 直接缩放 |\n| Small | 640×640 | 100 | 直接缩放 |\n| Base | 1024×1024 | 256 | 保持比例，填充 |\n| Large | 1280×1280 | 400 | 保持比例，填充 |\n| Gundam | n 个 640×640 局部＋1024×1024 全局 | n×100＋256 | 切块，n 为 2 到 9 |\n\n*表：整理自原论文 §3.2.2 与 Figure 4。另有 Gundam-master 模式（1024×1024 局部＋1280×1280 全局），是在已训练好的模型上继续训练得到的。*\n\n\n> [!TIP]\n> \n> **填充以后，有效的 token 还剩多少？**\n> \n> Base 与 Large 模式会把图像填充成正方形来保持比例，填充区域的 token 没有内容。论文给出了有效 token 的算法：\n> \n> $$\n> N_{valid}=\\left\\lceil N_{actual}\\times\\left[1-\\frac{\\max(w,h)-\\min(w,h)}{\\max(w,h)}\\right]\\right\\rceil\n> $$\n> \n> 拿 A4 纵向页面试算，宽高比约 1:1.414，方括号内是 $1-(1.414-1)/1.414\\approx0.707$。Base 模式得到 $\\lceil256\\times0.707\\rceil=182$，Large 模式得到 283。\n> \n> 后面 OmniDocBench 的表格里，Base 标为 256(182)，Large 标为 400(285)。表上是整个测试集的平均，页面比例各不相同；这里只是用 A4 验算一下量级。\n\n\n### 解码器：从压缩的表示中把字还原\n\n作者把解码器的工作写成一个映射：从 $n$ 个压缩后的视觉 token $\\mathbf{Z}\\in\\mathbb{R}^{n\\times d_{latent}}$，重建出 $N$ 个文本 token 的表示。\n\n解码器用的是 DeepSeekMoE，推理时从 64 个路由专家中激活 6 个，外加 2 个共享专家。按作者的说法，它有 30 亿参数模型的表达能力，推理成本却接近 5 亿参数的小模型。\n\n这里值得停一下：当 $N$ 比 $n$ 大十倍以上，解码器不可能只靠「逐个翻译」每个视觉 token。它得用自己学过的语言知识，把压缩后的信息展开成完整的句子。这是方法能够成立的原因，也是后续研究质疑它的地方，讨论一节会再回到这一点。\n\n### 数据与训练\n\n文档数据是重点。作者从网上收集了约 3,000 万页 PDF，涵盖约 100 种语言，其中中英文约 2,500 万页，标注分两种：\n\n- **粗标注**：直接用 fitz 从 PDF 中提取文本，主要让模型学会认出各种语言的字。\n- **细标注**：中英文各 200 万页，用 PP-DocLayout 这类版面模型和 MinerU、GOT-OCR2.0 等 OCR 模型，生成「坐标＋类别＋文本」交错的标注。小语种则先用 fitz 生成小图来训练一个 GOT-OCR2.0，再用它来标注，做出 60 万条。\n\n另外还有 300 万份 Word 文档、中英文各 1,000 万条用 PaddleOCR 标注的场景文字，以及作者称为「OCR 2.0」的数据：1,000 万张图表（标注成 HTML 表格）、500 万条化学式（SMILES）、100 万条平面几何。\n\n整体配比是 OCR 数据 70%、通用视觉数据 20%、纯文本 10%。\n\n训练分两个阶段。先用一个小型语言模型、以预测下一个 token 为目标，单独训练 DeepEncoder；再冻结 SAM 与压缩器，和解码器一起训练整个模型。正式训练用了 20 个节点、每个节点 8 张 A100-40G，多模态数据每天约 700 亿 token。\n\n## 讨论\n\n### 压缩比实验：Fox 上的 100 页\n\n[![左图：Fox 基准上 64 与 100 个视觉 token 在不同文本长度下的精确度与压缩比；右图：OmniDocBench 上各模型的平均视觉 token 数与整体编辑距离的关系](/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png)](/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png)\n\n*原论文 Figure 1，取自 [**v1 PDF 第 1 页**](https://arxiv.org/pdf/2510.18234v1#page=1)，CC BY 4.0。(a) 柱子是精确度（左轴），虚线是压缩比（右轴）；(b) 横轴越往右视觉 token 越少，纵轴越往上编辑距离越低。*\n\n先看左图。横轴是每页标准答案的文本 token 数，紫色柱子是 64 个视觉 token（Tiny），蓝色是 100 个（Small），虚线是对应的压缩比。\n\n作者挑出 Fox 基准中所有文本 token 数在 600 到 1,300 之间的英文页面，正好 100 页，用「Free OCR」这个不要求版面的提示词测试。Table 2 的几行：\n\n| 文本 token | 64 个视觉 token | 100 个视觉 token | 页数 |\n| --- | --- | --- | ---: |\n| 600–700 | 96.5%（10.5×） | 98.5%（6.7×） | 7 |\n| 800–900 | 83.8%（13.2×） | 96.8%（8.5×） | 28 |\n| 1000–1100 | 79.3%（16.5×） | 91.5%（10.6×） | 11 |\n| 1200–1300 | 59.1%（19.7×） | 87.1%（12.6×） | 4 |\n\n*表：原论文 Table 2 节选。括号内为压缩比。*\n\n读这张表要注意两件事：\n\n1. **页数分布不均**。摘要里「20 倍压缩还有约 60%」，来自最后一行，只有 4 页；中间 700 到 900 这一段，每一档各有 28 页。\n2. **格式差异会拉低分数**。模型的输出格式和 Fox 的标准答案不完全一致，作者说实际表现应该比表上略高。\n\n对于压缩比超过 10 倍后的下滑，作者提出两个可能的原因：长文档的版面比较复杂，以及在 512×512、640×640 分辨率下，长文本已经变得模糊。后者他们认为可以看作一种「遗忘机制」。\n\n### 实际文档：OmniDocBench\n\n右图与 Table 3 换到了真实的文档解析基准 OmniDocBench。论文没有注明版本；表格按英文、中文分开计分，与 v1.5 之前的格式一致。各项指标都是编辑距离，越低越好。作者的重点是 token 效率：\n\n- **Small 模式**只用 100 个视觉 token，英文整体编辑距离 0.221，低于使用 256 个 token 的 GOT-OCR2.0（0.287）。\n- **Gundam 模式**平均 795 个 token，英文 0.127、中文 0.181，都比平均用 6,790 个 token 的 MinerU2.0（0.133、0.238）好。\n\nTable 4 按文档类型拆开，可以看出哪类文档需要多少 token。幻灯片在 Tiny 模式下编辑距离就只有 0.116；书籍与报告在 Small 模式下表现就不错。报纸则完全是另一回事：Tiny 是 0.94，到了 Gundam 才降到 0.122。作者的解释是，报纸一页有四五千个文本 token，远远超出其他模式约 10 倍的压缩范围。\n\n### 光学压缩与遗忘\n\n在讨论一节，作者提出了一个延伸设想：多轮对话里较早的内容，可以渲染成图像来压缩；越久远的对话，图像缩得越小，token 越少、字也越模糊，就像人的记忆逐渐淡去。\n\n作者自己也说，这是很初步的探索。结论写得很清楚：**单靠 OCR，不足以完整验证真正的上下文光学压缩**，之后还要做数字文本与图像文本交错的预训练、大海捞针测试等评估。\n\n### 发布后的讨论\n\n论文公开后引起了不少讨论。Andrej Karpathy 在 2025 年 10 月 20 日发帖说，这是个不错的 OCR 模型，但他更感兴趣的是：像素会不会是比文本更好的 LLM 输入？他列出的理由包括信息压缩、能保留粗体和颜色等格式，以及去掉 tokenizer。[Karpathy，2025-10-20](https://x.com/karpathy/status/1980397031542989305)\n\n另一个方向的回应，是去检查那些高分到底有多少来自图像。2026 年 1 月的〈Visual Merit or Linguistic Crutch?〉把 Fox 的段落换成随机字母，Tiny 模式从 88% 降到约 20%；在同一份数据上，逐行识别的 PaddleOCR-v5 只从 94% 降到 90%。\n\n回到前面那个映射：当一个视觉 token 平均要对应十几个文本 token，解码器的语言知识就得补上很多东西。内容是正常英文时，这份知识让压缩得以成立；内容没有规律时，它就补不回来了。\n\n\n> [!TIP]\n> \n> 想看语义扰动实验的完整设置，可以参考：\n> \n> - **[[26.01] Linguistic Crutch：脑补的代价](/blog/papers/model-evaluation/linguistic-crutch)**\n\n\n## 结论\n\nDeepSeek-OCR 把「一页文档需要多少视觉 token」变成了一个可以测量的问题，并给出了一个实用的答案：\n\n1. **DeepEncoder 的排法有效**。先局部、后压缩、再全局，让 1024×1024 的页面只产生 256 个视觉 token，显存也扛得住。\n2. **约 10 倍压缩下，英文页面大多能读回来**。在 Fox 上，10 倍以内约 97%；压缩比更高时开始下滑，20 倍左右的数字只有少数几页支撑。\n3. **作为 OCR 工具，它的 token 效率很高**。Small 模式就超过了 GOT-OCR2.0，Gundam 模式用不到八分之一的 token 超过了 MinerU2.0。作者还说，单张 A100-40G 一天可以生成 20 万页以上的训练数据。\n\n至于「用图像压缩 LLM 的长上下文」，论文只走了第一步。OCR 的分数证明解码器能把字还原，却没有回答还原出来的字有多少是从图像里来的。这个问题，三个月后就有人接着问了。\n","imageSizes":{"/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png":{"width":1288,"height":350},"/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png":{"width":1272,"height":558}}}