跳转到主要内容

MoE 推理：Expert Parallelism（EP）、显存与调度

MoE 推理中的参数口径、dispatch-compute-combine 数据流、EP 边界与显存合同

· 约 6 分钟阅读

MoE 推理的难点不只是“每个 token 只激活少量参数”。所有 expert 权重仍要被放置和管理，token 还要经过路由、跨 rank dispatch、expert 计算与 combine。

这篇负责 MoE 的数据流和参数口径；通用 TP/PP/DP/EP 组合由 推理并行策略 展开，显存与吞吐公式由 模拟器建模指南 收口。

30 秒复习
  • 一句话：MoE 用稀疏激活降低单 token 计算，但把 Serving 复杂度转移到全量 expert 驻留、路由、all-to-all 与负载均衡。
  • 三个判断：active 参数决定每 token 计算而非总权重显存；EP 分散不同 expert 但不自动切开单个 expert；性能必须同时看 expert token 分布、dispatch/combine 与 grouped GEMM。
  • 核心模型：yt=∑e∈TopK⁡(t)pt,eEe(xt)+Eshared(xt)y_t=\sum_{e\in\operatorname{TopK}(t)}p_{t,e}E_e(x_t)+E_{\text{shared}}(x_t)，每 rank 显存包含 dense/attention shard、local experts、KV 与 runtime workspace。
  • 边界：expert 数、top-k、shared expert、路由函数和通信实现均为模型/版本合同；本文不把某个未核验模型参数或公开 benchmark 外推成通用结论。

MoE 推理中的 Router、Dispatch、Grouped GEMM、Combine 和 Shared Expert 路径

1. Expert 与三种参数口径

一个常见 SwiGLU expert 包含 gate、up、down 三个投影：

gate/up: [hidden, expert_intermediate]
down:    [expert_intermediate, hidden]

Router 为每个 token 选择 top-k routed experts，并用路由权重合并输出；shared expert 若存在，则对所有 token 执行。

必须区分：

口径含义主要用途
总参数dense/shared + 全部 routed expertscheckpoint 与全局权重容量
Active 参数单 token 实际经过的 dense/shared + top-k experts计算量近似
单 expert 参数一个 expert 的权重判断 expert 是否需要内部 TP

“active 40B”不等于模型只需保存 40B 参数，也不等于 40GB 显存。权重字节还取决于存储格式、scale、padding 和 runtime layout。

2. 完整执行流程：Dispatch - Compute - Combine

hidden states
  -> Router: top-k expert ids + weights
  -> Dispatch #1: token 按 expert owner 重排/发送
  -> Grouped GEMM: 各 expert 对收到的 token 分别执行 FFN
  -> Combine #2: expert 输出回到原 token/rank
  -> Weighted sum: 按 router weights 加权聚合
  -> + shared expert path（若模型定义）

对 token tt：

yt=∑e∈TopK⁡(t)pt,eEe(xt)+Eshared(xt)y_t = \sum_{e\in\operatorname{TopK}(t)} p_{t,e}E_e(x_t) +E_{\text{shared}}(x_t)

Router 对每个 token 的当前 hidden state xtx_t 独立打分；它不直接读取 KV Cache 或其他 token。由于 xtx_t 已经过 Attention，它仍然包含上下文信息。每个 routed expert EeE_e 是一套独立 FFN 参数：它只对收到的向量执行 MLP，不需要历史 K/V，也不直接读取其他 token。

实际 kernel 通常不会一次只算一个向量，而是把路由到同一 expert 的 token 收拢成子 batch，再用 Grouped GEMM 执行。这会让性能依赖 tokens_per_expert、padding 和负载均衡，但不会改变 Expert FFN 的逐 token 语义。

在 Expert 跨 rank 放置的 EP 配置中，dispatch 通常构成第一次 all-to-all，返回 expert 输出的 combine 构成第二次 all-to-all。若 top-k expert 位于本地、模型运行在单卡，或 backend 使用不同的 fused/point-to-point 实现，则不能仅凭“这是 MoE”断言一定发生两次跨卡 collective。

这条路径的关键观测不是“有多少 expert”，而是：

tokens_per_expert distribution
dispatch bytes / duration
grouped GEMM shape / duration
combine bytes / duration
load imbalance and synchronization

若少数 expert 过热，慢 rank 会延长整个 collective 的完成时间；若 batch/chunk 太小，每个 expert 收到的 token 太少，grouped GEMM 也可能低效。

3. 并行切分策略

MoE 页只保留与 expert 数据流直接相关的边界：

  • EP（Expert Parallel）：不同 rank 持有不同 experts；token 通过 all-to-all 到 owner，再把结果送回；
  • TP（Tensor Parallel）：切一个过大的 expert 或 dense/attention 矩阵；会增加该层内部 collective；
  • DP：复制可服务的模型实例、分摊请求；通常不降低单实例权重显存；
  • PP：按层切 stage；降低每个 stage 的层数，同时引入流水与激活传输。

EP 的简化权重估算是：

Mweights,rank≈Mdense/attn shard+Nlocal expertsSexpert+Mshared expertM_{\text{weights,rank}} \approx M_{\text{dense/attn shard}} +N_{\text{local experts}}S_{\text{expert}} +M_{\text{shared expert}}

其中：

Nlocal experts≈Nrouted expertsNEPN_{\text{local experts}} \approx \frac{N_{\text{routed experts}}}{N_{\text{EP}}}

这只在 expert 均匀放置且没有 replica/冗余时成立。若单个 expert 在保留 KV 与 workspace 后仍放不进一张卡，简单 EP 不够，需要 expert 内 TP、PP 或其他切分。

完整并行选择、通信和拓扑合同见 推理并行策略。

4. 单 rank 显存合同

不要只把总参数除以 GPU 数。每 rank 的常驻与峰值显存至少包括：

Mrank≈Mdense/attn shard+Mlocal expert weights+MKV/state+Mactivation+MMoE workspace+Mcommunication buffers+Mruntime reserve\begin{aligned} M_{\text{rank}} \approx{}& M_{\text{dense/attn shard}} +M_{\text{local expert weights}} \\ &+M_{\text{KV/state}} +M_{\text{activation}} +M_{\text{MoE workspace}} \\ &+M_{\text{communication buffers}} +M_{\text{runtime reserve}} \end{aligned}

权重部分要使用实际 resident layout：

Mweight=Nparams×bpayload/param+Mscale+Mmetadata/paddingM_{\text{weight}} = N_{\text{params}}\times b_{\text{payload/param}} +M_{\text{scale}} +M_{\text{metadata/padding}}

Active 参数适合估算计算，不适合代替 resident weights。量化格式的 scale 粒度与模拟器实现见 FP4/FP8 量化 和 模拟器建模指南。

5. Residency、Offload 与通信

查证层：工程实现需要额外确认什么

低延迟 Serving 通常倾向让 local expert 权重常驻 HBM，因为按 token 或按层从 CPU/NVMe 取权重会引入带宽、排队和 miss penalty。但“必须全部常驻”不是脱离 SLO 的定律：离线、低并发或分层缓存场景可能接受 offload。

评估 expert cache / offload 时应记录：

resident experts, hit/miss rate, transfer bytes,
PCIe/RDMA/NVMe effective bandwidth,
load latency, overlap ratio, TTFT/TPOT impact

DeepEP 等库提供 MoE dispatch/combine 通信能力。吞吐、低延迟模式、精度路径与 overlap 能力随目标版本和拓扑变化，不能把单个公开案例的 EP 规模或倍数当成容量常量。

一个粗略的 activation 通信量起点是：

Vdispatch∝Ntokens×k×dhidden×bactV_{\text{dispatch}} \propto N_{\text{tokens}}\times k\times d_{\text{hidden}}\times b_{\text{act}}

Combine 还有返回流量。真实 per-rank 字节取决于 token 是否本地命中、路由分布、量化/压缩、冗余发送和 collective 实现，需用 trace 或通信计数器校准。

6. 从 Trace 判断 MoE 瓶颈

按以下顺序收集证据：

  1. Router 输出的 tokens_per_expert 是否倾斜；
  2. Dispatch/combine 是否处于 GPU 关键路径；
  3. Grouped GEMM 的每 expert MM 维是否过小；
  4. 慢 rank、网络链路或同步是否拖长 collective；
  5. Prefill chunk / Decode batch 的变化是否同时改变以上形状。

仅看到 NCCL 时间高，不能判断是网络带宽不足：上游计算迟到、负载不均或显式同步也会让 collective 包络变长。

相关页面

← 被以下页面引用(8)

修改历史8 次提交

相关阅读

推理并行：DP、TP、PP、EP 与 CP 怎么选模拟器建模指南：显存与吞吐公式DeepSeek-V3 Technical Report：中英对照解读