MoE 路由实验：激活预算与专家热区

这个实验把 MoE 的部署问题压缩成三个量：总参数 $P$、专家总数 $E$、每 token 激活数 $k$。激活参数约为 $P k/E$。

缓存覆盖

若设备只能常驻 $C$ 个专家，常驻比例为 $C/E$。覆盖不足时，token 需要读取未常驻专家，权重读放大和换入延迟上升。批处理可以摊薄读取，但不能消除热点。

路由偏斜

理想均匀路由下，每个专家承担相近 token 数。真实路由可能集中在少数专家。偏斜并不总是坏事，它意味着专家更专注；但对服务系统，它会把负载集中到少数设备。

用 MoE 路由实验 调整专家数、top-k、缓存槽和偏斜。观察激活参数下降时尾延迟放大是否同时下降。

记录方式

报告 MoE 结果时，至少附上：总参数、激活参数、专家数、top-k、批大小、并行方式、带宽和路由分布。缺少这些条件，参数量对比没有工程意义。

公式与参数

实验用总参数、专家总数、每 token 激活专家数、缓存槽和路由偏斜来估算系统压力。一个简化的激活参数为：

$$P_{\text{active}} \approx P_{\text{total}} \times \frac{K}{E}$$

其中 $K$ 是 top-k，$E$ 是专家数。这个近似默认所有专家大小相同、注意力和其他层不随专家数变化，且路由均匀。实际 MoE 还有共享专家、门控和通信开销，因此它只能用于量级比较。

缓存常驻比例是 $C/E$。缓存不足时，token 可能触发专家换入，增加带宽和首 token 延迟。路由偏斜越高，热点专家越可能超过均匀负载，导致尾延迟放大。实验用偏斜度给出一个相对放大因子，而不是某一硬件的真实延迟。

如何解读结果

如果激活比例下降，但缓存槽很少、偏斜很高，那么“计算量变少”可能被专家加载和排队抵消。若总参数不大、专家数很少，路由收益也会有限。把实验中的有效吞吐或缓存命中当作真实性能之前，需要补充批大小、专家并行拓扑、all-to-all 带宽和 batch 内 token 分布。

一个实用的方案比较顺序是：

1. 用真实数据统计每个专家的 token 数；
2. 计算热点专家所在设备的最坏负载；
3. 估算每 token 的专家读取和通信字节；
4. 在目标硬件测冷启动、热缓存和缓存淘汰；
5. 分别报告平均吞吐与 P95/P99。

失败模式

路由偏斜可能来自训练分布、批内重复文本或路由器参数退化；缓存槽太少会让热门专家不断被换出；专家并行可能让一次请求跨多张卡，通信时间超过计算节省。对端侧设备，专家权重还可能与 Flash/DRAM 的随机读取模式冲突。任何一项都可能让“低激活参数”无法转化为低延迟。

实验是讨论架构风险的工具，不是模型质量评测。真正的选型应同时看任务准确率、内存占用、最坏延迟、能耗和可维护性。只有这些维度一起达标，MoE 的稀疏性才是工程优势。

别把激活比例当作性能预测

激活比例只描述计算量的一部分。若每 token 需要从远端加载专家，网络延迟可能远大于矩阵乘节省；若 batch 很大，专家读取可以被摊薄，但对缓存和带宽的要求更高。你可以把实验中的缓存槽调小，观察常驻比例下降如何增加对未缓存专家的依赖，再结合目标硬件的读取延迟判断是否需要专家复制或分层放置。

对于面试或方案评审，建议先给出一个预算表，再给出结论：总权重、每 token 激活权重、可用内存、专家并行带宽、热点专家占比和目标 P99。没有这些数字，“MoE 更省”只是一个未经定义的形容词。实验页提供的是这些量之间的敏感性关系，真实系统还需要用 trace 和负载分布替代假设。

如果要把它用于端侧选型，应额外检查随机读带宽、Flash 颗粒延迟和热缓存策略。专家数量增加会让模型更容易“参数很大、局部读取很碎”，而一个稳定的稠密小模型可能更适合硬实时任务。选择标准应落在可预测的 P99 和能耗，而不是单个平均 token/s。

实验里的偏斜度不是模型训练指标，而是用来模拟热点分布的灵敏度参数。真实路由需要从校准集采样并画直方图；如果分布随时间漂移，缓存策略也要周期性重估。把路由分布当作静态图表，是 MoE 容量规划最常见的盲点。

若采用专家并行，还应把 all-to-all 的同步时间加到每个 token 的关键路径中。一个批量很大、通信充分的配置可能吞吐很高，却不适合单请求交互；最终选择要按交互占比和 P99 目标决定。

交互型服务还应记录路由抖动，避免同一问题在相邻请求间频繁切换专家集合。

把路由、缓存和通信指标同时展示，才能判断稀疏结构是否真的改善了用户体验，而不是只改善了平均算力利用率。

如果无法同时说清这三类成本，最稳妥的结论是缩小模型或继续观察，而不是盲目增加专家数量。

专家越多并不自动越聪明，系统边界才是部署成败的分水岭。

把专家数量当作唯一目标，最终只会得到更昂贵的复杂度。

只有把服务目标写清楚，稀疏模型的选择才值得讨论。

这也是工程评审的起点。