MoE 的路由是怎么挑专家的？每次提问的分诊

同一个 MoE 大模型，回答数学题和写文案时内部启用的模块并不相同，这个切换动作由 MoE 路由完成：提问进来，先打分再放行，只让少数专家参与计算。这套分诊机制决定了混合专家模型的效率从哪来，也解释了它为什么偶尔「偏科」。

门控打分：算出每位专家的匹配度

路由本体是一个很小的门控矩阵。一个 token 的特征向量进来，与门控矩阵相乘，给每位专家各算一个分数，再把分数归一化成一组比例。出去的是一张带权重的名单：专家甲 0.6、专家乙 0.3，其余接近零。整个过程像医院分诊台快速判断该去哪个科室。

类比只到这里为止：分诊护士靠经验，路由靠训练中学到的权重，它的判断完全是数值上的匹配度，没有语义理解。分数高只说明这个 token 的特征与该专家擅长处理的模式相似，这是类比之外必须分清的部分。

前几位放行：省算力的关键一步

分数排完序，路由只保留靠前的少数几位，常见配置是两位，其余专家本轮关门。被选中的专家各自处理这个 token，输出按分数加权合并成最终结果。只挑两三位而非全员上阵，正是混合专家省算力的关键：总参数几百 B 的模型，每次真正参与计算的只有零头。

可带走的判断：一次提问并不对应一次分诊。模型逐 token 生成，每个 token 都重新过一遍门控，所以同一段回答内部可能频繁切换专家，前后用到的模块组合并不相同。

分数为什么有高有低

门控矩阵的权重来自训练。某类输入反复走向某位专家并带来更低误差时，这条通路被强化，专家随之分化：有的擅长代码符号，有的擅长数字运算，有的擅长常见搭配。分化没有人工指派，全部由误差信号自发形成。

也因此路由偶尔会选错：两个分数接近时，选哪个带随机性，回答的不稳定感有一部分来自这里。DeepSeek 的开源混合专家模型在技术报告里公开了路由设计，想核对细节按报告口径查阅；通义千问的部分版本也采用了类似思路。

路由不管的两件事

两条常见误会要划清：其一，路由不参与内容生成，它只决定谁上场；其二，路由的打分对象是每个 token，句子层面并不存在一个「选题专家」。词向量怎么来的，见 字节级分词；专家忙闲不均怎么办，见 负载均衡 的设计；专家怎么计入总参数，见 参数量 的账本。

记住一句话：MoE 路由是每次生成都要重跑的小分诊台，打分、放行、加权三步走完，被选中的专家才开工。

MoE 路由流程速查

• 进来：一个 token 的特征向量
• 打分：与门控矩阵相乘，得出每位专家的分数
• 放行：按分数排序，只留靠前的两三位
• 出去：选中专家的输出按分数加权合并

排查回答忽好忽坏时，先想到分诊环节的波动，再去调采样参数。

关于MoE路由再多问三句

• 路由会把我的提问发到外部服务吗？：不会。它只在模型内部给专家打分排序，所有动作都发生在一次前向计算里。
• 同一个问题问两次，走的专家会不同吗？：可能不同。分数接近时排序有波动，这是它的正常表现，多数时候不影响答案质量。
• 专家数量越多效果就越好吗？：不一定。专家多意味着总参数大，但每次只激活少数几位，收益取决于训练时分化是否充分、忙闲是否均衡。