百度開源無限OCR，跑通長程解析，核心作者YY疑是來自DeepSeek

DeepSeek OCR 留下的一個問題，好像被人接上了。

昨天，我們在 HuggingFace 上刷到一個新開源模型，直接被驚艷到了。

它叫 Unlimited OCR，百度出的。

最吸引眼球的地方是，在標準最大上下文長度 32K 的條件下，它讓 OCR 模型第一次能夠一口氣讀完整本書。

注意，這不是逐頁處理，不是 for-loop 式拆任務，也不是靠外部調度器把結果拼起來，而是真正意義上的一次前向推理直接完成數十頁文檔解析。

更絕的是，它不僅做到了，還做得相當好。在文檔解析主流基準 OmniDocBench v1.5 上，Unlimited OCR 以 93.23% 的總分拿下端到端 SOTA，比 DeepSeek OCR 整整高出 6 個百分點。

看到這里，我們不免好奇：它到底是怎麼做到的？於是翻開技術報告，結果越看越有意思。

因為 Unlimited OCR 並不是另起爐灶。恰恰相反，它直接構建在 DeepSeek OCR 的基礎之上。

原因很簡單：在視覺壓縮這件事上，DeepSeek OCR 已經把事情做到相當極致。一張 1024×1024 的文檔頁面，經過 DeepEncoder 編碼之后，最終只剩下 256 個視覺 token。即使放到今天看，這依然是一個相當激進的設計。

但之后，一個問題慢慢浮現 —— 如果輸入側已經壓縮得這麼狠，為什麼此前的 OCR 模型還是很難真正處理長文檔？

答案在解碼端。視覺 token 壓縮之后，模型生成的文本卻不會憑空消失。隨着輸出越來越長，解碼器里的 KV Cache 仍然會不斷增長。輸出越長，顯存佔用越高；歷史越長，注意力計算越重；生成速度也會越來越慢。

這也是為什麼過去的大多數 OCR 系統，最終都會退回到逐頁解析的模式。因為再高效的編碼器，也解決不了解碼階段不斷膨脹的歷史負擔。

而 Unlimited OCR 的切入點，恰好落在這里。它沒有重做編碼器，而是把全部精力放在瞭解碼階段。項目界面上有一句很耐人尋味的話：「push DeepSeek-OCR one step further」。

看到這里的時候，我們專門回去翻了一遍 DeepSeek OCR，然后發現兩者關注的，似乎正好是同一條技術路線上的兩個不同環節。

DeepSeek OCR 解決的是輸入側的問題 —— 如何把高分辨率文檔壓縮成儘可能少的視覺 token。Unlimited OCR 解決的是輸出側的問題 —— 如何讓模型在長時間生成過程中，不被不斷膨脹的 KV Cache 拖垮。

一個發生在編碼端，一個發生在解碼端。單獨看，兩者各自成立，放在一起看，卻意外地連貫。

更有意思的是，Unlimited OCR 技術報告對 DeepSeek OCR 的討論頻率相當高，整整高達 40 次。很多地方讀起來完全不像是在做通常意義上的競品對標，反而更像是在接着思路，繼續往前推。

至於為什麼會給人這種感覺，我們有一個大膽的猜測。

• 報告標題：Unlimited OCR Works
• 報告鏈接：https://huggingface.co/baidu/Unlimited-OCR/blob/main/Unlimited-OCR.pdf
• 項目地址：https://github.com/baidu/Unlimited-OCR
• Hugging Face：https://huggingface.co/baidu/Unlimited-OCR

像人類一樣抄書：Unlimited OCR 解決大模型的長程失憶症

要理解 Unlimited OCR 的意義，需要先回到傳統 OCR 模型處理長文檔的方式。

過去的 OCR 系統處理長文檔，通常採用逐頁解析的方式。模型識別第一頁，結束；然后識別第二頁，再結束；整個流程依賴外部程序一頁一頁調用模型。從模型能力本身看，它並沒有真正連續地完成一次長程任務。每一頁都像一次重新開始，上一頁的解析狀態被清空，模型並不真正知道自己正在完成一本書級別的連續轉寫。

這種 For-loop 範式，本質上依賴外部調度器（External Scheduler）來拼接結果。這相當於把一本完整的書拆成獨立碎片，不僅割裂了語義連貫性，更是一種工程上的權宜之計（Engineering Workaround），而非邁向 AGI 的路徑。

人類處理長程任務的方式，顯然更接近另一種模式。

例如，一個人手抄一本書時，注意力並不會平均分配給整本書。你不會一邊寫當前這個字，一邊完整回憶前面已經抄過的幾百頁內容。真實情況通常是：眼睛盯着原始書頁，腦子里記住剛剛寫下的一小段文字，然后把注意力放到下一個要寫的字上。

受人類抄書過程的啓發，百度提出了 Unlimited OCR。當一個人手抄一本書時，注意力通常集中在三個地方：原始書頁、剛剛寫下的一小段內容（通常只有幾個字），以及接下來要寫的那個字。

人類之所以能夠連續抄完整本書、翻譯數百頁內容，或者轉錄數小時音頻，並不是因為大腦完整保存了所有歷史輸出。相反，人並不會完整記住所有已經轉寫過的內容，而是會進行一種軟遺忘（Soft Forgetting）。

正是受這一觀察啓發，百度提出了 Unlimited OCR。

Unlimited OCR 以 DeepSeek OCR 作為基線模型。它由 DeepEncoder 和混合專家架構（Mixture-of-Experts，MoE）組成，模型總參數量為 3B，其中激活參數為 500M，這是其保持高效率的底牌之一。

DeepEncoder 的突出優勢在於出色的視覺 token 壓縮能力。它能夠在保留穩定光學文本特徵提取能力的同時，大幅降低 prefill 階段的 KV cache 佔用。

除了 DeepSeek OCR 編碼器，百度的創新是將標準多頭注意力機制（MHA）替換為 R-SWA（Reference Sliding Window Attention）。藉助這一新的注意力機制，只需要在原有參考 KV cache 𝑚 的基礎上，增加一個寬度為 𝑛 的固定容量輸出 KV 緩衝區，就可以實現長程解析。

R-SWA 如何穩住長程解碼？

儘管 DeepEncoder 在輸入側已經實現了令人滿意的視覺 token 壓縮，但一次性解析整本書的真正瓶頸在於解碼階段。

假設視覺 token 與文本 token 之間的壓縮比為 1:10，也就是説，一個視覺 token 大約可以解碼出 10 個文本 token。那麼，1 萬個視覺 token，也就是約等於 1024×1024 分辨率下的 20 到 30 頁文檔，在完整解碼時就需要輸出超過 10 萬個 token。

對普通 LLM 驅動的 OCR 模型來説，這會帶來兩個問題：

第一，KV cache 會不斷增長。每生成一個 token，模型都要把它的 Key 和 Value 存下來，供后面 token 使用。

第二，注意力計算會越來越重。越到后面，模型要回看的歷史越長，生成速度也就越慢。

為此，百度提出了參考滑動窗口注意力機制 R-SWA（Reference Sliding Window Attention），它把模型能看到的信息分成兩部分。

第一部分是 Reference tokens，也就是參考信息。在 OCR 里，它主要包括視覺 token 和 prompt。可以把它理解成模型一直放在眼前的原始文檔。

第二部分是最近生成的一小段輸出 token，默認窗口大小是 128，也就是説，模型只保留最近 128 個輸出 token 作為工作記憶。這恰好模擬了人類「只記得最近剛寫下的幾個字」的認知狀態。

R-SWA 示意圖。每個生成 token 都會關注所有參考 token，也就是 OCR 中的視覺 token，以及前面 𝑛 個輸出 token，其中 𝑛 默認設為 128。與標準全注意力相比，R-SWA 在整個解碼過程中都能保持恆定的 KV cache。與普通滑動窗口注意力（vanilla SWA）相比，R-SWA 將視覺 token 排除在狀態轉移之外，從而保留視覺 token 的保真度，避免視覺特徵在長程過程中逐漸模糊。

因此，R-SWA 的核心邏輯可以概括為：原始文檔始終可見，已經輸出過的文本只保留最近一段。

這和人抄書很像，人抄書時，不會一邊寫當前這個字，一邊回憶前面幾百頁全部內容。真正有用的是：原書還在眼前，剛剛寫過的幾個字還在腦子里，然后繼續寫下一個字。

這樣一來模型不再需要隨着輸出變長而不斷揹負越來越大的歷史緩存，解碼階段的計算開銷和顯存佔用也就不會一路膨脹。下圖直觀展示了這一點： DeepSeek OCR 基線模型和 Unlimited OCR Works（圖中記為 UOW）在 Flash Attention v3 內核上的單次調用耗時。

圖中可以清楚看到，DeepSeek OCR 中的標準 MHA 內核會隨着解碼步數增加而產生越來越高的延迟；而在 Unlimited OCR 中，單次調用耗時基本保持恆定。這正是因為 Unlimited OCR 在 LLM 解碼器的所有層中都採用了 R-SWA。

DeepSeek OCR 中出現的延迟尖峰，是因為 KV cache 長度跨過了某個對齊邊界，導致數據傳輸效率突然下降；而採用 R-SWA 后，這個問題也不會出現。

此外，推理過程中的 GPU 顯存使用也會呈現類似趨勢：在原始 DeepSeek OCR 中，顯存佔用會線性增長；而在 Unlimited OCR 中，顯存佔用保持固定。

計算成本和內存佔用的雙重穩定，正是長程解析得以實現的關鍵。

Flash Attention v3 內核延迟隨解碼長度增加而變化的情況。

準確率沒掉，長輸出更穩，R-SWA 的長程解析跑通了

當然，注意力機制設計得再巧妙，最終還要實驗來驗證。除了主結果（前文 table 1），論文還在 OmniDocBench v1.5 的 9 類文檔上做了細分類別分析，包括 PPT、學術論文、書籍、彩色教材、試卷、雜誌、報紙、筆記、研究報告等。

細分類別分析：複雜版式下也沒有掉隊

如表 2 所示，與 DeepSeek OCR 相比，Unlimited OCR 在所有指標上都取得了明顯且一致的提升。與 DeepSeek OCR 2 相比，Unlimited OCR 也保持了明顯優勢。

更關鍵的是，在 PPT、報紙、雜誌、筆記這類複雜版式文檔上，Unlimited OCR 也沒有表現出劣勢。這説明 R-SWA 的效果不是隻適用於簡單純文本，而是可以覆蓋更復雜的文檔解析場景。

長程解析實驗：一次性處理多頁文檔

長程解析是 Unlimited OCR 的一項新能力。

此前的模型難以實現這一點，主要有兩個障礙：第一，過長的輸出序列很容易超過最大 token 限制；第二，輸出延迟會隨着序列長度增加而上升，導致幾十頁文檔的 OCR 解析越往后越慢。

實驗中，百度構建了內部長文檔測試集，按頁數分為 2、5、10、15、20、40+ 頁幾組，測試模型在多頁一次性 OCR 場景下的表現。

結果顯示，Unlimited OCR 在同時輸入 20 頁時仍能保持較好效果；在 40+ 頁場景下，編輯距離仍低於 0.11，Distinct-35 約為 97%（Distinct-n 可以理解為生成文本中 n-gram 的多樣性指標，數值越高，説明模型越不容易陷入重複輸出）。

輸出越長，R-SWA 優勢越明顯

最后，論文比較了 Unlimited OCR 和 DeepSeek OCR 在不同輸出長度下的 TPS，也就是每秒輸出 token 數。

結果顯示，當輸出長度為 256 個 token 時，兩個模型的推理速度幾乎相同。但隨着輸出長度增加，DeepSeek OCR 的 TPS 會持續下降；當輸出長度達到 6000 個 token 時，DeepSeek OCR 的速度已經比採用 R-SWA 的 Unlimited OCR 落后 35%。

這和前面 Figure 3 的 kernel latency 結果是一致的：標準 MHA 會隨着 KV cache 變長而越來越慢；R-SWA 將輸出側 KV cache 限制在固定窗口內，因此解碼開銷不會隨着輸出長度持續膨脹。

一個大膽的猜測：百度把 DeepSeek 的研究員挖過來了？

咦？讀完 Unlimited OCR 的技術報告，怎麼有一種似曾相識的感覺。沒錯，它的技術風格、表達方式，都讓人想起 DeepSeek OCR 的技術報告。

技術上自不必説，Unlimited OCR 直接構建在 DeepSeek OCR 的基礎之上，對 DeepEncoder 等核心組件進行了進一步融合。同時，二者之間的這種近乎無縫的銜接，也讓我們感覺，這不像是一次對開源項目的簡單學習，而更像是在完整理解的基礎上，繼續向前推進，讓該技術順理成章地走入下一個階段。

而在行文風格上，Unlimited OCR 報告給人一種故事性極強、想法頗為激進，同時又帶有強烈探索色彩的感覺。而這種感覺，之前讀 DeepSeek 技術報告的時候我們也曾領略過。

這就不得不讓人大膽猜想：難道百度把 DeepSeek 的研究員挖過來了？

這也不是不可能。因為前段時間，的確有不少研究員從 DeepSeek 離職，比如 DeepSeek V4 技術報告里被「*」標出來的那些人，有些去向已知，如郭達雅去了字節跳動 Seed 團隊、王炳宣去了騰訊混元 (Hunyuan) 團隊。

但是還有一些人至今去向不明，如 OCR 系列模型作者魏浩然至今未公開披露去向。等等，百度不會把魏浩然挖來了吧？這也不是沒可能，畢竟他在 DeepSeek 期間，是 OCR 系列模型的核心作者。

此外，在 HuggingFace 主頁，我們還注意到致謝一欄寫着：感謝 Deepseek-OCR、Deepseek-OCR-2。

雖然，Unlimited OCR 技術報告沒有明確説明，但有一個署名「YY」的神祕作者。ta 是這份工作的「technical director」，通常來講，這個角色要負責技術路線的整體把關，如果 ta 確實來自 DeepSeek，那麼 Unlimited OCR 與 DeepSeek OCR 之間那種無縫銜接感便不再令人意外；同時，Unlimited OCR 技術報告的措辭也更像是在對自身先前研究進行反思與改進，而非一般意義上的競品對標。

若這一推測屬實，這也算是一場雙向奔赴 —— 畢竟，百度的 PaddleOCR 長期穩居行業榜首，對相關領域的人才本就有着獨特的吸引力。而如今，百度極有可能正在開闢新的技術路線，新鮮血液的注入也加速了成果的涌現。

當然，這一切都只是猜測。如果有了解這份工作背后故事的朋友，歡迎在評論區留言分享。

本文來自微信公眾號 「機器之心」（ID：almosthuman2014），編輯：張倩、陳陳 ，36氪經授權發佈。