ℹ️ 读者定位适合你如果你正在看大模型参数表、准备本地部署模型或者想搞懂 DeepSeek、Qwen3、Llama 4 为什么会同时写总参数和激活参数。开始前需要知道 Transformer、token、参数量这些基础词即可不要求会训练大模型。读完可以完成看懂671B / 37B、235B-A22B这类标记理解 MoE 的工作过程、优势和工程代价并判断一个模型是否真的公开披露为 MoE。暂时不适合想直接拿本文完成大模型多卡部署的人本文重点是架构理解和选型判断不提供一套可直接复制的生产部署方案。在工作中我们经常会看到这样的模型参数671B 总参数37B 激活参数。第一反应通常是这到底是 671B还是 37B为什么一会儿说它很大一会儿又说它推理成本没有那么夸张答案通常就是 MoE也就是 Mixture of Experts中文一般叫“混合专家模型”。这篇内容分为以下几个部分先建立直觉弄清 MoE 和普通 Dense 模型的区别。拆开 Router、Expert、Top-k 和负载均衡。讲清 MoE 的优势、局限以及为什么激活参数少不等于部署很轻。盘点公开资料明确说明采用 MoE 的头部或代表性模型。给你一套看模型卡和做选型的简单方法。一、先把一个误区掰正1.1. 671B 到底意味着什么大模型里至少要区分两个数字总参数量整个模型一共存了多少参数包括所有专家。激活参数量处理某一个 token 时实际参与计算的参数规模。MoE 的关键就在于总参数量可以很大但每个 token 不需要经过所有参数。你可以把它理解成一家公司有很多员工但每个工单只派给其中几位相关员工处理。公司的员工总数很大不代表每一个工单都要让全员加班。所以671B / 37B并不是自相矛盾前者描述模型容量后者描述单个 token 的激活规模。1.2. 一句话理解 MoEMoE 多个专家网络 一个路由器路由器根据输入把每个 token 分给少数合适的专家。它不是把多个完整大模型拿来投票也不是把一个模型简单切成几块。MoE 通常把 Transformer 中部分 FFN/MLP 层替换成多个专家注意力层和其他主干结构可以继续共享。1.3. 先记住一个边界“激活参数少”主要说明计算路径更稀疏并不等于显存、磁盘占用、跨卡通信和部署成本都只按激活参数量计算。这是理解 MoE 最容易踩的坑。后面我们会专门解释。二、MoE 到底是怎么工作的2.1. Dense 模型所有 token 走同一套大脑普通 Dense 模型可以粗略理解为一条固定的计算路径。无论输入的是代码、数学题还是中文长文每个 token 都会通过同一套参数。这条路线的优点是简单参数怎么切、怎么做批处理、怎么做推理工程上相对直观。缺点也很明显如果想提升模型容量就常常意味着每个 token 都要承担更多计算。2.2. MoE路由器先分流再让专家处理一个 token 进入 MoE 层后大致会经历四步Router 打分路由器读取 token 当前的隐藏状态为每个专家计算一个分数。Top-k 选择只保留得分最高的 k 个专家例如 top-1 或 top-2。Expert 计算被选中的专家分别处理这个 token。加权合并按照路由权重合并专家输出再送回 Transformer 主干。用一个很简化的公式表示yΣ gate_i(x)× Expert_i(x)只对 top-k 专家求和注意专家不是在整个模型生命周期里固定负责某一种任务。路由器是根据 token 的上下文动态选择专家的而且不同层、不同位置都可能选择不同组合。MoE 专家路由示意图2.3. Top-k、共享专家与负载均衡Top-k不是专家越多单 token 就越贵假设模型有 128 个路由专家但每个 token 只激活其中 8 个那么计算量主要和这 8 个专家有关而不是把 128 个专家全部跑一遍。不过k 越大通常意味着单 token 计算和通信更多k 越小计算更省但模型可能获得的专家组合能力也会受影响。具体取值是架构设计不是越小越好。共享专家给所有 token 留一条公共路径一些新模型会在路由专家之外增加 shared expert。每个 token 都经过共享专家同时再经过少数路由专家。这样可以保留通用能力再用路由专家处理输入差异。例如 Meta 公开的 Llama 4 Maverick 采用 128 个路由专家和一个共享专家每个 token 经过共享专家并选择一个路由专家。负载均衡别让所有人都去同一个专家如果路由器把大量 token 都派给同一个专家就会出现三个问题这个专家所在设备变成热点拖慢整体速度。其他专家闲着算力利用率下降。训练可能不稳定甚至需要丢弃超出容量的 token。因此 MoE 需要容量限制、辅助负载均衡损失或其他路由策略。DeepSeek-V3 技术报告还公开介绍了不依赖传统辅助损失的负载均衡方案说明路由本身已经是模型训练的关键工程问题而不是一个小插件。2.4. 总参数和激活参数怎么算设共享主干参数是S一共有E个专家每个专家规模是P每个 token 选择k个专家。可以做一个近似理解总参数量 ≈ S E × P 激活参数量 ≈ S k × P比如 Mixtral 8x7B 的论文说明它有 8 个专家每个 token 每层选择 2 个专家整个模型约 47B 参数但每个 token 约使用 13B 激活参数。Mixtral of Experts 论文这个例子特别适合入门因为8x7B不是“8 个 7B 模型完整串起来”而是 8 个专家池token 只走其中一部分。三、MoE 为什么火又为什么难3.1. 优势一用更大的容量换取更高的计算效率潜力Dense 模型扩容时每个 token 都要使用更大的网络。MoE 则允许模型把很多参数放进专家池但每个 token 只调用其中一部分。这就是“条件计算”不同输入走不同计算路径。Google 的 Switch Transformer 论文把这个方向总结得很清楚稀疏 MoE 可以让模型拥有很大的参数规模同时让每个输入只使用部分参数研究同时也指出通信成本、训练稳定性和复杂度是 MoE 的主要难点。Switch Transformers 论文3.2. 优势二让模型具备输入依赖的计算路径对一段代码、一道数学题和一篇中文文章模型不一定需要完全相同的计算方式。MoE 让模型可以学习不同输入之间的统计差异。但这里要说准确一点这不代表某个专家一定就是“代码专家”另一个专家一定就是“中文专家”。专家分工往往是隐式的、混合的不能只看专家编号就下语义结论。3.3. 优势三更适合在大规模训练和服务中做成本折中当模型规模上升到多卡、多机之后训练和服务成本不只是“矩阵乘法算了多少次”还包括显存、通信、并行策略和批处理效率。MoE 的价值不是无条件地“更快”而是给工程团队多了一个折中空间在保持较大总容量的同时控制每个 token 的计算路径。3.4. 代价一显存和磁盘不会按激活参数量下降这是最容易被宣传语带偏的地方。一个 671B 总参数的 MoE 模型即使每个 token 只激活 37B 参数模型权重仍然有大量专家参数需要被加载、分片保存或放在可访问的存储中。你不能拿 37B 直接当作“只需要 37B 模型显存”。更准确的说法是指标MoE 的影响单 token 计算量通常低于同等总容量的全激活模型权重存储仍然接近总参数规模取决于量化和保存格式GPU 显存受总权重、并行方式、KV cache 和运行时影响跨卡通信可能因为专家分布而增加实际吞吐取决于 batch、路由均衡、框架和硬件MoE 参数与成本关系图3.5. 代价二通信和负载均衡会成为瓶颈多卡部署时不同专家可能放在不同 GPU 上。一个 batch 里的 token 经过 Router 后需要被发送到承载目标专家的设备再把结果收回来。这类 token dispatch 常涉及 all-to-all 通信。如果某些专家变成热点就会出现“最慢的那张卡决定整体速度”的情况。尤其是低延迟、小 batch 场景MoE 的通信开销未必能被矩阵计算摊薄。3.6. 代价三训练、推理和量化都更复杂MoE 需要额外处理专家容量和超出容量的 token、路由概率和负载均衡、专家并行与张量并行的组合、量化后的精度与吞吐以及批处理时不同 token 的调度。所以MoE 的“理论每 token 计算更省”不等于“拿同一套推理命令运行就一定更省”。真正的结果取决于硬件、框架、量化、并发量和上下文长度。⚠️ 不要把激活参数当成部署门槛看模型卡时至少同时关注总参数、激活参数、量化格式、上下文长度、推荐 GPU 数量和推理框架。只看到AxxB就断言“单卡能跑”通常是不可靠的。四、哪些头部模型是 MoE先说明口径这里的“顶级模型”指公开披露过、在大模型生态里有头部影响力或代表性的模型不代表一份随时间变化的排行榜。公开披露的代表性 MoE 模型4.1. DeepSeekMoE 路线里最容易被看到的一组DeepSeek-V2 / V2.5DeepSeek-V2 论文明确称其为 Mixture-of-Experts 模型总参数 236B每个 token 激活 21B并结合了 MLAMulti-head Latent Attention和 DeepSeekMoE。DeepSeek-V2 论文DeepSeek-V3DeepSeek 官方发布信息和技术报告明确说明DeepSeek-V3 是 671B 总参数、37B 激活参数的 MoE 模型在 14.8T token 上预训练。DeepSeek-V3 技术报告DeepSeek-V3 官方仓库DeepSeek-R1DeepSeek-R1 官方仓库给出的模型表同样是 671B 总参数、37B 激活参数并明确说 R1 基于 DeepSeek-V3-Base 训练。因此更准确的表达是DeepSeek-R1 是建立在 MoE 基座上的推理模型而不是把“推理能力”误解成另一种架构。DeepSeek-R1 官方仓库4.2. Qwen3把 MoE 做成了大小两档Qwen 官方发布的 Qwen3 系列里Qwen3-235B-A22B 和 Qwen3-30B-A3B 都是 MoE同时 Qwen3 也提供了多个 Dense 模型。模型总参数激活参数专家信息Qwen3-235B-A22B235B22B128 个专家激活 8 个Qwen3-30B-A3B30B3B128 个专家激活 8 个这两档很适合拿来理解 MoE 的实际折中大模型档位追求更高容量小模型档位则把激活参数压得更低。Qwen 官方还列出了对应的上下文长度与本地推理生态。Qwen3 官方博客4.3. Llama 4Meta 首次把 MoE 带进 Llama 主线Meta 在 Llama 4 发布文章中明确说Llama 4 Scout 和 Llama 4 Maverick 是 Llama 系列首次采用 MoE 架构的模型。模型总参数激活参数专家信息Llama 4 Scout109B17B16 个专家Llama 4 Maverick400B17B128 个路由专家 共享专家Meta 还说明 Llama 4 Maverick 采用交替的 dense 层和 MoE 层MoE 层里 token 会经过共享专家并选择一个路由专家。MetaThe Llama 4 herd这里有一个很重要的观察Llama 4 Maverick 的总参数远大于激活参数但并不意味着部署时只需要按 17B 模型准备所有资源。4.4. Mixtral、Grok-1、Gemini 1.5、DBRX模型官方公开的 MoE 信息你需要记住的边界Mixtral 8x7B8 个专家每 token 每层选 2 个约 47B 总参数、13B 激活经典开放权重 MoE 代表Grok-1xAI 官方称为 314B MoE单 token 激活约 25% 权重这个结论只覆盖公开的 Grok-1不外推到 Grok 后续版本Gemini 1.5Google 官方明确说采用新的 MoE 架构Google 没有在该公告里公开完整专家数量与激活参数表DBRXDatabricks 资料称为 fine-grained MoE132B 总参数、36B 激活企业级开放模型代表实际部署仍看硬件和框架资料链接Mixtral 论文、xAIOpen Release of Grok-1、GoogleIntroducing Gemini 1.5、DatabricksDBRX 相关资料4.5. 哪些模型不要靠猜对于 GPT 系列、Claude 系列、Grok 2/3/4、Gemini 2.x/3.x 等具体版本如果官方技术报告没有明确说明就应该写“公开资料未完整披露架构”。不能因为某个模型能力强、参数传闻很大或者社区有人说“它大概率是 MoE”就把它列成已确认的 MoE。五、最后给你一套选型方法5.1. 看模型卡里的四个字段第一看总参数量判断模型容量、权重存储和大致部署规模。第二看激活参数量判断单 token 计算路径的规模但不要把它当成显存需求。第三看专家数量与 top-k了解路由稀疏程度以及可能的通信复杂度。第四看官方推荐的硬件、量化格式和推理框架这些比一个漂亮的参数数字更接近真实体验。5.2. 什么时候优先考虑 MoE你需要较强能力但希望控制每 token 计算成本。你有多卡或云端推理基础设施能够承受专家并行和通信。你愿意使用对 MoE 支持较好的推理栈并接受一定调参。你更关心吞吐和规模化服务而不是只在一台普通电脑上追求最简单的部署。5.3. 什么时候 Dense 反而更省心你只需要一个小模型做本地问答、摘要、分类或简单 Agent。你的硬件显存很紧无法容纳完整 MoE 权重。你的请求量很低通信和调度开销很难被摊薄。你需要非常稳定、简单、可预测的部署链路。Dense 不是“落后架构”。对于小规模、本地、低并发和边缘设备场景一个合适的 Dense 模型可能更便宜、更容易维护。5.4. 最后记住这句话MoE 的核心不是“模型里有很多专家”而是“每个 token 只调用少数专家”。 总参数决定容量激活参数影响每 token 计算但真实部署还要看显存、通信、框架和并发。如果你只想先建立直觉推荐从 Mixtral 8x7B 或 Qwen3-30B-A3B 的模型卡开始如果你要研究大规模推理系统再去看 DeepSeek-V3 的专家并行、负载均衡和推理实现。MoE 未来会不会完全取代 Dense我的判断是不会。大规模训练和服务会继续大量采用 MoE但小模型、端侧模型和强调简单运维的场景Dense 仍然有自己的位置。真正重要的不是追着参数量最大的模型跑而是把“能力、计算、显存、通信和维护成本”放在同一张表里看。