> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokios.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Tokios exposes private local models through https://api.tokios.com using an outbound-only connector tunnel.
> Use 'connector' for the local tokios-connector process.
> Use 'deployment' for the public model name in the API model field.
> Use 'upstream model id' for the model served by Ollama, llama.cpp, vLLM, LM Studio, or another local backend.
> API keys use the prefix sk-tok-. Connector tokens use the prefix ct-tok-.

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

> 了解混合专家模型 (MoE)：路由如何工作、为什么内存取决于总参数量、哪些开放权重模型采用 MoE。包含容量计算公式和硬件指南。

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

> [!NOTE]
>
> 最后验证时间：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**：

1. 路由器将 token 的隐藏状态与学习到的权重矩阵相乘，为每个专家计算得分，然后应用 softmax 生成所有专家上的概率分布。
2. 选出得分最高的 top-k 个专家。它们的输出使用 softmax 归一化后的权重作为系数进行组合。
3. 其余专家对该 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、逐层——激活哪些专家。无法预先知道某个提示需要哪些专家，因此每个专家都必须加载并就绪。按需从磁盘交换专家的速度远不能满足交互式推理的需求。

这意味着[内存与卸载](/zh/concepts/memory-and-offloading.md)中的内存公式适用于**总参数**，而非活跃参数：

```text theme={"theme":{"light":"github-light","dark":"css-variables"}}
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 模型使用相同的公式。完整容量推导请参见[内存与卸载](/zh/concepts/memory-and-offloading.md)。

### 实际意义

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](/zh/models/glm-5.3.md)) |
| 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 模型适配指南](/zh/guides/model-fit.md) 在下载前检查特定 MoE 模型和量化是否适配你的硬件。

## 深入了解

> **[内存与卸载](/zh/concepts/memory-and-offloading.md)**
>
> 完整的容量计算公式，包括不同精度下每参数字节数和卸载机制。

> **[量化](/zh/concepts/quantization.md)**
>
> 缩小每参数字节数，改变 MoE 和 dense 模型的内存等式。

> **[推理如何工作](/zh/concepts/how-inference-works.md)**
>
> 为什么解码受内存带宽限制，以及活跃参数如何影响生成速度。

> **[模型服务与扩展](/zh/concepts/model-serving-and-scaling.md)**
>
> 并行策略、多 GPU 推理服务，以及运行时如何分布模型。

## 使用 MoE 的模型

> **[Kimi K3](/zh/models/kimi-k3.md)**
>
> 2.8T 总参数、104B 活跃参数、896 个专家，采用 Stable LatentMoE 路由。

> **[DeepSeek](/zh/models/deepseek.md)**
>
> V3/R1 为 671B/37B，V4.1-Flash 为 552B，采用非对称 8B/16B 激活。

> **[Qwen3](/models/qwen3)**
>
> 30B-A3B 和 235B-A22B MoE 层级，128 个专家，top-8 路由。

> **[Qwen3.8](/zh/models/qwen3.8.md)**
>
> 2.4T 旗舰，95B 活跃参数、512 个专家、10 个路由 + 1 个共享。

> **[GLM-5.3](/zh/models/glm-5.3.md)**
>
> 753B 总参数、\~40B 活跃参数、MoE、1M 上下文。

> **[gpt-oss](/models/gpt-oss)**
>
> 20b（32 个专家）和 120b（128 个专家），top-4 路由，Apache 2.0。

## 模型就绪之后

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

> **[提供稳定的端点](/zh/quickstart.md)**
>
> 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 优化指南](/zh/guides/vllm-optimization.md)。

## 来源

* [DeepSeek-V3 Technical Report](https://arxiv.org/abs/2412.19437) — 671B 总参数、37B 活跃参数、256 个专家、无辅助损失负载均衡。
* [Kimi K2: Open Agentic Intelligence](https://arxiv.org/abs/2507.20534) — 1T 总参数、32B 活跃参数、384 个专家、每 token 8 个活跃。
* [Kimi K3 model card](https://huggingface.co/moonshotai/Kimi-K3) — 2.8T 总参数、104B 活跃参数、896 个专家、Stable LatentMoE。
* [Qwen3 Technical Report](https://arxiv.org/abs/2505.09388) — 128 个专家、8 个活跃、Qwen3 MoE 无共享专家。
* [Qwen3-Next-80B-A3B](https://qwen.ai/blog?id=4074cca80393150c248e508aa62983f9cb7d27cd) — 512 个专家、10 个路由 + 1 个共享。
* [Qwen3.8-Max announcement](https://qwen.ai/blog?id=qwen3.8) — 2.4T 总参数、95B 活跃参数、512 个专家。
* [gpt-oss model card](https://arxiv.org/abs/2508.10925) — 32 个专家（20b）和 128 个专家（120b）、每 token 4 个活跃。
* [GLM-5.3 model card](https://huggingface.co/zai-org/GLM-5.3) — 753B 总参数、\~40B 活跃参数。
* [Mixture of Experts Explained (localaimaster.com)](https://localaimaster.com/blog/mixture-of-experts-explained) — 路由机制和内存影响。
* [Mixture-of-Experts LLMs (Cameron R. Wolfe)](https://cameronrwolfe.substack.com/p/moe-llms) — Top-k gating 公式和训练动态。
* [MoE training in Qwen3-235B and Kimi-K2](https://medium.com/clickbait-programming/moe-training-in-qwen3-235b-a22b-and-kimi-k2-c51f582d2ef5) — 学习路由对比。
* [vLLM MoE Playbook](https://rocm.blogs.amd.com/software-tools-optimization/vllm-moe-guide/README.html) — 专家并行和混合并行配置。
* [Expert Parallelism in TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/advanced/expert-parallelism.html) — 多 GPU 专家分布策略。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.