> ## 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): Routing, Expert-Parallelität und Speicher

> Verstehen Sie Mixture of Experts (MoE): wie das Routing funktioniert, warum der Speicherbedarf mit der Gesamtzahl der Parameter skaliert und welche Open-Weight-Modelle MoE verwenden. Mit Formeln zur Dimensionierung und einem Hardware-Leitfaden.

Ein **Mixture-of-Experts (MoE)**-Modell sieht aus wie ein riesiges Modell, verwendet bei jedem erzeugten Token aber nur einen kleinen Teil seiner Gewichte. Diese Trennung — enorme Gesamtkapazität bei geringer Berechnung pro Token — ist der Grund, warum die neueste Generation offener Frontier-Modelle auf MoE umgestiegen ist. Deshalb benötigt ein Modell wie DeepSeek-V3 mit 671B Gesamtparametern, das pro Token nur 37B aktiviert, dennoch genug Speicher für alle 671B. Diese Seite erklärt, wie das Routing funktioniert, was Expert-Parallelität für das Serving bedeutet und wie die Hardware für MoE-Modelle dimensioniert wird.

> [!NOTE]
>
> Zuletzt überprüft: 2026-10-14

## Was ist Mixture of Experts

In einem Standard-**Dense**-Transformer durchläuft jedes Token jede Schicht und aktiviert bei jedem Forward-Pass alle Parameter. Ein Dense-Modell mit 70B verwendet für jedes Token alle 70B Parameter.

Ein MoE-Modell ersetzt die Feed-Forward-Subschicht in ausgewählten Transformer-Blöcken durch mehrere parallele **Expert**-Subnetzwerke und einen **Router** (auch **Gating-Netzwerk** genannt), der entscheidet, welche Experts jedes Token verarbeiten. Die meisten Experts bleiben für ein gegebenes Token inaktiv. Ein Modell mit 256 Experts aktiviert möglicherweise nur 8 pro Token — etwa 3% seiner Gesamtkapazität pro Schritt.

Das Ergebnis:

* **Gesamtparameter** bestimmen, wie viel Speicher das Modell benötigt (alle Experts müssen geladen bleiben).
* **Aktive Parameter** bestimmen, wie viel Berechnung jedes Token kostet (nur die ausgewählten Experts laufen).

Das ist der Kernkompromiss. MoE verschafft die Wissenskapazität eines sehr großen Modells bei den Berechnungskosten pro Token eines viel kleineren — aber man zahlt dennoch den Speicherpreis für jeden Expert, ob er aktiv wird oder nicht.

## Wie funktioniert das MoE-Routing

Jede MoE-Schicht enthält einen Router, der auswählt, welche Experts jedes Token verarbeiten. Der häufigste Ansatz in Produktionsmodellen ist **Top-k-Gating**:

1. Der Router berechnet für jeden Expert einen Score, indem er den Hidden-State des Tokens mit einer gelernten Gewichtsmatrix multipliziert, und wendet dann ein Softmax an, um eine Wahrscheinlichkeitsverteilung über alle Experts zu erzeugen.
2. Die Top-k-Experts mit den höchsten Scores werden ausgewählt. Ihre Ausgaben werden mit den softmax-normalisierten Gewichten als Koeffizienten kombiniert.
3. Alle übrigen Experts erzeugen für dieses Token keine Ausgabe — sie werden vollständig übersprungen.

Der Wert von k variiert je nach Modell. DeepSeek-V3 und Qwen3 verwenden k=8. gpt-oss verwendet k=4. Kimi K3 verwendet 16 geroutete Experts plus 2 Shared Experts pro Token.

### Shared Experts

Einige Architekturen reservieren eine Teilmenge von **Shared Experts**, die für jedes Token aktiviert werden, unabhängig von den Routing-Scores. Shared Experts verarbeiten gängige Muster (Grundlagen der Sprachmodellierung, Formatierung), damit sich die gerouteten Experts spezialisieren können. Qwen3-Next verwendet 1 Shared Expert plus 10 geroutete Experts. Kimi K3 verwendet 2 Shared Experts plus 16 geroutete Experts. DeepSeek-V3 und das ursprüngliche Qwen3-MoE verwenden keine Shared Experts — alle aktiven Experts werden vom Router ausgewählt.

### Lastverteilung

Ein Router, der Tokens immer an dieselben wenigen Experts sendet, macht den Zweck von MoE zunichte: Diese Experts werden zu Engpässen, während die übrigen inaktiv bleiben. Produktionsmodelle verwenden verschiedene Strategien, um die Expert-Nutzung auszubalancieren:

* **Auxiliary Loss** — eine Trainingsstrafe, die den Router zu gleichmäßiger Expert-Nutzung drängt. Die meisten frühen MoE-Modelle (Switch Transformer, ST-MoE) verwenden diesen Ansatz. Der Preis ist eine leichte Verringerung der Spezialisierung: Der Router optimiert sowohl Balance als auch Qualität.
* **Auxiliary-loss-freie Lastverteilung** — DeepSeek-V3 führte einen biasbasierten Ansatz ein, der die routing-biases pro Expert zur Inferenzzeit anpasst. Wenn ein Expert mehr Tokens erhält als seinen Zielanteil, sinkt sein Bias, wodurch er seltener ausgewählt wird. Dies eliminiert den Qualitätkompromiss von Auxiliary Losses vollständig.
* **Stable LatentMoE** — Kimi K3 verwendet einen gelernten latenten Routing-Mechanismus, der stabilere Expert-Zuweisungen über Tokens hinweg erzeugt und die Varianz reduziert, die bei Standard-Top-k-Gating zu Lastungleichgewicht führt.

Die praktische Erkenntnis: Lastverteilung wird zur Trainingszeit gelöst, nicht zur Serving-Zeit. Als Benutzer, der ein MoE-Modell lokal ausführt, konfiguriert man kein Routing — man konfiguriert Speicher und Parallelität.

## Warum der MoE-Speicher mit den Gesamtparametern skaliert, nicht mit den aktiven

Das ist das Wichtigste, was man vor dem Betrieb eines MoE-Modells lokal verstehen muss.

**Alle Experts müssen jederzeit im Speicher resident sein.** Der Router entscheidet dynamisch — pro Token, pro Schicht — welche Experts aktiviert werden. Es gibt keine Möglichkeit, im Voraus zu wissen, welche Experts ein bestimmter Prompt benötigt, daher muss jeder Expert geladen und bereit sein. Experts bei Bedarf von der Festplatte nachzuladen ist für interaktive Inferenz viel zu langsam.

Das bedeutet, dass die Speicherformel aus [Memory and offloading](/de/concepts/memory-and-offloading.md) für die **Gesamtparameter** gilt, nicht für die aktiven:

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

Aktive Parameter beeinflussen nur die Berechnung pro Token (und damit die Generierungsgeschwindigkeit), nicht den Speicher.

### Durchgerechnete Beispiele

| Modell | Gesamtparameter | Aktive Parameter | Experts (aktiv/gesamt) | Speicher bei 4-Bit (\~0.5 B/Param) | Speicher bei 8-Bit (\~1 B/Param) |
| - | - | - | - | - | - |
| DeepSeek-V3 / R1 | 671B | 37B | 8 von 256 | \~403 GB | \~805 GB |
| Kimi K2 | 1T | 32B | 8 von 384 | \~600 GB | \~1,200 GB |
| Kimi K3 | 2.8T | 104B | 16+2 von 896 | \~1,680 GB | \~3,360 GB |
| Qwen3-30B-A3B | 30.5B | 3.3B | 8 von 128 | \~18 GB | \~37 GB |
| Qwen3-235B-A22B | 235B | 22B | 8 von 128 | \~141 GB | \~282 GB |
| Qwen3.8-2.4T-A95B | 2.4T | 95B | 10+1 von 512 | \~1,440 GB | \~2,880 GB |
| GLM-5.3 | 753B | \~40B | Nicht öffentlich spezifiziert | \~452 GB | \~904 GB |
| gpt-oss-20b | 21B | 3.6B | 4 von 32 | \~13 GB | \~25 GB |
| gpt-oss-120b | 117B | 5.1B | 4 von 128 | \~70 GB | \~140 GB |

Der Faktor 1.2x berücksichtigt KV-Cache, Aktivierungen und Framework-Overhead bei moderater Kontextlänge — dieselbe Formel wie bei Dense-Modellen. Siehe [Memory and offloading](/de/concepts/memory-and-offloading.md) für die vollständige Herleitung der Dimensionierung.

### Was das in der Praxis bedeutet

Ein Qwen3-30B-A3B hat 30.5B Gesamtparameter, aber nur 3.3B aktive. Es erzeugt Tokens ungefähr mit der Geschwindigkeit eines Dense-Modells mit 3.3B — benötigt aber Speicher für alle 30.5B. Bei 4-Bit sind das etwa 18 GB, was in eine 24-GB-GPU passt. Ein Dense-Modell mit 30B bei 4-Bit bräuchte etwa denselben Speicher, würde Tokens aber langsamer erzeugen, da es pro Token alle 30B Parameter verarbeitet statt 3.3B.

Umgekehrt hat Kimi K3 2.8T Gesamtparameter und 104B aktive. Es erzeugt Tokens ungefähr mit der Geschwindigkeit eines Dense-Modells mit 104B — benötigt aber etwa 1.4 TB Speicher nur für die Gewichte bei 4-Bit. Keine Consumer- oder Prosumer-Hardware fasst das.

## MoE im Vergleich zu Dense-Modellen

| | Dense | MoE |
| - | - | - |
| **Parameter pro Token** | Alle Parameter | Nur aktive Parameter (ein Bruchteil der Gesamtparameter) |
| **Speicher** | Skaliert mit den Gesamtparametern | Skaliert mit den Gesamtparametern (gleiche Formel) |
| **Berechnung pro Token** | Skaliert mit den Gesamtparametern | Skaliert nur mit den aktiven Parametern |
| **Generierungsgeschwindigkeit** | Begrenzt durch die Gesamtzahl der Parameter | Begrenzt durch die Anzahl der aktiven Parameter — oft viel schneller als ein Dense-Modell gleicher Gesamtgröße |
| **Wissenskapazität** | Begrenzt durch die Gesamtparameter | Gesamtparameter können bei gleicher Berechnung pro Token viel größer sein |
| **Hardwareanforderung** | Gesamtparameter müssen passen | Gesamtparameter müssen passen (nicht aktive) |
| **Multi-GPU-Serving** | Tensor-Parallelität teilt Schichten auf | Expert-Parallelität teilt Experts über GPUs auf |

Die zentrale Erkenntnis: MoE entkoppelt die Wissenskapazität von der Berechnung pro Token. Ein MoE mit 671B Parametern und 37B aktiven kann ein Dense-Modell mit 70B qualitativ übertreffen und dabei Tokens ungefähr mit 70B-Geschwindigkeit erzeugen — benötigt aber Speicher für 671B.

## Expert-Parallelität: MoE über mehrere GPUs betreiben

Wenn ein MoE-Modell nicht auf eine einzelne GPU passt, muss es verteilt werden. **Expert-Parallelität** ist die MoE-spezifische Strategie dafür:

* Jede GPU hält eine Teilmenge der gesamten Experts. Bei einem Modell mit 256 Experts auf 8 GPUs hält jede GPU 32 Experts.
* Während des Forward-Passes bestimmen die Entscheidungen des Routers, welche Tokens an welche GPU gesendet werden müssen. Tokens, die zu Experts auf GPU 3 geroutet werden, werden zur Verarbeitung an GPU 3 kommuniziert, dann kommen die Ergebnisse zurück.
* Nicht-Expert-Schichten (Attention, Embeddings) werden typischerweise mit Standard-**Tensor-Parallelität** aufgeteilt, wobei jede GPU einen Slice der Gewichtsmatrizen jeder Schicht hält.

Produktions-Serving-Runtimes wie vLLM und TensorRT-LLM kombinieren Tensor-Parallelität für Attention-Schichten mit Expert-Parallelität für MoE-Schichten. Das Ergebnis heißt **Mixed Parallelism**. Die vLLM-Dokumentation behandelt die Konfiguration im Detail; die zentrale Einstellung ist, dass Expert-Parallelität eine eigene Parallelitätsachse neben der Tensor-Parallelität ist.

Die praktische Konsequenz: MoE-Modelle profitieren von Bandbreiten-starken Verbindungen zwischen GPUs (NVLink, InfiniBand), da Tokens während des Routing-Schritts zwischen GPUs bewegt werden müssen. Ein nur über PCIe verbundener Cluster erleidet erhebliche Geschwindigkeitseinbußen durch die Cross-GPU-Kommunikation.

## Welche Open-Weight-Modelle MoE verwenden

Die aktuelle Generation offener Frontier-Modelle hat sich stark in Richtung MoE bewegt. Hier ist der Stand Oktober 2026:

### Unter 50B gesamt (auf 1-2 Consumer-GPUs bei 4-Bit lauffähig)

| Modell | Gesamt | Aktiv | Experts | Aktiv pro Token | Lizenz |
| - | - | - | - | - | - |
| 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 gesamt (Multi-GPU oder Systeme mit großem Unified Memory)

| Modell | Gesamt | Aktiv | Experts | Aktiv pro Token | Lizenz |
| - | - | - | - | - | - |
| gpt-oss-120b | 117B | 5.1B | 128 | 4 | Apache 2.0 |
| Qwen3-235B-A22B | 235B | 22B | 128 | 8 | Apache 2.0 |

### Über 250B gesamt (Serverklasse-Hardware erforderlich)

| Modell | Gesamt | Aktiv | Experts | Aktiv pro Token | Lizenz |
| - | - | - | - | - | - |
| DeepSeek-V3 / R1 | 671B | 37B | 256 | 8 | MIT (V3), custom (R1) |
| GLM-5.3 | 753B | \~40B | MoE | MoE | Custom (siehe [GLM-5.3](/de/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 | Asymmetrisch | MIT |

Quellen: Modellkarten auf HuggingFace und die offiziellen technischen Berichte, die unten verlinkt sind.

## Praktische Erkenntnis für lokale Inferenz

MoE verändert die Bedeutung der Zahlen auf einer Modellkarte:

* **Aktive Parameter** sagen aus, wie schnell das Modell Tokens erzeugt. Ein MoE mit 671B und 37B aktiven erzeugt mit ungefähr 37B-Geschwindigkeit.
* **Gesamtparameter** sagen aus, wie viel Speicher das Modell benötigt. Dasselbe MoE mit 671B benötigt 671B an VRAM, nicht 37B.
* **Expert-Anzahl und Routing** sind Architekturdetails, die Qualität und Trainingseffizienz beeinflussen, aber als Benutzer lokaler Inferenz konfiguriert man sie nicht — man konfiguriert Speicher und Parallelität.

Wenn ein MoE-Modell als "2.4T Parameter, 95B aktiv" beworben wird, liest man das als: "erzeugt mit 95B-Geschwindigkeit, benötigt 2.4T Speicher." Die Hardware nach den Gesamtparametern dimensionieren, die Geschwindigkeit der aktiven Anzahl genießen.

Den [GPU model-fit guide](/de/guides/model-fit.md) verwenden, um zu prüfen, ob ein bestimmtes MoE-Modell und eine Quantisierung auf die Hardware passen, bevor man es herunterlädt.

## Tiefer einsteigen

> **[Memory and offloading](/de/concepts/memory-and-offloading.md)**
>
> Die vollständige Dimensionierungsformel, einschließlich Bytes pro Parameter nach Präzision und den Offloading-Mechaniken.

> **[Quantization](/de/concepts/quantization.md)**
>
> Bytes pro Parameter reduzieren, um die Speicher-Gleichung für MoE- und Dense-Modelle gleichermaßen zu verändern.

> **[How inference works](/de/concepts/how-inference-works.md)**
>
> Warum Decode speicherbandbreitengebunden ist und wie aktive Parameter die Generierungsgeschwindigkeit beeinflussen.

> **[Model serving and scaling](/de/concepts/model-serving-and-scaling.md)**
>
> Parallelitätsstrategien, Multi-GPU-Serving und wie Runtimes Modelle verteilen.

## Modelle mit MoE

> **[Kimi K3](/de/models/kimi-k3.md)**
>
> 2.8T gesamt, 104B aktiv, 896 Experts mit Stable LatentMoE-Routing.

> **[DeepSeek](/de/models/deepseek.md)**
>
> V3/R1 bei 671B/37B, V4.1-Flash bei 552B mit asymmetrischer 8B/16B-Aktivierung.

> **[Qwen3](/models/qwen3)**
>
> 30B-A3B und 235B-A22B MoE-Stufen, 128 Experts mit Top-8-Routing.

> **[Qwen3.8](/de/models/qwen3.8.md)**
>
> 2.4T-Flagship mit 95B aktiv, 512 Experts, 10 geroutete + 1 Shared.

> **[GLM-5.3](/de/models/glm-5.3.md)**
>
> 753B gesamt, \~40B aktiv, MoE mit 1M Kontext.

> **[gpt-oss](/models/gpt-oss)**
>
> 20b (32 Experts) und 120b (128 Experts), Top-4-Routing, Apache 2.0.

## Sobald es läuft

Ein MoE-Modell auf der eigenen Hardware zum Laufen zu bringen ist der erste Schritt. Sobald es Anfragen auf `localhost` beantwortet, ist der nächste Schritt, es von überall erreichbar zu machen.

> **[Give it a stable endpoint](/de/quickstart.md)**
>
> Tokios wählt, hostet oder feinabstimmt das Modell nicht — sobald es lokal läuft, macht Tokios daraus einen stabilen, authentifizierten Endpunkt, den man von überall aufrufen kann.

## Häufig gestellte Fragen

> **Why does an MoE model need memory for all experts if only a few are active?**
>
> Der Router wählt für jedes Token unterschiedliche Experts aus, daher muss jeder Expert erreichbar sein. In jedem Moment feuern nur k Experts, aber das nächste Token könnte ein völlig anderes Set benötigen. Das bedeutet, dass alle Expert-Gewichte jederzeit im Speicher (VRAM oder RAM) resident bleiben müssen — man dimensioniert nach Gesamtparametern, nicht nach aktiven Parametern.

> **How do I know if my hardware can run an MoE model?**
>
> Berechnen: Gesamtparameter × Bytes pro Gewicht. Bei 4-Bit (dem nativen Quantisierungsboden für die meisten MoE-Modelle) sind das `total_params × 0.5 GB`. Dazu 20% für KV-Cache und Overhead. Wenn diese Zahl in den kombinierten VRAM + RAM passt, lädt das Modell. Wenn nicht, ändert keine Optimierung etwas — man benötigt mehr Speicher oder ein kleineres Modell.

> **What is the difference between shared experts and routed experts?**
>
> Shared Experts sind bei jedem Token aktiv — sie verarbeiten allgemeine Aufgaben wie Sprachmodellierung. Geroutete Experts werden pro Token vom Gating-Netzwerk ausgewählt. DeepSeek-V3 verwendet 256 geroutete Experts mit 8 aktiven und keine Shared Experts. Kimi K3 verwendet 896 Experts mit 16 gerouteten + 2 Shared. Qwen3.8 verwendet 512 Experts mit 10 gerouteten + 1 Shared.

> **Can I run an MoE model on a single GPU?**
>
> Nur die kleinen. Qwen3-30B-A3B (30.5B gesamt, \~18 GB bei 4-Bit) passt in eine 24-GB-GPU. gpt-oss-20b (21B gesamt, \~13 GB bei 4-Bit) passt ebenfalls. Alles über \~50B Gesamtparametern benötigt entweder Multi-GPU-Serving (vLLM, SGLang mit Expert-Parallelität) oder ein System mit großem Unified Memory (Mac Studio, DGX Spark) mit CPU-Offload.

> **What is expert parallelism and when do I need it?**
>
> Expert-Parallelität teilt die Expert-Schichten über mehrere GPUs auf — GPU 0 hält Experts 0-63, GPU 1 hält Experts 64-127 usw. Jede GPU berechnet die Ausgaben ihrer Experts und sie werden über All-to-All-Kommunikation zusammengeführt. Man benötigt sie, wenn die gesamten Expert-Gewichte nicht auf eine einzelne GPU passen. vLLM und SGLang unterstützen beide; siehe den [vLLM optimization guide](/de/guides/vllm-optimization.md) für die Konfiguration.

## Quellen

* [DeepSeek-V3 Technical Report](https://arxiv.org/abs/2412.19437) — 671B gesamt, 37B aktiv, 256 Experts, Auxiliary-loss-freie Lastverteilung.
* [Kimi K2: Open Agentic Intelligence](https://arxiv.org/abs/2507.20534) — 1T gesamt, 32B aktiv, 384 Experts, 8 aktiv pro Token.
* [Kimi K3 model card](https://huggingface.co/moonshotai/Kimi-K3) — 2.8T gesamt, 104B aktiv, 896 Experts, Stable LatentMoE.
* [Qwen3 Technical Report](https://arxiv.org/abs/2505.09388) — 128 Experts, 8 aktiv, keine Shared Experts im Qwen3-MoE.
* [Qwen3-Next-80B-A3B](https://qwen.ai/blog?id=4074cca80393150c248e508aa62983f9cb7d27cd) — 512 Experts, 10 geroutete + 1 Shared.
* [Qwen3.8-Max announcement](https://qwen.ai/blog?id=qwen3.8) — 2.4T gesamt, 95B aktiv, 512 Experts.
* [gpt-oss model card](https://arxiv.org/abs/2508.10925) — 32 Experts (20b) und 128 Experts (120b), 4 aktiv pro Token.
* [GLM-5.3 model card](https://huggingface.co/zai-org/GLM-5.3) — 753B gesamt, \~40B aktiv.
* [Mixture of Experts Explained (localaimaster.com)](https://localaimaster.com/blog/mixture-of-experts-explained) — Routing-Mechaniken und Speicherauswirkungen.
* [Mixture-of-Experts LLMs (Cameron R. Wolfe)](https://cameronrwolfe.substack.com/p/moe-llms) — Top-k-Gating-Formulierung und Training-Dynamik.
* [MoE training in Qwen3-235B and Kimi-K2](https://medium.com/clickbait-programming/moe-training-in-qwen3-235b-a22b-and-kimi-k2-c51f582d2ef5) — Vergleich gelernter Routing-Mechanismen.
* [vLLM MoE Playbook](https://rocm.blogs.amd.com/software-tools-optimization/vllm-moe-guide/README.html) — Expert-Parallelität und Mixed-Parallelism-Konfiguration.
* [Expert Parallelism in TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/advanced/expert-parallelism.html) — Multi-GPU-Expert-Verteilungsstrategien.


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