Mixture of Experts

Mixture of Experts (MoE, auf Deutsch „Mischung von Experten") ist ein Bauplan für KI-Sprachmodelle, in dem statt eines einzigen großen Netzes viele kleinere spezialisierte Teil-Netze (die Experten) nebeneinander existieren. Ein Router (Verteiler) entscheidet für jedes Wortstück der Eingabe, welche wenigen Experten überhaupt rechnen; die übrigen bleiben still. Das Modell wird dadurch insgesamt sehr groß, verbraucht bei jeder Antwort aber nur einen Bruchteil der Rechenleistung eines gleich großen Modells, in dem immer alle Teile mitrechnen.

Was ist Mixture of Experts?

Die Grundidee ist alt: Statt ein einziges Netz alles lernen zu lassen, teilen sich mehrere Teil-Netze die Arbeit, und eine Zuteilungs-Logik entscheidet, wer gerade zuständig ist. Jacobs, Jordan, Nowlan und Hinton beschrieben dieses Muster 1991 in „Adaptive Mixtures of Local Experts". Für heutige große Sprachmodelle (LLMs) wurde die Idee erst 15 Jahre später wieder relevant, mit dem [„Outrageously Large Neural Networks"-Paper](https://arxiv.org/abs/1701.06538) von Shazeer et al. (Google, 2017), das erstmals viele Experten mit einem lernenden Verteiler in ein Sprachmodell einbaute, und dem [Switch Transformer](https://arxiv.org/abs/2101.03961) von Fedus et al. (Google, 2021), der diesen Bauplan auf Modelle mit über einer Billion Parametern (Stellschrauben des Netzes) hochskalierte.

In einem MoE-Transformer wird die klassische Feed-Forward-Schicht (FFN) jedes Layers durch mehrere parallele FFN-Experten ersetzt. Ein Router (Gating-Netzwerk) berechnet für jedes Token Scores und leitet es an die Top-k Experten, deren gewichtete Ausgabe die Layer-Berechnung ergibt. Typisch sind k=1 (Switch Transformer), k=2 (Mixtral) oder k=4 (DBRX). Nur die ausgewählten Experten rechnen, alle übrigen bleiben inaktiv. Bei 16 Experten und k=4 werden pro Token 25 Prozent der Experten-Parameter aktiviert, bei 8 Experten und k=2 ebenfalls 25 Prozent. Die Sparsity ist konfigurierbar und variiert je Modell.

Der Grund für den Aufwand ist ein Skalierungsvorteil: Modellkapazität, gemessen an der Gesamtparameterzahl, lässt sich stark erhöhen, ohne dass die Inferenz-Kosten linear mitsteigen. Ein 132-Milliarden-MoE-Modell wie DBRX hat pro Token nur rund 36 Milliarden aktive Parameter. Der Rechenaufwand pro Token liegt damit näher an einem 36-Milliarden-Dense-Modell, während die repräsentative Kapazität näher an einem 132-Milliarden-Dense-Modell liegt. Die Kosten dieser Architektur sind ebenfalls konkret: Load-Balancing zwischen Experten wird über einen zusätzlichen Auxiliary Loss erzwungen, damit nicht wenige Experten alle Tokens ziehen; der VRAM-Bedarf bleibt hoch, weil alle Experten geladen sein müssen, auch wenn nur ein Teil rechnet; die verteilte Inferenz erfordert Expert Parallelism über mehrere GPUs. Zu den bekannten produktiven Umsetzungen zählen Mixtral 8x7B und 8x22B (Mistral AI, Apache 2.0), DBRX (Databricks, 132 B / 36 B aktiv), DeepSeek-V2 (236 B / 21 B aktiv) und DeepSeek-V3 (671 B / 37 B aktiv).

Abgrenzung zu Dense Transformer, Ensemble Methods und Model Routing

Der Begriff Mixture of Experts wird häufig mit dichten Transformern, klassischen Ensemble-Verfahren und der Anfrage-Verteilung zwischen mehreren LLMs verwechselt.

Gegen den dichten Transformer ist der Unterschied die Sparsity. In einem Dense-Modell durchläuft jedes Token die vollen Parameter jeder Schicht; Trainings- und Inferenz-Kosten skalieren linear mit der Parameterzahl. In einem MoE-Modell skalieren sie nur mit den aktiven Parametern, während die Gesamtparameter-Zahl die repräsentative Kapazität bestimmt.

Gegen klassische Ensembles ist der Unterschied Trainings- und Aktivierungs-Modus. Ein Ensemble kombiniert die Ausgaben mehrerer unabhängig trainierter Modelle durch Voting oder Averaging, und alle Modelle rechnen bei jeder Vorhersage. Ein MoE-Modell trainiert die Experten gemeinsam in einem Netz und aktiviert pro Eingabe nur eine Auswahl. Wikipedia ordnet MoE historisch als „Form des Ensemble-Lernens" ein, das trifft aber nur den konzeptionellen Ursprung; die produktive Umsetzung in modernen LLMs unterscheidet sich in Struktur und Aktivierungs-Ökonomie deutlich.

Gegen Model Routing (auch LLM-Router genannt, etwa RouteLLM oder ein Mosaic-AI-Model-Router) ist der Unterschied die Granularität. Model Routing verteilt ganze Anfragen zwischen mehreren eigenständigen LLMs, um etwa einfache Prompts an ein kleineres Modell und komplexe Prompts an ein größeres Modell zu leiten. Diese Entscheidung fällt außerhalb der Modelle, auf Request-Ebene. Das MoE-Routing findet innerhalb eines einzelnen Modells statt, auf Token-Ebene und pro Layer, ohne dass die aufrufende Anwendung davon etwas mitbekommt.

Beispiel: MoE-LLM im produktiven Betrieb

Ein typisches Betriebsszenario zeigt, wo die MoE-Architektur ihren Vorteil ausspielt. In einer produktiven RAG-Anwendung, die als Antwort-Generator ein offenes MoE-Modell wie DBRX Instruct oder Mixtral 8x22B verwendet, spart die Sparsity Compute pro Token gegenüber einem gleich großen dichten Modell. Bei DBRX werden pro Token 36 Milliarden der 132 Milliarden Parameter aktiviert; der Rechenaufwand entspricht damit näherungsweise einem 36-B-Dense-Modell, während die Antwortqualität in Benchmarks wie MMLU oder HumanEval näher an dichten Modellen der 70-B- bis 100-B-Klasse liegt.

Der Preis für diese Ökonomie ist der VRAM-Bedarf. Auch inaktive Experten müssen im Speicher gehalten werden, damit das Routing sie pro Token wählen kann. Ein DBRX-Deployment braucht daher deutlich mehr GPU-VRAM als ein 36-B-Dense-Modell (grob im Bereich eines 132-B-Dense-Modells), weil die vollen Gewichte residieren. Für die Bereitstellung eignen sich zwei Wege: Foundation Model APIs mit Pay-per-Token-Abrechnung, bei denen der Anbieter das Load-Balancing und Expert-Parallelism-Setup verantwortet, oder ein dediziertes Model Serving mit Expert Parallelism über mehrere GPUs, wenn Anfrage-Volumen und Isolations-Anforderungen das rechtfertigen.