MoE 详解：为什么 30B-A3B 运行起来像小模型 模型

#MoE解决的问题

传统语言模型被称为“稠密模型”：生成每个词时，都会让您的文本经过全部参数。一个 32B 的稠密模型在生成每个 token 时都会调用其 320 亿个参数。这使它强大，但也使它运行缓慢、资源消耗大：参数越多，所需的计算量和内存就越多，无法绕开这一点。

本地运行模型的困境就在这里：既想要大模型的知识和细致表现，又想要小模型的速度和低资源消耗。在消费级显卡上，70B 的稠密模型要么无法运行，要么慢得令人难以忍受。混合专家（Mixture of Experts）架构打破了这一取舍，将原本被认为相互关联的两件事分开：模型规模和每个 token 的成本。

#原理：按需激活专家

在混合专家模型中，大型计算层不再是一个单一模块，而是由多个称为“专家”的子网络组成。一个模型可以包含 64 个、128 个专家，有时甚至更多。每处理一个 token，一个小型分流器——即“路由器”——都会查看上下文，只选择激活 2 个、4 个或 8 个专家。其余专家不为这个 token 执行任何计算。

与“专家”一词给人的印象不同，这些专家并不是按主题划分的：并不存在“法语专家”或“编程专家”。路由器与模型一起训练，并根据统计模式分配任务，这些模式并非由人工操控。每处理一个 token，所选的专家都可能变化。处理完整句话时，几乎所有专家最终都会参与，但绝不会同时全部启用。

专家

专用子网络，全部加载到内存中，但每次处理token时仅少数子网络参与工作。

路由器（门控）

一个轻量级组件，逐token决定激活哪些专家。

已激活的专家

每 token 激活的专家数量，通常为 2 到 8。这个数值决定了运行速度。

当前激活参数

处理每个 token 时实际调用的参数总数——也就是参与计算的那部分参数。

#解读 30B-A3B 标注

这种让初学者困惑的表示方式，一旦掌握了读法，其实很容易理解。以 Qwen3 30B-A3B 为例：第一个数字是模型的总参数量，第二个数字位于“A”之后，表示每个 token 的活跃参数量，其中 A 代表 Active。

30B

该模型总共有300亿参数，这决定了加载时所需的内存大小。

A3B

每个token仅有约30亿个参数被激活。这决定了生成速度。

换言之，30B-A3B 可以理解为“储备 300 亿个参数，实际工作时使用 30 亿个”。该模型拥有 30B 模型那样丰富的知识，但生成速度大致相当于一个 3B 稠密模型。同样的逻辑也适用于其他所有近期发布的模型。

Qwen3 30B-A3B

总计 300 亿参数，其中 30 亿为活跃参数——面向大众的 MoE 典范。

Llama 4 Scout 17B-A2B

总计170亿参数，每个token约20亿参数活跃，另加多模态支持。

gpt-oss 120B

总参数量为 1200 亿，但激活参数仅约 50 亿——因此，相对于它的规模，其速度快得令人惊讶。

DeepSeek V3.2 671B-A37B

共有 6710 亿参数，激活 370 亿参数：这个庞然大物每生成一个 token 的计算开销，却「仅相当于一个中等规模模型」。

#显存：究竟有哪些变化

这是最容易被误解的一点，因此需要说清楚。MoE 的所有专家都必须加载到内存中，因为路由器可能在下一个 token 调用其中任意一个。因此，所需显存取决于总参数量，而不是激活的参数量。30B-A3B 的内存容量需求应按 30B 稠密模型来估算。

Qwen3 30B-A3B 量化为 Q4_K_M

约需 18–19 GB 显存，与 32B 稠密模型相当。因此适合使用 RTX 4090 24 GB；若显卡显存更小，则需要将部分模型转入系统内存。

Llama 4 Scout 17B-A2B，Q4量化

≈ 10-11 GB，适用于 RTX 4070 12 GB 或 3060 12 GB 显卡

gpt-oss 120B

数十 GB：仅适合高配置机器，或将模型卸载到 RAM/SSD 的情况。

因此，本地运行 MoE 的优势不在于节省内存，而在于相同显存容量下的质量与速度表现。当一个 30B 稠密模型在您的显卡上运行缓慢时，一个 30B-A3B MoE 模型占用同样的空间，却能以快得多的速度生成内容。而且，由于并非每个 token 都会用到那些未激活的专家，MoE 通常能较好地适应将部分权重卸载到系统 RAM 中的做法：保留在 GPU 上的部分会优先被调用。

#速度：为何如此快速

LLM的生成速度主要取决于生成每个token时涉及的参数数量。由于MoE只激活其中一小部分，每个token所需的计算量会大幅下降。具体来说，30B-A3B模型生成token的速度接近一个3B稠密模型，同时回答仍具有30B模型的深度。

这正是 MoE 在配置不高的机器上掀起热潮的原因：可以获得大模型的质量，却不必承受它的慢速度。代价在别处——前面提到的内存，以及下载时更大的磁盘占用，因为必须存储所有专家。

速度提升的原因

每个 token 激活的参数较少 → 计算开销更小 → 每秒 token 数更高。

不变的部分

显存和文件大小，均与参数总数相关。

净收益

在内存容量相同的情况下，MoE模型能提供更丰富的知识，同时速度与规模小得多的稠密模型相当。

#需要了解的限制

MoE 并非万能，也不会让密集模型过时。在激活参数数量相同的情况下，密集模型通常在推理的细致程度上更胜一筹：30B-A3B 表现出色，但一个真正的 30B 密集模型，如果处理每个 token 时都激活全部 300 亿参数，能力会更强——代价是在本地运行时慢到难以接受。

内存需求不会减少

需要足以容纳整个模型的显存。MoE 并不能让大型模型装进显存容量较小的显卡。

按令牌激活的质量

在活跃参数量相近的情况下，训练充分的稠密模型在高难度推理上往往仍占优势。

下载体积较大

所有专家的权重都会被存储：GGUF 文件的大小取决于总参数量，而不是激活参数量。

量化敏感性

路由模块及部分专家对过于激进的量化容忍度较差；请使用 Q4_K_M 或精度更高的量化格式。

#值得在本地尝试的旗舰 MoE 模型

以下是 2026 年最值得在家中尝试的混合专家模型，按从最容易上手到要求最高的顺序排列。

Qwen3 30B-A3B

最佳入门选择。通用任务和编程表现都很扎实，速度出色，Q4 量化后约占 18 GB。是入门 MoE 的标杆之选。

Llama 4 Scout 17B-A2B

多模态（文本+图像）MoE 架构，支持长上下文，VRAM 占用更轻。如果您有 12GB 显存的显卡，这款模型非常合适。

gpt-oss 120B

OpenAI 的开放权重模型，激活参数仅约 5B：以这样的模型规模而言，速度快得惊人，但需要强大的硬件配置。

DeepSeek V3.2 671B-A37B

庞然大物。仅适用于配备大量 RAM、并将大量模型权重卸载到 RAM 中的配置，适合想探索顶尖模型的人。

如果您刚入门，请从 Qwen3 30B-A3B 开始：在单张消费级显卡上，它是最能展现这种架构优势的 MoE 模型。

#3分钟内尝试MoE

如果 Ollama 已安装并正在默认端口上监听，只需两条命令，就能感受到 MoE 模型与稠密模型之间的区别。

1. 01
   下载并启动一个MoE模型

   获取Qwen3 30B-A3B模型并立即与之对话。首次启动将下载模型（需占用数GB空间）。
2. 02
   观察运行速度

   提出一个稍长的问题，并记录生成吞吐量。尽管它拥有 300 亿参数，仍能迅速作答，速度与小模型相当。
3. 03
   与稠密模型对比

   运行一个规模相近的稠密模型，并提出相同的问题。在显存占用相近的情况下，MoE 模型的生成速度应该明显更快。

# Lancer un MoE et discuter avec
ollama run qwen3:30b-a3b

# Pour comparer avec un dense de taille voisine
ollama run qwen3:32b

#深入了解

将 MoE 与本地运行模型的其他基础概念联系起来，会更容易理解它。以下指南直接延伸了本指南的内容：

选择量化方案（Q4、Q5、Q8、FP16）

MoE对过于激进的量化较为敏感：本指南帮助您在质量与内存占用之间找到合适的平衡。

安装 Ollama：Windows、macOS 和 Linux

用于在下载您的第一个 MoE 模型之前，先配置好运行在 11434 端口的本地守护进程。

本地运行 Llama 4 Scout：使用 Ollama 的安装与初步测试

逐步详解一个多模态 MoE 模型，展示本指南中的理论如何实际发挥作用。