核心概念
PaddleOCR 3.5 在 2026 年 5 月 18 日發布，核心改變是將 Hugging Face Transformers 正式引入為第三個推理後端，與原有的 paddle_static（靜態圖）和 paddle_dynamic（動態圖）並列。這不是替換，而是增加一條對 PyTorch／Transformers 生態友好的路徑。
三層推理架構
PaddleOCR 3.5 採用清晰的三層分離設計：
| 層級 | 說明 | 範例 |
|---|---|---|
| 應用層 | 使用 OCR 輸出的下游應用 | RAG、Document AI、搜尋 Agent |
| 模型層 | OCR 與文件解析能力 | PP-OCRv5、PaddleOCR-VL 1.5 |
| 推理後端層 | 執行期環境 | paddle_static、paddle_dynamic、transformers（新增） |
這種分層讓開發者可以在不改變業務邏輯的前提下切換推理後端，最大化既有基礎設施的複用。
Transformers 後端的啟用方式
只需在 PaddleOCR() 建構時指定 engine="transformers"，並透過 engine_config 傳入後端設定：
from paddleocr import PaddleOCR
pipeline = PaddleOCR(
device="gpu:0",
engine="transformers",
engine_config={
"dtype": "bfloat16",
"device_type": "gpu",
"device_id": 0,
"attn_implementation": "sdpa",
}
)
results = pipeline.predict("path/to/document.png")
命令列同樣支援 --engine transformers 旗標，無需修改現有腳本架構。
支援的模型
Transformers 後端支援 20+ 個主要模型，核心是：
- PP-OCRv5：多語言文字辨識（支援 109 種語言）
- PaddleOCR-VL 1.5（0.9B 參數）：Vision-Language Model，專為文件解析設計，能處理表格、公式、圖表、印章等複雜元素
PaddleOCR-VL 1.5 的特色在於輕量：以 NaViT 風格的動態解析度視覺編碼器搭配 ERNIE-4.5-0.3B 語言模型，在極低參數量下達到多語言複雜版面解析能力。
關鍵要點
- 後端選擇原則：Transformers 後端適合開發體驗優先的場景（RAG、Agent、原型開發）；最大化吞吐量時仍建議用
paddle_static - 安裝前置條件：需安裝
torch（CUDA 版）、paddleocr==3.5.0、paddlex==3.5.2、transformers>=5.4.0，四者缺一不可 - HuggingFace Hub 整合：Transformers 後端讓模型管理走 HF Hub 標準流程，可直接享受版本管理、模型卡、Inference Endpoints 等生態工具
- dtypes 靈活性：支援
float32和bfloat16，後者在現代 GPU（Ampere+）上可顯著降低記憶體用量 - 注意力機制：
attn_implementation可設為sdpa（PyTorch Scaled Dot-Product Attention）或 Flash Attention 2，影響推理速度
實務應用
RAG 文件前處理
文件進入向量資料庫前，通常需要將 PDF／掃描圖轉換為結構化文字。PaddleOCR 3.5 的 Transformers 後端讓這條管線可以完全在 PyTorch 生態中閉環：
PDF / 掃描圖
→ PaddleOCR (engine=transformers)
→ 結構化文字 + 版面資訊
→ Embedding Model (HF Inference Endpoints)
→ Vector DB
原先需要維護兩套框架（Paddle + Transformers）的痛點消除，DevOps 複雜度下降。
複雜文件解析場景
PaddleOCR-VL 1.5 直接處理含表格、數學公式、折線圖的研究報告或財務文件，輸出格式可指定為 Markdown（適合 LLM 輸入）或 HTML（保留表格結構）。對於需要從非結構化文件中提取 key-value 對的 Document AI 場景，這個模型的 0.9B 參數量使其能部署在邊緣設備或成本受限的雲端實例。
與 HF Inference Endpoints 搭配
Transformers 後端開啟後，可直接在 Hugging Face 模型頁面點擊「Deploy」，幾秒完成 GPU 自動擴展的端點建立，無需自行管理 CUDA 環境。
延伸觀點
來自 Hugging Face 的兩篇相關報告（OCR Open Models 調查 及 Accelerating Document AI）提供了更宏觀的視角：
OCR 生態的典範轉移已完成：傳統管線（OCR → 文字 → NLP 模型）正被端到端 Vision-Language Model 取代。兩篇文章都一致指出，直接將文件圖片輸入 VLM（Qwen3-VL、PaliGemma 等）的精度通常高於先 OCR 再接 LLM 的方案，因為 VLM 能保留版面上下文。PaddleOCR 3.5 選擇同時提供 PP-OCRv5（傳統 OCR）和 PaddleOCR-VL（端到端 VLM）反映了這個過渡期的現實。
輕量模型佔有獨特生態位：OCR open models 調查顯示，多語言場景下 PaddleOCR-VL（0.9B）以極低參數量支援 109 種語言，在 Edge 部署和成本敏感場景中有明確優勢。相比之下，OlmOCR-2（8B）僅支援英文，Chandra（9B）雖精度更高但資源消耗顯著。選型時語言需求是第一決策維度。
Transformers 整合是生態票：Document AI 加速報告指出，幾乎所有主流 OCR 模型都已提供 Transformers 實作（TrOCR、Donut、Pix2Struct 等）。PaddleOCR 3.5 的這步整合，本質上是補齊了它在 HuggingFace 生態中的「標準入場券」，而非技術突破。對企業而言，統一 Transformers 後端意味著工程師不再需要學習 Paddle 框架即可使用 PaddleOCR 的高品質模型。
相關頁面：Hugging Face 推論供應商生態系：DeepInfra 整合實錄、AWS 基礎模型訓練與推論四層架構
反向連結
以下頁面引用了本頁：