Mixture of Experts 混合专家模型：激活参数少，部署为何仍然吃内存？

Mixture of Experts（混合专家模型）可以减少每个 token 的计算量，但部署时，模型依然可能庞大得惊人。根据 Moonshot AI 的官方发布帖，其 Kimi K3.1 Pro 语言模型拥有 2.8T 总参数，每个 token 仅激活 104B 参数。较小的数字有助于理解计算开销；较大的数字，则决定了存放模型权重时必须面对的规模。

本文参数量及来源中的说法核验于 2026 年 10 月 24 日。下文的激活参数占比由我们计算，不代表实测加速比、内存节省比例或质量得分。

Mixture of Experts（混合专家模型）是什么？

Mixture of Experts，简称 MoE，在模型内部设置多个处理网络，每次输入只选用其中一部分。 参数是模型通过学习得到的数值，存储下来的参数通常称为权重。token 是输入或输出中的小单位，往往是一个词的片段。

可以把它想成一栋设有许多咨询室的大楼：前台根据每位来访者的需求，将其引导到相应房间。接待这位来访者时，只有少数房间需要工作，但其他房间依然占据着大楼的空间。在 MoE 层中，路由器相当于前台，专家网络相当于这些房间。

这个比喻也有边界：专家是通过训练学到的数值计算网络，并不是按人类职业划分的岗位。不能据此认为，模型里有法律专家、编程专家和会计专家随时等候调用。

MoE 架构如何运作？

路由器在模型内部选择计算路径，再将各条路径的结果合并。 Transformer 负责处理 token 之间的上下文关系。在常见的 MoE Transformer 中，原本的前馈模块被多个专家网络取代。前馈模块对 token 的内部数值表示进行变换；注意力则是另一套机制，让 token 能够利用周围的上下文。

具体流程如下：

1. token 当前的表示进入 MoE 层。
2. 经过训练的路由器（也称门控）为各个专家打分。
3. 路由器选出部分专家，通常选择得分最高的那些。这称为 top-k 路由，k 就是选中的专家数量。
4. 选中的专家处理该表示，其输出经过加权合并后，继续传入后续计算。

这个过程发生在模型的各个 MoE 层，因此不同 token、不同层都可能选择不同的专家。PyTorch 的架构说明介绍了加权合并机制；Mistral 的模型论文展示了不同层的专家选择如何变化。

什么是稀疏 MoE？

稀疏，是指处理某个 token 时，只有一部分专家参与计算。 现代模型卡中总参数量与激活参数量的区别，主要对应的就是这种形式。其余专家可能处理其他 token，包括同一批次内正在处理的 token。

稠密前馈模块会让每个 token 经过整个前馈网络。稀疏专家层则能增加模型存储的容量，同时避免让每个 token 都经过所有专家。不过，这些示例中的注意力等共享组件仍然需要参与计算。

MoE 模型仍然是一个模型

MoE 路由不同于在多个 API 模型之间做选择，也不同于让多个聊天机器人投票。 路由器和专家是同一个网络的组成部分，一起接受训练。应用通常向这个网络发送请求，而不是像从菜单上选产品一样，自行挑选某个专家。

对开发者而言，分清这一点可以避免设计上的误判：选用 MoE 模型，并不意味着应用获得了一支可供直接调度的专业智能体团队。

看懂 MoE 模型：总参数量与激活参数量要一起看

总参数量反映存储中的模型规模，激活参数量则反映厂商公布的每个 token 所经过的计算路径。 任何一个数字都不能单独充当完整的硬件规格。B 表示十亿，T 表示万亿。

最后一列由激活参数量除以总参数量，再四舍五入得到。它只描述各厂商公布的参数关系，不是跨模型的效率排名。不同架构的参数统计口径也可能不同。

Kimi K3.1 Pro：激活的只是庞大模型中的一小部分

Kimi K3.1 Pro说明了为什么不能用激活参数量，代替部署时需要容纳的模型规模。 将 Moonshot 公布的总参数量换算到相同单位，得到 2,800B。因此，104 ÷ 2,800 × 100 = 3.7%，结果经过四舍五入。

这意味着，公布的激活参数量只占总参数量的一小部分。它不意味着推理部署可以丢弃其余权重，也不意味着 API 延迟能降到稠密模型的同等比例。token 和层发生变化，所选路径也会变化。

Moonshot 的发布博客将 Pro 描述为经过后训练的 K3，并使用了取整后的“3T-class”标签。官方发布帖给出的精确参数组合则是 2.8T / 104B。理解模型规模时，应以这组明确的规格为准。

对通过 API 开发应用的人来说，这个模型值得纳入评估。对自行部署的运营者来说，能否获得权重则是另一道门槛：截至核验日期，Moonshot 承诺在 2026 年 11 月 4 日前发布完整权重。承诺发布，不等于已经有可部署的文件。Kimi K3.1 Pro 详解讨论了这次发布涉及的具体选择。

Qwen3-235B-A22B：激活参数量不能替代总参数量

Qwen3-235B-A22B 的名称直接体现了这一区别。 Qwen 的原始模型卡写明：总参数量为 235B，激活参数量为 22B，共有 128 个专家，其中 8 个被激活。

按参数量计算，22 ÷ 235 × 100 = 9.4%，结果经过四舍五入。对于私有文档助手，这个比例可以帮助理解模型如何限制每个 token 的计算量。但内存规划仍然要容纳所选检查点的完整权重，以及处理请求时需要保存的状态。

不要把“激活 22B 参数”理解为“部署所需的内存和稠密 22B 模型一样”。引用参数时，也要同时保留检查点的具体身份：选择权重文件、精度和推理服务配置时，仅有模型家族名称还不够。

Mixtral 8x7B：为什么不能把名称里的数字直接相乘？

Mixtral 8x7B 包含共享组件，它的名称并不是一道乘法题。 Mistral 的发布博客给出的数据是：总参数量为 46.7B，每个 token 使用 12.9B 参数。直接将名称中的数字相乘，相当于把共享组件当成多个完整模型各自独有的部分，重复计算。

Mistral 的论文描述了专家前馈网络与共享注意力的组合。每层路由器会从 8 个专家中选择 2 个。这些专家并不是八个彼此独立的完整模型。

使用公布的参数组合计算，12.9 ÷ 46.7 × 100 = 27.6%，结果经过四舍五入。从 8 个专家中选出 2 个，选中的是专家总数的 25%，这里的分母已经不同。共享组件的存在，是专家数量占比与参数量占比不同的原因之一。

规划部署时，应查看模型卡中的总参数量和实际检查点文件。无论产品名称还是选中的专家数量，都无法告诉你完整权重的存储占用。

为什么计算量更少，延迟却不一定更低？

与执行规模相当的稠密网络相比，稀疏路由减少了专家部分的计算；但它并不保证拥有较小稠密模型的响应速度。 这正是 MoE 能够降低大容量模型每个 token 推理开销的原因，但内存与通信负担仍然可观。

推理，也就是运行已训练模型的过程，并不只有数值运算。服务器还要读取权重、运行共享组件、路由 token 表示，有时还要在设备之间传输这些表示。激活参数量减少，并不会让这些工作消失。Shazeer 及其同事在最初的稀疏 MoE 论文中，就指出了专家处理批次过小、网络带宽等性能约束。

吞吐量与延迟回答的是不同的业务问题。 吞吐量衡量服务在一段时间内完成多少工作，延迟衡量单个请求要等待多久。夜间运行的文档处理队列，可能适合高效处理大批次的配置；交互式客服助手则需要尽快给出第一个有用的回答。

批处理会将多个 token 或请求放在一起处理，有助于提高硬件利用率。但不同 token 可能选择不同专家，因此一个批次动用的模型范围，可能远大于单个 token。单个 token 的激活参数量，并不等于服务器处理整个批次时会访问的权重数量。

处理提示词和生成 token，对系统造成的压力也不同。**预填充（prefill）**处理输入，**解码（decode）**生成后续 token。语言模型推理服务软件 vLLM 的文档，为高吞吐量预填充和低延迟解码分别介绍了不同的专家通信方案。LLM 推理指南解释了这些阶段，以及应当分开记录的指标。

选择 API 时，应使用自己的请求比较实际表现。一组参数数字无法告诉你，服务商采用了多大规模的批处理、排队时间有多长，或硬件与模型是否匹配。

MoE 的取舍，会怎样影响业务？

MoE 将一部分基础设施负担，从反复计算转移到了存放和协调更大的模型上。 运营层面要回答的问题是：这种交换是否适合你的实际负载。

内存：每个专家都需要存放空间

某个 token 没有用到某个专家，不代表部署时可以删掉它。 在常规的权重常驻推理部署中，完整权重集仍然加载在整个推理服务系统里，尽管每个 token 只使用其中一部分。PyTorch 的说明明确指出了这一内存要求。

可以先用这个公式估算：权重存储占用 ≈ 总参数量 × 每个参数的存储字节数。但这只是起点：不同张量可能采用不同精度，文件元数据、填充、复制的副本和运行时分配的空间也会增加占用。

权重并不是内存预算的全部。KV 缓存保存先前 token 的注意力键和值，以便后续复用。文档助手的对话越长、同时处理的请求越多，需要容纳的请求状态内存也越多。KV 缓存详解介绍了这一独立约束。

量化通过降低权重的数值存储精度，减少权重占用的空间。但它不会把总参数量变成激活参数量，也不能免除对输出质量的验证。LLM 量化指南讨论了格式与精度的选择；Hugging Face 的量化概览说明了相关机制。

吞吐量：装得下模型，只是第一关

模型成功加载，并不意味着它能达到服务目标。 专家并行将专家分布到多台设备上，使部署能够容纳超出单台设备内存容量的模型。相应地，系统也需要将 token 表示发送到存放所选专家的设备，再合并结果。

这些传输使设备间的互连成为推理服务设计的一部分。把容量分散在连接不畅的多台机器上，并不等同于在互连良好的系统上拥有相同容量。这一点可以直接从 PyTorch 专家并行实现描述的通信模式中看出。

对低流量的内部助手来说，实际问题可能是固定配置的容量长期闲置；对繁忙的批处理服务来说，问题则可能是如何持续给专家计算提供足够的任务。仅凭激活参数量，无法判断最终会是哪种情况。

路由不一定均衡：热门专家可能成为瓶颈

经过训练的路由器，并不保证硬件使用完全均衡。 NVIDIA 的 Mixtral 路由分析发现，流量集中于某个主题时，专家负载可能不均衡。一些计算工作单元已经完成任务，另一些却仍在忙碌。

因此，如果服务主要处理合同或代码，仅用主题混杂的演示负载测试还不够。应评估这种主题集中的实际请求，并关注慢请求，而不能只看平均值。

推理服务软件可以做补偿，但补偿本身也有资源成本。vLLM 文档介绍了利用冗余专家进行负载均衡的方法，同时提醒：这些额外副本会占用原本可用于 KV 缓存的 GPU 显存。如果权重刚好塞满内存，就可能没有足够空间采用更合适的服务配置。

选择 MoE 大语言模型：调用 API，还是自行部署？

通过 API 开发应用，要评估最终交付的服务；自行部署，还必须评估完整的部署方案。 两者都需要合格的输出，但只有后者直接负责专家的存放与运行。

对于使用 API 的开发者，架构是有用的背景信息，却不是更换模型的充分理由。应测试有代表性的任务、指令遵循能力、适用时的工具调用能力，以及预期并发下的首 token 延迟和完成时间。失败尝试与重试也要记录。服务商自身的推理效率，并不能直接决定你的账单，也不能决定获得合格结果需要付出多少工作。

对于自行部署的运营者，应从可下载的具体检查点、许可证和受支持的推理实现入手，再评估权重精度、完整模型的内存占用、缓存余量、设备连接，以及负载下的性能。开放权重模型指南区分了获取文件与运行模型所涉及的权利和责任。

对于负责服务承诺的采购方，需要追问的是：在计划采用的基础设施上，候选模型能否在目标响应时间内完成符合验收标准的工作。“万亿总参数、十亿级激活参数”描述的是架构，并不是服务水平保证。

1. 1

   先定义负载，再比较模型

   使用有代表性的请求，并明确验收标准。将交互式任务与队列任务分开测试，同时纳入应用实际会遇到的长输入和主题集中的请求。

2. 2

   评估真正打算采用的服务方式

   使用 API，就测试计划采用的服务商和端点。自行部署，就记录具体检查点、精度、运行时和硬件。服务方式不同，实际运行结果也会不同。

3. 3

   同时验证容量与质量

   逐步提高并发量，观察内存使用、等待时间、输出质量和失败情况。单个请求响应快，不能证明有效吞吐量高；吞吐量高，也不能证明交互延迟可以接受。

4. 4

   只有实际负载受益，才更换模型

   只有在合格任务的完成表现与运行要求同时改善时，才采用候选模型。看不到收益，就保留当前模型。如果所需权重文件或受支持的部署路径尚未就绪，自行部署也应继续等待。

如果现有 API 已经满足质量和响应时间要求，架构标签本身不会改变开发者的选择。但如果部署运营者此前按激活参数量规划资源，就应立即修正方案。

关于 MoE，哪些说法被夸大了？

最常见的夸大，是认为稀疏性让模型兼得大模型的全部优势和小模型的全部运行特性。 MoE 确实把容量与计算量在一定程度上分开了，但这种分离有适用条件。

专家不一定是领域专家。 Mistral 对 Mixtral 的分析发现，路由模式并不能清晰地按学科划分。训练得到的专家不等于具备资质的专业人士，路由器选中了谁，也不能解释答案为什么正确。

总参数更多，不代表回答更好。 激活参数占比更低，也不代表模型更优。训练、架构和具体任务都会影响结果。上表只用于解释公布的模型规模，并不是质量排行榜。

激活参数占比更小，不等于费用或延迟按同样比例下降。 单看这个比例，无法推断服务商收费、排队、网络传输，或完成任务所需的生成 token 数量。

MoE 思路背后的关键论文

Shazeer 等人在 2017 年的论文中，系统提出了一种影响深远的稀疏门控 MoE 层，使模型容量可以增长，而计算量不必同比增长。 《超大规模神经网络：稀疏门控混合专家层》是理解这一机制的一手文献。论文对负载均衡和分布式性能的讨论也提醒我们：运行层面的取舍，从一开始就是这个思路的一部分。

开发者常问的 MoE 问题

大语言模型中的混合专家模型是什么？

它是一种构建大语言模型的方式，在模型内部设置多个专家网络，并通过训练得到的路由器进行选择。在稀疏 MoE 中，每个 token 在各个 MoE 层只使用被选中的专家。应用调用的仍然是同一个模型。

GPT-4 是混合专家模型吗？

GPT-4 技术报告没有披露包括模型规模在内的更多架构细节，也没有提供厂商核实的 MoE 参数明细。因此，不应将传闻中的参数量作为部署依据。

MoE 模型微调需要注意什么？

微调会调整模型学到的行为，但不会消除部署完整权重的资源要求。应在有代表性的流量下，评估微调后模型的任务质量与路由行为。Hugging Face 的 MoE 指南讨论了其中涉及的不同过拟合风险和均衡问题。

下一次部署决策，先补齐这些信息

周一，为每个入围模型附上一份推理服务说明。 记录厂商公布的总参数量与激活参数量、信息来源，以及具体检查点或 API 端点。如果使用托管服务，补上自己的任务测试结果和延迟测量值；如果自行部署，补上完整权重占用、缓存预留量，以及预期流量下的性能。这份说明，比按照宣传中最大的参数数字给候选模型排名更有价值。

想读懂 AI 产品背后的基础设施，以及它们对实际开发的影响，欢迎订阅邮件通讯。