機器之心發(fā)布

隨著 ChatGPT、Gemini、DeepSeek-V3、Kimi-K2 等主流大模型紛紛采用混合專家架構(gòu)（Mixture-of-Experts, MoE）及專家并行策略（Expert Parallelism, EP），MoE 技術(shù)已在產(chǎn)業(yè)應(yīng)用中逐漸成為主流。

與此同時，以代碼智能體、Cursor 類對話式 IDE 為代表的新型應(yīng)用，一方面顯著推高了用戶請求規(guī)模，另一方面大幅拉長了單次推理的上下文長度，兩者均呈現(xiàn)出一個數(shù)量級以上的增長。在 MoE 架構(gòu)下，這種變化不僅線性放大了計算開銷，還顯著增加了跨專家的通信與調(diào)度成本，使得整體系統(tǒng)壓力接近一個數(shù)量級提升，并在規(guī)?；?wù)場景中進一步被放大。

MoE 模型因其結(jié)構(gòu)上的稀疏性與專家并行特性，天然引入了頻繁且規(guī)模龐大的全局分布式數(shù)據(jù)交換。而當(dāng)前主流通信庫及解決方案（如 DeepEP）仍基于 “通信與數(shù)據(jù)布局解耦” 的傳統(tǒng)設(shè)計假設(shè)，難以高效應(yīng)對實際生產(chǎn)中的跨設(shè)備、非連續(xù)、動態(tài)重排的數(shù)據(jù)訪問模式，在高并發(fā)、長上下文與大規(guī)模專家配置的場景下，DeepEP 性能已逐漸趨近瓶頸，直接制約了 MoE 大模型的持續(xù)落地、系統(tǒng)穩(wěn)定擴展與經(jīng)濟性運行。

• 論文地址：https://www.arxiv.org/abs/2512.22036
• 開源地址：https://github.com/infinigence/FUSCO

基于此，無問芯穹聯(lián)合清華大學(xué)、中關(guān)村學(xué)院、上海交大及南加州大學(xué)，面向 MoE 模型結(jié)構(gòu)和 EP 并行策略場景，推出高效通信庫 “FUSCO”。

這是一種全新的融合式通信優(yōu)化路徑：將通信過程與數(shù)據(jù)底層布局主動協(xié)同，在數(shù)據(jù)搬運的同時完成布局轉(zhuǎn)換，從而徹底消除冗余的數(shù)據(jù)重排操作。

這一設(shè)計將融合優(yōu)化的邊界從傳統(tǒng)的計算算子之間融合，拓展至通信與數(shù)據(jù)操作之間的跨層融合，揭示了大模型訓(xùn)練與推理中一個此前未被充分挖掘的優(yōu)化新空間。在此基礎(chǔ)上，F(xiàn)USCO 可自動實現(xiàn)負(fù)載均衡與冗余通信消除，并在不同 GPU 架構(gòu)與網(wǎng)絡(luò)拓?fù)湎卤３至己玫目梢浦残?，為大?guī)模模型的端到端執(zhí)行提供了一種更具系統(tǒng)性的融合優(yōu)化路徑。

實驗表明，相較于 NCCL 和 DeepSeek 的 DeepEP 通信庫，F(xiàn)USCO 的通信性能可最高分別提升 3.84 倍和 2.01 倍。且在實際部署場景中，隨著并發(fā)請求數(shù)和文本長度（例如達(dá)到 2048K tokens）的增加，其性能優(yōu)勢將進一步擴大。這為基于 MoE 模型的推理、訓(xùn)練的各類 Agent 場景提供了有力支持。

背景

MoE 專家并行架構(gòu)下的通信與數(shù)據(jù)重排瓶頸

在大規(guī)模 MoE 模型的訓(xùn)練和推理中，單個 GPU 往往無法承載完整模型權(quán)重或處理全部 token。因而系統(tǒng)通常引入專家并行（Expert Parallelism），將不同專家分布在多個 GPU 上，以提升計算吞吐并擴展模型容量。盡管該策略有效提升了可擴展性，但也引入了新的性能瓶頸：token 需要在不同專家所在的 GPU 之間進行跨設(shè)備的數(shù)據(jù)重排與通信，形成分布式數(shù)據(jù)重排（Distributed Data Shuffling）過程，其典型執(zhí)行流程包括：

1. 通信前的 token 重排：根據(jù) token–expert 的映射關(guān)系確定目標(biāo) GPU，并將 token 按目標(biāo) GPU 的通信布局重新排列，以滿足 All-to-All 的數(shù)據(jù)組織要求；
2. 跨 GPU 的 All-to-All 通信：重排后的 token 通過 All-to-All 通信發(fā)送至對應(yīng)專家所在的 GPU；
3. 通信后的 token 重排：每個 GPU 根據(jù)其本地承載的專家集合，對接收到的 token 進一步按專家進行排列，并完成對應(yīng)專家的計算；
4. 鏡像式的合并 (Combine) 過程：在專家計算完成后，系統(tǒng)按與上述過程相反的順序，依次執(zhí)行本地逆向重排、All-to-All 通信以及最終的 token 順序恢復(fù)，以保證輸出與原始 token 順序一致。

傳統(tǒng)集合通信庫遵循 “通信與數(shù)據(jù)布局解耦” 的設(shè)計范式：通信被視為對連續(xù)數(shù)據(jù)塊的被動搬運，而數(shù)據(jù)在模型執(zhí)行過程中所固有的布局語義（如視圖變換、維度重排與切片關(guān)系）通常被忽略。這一抽象雖然簡化了接口，卻在大模型訓(xùn)練與推理中引入了大量隱式的中間張量重排與內(nèi)存拷貝，成為制約端到端效率的重要瓶頸。

隨著專家并行規(guī)模的擴大，上述過程的開銷呈上升趨勢。訓(xùn)練和推理的吞吐雖然隨更多設(shè)備的參與而提升，但分布式數(shù)據(jù)重排在端到端總延遲中所占比例總體上不斷增加。

這一現(xiàn)象主要源于隨著專家分布在更多設(shè)備上，token 在設(shè)備間的傳輸量增加，同時全局同步成本也隨之上升。每個 token 都必須在參與 GPU 間交換和重排，這相對于計算增加了額外的延遲。盡管專家內(nèi)部的前饋計算仍然高效，但在更高的專家并行度和更大集群規(guī)模下，分布式數(shù)據(jù)重排已成為端到端性能的重要瓶頸。

為量化這一過程的開銷，我們進一步對一次通信前后的數(shù)據(jù)重排與通信本身進行了細(xì)致分析。以 32 MB 數(shù)據(jù)為例，使用 PyTorch 的 index_select 算子模擬本地重排操作，并分別在機內(nèi)（NVLink）和跨機（RoCE）環(huán)境下，結(jié)合 NCCL 的 send/recv 原語測量通信延遲。

結(jié)果顯示，重排操作在總 shuffle 時間中的占比分別高達(dá) 68.8%（機內(nèi)）和 25%（跨機）。這說明 MoE 中的數(shù)據(jù)移動瓶頸不僅來自網(wǎng)絡(luò)帶寬限制，還受限于內(nèi)存綁定的數(shù)據(jù)重排操作。并且，隨著互聯(lián)效率不斷提升，通信本身變得更快，若數(shù)據(jù)重排開銷保持不變，其在總執(zhí)行時間中的占比將更突出。

此外，傳統(tǒng)的 All-to-All 通信對 token 冗余和網(wǎng)絡(luò)層次缺乏感知。在實際 MoE 工作負(fù)載中，同一 token 可能被路由到同一節(jié)點上不同 GPU 的多個專家，但在當(dāng)前通信實現(xiàn)中，這些重復(fù) token 會被序列化發(fā)送多次，造成帶寬浪費和通信效率下降?，F(xiàn)有優(yōu)化方案如 DeepEP 雖然引入了跨機去重，但高度依賴特定網(wǎng)絡(luò)硬件，部署范圍有限，且未消除通信前后的數(shù)據(jù)重排，在通用 MoE 場景中的優(yōu)化效果仍有限。

FUSCO 設(shè)計解析

如何讓大規(guī)模的分布式數(shù)據(jù)交換既高效又輕量？

FUSCO 的核心思路在于認(rèn)識到：數(shù)據(jù)重排本質(zhì)上就是一次數(shù)據(jù)布局的變換，而通信本身已經(jīng)定義了數(shù)據(jù)該如何被拆分、發(fā)送和放置。因此，與其在通信前后引入額外的布局調(diào)整，不如順著通信過程本身來完成布局變換。

基于這一觀察，我們提出了一種數(shù)據(jù)與通信協(xié)同設(shè)計的方法，在數(shù)據(jù)傳輸?shù)倪^程中同步完成布局變換，從而避免將數(shù)據(jù)通信與數(shù)據(jù)重排變換分離執(zhí)行的傳統(tǒng)做法。每個數(shù)據(jù)段（LLM 中的 token）在傳輸?shù)倪^程中即完成排列和發(fā)送，從而既減少了額外拷貝，也最大化利用了 GPU 和網(wǎng)絡(luò)帶寬。

融合重排的通信：讓數(shù)據(jù)在傳輸中一步到位完成布局變換

為實現(xiàn)數(shù)據(jù)在傳輸過程中即完成重排，FUSCO 打破了將重排視為獨立步驟的傳統(tǒng)思路，從上到下協(xié)同設(shè)計通信接口和底層算子：接口層負(fù)責(zé)精確表達(dá)數(shù)據(jù) “從哪里來、到哪里去” 的布局語義，而算子層則負(fù)責(zé)在一次通信執(zhí)行路徑中高效地落實這些語義。

通過將布局描述與通信執(zhí)行緊密綁定，FUSCO 構(gòu)建了一條從接口到算子的貫通路徑，使數(shù)據(jù)重排不再是獨立的前后處理，而是被自然地融合進通信過程本身。

（1）通信接口設(shè)計

在專家并行中，各個設(shè)備上的原始數(shù)據(jù)通常是一個大的連續(xù)張量，由多個 token 組成。經(jīng)過 MoE 路由后，不同 token 可能被分配到不同的設(shè)備，而路由到同一設(shè)備的 token 往往在張量中呈離散分布，而非連續(xù)的一塊。每個 token 的大小通常在 4KB 到 14KB 之間，需要發(fā)送到該設(shè)備上的不同專家。

所謂 “數(shù)據(jù)重排”，本質(zhì)上是在通信前，將這些離散 token 按目標(biāo)設(shè)備和對應(yīng)專家進行組織，并在通信完成后將它們正確地放置到各自的目標(biāo)位置。

為了簡化討論，先考慮兩個設(shè)備之間的一次單向傳輸。為精確描述這些離散數(shù)據(jù)的布局，我們將通信數(shù)據(jù)抽象為一組邏輯段。每個段對應(yīng)內(nèi)存中一小段連續(xù)數(shù)據(jù)，F(xiàn)USCO 用一個稱為段描述符的數(shù)據(jù)結(jié)構(gòu)記錄其起始地址。在通信過程中，一端并不直接操作原始張量，而是根據(jù)連續(xù)的段描述符序列，從張量的對應(yīng)位置讀取或?qū)懭霐?shù)據(jù)，從而實現(xiàn)對離散 token 的精確訪問和操作。

在發(fā)送端，這個描述符序列規(guī)定了通信負(fù)載如何從源張量中被逐段讀取；在接收端，對應(yīng)的描述符序列則明確了每一段數(shù)據(jù)在目標(biāo)內(nèi)存中的落點。

基于上述段描述符序列的創(chuàng)新設(shè)計，F(xiàn)USCO 以兩個互補的通語實現(xiàn)其通信接口：

• gather-send：發(fā)送端依據(jù)本地的段描述符序列，按順序從多個不連續(xù)位置讀取段數(shù)據(jù)并發(fā)起發(fā)送；
• scatter-recv：接收端依據(jù)自身的段描述符序列，將接收到的段數(shù)據(jù)直接寫入目標(biāo)布局中的對應(yīng)位置。

這兩個原語在語義上是一一對應(yīng)的：每一個邏輯段在發(fā)送端和接收端都有明確匹配的描述符，從而保證數(shù)據(jù)在端到端傳輸過程中被精確放置，無需任何額外的中間緩沖或后處理重排。

（2） 高效通信算子

盡管前面通過描述信息已經(jīng)可以精確表達(dá) “哪些 token 從哪里來、到哪里去”，但一個更現(xiàn)實的問題隨之而來：在引入細(xì)粒度重排語義之后，通信還能否保持原有的吞吐效率？

FUSCO 的答案是：通過一套流水線化的執(zhí)行方式，將布局整理與數(shù)據(jù)傳輸緊密地綁定在一起。

在機內(nèi)通信場景下，發(fā)送端和接收端位于同一臺機器，F(xiàn)USCO 直接使用 GPU 到 GPU 的點對點拷貝。關(guān)鍵在于，描述信息的解析被嵌入到拷貝路徑之中：GPU 在執(zhí)行數(shù)據(jù)拷貝的同時，按照描述信息從分散的位置讀取數(shù)據(jù)，并直接寫入目標(biāo)布局對應(yīng)的位置。整個過程中不會引入額外的中間緩沖或額外的內(nèi)存遍歷。

跨機通信則需要經(jīng)過網(wǎng)卡，而要充分利用網(wǎng)絡(luò)帶寬，必須持續(xù)提供足夠大的發(fā)送數(shù)據(jù)。為此，F(xiàn)USCO 并不會把每個數(shù)據(jù)段單獨進行一次發(fā)送，而是將多段數(shù)據(jù)組織成較大的發(fā)送單元，每個發(fā)送單元包含多個邏輯段。

FUSCO 跨機通信流水線執(zhí)行路徑

在此基礎(chǔ)上，F(xiàn)USCO 將跨機通信組織為一條清晰的流水線執(zhí)行路徑：GPU 作為生產(chǎn)者，按照描述信息依次收集數(shù)據(jù)、完成布局整理，并將結(jié)果寫入發(fā)送緩沖區(qū)；網(wǎng)卡作為消費者，一旦發(fā)現(xiàn)緩沖區(qū)中有就緒的數(shù)據(jù)單元，便立即發(fā)起 RDMA 傳輸。

由于單個發(fā)送單元的網(wǎng)絡(luò)傳輸時間通常長于 GPU 準(zhǔn)備該單元所需的時間，GPU 側(cè)的內(nèi)存操作可以穩(wěn)定地與網(wǎng)絡(luò)傳輸重疊，使通信鏈路始終保持高利用率。

通過這種設(shè)計，數(shù)據(jù)重排不再是通信前后的附加步驟，而是被直接嵌入到一次點對點通信的執(zhí)行過程中完成。在引入靈活重排能力的同時，F(xiàn)USCO 依然能夠維持與高性能通信庫相當(dāng)?shù)膸捫省?/strong>

通信調(diào)度和策略：跨機優(yōu)化與負(fù)載均衡的 token 傳輸

FUSCO 的通信調(diào)度優(yōu)化圍繞兩種數(shù)據(jù)重排操作展開：gather-send 和 scatter-recv。其核心目標(biāo)是在消除重排的基礎(chǔ)上，減少跨機傳輸量并平衡各設(shè)備通信負(fù)載。

為此，系統(tǒng)會先生成一份詳細(xì)的執(zhí)行計劃，將 MoE 的 token 路由信息轉(zhuǎn)化為可直接執(zhí)行的低層指令。計劃中明確了每個 token 的來源、目標(biāo) GPU 以及目標(biāo)節(jié)點的位置，使 gather-send 和 scatter-recv 能直接利用這些元數(shù)據(jù)，無需在通信前、通信中、通信后進行額外的數(shù)據(jù)重排操作。

FUSCO 通信調(diào)度策略

在生成執(zhí)行計劃時，F(xiàn)USCO 首先考慮了跨節(jié)點通信的效率問題。直接將每個 token 發(fā)送到目標(biāo)節(jié)點的所有 GPU 會導(dǎo)致重復(fù)傳輸。為解決這一問題，F(xiàn)USCO 為每個發(fā)送 GPU 在每個目標(biāo)節(jié)點指定一個 “轉(zhuǎn)發(fā) GPU”：當(dāng)某個 GPU 需要向同一節(jié)點的多個 GPU 發(fā)送相同 token 時，轉(zhuǎn)發(fā) GPU 會先接收發(fā)送端的數(shù)據(jù)，然后通過節(jié)點內(nèi)部高速鏈路（如 NVLink）將數(shù)據(jù)分發(fā)給該節(jié)點的其他 GPU。這樣不僅減少了跨節(jié)點傳輸，也充分利用了節(jié)點內(nèi)的高速網(wǎng)絡(luò)，讓數(shù)據(jù)流動更順暢。

同時，F(xiàn)USCO 還考慮了轉(zhuǎn)發(fā) GPU 的選擇。如果總是集中在少數(shù) GPU 上，容易形成網(wǎng)絡(luò)熱點。FUSCO 通過將轉(zhuǎn)發(fā) GPU 組織成通信組來解決這一問題，確保高負(fù)載 GPU 分散在不同組中，實現(xiàn)跨節(jié)點負(fù)載均衡。這樣每塊 GPU 都不會因數(shù)據(jù)過多而成為瓶頸，整個網(wǎng)絡(luò)的利用率也更高。

總結(jié)來看，F(xiàn)USCO 的通信調(diào)度策略主要通過三方面提升效率：

1. 精確執(zhí)行計劃：每個 token 直接到達(dá)目標(biāo) GPU 的對應(yīng)內(nèi)存位置，無需額外重排。
2. 分層轉(zhuǎn)發(fā)：跨節(jié)點只傳輸一份，節(jié)點內(nèi)快速分發(fā)，減少重復(fù)傳輸。
3. 在線負(fù)載均衡：在運行時根據(jù)實際 MoE 路由流量動態(tài)構(gòu)建通信組，高負(fù)載 GPU 均勻分布。

我們基于 NCCL 實現(xiàn)了 FUSCO，在保持與 NCCL 相同網(wǎng)絡(luò)兼容性的同時，復(fù)用了其高效通信能力，讓 FUSCO 可以專注于算法優(yōu)化。FUSCO 為 MoE 層提供了簡單直觀的 dispatch/combine 接口，可無縫接入現(xiàn)有 LLM 訓(xùn)練和推理框架。

不同于 DeepEP 僅能在特定網(wǎng)絡(luò)環(huán)境（ibgda, NVLink, RDMA）下工作，F(xiàn)USCO 能在多種網(wǎng)絡(luò)環(huán)境下高效運行，無需針對網(wǎng)絡(luò)做額外調(diào)優(yōu)。

簡而言之，F(xiàn)USCO 可以作為 MoE 框架中 AlltoAll 通信的高效解決方案，同時兼顧性能與易用性。

結(jié)果與分析

FUSCO 的性能與優(yōu)勢

通信性能：完全消除 MoE 模型通信數(shù)據(jù)重排開銷，效率 2 倍優(yōu)于 DeepEP

在應(yīng)用上，與現(xiàn)有的通信庫相比，F(xiàn)USCO 的最大特點在于完全消除了 MoE 模型通信中的數(shù)據(jù)重排開銷，并在此基礎(chǔ)上實現(xiàn)跨節(jié)點 token 去重和節(jié)點內(nèi)高速分發(fā)，從而顯著提升通信效率。系統(tǒng)適配主流 MoE 訓(xùn)練和推理框架和 GPU 架構(gòu)，在各種典型的 MoE 路由流量場景都能夠穩(wěn)定降低延遲和提升吞吐。

在量化評測中，我們構(gòu)造了三種具有代表性的 MoE 通信流量配置進行測試：

• 第一種是真實推理流量，直接采用大模型推理過程中實際產(chǎn)生的 MoE 路由結(jié)果，能夠反映真實場景下的通信特征；
• 第二種是單節(jié)點路由流量，即一個 token 被路由到的 topk 個 expert 都在同一節(jié)點上，此時跨節(jié)點只需要傳輸一份數(shù)據(jù)，主要考察系統(tǒng)對冗余跨節(jié)點通信的消除能力；
• 第三種是負(fù)載不均衡流量，不同 GPU 間通信量差異顯著，用于模擬熱點 GPU 和通信傾斜嚴(yán)重的極端情況，重點評估系統(tǒng)的負(fù)載均衡能力。

這三種配置均使用 64 張 GPU 進行性能測試，分別測試每卡文本長度 4K/8K/16K/32K 的情況，總文本長度最大可達(dá) 2048K。

真實通信數(shù)據(jù)重排負(fù)載下的性能對比（64 GPUs，文本長度可達(dá) 32K*64，下同）

每個 token 僅會被路由到一個設(shè)備上的多個 expert 下的性能對比

設(shè)備之間負(fù)載不均衡情況下的性能對比

實驗結(jié)果表明，在上述三種典型流量配置下，FUSCO 相比 NCCL 和 DeepEP 均能取得更高的通信效率。相較于 NCCL 和 DeepSeek 的 DeepEP 通信庫，F(xiàn)USCO 的通信性能最高可分別提升 3.84 倍和 2.01 倍，而且文本長度越長加速越明顯。

無論是在真實推理環(huán)境、跨節(jié)點通信最小化的場景，還是存在嚴(yán)重負(fù)載不均衡的情況下，FUSCO 都能穩(wěn)定降低通信開銷，為 MoE 模型的訓(xùn)練與推理提供更加高效、可靠的通信支持。

端到端性能：訓(xùn)練與推理效率全面提升，最高 1.39 倍優(yōu)化

在全模型訓(xùn)練和推理中，F(xiàn)USCO 同樣展現(xiàn)出明顯優(yōu)勢。我們在 64 張 GPU 上對 Qwen3-235B-A22B 和 DeepSeek-V3 兩種代表性 MoE 模型進行了評測，涵蓋模型單輪訓(xùn)練時間和推理首 token 響應(yīng)時間。

FUSCO 帶來的端到端訓(xùn)練與推理的性能提升

結(jié)果顯示，在訓(xùn)練任務(wù)中，F(xiàn)USCO 相較于 NCCL 性能最高提升 1.39 倍，相較于 DeepEP 性能最高提升 1.19 倍 ；在推理任務(wù)中，F(xiàn)USCO 相較于 NCCL 性能最高提升 1.25 倍，相較于 DeepEP 性能最高提升 1.16 倍。且在實際部署中，模型規(guī)模越大，性能提升越顯著。

總結(jié)

FUSCO 通過將 MoE 模型的 token 路由信息直接轉(zhuǎn)化為可執(zhí)行的 gather-send 與 scatter-recv 通信原語策略，徹底消除了傳統(tǒng)通信前后的數(shù)據(jù)重排開銷。

在多節(jié)點 64 GPU 測試中，相較于 NCCL 和 DeepEP，F(xiàn)USCO 的通信性能分別提升了 3.84 倍和 2.01 倍，同時端到端性能增幅最高達(dá) 40%。

無問芯穹這一創(chuàng)新方案不僅為大規(guī)模 MoE 模型提供了可擴展、低成本的通信支持，為大規(guī)模 MoE 模型的通信優(yōu)化提供了可驗證的創(chuàng)新示范。更有力推動了面向 Agent 的硬件效率潛能的釋放，加速智能體的規(guī)模化高效落地。

相關(guān)代碼和使用示例現(xiàn)已開源，歡迎在實際項目中下載測試與應(yīng)用。

• 開源地址：https://github.com/infinigence/FUSCO
• 論文鏈接：https://www.arxiv.org/abs/2512.22036