参数越大，为什么每次计算反而可以更省？

看到 DeepSeek-V3 的“671B 总参数、每个 token 激活 37B”时，很多人的第一反应是：这不是自相矛盾吗？模型明明有 6710 亿参数，为什么推理时只算 370 亿？

答案就在 MoE（Mixture of Experts，混合专家模型）的核心设计：模型把 Transformer 中的前馈网络拆成许多“专家”，再由 Router 针对每个 token 只挑少量专家参与计算。模型容量可以继续变大，但单个 token 不必经过全部专家。

**先记住一句话：**MoE 的价值不是“把几个完整大模型拼在一起”，而是用稀疏路由，让不同 token 只调用部分 FFN 参数。

一、Dense 模型的瓶颈：所有 token 都走同一套参数

传统 Dense Transformer 中，每个 token 都会经过同一套注意力层和同一套 FFN。想让模型记住更多知识、学习更复杂的模式，最直接的方法就是继续扩大隐藏维度、层数和 FFN。问题也很直接：参数越多，计算、显存和延迟往往一起上涨。

MoE 没有把 Transformer 全部推倒重来。主流做法仍保留注意力模块，只把参数占比很高、计算量也很大的 FFN 换成“多个 FFN 专家 + Router”。

二、MoE 的三个核心组件

1. Experts：许多参数独立的 FFN

每个专家通常是一个结构相同、参数不同的前馈网络。它不是一整个独立大模型，也不是人工提前指定的“数学老师”或“代码老师”。专家的分工是在训练中根据 token 和上下文模式逐渐形成的。

2. Router：给每个 token 分配专家

Router 一般很轻量，常见实现是一个线性映射。它根据 token 的隐藏状态计算对各专家的匹配分数，再选分数最高的 Top-K 个专家。Switch Transformer 采用更简单的 Top-1 思路；Mixtral 8x7B 每层为每个 token 选择两个专家。

3. Combine：把专家输出重新合并

被选中的专家分别处理 token，最后根据路由权重做加权合并。一个简化表达是：输出等于若干个“路由权重 × 专家输出”的和。

三、路由不是“整道题选一个专家”

MoE 的路由通常发生在 token 级，而且会在不同 MoE 层重复发生。即便是一句话，“Python”“快速排序”和普通虚词也可能被分到不同专家；同一个 token 在不同上下文、不同层里，也可能选择完全不同的专家。

**容易误解的地方：**专家的“专业化”更接近对某些 token、语法和上下文模式更敏感，而不是稳定对应现实世界的学科部门。

四、Router 的核心计算

下面是一段只表达结构的伪代码。真实框架还会处理专家容量、批量 dispatch、归一化和分布式通信。

gate_logits = hidden_state @ W_router

expert_scores = softmax(gate_logits)

top_scores, top_ids = topk(expert_scores, k=2)

outputs = [experts[i](hidden_state) for i in top_ids]

result = weighted_sum(outputs, top_scores)

Top-K 越小，稀疏度越高，计算更省；Top-K 越大，每个 token 可以获得更多专家协作，但计算和通信也会增加。因此 K 不是越大越好，而是效果、稳定性和成本的折中。

五、总参数和激活参数到底是什么关系？

“总参数”包含模型里所有专家、注意力、嵌入层等参数；“激活参数”表示单个 token 做一次前向计算时实际参与的参数规模。由于每个 token 只走少量专家，激活参数可以远小于总参数。

Mixtral 8x7B 公开论文给出的口径是约 47B 总参数、13B 激活参数；DeepSeek-V2 为 236B / 21B；DeepSeek-V3 为 671B / 37B；Qwen3-235B-A22B 的官方模型卡给出 235B 总参数、22B 激活参数。

**重要提醒：**激活参数不是完整的延迟公式。不同模型的注意力结构、专家大小、路由方式、量化精度和通信拓扑不同，不能只比较一个“AxxB”数字就判断谁更快。

六、MoE 为什么能学得更多？

Dense 模型让所有输入共享同一套 FFN 参数，所有知识和模式都挤在一起。MoE 给模型增加了更多参数路径：不同 token 可以更新不同专家，专家之间逐渐形成差异，整体容量随专家数量增长。

2017 年的稀疏门控 MoE 论文已经证明，条件计算可以大幅增加模型容量，而计算效率只受到较小影响。之后的 Switch Transformer 进一步简化路由，并把稀疏模型扩展到万亿参数规模。

七、最棘手的问题：专家不平衡

Router 如果长期偏爱少数专家，会形成“强者越强”的循环：热门专家获得更多训练，冷门专家几乎没有梯度；热门专家的容量被挤爆，其他 GPU 却很空。严重时会出现路由塌缩，模型名义上有很多专家，实际上只在使用几个。

早期方案通常加入辅助负载均衡损失，鼓励专家使用率更平均。但辅助损失权重太大，又可能让 Router 为了“平均”而牺牲主任务效果。因此后续研究出现了 Expert Choice、动态偏置、节点限制路由等方案。

八、DeepSeek-V3 的无辅助损失负载均衡

DeepSeek-V3 的技术报告提出了一种 auxiliary-loss-free 策略：为每个专家维护一个只用于路由的偏置。专家过载时降低偏置，欠载时提高偏置，Router 的 Top-K 选择会随之调整。真正用于加权专家输出的权重仍来自原始匹配分数。

这样做的目标是减少传统辅助损失对主任务优化的干扰。报告同时说明，它仍使用一个权重很小的序列级辅助损失，防止单条序列出现极端不平衡，所以“无辅助损失”更准确地理解为：主要的全局均衡不依赖传统辅助损失。

九、Shared Expert：通用能力不必重复学

细粒度 MoE 容易让多个路由专家重复学习通用模式。DeepSeekMoE 的一个设计是把部分专家设为 Shared Expert，让所有 token 都经过它们；路由专家则更专注于差异化模式。

十、训练和部署真正难在“把 token 搬来搬去”

如果所有专家都放在一张 GPU 上，模型规模很快会撞上显存上限。大规模 MoE 通常采用 Expert Parallel：不同专家分布在不同 GPU 或不同节点上。Router 选完专家后，要把 token 发送到专家所在设备，计算完再把结果发回来。

这也是 MoE 的核心工程矛盾：稀疏计算省下了矩阵乘法，但跨卡通信、token 重排和负载调度可能吞掉收益。DeepSeek-V3 报告专门设计了通信与计算重叠、节点限制路由和高效 All-to-All 内核。

十一、几种代表性 MoE 路线

Mixtral 代表“专家较少、Top-2”的简洁路线；DeepSeek 系列更强调细粒度专家、共享专家与系统级通信优化；Qwen3 同时提供 Dense 与 MoE 规模，旗舰 MoE 模型采用 128 个专家、每个 token 激活 8 个。

这些路线没有绝对优劣。专家越多，可以切得更细，但 Router、并行和通信更复杂；专家越少，部署更直观，却可能需要更高的激活比例来保持能力。

十二、MoE 不是免费的：四类代价

第一，权重显存通常仍按总参数准备。即使一次只算部分专家，被路由到的专家也必须可访问。量化、权重分片和专家卸载可以缓解，但会引入新的延迟。

第二，低并发时未必比同等激活规模的 Dense 更快。MoE 的 dispatch、combine 和跨卡通信存在固定开销，batch 太小就难以摊薄。

第三，热门专家会造成尾延迟。线上流量并不一定像训练数据那样均匀，一类请求突然增多时，某些专家可能成为热点。

第四，微调和量化工具链更复杂。LoRA 应该加在哪些模块、是否微调 Router、专家如何切分、量化内核是否支持，都需要单独验证。

十三、为什么近几年 MoE 才真正火起来？

MoE 并不是突然出现的新概念。真正的变化是三件事同时成熟：路由与负载均衡更稳定；分布式训练能把通信和计算重叠；vLLM、SGLang、TensorRT-LLM 等推理生态逐步补齐 MoE 支持。

开源模型也提供了更直观的验证。Mixtral 证明了开源稀疏模型可以获得强性能；DeepSeek-V2/V3 展示了细粒度 MoE、共享专家和大规模系统优化；Qwen3 则把 Dense 与 MoE 放进同一模型家族，方便不同部署条件选择。

十四、项目里应该选 Dense 还是 MoE？

下面这些场景更适合优先考虑 MoE：需要极大模型容量；拥有多卡高速互联；流量足够大，能够摊薄调度成本；团队有能力处理专家并行、监控和负载问题。

下面这些场景 Dense 往往更稳：单机或少量 GPU 部署；请求量小但要求低尾延迟；模型规模在 1B 到几十 B 已能满足业务；团队更重视部署简单、量化兼容和故障排查。

**选型原则：**不要只看榜单和“总参数”。必须用真实提示词和真实并发压测：吞吐、首 token 延迟、单 token 延迟、P99、显存、通信带宽与专家负载。

十五、面试与工程实践的回答框架

回答“什么是 MoE”时，可以按照下面的顺序：

先说核心：用稀疏激活把模型容量和单 token 计算量拆开。

再说结构：把 FFN 替换成多个专家，由 Router 为每个 token 选择 Top-K。

解释总参数与激活参数：计算更接近激活规模，但显存和通信仍受总规模影响。

指出训练难点：专家不平衡、Router 稳定性、专家容量与 token 丢弃。

指出系统难点：Expert Parallel、All-to-All、热门专家和尾延迟。

最后做选型：超大容量和高吞吐适合 MoE，部署简单和稳定延迟更适合 Dense。