MoE 混合专家推理：路由、负载均衡与显存策略

MoE 层的构成：
□ 共享 attention 部分（与其他层相同）
□ 多个专家（Expert）：每个专家是一个独立的 FFN
□ 一个路由网络（Router/Gating）：给 token 打分选专家
□ 推理时 token 只经过 Top-K 个专家 → 稀疏激活

与稠密模型对比：
□ 稠密 FFN：所有 token 走同一个 FFN
□ MoE FFN：总参数 = K× 单专家参数，激活仅 Top-K 个
  → 同样 FLOPs，参数量大得多 → 「大模型质量」
  → 每个 token 只算 K 个专家 → 「小模型速度」

代表模型：
□ Mixtral 8x7B：每层 8 专家，Top-2
□ DeepSeek-V3：细粒度专家 + 共享专家
□ Qwen-MoE、Grok：不同专家规模与路由策略

一次 MoE forward（Top-2，8 专家）：
token → router 打分 → 得分最高的 2 个专家
      → 结果按得分加权求和
□ 未激活的 6 个专家完全不参与计算
□ 但它们的权重仍占显存 → 显存压力来自「总参数」

路由打分：
□ router 输出每个专家的概率分布（softmax over 专家数）
□ 取 Top-K（如 K=2）个专家执行
□ 结果按概率加权求和（gating 加权）

为什么路由会不均匀：
□ 部分专家「全能」→ 几乎每个 token 都选它（热点）
□ 部分专家「冷门」→ 长期闲置
□ 热点专家所在 GPU 忙爆，冷门专家 GPU 空闲
  → 负载不均衡直接拉低整体吞吐

训练 vs 推理：
□ 训练用辅助负载均衡损失约束路由
□ 推理无法改路由，只能靠「调度/复制」缓解

路由打分示意：
token: "The cat sits"
router 输出（8 专家）：
  e0: 0.55  e3: 0.30  e5: 0.08  e7: 0.03 ...
→ Top-2 = e0, e3
→ 输出 = 0.55×e0(x) + 0.30×e3(x)（归一化加权）

EP 的做法：
□ 每个专家整块放在某一张卡上
□ attention 部分仍走张量并行（TP）
□ 路由决定 token 去哪些卡上的专家 → all-to-all 通信

为什么 EP 适合 MoE：
□ 专家天然是「可切分的独立块」
□ 卡 A 上的 token 要访问卡 B 的专家 → 必须搬 token
□ 相比把整个专家切碎做 TP，EP 通信更少、更直接

推理流程：
□ 每张卡算路由 → 决定本卡 token 的目标专家
□ all-to-all：把 token 发给对应专家所在卡
□ 专家计算 → all-to-all：把结果发回
□ 加权求和输出

EP 数据流示意（8 卡，专家分散）：
卡0 的 token t 路由到 e3（在卡3）
→ 卡0 ──all-to-all──▶ 卡3（发送 token 隐状态）
→ 卡3 上 e3 计算
→ 卡3 ──all-to-all──▶ 卡0（发送结果）
→ 卡0 加权求和，进入下一层

训练侧的约束（辅助损失）：
□ 训练时给 router 加负载均衡损失，惩罚「过热」专家
□ 让路由分布接近均匀 → 推理时天然更均衡
□ 但强约束会损失质量（专家分化被抑制）

推理侧的缓解：
□ 专家复制（Expert Replication）：
  - 热点专家在多个 GPU 上放副本
  - 路由被分散到副本，忙闲重排
□ 调度优先：把 token 多的卡上的请求降优先
□ 虚拟专家：把大专家拆成小片，更细粒度分布
□ 路由缓存：相似 prompt 复用已学到的路由结果

专家复制示意：
热点专家 e0 在卡0 满载
→ 在卡2、卡5 各放一份 e0 副本
→ 路由把 e0 的 token 平均到 3 个副本
→ 卡0 压力 1/3，卡2、卡5 的冷门资源被利用

代价：
□ 副本占用额外显存
□ 副本间的一致性：同一专家多份权重需同步（推理只读，无问题）

激活内存问题：
□ 每个 token 经过多个专家 → 每个专家的输出都要暂存
□ 稠密模型激活随 batch 线性增长
□ MoE 激活随「batch × 专家数」增长 → 显存压力更大

缓解手段：
□ 减少中间激活的驻留：一次只算一个专家、即时加权
□ 序列专家（Sequence Expert）：
  - 把整个序列（batch）一次性喂给一个专家
  - 减少 per-token 的跨卡通信次数
  - 提升专家计算的批量效应（大 GEMM）
□ activation checkpointing 式重算（节省峰值显存）

通信量分析：
□ all-to-all 传输量 ∝ 跨卡 token 数 × hidden 维度
□ 路由越分散（K 大、专家分散广）→ 通信越大
□ 大批次 → 单次通信体积大，但次数少

通信体积估算：
每 token hidden = 4096 × 2 bytes（FP16）= 8 KB
10K token 跨卡传输 = 10K × 8KB = 80 MB（一次 all-to-all）
→ 网络（NVLink ~900 GB/s / 网卡 25 GB/s）是主要瓶颈

显存压力来源：
□ 全部专家权重常驻显存（即使未激活）
□ 70B 稠密 ≈ 140 GiB；8x7B MoE ≈ 140+ GiB（8×7B FFN）

三大策略：
□ 专家 Offload（分级存储）：
  - 热专家（高频路由）在 GPU
  - 冷专家（低频路由）放 CPU RAM / NVMe
  - 被路由到冷专家时现场加载 → 吞吐换容量
  - 冷热划分基于路由统计，动态调整
□ 专家量化：
  - 不活跃专家用低精度（INT8/FP8）常驻
  - 活跃专家保留高精度 → 混合精度管理
□ 投机专家（Speculative Experts）：
  - 先用「轻量路由/小专家」猜结果
  - 只在必要时唤醒大专家 → 减少专家计算量

Offload 决策示例：
┌─ 路由统计 ───────────────────────────┐
│ e0: 45%（热）→ GPU 常驻 FP16        │
│ e3: 28%（热）→ GPU 常驻 FP16        │
│ e1: 12%      → CPU RAM（FP8）       │
│ e5: 6%       → CPU RAM（FP8）       │
│ e2/e4/e6/e7: <5%（冷）→ NVMe 懒加载 │
└──────────────────────────────────────┘

组合方式：
□ 节点内：TP（attention 张量切分）+ EP（专家分布）
□ 节点间：EP 跨节点（all-to-all 走网卡）
□ 数据并行（DP）：多副本处理不同请求

拓扑考量：
□ 节点内 NVLink：带宽高，适合 attention TP 与专家跨卡
□ 节点间网络（RDMA/网卡）：带宽低，EP 通信受限
□ 把「跨节点通信」降到最少：
  - 尽量让同一序列的专家落在同一节点
  - 路由局部性：按前缀聚类请求，减少跨机路由

可扩展性：
□ EP 扩展的是「容量与带宽」，单 token 延迟不降
□ DP 扩展的是「并发吞吐」
□ 需要超大模型：TP+EP+DP 三维组合

8 卡节点 × 2 节点，8x7B 模型：
□ attention：TP=8 在节点内（NVLink）
□ experts：EP=16 跨节点（部分跨机 all-to-all）
□ 或：experts EP=8 节点内 + DP=2 两副本
→ 选型看「跨机网络带宽」能否承受路由分散

稀疏优势：
□ 同样 FLOPs：8x7B Top-2 ≈ 激活 2/8 专家
  → 每 token 计算量 ≈ 稠密 12B-14B 级别
□ 同样质量：达到稠密 70B 质量，计算量小很多
□ 单 token 延迟接近小模型，生成质量接近大模型

瓶颈与成本：
□ 显存：全部专家权重常驻 → 需要大显存或 offload
□ 通信：all-to-all 在 batch 大、K 大时成为瓶颈
□ 批量效率：专家间负载不均 → 部分卡闲置
□ 路由开销：多一跳路由计算

经济账：
□ 硬件成本：显存需求高（总参数大）
□ 运行成本：每 token 计算少（激活少）→ 电费/时延低
□ 场景适合：大并发、质量敏感、长输出
□ 场景不适合：显存小、短 prompt、极低延迟

粗略对比（质量相近的场景）：
模型           每token计算     显存需求     单卡延迟
稠密 70B       ~70B 激活       ~140 GiB    高
MoE 8x7B Top-2 ~14B 激活       ~140 GiB    中（更小 batch 时）
→ 计算省 ~5x，显存不变 → 显存是 MoE 的第一成本

工程经验：
□ 路由统计先行：上线前统计路由分布，规划热/冷专家
□ 冷热动态调整：路由随业务变化，定期重划分
□ EP 拓扑按网络带宽选：NVLink 充足再开跨节点 EP
□ 与量化配合：专家低精度常驻是显存的第一杠杆

高频踩坑：
□ 忽略路由不均 → 热点卡 100% 利用率、其他卡 30%
□ 专家 offload 阈值设太低 → 高频专家被挪到 CPU → 延迟崩
□ batch 拉大后通信爆炸 → all-to-all 拖垮整体吞吐
□ 冷专家加载无预热 → 首次路由到冷专家时卡顿数秒
□ 用稠密模型的压测方法测 MoE → 负载模型完全不对

验证手段：
□ 每专家路由次数直方图（负载均衡的第一指标）
□ 每卡利用率（EP 是否真的均匀）
□ all-to-all 通信量与耗时（通信占比）
□ 端到端吞吐与 P99（稀疏优势是否兑现）

生产配置示意（vLLM / SGLang 类引擎）：
--model mistralai/Mixtral-8x7B-Instruct
--tensor-parallel-size 8      # attention TP
--expert-parallel-size 8      # 专家 EP（节点内）
--max-model-len 32768
--kv-cache-dtype fp8