稠密模型与 MoE 怎么选：总参数和激活参数要分开
结合 Mixtral 与 Switch Transformer 原始论文，说明专家路由怎样影响模型计算，并给出自部署时对照内存和任务结果的方法。
怎样选择更合适
MoE 模型会按输入选择部分专家参与计算，稠密模型则没有这种稀疏专家选择机制。选择自部署模型时，需要同时核对总参数与实际参与计算的参数，以及运行后端如何放置专家权重。激活参数较少，不表示所有权重都可以忽略；也不能只凭架构名称判断哪一个更适合自己的设备。
专家路由改变的是参与计算的部分
Mixtral 论文描述了对每个词元选择专家并组合输出的做法，Switch Transformer 则研究简化专家路由的稀疏架构。不同 MoE 的专家数量和路由策略可以不同，不能把某篇论文的配置当作所有 MoE 的固定规则。
总参数关系到需要保存的权重，激活参数有助于理解一次处理的计算范围。实际部署可能还需要在设备间调度数据，因此内存与计算不是一个数字。稠密模型和 MoE 都有具体大小与版本，应比较选中的模型，而不是抽象类别。
让两种模型处理同一批实际输入
先固定任务要求及输入长度，例如相同的文档分类与摘要材料，再记录各模型是否按要求输出。模型训练资料不同会影响结果，不能把所有差异都归因于专家机制。结果表应明确模型全名和版本，并单独保留失败样本。
加载测试要确认目标后端确实支持该架构，再检查长上下文和并发时的峰值占用。若需要卸载部分权重到其他设备，记录这种运行方式；否则一边全部放在 GPU，另一边频繁移动权重，得出的速度比较并不对应相同条件。
把专家放置与故障处理纳入维护
自部署的维护还包括模型格式转换、后端升级以及权重存放方式。小规模业务若只有一台设备，应先确认可持续运行的配置；不能因为论文展示了稀疏计算，就省略自己的容量验证。这里没有给出任何架构的通用胜负。
验收时同时检查任务质量和完整请求等待，而不只引用每秒生成词元。保存当前配置，升级后重放相同输入，观察是否出现加载或输出回归。本文只核对两篇原论文的机制，没有复现论文训练，也没有测量自部署吞吐。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。