Effizienzsteigerung durch Mixture of Experts in Transformer-Architekturen

Mixture of Experts (MoEs) in Transformer-Modellen: Eine Analyse der Effizienz und Skalierbarkeit

Die Entwicklung von Large Language Models (LLMs) war in den letzten Jahren maßgeblich von der Skalierung dichter Modelle geprägt. Konzepte wie "mehr Daten und mehr Parameter führen zu besserer Leistung" haben die Fortschritte vorangetrieben, von frühen Modellen mit Millionen von Parametern bis hin zu heutigen Systemen mit Hunderten von Milliarden Parametern. Die sogenannten Skalierungsgesetze haben diesen Trend bestätigt, doch stoßen dichte Skalierungsansätze zunehmend an praktische Grenzen. Diese Grenzen manifestieren sich in:

• Steigenden Trainingskosten.
• Längeren Inferenzlatenzen.
• Hohen Anforderungen an Speicher und Hardware für den Einsatz.

An diesem Punkt treten Mixture of Experts (MoE) Architekturen in den Vordergrund, um diese Herausforderungen zu adressieren.

Von dichten zu spärlichen Architekturen: Was sind MoEs?

Ein MoE-Modell behält das grundlegende Transformer-Gerüst bei, ersetzt jedoch bestimmte dichte Feed-Forward-Schichten durch eine Ansammlung von Experten. Ein "Experte" ist hierbei kein thematisch spezialisiertes Modul (z.B. ein "Mathematik-Experte" oder "Code-Experte"), sondern schlicht ein trainierbares Sub-Netzwerk. Für jedes Token wählt ein Router eine kleine Untergruppe von Experten aus, die dieses Token verarbeiten sollen.

Unterschiedliche Token aktivieren demnach basierend auf ihren verborgenen Repräsentationen unterschiedliche Experten. Das zentrale Konzept ist hierbei, dass die Modellkapazität von der Gesamtzahl der Parameter abhängt, die Inferenzgeschwindigkeit jedoch von der Anzahl der aktiv genutzten Parameter. Nehmen wir beispielsweise das Modell `gpt-oss-20b`. Es verfügt über 21 Milliarden Gesamtparameter, nutzt aber pro Token 4 aktive Experten aus insgesamt 32. Berücksichtigt man die gemeinsam genutzten Komponenten und die aktiven Experten, verwendet dieses Modell etwa 3,6 Milliarden aktive Parameter pro Token. Wird dieses Modell auf einem M3 Ultra Mac mit einer Speicherbandbreite von ca. 800 GB betrieben, lässt sich die Generierungsgeschwindigkeit in `bfloat16` auf etwa 111 Token pro Sekunde schätzen, wobei jeder Parameter 2 Byte beansprucht. Die tatsächlich erreichte Leistung von etwa 115 Token pro Sekunde liegt sehr nahe an dieser Schätzung. Diese hohe Geschwindigkeit bestätigt, dass das Modell annähernd wie ein 3,6 Milliarden Parameter großes Modell arbeitet, jedoch die Kapazität (oder Qualität) eines 21 Milliarden Parameter großen Modells besitzt.

MoEs sind aus mehreren Gründen attraktiv:

1. Bessere Recheneffizienz: Bei einem festen Trainings-FLOP-Budget übertreffen MoEs oft ihre dichten Pendants. Dies bedeutet schnellere Iterationen und eine effizientere Skalierung.
2. Eine natürliche Parallelisierungsachse: Experten bieten eine strukturelle Grenze im Rechengraph. Da verschiedene Token unterschiedliche Experten beanspruchen, kann die Verarbeitung über Experten hinweg parallelisiert werden.
3. Branchenakzeptanz: Jüngste Veröffentlichungen großer MoE-Modelle, wie Qwen 3.5, MiniMax M2, GLM-5 oder Kimi K2.5, unterstreichen diesen Trend. Der Erfolg von DeepSeek R1 im Januar 2025, aufbauend auf früheren Systemen wie DeepSeek V2, und Mixtral-8x7B im Dezember 2023 haben die Akzeptanz beschleunigt. Auch geschlossene Forschungslabore nutzen MoEs; ChatGPT soll Gerüchten zufolge eine spärliche Architektur verwenden, und die offenen gpt-oss Modelle tun dies definitiv.

MoEs und Transformer: Technische Integration in `transformers`

Die meisten Tools im Ökosystem, einschließlich des Ladens von Modellen, der Geräteplatzierung, der Quantisierung und der Backend-Ausführung, wurden ursprünglich für dichte Modelle konzipiert. MoEs stellen diese Annahmen in Frage. Die Integration von MoEs als "First-Class Citizens" in `transformers` bedeutet eine Neugestaltung von Teilen der Lade-Pipeline, des Ausführungsmodells und der verteilten Abstraktionen, über die bloße Hinzufügung neuer Modellklassen hinaus.

Im Folgenden wird erläutert, wie sich die `transformers`-Bibliothek entwickelt hat, um spärliche Architekturen in den Bereichen Gewichts-Laden, Expert-Backend und Expert-Parallelisierung zu unterstützen.

Refactoring des Gewichts-Ladens

Die Funktion `AutoModelForCausalLM.from_pretrained("model_id")` lädt Modellgewichte in ein PyTorch-Modell. Bei dichten Modellen ist dieser Vorgang relativ einfach, da jeder Tensor im Checkpoint eins zu eins einem Parameter im Laufzeitmodul entspricht. Bei MoEs ist dies komplexer. In den meisten MoE-Checkpoints wird jeder Experte unabhängig serialisiert. Ein Blick in den DeepSeek-V3 Checkpoint-Index zeigt Schlüssel wie `model.layers.3.mlp.experts.0.gate_proj.weight` bis `model.layers.3.mlp.experts.255.gate_proj.weight`. Jeder Experte besitzt eigene Gewichtungsmatrizen, effektiv 256 kleine Feed-Forward-Netzwerke, die Seite an Seite gespeichert sind. Zur Laufzeit benötigen GPUs jedoch optimierte Kernel, die alle Experten in einer einzigen Operation verarbeiten, anstatt sie einzeln zu durchlaufen. Dies erfordert, dass die Expertengewichte in einem einzigen, zusammenhängenden Tensor verpackt sind. Daraus ergibt sich eine Diskrepanz zwischen dem Checkpoint (256 separate Tensoren) und der Laufzeit (1 gepackter Tensor). Die systematische Überbrückung dieser Lücke wird durch das Refactoring des Gewichts-Ladens ermöglicht.

Mit der Einführung eines generischen WeightConverter hat sich das Verständnis von einem Checkpoint, der dem Laufzeit-Layout entspricht, zu einem Checkpoint als serialisierte Quelle von Tensoren entwickelt, die durch eine Konvertierungspipeline in das gewünschte Laufzeit-Layout transformiert werden.

Dynamisches Gewichts-Laden mit `WeightConverter`

Die zentrale Abstraktion dieses Refactorings ist das dynamische Gewichts-Laden über einen `WeightConverter`. Dieser allows die Definition von:

Quellschlüsselmuster → Zielschlüssel(e) + Operationen

Primitive Operationen (Chunk, Concatenate etc.) sind komponierbar. Zwei besonders nützliche für MoEs sind:

• `MergeModulelist` führt eine Liste von Tensoren zu einem einzigen Tensor zusammen.
• `SplitModulelist` teilt einen Tensor wieder in eine Liste von Tensoren auf.

Der Ladevorgang scannt Checkpoint-Schlüssel einmal, gleicht sie mit Konverter-Mustern ab und gruppiert Tensoren pro Konverter. Sobald ein Schlüssel als benötigt identifiziert wird, wird er als "Future" registriert und über einen Thread-Pool materialisiert. Konvertierungsoperationen werden erst ausgeführt, wenn ihre Abhängigkeiten bereit sind. Dies vermeidet wiederholte Scans und reduziert Speicherpeaks.

Die Benchmarks zeigen eine signifikante Beschleunigung des Ladevorgangs von großen MoE-Modellen. Die Kombination aus Single-Pass-Routing, asynchroner Materialisierung und konvertierungsbewusster Planung vermeidet unnötige Materialisierung und Speicherpeaks, während sie das Packen von Experten und die Projektionsfusion zur Ladezeit ermöglicht. Dieses Refactoring ermöglicht auch die Integration der Quantisierung in die Gewichts-Lade-Pipeline, da die Quantisierung "pro Experte" erst sinnvoll ist, wenn die Experten in einem vorhersagbaren, gepackten Layout vorliegen.

Expert Backend

Sind die Experten in einem einzigen Laufzeit-Tensor gepackt, stellt sich die Frage, wie effizient durch sie geroutet werden kann. In einem MoE-Modell wird jedes Token an unterschiedliche Experten weitergeleitet. Die Laufzeit muss Tokens an die ausgewählten Expertengewichte senden, die Projektionen effizient ausführen, die Routing-Gewichte anwenden und dann die Ergebnisse sammeln und neu ordnen. Dies adressiert das Expert Backend System (eingeführt in PR #42697).

Das Expert Backend führt eine steckbare Ausführungsarchitektur ein, die die Expertenberechnung von der Modellimplementierung entkoppelt. Anstatt eine Dispatch-Strategie in jedem MoE-Modell fest zu kodieren, ermöglicht das System Expertenschichten, dynamisch ein Backend zur Laufzeit auszuwählen. Dies wird durch ein Decorator-Muster implementiert (@use_experts_implementation), das Expert-Klassen umschließt und die Berechnung automatisch an das ausgewählte Backend sendet.

Aktuell sind drei Backends verfügbar:

• `eager`: Durchläuft die ausgewählten Experten und wendet Projektionen pro Experte an. Dient als Referenz für Korrektheit und Debugging.
• `batched_mm`: Verwendet die `torch.bmm` API. Dupliziert ausgewählte Expertengewichte pro Token und führt eine einzige Batched GEMM aus. Gut geeignet für kleine Batches und GPU-intensive Workloads mit ausreichend Speicher.
• `grouped_mm`: Verwendet die `torch._grouped_mm` API. Sortiert Tokens nach Expert-ID, gruppiert sie und führt eine einzige Grouped GEMM aus. Ideal für große Batches oder speicherbeschränkte Setups.

Expert Parallelisierung

Mixture of Experts (MoE) Modelle können Hunderte von Milliarden Parametern umfassen, weit mehr als auf eine einzelne GPU passen. Die Expert Parallelisierung (EP) löst dieses Problem, indem sie Experten auf mehrere Geräte verteilt. Jedes Gerät lädt nur seine zugewiesene Untergruppe von Experten, führt Berechnungen für diese Experten durch und beteiligt sich dann an der Aggregation der Ergebnisse. Dieser Ansatz skaliert Modelle auf weitaus größere Parameterzahlen, ohne die Rechenkosten zu erhöhen, da jedes Token nur wenige Experten aktiviert.

Expert Parallelisierung wird über `enable_expert_parallel` aktiviert:

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from transformers.distributed.configuration_utils import DistributedConfig

distributed_config = DistributedConfig(enable_expert_parallel=True)

model = AutoModelForCausalLM.from_pretrained(
    "openai/gpt-oss-120b",
    dtype="auto",
    distributed_config=distributed_config,
)

Der Start erfolgt mit:

torchrun --nproc-per-node N script.py

Dabei teilt `N` die Gesamtzahl der Experten gleichmäßig und entspricht möglicherweise der Anzahl der GPUs in Ihrem Knoten.

Wenn `enable_expert_parallel=True` gesetzt ist, wechselt das Modell vom standardmäßigen Tensor-Parallel-Plan (TP) zu einem Expert-Parallel-Plan (EP) mit spezialisierten Sharding-Strategien. Kernkomponenten von EP sind:

1. `GroupedGemmParallel`: Teilt die Expertengewichte entlang der Expertendimension (`dim=0`). Jedes Gerät lädt hierbei nur `num_experts / num_devices`.
2. `RouterParallel`: Bildet globale Expertenindizes auf lokale Indizes ab, maskiert Experten, die dem aktuellen Rang nicht zugewiesen sind, stellt sicher, dass jedes Gerät nur mit seinen lokalen Experten rechnet und verwendet einen All-Reduce, um Teilergebnisse über Geräte hinweg zu kombinieren.

Training von MoEs mit Transformers

MoEs sind hervorragend für die Skalierung der Inferenz geeignet, ihr Training ist jedoch erheblich komplexer. Dies liegt an der enormen Parameteranzahl, der komplizierten Kommunikation zwischen verteilten Experten und den Instabilitäten beim Routing. Um diese Herausforderungen zu bewältigen, wurde in Zusammenarbeit mit Unsloth eine deutlich schnellere MoE-Trainingslösung entwickelt, die:

• Etwa 12-mal schnelleres MoE-Training ermöglicht.
• Eine VRAM-Reduktion von über 35% erreicht.
• Einen etwa 6-mal längeren Kontext unterstützt.
• Eine 12- bis 30-fache Gesamtbeschleunigung im Vergleich zu v4 bietet.

Diese Optimierungen nutzen die Abstraktion des Expert Backends, standardisieren die `torch._grouped_mm` API von PyTorch und verwenden benutzerdefinierte Triton Grouped-GEMM + LoRA-Kernel. Unsloth baut auf den Optimierungen von Transformers (und TRL) auf, um die Leistung weiter zu steigern.

Fazit und Ausblick

Während spärliche Architekturen sich weiterentwickeln, ist es das Ziel, dass die `transformers`-Bibliothek diese Entwicklung begleitet. Die Integration von Mixture of Experts in die `transformers`-Bibliothek stellt einen bedeutenden Schritt dar, um die Grenzen der Skalierbarkeit von großen Sprachmodellen zu erweitern. Durch innovative Ansätze beim Laden von Gewichten, der Gestaltung des Expert-Backends und der Expert-Parallelisierung werden sowohl die Effizienz der Inferenz als auch die Trainingsgeschwindigkeit erheblich verbessert. Diese Entwicklungen tragen dazu bei, die praktische Anwendbarkeit von extrem großen Modellen zu erleichtern und neue Möglichkeiten für zukünftige KI-Anwendungen zu eröffnen.

Die fortlaufende Forschung und Entwicklung in diesem Bereich, insbesondere im Hinblick auf die Stabilität des Trainings und die weitere Optimierung der Hardware-Nutzung, wird entscheidend sein, um das volle Potenzial von MoE-Architekturen auszuschöpfen. Die Zusammenarbeit zwischen Forschungsgemeinschaften und Entwicklern von Frameworks wie `transformers` ist dabei unerlässlich, um diese komplexen Systeme zugänglich und leistungsfähig zu gestalten.

Bibliographie

1. Tam, Adrian. "Mixture of Experts Architecture in Transformer Models." MachineLearningMastery.com, 28. November 2025.
2. Hugging Face. "Mixture of Experts Explained." Hugging Face Blog, 11. Dezember 2023.
3. Xiao, Baicen. "Hands-on: Mixture of Experts with Transformers." Medium, 25. Februar 2024.
4. "Transformer vs. Mixture of Experts in LLMs." Daily Dose of DS, 27. Februar 2025.
5. Kranen, Kyle, und Nguyen, Vinh. "Applying Mixture of Experts in LLM Architectures." NVIDIA Developer Blog, 14. März 2024.
6. "How do mixture-of-experts layers affect transformer models?" Stack Overflow Blog, 4. April 2024.
7. Wolfe, Cameron R. "Mixture-of-Experts (MoE): The Birth and Rise of Conditional Computation." Deep (Learning) Focus, Substack, 18. März 2024.
8. Csordás, Róbert et al. "MoEUT: Mixture-of-Experts Universal Transformers." arXiv preprint arXiv:2405.16039, 25. Mai 2024.
9. Suwito, Ryo. "From Toy Model to DeepSeek Giant: The Innocence of x + f(x)." DEV Community, 23. Februar 2026.