![]()
機器之心發布
隨著 ChatGPT、Gemini、DeepSeek-V3、Kimi-K2 等主流大模型紛紛采用混合專家架構(Mixture-of-Experts, MoE)及專家并行策略(Expert Parallelism, EP),MoE 技術已在產業應用中逐漸成為主流。
與此同時,以代碼智能體、Cursor 類對話式 IDE 為代表的新型應用,一方面顯著推高了用戶請求規模,另一方面大幅拉長了單次推理的上下文長度,兩者均呈現出一個數量級以上的增長。在 MoE 架構下,這種變化不僅線性放大了計算開銷,還顯著增加了跨專家的通信與調度成本,使得整體系統壓力接近一個數量級提升,并在規模化服務場景中進一步被放大。
MoE 模型因其結構上的稀疏性與專家并行特性,天然引入了頻繁且規模龐大的全局分布式數據交換。而當前主流通信庫及解決方案(如 DeepEP)仍基于 “通信與數據布局解耦” 的傳統設計假設,難以高效應對實際生產中的跨設備、非連續、動態重排的數據訪問模式,在高并發、長上下文與大規模專家配置的場景下,DeepEP 性能已逐漸趨近瓶頸,直接制約了 MoE 大模型的持續落地、系統穩定擴展與經濟性運行。
![]()
- 論文地址:https://www.arxiv.org/abs/2512.22036
- 開源地址:https://github.com/infinigence/FUSCO
基于此,無問芯穹聯合清華大學、中關村學院、上海交大及南加州大學,面向 MoE 模型結構和 EP 并行策略場景,推出高效通信庫 “FUSCO”。
這是一種全新的融合式通信優化路徑:將通信過程與數據底層布局主動協同,在數據搬運的同時完成布局轉換,從而徹底消除冗余的數據重排操作。
這一設計將融合優化的邊界從傳統的計算算子之間融合,拓展至通信與數據操作之間的跨層融合,揭示了大模型訓練與推理中一個此前未被充分挖掘的優化新空間。在此基礎上,FUSCO 可自動實現負載均衡與冗余通信消除,并在不同 GPU 架構與網絡拓撲下保持良好的可移植性,為大規模模型的端到端執行提供了一種更具系統性的融合優化路徑。
實驗表明,相較于 NCCL 和 DeepSeek 的 DeepEP 通信庫,FUSCO 的通信性能可最高分別提升 3.84 倍和 2.01 倍。且在實際部署場景中,隨著并發請求數和文本長度(例如達到 2048K tokens)的增加,其性能優勢將進一步擴大。這為基于 MoE 模型的推理、訓練的各類 Agent 場景提供了有力支持。
背景
MoE 專家并行架構下的通信與數據重排瓶頸
在大規模 MoE 模型的訓練和推理中,單個 GPU 往往無法承載完整模型權重或處理全部 token。因而系統通常引入專家并行(Expert Parallelism),將不同專家分布在多個 GPU 上,以提升計算吞吐并擴展模型容量。盡管該策略有效提升了可擴展性,但也引入了新的性能瓶頸:token 需要在不同專家所在的 GPU 之間進行跨設備的數據重排與通信,形成分布式數據重排(Distributed Data Shuffling)過程,其典型執行流程包括:
- 通信前的 token 重排:根據 token–expert 的映射關系確定目標 GPU,并將 token 按目標 GPU 的通信布局重新排列,以滿足 All-to-All 的數據組織要求;
- 跨 GPU 的 All-to-All 通信:重排后的 token 通過 All-to-All 通信發送至對應專家所在的 GPU;
- 通信后的 token 重排:每個 GPU 根據其本地承載的專家集合,對接收到的 token 進一步按專家進行排列,并完成對應專家的計算;
- 鏡像式的合并 (Combine) 過程:在專家計算完成后,系統按與上述過程相反的順序,依次執行本地逆向重排、All-to-All 通信以及最終的 token 順序恢復,以保證輸出與原始 token 順序一致。
傳統集合通信庫遵循 “通信與數據布局解耦” 的設計范式:通信被視為對連續數據塊的被動搬運,而數據在模型執行過程中所固有的布局語義(如視圖變換、維度重排與切片關系)通常被忽略。這一抽象雖然簡化了接口,卻在大模型訓練與推理中引入了大量隱式的中間張量重排與內存拷貝,成為制約端到端效率的重要瓶頸。
![]()
隨著專家并行規模的擴大,上述過程的開銷呈上升趨勢。訓練和推理的吞吐雖然隨更多設備的參與而提升,但分布式數據重排在端到端總延遲中所占比例總體上不斷增加。
這一現象主要源于隨著專家分布在更多設備上,token 在設備間的傳輸量增加,同時全局同步成本也隨之上升。每個 token 都必須在參與 GPU 間交換和重排,這相對于計算增加了額外的延遲。盡管專家內部的前饋計算仍然高效,但在更高的專家并行度和更大集群規模下,分布式數據重排已成為端到端性能的重要瓶頸。
為量化這一過程的開銷,我們進一步對一次通信前后的數據重排與通信本身進行了細致分析。以 32 MB 數據為例,使用 PyTorch 的 index_select 算子模擬本地重排操作,并分別在機內(NVLink)和跨機(RoCE)環境下,結合 NCCL 的 send/recv 原語測量通信延遲。
![]()
結果顯示,重排操作在總 shuffle 時間中的占比分別高達 68.8%(機內)和 25%(跨機)。這說明 MoE 中的數據移動瓶頸不僅來自網絡帶寬限制,還受限于內存綁定的數據重排操作。并且,隨著互聯效率不斷提升,通信本身變得更快,若數據重排開銷保持不變,其在總執行時間中的占比將更突出。
此外,傳統的 All-to-All 通信對 token 冗余和網絡層次缺乏感知。在實際 MoE 工作負載中,同一 token 可能被路由到同一節點上不同 GPU 的多個專家,但在當前通信實現中,這些重復 token 會被序列化發送多次,造成帶寬浪費和通信效率下降。現有優化方案如 DeepEP 雖然引入了跨機去重,但高度依賴特定網絡硬件,部署范圍有限,且未消除通信前后的數據重排,在通用 MoE 場景中的優化效果仍有限。
FUSCO 設計解析
如何讓大規模的分布式數據交換既高效又輕量?
FUSCO 的核心思路在于認識到:數據重排本質上就是一次數據布局的變換,而通信本身已經定義了數據該如何被拆分、發送和放置。因此,與其在通信前后引入額外的布局調整,不如順著通信過程本身來完成布局變換。
基于這一觀察,我們提出了一種數據與通信協同設計的方法,在數據傳輸的過程中同步完成布局變換,從而避免將數據通信與數據重排變換分離執行的傳統做法。每個數據段(LLM 中的 token)在傳輸的過程中即完成排列和發送,從而既減少了額外拷貝,也最大化利用了 GPU 和網絡帶寬。
![]()
融合重排的通信:讓數據在傳輸中一步到位完成布局變換
為實現數據在傳輸過程中即完成重排,FUSCO 打破了將重排視為獨立步驟的傳統思路,從上到下協同設計通信接口和底層算子:接口層負責精確表達數據 “從哪里來、到哪里去” 的布局語義,而算子層則負責在一次通信執行路徑中高效地落實這些語義。
通過將布局描述與通信執行緊密綁定,FUSCO 構建了一條從接口到算子的貫通路徑,使數據重排不再是獨立的前后處理,而是被自然地融合進通信過程本身。
(1)通信接口設計
在專家并行中,各個設備上的原始數據通常是一個大的連續張量,由多個 token 組成。經過 MoE 路由后,不同 token 可能被分配到不同的設備,而路由到同一設備的 token 往往在張量中呈離散分布,而非連續的一塊。每個 token 的大小通常在 4KB 到 14KB 之間,需要發送到該設備上的不同專家。
所謂 “數據重排”,本質上是在通信前,將這些離散 token 按目標設備和對應專家進行組織,并在通信完成后將它們正確地放置到各自的目標位置。
為了簡化討論,先考慮兩個設備之間的一次單向傳輸。為精確描述這些離散數據的布局,我們將通信數據抽象為一組邏輯段。每個段對應內存中一小段連續數據,FUSCO 用一個稱為段描述符的數據結構記錄其起始地址。在通信過程中,一端并不直接操作原始張量,而是根據連續的段描述符序列,從張量的對應位置讀取或寫入數據,從而實現對離散 token 的精確訪問和操作。
在發送端,這個描述符序列規定了通信負載如何從源張量中被逐段讀取;在接收端,對應的描述符序列則明確了每一段數據在目標內存中的落點。
基于上述段描述符序列的創新設計,FUSCO 以兩個互補的通語實現其通信接口:
- gather-send:發送端依據本地的段描述符序列,按順序從多個不連續位置讀取段數據并發起發送;
- scatter-recv:接收端依據自身的段描述符序列,將接收到的段數據直接寫入目標布局中的對應位置。
這兩個原語在語義上是一一對應的:每一個邏輯段在發送端和接收端都有明確匹配的描述符,從而保證數據在端到端傳輸過程中被精確放置,無需任何額外的中間緩沖或后處理重排。
(2) 高效通信算子
盡管前面通過描述信息已經可以精確表達 “哪些 token 從哪里來、到哪里去”,但一個更現實的問題隨之而來:在引入細粒度重排語義之后,通信還能否保持原有的吞吐效率?
FUSCO 的答案是:通過一套流水線化的執行方式,將布局整理與數據傳輸緊密地綁定在一起。
在機內通信場景下,發送端和接收端位于同一臺機器,FUSCO 直接使用 GPU 到 GPU 的點對點拷貝。關鍵在于,描述信息的解析被嵌入到拷貝路徑之中:GPU 在執行數據拷貝的同時,按照描述信息從分散的位置讀取數據,并直接寫入目標布局對應的位置。整個過程中不會引入額外的中間緩沖或額外的內存遍歷。
跨機通信則需要經過網卡,而要充分利用網絡帶寬,必須持續提供足夠大的發送數據。為此,FUSCO 并不會把每個數據段單獨進行一次發送,而是將多段數據組織成較大的發送單元,每個發送單元包含多個邏輯段。
![]()
FUSCO 跨機通信流水線執行路徑
在此基礎上,FUSCO 將跨機通信組織為一條清晰的流水線執行路徑:GPU 作為生產者,按照描述信息依次收集數據、完成布局整理,并將結果寫入發送緩沖區;網卡作為消費者,一旦發現緩沖區中有就緒的數據單元,便立即發起 RDMA 傳輸。
由于單個發送單元的網絡傳輸時間通常長于 GPU 準備該單元所需的時間,GPU 側的內存操作可以穩定地與網絡傳輸重疊,使通信鏈路始終保持高利用率。
通過這種設計,數據重排不再是通信前后的附加步驟,而是被直接嵌入到一次點對點通信的執行過程中完成。在引入靈活重排能力的同時,FUSCO 依然能夠維持與高性能通信庫相當的帶寬效率。
通信調度和策略:跨機優化與負載均衡的 token 傳輸
FUSCO 的通信調度優化圍繞兩種數據重排操作展開:gather-send 和 scatter-recv。其核心目標是在消除重排的基礎上,減少跨機傳輸量并平衡各設備通信負載。
為此,系統會先生成一份詳細的執行計劃,將 MoE 的 token 路由信息轉化為可直接執行的低層指令。計劃中明確了每個 token 的來源、目標 GPU 以及目標節點的位置,使 gather-send 和 scatter-recv 能直接利用這些元數據,無需在通信前、通信中、通信后進行額外的數據重排操作。
![]()
FUSCO 通信調度策略
在生成執行計劃時,FUSCO 首先考慮了跨節點通信的效率問題。直接將每個 token 發送到目標節點的所有 GPU 會導致重復傳輸。為解決這一問題,FUSCO 為每個發送 GPU 在每個目標節點指定一個 “轉發 GPU”:當某個 GPU 需要向同一節點的多個 GPU 發送相同 token 時,轉發 GPU 會先接收發送端的數據,然后通過節點內部高速鏈路(如 NVLink)將數據分發給該節點的其他 GPU。這樣不僅減少了跨節點傳輸,也充分利用了節點內的高速網絡,讓數據流動更順暢。
同時,FUSCO 還考慮了轉發 GPU 的選擇。如果總是集中在少數 GPU 上,容易形成網絡熱點。FUSCO 通過將轉發 GPU 組織成通信組來解決這一問題,確保高負載 GPU 分散在不同組中,實現跨節點負載均衡。這樣每塊 GPU 都不會因數據過多而成為瓶頸,整個網絡的利用率也更高。
總結來看,FUSCO 的通信調度策略主要通過三方面提升效率:
- 精確執行計劃:每個 token 直接到達目標 GPU 的對應內存位置,無需額外重排。
- 分層轉發:跨節點只傳輸一份,節點內快速分發,減少重復傳輸。
- 在線負載均衡:在運行時根據實際 MoE 路由流量動態構建通信組,高負載 GPU 均勻分布。
我們基于 NCCL 實現了 FUSCO,在保持與 NCCL 相同網絡兼容性的同時,復用了其高效通信能力,讓 FUSCO 可以專注于算法優化。FUSCO 為 MoE 層提供了簡單直觀的 dispatch/combine 接口,可無縫接入現有 LLM 訓練和推理框架。
不同于 DeepEP 僅能在特定網絡環境(ibgda, NVLink, RDMA)下工作,FUSCO 能在多種網絡環境下高效運行,無需針對網絡做額外調優。
簡而言之,FUSCO 可以作為 MoE 框架中 AlltoAll 通信的高效解決方案,同時兼顧性能與易用性。
結果與分析
FUSCO 的性能與優勢
通信性能:完全消除 MoE 模型通信數據重排開銷,效率 2 倍優于 DeepEP
在應用上,與現有的通信庫相比,FUSCO 的最大特點在于完全消除了 MoE 模型通信中的數據重排開銷,并在此基礎上實現跨節點 token 去重和節點內高速分發,從而顯著提升通信效率。系統適配主流 MoE 訓練和推理框架和 GPU 架構,在各種典型的 MoE 路由流量場景都能夠穩定降低延遲和提升吞吐。
在量化評測中,我們構造了三種具有代表性的 MoE 通信流量配置進行測試:
- 第一種是真實推理流量,直接采用大模型推理過程中實際產生的 MoE 路由結果,能夠反映真實場景下的通信特征;
- 第二種是單節點路由流量,即一個 token 被路由到的 topk 個 expert 都在同一節點上,此時跨節點只需要傳輸一份數據,主要考察系統對冗余跨節點通信的消除能力;
- 第三種是負載不均衡流量,不同 GPU 間通信量差異顯著,用于模擬熱點 GPU 和通信傾斜嚴重的極端情況,重點評估系統的負載均衡能力。
這三種配置均使用 64 張 GPU 進行性能測試,分別測試每卡文本長度 4K/8K/16K/32K 的情況,總文本長度最大可達 2048K。
![]()
真實通信數據重排負載下的性能對比(64 GPUs,文本長度可達 32K*64,下同)
![]()
每個 token 僅會被路由到一個設備上的多個 expert 下的性能對比
![]()
設備之間負載不均衡情況下的性能對比
實驗結果表明,在上述三種典型流量配置下,FUSCO 相比 NCCL 和 DeepEP 均能取得更高的通信效率。相較于 NCCL 和 DeepSeek 的 DeepEP 通信庫,FUSCO 的通信性能最高可分別提升 3.84 倍和 2.01 倍,而且文本長度越長加速越明顯。
無論是在真實推理環境、跨節點通信最小化的場景,還是存在嚴重負載不均衡的情況下,FUSCO 都能穩定降低通信開銷,為 MoE 模型的訓練與推理提供更加高效、可靠的通信支持。
端到端性能:訓練與推理效率全面提升,最高 1.39 倍優化
在全模型訓練和推理中,FUSCO 同樣展現出明顯優勢。我們在 64 張 GPU 上對 Qwen3-235B-A22B 和 DeepSeek-V3 兩種代表性 MoE 模型進行了評測,涵蓋模型單輪訓練時間和推理首 token 響應時間。
![]()
FUSCO 帶來的端到端訓練與推理的性能提升
結果顯示,在訓練任務中,FUSCO 相較于 NCCL 性能最高提升 1.39 倍,相較于 DeepEP 性能最高提升 1.19 倍 ;在推理任務中,FUSCO 相較于 NCCL 性能最高提升 1.25 倍,相較于 DeepEP 性能最高提升 1.16 倍。且在實際部署中,模型規模越大,性能提升越顯著。
總結
FUSCO 通過將 MoE 模型的 token 路由信息直接轉化為可執行的 gather-send 與 scatter-recv 通信原語策略,徹底消除了傳統通信前后的數據重排開銷。
在多節點 64 GPU 測試中,相較于 NCCL 和 DeepEP,FUSCO 的通信性能分別提升了 3.84 倍和 2.01 倍,同時端到端性能增幅最高達 40%。
無問芯穹這一創新方案不僅為大規模 MoE 模型提供了可擴展、低成本的通信支持,為大規模 MoE 模型的通信優化提供了可驗證的創新示范。更有力推動了面向 Agent 的硬件效率潛能的釋放,加速智能體的規模化高效落地。
相關代碼和使用示例現已開源,歡迎在實際項目中下載測試與應用。
- 開源地址:https://github.com/infinigence/FUSCO
- 論文鏈接:https://www.arxiv.org/abs/2512.22036
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.