稀疏 MoE：参数规模不等于计算规模

MoE 的核心是把前馈层拆成多个专家，每个 token 只路由到少数专家。若总参数为 $P$、专家数为 $E$、每 token 激活 $k$ 个专家，激活参数可粗略写成：

$$P_{\text{active}} \approx P \times \frac{k}{E}$$

这个比例解释计算侧的稀疏，却不能解释部署成本。

显存与通信

所有专家都需要存储；若专家分散在多张 GPU 上，token 路由会产生 all-to-all 通信。批越大，专家计算越容易摊薄通信；批很小时，通信和调度开销可能超过节省的 FLOPs。

路由偏斜会制造热门专家。即便平均激活参数很低，热点专家仍可能成为尾延迟来源。负载均衡损失、容量因子和 token drop 策略都会影响质量与吞吐。

结构差异

Mixtral 展示了稀疏专家语言模型的可扩展性；DeepSeekMoE 进一步讨论更细粒度专家和共享专家，以改善参数效率。专家剪枝研究说明，部分专家可以被移除或跳过，但必须基于路由统计和校准数据。

MoE 路由实验 展示总参数、激活专家、缓存槽和路由偏斜的关系。它不模拟通信，因此结果只是计算与缓存侧的量级。

结论

评价 MoE 应同时报告总参数、激活参数、专家数、top-k、并行策略、批大小、通信带宽和尾延迟。只写“47B 参数、13B 激活”不足以判断服务成本。

先把参数账本写对

MoE 的“稀疏”描述的是每个 token 激活多少专家，而不是部署时只保存多少权重。模型总参数可能仍然很大，所有专家都需要存储；每 token 只经过部分专家，才降低矩阵乘工作量。若模型总参数为 $P$，每层有 $E$ 个专家、top-k 为 $K$，一个粗略的激活比例为 $K/E$，但这只适用于专家同尺寸、路由均匀且忽略共享专家的情形。真实结构还要加上门控、共享专家、注意力层和输出层。

可以用一个示意表格区分不同成本：

成本项	由什么决定	稀疏化后是否自动下降
权重存储	总专家数与精度	否，所有专家通常都要常驻或被换入
单 token 计算	top-k 专家比例	是，但取决于 routed token 的批处理
HBM 读取	活跃专家、缓存命中、批次	不一定，热点专家仍会被反复读取
通信	expert parallel、all-to-all	不，甚至可能增加
尾延迟	最忙专家和路由偏斜	不，偏斜会制造长尾

所以“47B 总参数、13B 激活”只回答了一个维度：每个 token 大约经过多少参数。它没有回答权重是否装得下、专家并行需要多少通信、热点专家是否拖慢 P99，也不能直接推导出吞吐提升。

路由为什么会产生尾延迟

MoE 路由器通常为每个 token 选择 top-k 专家。训练时为了让负载均衡，会使用辅助损失、容量因子或 token dropping；推理时则更关注路由稳定性和缓存。若请求分布集中在少数专家，这些专家所在设备会成为热点，而其他设备空闲。扩大批处理可以摊薄权重加载，但也会增加同步和内存压力。

以 64 个专家、top-2 为例，每个 token 只激活 2 个专家，却可能在不同上下文中选择任意两个。若专家参数需要从远端设备读取，一次 token 的路由就会变成小型网络请求。专家缓存能减少重复加载，但缓存容量有限；热点专家被淘汰时，下一次请求会重新付出传输延迟。平均 token/s 很好，不代表最慢请求也能在截止期内完成。

结构选择与训练约束

Mixtral 的稀疏专家结构展示了在推理时用较少激活参数获得较大模型容量的思路；DeepSeekMoE 讨论了细粒度专家与共享专家，把通用知识和高频模式放在共享部分，减少专家路由的碎片化。专家剪枝研究则说明，部分专家可以在校准后剪掉或跳过，但剪枝策略必须依据真实路由统计，而不是按参数位置随意删除。

这三类工作提示我们：MoE 不是简单的“把 FFN 复制很多份”。门控初始化、负载均衡、专家尺寸、共享比例和微调数据都会影响专家是否真正专精。一个训练损失更低的结构，如果造成路由极端偏斜，也不一定适合低延迟服务。

端侧 MoE 的现实边界

端侧模型的内存和功耗更紧。即使 top-k 很小，模型也可能需要加载多个专家；Flash 存储降低容量成本，但随机读取会增加延迟。移动端可以把专家分成常驻、热缓存与按需加载三层，训练端则要约束路由，使常用专家与硬件层级匹配。这里的优化目标不是最高参数规模，而是在给定 SRAM/DRAM 预算下的稳定首 token 时间和能耗。

端侧评估至少需要报告：

1. 全模型权重和单个专家的大小；
2. 目标设备的常驻内存与可用带宽；
3. top-k 路由在真实输入上的分布；
4. 专家缓存命中率、换入次数和冷启动延迟；
5. 稀疏化对任务质量和长尾输入的影响。

评测时不要只看平均激活

一个可复现的 MoE 报告应固定总参数、专家数、top-k、精度、batch、序列长度和并行拓扑，并分别报告 prefill、decode、吞吐、P95/P99 延迟和显存峰值。最好提供路由分布直方图和每个专家的负载，否则读者无法判断“稀疏”是否真的降低了系统成本。

MoE 路由实验 用总参数、专家数、激活专家、缓存槽和偏斜度来演示这些关系。它是预算模型，不是对某个具体模型的 benchmark。把结果写成工程结论时，必须同时写出“计算少多少”和“内存、通信、尾延迟转移到了哪里”。

一个部署决策表

MoE 是否值得使用，取决于目标约束，而不是单看 benchmark：

目标	MoE 可能有利	MoE 可能不利
提升模型容量	总参数增加但每 token 计算受 top-k 限制	显存和专家管理成本上升
降低单 token 计算	激活比例低且 batch 足够大	路由开销、通信和换入吃掉收益
端侧部署	只常驻少量专家，按需加载	随机读取和冷启动破坏实时性
高吞吐服务	专家并行与批处理摊薄权重读取	热点专家、all-to-all 和同步造成尾延迟
简化运维	可用专家池和共享专家复用	路由版本、专家放置和负载均衡更复杂

选择前先回答“我最需要降低的是权重读取、计算、显存还是延迟”。MoE 很少同时改善四项；它通常把一种成本换成另一种。只有用目标任务的真实 token 分布和硬件 profile 测量，才能判断交换是否值得。

可观察指标与回归

一条稳定的评测流水线应记录：总参数、激活参数、专家数、top-k、每个专家负载、缓存命中率、每 token 读取字节、并行通信时间、P50/P99 延迟和任务准确率。每次改变专家数或路由损失时，不只看平均吞吐，还要检查长尾输入是否集中到同一批专家。如果专家负载长期偏斜，应考虑容量因子、辅助均衡、专家复制或剪枝，而不是继续扩大总专家数。

最后保留一个简单基线：同样任务下，一个较小的稠密模型需要多少显存、多少延迟、多少准确率。只有当 MoE 在目标约束下明显优于基线，且运维复杂度可接受时，稀疏结构才是工程收益，而不只是参数表上的漂亮数字。

训练与推理的 MoE 成本也不能混用。训练需要考虑专家并行、梯度同步和容量因子；推理需要考虑权重常驻、路由缓存和批处理。一个在训练基准上表现良好的稀疏结构，可能因为推理 batch 太短或专家通信过多而不适合线上。选择结构时先写清目标阶段，再讨论激活比例。

如果团队暂时无法做完整 MoE 服务，可以先实现一个路由日志和专家负载分析原型，用稠密模型模拟路由分布。这样能在不部署大模型的情况下验证负载均衡、缓存大小和尾延迟问题。参考实验页的敏感性模型，先固定硬件和预算，再逐步替换为真实测量，是较稳妥的落地路径。

在评估结果中，最好同时给出一个“不采用 MoE”的对照方案。很多团队需要的其实是更小的稠密模型、更好的量化或更高效的注意力，而不是更复杂的专家路由。MoE 的工程成本包括专家放置、路由版本、负载均衡和通信调优，只有在容量与质量收益足够大时才值得承担。把这条取舍写清楚，比宣称稀疏一定先进更专业。

对于边缘设备，专家路由还意味着冷启动不可预测。一个首次出现的输入可能触发多个专家加载，导致帧时间尖峰。实时系统应限制单帧允许的专家换入次数，必要时回退到较小的常驻模型。平均能效不等于可调度性，最坏路径才是控制系统的验收标准。

这条约束应写进部署前检查表，而不是等线上出现尖峰再补。

最终，稀疏结构只有把计算、内存、通信和最坏延迟同时纳入预算，才算真正落地。

对研究复现而言，建议同时保留 dense baseline 和 MoE 的路由 dump。路由 dump 能让你重放同一批 token，比较专家缓存、专家剪枝和并行拓扑的影响；dense baseline 则回答“是否真的需要 MoE”。只报告 MoE 与另一个 MoE 的对比，无法说明结构本身是否值得。

如果数据分布会随时间变化，定期重新采样路由并检查专家使用率。长期偏斜可能意味着专家训练不足、路由塌缩，或者任务已经变化。把路由分布当成可观测指标，而不是一次训练结束后的静态结论，才能让 MoE 系统在长期运行中保持可用。

最终的选择标准不是专家数量，而是目标任务下的质量、显存、通信和最坏延迟是否同时优于 dense baseline。四项都通过，MoE 才是工程方案；只要有一项明显退化，就应该把稀疏结构当作实验假设，而不是产品结论。

把这条标准提前写给团队，可以避免为了追逐参数规模而引入无法运维的系统。

一个值得采纳的 MoE 方案，应该能用一句话说明它在哪种请求分布下比 dense 更好，以及在何时必须退回 dense。说不清适用域，就说明选型还停留在参数表层面。

更进一步，团队应保存触发退回的监控条件，例如专家缓存命中率、P99 延迟或路由器偏斜度。这样系统在流量变化时能自动切换，而不是等到用户投诉才发现稀疏模型不再适合当前负载。

可切换、可回退的 MoE 才是生产方案，静态参数表上的稀疏比例只是起点。

在发布记录中写清切换阈值和回退步骤，才能让值班人员安全地处理专家热点。