模型介绍里有时会同时写两个参数量，一个很大，一个小很多，Qwen3MoE 的文档就列出 30.5B 总参数和每个 Token 激活 3.3B 参数，两个数字都是真的，它们回答的是两件事。总参数说明模型里一共有多少权重，激活参数说明生成当前 Token 时有多少权重参加主要计算。
我查了 Switch Transformer 论文与 Hugging Face 当前的专家接口，混合专家模型通常保留 Transformer 的共享部分，把部分前馈层换成多组专家。每个 Token 到达这些层时，路由器选出 k 个专家，专家分别计算，结果再按路由权重汇总。
路由发生在每个 Token 上
这里的专家更像多组可选参数，并不等于公司里按行业分工的人。一个专家未必专管法律，另一个也未必只懂代码。路由器根据当前 Token 的内部表示选择组合，同一句话里的不同 Token 可能走向不同专家。
Qwen3MoE 当前文档列出 128 个路由专家，每个 Token 激活 8 个。Switch Transformer 采用更简化的单专家路由。共同点是稀疏激活，模型可以拥有较大的总容量，每一步只计算其中一部分。总参数因此适合描述模型容量，激活参数更接近一次前向计算实际经过的规模。Switch 论文报告，同等计算资源下，稀疏模型的预训练速度可以明显提高。
路由也会带来新的训练问题。大量 Token 若挤向少数专家，热门专家会超载，其余专家又闲着。系统需要限制专家容量或加入负载平衡办法。专家分布在多块设备上时，Token 还要在设备之间传送，通信时间可能吃掉一部分计算收益。论文把通信成本、训练不稳定和实现复杂度都列为 MoE 的现实困难。
激活少不等于部署一定轻
下载和加载模型时，机器仍要容纳总权重。Hugging Face 的模型加载文档专门提醒，MoE 的内存要考虑模型大小和专家数量。每个 Token 只激活 3.3B 参数，不能直接推导出它只占一个 3.3B 稠密模型的磁盘或内存。
实际速度还跟推理框架有关。Hugging Face 为专家计算提供多种后端，有的逐个处理选中专家，有的把矩阵乘法批量或分组执行。它们对 GPU、编译方式和数据类型的支持不同。同一个模型换框架或硬件，吞吐和延迟可能差很多。小并发时通信开销更显眼，高并发又会碰到专家负载分布，宣传页里的单次速度很难代替本机测试。
选本地模型时，我会把总参数、激活参数、模型文件大小和实测显存分开记，再跑真实并发量。总参数能说明容量，激活参数更接近单步计算，部署成本还要看权重是否装得下、专家之间怎样通信。只拿宣传页上较小的那个数字估机器，常会在加载模型时先碰壁。