#MoE模型
華為:讓DeepSeek的“專家們”動起來,推理延遲降10%!
昨天的文章已經提到,昇騰超大規模MoE模型推理部署技術在本周會有持續的技術披露,果然第二天的技術報告又如期而至了。要問最近那個模型最火,混合專家模型(MoE,Mixture of Experts)絕對是榜上提名的那一個。它的巧妙之處,就在於把不同的任務分配給擅長處理的專家網路,讓整個系統性能得以提升。但你知道嗎?正是這個關鍵的專家網路,也是嚴重影響系統推理性能的因素之一。因為在大量任務來臨之際(尤其是超大規模時),MoE並不是以“雨露均霑”的方式去分配——專家網路們的負載平衡問題,就會顯得尤為突出。這個問題的根源,是因為某些專家網路總是被頻繁呼叫(熱專家),而另一些專家網路則鮮有機會派上用場(冷專家)。沒錯,MoE裡的“專家們”也是有冷熱之分的,而且被呼叫頻率的差距甚至可以達到一個數量級以上!如此負載不均衡的現象,就會導致整個系統推理的時間被延長,以及還有資源利用率、系統性能受限等問題。那麼此局又該如何破解?別急,華為團隊已經給出了一種有效解法,直接讓DeepSeek-V3在理論上的推理延遲可降低約10%、吞吐量可提升約10%。值得一提的是,團隊還將在近期準備把這個解法全面開源了;那麼接下來,我們就來深入瞭解一下。華為的刀法:OmniPlacement針對專家們冷熱不均的問題,華為最佳化的刀法,叫做OmniPlacement。簡單來說,它的工作原理是這樣的:通過專家重排、層間冗餘部署和近即時動態調度,顯著提升MoE模型的推理性能。具體可以分為三步走:第一刀:基於計算均衡的聯合最佳化在這一步中,華為團隊通過分析專家的活躍度(啟動資料),先是識別出了忙碌的熱專家和清閒的冷專家。然後將提出的一種基於計算均衡的聯合最佳化演算法OmniPlacement用了上去。這個演算法會根據專家呼叫頻率和計算需求來最佳化部署的順序,這樣就會顯著降低負載不均的現象。具體來說,OmniPlacement演算法的特點如下:動態優先順序調整:通過即時統計專家呼叫頻率,動態調整專家的優先順序和節點分配,確保高頻專家優先部署在計算能力較強的節點上。通訊域最佳化:演算法分析批次內啟動卡數,最佳化跨節點通訊域的範圍,減少通訊延遲。相比傳統的靜態分配方法,本演算法顯著降低了通訊開銷。層間差異化部署:允許不同層根據負載特性設定不同的專家部署策略,支援非均勻冗餘次數配置,從而更好地適應層間負載差異。△相同資料條件下,EPLB與OmniPlacement演算法,每層裝置最大啟動數理論對比第二刀:層間高頻專家冗餘部署剛才的步驟是面向冷熱專家整體,那麼這一步則是劍指熱專家。為了緩解熱專家的壓力,華為團隊還提出了一種層間冗餘部署的策略——通過為高頻呼叫專家分配額外的冗餘實例,降低跨節點通訊開銷,從而提升系統吞吐量。這個策略的創新點在於:動態資源分配:根據即時計算資源佔用情況和專家呼叫頻率,動態調整冗餘實例的分配比例。系統通過預測模型提前分配資源,減少冷熱專家間的性能差距。層間差異化配置:不同層根據負載需求設定不同的冗餘次數,增強對層間負載差異的適應能力。例如,高負載層可分配更多的冗餘實例,而低負載層則減少冗餘以節省視訊記憶體。預測性分配:結合歷史啟動資料和負載預測模型,系統能夠提前最佳化資源分配,降低突發負載對系統性能的影響。△冗餘不同層數排布的理論熱力圖第三刀:近即時調度與動態監控機制為了讓系統能更靈活地應對各種變化,在實際運行中快速做出反應,研究團隊設計了一套類似 “智能管家” 的方案——近即時調度與動態監控機制。其具體包含的子模組如下:近即時調度:通過即時統計資料流特性,動態調整專家分配以適應輸入資料的變化。調度演算法能夠在毫秒級時間內收斂到最佳化的靜態專家部署模式,確保推理過程的高效性和一致性。該機制通過迭代最佳化專家分配,顯著降低了動態調整的計算開銷。動態監控:即時跟蹤專家啟動資料和系統資源佔用情況,為調度決策提供精準依據。監控任務在獨立的計算流中運行,避免對推理主流程的干擾,保障系統整體效率。動態專家權重訪問與擺放:通過層間流水線設計,實現專家權重和分配的動態調整。系統在推理過程中平行處理權重更新和資料流分配,支援高效的專家動態擺放。流水線設計允許在不中斷推理流程的情況下完成權重調整,顯著降低高負載場景下的推理延遲。這套機制通過兩個關鍵設計大幅提升了系統性能:首先採用多工平行處理技術,讓系統反應更快、調整更靈活;其次獨創性地將監控和調度功能分開運行。這樣既保證了即時監控的精準性,又避免了監控程序拖慢系統速度,使整個系統運行更加穩定可靠。△近即時調度理論效果與收斂性為了支援上述技術的穩定運行,團隊還開發了適用於vLLM的推理最佳化框架OmniPlacement,其核心特點如下:高相容性:框架支援多種MoE模型架構,能夠無縫整合到現有的推理系統中。低時延開銷:通過最佳化資料處理和調度流程,框架顯著減少了額外計算開銷,確保推理性能不受影響。模組化設計:框架包含資料統計、演算法運行和專家調度三大模組,各模組功能解耦,支援功能擴展和維護。模組化設計便於快速迭代和定製化開發。可擴展性:框架支援動態加入新的負載平衡演算法和調度策略,適應未來MoE模型的複雜需求。OmniPlacement採用模組化設計,把核心演算法和推理流程分開處理,就像把汽車的發動機和控制系統分開最佳化一樣。這樣設計有兩個突出優勢:一是專門負責任務調度的模組可以獨立工作,不會干擾主系統的運行效率;二是整個框架可以根據不同需求靈活調整,為大型AI模型的穩定運行提供了堅實的底層支援。DeepSeek V3系統延遲理論可直降10%在瞭解完華為的“刀法”之後,我們再來看下“療效”。華為團隊把這套最佳化方法在DeepSeek-V3上進行了全面驗證,實驗環境包括多節點GPU叢集和高並行推理場景。得到了如下的測試結果:推理延遲:相比基線方法(未最佳化負載平衡的MoE模型),推理延遲平均降低約10%。延遲的減少主要得益於動態專家分配和通訊域最佳化,顯著改善了使用者體驗。吞吐量:系統吞吐量提升約10%,反映了資源利用率的顯著提高。特別是在高並行場景下,冗餘部署和動態調度有效緩解了負載瓶頸。系統穩定性:在動態輸入和高負載場景下,系統保持高效運行,未出現性能波動或服務中斷。動態監控機制確保了系統對突發負載的快速響應。△OmniPlacement與基線和BestEP的性能對比進一步的分析表明,OmniPlacement在不同規模的MoE模型和輸入資料分佈下均表現出良好的適應性。並且從實際測試證明來看,它不僅能大幅提升運算效率,還能更合理地利用計算資源,同時保持系統穩定運行。這為今後在實際應用中部署大型MoE模型提供了堅實的技術保障。最後值得一提的是,華為團隊不僅是發佈最佳化方案這麼一個動作,更是要將這個方法在近期全面開源。 (量子位)
華為全面揭秘超大規模MoE模型昇騰推理部署技術,國產晶片推理性能再創新高
“華為不只是「官宣」一下而已,後面更會是全面開源。”推理部署,成為大模型落地重中之重從2017年Google提出Transformer——這一人工智慧中最常用的神經網路架構,到DeepSeek V3/R1在2025年春節一夜爆火,超大規模MoE架構大模型的重點逐漸從訓練開發轉向推理支撐的應用落地。推理場景是大模型認知能力的"試金石",是大模型商業化落地的核心能力,從搶先上線DeepSeek模型到API服務價格戰,在推理為王的時代,誰能最極致的提升推理部署計算效率,誰才能真正獲得大模型商業成功。數學補物理,極致提升計算效率“數學補物理” ,通常指通過數學理論、演算法和建模方法,彌補傳統物理裝置開發在複雜系統分析、大規模計算或多場耦合問題中的侷限性。華為輪值董事長孟晚舟曾在2025年新年致詞中提到:“華為十多個實驗室與夥伴們的工程師組成“大雜燴”團隊,面對天成AI叢集系統和單晶片性能的嚴峻工程挑戰,他們創造性應用數學補物理、非摩爾補摩爾、系統補單點等思想,在散熱、供電、高速、高密及大晶片在板可靠性等工程領域突破極限。”華為技術團隊面向超大規模MoE模型的推理技術最佳化也是圍繞著數學補物理這一思路,充分發揮等價數學變換,也就是在保持數學對象本質屬性不變的前提下,通過代數變形、邏輯轉換或結構重構等方式提升計算效率的方法,極致的提升了硬體叢集的計算效率,包括從點到面的推理框架側最佳化技術,把數學最優實現變為物理最優的FlashComm通算最佳化技術,把序列計算變成四流並行的通算極致掩蓋技術,以加法代乘法昇騰MLA最優實現,硬體感知親和的大量創新算子等一系列核心技術孕育而生,並將通過一連串的技術報告首次全面披露這些寶貴的技術細節。開源共享,打造持久的開放協作生態昇騰生態的建設不是一次性的工作,而這次昇騰超大規模MoE模型推理部署技術的揭秘,除了通過技術報告分享昇騰在超大規模MoE模型的推理部署技術之外,在不到一個月的時間之後,實現這些核心技術的相關程式碼也都會陸續開源出來, 歡迎關注https://gitcode.com/ascend-tribe/ascend-inference-cluster中的持續更新。在與業界分享技術思路的同時,也通過開放原始碼的方式共同打造長期持續的開放協作生態環境,讓昇騰親和的技術能力通過這些開放原始碼專案真正的活躍起來,這體現出華為堅定建設開放生態的決心,讓所有願意嘗試使用昇騰能力的專家有信心長期投入,也讓所有積極參與貢獻的開發者有信心持續耕耘,一起努力讓昇騰生態在中國茁壯成長。超大MoE類模型推理的挑戰擁有6710億參數,採用混合專家架構,在各種榜單表現出色的DeepSeek V3某種程度上代表了大模型發展的一個新趨勢,即基於軟硬體協同最佳化的模型架構,能夠最大性能的發揮硬體平台的能力,在多種任務中表現出色,包括自然語言理解、程式碼生成和數學推理。我們暫且把DeepSeek V3為代表的大模型統稱為超大MoE類模型。儘管在性能上表現出色,並且有著大量開放原始碼的模型權重以及很多的包括DeepEP等在內的工具類項目,但對於想使用這類大模型的企業來說,能夠部署完整版本的超大MoE類模型目前依舊面臨多重挑戰:首先,硬體部署規模要求更高。現在我們在和大模型進行互動聊天的時候,無時無刻不在使用大模型的推理。而由於其自身的尺寸規模,這不再是此前小尺寸模型在單機多卡甚至單機單卡就可以運行能夠相比的。硬體叢集逐漸成為“滿血版”超大MoE類模型的標配。其次,模型規模龐大對推理效率提出了高要求。龐大的專家數量給硬體記憶體使用效率提出了很大挑戰,需要合理的分佈式平行和通訊策略設計,才能將如此大量的專家有效的跑在硬體叢集上。再次,超大MoE類模型的諸多架構創新,也帶來了很多實際部署上的困難。比如其多頭隱式注意力機制(MLA - Multi Head Latent Attention),雖然可以通過將原有的注意力機制的鍵值對通過一個投影矩陣壓縮到一個較小的隱式向量空間中,但這種創新也為算子最佳化帶來了新的挑戰,比如其帶來了中間變數膨脹且向量計算佔比顯著增加,這樣給硬體對計算的加速提出了新的要求。昇騰使能技術對大模型叢集推理的極致創新為瞭解決如上提到的實際部署中遇到的問題,從模型和算子兩個方面入手,我們基於昇騰硬體和組網方式,提出了多個親和的最佳化策略,開發出了一整套面向叢集的大規模專家平行的解決方案。昇騰伺服器有多種配置和型號,我們針對近期發佈的CloudMatrix 384 超節點和Atlas 800I A2 推理伺服器兩種典型機型進行部署。為瞭解耦prefill 階段的首token 時延約束和decode 階段的解碼時延約束,我們採用PD 分離部署的方式。在框架側,我們基於vLLM框架,為了適配昇騰伺服器,針對DP和EP 平行策略做了相應適配,在調度和KV 傳輸方面分別採用了Prefill調度分桶和靈衢互聯與分層傳輸的技術來降低調度開銷,在請求下發、調度策略、系統建鏈和框架前後處理方面做了性能最佳化,以實現整個系統的最優性能。模型方面,我們採用A8W8C16 的量化策略,其中A8W8 採用INT8 的資料類型,C16 採用BF16 的資料類型進行量化。詳細的部署方面,由於兩種機型的定位和配置,特別是網路配置相差巨大,所以具體部署方案也不盡相同。針對CloudMatrix 384 超節點,其特殊的組網方式為其提供了非常強大的優勢。按照DeepSeek的論文所述,Decode 部分是嚴重的通訊主導,在MicroBatch技術的加持下,幾乎可以做到通訊掩蓋其他所有計算類操作。而CloudMatrix 384 的組網非常強大,使得通訊耗時大幅降低,可以更進一步釋放昇騰晶片的算力。因此,針對超節點我們採用大規模EP 平行的方式來部署,針對Prefill 使用16 卡,針對Decode 使用144 卡,其中128 卡部署路由專家,16 卡通過DP 的方式部署共享專家,MLA 部分使用DP 的方式進行部署。超節點可以獲得非常高的吞吐,當然由於各種情況的影響,包括時延約束的影響使得各部分耗時未能達到理想的線性度,頻寬搶佔和啟動開銷等帶來一部分性能劣化,框架的耗時和調度開銷帶來了額外的時延增加,MLA 部分的序列負載平衡和MoE部分的專家負載帶來進一步的性能惡化;最後多種原因綜合在一起,使得當前吞吐實現在保證50ms 時延下單卡decode 吞吐達到1920 token/s。針對Atlas 800I A2 伺服器,由於其是8 卡的伺服器,我們需要採用多機互聯的方式來進行。綜合考慮模型吞吐和部署靈活性,我們選定使用2 機16 卡作為一個prefill 示例,使用4 機32 卡作為一個decode 示例。為了部署時儘可能的靈活,這裡選用的卡數都比較少,這使得我們採用較小規模的EP 平行策略:每張卡上部署8 個路由專家和1 個共享專家。MLA 部分採用DP 平行策略,通訊方式採用AllGather方案。這種部署方式可以在卡數較少情況下依然達到相當可觀的吞吐。這裡值得一提的是,我們的通訊方案採用的是AllGather而不是Dispatch/Combine 的通訊方案,該方案在真實負載下具有更好的性能表現。採用各種最佳化策略的情況下,實現了在100ms 時延下達到單卡吞吐速度808tokens/S。1.推理框架側最佳化技術1) API Server 擴展技術團隊提出了API Server 擴展技術,通過支援API Server 水平擴容策略,可以有效提升框架請求處理能力,降低使用者請求延遲,提高系統吞吐量(QPS)。結合包括組網方案最佳化和全平行、全非同步前後處理,可進一步實現最佳TTFT,提升推理服務的可用性與處理效率。2)MoE模型負載平衡團隊提出了一種高效的負載平衡策略,通過動態負載平衡,熱專家冗餘部署,即時調度和動態監控等核心技術,顯著提升MoE 模型推理性能。2. FusionSpec推理投機加速技術在實際應用中,投機推理技術更多聚焦於小批次(batch)低時延場景,如何將其高效應用於高吞吐量場景並實現性能收益最大化,成為當前亟待攻克的技術難題。投機推理提升了模型解碼階段的計算密度,天然匹配昇騰高計算頻寬比的特點。為了能夠充分發揮昇騰算力大的優勢,在低時延大並行場景下實現高吞吐,我們提出了投機推理引擎FusionSpec深度最佳化MTP 在昇騰上的推理性能:在推理流程上,將投機模型置於主體模型之後,直接使用主體模型的輸出,並復用主體的控制參數,大幅減少了框架耗時,並親和PD 分離的部署場景。為了在投機推理開啟時進一步發揮Ascend 的計算能力,減少NPU 的空閒時間,我們對投機推理的框架、採樣(sampler)操作、多頭潛在注意力(MLA)計算進行了最佳化。3.FlashComm通訊最佳化技術FlashComm :主流張量平行(TP)中使用AllReduce進行通訊的方案存在通訊次數多,通訊資料量大,通訊資料格式位元數高等問題,且AllReduce之後的如殘差連接和歸一化計算存在計算冗餘,沒有充分利用多卡平行能力。為此,我們提出FlashComm網路通訊方案:我們針對Deepseek網路前三層稠密MLP 層,基於相同的集合通訊邏輯將張量平行中的AllReduce通訊算子進行替換,並對通訊算子在網路中位置進行編排,實現了低位元和低維度資料通訊,從而有效降低了通訊資料量和通訊時延,並消除了網路中存在的冗餘計算。層內平行轉換技術:在FlashComm的基礎上,為進一步最佳化通訊算子的時延,我們提出層內平行轉換的最佳化方案:我們針對Prefill 階段網路MLA 層重新設計了單層內使用的平行策略,靈活做到張量平行(TP)與資料平行(DP)的轉化,消除節點內卡間求和的需求,且充分利用網路低資料維度和量化特性實現節點間通訊量的大幅降低,從而顯著最佳化了通訊時延。計算通訊並行:昇騰晶片提供了計算和通訊的並行機制。MoE層的計算過程中需要使用AllGather匯聚各張卡上的Token 的特徵進行啟動專家的篩選和計算。我們的方案中,對於Gate 函數使用先計算後通訊匯聚的方法,對共享專家使用DP 的方式,從而保證了Gate 函數的計算和通訊、共享專家的計算,以及特徵匯聚的AllGather函數之前沒有依賴關係。我們利用昇騰的多流機制,將這三部分進行並行處理,從而最大化推理模型的性能。特別的,模型部署方面可以根據不同的需要進行更細緻的設計,比如為了能更好的節省記憶體,共享專家可以採用機內TP 機間DP 的方式,共享專家的計算仍然可以和機間AllGather通訊或者其他機器傳輸來特徵的機內通訊進行並行掩蓋。通訊通訊並行:昇騰晶片也提供了通訊和通訊並行的機制。當通訊頻寬利用率比較低的時候,可以把兩個通訊算子並行起來以掩蓋通訊算子的啟動開銷,同時提高通訊頻寬的利用率。DeepSeek模型在進行AllGather等通訊時,可以將Norm 算子和量化算子移到AllGather通訊的前面,從而降低通訊的資料量,進而提高通訊的效率。但是由於量化算子的前移,需分別通訊量化後的啟動值和scale,進而增大了通訊算子啟動開銷。由於scale 的資料量較小,對頻寬的佔用極低,因此我們採用通訊通訊並行的機制,將通訊啟動值和通訊scale 並行起來,在不增加啟動值通訊開銷的前提下,掩蓋掉scale 的通訊代價。通訊和權重預取的並行:昇騰晶片提供了快取機制,算子在進行計算時,會優先從快取中尋找資料,如果存在,則直接從快取中讀取資料,否則從HBM 中讀取資料,而快取的頻寬是HBM 頻寬的幾倍。由於通訊算子進行過程中HBM 頻寬佔用率較低,我們在通訊算子進行過程中可以將後續算子需要的權重提前預取到快取中,從而降低後續算子計算過程中的權重搬運開銷。同時昇騰晶片支援靈活限定預取頻寬,因此在通訊過程中預取對通訊性能影響很小。對於DeepSeek模型我們在MoE結束的ReduceScatter預取MLA 中權重矩陣和KV cache,可以提升MLA 部分的計算性能。4.昇騰親和的創新算子1) MLA 算子最佳化:Attention 算子:MLA 相較於傳統的Attention 算子(如MHA, GQA 類顯著頻寬瓶頸的算子),由於其中間變數膨脹且計算量顯著增加,為算子最佳化帶來了新的挑戰。針對昇騰處理器的架構特性,我們對MLA 場景的FA 算子進行了演算法重構以及硬體親和的性能最佳化。提出AMLA(Ascend MLA)演算法,通過浮點二進制編碼解析及原子累加操作實現乘性計算的加性等價轉換,從而實現直接在Global Memory 上更新O 的步驟,無須進入Vector core,大幅降低中間變數的重複搬運。對L1 快取進行了細緻規劃,儘可能地減少資料重複搬入搬出的過程。在工程實現方面,通過最佳化計算流程提高L2 cache 命中率,並且利用K-buffer 流水排布等策略,實現Cube 計算和Vector 計算互相掩蓋,提高了算子整體性能。同時,雖然當前版本的模型實現中並未採用KVCache的量化演算法,但我們也對MLA 的Attention 計算,針對僅KV cache 的INT8 量化和Q/K/V 全INT8 量化場景均進行了深度的算子重構與極致流水最佳化。MLA 前序算子:針對複雜的MLA 前序算子,我們分別在Prefill 階段和Decode 階段採取了不同的最佳化策略:在Prefill 階段,我們通過雙流並行等技術實現了流水掩蓋,同時增加了FA 算子對多種輸入輸出模式的支援以消除純訪存類冗餘算子。在Decode 階段,我們採用權重吸收,同時將前序算子深度融合為MLAProlog算子,並且針對昇騰硬體架構進行了全方位的深度最佳化。具體最佳化措施包括:採用權重預取減少流水線空泡;基於最小化搬運以及最大化頻寬的tiling 策略;通過計算解耦降低指令依賴與等待;利用局部計算融合消除全核同步開銷;運用昇騰定製指令集實現ICache壓縮,規避issue queue 阻塞風險等。2) MOE 算子最佳化Dispatch/Combine 通算融合算子:在EP 部署模式中,MoE中的專家分佈在較大的通訊域的各個卡上,每個Token 需要分發到對應的卡上進行計算,原始的實現方式使用InitialRouting根據專家排序對所有Token 進行重排,再用AllToAll以及AllToAllv通訊算子進行交換token。該實現方式在通訊域比較大的場景下,存在通訊次數多,卡間同步開銷嚴重等問題,阻礙了整網端到端時延的提升。因此,我們提出MoeDistributeDispatch和MoeDistributeCombine兩個通算融合算子技術:將計算和傳輸拆解為Token 粒度的計算單位,通過流水排布實現通訊和計算的平行執行;同時利用記憶體語義的通訊技術直接向不同卡上的共用記憶體傳輸資料,從而減少了本地複製和等待資料的開銷;我們通過本地記憶體篩選和複製的機制,減少了資料傳輸次數和卡間同步開銷。SMTurbo-CPP 算子:針對MOE 層大通訊域場景下,小資料量傳輸效率低的問題,我們提出SMTurbo-Concurrent Push and Pull (SMTurbo-CPP)技術:在記憶體語義等級對通訊算子AllToAll(v) 進行最佳化,充分利用硬體並行能力,使用讀寫混合、聚合流水、批次檢測等技術,提升了執行緒的訪存效率與吞吐,顯著降低Dispatch 和Combine 場景通訊算子的時延。細粒度分級流水演算法:基於Atlas A2 系列產品,HCCL 支援細粒度的分級流水演算法,可大幅提升叢集中Allgather、ReduceScatter、AlltoAll等集合通訊算子的執行效率。該演算法利用A2 組網的特性,實現了Server 內/Server 間的並行執行,以提高頻寬利用率。性能表現在2025 年4 月,矽基流動聯合華為雲基於CloudMatrix 384 超節點昇騰雲服務和高性能推理框架SiliconLLM,用大規模專家平行最佳實踐正式上線DeepSeek-R1。該服務在保證單使用者20 TPS 水平前提下,單卡Decode 吞吐突破1920 Tokens/s,可比肩H100 部署性能。同時,經過主流測試集驗證及大規模線上盲測,在昇騰算力部署DeepSeek-R1 的模型精度與DeepSeek官方保持一致。結 語在人工智慧大模型技術蓬勃發展的浪潮中,華為憑藉其卓越的算力支撐和創新架構設計,正在為行業創新注入澎湃動力。華為發佈昇騰推理系列關鍵技術,並將於近期開放技術程式碼,建構開放共贏的開發者生態,推動大模型技術的創新發展,為中國自主的人工智慧生態體系貢獻核心力量。 (雷峰網)
阿里Qwen3深夜開源!8款模型、整合MCP,性能超DeepSeek-R1,2小時狂攬16.9k星
開源大模型新王!Qwen3連發8種規格支援119種語言。阿里通義大模型新成員Qwen3系列模型終於亮相!智東西4月29日報導,今日凌晨4點,阿里雲正式開源Qwen3系列模型,包含2個MoE模型、6個稠密模型。發佈2小時,Qwen3模型在GitHub上的star數已超過16.9k。其中旗艦模型Qwen3-235B-A22B,在程式設計、數學、通用能力等基準評估中的表現優於DeepSeek-R1、OpenAI o1、OpenAI o3-mini、Grok-3和Gemini-2.5-Pro等業界知名模型。此次全新升級的Qwen3系列有以下5大關鍵特性:8種參數大小的稠密與MoE模型:0.6B、1.7B、4B、8B、14B、32B和Qwen3-235B-A22B(2350億總參數和220億啟動參數)、Qwen3-30B-A3B(300億總參數和30億啟動參數);引入混合思考模式:使用者可切換“思考模式、“非思考模式”,自己控制思考程度;推理能力提升:在數學、程式碼生成和常識邏輯推理方面超越QwQ(在思考模式下)和Qwen2.5 instruct models(在非思考模式下);支援MCP(模型上下文協議),Agent能力提升:可以在思考和非思考模式下實現大語言模型與外部資料來源和工具的整合,並完成複雜任務;支援119種語言和方言:具備多語言理解、推理、指令跟隨和生成能力。目前,Qwen3系列模型已在Hugging Face、ModelScope和Kaggle等平台上開源,均遵循Apache 2.0許可證。在部署方面,其部落格提到,建議開發者使用SGLang和vLLM等框架,並推薦本地部署的開發者使用Ollama、LMStudio、MLX、llama.cpp等工具。值得一提的是,Qwen3模型採用了不同的命名方案,後訓練模型不再使用“-Instruct”後綴,基礎模型的後綴是“-Base”。體驗地址:https://chat.qwen.ai/部落格地址:https://qwenlm.github.io/blog/qwen3/GitHub地址:https://github.com/QwenLM/Qwen3Hugging Face地址:https://huggingface.co/collections/Qwen/qwen3-67dd247413f0e2e4f653967f01.以小搏大!啟動參數僅1/10 實現性能反超6個稠密模型中,0.6B~4B參數規模的模型上下文長度為32K,8B~32B參數規模的模型上下文長度為128K。2個MoE模型的上下文長度均為128K。小型MoE模型Qwen3-30B-A3B,在啟動參數是QwQ-32B的1/10的情況下,實現了性能反超。且參數規模更小的Qwen3-4B模型,實現了與Qwen2.5-72B-Instruct的性能相當。其他基準測試評估結果顯示,Qwen3-1.7B/4B/8B/14B/32B-Base的性能分別與Qwen2.5-3B/7B/14B/32B/72B-Base相當。其部落格還特別提到,在STEM、程式設計和推理等領域,Qwen3稠密模型的性能甚至優於參數規模更大的Qwen2.5系列模型。▲Qwen3系列與Qwen2.5系列基準測試對比02. 引入混合思考模式支援119種語言、MCP協議Qwen3系列模型的關鍵特性包括引入混合思維模式、支援119種語言和方言、整合MCP協議以提升Agent能力。其中,混合思維模式指的是支援思考和非思考兩種模式。思考模式下,模型會逐步推理,花費時間給出最終答案,這適用於需要深入思考的複雜問題;非思考模式下,模型提供快速、幾乎瞬間的響應,適用於對響應速度敏感的問題。▲思考和非思考模式對比這使得使用者可以根據任務需求控制模型進行的“思考”程度。例如,對於更難的問題可以使用擴展推理來解決,而對於較簡單的問題則可以直接回答,無需延遲。此外,這兩種模式的整合還增強了模型實施穩定和高效思考預算控制的能力,這種設計使使用者能夠組態特定任務的預算,平衡實現成本效率和推理質量。在多語言方面,Qwen3模型支援119種語言和方言。此外,Qwen3系列模型在程式設計和Agent能力方面性能提升,整合了MCP協議。03. 預訓練資料集翻番 模型兼顧逐步推理、快速響應與Qwen2.5相比,Qwen3的預訓練資料集大小翻了兩倍。Qwen2.5在1800億個token上進行預訓練,Qwen3基於大約3600億個token進行預訓練。為了這一大型資料集,研發人員收集了網路資料、PDF文件資料等,然後使用Qwen2.5-VL從這些文件中提取文字,並使用Qwen2.5提高提取內容的質量。同時,為了增加數學和程式碼資料量,研發人員使用了Qwen2.5-Math和Qwen2.5-Coder來生成教科書、問答對和程式碼片段等合成資料。預訓練過程分為三個階段:在第一階段,模型在超過3000億個token上進行了預訓練,上下文長度為4K個token。這一階段為模型提供了基本語言技能和一般知識;在第二階段,其通過增加STEM、程式設計和推理任務等知識密集型資料的比例來改進資料集,並讓模型在額外的500億個token上進行預訓練;第三階段,研發人員使用高品質的長上下文資料將上下文長度擴展到32K個token,使得模型可以處理較長的輸入。在後訓練階段,為了開發既能逐步推理又能快速響應的混合模型,研發人員採取了四階段訓練流程:思維鏈(CoT)冷啟動、基於推理的強化學習、思維模式融合、通用強化學習。第一階段,其使用多樣化的長思維鏈資料微調模型,涵蓋各種任務和領域,如數學、程式設計、邏輯推理和STEM問題,這個過程旨在使模型具備基本的推理能力。第二階段專注於擴大強化學習的計算資源,利用基於規則的獎勵來增強模型的探索和利用能力。第三階段,通過在長思維鏈資料和常用指令微調資料組合上微調,將非思考能力整合到思考模型中。這些資料由第二階段增強的思考模型生成,確保推理能力和快速響應能力的無縫融合。第四階段,其將強化學習應用於超過20個通用領域任務,包括指令遵循、格式遵循和Agent能力等任務,以進一步增強模型的一般能力和糾正不良行為。04. 結語:Agent生態爆發前夜最佳化模型架構和訓練方法推進智能升級通過擴大預訓練和強化學習的規模,可以看到Qwen3系列模型以更小的參數規模實現了更高的智能水平,其整合的混合思考模式,使得開發者能更靈活控制模型預算。研發人員還提到,未來其將圍繞以下幾個維度繼續提升模型能力:最佳化模型架構和訓練方法,以實現擴展資料規模、增加模型大小、延長上下文長度、拓寬模態的目標,並通過環境反饋推進長期推理的強化學習。如今,AI產業正從關注模型訓練的時代過渡到一個以訓練Agent為中心的時代,未來大模型能力的實際應用價值將逐漸被放大,通義大模型系列也正以此為目標繼續推進升級。 (智東西)
Llama 4革命:原生多模態AI的創新時代
昨天發佈Llama 4系列模型全面擁抱MoE<溫習>,在 MoE 模型中,單個 token 僅啟動總參數的一小部分。MoE 架構在訓練和推理方面的計算效率更高,並且在給定固定訓練 FLOPs 預算的情況下,與密集模型相比,可提供更高的質量。在Llama4系列中有兩個高效的模型,一個是Llama 4 Scout,一個由16位專家組成的17B的啟動參數模型,另一個是Llama 4 Maverick,一個由128位專家組成的17B個啟動參數模型。前者適用於單個H100 GPU(Int4量化),後者適用於單個H100主機。MoE 層使用 128 個路由專家和一個共享專家組合而成。當然這個系列中還有一個教師模型Llama 4 Behemoth(2T參數的巨獸),它在以STEM為核心的基準測試(如MATH-500和GPQA Diamond)上的表現優於GPT-4.5、Claude Sonnet 3.7和Gemini 2.0 Pro。Llama 4 Behemoth仍在訓練中,但已經可以看到其中的很多技術細節。Llama 4 Scout是一個109B的參數規模,其中17B的啟動參數,由 16 位專家組成,據說是世界上同類產品中最好的多模態模型,比所有上一代 Llama 模型都更強大,同時適合單個 H100 GPU。Llama 4 Scout提供了行業領先的10M上下文窗口,並且在熱門的基準測試中提供了比Gemma 3、Gemini 2.0 Flash-Lite和Mistral 3.1更好的結果。它採用創新的iRoPE(交錯旋轉位置嵌入)架構來增強長上下文泛化,而且表現不俗。在大模型處理中長視訊任務時,NLL(負對數似然)基準是一種常用的評估指標,用來衡量模型對視訊內容建模的精準性。它反映的是模型在預測視訊中下一幀、下一動作或下一事件時的“信心”。NLL值越低,說明模型對視訊的理解和預測越準確。在中長視訊場景下,這種基準可以幫助判斷模型是否具備捕捉長時間依賴關係和複雜時序結構的能力,因此被廣泛用於大模型在視訊生成、視訊理解等任務中的性能對比和調優。Llama 4 Maverick的參數規模為400B,其中17B個啟動參數,擁有128名專家,是同類產品中最好的多模態模型,在廣泛報導的基準測試中擊敗了GPT-4o和Gemini 2.0 Flash,同時在推理和編碼方面取得了與新的DeepSeek v3相當的結果——而且啟動參數不到一半。Llama 4 Maverick提供一流性價比,實驗性聊天版本在LMArena上的ELO得分為1417。DeepSeek v3.1暫時不支援多模態Llama 4 Maverick主要歸功於Llama 4 Behemoth的蒸餾,Llama 4 Behemoth具有2T的總參數,288B個啟動參數模型,擁有 16 位專家。Llama 4 Behemoth在多項STEM基準測試中優於GPT-4.5、Claude Sonnet 3.7和Gemini 2.0 Pro。Llama 4模型採用原生多模態設計,結合早期融合,將文字和視覺標記無縫整合到統一的模型主幹中。早期融合是向前邁出的一大步,它聯合大量未標記的文字、圖像和視訊資料進行預訓練模型的訓練,尤其是這個過程中它還改進了Llama 4中的視覺編碼器(基於MetaCLIP)。訓練過程中還採用一種新的訓練技術,姑且稱之為 MetaP。它能夠可靠地設定關鍵的模型超參數,例如每層學習率和初始化規模。所選的超參數在不同的批次大小、模型寬度、深度和訓練標記值之間遷移特性良好。Llama 4 通過對200種語言進行預訓練,其中包括100多種語言,每種語言的令牌超過10億個,總體上是Llama 3的10倍。 Llama 4模型群的推出標誌著AI研究和應用的變革時刻。Llama 4結合了多模態智能、高效的MoE 架構、廣泛的預訓練和強大的訓練後策略,樹立了新的基準。 (魯班模錘)
1000萬上下文+2880億參數的Llama4,卻讓DeepSeek們鬆了一口氣
Llama4 來了。4月5日,Meta發佈了外界期待許久的Llama4系列開源模型,目前它包括Llama 4 Scout、Llama 4 Maverick和Llama 4 Behemoth。三種模型對應不同的使用需求,簡單來說:Llama 4 Scout是可以在單張H100上跑的多模態MoE模型,Llama 4 Maverick是擊敗了GPT-4o 和 Gemini 2.0,比DeepSeek v3小但編碼和推理能力匹配的“最佳模型”,還有一個即將發佈的、隱藏在後為所有Llama4系列提供能力的2880億活躍參數“巨獸”模型Llama 4 Behemoth。根據它官方發佈的介紹,此次Llama4有幾個重要的技術亮點。MoE架構:此次是Llama首次採用混合專家架構,任務執行時僅啟動部分參數(如Maverick總參數4000億,活躍參數170億),顯著提升訓練和推理效率。多模態融合:早期融合(Early Fusion)策略統一處理文字、圖像、視訊,突破傳統多模態模型的分階段處理限制。超長上下文:Scout支援1000萬Token上下文窗口(約2000萬字文字或20小時視訊),通過iRoPE架構實現“短序列訓練,長序列泛化”。部署上,Scout支援單張H100 GPU運行(Int4量化後),Maverick需H100 DGX叢集,Behemoth則誇張地使用了32000塊GPU訓練。後訓練策略:採用“輕量級SFT → 線上RL → 輕量級DPO”流程,減少對齊約束,增強模型探索能力。 引入“自我批判式資料篩選”,利用早期模型Check point檢查點過濾低品質訓練樣本,提升最終性能。由於Behemoth這個巨大參數的模型此次並沒有正式發佈,另外兩個模型並沒有太過讓人震驚的突破——尤其在刷新評測榜單這件事已經沒那麼重要的今天,人們對Llama4的期待在於它的技術思路上是否有新玩意。從目前官方給的說明來看,它自己總結的幾個重要的創新在於:原生多模態的預訓練融合方法Llama 4 模型設計為原生多模態,通過早期融合(early fusion)無縫整合文字和視覺標記到統一的模型主幹中。早期融合是一大進步,使 Llama 能夠聯合預訓練大量未標記的文字、圖像和視訊資料。Llama 還改進了 Llama 4 的視覺編碼器——基於 MetaCLIP——但與凍結的 Llama 模型聯合訓練,以更好地和LLM結合。最佳化MoE專家超參數設定的MetaP;Llama 開發了一種新訓練技術 MetaP,能夠可靠設定關鍵模型超參數,如每層學習率和初始化規模。Llama 發現所選超參數在不同batch size、模型寬度、深度和訓練token數中可以很好的匹配。Llama 4 通過在200種語言上預訓練(包括超過100種每種超過10億token的語言),總體的多語言訓練token比 Llama 3 多10倍。對注意力機製做改進,從而突破上下文能力的iRoPE架構;Llama 4 架構的一個關鍵創新是使用了交錯注意力層,且不使用位置嵌入(positional embeddings)。此外,我們還採用了推理時注意力溫度縮放( inference time temperature scaling of attention)來增強長度和泛化。我們將這種架構稱為 iRoPE 架構,其中“i”代表“交錯”注意力層,突出了支援“無限”上下文長度的長期目標,“RoPE”則指在大多數層中使用的旋轉位置嵌入。SFT、RL和DPO使用搭配上的新配方在 Llama 4 中,Llama 通過採用不同方法重構了後訓練流程:輕量級監督微調(SFT) > 線上強化學習(RL) > 輕量級直接偏好最佳化(DPO)。關鍵經驗是,SFT和DPO可能過度約束模型,限制線上RL階段的探索,導致推理、編碼和數學領域的次優精準性。後訓練一個擁有2兆參數的模型也是一大挑戰,需要 Llama 徹底改造配方,從資料規模開始。為最大化性能,Llama 不得不修剪95%的SFT資料(相比小型模型的50%),以實現質量和效率的必要關注。為2兆參數模型擴展RL還需要 Llama 改造底層RL基礎設施,因其規模前所未有。Llama 最佳化了MoE平行設計以提高速度,加快了迭代。Llama 開發了一個完全非同步的線上RL訓練框架,增強了靈活性。與犧牲計算記憶體以在記憶體中堆疊所有模型的現有分佈式訓練框架相比,Llama 的新基礎設施支援將不同模型靈活分配到單獨GPU上,根據計算速度平衡多個模型的資源。這一創新使訓練效率比前幾代提高了約10倍。這些創新與大家對今天開源模型競賽的預期相比,可能會略微讓人失望。原生多模態的做法基本依然是行業的常規操作——把其他模態與最強的語言模態在token層面上統一;MetaP背後強調的不同尺寸的高效轉化,讓人想到諸如面壁智能提出的“densing law”,如何在小一點的參數上做實驗,預測出更大參數的表現;對注意力的改進也在過去幾個月有諸多嘗試,無論是月之暗面的MoBA,DeepSeek的NSA還是MiniMax-01對Lighting Attention的激進的融合,似乎Meta的嘗試並沒有比這些帶來更徹底的效果;而在SFT,RL和DPO的“煉丹”上,也反而讓DeepSeek R1的更純粹的RL方法顯得更簡潔優雅。與Llama過往作為開源執旗者時相比,通過開源給社區提供對抗閉源模型強大的新方法的意味少了很多,結合其他更徹底的開源模型公佈的各種技術來快速交出一個作品來先跟上領先者的意味更強了。這次的模型與此前Llama2和Llama3發佈時的影響完全不同,它不是碾壓式領先的發佈,也許之後的Behemoth才是主菜,這次只是開胃菜。但目前看來,Behemoth的最大亮點可能還是在它背後的算力資源,Meta表示,Behemoth使用FP8和32K GPU訓練,實現了390 TFLOPs/GPU。這些都在提示這一次Llama4發佈的倉促。這次Llama在行業對推理模型需求爆炸,對很看重程式設計能力的AI Agent類產品興趣濃厚的時候,沒有先發佈推理模型,而是繼續通過做大底座模型來提高推理和程式設計能力。在通過Scout強調部署便利的同時,卻又沒有可以在本地運行的尺寸的模型。整體看來,Llama4像是Meta先給自己一個“台階”——在DeepSeek爆火之前,它堅持不用MoE架構,這次算是完成了糾錯。另外有意思的是,在模型發佈後,行業裡活躍的幾家競對也“討論”起了它的發佈時間——這次發佈選擇放在了周末。有人發現它在Github上最初提交的計畫時間是周一,以至於不少人懷疑Meta是為了避免下周被某個更強模型的發佈蓋過風頭。有人猜測DeepSeek ,Qwen和DeepMind的更強模型都會在下周出現,而Llama4目前的實力已經無法與它們爭奪注意力。“在周六發佈有一個好處,至少沒人在當天會想截胡你。”Gemini團隊活躍的研究者Logan Kilpatrick調侃道。千問的林俊暘則回覆了一個“hahahah”。在Llama3領先開源競爭的時候,你很難想像它的對手會如此戲虐地做出反應。從領先變回追趕者,Meta AI看來有得忙了。 (矽星人Pro)