几千亿参数为什么只用一小部分？MoE 的路由与专家

文章目录1 - 引言2 - 专家是参数模块不是坐在模型里的几位顾问3 - 三笔不同的账参数容量、单次计算与实际部署4 - 路由不是简单挑最大值训练还要避免专家闲忙不均5 - 评估 MoE最好把系统条件写在成绩旁边1 - 引言模型介绍里的“总参数”和“激活参数”往往会差出好几倍。准备部署时到底该拿哪一个数字估显存如果先按激活参数下载权重、准备机器可能在模型还没开始生成之前就发现根本装不下。原因不复杂没有参与当前计算的权重仍然要保存在某处。单个 Token 只访问两个专家同批的其他 Token 却可能访问另外几个。混合专家模型也就是 Mixture of Experts把参数容量和单次计算路径部分分开了显存、计算和搬运数据的账也得跟着分开算。2 - 专家是参数模块不是坐在模型里的几位顾问“专家”这个名字很容易让人联想到分工明确的人数学交给数学专家代码交给代码专家历史问题交给历史专家。实际 MoE 通常没有这么清晰的人工岗位。专家是一组可训练的网络参数输入由路由器根据隐藏表示进行分配。训练后可能出现某些专门化现象但不能仅凭专家编号给它贴上确定的学科标签。在许多 Transformer MoE 设计中稀疏替换主要发生在前馈网络部分。Token 经过共享的处理后路由器为候选专家打分选中其中几个再将这些专家的输出按权重组合起来。注意力、归一化、嵌入等部分是否共享取决于模型的具体结构不能假设整座网络都被平均分成了若干独立模型。如果某层有八个候选专家每个 Token 只进入两个这叫 Top-2 路由的一种直观形式。另一些设计使用 Top-1、更多专家或者额外设置始终参与计算的共享专家。路由概率怎样归一化、是否限制专家容量也都有不同实现。因此MoE 与“同时问多个完整模型再投票选答案”不是一回事。后者通常属于模型集成需要分别完成多次模型推理MoE 的专家选择发生在网络内部而且同一 Token 在不同层可能走不同路径。Switch Transformers 原始论文是理解稀疏路由、容量与训练问题的一个基础入口。3 - 三笔不同的账参数容量、单次计算与实际部署为了建立数量感可以先做一个不涉及具体产品的简化计算。假设共享部分有 20 亿参数八个候选专家各有 10 亿参数每个 Token 选两个专家。粗略看总参数是 100 亿而与这个 Token 相关的活跃路径包含约 40 亿参数。这个计算适合说明容量与激活量的区别却不足以估计端到端耗时。注意力计算会随序列条件变化专家之间可能分布在不同设备上数据的派发与回收也需要时间。参数计数并没有包含这些因素。如果全部 100 亿参数都采用每参数两字节的存储方式仅权重本身就约需要 200 亿字节尚未计入运行时缓存、临时张量、框架开销和训练状态。量化、卸载与分布式放置可以改变具体内存布局但不能把“激活 40 亿”直接换算成“只需要保存 40 亿”。常见说法更准确的理解激活参数少所以模型文件小模型文件通常仍需要包含全部专家权重每个 Token 只用两个专家所以整批也只用两个不同 Token 可能选择不同专家批次覆盖面会扩大MoE 一定比同等激活量的稠密模型快还要计算派发、通信、负载和内核效率专家越多效果就一定越好专家需要获得合适的训练和有效路由多张卡把专家平均放置就能解决问题Token 分布可能不均设备间负载也会不均当专家分布在不同设备上时系统需要把相应 Token 送到对应设备再收回输出。这类专家并行可以支持更大的模型但网络连接、批量大小和跨设备流量都可能成为限制。单个请求的延迟与大量请求的总吞吐也可能表现不同。输入处理与逐步生成也会呈现不同负载。一次处理长提示时可派发的 Token 较多同一个专家可能收到一批输入较容易形成有效的矩阵运算单请求逐 Token 生成时每次派发的数据很少调度与读权重的开销就可能更突出。增加并发能够改变批量形态却也会增加排队和缓存需求。因此预填充阶段快不足以证明生成阶段也按同样比例变快。假设只有一张显卡放不下全部专家把部分权重保存在主机内存是一种可能的部署方式。但这时就要回答下一批需要的专家是否已经在设备上缓存没命中时搬运多少数据不同请求的专家选择会不会互相挤占缓存这些条件决定卸载是否可接受。它并不是“没有激活的专家不存在”而是把保存与搬运安排到了别处。对部署者来说模型介绍里的激活参数更适合帮助理解计算结构而不是代替显存测量。真正有用的容量记录应包含权重精度、并发数、输入长度、输出长度、设备拓扑和运行时版本。4 - 路由不是简单挑最大值训练还要避免专家闲忙不均如果所有 Token 都选择同一个专家理论上的稀疏模块就变成了一个很忙的模块和若干几乎没有训练机会的模块。忙的专家可能触及容量限制闲的专家则难以学到有效表示。专家数量虽然没有减少能够被有效利用的容量却可能缩水。负载均衡的目标是缓解这种情况但平均分配本身也不是最终目的。对不同输入做有意义的选择与让所有专家工作量相同并不总是完全一致。过度追求均匀可能妨碍专门化完全不约束又可能出现路由集中。不同模型会采用辅助损失、路由偏置、容量设置或其他机制来平衡这些目标。容量问题可以用一个小场景理解。某批有十六次专家分配其中十二次都指向同一个专家如果系统只为这个专家准备了八个位置就必须决定剩余输入怎么办。有的设计会改变派发或处理方式有的会引入额外空间有的训练方案允许丢弃超出容量的专家路径。具体行为属于实现的一部分不能只看到 Top-2 就假定每个 Token 最终都获得了两次完整专家计算。这里说的“丢弃路径”也不是删除用户文本。它描述的是某层某条计算分支没有按原计划执行最终文本仍由后续网络生成。把内部路径处理翻译成“模型把你的句子扔掉了”会让读者错误理解发生了什么。排查这类问题需要查看路由与容量统计而不是单凭输出长度猜测。2026 年 10 月的一项研究进一步讨论了共享专家与细粒度专家组合中的探索问题共享路径可能改变输入表示的变化程度从而影响路由探索。这个结果说明路由设计仍在发展而不是某个 Top-K 公式已经解决了所有问题。它是论文中的分析与方法不应被转述成所有 MoE 产品的已知缺陷。Rethinking Routing Exploration in Modern Mixture-of-Experts下面的 NumPy 程序展示一层最简化的稀疏计算。专家只是线性矩阵没有训练不代表真实语言模型的效果。程序会确认每个 Token 的组合权重之和为一同时统计各专家被选择的次数。# Python 3.10, NumPy; an untrained single-layer routing example.importnumpyasnp rngnp.random.default_rng(7)tokens,width,expert_count,top_k8,4,4,2xrng.normal(size(tokens,width))routerrng.normal(size(width,expert_count))expertsrng.normal(size(expert_count,width,width))logitsx router probnp.exp(logits-logits.max(axis1,keepdimsTrue))prob/prob.sum(axis1,keepdimsTrue)chosennp.argsort(-prob,axis1)[:,:top_k]weightsnp.take_along_axis(prob,chosen,axis1)weights/weights.sum(axis1,keepdimsTrue)outnp.zeros_like(x)loadsnp.zeros(expert_count,dtypeint)forrowinrange(tokens):forexpert_id,weightinzip(chosen[row],weights[row]):out[row]weight*(x[row] experts[expert_id])loads[expert_id]1assertnp.allclose(weights.sum(axis1),1)assertloads.sum()tokens*top_kassertnp.isfinite(out).all()print(selected experts:\n,chosen)print(expert loads:,loads.tolist())print(output shape:,out.shape)same_inputnp.repeat(x[:1],tokens,axis0)same_choicesnp.argsort(-(same_input router),axis1)[:,:top_k]same_loadsnp.bincount(same_choices.ravel(),minlengthexpert_count)assertsorted(same_loads.tolist())[0,0,tokens,tokens]print(identical-input loads:,same_loads.tolist())这里对选中的 Top-K 概率重新归一化最后一段只统计路由直接对 logits 排序因为 softmax 不改变候选的大小顺序。真实模型还可能加入共享专家、路由噪声、容量处理和不同的缩放规则示例没有实现这些部分。固定这个随机种子第一批输入恰好让四个专家各收到四次分配。看起来非常均衡但代码里根本没有均衡机制。把八行输入换成同一个向量之后十六次分配便全部落到两个专家各八次另两个为零。总计算路径数量没变忙闲分布却变了。这个对照比第一次的均匀结果更有解释力。部署时如果只测一批随机输入很可能把输入分布带来的巧合误当成系统特性。当然真实文本相同不必然使每层隐藏表示都相同这个例子只证明对当前确定性的路由器相同表示会给出相同选择。实际服务需要记录逐层路由分布再关联延迟和容量溢出。5 - 评估 MoE最好把系统条件写在成绩旁边一张只写模型名、参数量和 Token/s 的表格很难解释两套 MoE 系统为什么快慢不同。比较时至少应固定或说明权重精度、输入输出长度、批量与并发、硬件连接方式和模型版本。若其中一方使用了量化或特殊内核这也是实验条件的一部分。性能与能力还应分开评价。低延迟不自动意味着复杂任务完成率更高更多专家也不自动意味着稀有输入一定能找到更合适的路径。把模型放到目标任务上测试比根据参数数量推测能力可靠得多。训练侧则需要注意专家利用率、不同专家获得的有效样本以及路由机制是否随着数据变化出现失衡。总训练损失下降时某些模块仍可能长期缺少训练信号只看一个平均指标未必看得到这些内部差异。还可以做一项很实际的压力测试分别使用内容高度相似和内容较为分散的请求批次在相同并发下观察延迟。若相似请求把大量 Token 推向少数专家平均吞吐与尾部延迟可能出现不同变化。测试应报告实际路由分布而不是预先假定一定集中专家偏好是训练结果不能凭任务名称猜测。假如压测出现尾部延迟突然升高而显卡总体利用率并不高可以把专家负载和跨设备通信时间放到同一条时间轴上看是少数专家排队还是派发与回收占了太久抑或权重卸载频繁未命中这些原因需要不同处理。增加专家数不会自动修好通信瓶颈平均摆放权重也不会自动均衡请求。激活参数能解释一次计算走了多少模块却解释不了它在哪一步等了多久。感谢各位大佬支持互三啦