医院不会让一位医生既看骨科又看皮肤科，它靠分诊台把病人引向对应的专科。大模型里的 MoE（混合专家，Mixture of Experts）借的就是这个思路：把一整个模型拆成许多「专家」，每个词进来时只请其中几位帮忙。这些专家不是真人，也不是独立程序，而是模型内部一小块一小块的参数。
专家到底长什么样
MoE 模型内部有一个「路由器」，角色类似分诊台。每个 token（可以粗略理解为文本的一个片段）到达时，路由器依据它的数值特征，从几十上百个专家里挑出少数几位处理，其余专家这一步完全不参与。所谓专家，本质上是一层前馈网络的一组参数，训练过程中因为「各接各的活」，逐渐形成了分工差异。
带走一个判断：专家分工是训练自然涌现的，不是工程师手动划定的科室。你在任何模型卡片上都查不到「3 号专家专管语法」这种说明。
医院类比的边界在哪
这个类比讲到「分诊、专科」就够用，再往下推会误导你。真实医院的专科边界清晰，MoE 的专家分工却是模糊的：多位专家可能都「会一点」同类问题，路由结果还随上下文变化。另外，医院分诊看的是症状描述，MoE 的路由看的是 token 的数值特征，和人能读懂的「主题」根本不是一回事，所以别指望按问题类型预测激活了哪些专家。类比只负责带你进门，进门之后的机制，得靠模型卡的架构说明和实测体感来补。还有一点和医院不同：一位病人通常只挂一个科，而路由可能同时请多位专家一起「会诊」，这也是它表达能力的一部分来源。
| 医院里的角色 | 模型里的对应 | 类比的边界 |
|---|---|---|
| 分诊台 | 路由器 | 按 token 数值特征挑人，不看症状描述 |
| 专科医生 | 一组前馈网络参数 | 分工由训练涌现，没有科室名录 |
| 病人挂一个科 | 一个 token 激活少数专家 | 路由可能同时请多位「会诊」 |
专家很多，为什么反而省算力
关键在「只请几位出场」。总参数很多、每次激活的参数很少，这正是 MoE 能同时做到知识面广、响应快的原因，也是它总与激活参数量成对出现的原因。通义千问和 DeepSeek 的部分开源版本都采用了这种架构，模型页上常见「总参数/激活参数」两个数并排，详细信息看对应的模型卡片。代价也有：总参大意味着要存的数字多，权重文件体积随之上涨，下载前要有心理准备。另一个常被忽略的点：MoE 省的是计算量，省不了显存——所有专家的权重都要驻留显存，哪怕大部分不参与当次计算，显存不够的话再聪明的路由也帮不上忙。
稠密模型与 MoE 一眼对照
- 参数使用：稠密全员参与；MoE 按词点名几位专家。
- 速度来源：稠密靠参数总量适中；MoE 靠激活参数少。
- 规格写法：稠密只给一个 B 数；MoE 常给两个数。
- 人工干预：路由由模型自动完成，使用者不用管也管不了。
下次看到「激活 14B」的字样，你应该能立刻反应过来：它背后站着一支更大的队伍。
日常用腾讯元宝这类在线助手时，你感受不到这套机制的存在；它真正进入你的视野，是在你挑选、部署开源模型，需要权衡速度与显存的那一天。
关于MoE专家的三个追问
- 专家越多模型越强吗？：不一定。专家数量增加会扩大总参数规模，但效果还取决于训练质量与路由机制的设计，盲目堆专家可能得不偿失。
- 能指定让某位专家来回答吗？：不能。路由由模型自动完成，使用者既看不到专家名单，也干预不了分配过程。
- 在聊天应用里能感受到专家切换吗？：感受不到。界面上只有回答结果，内部哪些专家参与属于模型自己的事。
