一句話總結
百度開源的 Unlimited-OCR 用 30 億參數做到了傳統 OCR 工具做不到的事：一次性讀完 100 頁 PDF，記憶體不爆炸，速度不衰減。核心秘密是一個叫 R-SWA 的注意力機制——讓模型像人抄書一樣，只看原文和最近寫下的幾個字，而不是反覆回讀所有內容。
為什麼傳統 OCR 處理長文檔這麼痛苦？
如果你曾經用 Tesseract 或者 Adobe Acrobat 處理過超過 10 頁的掃描件 PDF，你一定經歷過這些：
- 逐頁處理：OCR 引擎一頁一頁識別，每頁重設狀態，跨頁表格被截斷
- 記憶體飆升：端到端 OCR 模型（如 DeepSeek-OCR）的 KV Cache 隨文字長度線性增長，40 頁文檔就能吃掉 24GB 顯存
- 格式丟失：多欄排版、跨頁表格、頁首頁尾在逐頁處理中徹底亂序
這不是工具不好用，而是架構層面的天花板。傳統 OCR 把每一頁當作獨立任務，缺乏「整本書」的全域視野。
Unlimited-OCR 的核心創新：R-SWA 注意力機制
像人抄書一樣工作
百度研究團隊從人類抄書的行為中獲得了靈感。想像你在抄一本書：
- 你的眼睛看著原文（視覺 token）
- 你剛寫下的最後幾個字還在視野內（滑動視窗內的歷史 token）
- 更早的內容你已經不需要重新閱讀了（被滑出視窗的 token）
這就是 Reference Sliding Window Attention（R-SWA，參考滑動視窗注意力） 的核心思想。
技術細節
傳統多頭注意力（MHA）中，每生成一個新 token，KV Cache 就增加一條記錄，記憶體隨輸出長度線性增長。R-SWA 做了兩件事：
- 視覺 token 凍結：圖像編碼一次後保持不變，不參與滑動視窗的狀態更新。這避免了標準滑動視窗注意力會逐漸模糊圖像特徵的問題。
- 輸出 token 滑動視窗：每個新生成的 token 只關注最近 128 個已生成的 token，更早的 token 被推出視窗。KV Cache 變成固定長度的佇列——新 token 入隊，最舊的 token 出隊。
結果：無論文檔是 5 頁還是 100 頁，解碼階段的 KV Cache 大小恆定不變。
與 DeepSeek-OCR 的關係
Unlimited-OCR 建構在 DeepSeek-OCR 的開源基礎之上：
- 保留 DeepEncoder 視覺編碼器（將 1024×1024 的 PDF 頁面壓縮為 256 個 token）
- 將解碼器替換為 MoE（混合專家）架構，總參數 30 億，推理時僅啟用約 5 億
- 所有標準注意力層替換為 R-SWA
性能實測：93% 準確率，32K 上下文視窗
基準測試成績
在 OmniDocBench v1.5/v1.6 標準 OCR 基準測試中：
| 模型 | 綜合得分 | 備註 |
|---|---|---|
| Unlimited-OCR | 93.92% | OmniDocBench v1.6 SOTA |
| DeepSeek-OCR | 87.70% | 基線模型 |
| GPT-4o | ~88% | 閉源參考 |
| Tesseract 5 | ~72% | 傳統 OCR 參考 |
相比 DeepSeek-OCR 提升 6.22 個百分點，在 40+ 頁長文檔上表現尤為穩定。
實際使用場景
- 單張圖片：使用 “Gundam” 模式（動態解析度），適合高精度單頁識別
- 多頁文檔/PDF：使用 “Base” 模式，一次性輸入整個文檔，無需拆分頁面
- 32K 上下文視窗：理論上可處理約 100 頁標準 PDF（每頁約 300 token）
兩種使用方式：線上體驗 vs 本地部署
方式一：Hugging Face Space 線上體驗（零配置）
最快的體驗方式是使用社群部署的 Hugging Face Space：
- 造訪 akhaliq/Unlimited-OCR
- 上傳圖片或 PDF 檔案
- 選擇快速裁剪模式或完整解析模式
- 等待處理，獲取 Markdown 格式輸出
適合快速驗證效果，但受限於共享 GPU 資源，長文檔可能需要排隊。
方式二：本地部署（完整控制）
硬體要求：
- GPU：NVIDIA GPU，至少 8GB VRAM（推薦 RTX 3090/4090）
- 記憶體：16GB+
- 磁碟：模型約 6GB
安裝步驟：
# 1. 複製儲存庫
git clone https://github.com/baidu/Unlimited-OCR.git
cd Unlimited-OCR
# 2. 建立虛擬環境
conda create -n unlimited-ocr python=3.10
conda activate unlimited-ocr
# 3. 安裝相依性
pip install -r requirements.txt
# 4. 下載模型（從百度網盤或 Hugging Face）
# Hugging Face：自動下載
# 5. 執行推理
python inference.py \\
--input your_document.pdf \\
--mode base \\
--output result.md使用 vLLM 加速推理（推薦生產環境）：
# 安裝 vLLM
pip install vllm
# 啟動服務
python -m vllm.entrypoints.openai.api_server \\
--model baidu/Unlimited-OCR \\
--max-model-len 32768Apple Silicon 使用者：MLX 版本
社群已經將 Unlimited-OCR 移植到 Apple MLX 框架（LoJexLLM/Unlimited-OCR-MLX），M1/M2/M3 Mac 使用者可以原生執行。
Unlimited-OCR vs 傳統 OCR 工具對比
| 維度 | Unlimited-OCR | Tesseract 5 | Adobe Acrobat OCR | PaddleOCR |
|---|---|---|---|---|
| 長文檔處理 | ✅ 一次性 100 頁 | ❌ 逐頁處理 | ❌ 逐頁處理 | ❌ 逐頁處理 |
| KV Cache | 恆定（R-SWA） | N/A | N/A | N/A |
| 表格識別 | ✅ 跨頁表格保持完整 | ⚠️ 簡單表格 | ✅ 較好 | ⚠️ 一般 |
| 公式識別 | ✅ LaTeX 輸出 | ❌ 不支援 | ⚠️ 有限 | ⚠️ 有限 |
| 模型大小 | ~6GB | ~30MB | 雲端 | ~100MB |
| 開源 | ✅ MIT | ✅ Apache 2.0 | ❌ 商業 | ✅ Apache 2.0 |
| 離線執行 | ✅ | ✅ | ❌ | ✅ |
| GPU 要求 | 8GB+ VRAM | CPU 即可 | 雲端 | 可選 GPU |
結論：Unlimited-OCR 不是要替代 Tesseract 這種輕量級工具，而是解決端到端長文檔 OCR 這個特定痛點。如果你的場景是掃描件 PDF 批次數位化、合約/財報全文提取、學術論文解析，Unlimited-OCR 是目前開源方案中的最優選擇。
社群生態與最新進展
- Hugging Face Space：akhaliq/Unlimited-OCR 可線上體驗
- Apple MLX 移植：LoJexLLM/Unlimited-OCR-MLX 支援 Mac 原生執行
- vLLM 整合：社群提供了完整的 vLLM 推理腳本（uv-scripts/ocr）
- GitHub 儲存庫：baidu/Unlimited-OCR，MIT 授權證，活躍社群
常見問題（FAQ）
Q1: Unlimited-OCR 需要多少顯存？
推理時約需 8GB VRAM。雖然模型總參數 30 億，但 MoE 架構在推理時僅啟用約 5 億參數，加上 R-SWA 保持 KV Cache 恆定，實際顯存佔用遠低於同參數量的 dense 模型。
Q2: 支援哪些語言的文檔識別？
Unlimited-OCR 主要訓練資料來自中英文文檔，對中文和英文的識別效果最佳。其他語言（日文、韓文等）也能識別但準確率可能略低。
Q3: 與 PaddleOCR 有什麼區別？應該選哪個？
PaddleOCR 是傳統 OCR 管線（偵測 + 識別），輕量、快速、適合單頁場景。Unlimited-OCR 是端到端模型，優勢在於長文檔一次性處理和複雜版面理解。如果你只需要識別單張發票或名片，PaddleOCR 更合適；如果要處理整本掃描書或長篇合約，Unlimited-OCR 更優。
Q4: 可以商用嗎？
可以。Unlimited-OCR 採用 MIT 授權證，允許商業使用、修改和分發，無需額外授權。
Q5: 處理 100 頁 PDF 需要多長時間？
取決於 GPU 性能。在 RTX 4090 上，100 頁標準 PDF（每頁約 300 token 輸出）大約需要 3-5 分鐘。瓶頸主要在視覺編碼階段，解碼階段因為 R-SWA 保持恆定速度，不會隨頁數增加而變慢。
Q6: 沒有 GPU 能用嗎？
理論上可以，但速度會非常慢。CPU 推理 30 億參數模型不實用。建議沒有 GPU 的使用者使用 Hugging Face Space 線上體驗，或者考慮使用 Apple MLX 版本在 M 系列晶片 Mac 上執行。
希望這篇部落格文章對您有所幫助！如果您正在尋找更多 AI 工具，不妨看看我們的 2026 年 AI 工具終極指南，涵蓋 50+ 款工具的深度評測。
