LoongForge
百度百舸開源的全模態訓練框架，用一套統一框架覆蓋 LLM、VLM、擴散模型和具身智慧訓練，原生支援 NVIDIA GPU 和崑崙芯 XPU
深度報告
-
LoongForge 是百度百舸近期正式開源的全模態訓練框架，由內部訓練加速棧 AIAK-Training-LLM 演進而來。它用一個統一框架覆蓋大語言模型（LLM）、視覺語言模型（VLM）、擴散模型（Diffusion）和具身智慧（Embodied）四種模態的訓練需求，在主流模型上實現 15%–50% 的端到端訓練加速，並原生支援 NVIDIA GPU 和崑崙芯 XPU 雙硬體平臺。該框架已在教育、計算機視覺和具身智慧領域的企業客戶中經歷過大規模生產驗證，最大叢集規模超過 5000 個加速器，採用 Apache-2.0 協議開源。
-
LoongForge 的前身是百度百舸內部長期使用的訓練加速框架 AIAK-Training-LLM，在正式開源之前已經在多個行業的企業客戶中經受住生產級考驗——教育場景的模型訓練、計算機視覺的多模態任務、具身智慧的 VLA（視覺-語言-動作）模型，均有實際落地。2026 年 4 月，百度百舸決定將其正式開源並命名為 LoongForge，加入百舸 Loong 開源系列，與同系列的 LoongFlow（面向專家級 AI Agent 的思考與學習框架）遙相呼應。 「LoongForge」的名字取自中國傳統龍舟，寓意協同發力、破浪前行。截至 2026 年 7 月，其 GitHub 倉庫已有超過 150 顆星標，並保持了較高的社群活躍度。團隊的工程部落格定期更新技術深度文章，涵蓋異構並行訓練、DP 負載均衡、VLA 模型加速等主題，內容質量較高，說明專案團隊對技術投入較為持續。
-
LoongForge 的核心定位很明確：一個框架，四種模態。它的架構分三層——模型層負責統一抽象，系統層專注端到端最佳化，硬體層解決跨平臺適配。 在模型層，LoongForge 在 Megatron-LM 之上構建了一層模型抽象，將多模態模型拆解為感知編碼層（Encoder）、生成主幹層（Foundation）和組合排程層三部分。接入新模型只需要註冊對應元件，然後透過一份 YAML 配置檔案完成模組拼接和並行策略配置，不用改寫底層程式碼。實際測試中，團隊適配 LLaVA-OneVision 的新視覺編碼器 RICE-ViT 只花了幾天的工夫，對比傳統方案數週的適配週期，差距明顯。如果想把 Qwen3.5 的語言主幹替換成 DeepSeek V3，改一行 YAML 引用路徑就行，不需要 fork 整個倉庫。 在系統層的最佳化則更為密集。針對 LLM 基座，LoongForge 實現了 CCT 算通傳並行，將 MoE 模型在長序列訓練中的計算、通訊和資料傳輸進行統一編排，實測 Qwen3-30B-A3B 在 32K 序列長度下訓練效能提升了 16%。ChunkPipe 流水線並行解決了超長序列視訊記憶體瓶頸，讓百萬級上下文視窗在中小規模叢集上也能跑。對 DeepSeek V3.2 的 DSA 稀疏注意力架構，LoongForge 對注意力計算全鏈路做了深度運算元融合與最佳化，端到端效能提升了約 5 倍。 在多模態最佳化側，DP 負載均衡機制尤為關鍵。傳統資料並行在遇到長度極不均勻的多模態資料（單張圖片約 256 token、20 分鐘影片超過 10 萬 token）時，序列長度二次方差會導致各 GPU 實際計算量相差懸殊，快的卡等慢的卡。LoongForge 在每輪迭代前對樣本分配做動態重排，顯著收窄了各 Rank 之間的負載差距，這也是它在 5000+ 卡崑崙 P800 叢集上實現 90%+ 線性擴充套件效率的關鍵支撐。 模型異構並行則解決了 Vision Transformer 與 LLM 引數規模相差數百倍帶來的效率問題，允許二者各自獨立配置最優並行策略。實測 Qwen3-VL-30B 在 32K 序列下，相比社群方案吞吐提升了 45%。 硬體層的外掛化設計是 LoongForge 的一個差異化優勢。GPU 側透過 PyTorch/CUDA 原生對接 Megatron，XPU 側透過 XPU_Plugin 外掛封裝底層介面差異。同一份訓練程式碼只改一個環境變數，就能在 NVIDIA GPU 和崑崙芯 XPU 之間無縫切換。對需要跨硬體部署做訓練的團隊來說，這意味著不用維護兩套程式碼，也不用因為換硬體而重寫分散式邏輯。 使用體驗方面，LoongForge 延續了 Megatron 使用者的習慣，基礎訓練引數與 Megatron 相容，流水線和資料並行的配置風格接近。元件級的獨立配置（如視覺編碼器和語言主幹使用不同的 TP 大小）透過 Hydra 實現，對有一定分散式訓練經驗的團隊來說上手應該不會太困難。資料預處理工具鏈和離線轉換 HuggingFace 權重的工具也已內建。 當前版本（v0.1.0，2026 年 5 月釋出）已支援 20+ 模型族，覆蓋 DeepSeek（V2/V3/V3.2/V4）、Qwen（全系列 0.6B–480B）、LLaMA（2/3/3.1）、MiniMax、GLM 等主流 LLM；VLM 側支援 Qwen2.5/3-VL、InternVL2.5/3.5、Kimi-K2.5/K2.6、ERNIE4.5-VL 等；擴散模型支援 Wan2.1/2.2 和 Qwen-Image；具身模型覆蓋 Pi0.5、GR00T N1.6/N1.7、X-VLA、FastWAM 和多個世界動作模型。這一模型覆蓋範圍在開源訓練框架中目前是最廣的之一。
-
LoongForge 採用 Apache-2.0 協議開源，原始碼免費可用，沒有社群版與企業版的許可權區隔。作為一種訓練基礎設施，它的商業化路徑並非直接售賣軟體許可，而是透過吸引更多團隊在百度百舸的算力平臺上使用 LoongForge，拉動百度智慧雲的算力租賃和 AI 平臺服務需求。這與此前開源 AI 框架常見的商業模式一致——框架本身免費，能力越強、生態越大，對上游算力服務的拉動力就越強。得益於 XPU_Plugin 的設計，在百度崑崙芯上跑 LoongForge 的使用者無需額外適配，用 NVIDIA GPU 的使用者也不受影響。 目標使用者指向比較明確：做預訓練或大規模微調的團隊，尤其是那些已經被迫同時維護語言、視覺-語言、擴散和機器人四套不同訓練棧的團隊。它對單 GPU 使用者或只做推理的團隊沒什麼吸引力——這是典型的叢集級工具。
-
LoongForge 正式開源至今約三個月，社群反饋仍處於早期積累階段。從 GitHub Issues 和工程部落格的互動來看，技術社群的反應總體偏正面。 正面評價集中在幾個方面：一是「一套框架覆蓋全模態」的定位切中了實際痛點，有使用者評論提到「終於不用在 Megatron、LeRobot 和擴散框架之間來回切換了」；二是效能資料比較紮實，第三方評測站點 besthub.dev 的獨立分析文章認可了其 DSA 模型上超過 5 倍的加速表現；三是雙硬體後端的差異化優勢明顯，在社群對比文章中常被視作 LoongForge 相較於 Megatron-LM 和 DeepSpeed 的核心差異點——後兩者在崑崙芯上均無原生支援。 負面評價和爭議點也值得關注：一是框架尚處於早期階段（v0.1.0），部分功能（如檢查點格式轉換的穩定性）仍在持續迭代中；二是安裝部署門檻較高，目前依賴 Docker 映象或原始碼編譯，需要一定工程配置經驗；三是專案目前只有 150 餘顆星標，與 Megatron-LM 的成熟度差距較大，社群貢獻生態尚未形成規模。部分使用者也反映文件還需要進一步完善，特別是中文版文件的部分章節仍有翻譯痕跡。
-
LoongForge 所處的 AI 訓練框架賽道，目前已形成幾個清晰的分層。在 LLM 訓練領域，NVIDIA 的 Megatron-LM 和微軟的 DeepSpeed 是事實上的行業標準，前者在大規模分散式訓練的效能上一直被廣泛採用，後者以 ZeRO 最佳化系列著稱。在這兩個框架之外，還有面向微調場景的 LLaMA-Factory、Axolotl，以及 Hugging Face 生態的 Transformers。 LoongForge 的獨特之處在於它不是一個純粹的 LLM 訓練框架，而是一個試圖拉通多模態的「聚合型」框架。它繼承 Megatron-LM 的並行策略作為 LLM 基座，補上 LLM 框架普遍缺失的 VLM 視覺元件解耦和 VLA 具身模型支援，再向下相容擴散模型。行業媒體 36kr 和多家科技自媒體的報道普遍認為這個定位「務實」——它沒有宣稱要取代誰，而是去填補 Megatron-LM 等框架在多模態場景下的缺口。 值得注意的是，LoongForge 在國產晶片生態中佔據了一個獨特位置。目前主流開源訓練框架對國產晶片的支援普遍薄弱，而 LoongForge 的原生崑崙芯 XPU 支援使它在國產算力場景下幾乎沒有直接競品。這一優勢隨著國產晶片在大模型訓練中的佔比持續提升，價值可能會進一步放大。
-
LoongForge 現階段的主要風險源於它的成熟度。v0.1.0 版本仍屬於早期釋出，部分使用者在部署中遇到的環境配置問題尚未完全消化。與 Megatron-LM 在 GitHub 上數千顆星標和龐大的社群貢獻者規模相比，LoongForge 的社群生態還遠不夠成熟，長期維護和發展高度依賴百度百舸團隊的持續投入。如果百度內部戰略優先順序發生變化，框架的迭代節奏可能受到影響。 技術層面，LoongForge 的具身模型訓練子系統雖然設計思路清晰，但具身智慧領域自身的成熟度仍在快速演進中，主流策略模型的標準尚未形成，這意味著框架在具身方向的相容性可能面臨持續迭代的壓力。此外，框架對崑崙芯 XPU 的最佳化深度是否存在對特定硬體的隱性依賴，以及這種最佳化能否在不依賴百度內部算力的情況下被外部團隊低成本復現，也是值得持續關注的問題。
-
LoongForge 最適合的團隊畫像：正在做大模型預訓練或大規模微調、使用多種模態（LLM + VLM 或 LLM + 擴散或更復雜的組合）、已經感到維護多套訓練框架的成本在上升、並且希望保留在兩個硬體平臺間靈活切換的能力。對於那些只用純文字 LLM 做微調的團隊，直接用 LLaMA-Factory 或 Hugging Face 的 Trainer 可能更加輕量高效。如果團隊完全依賴 NVIDIA GPU 並且不需要具身模型訓練，當前版本的 Megatron-LM 或 DeepSpeed 也依然是更穩妥的選擇。
-
LoongForge 是一個定位清晰、設計務實的全模態訓練框架，在降低多模態訓練工程複雜度、打通國產晶片生態方面做出了差異化價值。它不是一個試圖「包打天下」的框架，而是去填補已有技術棧在多模態場景下的缺口。如果團隊已經在多模態訓練中感受到工程成本的壓力，值得關注這個專案。開源社群的積極反饋和持續的版本迭代，將是它能否真正成長為產業級解決方案的關鍵變數。
使用者評論
-
kqreqlob—LoongForge 這個框架是真的猛，我們團隊在崑崙芯 P800 上跑了 Qwen3-VL 的訓練，實測比之前用 Megatron 快了將近 40%，直接省了快一半的卡時。 -
DogeDadWalker—終於不用在 Megatron、LeRobot 和擴散框架之間來回切換了，一個 LoongForge 全搞定，維護成本下降太多了。 -
MiningMoleFoster—昨天試了 LoongForge 的 Embodied 子系統，Pi0.5 訓練比 OpenPI 快了 2.2 倍，具身模型這塊確實沒什麼框架能做到這個程度。 -
DomingoGonzález—文件還是有些粗糙，中文文件的部分章節明顯就是機器翻譯的，讀起來很彆扭，希望後面能好好修一下。 -
Stephen_Fisher2—apt install 一下午沒跑起來，最後還是靠 Docker 搞定的，安裝門檻確實不低，對新手不太友好。 -
Diana.StewartK—換基座改一行 YAML 這個設計太香了，以前在 Megatron 裡換主幹要改好幾層底層程式碼，現在真的一天搞定。 -
bigrabbit734—粗略跑了一下 DeepSeek V3.2，訓練吞吐確實吊打 Megatron，但是說實話社群太小了，遇到問題 Issues 裡問了三天沒人回。 -
StephenSmith_Pro601—DP 負載均衡這個機制很細節，我們 256 卡跑 InternVL 的時候確實看到吞吐提升了 3% 左右，大叢集效果應該更明顯。 -
VerbanShulga vasil—LoongForge 加崑崙芯的組合，對於被 GPU 卡脖子又想做多模態訓練的團隊來說，簡直是救命稻草。 -
石飛—CCT 算通傳並行這個思路漂亮，我們 32K 序列訓 Qwen3-MoE 的時候確實比之前少了將近 16% 的 wall time。 -
Sean.Stewart520399—v0.1.0 還是有不少坑的，checkpoint 轉換偶爾會報錯，而且訓練中斷恢復的時候不太穩定，剛開源可以理解吧。 -
xLauraPáez_dev—我比較關心的是有沒有長期維護的承諾，畢竟百度之前的開源專案斷更的也不少，LoongForge 希望能持續迭代下去。 -
ZLong_889—ChunkPipe 流水線並行很實用，之前 1M 長序列根本沒法在小叢集上跑，現在 8 卡就能搞定，對我們小團隊太友好了。 -
Betty.EvansSr567—看了那篇異構並行的技術部落格，編碼器用 TP=1 解碼器用 TP=4 這個方案確實聰明，ViT 通訊開銷直接降為 0。 -
Timothy_WilsonJr—同實驗室的在訓機器人策略模型，LoongForge 的 Embodied 子系統把 Pi0.5 的吞吐翻了一倍多，這資料擺在那沒法黑。 -
Cole397_r—Apache 2.0 協議開源好評，不像某些框架搞個社群版和企業版割韭菜，商用改起來也放心。 -
tinygoose585—專案到現在才 150 多顆星，跟 Megatron 比還是差太大，而且社群基本都是百度的開發在回問題，外部貢獻者太少。 -
SGonzales—如果不是要在崑崙芯上訓，我覺得沒必要上 LoongForge，純 NVIDIA GPU 的話 Megatron 還是更穩。 -
GregoryMartin_2020—跑 GR00T N1.6 的 VLA 訓練，訓練週期直接砍半，56% 的加速太誇張了，之前用 LeRobot 要等兩天才能出結果。 -
xJesusGrant_dev—自適應 FP8 在 Qwen3-VL 235B 上比全量 FP8 還快了 10%，這最佳化深度確實可以，不是那種換個皮就走的東西。 -
Russell_Robinson369—DL 負載均衡那個方案寫得挺深的，知道能看懂的人在跑大規模叢集時候體會更深吧，我們 64 卡效果就不錯了。 -
Jude665—總的來說是個可用的框架，但如果只能選一個穩定版，我會再等幾個小版本迭代再上生產環境。 -
x_7kpq611—有沒有人試過在崑崙芯 P800 上跑 Wan2.2 的擴散訓練？看了官方說加速 116%，我想知道實際復現的差距大不大。 -
StephanieWalker_2023—具身智慧這塊 LoongForge 確實打了差異化，其他框架都不怎麼管 VLA 和 WAM 模型的訓練加速，LoongForge 直接內建了一個子系統專門搞這個。 -
KimberlyLee—作為一個搞 infra 的，LoongForge 最吸引我的是 XPU_Plugin 的設計，換硬體不用重寫分散式邏輯，這在國產晶片採購場景下太實用了。 -
FrankLong—測試了幾天，發現 LoongForge 的 DSA 融合運算元對 DeepSeek V3.2 的加速確實很猛，5 倍差距不是吹的。 -
TSmith_88—能不能把 Docker image 先做好推到 Docker Hub 上？每次原始碼編譯太勸退了，我們團隊好幾個小夥伴都卡在環境配置上。 -
Alan.Price007—自從切了 LoongForge 之後，同時訓 LLM 和 VLM 終於不用在兩套配置之間反覆橫跳了，統一的 checkpoint 格式解放雙手。 -
DVasquez_2021—搞不懂為什麼非要自己做一套模型抽象層，直接基於 Megatron 加多模態支援不好嗎？說實話更希望看到對現有生態的相容，而不是又出一個新框架讓人學。 -
RHughes_7718—雖然還在早期，但這個方向真的正確。多模態訓練的基礎設施太碎片化了，LoongForge 至少給了一條路。如果百度能堅持投入，兩年後很有可能成為標配。