All-to-All 通訊
All-to-All 通訊（All-to-All Communication）
3 秒看懂
All-to-All 是一種”每個節點都要給其他每個節點發不同資料”的集體通訊操作。 它是 Mixture-of-Experts（MoE）模型訓練與推論的核心通訊原語——每個 token 被路由到不同 GPU 上的專家，就必須通過 All-to-All 把 token 分發出去、再把結果收回來。它對網路全對分頻寬的要求極高，是當前萬卡叢集通訊瓶頸的頭號難題之一。
3 分鐘產業解釋
為什麼 All-to-All 突然成為熱點？
2023–2025 年，MoE 架構從學術走向產業主流：Mixtral 8×7B、DeepSeek-V2/V3、Grok-1 等模型均採用稀疏 MoE 結構。MoE 模型將每一層的前饋網路（FFN）拆分為多個”專家”，分佈在不同 GPU 上。每個 token 只啟用其中 Top-K 個專家（通常 K=1 或 2），但這些專家分散在不同裝置上。
關鍵問題： 你不知道每個 token 會被路由到哪個專家——路由是動態的、資料依賴的。因此，通訊模式無法提前編排為 AllReduce 這樣規則的模式，而必須做 All-to-All：每個 GPU 把屬於其他 GPU 上專家的 token 發過去，同時接收屬於本地專家的 token。
這意味著：
- 通訊量與專家數（≈GPU數）成正比，而非固定大小；
- 流量模式是全對全的置換（permutation），網路中任意兩點間都可能同時有流量——這是對交換網路最難的流量模式；
- All-to-All 的延遲直接疊加在每個 MoE 層上，一層一次 dispatch + 一次 combine，百層模型就是兩百次。
產業鏈影響： 正因為 All-to-All，MoE 訓練對網路拓撲的要求比純資料並行/張量並行高一個量級。InfiniBand 全對分胖樹、NVSwitch 全連線、甚至光交換等前沿方案的加速落地，都與 MoE 的 All-to-All 需求直接相關。
15 分鐘專家深入
1. All-to-All 在並行策略中的位置
在分散式訓練中，三種核心並行策略對應三種截然不同的通訊模式：
| 並行策略 | 核心通訊操作 | 通訊特徵 |
|---|---|---|
| 資料並行（DP） | AllReduce / ReduceScatter + AllGather | 每個 rank 傳送相同的聚合結果，流量對稱且可預知 |
| 張量並行（TP） | AllReduce（Megatron-LM 風格） | 沿張量維度切分，通訊發生在同一層的矩陣乘前後 |
| 流水線並行（PP） | Point-to-Point Send/Recv | 只在相鄰 stage 之間傳遞 activation |
| 專家並行（EP） | All-to-All | 每個 rank 傳送不同資料給每個其他 rank，流量為全對全置換 |
關鍵區分： AllReduce 是”所有人算完自己的部分，然後求和/均攤”；All-to-All 是”每個人手裡有不同東西，要發給不同的目標”。兩者的網路行為完全不同。
2. All-to-All 的 MoE 工作流
以一個簡化的 4-GPU MoE 層為例，假設 8 個專家，每個 GPU 放 2 個專家，Top-1 路由：
┌─────────────────────────────────────────────────────────┐
│ MoE Layer Forward │
│ │
│ Step 1: Router計算 (每個GPU本地完成) │
│ GPU0: token A→Expert3, token B→Expert6 │
│ GPU1: token C→Expert1, token D→Expert7 │
│ GPU2: token E→Expert0, token F→Expert5 │
│ GPU3: token G→Expert4, token H→Expert2 │
│ │
│ Step 2: All-to-All Dispatch (分發token到專家所在GPU) │
│ GPU0 持有 Expert0,1 → 收到 token C(→E1), token E(→E0)│
│ GPU1 持有 Expert2,3 → 收到 token A(→E3), token H(→E2)│
│ GPU2 持有 Expert4,5 → 收到 token G(→E4), token F(→E5)│
│ GPU3 持有 Expert6,7 → 收到 token B(→E6), token D(→E7)│
│ │
│ Step 3: Expert計算 (每個GPU本地執行2個專家的FFN) │
│ │
│ Step 4: All-to-All Combine (將結果發回token原始所在GPU) │
│ (Step 2的逆置換) │
└─────────────────────────────────────────────────────────┘每次 MoE 層 = 2 次 All-to-All（dispatch + combine）。如果一個 MoE 模型有 58 個 MoE 層（如 DeepSeek-V3 的設計），就是 116 次 All-to-All。
3. 通訊量分析
設：
- N = 參與專家並行的 GPU 數（= 專家數 / 每 GPU 專家數）
- S = 每個 token 的 hidden dimension 大小（位元組）
- T = 每個 GPU 上的 token 數
- K = Top-K 路由數（通常 1 或 2）
每次 All-to-All 的通訊量（理想情況）：
- 每個 GPU 傳送 K·T 個 token，均勻分散到 N 個目標 → 每個 GPU 傳送 K·T·S / N 位元組給其他每個 GPU
- 單 GPU 總髮送量 ≈ K · T · S · (N-1) / N ≈ K · T · S（當 N 較大時）
- 這與 AllReduce 不同——AllReduce 的通訊量約 2·(N-1)/N · D（D 為本地資料量），與 GPU 數幾乎無關；而 All-to-All 的每 GPU 通訊量 ≈ K·T·S，與 GPU 數 N 無關但流量模式要求全對全。
真正的問題不是總頻寬，而是流量模式： All-to-All 產生的是全對全置換流量，要求網路任意兩點間都能同時以線速通訊。這對網路的”對分頻寬”（bisection bandwidth）提出了 100% 的要求。
4. 網路拓撲的影響
All-to-All 對網路的核心要求: 全對分頻寬 (Full Bisection Bandwidth)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[理想情況] 無阻塞胖樹/Spine-Leaf
- 任意兩點間均可線速通訊
- All-to-All 達到理論峰值
- 成本: O(N·logN) 交換埠
[常見妥協] 過度訂閱 (Oversubscription)
- 上行鏈路頻寬 < 下行鏈路頻寬 (如 1:4, 1:8)
- All-to-All 在跨 leaf 時嚴重擁塞
- MoE 訓練效率大幅下降
[前沿方案]
- Rail-optimized 拓撲 (GPU rail 與網路 rail 對齊)
- 光交換/電路交換 (應對突發 All-to-All burst)
- SHARP 網路內計算 (In-Network Aggregation)
注: SHARP 原生支援 Reduce/AllReduce,
對 All-to-All 的支援有限/需進一步確認Rail-optimized 網路設計： 這是 NVIDIA 在 DGX SuperPOD 等大規模叢集中推薦的拓撲。其核心思想是將 GPU 的多個網路埠（如 ConnectX-7 的多埠或多個 NIC）分別連線到不同的 rail 交換器，使得同一 rail 內的通訊不經過 spine 層。對於 All-to-All，這種設計可以將跨 rail 的流量均勻分散到所有 spine 鏈路上，最大化有效對分頻寬。
5. 實現層面
NCCL（NVIDIA Collective Communications Library）： 支援 ncclAllToAll 和 ncclAllToAllv 操作。ncclAllToAll 要求每個 rank 傳送給其他每個 rank 的資料塊大小相同；ncclAllToAllv 支援變長（這在 MoE 中很重要，因為不同專家接收的 token 數量是動態的）。
通訊原語分解： 理論上，All-to-All 可以分解為 N-1 次點對點 Send/Recv，也可以用其他集體操作組合近似，但直接的 All-to-All 實現通常更高效。
NVLink + NVSwitch（節點內）： 在 DGX H100 等系統中，8 個 GPU 通過 NVSwitch 實現全連線，節點內的 All-to-All 可以達到 NVLink 的全頻寬。這是 MoE 模型在單節點內做專家並行的高效基礎。
跨節點 All-to-All： 通過 InfiniBand（HDR/NDR/XDR）或 RoCE 網路實現。跨節點的 All-to-All 延遲和頻寬直接受網路拓撲、擁塞控制、路由策略影響。
6. 延遲敏感性
All-to-All 與 AllReduce 的一個關鍵區別：AllReduce 的時間主要由頻寬決定（大數據量傳輸），而 All-to-All 在小訊息場景下嚴重受延遲影響。
原因：All-to-All 需要 N 個獨立的訊息交換，每次交換都有固定的啟動延遲。當每個訊息很小時（如 token 數少、hidden dim 小），總時間 ≈ N × latency_per_message，而非 data_size / bandwidth。
這對 MoE 的影響：batch size 較小（推論或小 batch 訓練）時，All-to-All 的延遲佔比急劇上升，成為主要瓶頸。
技術原理（最深）
All-to-All 的形式化定義
設有 P 個程序（rank），每個 rank i 持有 P 個數據塊 D_{i,0}, D_{i,1}, …, D_{i,P-1}。
All-to-All 操作完成後：
- rank j 收到所有 rank i 發給它的資料塊 D_{i,j}（對所有 i = 0, 1, …, P-1）
Rank 0 持有: [D₀₀] [D₀₁] [D₀₂] [D₀₃]
Rank 1 持有: [D₁₀] [D₁₁] [D₁₂] [D₁₃]
Rank 2 持有: [D₂₀] [D₂₁] [D₂₂] [D₂₃]
Rank 3 持有: [D₃₀] [D₃₁] [D₃₂] [D₃₃]
↓ All-to-All ↓
Rank 0 收到: [D₀₀] [D₁₀] [D₂₀] [D₃₀] ← 每個rank發給它的第0塊
Rank 1 收到: [D₀₁] [D₁₁] [D₂₁] [D₃₁]
Rank 2 收到: [D₀₂] [D₁₂] [D₂₂] [D₃₂]
Rank 3 收到: [D₀₃] [D₁₃] [D₂₃] [D₃₃]通訊量： 每個 rank 傳送 (P-1) 個訊息，接收 (P-1) 個訊息。總網路通訊量 = P × (P-1) × block_size，即 O(P² × block_size)。
與 All-to-Allv 的區別
| 操作 | 資料塊大小 | MoE 適用性 |
|---|---|---|
AlltoAll | 固定（每個 rank 給其他每個 rank 的塊大小相同） | 簡單場景，負載均衡時可用 |
AlltoAllv | 變長（每個 rank 給不同 rank 的塊大小可以不同） | MoE 的實際需要——不同專家被路由到的 token 數動態變化 |
MoE 中，一個 GPU 發給 GPU_3（持有 Expert 6,7）的 token 數取決於 router 的決策，不可能預先保證相等。因此實際使用的是 AlltoAllv。
All-to-All 的網路層實現
在胖樹（Fat-Tree）拓撲下，All-to-All 的流量模式分析：
┌─── Spine ───┐
/ | | \
/ | | \
Leaf0 Leaf1 Leaf2 Leaf3
/ \ / \ / \ / \
G0 G1 G2 G3 G4 G5 G6 G7
All-to-All 流量特徵:
- G0→G6 的流量經過 Leaf0→Spine_x→Leaf3
- G0→G7 的流量經過 Leaf0→Spine_y→Leaf3 (可能不同spine)
- 同時: G6→G0, G7→G0, G1→G5, ... 所有方向同時有流量
- 結果: 每條 Spine 鏈路都被打滿
- 要求: Spine 層無阻塞 (bisection bandwidth = 埠數×線速)為什麼 1:4 過度訂閱對 MoE 是災難性的： 假設 leaf switch 有 8 個 100Gbps 下行口連線 GPU，但只有 2 個 100Gbps 上行口連線 spine（1:4 過度訂閱）。此時 leaf 對外總頻寬只有 200Gbps，但 All-to-All 要求 leaf 對外發送約 6/8 × 總輸入頻寬的流量。當跨 leaf 流量佔比高時，上行口成為瓶頸，All-to-All 效能驟降至理論值的 1/4。
技術演進史
| 時間 | 事件 | 與 All-to-All 的關係 |
|---|---|---|
| 2007-2012 | MPI 標準定義 All-to-All / AlltoAllv | 經典 HPC 通訊原語，主要用於科學計算（如 FFT、矩陣轉置） |
| 2020 | GShard (Google) 600B MoE | 確立了 MoE 中 All-to-All dispatch/combine 範式 |
| 2021 | Switch Transformer (Google) 首次大規模 MoE 訓練 | 在 TPU Pod 上使用 ICI 網路做 All-to-All dispatch |
| 2021 | Megablocks (Stanford) | 最佳化 MoE 中 All-to-All 的排程，減少 padding 浪費 |
| 2022 | NCCL 增強 All-to-Allv 支援 | NVIDIA 官方通訊庫對 MoE 場景的原生支援改善 |
| 2022-2023 | Mixtral 8×7B, DeepSeek-V2 | 開源 MoE 模型爆發，All-to-All 從 TPU 走向 GPU 叢集的核心挑戰 |
| 2023-2024 | NVSwitch + Rail-Optimized 網路大規模部署 | 產業界為 All-to-All 最佳化網路基礎設施 |
| 2024 | DeepSeek-V3/R1 | 超大規模 MoE（數百專家），EP+TP+DP+PP 多維並行中 All-to-All 的工程極致 |
| 2024-2025 | 光交換、電路交換方案探索 | 研究界探索用光/電路交換解決 All-to-All 的突發全對全流量 |
技術路線對比（量化表）
| 維度 | AllReduce (DP/TP) | All-to-All (EP) | Point-to-Point (PP) |
|---|---|---|---|
| 流量模式 | 聚合/廣播，對稱 | 全對全置換 | 僅相鄰 rank |
| 通訊量/GPU | ≈ 2×(N-1)/N × param_size | ≈ K × tokens × hidden_bytes | ≈ microbatch × hidden_bytes |
| 對分頻寬需求 | 高但可最佳化（梯度壓縮等） | 極高且難以最佳化 | 低 |
| 延遲敏感性 | 低（大訊息為主） | 高（小訊息時尤為突出） | 中 |
| 網路拓撲敏感性 | 中 | 極高 | 低 |
| 擁塞控制難度 | 中（可預測模式） | 高（突發、全對全） | 低 |
| 典型加速方案 | SHARP 網路內聚合、梯度壓縮 | NVSwitch、全對分胖樹、[前沿:光交換] | Micro-batching |
| NCCL 支援 | 成熟 | ncclAllToAll / ncclAllToAllv | ncclSend / ncclRecv |
上下游
上游（依賴）
┌──────────────────────┐
│ MoE 模型架構設計 │ ← 專家數量、Top-K、路由策略
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ 專家分佈策略 (EP degree) │ ← 每GPU放多少專家,決定N
└──────────┬───────────┘
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 集體通訊庫 │ │ 網路硬體 │ │ 拓撲設計 │
│ NCCL / GLOO │ │ NVSwitch │ │ 胖樹/Spine-Leaf│
│ MPI / MSCCL │ │ IB NDR/XDR │ │ Rail-Optimized │
└───────────────┘ │ RoCE v2 │ │ 過度訂閱比例 │
└───────────────┘ └───────────────┘下游（影響）
- MoE 模型訓練吞吐：All-to-All 效率直接影響 MFU（Model FLOPs Utilization）
- MoE 推論延遲：小 batch 推論時 All-to-All 延遲佔比高，影響 Time-to-First-Token
- 叢集網路採購決策：是否需要全對分頻寬直接影響交換器和光模組的採購量（成本可能翻倍）
- 模型架構設計：All-to-All 成本反過來約束了專家數量、EP degree 的選擇（通訊成本太高時可能減小 EP、增大 TP）
關鍵指標
| 指標 | 含義 | 典型量級參考 |
|---|---|---|
| All-to-All 延遲 | 單次 All-to-All 的端到端時間（小訊息） | 節點內（NVSwitch）: 低微秒級；跨節點（IB）: 數十微秒級 [具體值因系統規模和配置差異較大，無據不編] |
| All-to-All 頻寬效率 | 實際吞吐 / 理論峰值 | 良好配置下可接近線速；差配置（過度訂閱）可能 < 30% [估算] |
| 對分頻寬（Bisection BW） | 將網路切為兩半時，跨切面的總頻寬 | 全對分 = 線速 × 埠數/2；1:4 過度訂閱 = 全對分的 1/4 |
| EP Degree | 參與專家並行的 GPU 數 | 從 8（單節點）到數百（跨節點） |
| Tokens per Expert | 每個專家平均處理的 token 數 | 決定 All-to-All 的訊息大小；負載均衡時 ≈ total_tokens × K / num_experts |
| All-to-All 時間佔比 | All-to-All 時間 / 總 MoE 層時間 | 網路差時可達 50%+；最佳化後可降至 10-20% [估算] |
供需與市場資料
需求端驅動力
- MoE 模型規模爆發： 主流前沿模型（DeepSeek-V3/R1、Mixtral 系列、Grok 等）均採用 MoE，且專家數持續增長（從 8 到 64 到 256+），直接放大 All-to-All 通訊需求。
- 推論場景： MoE 模型推論時，Expert Parallelism 是常見的部署策略（尤其當單個專家無法放入單 GPU 時），推論階段的 All-to-All 對延遲極為敏感。
- 萬卡訓練叢集： 當 EP degree 擴充套件到數百 GPU 時，All-to-All 的 O(N²) 流量模式使網路成為硬瓶頸。
供給端響應
- 網路裝置升級： 全對分頻寬的胖樹拓撲需要的交換器埠數和光模組數量遠高於過度訂閱方案。據行業估算，從 1:4 過度訂閱升級到 1:1 全對分，網路側成本可能增加 2-3 倍 [行業估算，無精確來源]。
- NVSwitch 演進： NVIDIA 在 DGX 系統中持續升級 NVSwitch，提升節點內 All-to-All 頻寬。GB200 NVL72 等系統通過 NVLink 實現更大範圍的高速互聯。
- 光互連/光交換： 學術界和產業界（如 RotorNet、Jupiter 等專案）探索用光電路交換來高效支援 All-to-All 流量模式，但尚處於早期。
代表公司與資本對映
| 領域 | 代表公司/專案 | 與 All-to-All 的關聯 |
|---|---|---|
| GPU + 互連 | NVIDIA | NVSwitch 提供節點內 All-to-All 基礎；NCCL 提供 AlltoAllv 實現；ConnectX NIC 支援跨節點通訊 |
| 網路交換 | NVIDIA (Spectrum-X)、Arista、Cisco | 提供全對分胖樹/Spine-Leaf 交換器 |
| InfiniBand | NVIDIA (ConnectX, Quantum) | IB 是跨節點 All-to-All 的主流高效能網路 |
| RoCE / 乙太網路 | Broadcom、Marvell | 超乙太網路（Ultra Ethernet）聯盟推動乙太網路增強集體通訊支援 |
| 光互連 | Lightmatter、Ayar Labs、Celestial AI | 矽光/光交換可能從根本上改變 All-to-All 的網路行為 |
| 通訊庫/編譯器 | NVIDIA (NCCL/MSCCL)、微軟 (MSCCL)、CMU (Hetu) | 最佳化 All-to-All 的排程、流水線和分塊策略 |
| MoE 模型 | DeepSeek、Mistral AI、xAI (Grok) | 作為 All-to-All 的核心”消費者”，其架構設計直接影響 All-to-All 需求 |
投資邏輯
核心推論鏈
MoE成為主流架構 → 每層需要2次All-to-All → 要求全對分頻寬網路
→ 網路基礎設施成本和複雜度大幅上升
→ 受益標的: 高效能網路交換(光模組/交換器)、NVLink/NVSwitch生態、
光互連技術、高效能通訊庫看多邏輯
- MoE 趨勢確立： 從 DeepSeek 到各大廠商，MoE 是scaling的主流路徑。專家數越多 → EP degree 越大 → All-to-All 通訊量越大 → 網路需求越強。
- 網路從”夠用”到”必須全對分”： 純 DP/TP 時代，過度訂閱網路勉強可用；MoE 時代，全對分頻寬成為硬性要求。這驅動網路側資本支出升級。
- 光互連的結構性機會： 電交換在全對全流量下功耗和成本急劇上升，光互連/光交換在 All-to-All 場景下有潛在結構性優勢。
風險與不確定性
- MoE 架構可能被替代： 如果 Dense 模型（如 Llama 系列）在同等成本下持續縮小與 MoE 的差距，EP 和 All-to-All 的重要性會下降。
- 通訊最佳化可能緩解瓶頸： 專家合併、Token 選擇策略最佳化、本地化路由（減少跨節點通訊）等方法可能降低 All-to-All 的實際壓力。
- DeepSeek 等已展示部分緩解方案： 如通過 DualPipe 等技術將 All-to-All 與其他計算重疊，減少實際暴露的通訊時間。
常見誤讀糾偏
❌ 誤讀 1：“All-to-All 和 AllReduce 本質一樣，都是集體通訊”
糾正： 兩者在流量模式上完全不同。AllReduce 的核心操作是聚合（Reduce），每個節點的貢獻被求和/均攤到所有節點，流量模式是樹形或環形的，具有高度對稱性和可預測性。All-to-All 的流量模式是全對全置換——每個節點發給其他每個節點的資料都不同，網路中任意兩點間都可能同時有流量。這意味著 AllReduce 可以通過 SHARP 等網路內聚合技術加速，而 All-to-All 原則上無法用類似方式最佳化（你無法在網路交換器上”聚合”不同目的地的資料）。
❌ 誤讀 2：“MoE 用 AllReduce 就行，和資料並行一樣”
糾正： MoE 的專家並行層不能用 AllReduce 替代 All-to-All。AllReduce 是”所有人算完聚合”；而 MoE 需要的是”把不同 token 發給不同專家、再把結果發回來”——這是本質上不同的通訊模式。有人可能混淆的原因是：在 MoE 模型中，非 MoE 層（如 Attention 層）仍然使用 AllReduce（如果做了張量並行），但 MoE 層的 dispatch/combine 必須是 All-to-All（或其變體）。
❌ 誤讀 3：“All-to-All 的瓶頸是頻寬，增加頻寬就能解決”
糾正： 頻寬只是問題的一面。All-to-All 在小訊息場景下延遲是主要瓶頸——它需要 N 次獨立的訊息交換，每次都有固定的啟動延遲。此外，即使頻寬充足，All-to-All 的全對全流量模式也極易引發網路擁塞（多條路徑同時競爭交換器快取），因此對分頻寬和擁塞控制與絕對頻寬同等重要。
❌ 誤讀 4：“節點內 All-to-All 沒有瓶頸”
糾正： 在配備 NVSwitch 的系統中（如 DGX H100），節點內 All-to-All 確實可以高效完成。但當單節點內 GPU 數有限（如 8 個），而專家數遠大於 8 時，必須做跨節點 EP。此時節點內 All-to-All 只是整個通訊鏈的一環。另外，如果未來採用 GB200 NVL72 等更大範圍的 NVLink 域，節點內/域內 All-to-All 的定義也會變化。
學習路徑
Level 0: 理解概念
├── 理解 All-to-All 的資料交換語義（每個rank發不同資料給每個其他rank）
├── 對比 AllReduce、AllGather、ReduceScatter 的語義差異
└── 推薦: 閱讀 MPI 標準中 MPI_Alltoall 的文件
Level 1: 理解 MoE 中的應用
├── 讀懂 GShard 論文中的 MoE dispatch/combine 圖示
├── 理解 Top-K 路由如何決定 All-to-All 的訊息大小和目的地
└── 推薦: 程式碼閱讀 Megablocks 或 FairScale MoE 實現
Level 2: 理解網路影響
├── 學習胖樹/Spine-Leaf 拓撲和對分頻寬概念
├── 理解過度訂閱對 All-to-All 效能的影響（可以用簡單模擬驗證）
└── 推薦: NVIDIA DGX SuperPOD 網路設計文件
Level 3: 理解系統最佳化
├── 學習 All-to-All 與計算的重疊（overlap）技術
├── 瞭解 MSCCL 等可程式設計集合通訊最佳化
├── 理解 EP + TP 混合並行中通訊量的權衡
└── 推薦: DeepSeek-V3 技術報告（DualPipe 等最佳化）;
論文 "MegaScale" (ByteDance, 2024)
Level 4: 前沿研究
├── 光交換/電路交換支援 All-to-All 的方案
├── 網路內計算（In-Network Computing）對 All-to-All 的潛在加速
├── 自適應路由和擁塞控制在 All-to-All 場景下的表現
└── 推薦: RotorNet, c-Through, Jupiter 等光交換論文一句話總結
All-to-All 是 MoE 大型模型時代最關鍵的通訊原語——它把”全對全置換流量”這個對網路最不友好的模式變成了每次 MoE 層的剛需，倒逼整個 AI 基礎設施從網路拓撲到互連技術的全面升級。
延伸閱讀與來源
| 資源 | 說明 |
|---|---|
| GShard (Lepikhin et al., 2020) | 首次系統描述 MoE 中 All-to-All dispatch/combine 範式 |
| Switch Transformer (Fedus et al., 2022) | Google 的稀疏 MoE 大規模訓練 |
| Mixtral 8×7B | 開源 MoE 語言模型，採用 Top-2 路由 |
| DeepSeek-V2/V3 技術報告 | 大規模 MoE 訓練的並行策略與通訊最佳化細節 |
| NCCL 文件 | ncclAllToAll / ncclAllToAllv 使用說明 |
| DGX SuperPOD 網路設計指南 | NVIDIA 推薦的 Rail-Optimized 拓撲 |
| MSCCL (Microsoft) | 可程式設計集合通訊庫，支援自定義 All-to-All 排程 |
| 光交換論文 | RotorNet, c-Through, Jupiter 等 |