DeepSeek昨晚開源了一個OCR模型。

幾小時后，Andrej Karpathy在X上發(fā)了一條長推，說這篇論文"很有意思"，然后開始討論一個激進(jìn)的想法：

能不能讓所有LLM的輸入都變成images，包括純文本？

馬斯克也跟了一條：

長期來看，AI模型99%以上的輸入和輸出都會是photons。我讀完論文，發(fā)現(xiàn)他們討論的是同一件事。

DeepSeek-OCR表面上是個OCR模型，實(shí)際上在探索一個更大的問題：

1000個字的文檔，最少需要多少個vision tokens才能讓LLM理解？

論文給的答案是：100個。

壓縮比10倍，準(zhǔn)確率97%。

這不只是OCR的問題，而是在挑戰(zhàn)一個基本假設(shè)：一張圖真的值一千個字嗎？

今天就跟你聊聊這個。

一、論文在探索什么？

DeepSeek-OCR的論文一開始就問了一個很關(guān)鍵的問題：

"For a document containing 1000 words, how many vision tokens are at least needed for decoding?"

1000個字的文檔，最少需要多少vision tokens才能解碼？

這個問題看似簡單，但它在挑戰(zhàn)一個基本假設(shè)：一張圖真的值一千個字嗎？

傳統(tǒng)想法：

• 1000個字 = 1000個text tokens

• 一張包含這1000個字的圖片，也需要差不多1000個vision tokens

DeepSeek的實(shí)驗結(jié)果：

• 1000個字 ≈ 100個vision tokens

• 壓縮比10倍，準(zhǔn)確率97%

這就有意思了。

如果vision tokens真的這么高效，那為什么我們還要用text tokens？

能不能把所有文本都渲染成圖片，然后用vision tokens輸入LLM？

這就是Andrej Karpathy看完論文后，立刻想到的問題。

二、量化的答案：壓縮邊界在哪？

論文做了一個很系統(tǒng)的實(shí)驗，用Fox benchmark測試不同壓縮比下的準(zhǔn)確率。

結(jié)果很清楚：

文檔字?jǐn)?shù)

Vision Tokens

壓縮比

準(zhǔn)確率

600-700字

100 tokens

6.7×

98.5%

700-800字

100 tokens

7.5×

97.3%

900-1000字

100 tokens

9.7×

96.8%

1000-1100字

100 tokens

10.6×

91.5%

1200-1300字

100 tokens

12.6×

87.1%

看到趨勢了嗎？

10倍壓縮以內(nèi)，準(zhǔn)確率97%+，幾乎無損。

超過10倍，準(zhǔn)確率開始下降，但12倍壓縮還有87%。

如果用64個tokens（Tiny模式）：

• 1000字文檔，壓縮比15倍，準(zhǔn)確率85%

• 1200字文檔，壓縮比20倍，準(zhǔn)確率59%

核心發(fā)現(xiàn)：壓縮比和準(zhǔn)確率的關(guān)系不是線性的，而是有一個"甜蜜點(diǎn)"——10倍左右。

論文特別提到：實(shí)際準(zhǔn)確率比測試結(jié)果還要高，因為測試時格式對不上（formatting differences）。

這是首次有人系統(tǒng)地量化vision-text compression的邊界。

三、怎么做到的？DeepEncoder架構(gòu)

能做到10倍壓縮，靠的是一個叫DeepEncoder的新架構(gòu)。

現(xiàn)有的VLM encoder都有問題：

• Vary（雙塔）：需要兩次預(yù)處理，部署復(fù)雜

• InternVL2（tile-based）：圖片會被切成很多小塊，vision tokens太多（>15個/頁）

• Qwen2-VL（adaptive）：activation memory太大，大圖會爆顯存

DeepEncoder的設(shè)計很巧妙：

輸入1024×1024圖片
↓
SAM (80M, window attention) → 4096個patch tokens
↓
16× Conv Compressor → 壓縮到256個tokens
↓
CLIP (300M, global attention) → 輸出256個vision tokens

核心技巧：串聯(lián)window attention和global attention，中間用16×壓縮橋接。

為什么這樣設(shè)計？

• 前半部分（SAM）：用window attention處理海量tokens（4096個），但因為是局部attention，activation memory可控

• 中間壓縮：16倍降采樣，從4096→256

• 后半部分（CLIP）：用global attention處理少量tokens（256個），雖然密集但tokens少所以可控

結(jié)果：

• ? 支持高分辨率（1024×1024）

• ? Vision tokens少（256個）

• ? Activation memory低（不會爆顯存）

而且通過調(diào)整輸入分辨率，可以得到不同數(shù)量的vision tokens：

• 512×512 → 64 tokens

• 640×640 → 100 tokens

• 1024×1024 → 256 tokens

• 1280×1280 → 400 tokens

這讓他們能系統(tǒng)地測試：用N個vision tokens，能壓縮多少text tokens？

四、最激進(jìn)的idea：模擬人類遺忘

論文里有一張圖（Figure 13），我覺得是整篇論文最有想象力的部分。

他們畫了一個類比：

人類記憶的時間衰退：

• 剛發(fā)生 → Crystal Clear（水晶般清晰）

• 1小時 → Very Clear

• 1天 → Clear

• 1周 → Blurry（模糊）

• 1月 → Very Blurry

• 1年 → Almost Gone（幾乎消失）

視覺的空間衰退：

• 10cm → Crystal Clear

• 50cm → Very Clear

• 1m → Clear

• 3m → Blurry

• 10m → Very Blurry

• 20m → Almost Gone

DeepSeek-OCR的分辨率模式：

• Text token → Crystal Clear

• Gundam → Very Clear

• Large → Clear

• Base → Blurry

• Small → Very Blurry

• Tiny → Almost Gone

看到了嗎？三條曲線的衰退規(guī)律一模一樣。

論文提出的想法：

能不能用降低分辨率的方式，模擬人類的記憶遺忘？

具體怎么做？

假設(shè)你有一個AI agent，有100輪對話歷史：

• 最近5輪：保持text tokens（高清）

• 6-20輪：渲染成Large模式圖片（400 tokens/輪）

• 21-50輪：渲染成Base模式（256 tokens/輪）

• 51-100輪：渲染成Small模式（100 tokens/輪）

• 100輪以上：渲染成Tiny模式（64 tokens/輪）

效果：

• Context window從100,000 tokens壓縮到10,000 tokens（10倍）

• 舊對話越來越"模糊"，但關(guān)鍵信息還在

• 重要的舊對話可以"恢復(fù)"到高分辨率

這就是論文說的"memory forgetting mechanisms in LLMs"。

用物理的方式（降低分辨率）模擬生物的記憶（遺忘曲線）。

五、這給我們什么啟發(fā)？

理解了技術(shù)思路，再看應(yīng)用場景，你會發(fā)現(xiàn)這不只是"功能列表"。

它展示的是一個新思維：用壓縮比和準(zhǔn)確率的trade-off，匹配不同場景。

1. 高精度場景：Large/Base模式

學(xué)術(shù)論文、合同文檔、技術(shù)手冊——這些場景容錯率低，必須保證準(zhǔn)確。

用Large模式（400 tokens）或Base模式（256 tokens），壓縮比不高（5-7倍），但準(zhǔn)確率接近100%。

這時候，vision tokens不是為了省token，而是為了保留文檔的結(jié)構(gòu)化信息（標(biāo)題、列表、表格、圖表）。

傳統(tǒng)OCR只能給你純文本，但DeepSeek-OCR能輸出Markdown，保留語義結(jié)構(gòu)。

2. 效率優(yōu)先場景：Small/Tiny模式

快遞單掃描、票據(jù)識別、移動端OCR——這些場景對速度和成本敏感。

用Small模式（100 tokens）甚至Tiny模式（64 tokens），壓縮比10-20倍，準(zhǔn)確率85-95%。

雖然不是100%準(zhǔn)確，但對于"掃一眼快遞單看個大概"的場景，完全夠用。

而且，64個vision tokens意味著顯存占用極低，可以跑在移動設(shè)備上。

3. 超長文檔場景：Gundam模式

這個名字很中二，但思路很務(wù)實(shí)。

如果你有一個100頁的PDF，傳統(tǒng)做法是分頁處理，然后拼接結(jié)果。但這樣會丟失跨頁的上下文信息。

Gundam模式是動態(tài)分辨率：n×640×640 + 1×1024×1024。

根據(jù)文檔長度，自動調(diào)整vision tokens數(shù)量，既能處理超長文檔，又不會爆顯存。

4. 壓縮思維的本質(zhì)

看完這些場景，你會發(fā)現(xiàn)：

DeepSeek-OCR不是在做"更好的OCR"，而是在探索**"用多少視覺信息，能讓LLM理解到什么程度"**。

這就像壓縮算法——不是無損壓縮，而是有損壓縮。

關(guān)鍵是找到那個"甜蜜點(diǎn)"：壓縮到什么程度，信息損失還在可接受范圍內(nèi)？

對于文檔OCR，10倍壓縮是個甜蜜點(diǎn)（準(zhǔn)確率97%）。

對于不同場景，甜蜜點(diǎn)不一樣。所以DeepSeek-OCR提供了5種模式，讓你自己選。

六、DeepSeek真是開源之神

DeepSeek-OCR和他們之前的所有項目一樣，用的是MIT協(xié)議，完全開源。

開源，意味著這個技術(shù)思路可以被驗證、改進(jìn)、集成到更大的系統(tǒng)里。

如果你認(rèn)同Andrej Karpathy說的那個方向——未來LLM的輸入應(yīng)該都是images——那DeepSeek-OCR就是第一個可以拿來用的工具。

你可以：

• 用它做實(shí)驗，驗證vision tokens是不是真的比text tokens更高效

• 基于它改進(jìn)encoder，探索更好的壓縮算法

• 把它集成到自己的多模態(tài)系統(tǒng)里，測試真實(shí)場景的效果

這比閉源的API強(qiáng)太多了。

API只能告訴你"輸入圖片，輸出文字"，但底層怎么做的、為什么這么做、能不能改進(jìn)——你都不知道。

開源才能推動這個領(lǐng)域往前走。

而且，DeepSeek一直在這么做。去年的DeepSeek-Coder、今年的DeepSeek-V3，都是完全開源的。

這次的DeepSeek-OCR也一樣。

這對整個AI社區(qū)來說，是真正的貢獻(xiàn)。

七、回到最初的問題

文章開頭，我們提到Andrej Karpathy的那個激進(jìn)想法：

"能不能讓所有LLM的輸入都變成images？"

和馬斯克的觀點(diǎn)：

"長期來看，AI模型99%以上的輸入和輸出都會是photons。"

現(xiàn)在，讀完DeepSeek-OCR的技術(shù)細(xì)節(jié)，你應(yīng)該明白了：

這不是科幻，而是正在發(fā)生的技術(shù)路徑。

DeepSeek-OCR證明了：

• 1000個字的文檔，可以壓縮到100個vision tokens（10倍壓縮，97%準(zhǔn)確率）

• 通過降低分辨率，可以模擬人類的記憶遺忘

• Vision tokens比text tokens更適合做上下文壓縮

如果這個方向成立，那未來的LLM可能長這樣：

• 輸入層：全是vision encoder，文本也渲染成圖片

• 壓縮層：根據(jù)重要性動態(tài)調(diào)整分辨率

• 理解層：LLM在"模糊"和"清晰"之間做trade-off

一張圖到底值多少個字？

DeepSeek-OCR的答案是：取決于你需要什么精度。

10倍壓縮夠了，就用100個tokens。想要更清晰，就用400個tokens。想要省資源，64個tokens也能用。

這就是"上下文光學(xué)壓縮"的本質(zhì)。

DeepSeek-OCR剛發(fā)布，還有很多問題需要驗證：中文支持、復(fù)雜布局、長文檔處理...

但我覺得，它的思路值得關(guān)注。

不是做"更好的OCR"，而是探索"LLM需要什么樣的視覺信息"。

如果你對這個方向感興趣，可以去GitHub看看代碼：

https://github.com/deepseek-ai/DeepSeek-OCR

MIT協(xié)議，開源免費(fèi)，拿去用就是了。

實(shí)際效果展示

這是DeepSeek-OCR官方提供的幾個實(shí)際案例：

從這些示例可以看出，DeepSeek-OCR能處理多種類型的文檔：復(fù)雜布局、圖文混排、表格、手寫文字等。

參考資料：

• DeepSeek-OCR GitHub: https://github.com/deepseek-ai/DeepSeek-OCR

• Hacker News討論: https://news.ycombinator.com/item?id=45640594

• GOT-OCR2.0論文: https://arxiv.org/abs/2409.01704

• Vary項目: https://varybase.github.io/