> ## 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-.

# Mixture of Experts (MoE)：ルーティング、エキスパート並列、メモリ

> Mixture of Experts (MoE) を理解します。ルーティングの仕組み、メモリが総パラメータ数に比例する理由、MoE を採用しているオープンウェイトモデルを解説し、サイジングの計算式とハードウェアガイドも掲載しています。

ある**Mixture of Experts (MoE)** モデルは巨大なモデルのように見えますが、各トークン生成時には重みの小さな割合しか使用しません。この分離 — 巨大な総容量、トークンあたりの小さな計算量 — が、最新世代のフロンティアオープンウェイトモデルが MoE に移行した理由です。だからこそ、DeepSeek-V3 のような 671B の総パラメータを持つモデルでも、トークンあたり 37B しかアクティブにならないにもかかわらず、671B 全体を保持するのに十分なメモリが必要になります。このページでは、ルーティングの仕組み、サービングにおけるエキスパート並列の意味、そして MoE モデルのハードウェアサイジング方法を説明します。

> [!NOTE]
>
> Last verified: 2026-10-14

## What is Mixture of Experts

標準的な**デンス**トランスフォーマーでは、すべてのトークンがすべてのレイヤーを通過し、各フォワードパスですべてのパラメータをアクティブにします。70B のデンスモデルは、すべてのトークンに対して 70B のパラメータをすべて使用します。

MoE モデルは、選択されたトランスフォーマーブロックのフィードフォワードサブレイヤーを、複数の並列**エキスパート**サブネットワークと、各トークンをどのエキスパートが処理するかを決定する**ルーター**（**ゲーティングネットワーク**とも呼ばれる）で置き換えます。ほとんどのエキスパートは、任意のトークンに対してアイドル状態です。256 人のエキスパートを持つモデルでも、トークンあたり 8 人のみアクティブにする場合があります — ステップあたりの総容量の約 3% です。

その結果：

* **総パラメータ**はモデルに必要なメモリ量を決定します（すべてのエキスパートをロードし続ける必要があります）。
* **アクティブパラメータ**は各トークンの計算コストを決定します（選択されたエキスパートのみが実行されます）。

これが核心的なトレードです。MoE は、はるかに小さいモデルのトークンあたりの計算コストで、非常に大きなモデルの知識容量を購入します — ただし、エキスパートが機能するかどうかに関わらず、すべてのエキスパートのメモリコストは支払う必要があります。

## How does MoE routing work

各 MoE レイヤーには、各トークンを処理するエキスパートを選択するルーターが含まれています。本番モデルで最も一般的なアプローチは**トップ k ゲーティング**です：

1. ルーターは、トークンの隠れ状態を学習済みの重み行列に乗算し、次にソフトマックスを適用してすべてのエキスパートの確率分布を生成することで、各エキスパートのスコアを計算します。
2. 最も高いスコアを持つトップ k のエキスパートが選択されます。その出力は、ソフトマックスで正規化された重みを係数として結合されます。
3. 他のすべてのエキスパートはそのトークンに対して出力を生成しません — 完全にスキップされます。

k の値はモデルによって異なります。DeepSeek-V3 と Qwen3 は k=8 を使用します。gpt-oss は k=4 を使用します。Kimi K3 は 16 人のルーティングエキスパートと 2 人の共有エキスパートをトークンごとに使用します。

### Shared experts

一部のアーキテクチャは、ルーティングスコアに関係なくすべてのトークンでアクティブになる**共有エキスパート**のサブセットを予約します。共有エキスパートは一般的なパターン（言語モデルの基本、フォーマット）を処理するため、ルーティングされたエキスパートは専門化できます。Qwen3-Next は 1 人の共有エキスパートと 10 人のルーティングエキスパートを使用します。Kimi K3 は 2 人の共有エキスパートと 16 人のルーティングエキスパートを使用します。DeepSeek-V3 と元の Qwen3 MoE は共有エキスパートを使用しません — すべてのアクティブなエキスパートはルーターによって選択されます。

### Load balancing

常に同じ少数のエキスパートにトークンを送信するルーターでは、MoE の目的が失われます。それらのエキスパートがボトルネックになり、残りはアイドル状態になります。本番モデルは、エキスパートの使用をバランスさせるためにいくつかの戦略を使用します：

* **補助損失** — ルーターを均一なエキスパート使用に向かわせるトレーニング時のペナルティ。初期の MoE モデルのほとんど（Switch Transformer、ST-MoE）はこのアプローチを使用します。コストは専門化のわずかな低下です。ルーターは品質と並行してバランスを最適化します。
* **補助損失なしのロードバランシング** — DeepSeek-V3 は、推論時にエキスパートごとのルーティングバイアスを調整するバイアスベースのアプローチを導入しました。エキスパートがターゲットシェアより多くのトークンを受け取っている場合、バイアスが減少し、選択される可能性が低くなります。これにより、補助損失の品質トレードオフが完全に排除されます。
* **Stable LatentMoE** — Kimi K3 は、トークン間でより安定したエキスパート割り当てを生成する学習済み潜在ルーティングメカニズムを使用し、標準的なトップ k ゲーティングでロード不均衡を引き起こす分散を削減します。

実際的なポイント：ロードバランシングはサービング時ではなくトレーニング時に解決されます。ローカルで MoE モデルを実行するユーザーとして、ルーティングは設定しません — メモリと並列性を設定します。

## Why MoE memory scales with total parameters, not active

これは MoE モデルをローカルで実行する前に理解すべき最も重要なことです。

**すべてのエキスパートは常にメモリに常駐している必要があります。** ルーターは動的に — トークンごと、レイヤーごとに — どのエキスパートをアクティブにするかを決定します。特定のプロンプトにどのエキスパートが必要になるかを事前に知る方法はないため、すべてのエキスパートをロードして準備しておく必要があります。ディスクからオンデマンドでエキスパートをスワップすることは、インタラクティブな推論にははるかに遅すぎます。

つまり、[Memory and offloading](/ja/concepts/memory-and-offloading.md) のメモリ式が**総パラメータ**に適用され、アクティブパラメータには適用されません：

```text theme={"theme":{"light":"github-light","dark":"css-variables"}}
VRAM(GB) ≈ total_params(B) × bytes-per-param × 1.2
```

アクティブパラメータはトークンあたりの計算量（したがって生成速度）にのみ影響し、メモリには影響しません。

### Worked examples

| Model | Total params | Active params | Experts (active/total) | Memory at 4-bit (\~0.5 B/param) | Memory at 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 | Not publicly specified | \~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 キャッシュ、アクティベーション、フレームワークオーバーヘッドを考慮しています — デンスモデルと同じ式です。完全なサイジングの導出については [Memory and offloading](/ja/concepts/memory-and-offloading.md) を参照してください。

### What this means in practice

Qwen3-30B-A3B は 30.5B の総パラメータがありますが、アクティブなのは 3.3B だけです。3.3B のデンスモデルとほぼ同じ速度でトークンを生成しますが、30.5B 全体のメモリが必要です。4 ビットでは約 18 GB で、24 GB の GPU に収まります。30B のデンスモデルでも 4 ビットでほぼ同じメモリが必要ですが、30B のパラメータを 3.3B ではなくトークンごとにすべて処理するため、より遅くなります。

逆に、Kimi K3 は 2.8T の総パラメータと 104B のアクティブパラメータがあります。104B のデンスモデルとほぼ同じ速度でトークンを生成しますが、重みだけで約 1.4 TB のメモリを 4 ビットで必要とします。コンシューマーやプロシューマーのハードウェアでは保持できません。

## MoE vs dense models

| | Dense | MoE |
| - | - | - |
| **Parameters per token** | All parameters | Only active parameters (a fraction of total) |
| **Memory** | Scales with total parameters | Scales with total parameters (same formula) |
| **Compute per token** | Scales with total parameters | Scales with active parameters only |
| **Generation speed** | Limited by total parameter count | Limited by active parameter count — often much faster than a dense model of the same total size |
| **Knowledge capacity** | Limited by total parameters | Total parameters can be much larger for the same per-token compute |
| **Hardware requirement** | Must fit total parameters | Must fit total parameters (not active) |
| **Multi-GPU serving** | Tensor parallelism splits layers | Expert parallelism splits experts across GPUs |

重要な洞察：MoE は知識容量をトークンあたりの計算量から切り離します。671B パラメータの MoE（37B アクティブ）は、品質で 70B のデンスモデルに匹敵するかそれを上回り、ほぼ 70B の速度でトークンを生成できます — ただし 671B 分のメモリが必要です。

## Expert parallelism: serving MoE across multiple GPUs

MoE モデルが単一の GPU に収まらない場合、分散する必要があります。**エキスパート並列**は、そのための MoE 固有の戦略です：

* 各 GPU は総エキスパートのサブセットを保持します。256 エキスパートのモデルを 8 GPU に分散すると、各 GPU は 32 人のエキスパートを保持します。
* フォワードパス中に、ルーターの決定により、どのトークンをどの GPU に送信する必要があるかが決まります。GPU 3 のエキスパートにルーティングされたトークンは処理のために GPU 3 に通信され、その後結果が戻ります。
* 非エキスパートレイヤー（アテンション、埋め込み）は通常、標準的な**テンソル並列**を使用して分割され、各 GPU が各レイヤーの重み行列のスライスを保持します。

vLLM や TensorRT-LLM などの本番サービングランタイムは、アテンションレイヤーのテンソル並列と MoE レイヤーのエキスパート並列を組み合わせています。その結果は**混合並列**と呼ばれます。vLLM のドキュメントに設定の詳細が記載されています。重要な設定は、エキスパート並列がテンソル並列とは別の並列軸であることです。

実際的な意味：MoE モデルは GPU 間の高帯域幅インターコネクト（NVLink、InfiniBand）の恩恵を受けます。トークンはルーティングステップ中に GPU 間を移動する必要があるためです。PCIe のみで接続されたクラスターでは、GPU 間通信による大幅な速度低下が発生します。

## Which open-weight models use MoE

現在の世代のフロンティアオープンウェイトモデルは MoE に大きく移行しています。2026 年十月時点の状況です：

### Sub-50B total (runnable on 1-2 consumer GPUs at 4-bit)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| 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 total (multi-GPU or high-memory unified systems)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| gpt-oss-120b | 117B | 5.1B | 128 | 4 | Apache 2.0 |
| Qwen3-235B-A22B | 235B | 22B | 128 | 8 | Apache 2.0 |

### 250B+ total (server-class hardware required)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| DeepSeek-V3 / R1 | 671B | 37B | 256 | 8 | MIT (V3), custom (R1) |
| GLM-5.3 | 753B | \~40B | MoE | MoE | Custom (see [GLM-5.3](/ja/models/glm-5.3.md)) |
| Kimi K2 | 1T | 32B | 384 | 8 | Custom |
| Qwen3.8-2.4T-A95B | 2.4T | 95B | 512 | 10+1 shared | Apache 2.0 |
| Kimi K3 | 2.8T | 104B | 896 | 16+2 shared | Custom |
| DeepSeek V4.1-Flash | 552B | 8B in / 16B out | MoE | Asymmetric | MIT |

Sources: model cards on HuggingFace and the official technical reports linked below.

## Practical takeaway for local inference

MoE はモデルカードの数字の意味を変えます：

* **アクティブパラメータ**はモデルのトークン生成速度を示します。671B の MoE（37B アクティブ）は、ほぼ 37B の速度で生成します。
* **総パラメータ**はモデルに必要なメモリ量を示します。同じ 671B の MoE でも 671B 分の VRAM が必要で、37B ではありません。
* **エキスパート数とルーティング**は品質とトレーニング効率に影響するアーキテクチャの詳細ですが、ローカル推論ユーザーとしては設定しません — メモリと並列性を設定します。

MoE モデルが「2.4T パラメータ、95B アクティブ」と宣伝されているのを見たら、「95B の速度で生成、2.4T のメモリが必要」と読んでください。ハードウェアは総量でサイズし、アクティブ数の速度を楽しみます。

特定の MoE モデルと量子化がハードウェアに収まるかどうかをダウンロード前に確認するには、[GPU model-fit guide](/ja/guides/model-fit.md) を使用してください。

## Go deeper

> **[Memory and offloading](/ja/concepts/memory-and-offloading.md)**
>
> バイト/パラメータ（精度別）とオフロードメカニズムを含む完全なサイジング式。

> **[Quantization](/ja/concepts/quantization.md)**
>
> バイト/パラメータを縮小して、MoE とデンスモデルの両方のメモリ方程式を変更します。

> **[How inference works](/ja/concepts/how-inference-works.md)**
>
> デコードがメモリ帯域幅制約である理由と、アクティブパラメータが生成速度に影響する仕組み。

> **[Model serving and scaling](/ja/concepts/model-serving-and-scaling.md)**
>
> 並列戦略、マルチ GPU サービング、ランタイムがモデルを分散する方法。

## Models using MoE

> **[Kimi K3](/ja/models/kimi-k3.md)**
>
> 2.8T total, 104B active, 896 experts with Stable LatentMoE routing.

> **[DeepSeek](/ja/models/deepseek.md)**
>
> V3/R1 at 671B/37B, V4.1-Flash at 552B with asymmetric 8B/16B activation.

> **[Qwen3](/models/qwen3)**
>
> 30B-A3B and 235B-A22B MoE tiers, 128 experts with top-8 routing.

> **[Qwen3.8](/ja/models/qwen3.8.md)**
>
> 2.4T flagship with 95B active, 512 experts, 10 routed + 1 shared.

> **[GLM-5.3](/ja/models/glm-5.3.md)**
>
> 753B total, \~40B active, MoE with 1M context.

> **[gpt-oss](/models/gpt-oss)**
>
> 20b (32 experts) and 120b (128 experts), top-4 routing, Apache 2.0.

## Once it fits and runs

MoE モデルをハードウェアにロードさせるのが最初のステップです。`localhost` でリクエストに答え始めたら、次のステップは他の場所からもアクセスできるようにすることです。

> **[Give it a stable endpoint](/ja/quickstart.md)**
>
> Tokios はモデルの選択、ホスト、ファインチューニングは行いません — ローカルで実行されれば、Tokios はそれをどこからでも呼び出せる安定した認証済みエンドポイントに変換します。

## Frequently asked questions

> **Why does an MoE model need memory for all experts if only a few are active?**
>
> ルーターは各トークンごとに異なるエキスパートを選択するため、すべてのエキスパートがアクセス可能である必要があります。任意の瞬間には k 人のエキスパートのみが機能しますが、次のトークンでは完全に異なるセットが必要になる場合があります。つまり、すべてのエキスパートの重みが常にメモリ（VRAM または RAM）に常駐している必要があり — アクティブパラメータではなく総パラメータでサイズを設定します。

> **How do I know if my hardware can run an MoE model?**
>
> 計算します：総パラメータに重みあたりのバイト数を掛けます。4 ビット（ほとんどの MoE モデルのネイティブ量子化フロア）では、`total_params × 0.5 GB` です。KV キャッシュとオーバーヘッドに 20% を加えます。その数値が合計 VRAM + RAM に収まれば、モデルはロードされます。収まらない場合、どの程度の最適化でも変更できません — より多くのメモリまたはより小さいモデルが必要です。

> **What is the difference between shared experts and routed experts?**
>
> 共有エキスパートはすべてのトークンでアクティブです — 言語モデリングなどの一般的なタスクを処理します。ルーティングエキスパートはゲーティングネットワークによってトークンごとに選択されます。DeepSeek-V3 は 256 ルーティングエキスパート（8 アクティブ）を使用し、共有エキスパートはありません。Kimi K3 は 896 エキスパート（16 ルーティング + 2 共有）を使用します。Qwen3.8 は 512 エキスパート（10 ルーティング + 1 共有）を使用します。

> **Can I run an MoE model on a single GPU?**
>
> 小さいものだけです。Qwen3-30B-A3B（総 30.5B、約 18 GB at 4 ビット）は 24 GB の GPU に収まります。gpt-oss-20b（総 21B、約 13 GB at 4 ビット）も収まります。約 50B を超える総パラメータの場合、マルチ GPU サービング（エキスパート並列を備えた vLLM、SGLang）または CPU オフロードを備えた高統一メモリシステム（Mac Studio、DGX Spark）が必要です。

> **What is expert parallelism and when do I need it?**
>
> エキスパート並列はエキスパートレイヤーを複数の GPU に分割します — GPU 0 はエキスパート 0-63 を保持、GPU 1 はエキスパート 64-127 を保持、など。各 GPU はエキスパートの出力を計算し、オールツーオール通信で結合されます。総エキスパートの重みが単一の GPU に収まらない場合に必要です。vLLM と SGLang の両方がサポートしています。設定については [vLLM optimization guide](/ja/guides/vllm-optimization.md) を参照してください。

## Sources

* [DeepSeek-V3 Technical Report](https://arxiv.org/abs/2412.19437) — 671B total, 37B active, 256 experts, auxiliary-loss-free load balancing.
* [Kimi K2: Open Agentic Intelligence](https://arxiv.org/abs/2507.20534) — 1T total, 32B active, 384 experts, 8 active per token.
* [Kimi K3 model card](https://huggingface.co/moonshotai/Kimi-K3) — 2.8T total, 104B active, 896 experts, Stable LatentMoE.
* [Qwen3 Technical Report](https://arxiv.org/abs/2505.09388) — 128 experts, 8 active, no shared experts in Qwen3 MoE.
* [Qwen3-Next-80B-A3B](https://qwen.ai/blog?id=4074cca80393150c248e508aa62983f9cb7d27cd) — 512 experts, 10 routed + 1 shared.
* [Qwen3.8-Max announcement](https://qwen.ai/blog?id=qwen3.8) — 2.4T total, 95B active, 512 experts.
* [gpt-oss model card](https://arxiv.org/abs/2508.10925) — 32 experts (20b) and 128 experts (120b), 4 active per token.
* [GLM-5.3 model card](https://huggingface.co/zai-org/GLM-5.3) — 753B total, \~40B active.
* [Mixture of Experts Explained (localaimaster.com)](https://localaimaster.com/blog/mixture-of-experts-explained) — Routing mechanics and memory implications.
* [Mixture-of-Experts LLMs (Cameron R. Wolfe)](https://cameronrwolfe.substack.com/p/moe-llms) — Top-k gating formulation and training dynamics.
* [MoE training in Qwen3-235B and Kimi-K2](https://medium.com/clickbait-programming/moe-training-in-qwen3-235b-a22b-and-kimi-k2-c51f582d2ef5) — Learned routing comparison.
* [vLLM MoE Playbook](https://rocm.blogs.amd.com/software-tools-optimization/vllm-moe-guide/README.html) — Expert parallelism and mixed parallelism configuration.
* [Expert Parallelism in TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/advanced/expert-parallelism.html) — Multi-GPU expert distribution strategies.


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