ERNIE 4.5 與 ERNIEKit：Apache-2.0 授權下的 MoE 多模態模型家族與訓練工具箱
The official repository for ERNIE 4.5 and ERNIEKit – its industrial-grade development toolkit based on PaddlePaddle.
秒懂
- 它是什麼？
- 百度以 Apache-2.0 開源了 ERNIE 4.5 系列共 10 個模型變體，並附上基於 PaddlePaddle 的開發工具箱 ERNIEKit。本文整理倉庫中可確認的模型規格、訓練流程與硬體限制，並指出它在什麼情況下不是合適的選擇。
- 適合誰用？
- 已經在 PaddlePaddle 上跑訓練、或需要對 128K 上下文的 VL 模型做 SFT 與 function call 微調的團隊，這個倉庫值得先讀 docs/erniekit.md 再決定。若你的推論堆疊是 vLLM 或 TensorRT-LLM，或你只想下載權重而不打算碰訓練，那 ERNIEKit 的多數功能對你沒有用處，直接取 Hugging Face 上的權重即可。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 53 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
ERNIE 4.5 想解決的是多模態與文字任務互相拖累的問題
多模態模型常見的取捨是：為了看懂圖片與影片而加進去的參數，往往讓純文字任務的表現變差。ERNIE 4.5 的模型家族用 Mixture-of-Experts 架構來處理這件事。README 的說法是，這個家族包含 10 個不同變體，MoE 部分有 47B 與 3B 兩種激活參數規模，最大的模型總參數達 424B，另外還有一個 0.3B 的 dense 模型。
關鍵設計在 README 稱為 heterogeneous modality structure 的異質模態結構：跨模態之間共享部分參數，同時讓每個模態保有自己的專屬參數。專案聲稱這樣的結構能在不犧牲文字任務表現的前提下提升多模態理解，甚至讓文字任務表現變好。這是專案自己的說法，我沒有驗證。
適合誰？如果你的場景同時要處理文字與圖像或影片，又不希望因此換掉現有的文字模型，這個家族的分層設計值得研究。若你只需要純文字模型，21B-A3B 與 300B-A47B 這兩個文字版本就是對應的入口，不需要碰 VL 分支。
README 列出所有模型皆以 Apache-2.0 公開，這對要商用或要放進產品的團隊是實質差異，不是宣傳詞。
模型清單與 128K 上下文的實際分佈
README 的表格把 10 個變體分成三類。語言模型有四個：ERNIE-4.5-300B-A47B-Base、ERNIE-4.5-300B-A47B、ERNIE-4.5-21B-A3B-Base、ERNIE-4.5-21B-A3B，輸入輸出都是純文字。視覺語言模型也有四個：ERNIE-4.5-VL-424B-A47B-Base、ERNIE-4.5-VL-424B-A47B、ERNIE-4.5-VL-28B-A3B-Base、ERNIE-4.5-VL-28B-A3B，輸入接受文字、圖像與影片，輸出只有文字。dense 模型兩個：ERNIE-4.5-0.3B-Base 與另一個同系列變體。
表格中所有列的 context window 都標示 128K。這個數字是模型規格層級的宣稱，但 128K 的實際可用性取決於部署框架的記憶體管理，README 沒有在這裡給出推論階段的記憶體數據。
命名規則值得記住：A47B 與 A3B 指的是激活參數，不是總參數。ERNIE-4.5-21B-A3B 的總參數量與激活量差距很大，這正是 MoE 的意義所在，但也意味著你不能用激活參數去估算顯存需求。424B 這個數字是總參數，部署時的權重儲存與載入成本要按它算。
VL 系列的 Base 與非 Base 成對出現，前者是預訓練基礎版本，後者通常對齊過。ERNIEKit 的更新紀錄顯示，非 Base 的 Thinking 版本才是 SFT 與 function call 訓練的目標，例如 ERNIE-4.5-21B-A3B-Thinking 在 v1.3 加入支援，ERNIE-4.5-VL-28B-A3B-Thinking 在 v1.5 加入。
ERNIEKit 的版本線與它逐步補上的訓練能力
從更新紀錄可以看出 ERNIEKit 的覆蓋範圍是分階段長出來的，這對評估採用時機很重要。v1.0 在 2025-06 與模型同時發布，定位是開發工具箱。v1.1 補上 ERNIE-4.5-VL 系列的 SFT 與 LoRA。v1.2 加入 WebUI 的訓練與對話功能，支援 28b 與 424b 的 VL 模型，VL 訓練資料支援 query-response 格式，命令列工具補上 iluvatar GPU 支援，同時修掉 AutoParallel 的 pp+recompute+moe 與 checkpoint 儲存問題，以及 VL 的 lora 128k 訓練問題。v1.3 加入 ERNIE-4.5-21B-A3B-Thinking 的 SFT 與 function call 訓練。v1.4 加入 PaddleOCR-VL-0.9B 的 SFT，並在 Dataflow 支援 padding-free 策略。v1.5 加入 ERNIE-4.5-VL-28B-A3B-Thinking 的 SFT 與 function call 訓練。
這條時間線透露兩件事。第一，function call 訓練是後來才成為一等公民的功能，早期版本沒有。第二，修補清單集中在 AutoParallel 與 VL 訓練，說明這兩個路徑在早期版本並不穩定。
padding-free 策略的說明值得單獨看：把一個 batch 內的資料打包成單一序列以避免 padding，藉此降低 GPU 記憶體用量並加速訓練。這是長上下文訓練的常見手法，但打包會改變樣本邊界，若你的任務對序列邊界敏感，需要自己確認資料處理是否正確。
安裝與啟動：從 docs/erniekit.md 開始
README 沒有把安裝指令直接寫在首頁，而是把訓練相關內容指向 docs/erniekit.md，部署則指向獨立的 PaddlePaddle/FastDeploy 倉庫。這個分工本身就是一個訊號：這個倉庫管訓練與微調，推論部署是另一個專案的事。
因此取得路徑是：先讀 docs/erniekit.md 取得訓練環境的安裝與啟動方式，再依需要的模型變體選擇對應的訓練文件。VL 相關的訓練在 docs 底下有獨立文件，例如 PaddleOCR-VL-0.9B 的 SFT 有專門的 docs/paddleocr_vl_sft.md。
模型權重不在這個倉庫裡。README 把權重導向 Hugging Face 的 baidu 組織頁面，以及 AI Studio 的模型總覽頁。這表示你的流程會橫跨兩個來源：程式碼從 GitHub 拿，權重從 Hugging Face 拿。
倉庫的預設分支是 release/v1.5，與最新的 ERNIEKit v1.5 對應。若你要重現某個特定版本的行為，記得切到對應的 release 分支，而不是用預設分支的 HEAD。
我沒有實際安裝或執行過這個專案，以上是根據倉庫結構與 README 的指向所做的整理。具體的依賴版本、CUDA 對應關係與安裝指令，必須以 docs/erniekit.md 的內容為準，我無法從現有材料確認。
綁定 PaddlePaddle 是這個專案最大的結構性限制
README 明確說所有模型都以 PaddlePaddle 框架訓練，該框架同時提供高效能推論與簡化的部署流程。這句話的另一面是：ERNIEKit 是 PaddlePaddle 生態內的工具，不是框架中立的。
如果你的團隊已經在用 PyTorch 生態的訓練堆疊，採用 ERNIEKit 意味著要嘛維護兩套框架，要嘛整體遷移。這不是一個可以輕鬆繞過的細節，因為訓練工具鏈的價值在於整合，拆開用就失去了大部分意義。
第二個限制是硬體支援的廣度。README 把 multi-hardware compatibility 列為工具箱的特點之一，但更新紀錄顯示 iluvatar GPU 的支援是 v1.2 才加入的。這說明硬體覆蓋是逐步擴充的過程，不是一開始就完備。在投入之前，你應該先確認自己手上的加速卡是否在當前版本的支援範圍內。
第三個限制是模型規模與資源的落差。424B 總參數的 VL 模型不是單機可訓練的對象，即使 ERNIEKit 提供了 AutoParallel 相關功能，平行策略的調校成本仍然存在。更新紀錄中反覆出現的 AutoParallel 修補，側面說明這條路徑的複雜度。
最後，README 提到在最大的語言模型預訓練中達到 47% MFU。這是專案在自家訓練環境下的數字，不構成你本地環境的預期值。把它當成一個上限參考，而不是基準。
與直接使用 Hugging Face 生態工具的差異
最直接的替代方案是不碰 ERNIEKit，直接用 Hugging Face 生態的訓練工具對 ERNIE 權重做微調。權重確實放在 Hugging Face 的 baidu 組織底下，這條路在取得模型這一步是通的。
差別在於工具針對性。ERNIEKit 的更新紀錄顯示它處理的是 ERNIE 特有的問題：MoE 的平行策略、VL 模型的 128K LoRA 訓練、多模態影片資料的處理速度、以及 padding-free 的資料打包。這些不是通用訓練框架會自動幫你解決的事，尤其是 MoE 搭配 pipeline parallel 與 recompute 的組合，更新紀錄裡就有專門的修補項。
反過來說，通用框架的優勢是生態與人才。如果你的團隊熟悉 PyTorch 生態的分散式訓練，用通用工具處理 ERNIE 權重可能比學一套新工具鏈更快，代價是要自己處理 MoE 平行與多模態資料流的細節。
部署端的替代路徑更明確：README 把部署指向 PaddlePaddle/FastDeploy，而不是把推論塞進這個倉庫。如果你的推論服務已經有既定的框架，這個倉庫不會干預你，但也幫不上忙。
授權與長期維護成本
模型與工具箱採 Apache-2.0。這是一個寬鬆授權，允許修改與商用，並包含專利授權條款。這裡不提供法律意見，實際使用前請自行確認授權全文與你所在司法管轄區的要求。
維護成本可以從更新節奏推估。從 2025-06 的 v1.0 到 2025-11 的 v1.5，大約每兩個月一個版本，每個版本都帶新功能與修補。這個節奏對使用者是雙面的：功能補得快，但版本之間的差異也大，例如 v1.2 修掉的 checkpoint 儲存問題與 lora 128k 訓練問題，在更早的版本上就會遇到。
實務上的做法是鎖定 release 分支。倉庫預設分支是 release/v1.5，這表示專案自己就用 release 分支來管理版本界線。升級前先讀對應版本的更新紀錄，確認你依賴的功能沒有被改動，尤其是 AutoParallel 相關的設定，因為那是最常出現在修補清單裡的區域。
至於模型本身的替換成本，由於權重託管在 Hugging Face 而非本倉庫，模型更新與工具更新是兩條獨立的線，你需要分別追蹤。
編輯結論
已經在 PaddlePaddle 上跑訓練、或需要對 128K 上下文的 VL 模型做 SFT 與 function call 微調的團隊，這個倉庫值得先讀 docs/erniekit.md 再決定。若你的推論堆疊是 vLLM 或 TensorRT-LLM，或你只想下載權重而不打算碰訓練，那 ERNIEKit 的多數功能對你沒有用處，直接取 Hugging Face 上的權重即可。動手前先確認三件事：目標模型是否落在 ERNIEKit 已支援的 SFT 清單內（例如 ERNIE-4.5-VL-28B-A3B-Thinking 是 v1.5 才加入）、你的 GPU 是否在支援的硬體清單中（iluvatar 是 v1.2 才補上）、以及 424B 這類總參數量在你的儲存與平行策略下是否真的放得下。這三項任一不符，ERNIEKit 的價值就大幅下降。
社群筆記