Zum Hauptinhalt springen
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.
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 für die Gesamtparameter gilt, nicht für die aktiven:
Aktive Parameter beeinflussen nur die Berechnung pro Token (und damit die Generierungsgeschwindigkeit), nicht den Speicher.

​
Durchgerechnete Beispiele

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

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)

​
50B-250B gesamt (Multi-GPU oder Systeme mit großem Unified Memory)

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

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

Die vollständige Dimensionierungsformel, einschließlich Bytes pro Parameter nach Präzision und den Offloading-Mechaniken.

Quantization

Bytes pro Parameter reduzieren, um die Speicher-Gleichung für MoE- und Dense-Modelle gleichermaßen zu verändern.

How inference works

Warum Decode speicherbandbreitengebunden ist und wie aktive Parameter die Generierungsgeschwindigkeit beeinflussen.

Model serving and scaling

Parallelitätsstrategien, Multi-GPU-Serving und wie Runtimes Modelle verteilen.

​
Modelle mit MoE

Kimi K3

2.8T gesamt, 104B aktiv, 896 Experts mit Stable LatentMoE-Routing.

DeepSeek

V3/R1 bei 671B/37B, V4.1-Flash bei 552B mit asymmetrischer 8B/16B-Aktivierung.

Qwen3

30B-A3B und 235B-A22B MoE-Stufen, 128 Experts mit Top-8-Routing.

Qwen3.8

2.4T-Flagship mit 95B aktiv, 512 Experts, 10 geroutete + 1 Shared.

GLM-5.3

753B gesamt, ~40B aktiv, MoE mit 1M Kontext.

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

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

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.
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.
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.
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.
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 für die Konfiguration.

​
Quellen