最近选型大模型时发现一个现象：稍微大一点的模型，架构介绍里基本都有"混合专家"（MoE）这个词。稠密模型（Dense）也不是不能用，但大家似乎都在往 MoE 转。今天结合这几年跟项目的经验，把 MoE 这件事掰开讲清楚。

## 一句话讲明白 MoE

传统大模型是"全员上阵"：每个 token 输入，模型里所有参数都参与计算。MoE 是"按需点将"：模型里养了一堆"专家"（expert）子网络，输入进来后由一个"门控网络"（gating/router）决定：这 token 只需要哪一两个专家来处理，其他专家直接跳过。

总参数量可以很大（几百 B），但每次推理实际激活的参数只有一小部分（比如总量的十分之一左右）。这就是"稀疏激活"的核心：容量大、开销小。

## 为什么推理成本低了

推理成本主要跟"每次前向实际激活的参数"相关，跟总参数关系不大。MoE 相当于用更大的总参数换来了更强的知识容量，却只付出小模型的推理代价。我在做客服场景选型时对比过同档体验的模型，MoE 版本的单次推理耗时和显存占用明显低于同等总参数的稠密模型——当然这是定性结论，具体数字跟部署环境强相关。

## 选型时要看的三点

**1. 路由稳定性。** 门控网络如果把 token 分得很不均匀（某些专家闲置、某些过载），实际效果会打折。问厂商要负载均衡相关的说明，看他们有没有处理"专家塌缩"的机制。

**2. 专家并行的部署要求。** MoE 的专家可以拆到不同卡上（专家并行），但这意味着推理时卡间通信不能是瓶颈。机房里卡间带宽拉胯的话，MoE 的优势会被通信吃掉一部分。单卡部署小规模 MoE 反而可能不如稠密模型顺手。

**3. 微调的坑。** 全参数微调 MoE 成本高；只微调门控或部分专家是常见做法，但我踩过的坑是：微调后路由分布变了，原本均衡的专家负载被打破，上线后延迟抖动变大。微调完一定要重测负载分布。

## 实战建议清单

- 推理预算紧张、但想要大模型知识容量的场景，优先看 MoE 路线
- 部署前先确认卡间互联带宽，别只看单卡算力
- 微调后必做路由负载复测，别只看 loss 下降了就上线
- 小团队第一次上 MoE，建议先用成熟的开源 MoE 模型跑通链路，再考虑自研

## 结尾讨论

你们在生产环境用过 MoE 吗？路由不均衡的问题是怎么发现的、又是怎么解的？欢迎分享实战经验。