MoE 推理：Expert 并行与调度机制

1. Expert 的本质

每个 expert 就是一个独立的 SwiGLU FFN，包含三个权重矩阵：

• w1: [dim, inter_dim] — gate 投影
• w3: [dim, inter_dim] — up 投影
• w2: [inter_dim, dim] — down 投影

Dense FFN 中所有 token 共用同一组参数；MoE 中每个 token 经 router 选出 top-k 个 expert，只过这 k 个 FFN 并加权求和。

DeepSeek-V4-Pro 具体参数：

参数	值
Routed experts	384
Activated (top-k)	6
Shared experts	1 (始终激活)
moe_inter_dim	3072
dim	7168
每个 routed expert 大小	3 x 3072 x 7168 x bytes_per_param

关键区分：“49B activated” 只意味着每个 token 的计算量是 49B 级别，但显存必须容纳全部 1.6T 参数。 任何 token 都可能被路由到任何 expert，batch 越大 expert 访问越均匀。

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

Input x [bs, seq, dim]
    |
    v
+-- Gate/Router --+
|  scores = sqrt_softplus(x @ W_gate)  [bs*seq, n_experts]
|  top-k indices + weights (k=6)
|  Hash routing (前3层): 直接查 tid2eid 表
+-----------------+
    |
    v
+-- Dispatch (all-to-all) --+
|  EP模式: token 按 expert 归属发送到对应 rank
|  TP模式: expert 在本地，按 expert ID 分组
+----------------------------+
    |
    v
+-- Grouped GEMM --+
|  每个 expert 处理分配到的 token 子集
|  SwiGLU: silu(w1(x)) * w3(x) -> w2(...)
|  FP4 weight x FP8 activation (见量化页面)
+-------------------+
    |
    v
+-- Combine (all-to-all) --+
|  结果按原始 token 位置聚合
|  y[idx] += expert_output * weight
+---------------------------+
    |
    v
y += shared_expert(x)   <-- 所有 token 都过

Router 使用 sqrt_softplus 评分函数（非标准 softmax），前 3 层使用 hash routing 直接查 tid2eid 表绕过 learned gating。

3. 并行切分策略

并行方式	切什么	通信开销	适用场景
TP (Tensor Parallel)	每个 expert 权重按行/列切分	all-reduce per layer	小 expert 数，单节点内
EP (Expert Parallel)	每个 rank 持有 n_experts/EP_size 个完整 expert	all-to-all dispatch+combine	大 expert 数（如 384），跨节点
DP (Data Parallel)	每个 rank 完整模型副本，切 batch	仅训练 gradient sync	推理时 = 多实例
PP (Pipeline Parallel)	按 layer 切	send/recv 激活	超大模型 + 高吞吐
CP (Context Parallel)	按 seq_len 切 KV cache	all-gather KV	超长上下文

DeepSeek-V4-Pro reference code 使用 TP（expert 按 world_size 均分）：

self.n_local_experts = args.n_routed_experts // world_size  # 384 / TP

实际生产部署使用 EP（DeepEP），支持到 EP2048。

模拟器建模公式：

weights_memory [per-rank] = (n_local_experts x expert_size + shared_expert_size + attn_size) x bytes_per_param

其中 n_local_experts = n_routed_experts / EP_size。shared expert 和 attention 层不被 EP 切分。

4. Expert 常驻 vs Offload

策略	描述	代价	适用场景
常驻 GPU	所有 local expert weights 在 HBM	显存大	生产推理（延迟敏感）
Layer-wise loading	每层从 CPU/NVMe 加载当前层 expert	PCIe 4.0 ~32 GB/s 带宽瓶颈	离线/低吞吐
Expert Cache (LRU)	缓存热门 expert，冷 expert 按需加载	miss penalty 10-100ms	资源受限单卡
CPU/NVMe Offload	FlexGen 类 swap in/out	3-10x 延迟增加	研究/低成本部署

结论：生产 MoE 推理中 expert 权重必须常驻 GPU 显存（EP 切分后每 rank 的量）。Offload 仅用于资源极度受限场景。

5. DeepEP 工程实践

DeepEP 是 EP 专用的 all-to-all dispatch/combine 库：

• FP8 低精度通信支持
• V2: 统一高吞吐 + 低延迟 API 为 ElasticBuffer
• 支持 EP2048，SM 占用从 24 降到 4-6
• 0-SM PP/CP/Engram (RDMA)
• NCCL Gin 后端（轻量级）

对模拟器的影响：

• EP all-to-all 通信量 [per-rank] = bs x seq x dim x 2 x bytes / EP_size（dispatch + combine 各一次）
• 通信可与计算 overlap（DeepEP V2 设计目标）
• Overlap 条件：compute_per_byte >= 2 x d_moe = 6144 FLOPs/Byte

6. 与其他主题的关联

• Expert 权重的 FP4 存储机制详见 FP4/FP8 量化
• MoE workspace 的显存建模详见 模拟器建模指南
• MoE 框架支持对比详见 推理框架对比 2026
• KV cache 与 MoE 层的交互模式详见 CSA/HCA 注意力