一、参数量大，算力反而省？
MoE 的卖点就是这个：模型总参数很大，但每次推理只激活其中一小部分。
比如总参数几百 B，每个 token 只走两个专家，实际算力消耗接近一个几十 B 的稠密模型。
MoE 火起来，是因为它解决了一个很实际的问题：想让模型更强，又不想让推理贵到用不起。
稠密模型加参数，算力跟着涨；MoE 加参数，算力只涨一点。
代价是显存和工程复杂度。这两样，通常宣传里不提。
二、它是怎么做到的
核心是一个路由网络。每层有一组专家，路由决定当前 token 交给哪几个专家处理。
不同 token 走不同专家，所以同一个模型里可以同时装下代码、数学、多语言等不同能力。
代价是显存要装下全部专家，所以 MoE 省算力但不省显存。
稀疏激活的做法，是先训练多个「专家」子网络，再由一个路由器决定每个 token 走哪几个。
所以算力只花在被选中的专家上，其余不参与计算。参数总量很大，实际计算量却小。
这也是它名字的来源：参数稠密，计算稀疏。
三、三个常见的坑
一、负载不均。热门专家被挤爆，冷门专家闲着。训练时要加负载均衡损失，不然实际速度比理论差很多。
二、专家不专。路由学不好，每个专家都学成半吊子，等于白拆。
三、微调难。全参微调要装下所有专家，成本高；只调部分专家，又容易破坏路由。
三个坑，我按踩到的顺序说。第一个是路由不均：少数专家被过度使用，其余闲置。
结果是有效参数远小于标称参数。看起来 8 个专家，实际只有 3 个在干活。
第二个是专家崩塌：训练到中途，某几个专家彻底不被选中，等于白占显存。
第三个是批处理效率：不同请求走不同专家，显存碎片和调度开销都上来了。
三个坑里，第一个看日志能发现，第二个要靠监控训练指标，第三个只能靠压测。
四、部署时看什么
一、激活参数与总参数的比例。比例越小越省算力，但能力上限也受影响。
二、专家并行能不能跨卡。专家多到一张卡装不下，就要通信开销。
三、batch 多大时吞吐才起来。MoE 在小 batch 下优势不明显。
部署时看三样：专家数、激活比例、以及显存布局。
专家数越多，路由越难均衡；激活比例越高，算力越接近稠密模型。
显存布局最实际。专家分散在不同卡上，跨卡通信就成了瓶颈。这一项最影响实际吞吐。
五、对使用者的实际意义
如果你只是调 API，MoE 的直接感受是"便宜且能力不弱"。
如果你自己部署，MoE 的显存门槛反而更高，中小规模场景不一定划算。
选型时别只看"总参数"，要看"激活参数"和"显存需求"这两栏。
对使用者的意义，其实比想象中直接。
第一，同样的显存，能跑更大的模型。这是最实在的好处，尤其对本地部署。
第二，激活参数少，单次推理延迟未必更高，但首 token 时间可能变长——要加载的权重多。
第三，量化要小心。专家分得散，某些专家的量化误差会被放大。
所以选 MoE 模型，别只看参数量，要看专家数、激活比例、路由策略三样。
六、一句话总结
MoE 不是把模型变小，是把算力花在需要的地方。
一句话总结：MoE 是拿显存换算力。
显存宽裕、算力紧张的场景，它划算；显存紧张的场景，它就是负担。
还有一个隐性成本：调试。出了问题，你很难判断是路由错了还是专家本身弱。
所以我一般建议，先在稠密模型上把效果跑通，再考虑换 MoE。
顺序反了，你会同时面对两个变量，最后不知道是谁的问题。
对使用者的意义，最直接的是「同样的显存跑更大的模型」。
但要注意：大不等于强。专家没训好，大参数也是浪费。
所以评估 MoE 模型，一定要在真实任务上跑，别只看参数量。
最后说个使用层面的建议：MoE 模型批量处理很划算，单条对话的优势不明显。
它的优势在吞吐，不在单次响应。所以用错了场景，会觉得它跟普通模型没区别。
延伸参考
术语这块，前端 Wiki 的条目写得克制，一个词配一句解释，查概念比看长文快。
留一句：看 MoE 的宣传，先问它一次推理激活了多少。
