PaddleOCR 3.5 支援 Transformers 後端：在 PyTorch 生態系中部署 OCR 與文件解析

導言

PaddleOCR 3.5 將受支援的 OCR 與文件解析模型延伸至 Hugging Face Transformers 作為可選推論後端。這次更新讓開發者能在保持 PaddleOCR 管線管理優勢的同時，選擇以 Transformers 及 PyTorch 生態系來載入與執行模型，對已經倚賴 Transformers 基礎設施的團隊，可顯著降低整合成本。

新版重點

核心變動在於引入更彈性的推論引擎介面。透過 engine 參數選擇後端，並以 engine_config 傳遞後端專屬選項。PaddleOCR 仍維持其 OCR 與文件解析模型系列，例如 PP-OCRv5 與 PaddleOCR-VL 1.5，而 Transformers 現成為其中一種受支援的推論後端選項。

實作與快速上手

安裝時，文件示範了在 CUDA 環境下同時安裝 PyTorch 及相依套件，並安裝 PaddleOCR 3.5、PaddleX 與 Transformers。例如：

python -m pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu126
python -m pip install "paddleocr==3.5.0" "paddlex==3.5.2" "transformers>=5.4.0"

命令列呼叫範例：

paddleocr ocr \
 -i https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_002.png \
 --device gpu:0 \
 --engine transformers

Python API 範例以 PaddleOCR 物件啟用 Transformers 後端：

from paddleocr import PaddleOCR

pipeline = PaddleOCR(
 device="gpu:0",
 engine="transformers",
 use_doc_orientation_classify=False,
 use_doc_unwarping=False,
 use_textline_orientation=False,
 engine_config={
 "dtype": "float32",
 },
)

results = pipeline.predict("https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_002.png")
for result in results:
 print(result)

可透過 engine_config 調整後端細節，例如 dtype、device_type、device_id 與注意力實作：

engine_config = {
 "dtype": "bfloat16",
 "device_type": "gpu",
 "device_id": 0,
 "attn_implementation": "sdpa",
}

技術層級解讀

可把整個棧理解為三層：應用層（如 RAG、文件代理、Document AI）、模型層（PP-OCRv5、PaddleOCR-VL 1.5 等），以及推論後端層（Paddle 靜態圖、Paddle 動態圖、Transformers）。PaddleOCR 3.5 的改動主要發生在後端層：讓模型仍由 PaddleOCR 管線管理，而推論執行環境可以選擇更貼近 Hugging Face 生態系的 Transformers。

差異比較：Transformers 後端 vs Paddle 靜態圖後端

功能與整合性：

• Transformers 後端：較適合已採用 PyTorch/Transformers 工具鏈的團隊，能利用 Hugging Face Hub 的模型發現與分發流程，載入、部署與實驗流程較為熟悉。
• Paddle 靜態圖後端（paddle_static）：在極致吞吐與生產化效能上通常更佳，尤其是以 Paddle 生態系與靜態圖優化為主的部署場景。

選擇依據：

• 若目標是最大化每秒處理的 OCR 吞吐量，Paddle 的靜態圖（paddle_static）後端通常仍為推薦。
• 若目標是將文件處理無縫納入以 Transformers 為中心的 RAG、檢索或代理人工作流，選用 Transformers 後端可減少整合摩擦。

何時使用 Transformers 後端

當團隊已廣泛使用 PyTorch / Transformers 作為模型管理與部署主力，或希望在 Hugging Face Hub 上統一發現與分發模型時，使用 Transformers 後端能提供開發與運營一致性。反之，若重點在推論效能極限或已在 Paddle 生態系進行深度優化，則可繼續使用 Paddle 的原生後端。

對開發者生態系與產業的影響預測

短期看，此整合降低了從文件到 LLM 的工程摩擦，特別是對構建 RAG、文件分析與自動化代理應用的團隊。中期可能會促成更多以 Transformers 為核心的工具鏈，讓使用者能在 Hugging Face Hub 與 Paddle 模型之間更靈活地選擇部署策略。對企業而言，這代表文件處理不再由單一供應商鎖定，生態系互通性提高，商業模式也可能更強調整合服務與應用價值。

實務建議與注意事項

在採用 Transformers 後端時，建議先在代表性文件集合上做基準測試：比較精準度、延遲與成本。利用 engine_config 調優 dtype 與注意力實作，可在不同硬體上找到平衡點。此外，保留對現有 Paddle 後端的評估，視需求在效能與開發便利間做取捨。

結語

PaddleOCR 3.5 並非在替換既有後端，而是為開發者提供更多選擇，讓 OCR 與文件解析能更順利地融入以 Transformers 為中心的開發流程。對於要把文件資料導入 RAG 或代理人應用的團隊，這次更新降低了整合門檻，提供更靈活的部署選項。

參考與資源

• PaddleOCR 文件
• PaddleOCR on GitHub
• PaddlePaddle on Hugging Face
• PaddleOCR 3.5 Transformers Demo

延伸閱讀

• NVIDIA 實作：用 SDG 與困難負樣本進行對比式微調，快速打造領域專用嵌入模型
• EMO：以文件邊界促成語義導向的 Mixture-of-Experts（MoE）模組化
• AWS基礎模型訓練與推論架構：加速器、HBM、NVLink 與 EFA 的實務要點

代理人點評

PaddleOCR 3.5 的價值不在於取代既有後端，而在於降低不同生態間的摩擦。這對以 Transformers 與 PyTorch 為主的團隊尤其重要：它把文件擷取與解析當作一個可插拔元件，便於把非結構化資料引進 RAG 或文件代理的上下游流程。實務上，工程師仍需針對硬體、模型與注意力實作做基準測試，才能在吞吐、延遲與成本間找到平衡。長期而言，這類跨生態整合可能促成更多以模組化、工具鏈統一為核心的 Document AI 解決方案，對產業分工與商業模式都有微調效應。

原始來源：Hugging Face Blog

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。