大规模MoE的通信墙问题：TP、CP、EP、All-to-All

大规模 MoE（Mixture of Experts）模型训练中的一个核心系统矛盾：同一个 Transformer Block 里，Attention 和 MoE FFN 对“并行方式”的最优选择几乎是相反的，因此会形成严重的通信瓶颈，也就是所谓的“通信墙”。

通信墙（数据传输慢）：专家并行的 All-to-All 通信量会随着 token 数量、Top-k 和隐藏维度增长。同时，在同一个 Transformer Block 内，注意力层需要高 TP 来处理大的 QKV 矩阵、高 CP 来处理长序列；但是 MoE 层需要高 EP 来分布大量专家、低 TP 来保持完整专家宽度。

理解这句话，关键是先把四个概念分清楚：TP、CP、EP、All-to-All。

一、先看 Transformer Block 里究竟发生了什么

一个简化的 MoE Transformer Block 可以写成：

\[X \rightarrow \text{Attention} \rightarrow \text{MoE} \rightarrow Y \]

其中 Attention 大致是：

\[Q=XW_Q,\quad K=XW_K,\quad V=XW_V \]

然后计算：

\[\text{Attention}(Q,K,V) = \text{softmax}\left(\frac{QK^T}{\sqrt d}\right)V \]

而 MoE 层则不是普通的一个 FFN：

\[FFN(X) \]

而是有很多个专家：

\[E_1,E_2,\dots,E_N \]

Router 会给每个 token 选 Top-k 个专家：

\[x_i\rightarrow E_{a},E_{b} \]

例如：

token 1 → Expert 3, Expert 17
token 2 → Expert 8, Expert 22
token 3 → Expert 3, Expert 11
...

问题就从这里产生了。

因为这些 Expert 通常分布在不同 GPU 上。

于是 token 必须：

GPU A
  token
    ↓
网络传输
    ↓
GPU B 上的 Expert 17

计算完以后还得再传回来。

这就是 All-to-All 通信。

二、什么是 EP：Expert Parallelism

EP = 专家并行。

假设模型有：

\[64\ 个 experts \]

你有：

\[8\ 张 GPU \]

那么可能：

GPU0: Expert 0~7
GPU1: Expert 8~15
GPU2: Expert 16~23
...
GPU7: Expert 56~63

这就是：

\[EP=8 \]

每张 GPU 保存部分专家。

EP 越大，可以承载的专家越多。

例如：

EP=8   → 每张GPU 8个专家
EP=64  → 每张GPU 1个专家

因此 MoE 模型天然喜欢：

\[\boxed{\text{高 EP}} \]

因为 MoE 的核心优势本来就是：

模型参数很多，但一个 token 只激活少数专家。

比如：

\[256\ experts,\ Top\text{-}8 \]

一个 token 实际只使用：

\[8/256=3.125\% \]

的专家。

三、为什么 EP 会产生 All-to-All？

假设 GPU0 当前有这样几个 token：

t1 → Expert 5
t2 → Expert 18
t3 → Expert 41
t4 → Expert 63

但 Expert 分布是：

GPU0: Expert 0~7
GPU1: Expert 8~15
GPU2: Expert 16~23
...
GPU7: Expert 56~63

于是：

t1 留在 GPU0
t2 → GPU2
t3 → GPU5
t4 → GPU7

而与此同时，其他 GPU 的 token 也可能需要 GPU0 上的 Expert。

于是形成：

GPU0 ↔ GPU1
GPU0 ↔ GPU2
GPU0 ↔ GPU3
...
GPU7 ↔ GPU6

这就是：

\[\boxed{All-to-All} \]

几乎所有 GPU 都可能和所有 GPU 交换 token。

这和普通 AllReduce 很不一样。

AllReduce 通常是：

大家共同对同一个 tensor 做求和/同步。

而 MoE 的 All-to-All 更像：

“你这里的 token 给我，我这里的 token 给他，他那里的 token 再给另一个人。”

网络流量非常碎，而且方向很多。

四、为什么原文说 All-to-All 通信量随 token 数、Top-k、隐藏维度增长？

这其实非常直观。

假设有：

\[T \]

个 token。

每个 token 激活：

\[k \]

个专家。

hidden dimension 是：

\[H \]

那么每个 token 本质上就是一个：

\[H \]

维向量。

如果每个 token 被送到 k 个专家，那么需要发送的数据量大致与：

\[\boxed{T\times k\times H} \]

成正比。

如果使用 FP16/BF16，每个元素大约 2 bytes。

于是粗略的数据量：

\[Data \approx T\times k\times H\times 2\ bytes \]

而且通常还有两次：

第一次

Dispatch：

token → expert

第二次

Combine：

expert output → 原 GPU

所以更接近：

\[\boxed{ 2TkHb } \]

其中 (b) 是每个元素字节数。

举一个现实规模的例子

假设：

\[T=131072 \]

也就是一个并行组里约 13 万 token。

隐藏维度：

\[H=8192 \]

Top-k：

\[k=8 \]

BF16：

\[2\ bytes \]

单方向数据：

\[131072\times8192\times8\times2 \]

约等于：

\[17.2GB \]

如果算 dispatch + combine：

\[\approx34.4GB \]

当然实际系统通过分组、分片、路由、并发等方式不会简单地一次传这么多，但这个数量级已经说明问题了：

MoE 算力可能非常便宜，但搬 token 很贵。

这就是所谓：

\[\boxed{\text{Communication Wall}} \]

即“通信墙”。

五、接下来才是这句话最深的一层：Attention 和 MoE 想要完全不同的并行策略

原句最关键的是：

Attention 层需要高 TP、高 CP；MoE 层需要高 EP、低 TP。

这是整个问题的核心。

六、TP 是什么：Tensor Parallelism

TP = Tensor Parallelism，张量并行。

例如一个巨大的矩阵乘法：

\[XW \]

假设：

\[W\in \mathbb{R}^{8192\times32768} \]

这个矩阵太大，一张 GPU 放不下或者算起来太慢。

于是可以把 W 分给 8 张 GPU：

GPU0: W0
GPU1: W1
GPU2: W2
...
GPU7: W7

于是：

\[TP=8 \]

每张 GPU 只计算：

\[XW_i \]

最后组合结果。

TP 的本质就是：

把一个大矩阵切开，多张 GPU 一起算。

七、为什么 Attention 喜欢“高 TP”？

Attention 中有非常大的矩阵：

\[W_Q,W_K,W_V,W_O \]

比如 hidden size：

\[H=16384 \]

那么 QKV projection：

\[W_{QKV} \]

可能是：

\[16384\times49152 \]

参数量巨大。

如果：

\[TP=1 \]

意味着：

一张 GPU 完整保存并计算 QKV。

压力很大。

如果：

\[TP=8 \]

那么：

GPU0：部分 QKV
GPU1：部分 QKV
...
GPU7：部分 QKV

所以 Attention 通常希望：

\[\boxed{\text{较高 TP}} \]

八、CP 又是什么？

CP = Context Parallelism。

主要解决：

\[\boxed{\text{长序列}} \]

问题。

假设 context length：

\[1M tokens \]

一张 GPU 不可能保存完整：

Q
K
V
Attention matrix
KV Cache

于是按 sequence dimension 切：

GPU0: token 0~249999
GPU1: token 250000~499999
GPU2: token 500000~749999
GPU3: token 750000~999999

这就是：

\[CP=4 \]

所以序列越长，越需要：

\[\boxed{\text{高 CP}} \]

因此 Attention 最舒服的状态通常是：

\[\boxed{\text{高 TP + 高 CP}} \]

九、但到了 MoE，需求突然反过来了

MoE 希望：

\[\boxed{\text{高 EP + 低 TP}} \]

为什么？

这里非常关键。

假设一个 expert 是一个 FFN：

\[H\rightarrow4H\rightarrow H \]

例如：

\[8192\rightarrow32768\rightarrow8192 \]

如果 TP 很高，比如：

\[TP=8 \]

一个 expert 会被拆成：

Expert 17

GPU0：1/8
GPU1：1/8
GPU2：1/8
...
GPU7：1/8

这意味着：

每运行一次 Expert，都需要跨 GPU 协同。

结果 MoE 原本想实现：

一个 token
→ 某一张 GPU 的 Expert
→ 本地 GEMM
→ 完成

现在却变成：

token
↓
送到 Expert 所在 TP group
↓
8张 GPU 一起算 Expert
↓
通信
↓
聚合

通信反而更多。

因此 MoE 更喜欢：

一个完整 Expert
放在一张 GPU

也就是所谓：

保持完整专家宽度

这就是原文：

“低 TP 保持完整专家宽度”

的意思。

十、所谓“完整专家宽度”到底是什么意思？

例如：

\[H=8192 \]

专家第一层：

\[8192\times32768 \]

如果：

\[TP=1 \]

一张 GPU 拥有完整：

\[8192\times32768 \]

Expert：

token
 ↓
GPU5
 ↓
Expert 17
 ↓
本地 GEMM

非常干净。

但如果：

\[TP=8 \]

每张 GPU 只拥有：

\[8192\times4096 \]

的 slice。

Expert 被“横着劈成了 8 份”。

于是一个 token 要调用 Expert 17，就不能只找一个 GPU。

需要找一整个：

\[8 GPU TP Group \]

所以 MoE 希望：

\[TP \downarrow \]

甚至：

\[TP=1 \]

而 EP 尽可能大。

十一、于是出现了一个非常尴尬的矛盾

同一个 Transformer Block：

          Transformer Block

        ┌─────────────────┐
        │    Attention    │
        │                 │
        │ 喜欢：           │
        │ TP ↑            │
        │ CP ↑            │
        └────────┬────────┘
                 │
                 ▼
        ┌─────────────────┐
        │       MoE       │
        │                 │
        │ 喜欢：           │
        │ EP ↑            │
        │ TP ↓            │
        └─────────────────┘

于是：

\[\boxed{ Attention:\ TP\uparrow,\ CP\uparrow } \]

但是：

\[\boxed{ MoE:\ EP\uparrow,\ TP\downarrow } \]

注意到没有？

TP 的要求是直接冲突的。

这就是原句真正想表达的系统设计难题。

十二、为什么不能简单地“Attention 用 TP=8，MoE 用 TP=1”？

理论上当然可以。

实际上这正是现代 MoE 系统设计的方向。

但会产生一个非常讨厌的问题：

\[\boxed{\text{Parallelism Layout Transformation}} \]

即：

并行布局转换。

Attention 结束的时候数据可能按 TP 切：

GPU0: hidden[0:1024]
GPU1: hidden[1024:2048]
...

但是 MoE 希望：

GPU0: 完整 token vector
GPU1: 完整 token vector
...

于是中间必须发生：

\[\boxed{\text{Redistribution}} \]

类似：

Attention layout
      ↓
AllGather / All-to-All
      ↓
MoE layout

MoE 算完：

MoE layout
      ↓
All-to-All
      ↓
Attention layout

所以一个 Transformer Block 内甚至可能出现：

Attention
   ↓
通信
   ↓
MoE Dispatch
   ↓
All-to-All
   ↓
Expert GEMM
   ↓
All-to-All
   ↓
通信
   ↓
Attention

结果 GPU 算力越来越强以后，你会发现：

GPU 并不是在“等计算”，而是在“等数据”。

十三、这就是“通信墙”最本质的含义

过去训练大模型的瓶颈主要是：

\[\boxed{Compute} \]

也就是 FLOPS 不够。

但随着：

H100
H200
B200
GB200
GB300
下一代 GPU

矩阵乘越来越快。

可是网络带宽提升速度没有同样快。

于是出现：

\[T_{total} = T_{compute} + T_{communication} \]

以前可能：

compute       ████████████████████
communication ███

现在可能：

compute       █████
communication ███████████████

最后：

\[\boxed{ T_{communication} > T_{compute} } \]

这就是通信墙。

甚至更准确地说：

现代大规模 MoE 的挑战越来越不是“能不能算得动”，而是“能不能把 token 足够快地送到该去的 GPU”。

十四、Top-k 为什么尤其危险？

假设：

\[Top\text{-}1 \]

每个 token 只发送一次：

token → Expert A

如果：

\[Top\text{-}8 \]

就变成：

             → Expert A
             → Expert B
             → Expert C
token ───────→ Expert D
             → Expert E
             → Expert F
             → Expert G
             → Expert H

通信量理论上近似扩大：

\[8\times \]

所以虽然提高 Top-k 通常可能增加模型 capacity / quality，但系统代价很高。

因此现代 MoE 设计里：

\[\boxed{\text{Top-k 是“模型质量—计算—通信”的三方权衡}} \]

而不仅仅是一个模型结构超参数。

十五、再进一步：MoE 真正的问题不是 FLOPs，而是 Arithmetic Intensity

这是理解 MoE 系统的一个很重要的视角。

普通 Dense FFN：

\[XW \]

通常 GEMM 很大。

GPU 可以吃满。

Arithmetic Intensity 很高：

\[\frac{FLOPs}{Bytes} \]

很高。

但 MoE 之后：

大量 token
↓
被拆成很多小 batch
↓
分给不同 experts

于是原来一个大 GEMM：

\[4096\times8192\times32768 \]

可能变成几十个：

\[50\times8192\times32768 \]

这种“小 GEMM”。

结果出现两个问题：

GPU 利用率下降；
通信占比上升。

所以 MoE 的 paradox 是：

理论 FLOPs 降低了，但系统效率未必同比提高。

也就是：

\[\boxed{ \text{少算了很多} \neq \text{快了很多} } \]

十六、你可以把 TP、CP、EP 想象成“怎么分工”

这是最好理解的类比。

假设训练一个模型相当于一家大型工厂。

TP

叫：

把一台机器拆给多人一起操作。

比如：

一个巨型 Expert
→ 8个人共同完成

所以 TP 是：

\[\boxed{\text{切模型宽度}} \]

CP

叫：

把一长串订单分段处理。

例如：

订单1~1000   → GPU0
订单1001~2000 → GPU1

所以 CP：

\[\boxed{\text{切 sequence}} \]

EP

叫：

不同工人负责不同专业。

例如：

GPU0：法律专家
GPU1：数学专家
GPU2：代码专家
GPU3：医学专家

所以 EP：

\[\boxed{\text{切 experts}} \]

Attention 相当于：

“一项特别巨大的统一任务。”

所以适合：

大家一起干

即高 TP。

MoE 则是：

“很多专业任务。”

所以适合：

每个人负责一个专家

即高 EP。

这两种组织结构本身就冲突。

十七、所以这句话背后真正讨论的是“并行策略不匹配”

可以把整个问题浓缩成：

\[\boxed{ \text{Attention-optimal parallelism} \neq \text{MoE-optimal parallelism} } \]

具体来说：

Layer	理想并行
Attention	高 TP
Attention	高 CP
MoE	高 EP
MoE	低 TP

于是需要不断做：

\[TP/CP Layout \leftrightarrow EP Layout \]

转换。

而转换的代价就是：

\[\boxed{\text{Communication}} \]

十八、一个很典型的超大规模配置就能看出这种矛盾

假设：

\[1024 GPUs \]

Attention 可能希望：

\[TP=8,\ CP=8,\ DP=16 \]

因为：

\[8\times8\times16=1024 \]

但到了 MoE：

假设：

\[256 experts \]

可能希望：

\[EP=64 \]

甚至：

\[EP=128 \]

而：

\[TP=1\ 或\ 2 \]

于是硬件拓扑必须从：

Attention:

TP × CP × DP

重新组织成：

MoE:

EP × TP × DP

这个重新排列 GPU 通信组的过程，本质上非常昂贵。

十九、所以 NVIDIA / DeepSeek 等现在真正优化的是什么？

从这个背景出发，你就能理解很多看似复杂的技术。

现在大型 MoE 系统优化的核心往往不是：

“怎么再少做一点矩阵乘法？”

而是：

怎么隐藏、减少或者加速 All-to-All。

典型方向包括：

communication-computation overlap
hierarchical All-to-All
topology-aware routing
expert placement
expert replication
token dispatch fusion
grouped GEMM
FP8 communication
low precision dispatch
load balancing
shared experts
node-limited routing

本质上全部围绕一句话：

\[\boxed{ \text{不要让 GPU 等网络} } \]

例如 DeepSeek 的一些系统设计非常强调：

限制 token 路由到有限节点。

原因不是模型数学上的必要性，而是：

\[\boxed{\text{降低跨节点 All-to-All}} \]

因为：

GPU 内 HBM
      ↓
NVLink
      ↓
NVSwitch
      ↓
InfiniBand / RoCE

越往下，代价越大。

尤其：

\[\text{intra-node communication} \]

和

\[\text{inter-node communication} \]

完全不是一个成本等级。

二十、把原句翻译成一句真正容易理解的话

原文：

专家并行的 all-to-all 通信量会随着 token 数量、top-k 和隐藏维度增长。同时在同一个 Transformer 块内，注意力层需要高 TP 处理大的 QKV 矩阵，高 CP 处理长序列；但是 MoE 层需要高 EP 分布大量专家，低 TP 保持完整专家宽度。

真正想说的是：

MoE 大模型现在越来越受制于“搬数据”，而不是“做计算”。Attention 希望把一个大矩阵拆给很多 GPU 一起算，而 MoE 希望每张 GPU 独立保存不同的完整专家。因此每经过一个 Transformer Block，数据往往都要在不同并行布局之间重新分配。与此同时，一个 token 还可能被发送到多个远程专家，导致 All-to-All 网络流量随 token 数、Top-k 和 hidden size 快速增长。最终 GPU 算得越来越快，却越来越多时间花在等待网络传输上，这就是 MoE 的通信墙。

如果只记一个公式，可以记：

\[\boxed{ \text{MoE Communication} \propto N_{token} \times TopK \times HiddenSize } \]

如果只记一个矛盾，可以记：

\[\boxed{ Attention: TP\uparrow,\ CP\uparrow \qquad MoE: EP\uparrow,\ TP\downarrow } \]

而整个超大规模 MoE 系统工程，其实就在解决这个矛盾。

posted @ 2026-08-27 13:48 stardsd 阅读(40) 评论(0) 收藏举报

刷新页面返回顶部

赏月斋

慎终如始宁静致远

大规模MoE的通信墙问题：TP、CP、EP、All-to-All

一、先看 Transformer Block 里究竟发生了什么

二、什么是 EP：Expert Parallelism

三、为什么 EP 会产生 All-to-All？

四、为什么原文说 All-to-All 通信量随 token 数、Top-k、隐藏维度增长？

第一次

第二次

举一个现实规模的例子

五、接下来才是这句话最深的一层：Attention 和 MoE 想要完全不同的并行策略

六、TP 是什么：Tensor Parallelism

七、为什么 Attention 喜欢“高 TP”？

八、CP 又是什么？

九、但到了 MoE，需求突然反过来了

十、所谓“完整专家宽度”到底是什么意思？

十一、于是出现了一个非常尴尬的矛盾

十二、为什么不能简单地“Attention 用 TP=8，MoE 用 TP=1”？

十三、这就是“通信墙”最本质的含义

十四、Top-k 为什么尤其危险？

十五、再进一步：MoE 真正的问题不是 FLOPs，而是 Arithmetic Intensity

十六、你可以把 TP、CP、EP 想象成“怎么分工”

TP

CP

EP

十七、所以这句话背后真正讨论的是“并行策略不匹配”

十八、一个很典型的超大规模配置就能看出这种矛盾

十九、所以 NVIDIA / DeepSeek 等现在真正优化的是什么？

二十、把原句翻译成一句真正容易理解的话

公告

赏月斋

慎终如始 宁静致远

大规模MoE的通信墙问题：TP、CP、EP、All-to-All

一、先看 Transformer Block 里究竟发生了什么

二、什么是 EP：Expert Parallelism

三、为什么 EP 会产生 All-to-All？

四、为什么原文说 All-to-All 通信量随 token 数、Top-k、隐藏维度增长？

第一次

第二次

举一个现实规模的例子

五、接下来才是这句话最深的一层：Attention 和 MoE 想要完全不同的并行策略

六、TP 是什么：Tensor Parallelism

七、为什么 Attention 喜欢“高 TP”？

八、CP 又是什么？

九、但到了 MoE，需求突然反过来了

十、所谓“完整专家宽度”到底是什么意思？

十一、于是出现了一个非常尴尬的矛盾

十二、为什么不能简单地“Attention 用 TP=8，MoE 用 TP=1”？

十三、这就是“通信墙”最本质的含义

十四、Top-k 为什么尤其危险？

十五、再进一步：MoE 真正的问题不是 FLOPs，而是 Arithmetic Intensity

十六、你可以把 TP、CP、EP 想象成“怎么分工”

TP

CP

EP

十七、所以这句话背后真正讨论的是“并行策略不匹配”

十八、一个很典型的超大规模配置就能看出这种矛盾

十九、所以 NVIDIA / DeepSeek 等现在真正优化的是什么？

二十、把原句翻译成一句真正容易理解的话

公告

慎终如始宁静致远