{"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-hant","path":"/content/papers/zh-hant/deepseek/deepseek-ocr.d61cee3b4441.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-hant","path":"/content/papers/zh-hant/model-evaluation/linguistic-crutch.eaf147d2fdb2.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}}}