Mixture-of-Experts ist die Architektur hinter den größten produktiven LLMs – und sie funktioniert anders, als die meisten denken

Als OpenAI GPT-4 auslieferte, weigerte sich das Unternehmen, eine Parameteranzahl zu veröffentlichen. Monate später deuteten durchgesickerte Dokumente und bestätigende Benchmarks darauf hin, dass es eine Mixture-of-Experts (MoE)-Architektur mit rund 1,8 Billionen Gesamtparametern verwendet, verteilt auf acht Experten-Subnetzwerke – aber nur etwa 220 Milliarden pro Forward Pass aktiviert. Diese einzelne Designentscheidung erklärt sowohl die Leistungsgrenze des Modells als auch seine Inferenzökonomie auf eine Weise, die eine naive Parameterzahl nie könnte.

MoE ist heute die dominierende Architektur für Frontier-Modelle. Googles Gemini 1.5 nutzt MoE. Mistral AIs offene Modelle Mixtral 8x7B und 8x22B haben MoE für Selbst-Hoster zugänglich gemacht. Metas interne Forschung zu MoE für Llama-Nachfolger ist gut dokumentiert. Zu verstehen, wie es tatsächlich funktioniert – und wo es wirklich hilft gegenüber wo es nur die Folien gut aussehen lässt – ist entscheidend, wenn Sie entscheiden, welche Modelle Sie einsetzen oder wie Sie neue Veröffentlichungen bewerten.

Die Kernidee: bedingte Berechnung

Ein standardmäßiger dichter Transformer wie Llama 2 70B aktiviert alle seine 70 Milliarden Parameter für jedes verarbeitete Token. Das ist rechenintensiv, aber vorhersagbar. MoE ersetzt die Feedforward-Schichten (die Schichten, die den Großteil der Parameter eines Transformers ausmachen) durch mehrere parallele "Expert"-Netzwerke plus einen leichten Router. Für jedes Token wählt der Router die Top-k-Experten – typischerweise 2 von 8 oder 16 – und nur diese Experten verarbeiten dieses Token. Die Ergebnisse werden gewichtet und kombiniert.

Die praktische Konsequenz: Ein Mixtral 8x7B-Modell hat rund 47 Milliarden Gesamtparameter, aber jedes Token berührt nur etwa 13 Milliarden davon. Sie erhalten den Großteil der Repräsentationskapazität eines dichten 47B-Modells, während die Inferenzkosten eher bei 13B liegen. Der Durchsatz verdoppelt sich im Vergleich zu einem äquivalenten dichten Modell auf derselben Hardware bei gleicher Ausgabequalität.

Was der Router tatsächlich lernt

Der Router ist eine kleine lineare Schicht, die eine Wahrscheinlichkeitsverteilung über alle verfügbaren Experten erzeugt. Sie wird End-to-End mit dem Rest des Modells mittels standardmäßigem Gradientenabstieg trainiert – es gibt kein separates Vortraining oder manuelle Kennzeichnung, welcher Experte welche Inhalte behandeln soll. Was entsteht, ist in etwa eine Domänenspezialisierung: Analysen der Routing-Muster von Mixtral zeigen, dass Experten weiche Präferenzen für Code-Syntax, natürliche Sprachverarbeitung, Faktenabruf usw. entwickeln. Diese Spezialisierung ist jedoch ungenau und stimmt nicht immer mit menschlichen Intuitionen über Themengebiete überein.

Ein anhaltendes ingenieurtechnisches Problem ist das Load Balancing. Ohne Eingriff neigt der Router dazu, auf eine kleine Gruppe "beliebter" Experten zu kollabieren und andere auszuhungern, was Kapazität verschwendet. Der Standardfix ist ein zusätzlicher Load-Balancing-Verlust, der während des Trainings hinzugefügt wird und ungleichmäßige Expertenauslastung bestraft. Die Stärke dieses Verlusts richtig einzustellen, ist ein Hyperparameter, der sowohl die Modellqualität als auch die Hardwareeffizienz wesentlich beeinflusst – zu wenig führt zum Expertenkollaps; zu viel verhindert eine sinnvolle Spezialisierung des Routers.

Der Speicher-Engpass, den das Marketing ignoriert

Hier wird MoE für Anwender kompliziert. Alle Parameter müssen im Speicher liegen, obwohl nur ein Bruchteil pro Token aktiviert wird. Ein Mixtral 8x22B-Modell – mit rund 141 Milliarden Gesamtparametern – benötigt in BF16-Präzision etwa 280 GB GPU-VRAM, noch bevor der KV-Cache berücksichtigt wird. Das bedeutet mindestens vier H100 80GB GPUs, nur um die Gewichte zu halten, obwohl der Inferenzdurchsatz dem eines viel kleineren dichten Modells ähnelt.

Dies schafft eine Infrastrukturspaltung. In einem Rechenzentrum, in dem Sie einen 4-GPU-Knoten pro Modellreplikat dedizieren können, ist MoE tatsächlich günstiger pro Token. In einer Bereitstellung, in der Sie mehrere Modelle auf gemeinsamer Hardware ko-lokalisieren möchten, macht der Speicherfußabdruck von MoE es teuer. Deshalb ist Quantisierung für MoE-Modelle wichtiger: Mixtral 8x7B auf 4-Bit-Präzision (etwa 25 GB) zu bringen, macht es praktikabel, auf einem einzigen Consumer-Workstation oder einem Dual-GPU-Server zu laufen.

Expert-Parallelität als Skalierungshebel

Für das Training sehr großer MoE-Modelle verteilt eine Technik namens Expert Parallelism verschiedene Experten auf verschiedene physikalische GPUs. Wenn ein Token an Expert #5 weitergeleitet wird, erfolgt die Berechnung auf der GPU, die die Gewichte von Expert #5 hält, und das Ergebnis wird zurückgesendet. Dies verwandelt All-Reduce-Kommunikation in lokalisiertere Point-to-Point-Übertragungen und ermöglicht Training in Größenordnungen, die sonst zu viel Speicher pro GPU erfordern würden.

Googles Switch Transformer Paper von 2021 demonstrierte dies bei 1,6 Billionen Parametern – das erste öffentlich dokumentierte Billionen-Parameter-Modell. Die wichtigste Erkenntnis: Ein 64-Experten-MoE mit dem gleichen Rechenbudget wie ein dichtes T5-XXL-Modell erreichte eine 4-fache Beschleunigung der Trainingszeit bei gleichbleibender oder besserer Qualität in Standard-Benchmarks. Das Paper dokumentierte auch Fehlermodi: Trainingsinstabilität bei hohen Expertenzahlen, das Load-Balancing-Kollapsproblem und Kommunikations-Overhead in Multi-Node-Setups.

Wo MoE dichten Modellen wirklich unterlegen ist

Few-Shot-Learning bei hochspezifischen Domänenaufgaben ist ein Bereich, in dem MoE-Modelle im Vergleich zu gleich großen dichten Modellen schlechter abschneiden können. Da der Router Tokens probabilistisch zuweist und verschiedene Tokens im selben Prompt an verschiedene Experten gehen können, kann das "Gedächtnis" des Modells für frühen Kontext über Experten hinweg fragmentiert werden, was die Kohärenz bei langen, spezialisierten Dokumenten beeinträchtigt. Anekdotische Berichte aus Unternehmenseinsätzen von Mixtral deuten darauf hin, dass dichte Modelle mit äquivalenten Inferenzkosten manchmal bessere Ergebnisse bei juristischen oder medizinischen Texten liefern, bei denen genaue Terminologiekonsistenz wichtig ist.

Die Batch-Größe spielt ebenfalls eine Rolle. Der Durchsatzvorteil der MoE-Architektur ist am stärksten bei großen Batch-Größen ausgeprägt, bei denen alle Experten eine annähernd gleichmäßige Auslastung erhalten. Bei Batch-Größe 1 – ein einzelner Benutzer, der eine Echtzeitabfrage stellt – aktivieren Sie zwei Experten und warten untätig auf die anderen sechs. Die Latenz pro Token kann aufgrund des Routing-Overheads tatsächlich schlechter sein als bei einem dichten Modell mit äquivalenter aktivierter Parameterzahl. Deshalb bündeln Produktionsumgebungen Anfragen aggressiv und warum Streaming-API-Endpunkte andere Latenzprofile haben als Batch-Inferenz-Endpunkte.

Praktische Entscheidungen für Teams, die MoE-Modelle evaluieren

Wenn Sie ein dichtes 70B-Modell mit einem MoE-Modell wie Mixtral 8x22B für die Bereitstellung vergleichen, ist der richtige Vergleich nicht die Parameterzahl – sondern Speicherfußabdruck gegen Qualität für Ihre spezifische Arbeitslast. Testen Sie beide auf Ihrer tatsächlichen Aufgabenverteilung. Mixtral 8x22B wird Llama 2 70B in Reasoning-Benchmarks konsequent schlagen, aber die Lücke schließt sich deutlich bei schmalen Retrieval-Augmented-Generation-Aufgaben, bei denen der Datensatz homogen ist.

Für Fine-tuning stellen MoE-Modelle eine besondere Herausforderung dar: LoRA-Fine-tuning, das nur auf dichte Schichten angewendet wird, berührt nicht die Expert-Gewichte, die den Großteil des spezialisierten Wissens des Modells enthalten. Vollständiges Fine-tuning von MoE-Modellen ist speicherintensiv. MoE-spezifische LoRA-Varianten, die Adapter auf Expert-Feedforward-Schichten anwenden, existieren, sind aber noch nicht Standard-Tooling – überprüfen Sie, ob Ihr Fine-tuning-Framework diese unterstützt, bevor Sie sich festlegen.

Die Router-Gewichte selbst können während des Fine-tunings eingefroren werden, um die während des Vortrainings gelernten Spezialisierungsmuster zu erhalten. Dies funktioniert gut, wenn Sie für eine Aufgabe fine-tunen, die in der ursprünglichen Trainingsverteilung gut repräsentiert ist. Bei der Anpassung an eine wirklich neue Domäne lohnt es sich, den Router aufzutauen und den längeren Fine-tuning-Durchlauf in Kauf zu nehmen.

Was als Nächstes kommt

Forschungsrichtungen, die aktiv erforscht werden, umfassen sparsames MoE mit mehr als zwei aktivierten Experten pro Token (Kompromiss zwischen Rechenleistung und Qualität), hierarchisches Routing, bei dem ein grober Router Experten-"Familien" auswählt, bevor ein feinkörniger Router spezifische Experten auswählt, und Mixture-of-Depths-Architekturen, die Tokens zu verschiedenen Schichten statt zu verschiedenen Experten innerhalb einer Schicht leiten. Das Paper von Google DeepMind von 2024 zu Mixture-of-Depths zeigte, dass nicht jedes Token jede Transformer-Schicht durchlaufen muss, was weitere Gewinne durch bedingte Berechnung ermöglicht.

Die architektonische Lehre aus MoE ist konsistent: Skalierungsgesetze belohnen bedingte Berechnung. Die gesamte Rechenleistung für jedes Token und jede Aufgabe auszugeben, ist Verschwendung. Die Modelle, die in den nächsten zwei Jahren relevant sein werden, werden zunehmend hybride Systeme sein, die Arbeit intelligent lenken – sei es durch Routing zu Experten innerhalb eines Modells, durch Orchestrierung zu verschiedenen Modellen oder durch Routing zu externen Tools. MoE ist die erste Produktionsskala-Demonstration, dass dieses Prinzip auf Gewichtsebene funktioniert.