混合专家模型 (MoE)：路由、专家并行与内存

一个混合专家模型 (MoE) 看起来像一个巨大的模型，但每个生成的 token 只使用其中一小部分权重。这种分离——巨大的总容量、小量的每 token 计算——正是新一代前沿开放权重模型转向 MoE 的原因。这也是为什么像 DeepSeek-V3 这样拥有 671B 总参数的模型每个 token 只激活 37B，却仍然需要足够的内存来容纳全部 671B 参数。本页介绍路由如何工作、专家并行对推理服务意味着什么，以及如何为 MoE 模型配置硬件。

最后验证时间：2026-10-14

什么是混合专家模型

在标准 dense Transformer 中，每个 token 在每次前向传播时都会经过每一层并激活全部参数。一个 70B 的 dense 模型对每个 token 都会使用全部 70B 参数。 MoE 模型将选定 Transformer 块中的前馈子层替换为多个并行的 expert 子网络和一个 router（也称为 gating network），由它决定每个 token 由哪些专家处理。对于任何给定的 token，大多数专家处于空闲状态。一个拥有 256 个专家的模型可能每个 token 只激活 8 个——大约每步使用总容量的 3%。结果是：

总参数决定模型需要多少内存（所有专家必须保持加载状态）。
活跃参数决定每个 token 的计算成本（只有被选中的专家运行）。

这就是核心权衡。MoE 以较小模型的每 token 计算成本换取了超大模型的知识容量——但你仍然必须为每个专家支付内存开销，无论它是否被激活。

MoE 路由如何工作

每个 MoE 层包含一个路由器，用于选择哪些专家处理每个 token。生产模型中最常见的方法是 top-k gating：

路由器将 token 的隐藏状态与学习到的权重矩阵相乘，为每个专家计算得分，然后应用 softmax 生成所有专家上的概率分布。
选出得分最高的 top-k 个专家。它们的输出使用 softmax 归一化后的权重作为系数进行组合。
其余专家对该 token 不产生任何输出——它们被完全跳过。

k 的值因模型而异。DeepSeek-V3 和 Qwen3 使用 k=8。gpt-oss 使用 k=4。Kimi K3 使用 16 个路由专家加 2 个共享专家。

共享专家

部分架构会保留一组 shared experts，它们对每个 token 都激活，不受路由得分影响。共享专家处理常见模式（语言建模基础、格式处理），让路由专家可以专注于更专门的任务。Qwen3-Next 使用 1 个共享专家加 10 个路由专家。Kimi K3 使用 2 个共享专家加 16 个路由专家。DeepSeek-V3 和原始 Qwen3 MoE 不使用共享专家——所有活跃专家均由路由器选出。

负载均衡

如果路由器总是把 token 发送给同样的少数几个专家，就违背了 MoE 的初衷：这些专家会成为瓶颈，其余专家则闲置。生产模型使用多种策略来保持专家使用均衡：

辅助损失——一种训练时的惩罚项，推动路由器均匀使用各专家。早期大多数 MoE 模型（Switch Transformer、ST-MoE）采用这种方式。代价是专业化的轻微降低：路由器在优化质量的同时还要优化均衡。
无辅助损失负载均衡——DeepSeek-V3 引入了一种基于偏置的方法，在推理时调整每个专家的路由偏置。如果某个专家接收的 token 超过其目标份额，其偏置会降低，使其被选中的概率下降。这完全消除了辅助损失的质量折损。
Stable LatentMoE——Kimi K3 使用一种学习到的潜在路由机制，产生更稳定的跨 token 专家分配，降低了标准 top-k gating 中导致负载不均的方差。

实际要点：负载均衡在训练时就已解决，而非推理服务时。作为在本地运行 MoE 模型的用户，你不需要配置路由——你需要配置的是内存和并行。

为什么 MoE 内存取决于总参数而非活跃参数

这是在本地运行 MoE 模型前最重要的一个概念。 所有专家必须始终驻留在内存中。 路由器动态决定——逐 token、逐层——激活哪些专家。无法预先知道某个提示需要哪些专家，因此每个专家都必须加载并就绪。按需从磁盘交换专家的速度远不能满足交互式推理的需求。这意味着内存与卸载中的内存公式适用于总参数，而非活跃参数：

VRAM(GB) ≈ total_params(B) × bytes-per-param × 1.2

活跃参数只影响每 token 的计算量（以及生成速度），不影响内存。

计算示例

模型	总参数	活跃参数	专家（活跃/总数）	4-bit 内存（~0.5 B/param）	8-bit 内存（~1 B/param）
DeepSeek-V3 / R1	671B	37B	8 of 256	~403 GB	~805 GB
Kimi K2	1T	32B	8 of 384	~600 GB	~1,200 GB
Kimi K3	2.8T	104B	16+2 of 896	~1,680 GB	~3,360 GB
Qwen3-30B-A3B	30.5B	3.3B	8 of 128	~18 GB	~37 GB
Qwen3-235B-A22B	235B	22B	8 of 128	~141 GB	~282 GB
Qwen3.8-2.4T-A95B	2.4T	95B	10+1 of 512	~1,440 GB	~2,880 GB
GLM-5.3	753B	~40B	未公开	~452 GB	~904 GB
gpt-oss-20b	21B	3.6B	4 of 32	~13 GB	~25 GB
gpt-oss-120b	117B	5.1B	4 of 128	~70 GB	~140 GB

1.2x 系数考虑了适度上下文长度下的 KV 缓存、激活值和框架开销——与 dense 模型使用相同的公式。完整容量推导请参见内存与卸载。

实际意义

Qwen3-30B-A3B 拥有 30.5B 总参数，但只有 3.3B 活跃参数。它的 token 生成速度大约与 3.3B dense 模型相当——但它需要容纳全部 30.5B 参数的内存。4-bit 量化下大约 18 GB，可以放入 24 GB GPU。一个 30B dense 模型需要差不多的内存（4-bit 量化下），但生成速度更慢，因为它每个 token 要处理全部 30B 参数而非 3.3B。反过来，Kimi K3 拥有 2.8T 总参数和 104B 活跃参数。它的 token 生成速度大约与 104B dense 模型相当——但仅权重就需要约 1.4 TB 内存（4-bit 量化下）。没有任何消费级或专业级硬件能容纳这个量。

MoE 与 dense 模型对比

	Dense	MoE
每 token 参数	全部参数	仅活跃参数（总参数的一部分）
内存	取决于总参数	取决于总参数（相同公式）
每 token 计算	取决于总参数	仅取决于活跃参数
生成速度	受总参数量限制	受活跃参数量限制——通常比同等总参数量的 dense 模型快得多
知识容量	受总参数限制	在相同每 token 计算下，总参数可以大得多
硬件需求	必须容纳总参数	必须容纳总参数（而非活跃参数）
多 GPU 推理	张量并行切分层	专家并行切分专家到多个 GPU

关键洞察：MoE 将知识容量与每 token 计算解耦。一个 671B 参数、37B 活跃的 MoE 可以在质量上匹配甚至超越 70B dense 模型，同时以大约 70B 的速度生成 token——但它需要 671B 参数量的内存。

专家并行：跨多 GPU 服务 MoE

当一个 MoE 模型无法放入单个 GPU 时，你需要分布式部署。专家并行是 MoE 特有的分布式策略：

每个 GPU 持有总专家的一个子集。256 个专家的模型跨 8 个 GPU 部署时，每个 GPU 持有 32 个专家。
在前向传播过程中，路由器的决策决定哪些 token 需要发送到哪个 GPU。路由到 GPU 3 上专家的 token 会被传送到 GPU 3 进行处理，然后结果返回。
非专家层（注意力层、嵌入层）通常使用标准的张量并行切分，每个 GPU 持有每层权重矩阵的一片。

vLLM 和 TensorRT-LLM 等生产级推理运行时会结合注意力层的张量并行和 MoE 层的专家并行。结果称为混合并行。vLLM 文档详细介绍了配置方法；关键设置是专家并行是一个独立于张量并行的并行维度。实际影响：MoE 模型受益于 GPU 间的高带宽互连（NVLink、InfiniBand），因为 token 在路由步骤中必须在 GPU 之间移动。仅通过 PCIe 连接的集群会因跨 GPU 通信而遭受显著的速度损失。

哪些开放权重模型使用 MoE

当前一代前沿开放权重模型大量转向了 MoE。以下是截至 2026 年十月的格局：

总参数 50B 以下（可在 1-2 个消费级 GPU 上以 4-bit 运行）

模型	总参数	活跃参数	专家数	每 token 活跃数	许可证
gpt-oss-20b	21B	3.6B	32	4	Apache 2.0
Qwen3-30B-A3B	30.5B	3.3B	128	8	Apache 2.0

总参数 50B-250B（多 GPU 或高内存统一内存系统）

模型	总参数	活跃参数	专家数	每 token 活跃数	许可证
gpt-oss-120b	117B	5.1B	128	4	Apache 2.0
Qwen3-235B-A22B	235B	22B	128	8	Apache 2.0

总参数 250B+（需要服务器级硬件）

模型	总参数	活跃参数	专家数	每 token 活跃数	许可证
DeepSeek-V3 / R1	671B	37B	256	8	MIT (V3), custom (R1)
GLM-5.3	753B	~40B	MoE	MoE	Custom (见 GLM-5.3)
Kimi K2	1T	32B	384	8	Custom
Qwen3.8-2.4T-A95B	2.4T	95B	512	10+1 共享	Apache 2.0
Kimi K3	2.8T	104B	896	16+2 共享	Custom
DeepSeek V4.1-Flash	552B	8B in / 16B out	MoE	非对称	MIT

来源：HuggingFace 上的模型卡和下方链接的官方技术报告。

本地推理的实际要点

MoE 改变了模型卡上数字的含义：

活跃参数告诉你模型的 token 生成速度。一个 671B MoE、37B 活跃的模型以大约 37B 的速度生成。
总参数告诉你模型需要多少内存。同样是那个 671B MoE，需要 671B 参数量的 VRAM，而非 37B。
专家数量和路由是影响质量和训练效率的架构细节，但作为本地推理用户，你不需要配置它们——你需要配置的是内存和并行。

当你看到一个 MoE 模型宣传”2.4T 参数、95B 活跃”时，这样理解：“以 95B 的速度生成，需要 2.4T 的内存。“按总参数量配置硬件，享受活跃参数量带来的速度。使用 GPU 模型适配指南在下载前检查特定 MoE 模型和量化是否适配你的硬件。

深入了解

内存与卸载

完整的容量计算公式，包括不同精度下每参数字节数和卸载机制。

量化

缩小每参数字节数，改变 MoE 和 dense 模型的内存等式。

推理如何工作

为什么解码受内存带宽限制，以及活跃参数如何影响生成速度。

模型服务与扩展

并行策略、多 GPU 推理服务，以及运行时如何分布模型。

使用 MoE 的模型

Kimi K3

2.8T 总参数、104B 活跃参数、896 个专家，采用 Stable LatentMoE 路由。

DeepSeek

V3/R1 为 671B/37B，V4.1-Flash 为 552B，采用非对称 8B/16B 激活。

Qwen3

30B-A3B 和 235B-A22B MoE 层级，128 个专家，top-8 路由。

Qwen3.8

2.4T 旗舰，95B 活跃参数、512 个专家、10 个路由 + 1 个共享。

GLM-5.3

753B 总参数、~40B 活跃参数、MoE、1M 上下文。

gpt-oss

20b（32 个专家）和 120b（128 个专家），top-4 路由，Apache 2.0。

模型就绪之后

让 MoE 模型在硬件上成功加载是第一步。当它在 localhost 上响应请求后，下一步是让它从任何地方都可以访问。

提供稳定的端点

Tokios 不负责选择、托管或微调模型——一旦模型在本地运行，Tokios 就能将其转变为稳定的、经过认证的端点，你可以从任何地方调用。

常见问题

为什么 MoE 模型只有少数专家活跃却需要容纳全部专家的内存？

路由器为每个 token 选择不同的专家，因此每个专家都必须可访问。在任意时刻只有 k 个专家激活，但下一个 token 可能需要完全不同的专家组合。这意味着所有专家权重必须始终驻留在内存（VRAM 或 RAM）中——你需要按总参数而非活跃参数来规划内存。

如何判断我的硬件能否运行 MoE 模型？

计算：总参数 × 每权重字节数。4-bit（大多数 MoE 模型的原生量化下限）下为 total_params × 0.5 GB。加上 20% 的 KV 缓存和开销。如果结果在你的 VRAM + RAM 总量范围内，模型可以加载。如果放不下，再多的优化也无法改变——你需要更多内存或更小的模型。

共享专家和路由专家有什么区别？

共享专家对每个 token 都激活——它们处理语言建模等通用任务。路由专家由门控网络逐 token 选择。DeepSeek-V3 使用 256 个路由专家、8 个活跃、无共享专家。Kimi K3 使用 896 个专家、16 个路由 + 2 个共享。Qwen3.8 使用 512 个专家、10 个路由 + 1 个共享。

能在单个 GPU 上运行 MoE 模型吗？

只有小型的可以。Qwen3-30B-A3B（30.5B 总参数、约 18 GB，4-bit 量化下）可以放入 24 GB GPU。gpt-oss-20b（21B 总参数、约 13 GB，4-bit 量化下）也可以。总参数超过约 50B 的模型需要多 GPU 推理服务（vLLM、SGLang 配合专家并行）或高统一内存系统（Mac Studio、DGX Spark）配合 CPU 卸载。

什么是专家并行，什么时候需要它？

专家并行将专家层分布到多个 GPU——GPU 0 持有专家 0-63，GPU 1 持有专家 64-127，依此类推。每个 GPU 计算其专家的输出，然后通过 all-to-all 通信合并结果。当总专家权重无法放入单个 GPU 时就需要它。vLLM 和 SGLang 都支持；配置方法请参见 vLLM 优化指南。

来源

DeepSeek-V3 Technical Report — 671B 总参数、37B 活跃参数、256 个专家、无辅助损失负载均衡。
Kimi K2: Open Agentic Intelligence — 1T 总参数、32B 活跃参数、384 个专家、每 token 8 个活跃。
Kimi K3 model card — 2.8T 总参数、104B 活跃参数、896 个专家、Stable LatentMoE。
Qwen3 Technical Report — 128 个专家、8 个活跃、Qwen3 MoE 无共享专家。
Qwen3-Next-80B-A3B — 512 个专家、10 个路由 + 1 个共享。
Qwen3.8-Max announcement — 2.4T 总参数、95B 活跃参数、512 个专家。
gpt-oss model card — 32 个专家（20b）和 128 个专家（120b）、每 token 4 个活跃。
GLM-5.3 model card — 753B 总参数、~40B 活跃参数。
Mixture of Experts Explained (localaimaster.com) — 路由机制和内存影响。
Mixture-of-Experts LLMs (Cameron R. Wolfe) — Top-k gating 公式和训练动态。
MoE training in Qwen3-235B and Kimi-K2 — 学习路由对比。
vLLM MoE Playbook — 专家并行和混合并行配置。
Expert Parallelism in TensorRT-LLM — 多 GPU 专家分布策略。

入门

模型

概念

参考