Mixture of Experts erklärt

Ein großes Problem bei Scaling: Modelle werden nicht nur größer, sondern langsamer.

GPT-3: 175B Parameter aber schnell genug für Inference. Aber was wenn wir 1 Trillion Parameter wollen?

Das ist computationally unmöglich bei Dense Models.

Mixture of Experts (MoE) löst das: Aktiviere nicht alle Parameter gleichzeitig.

Das Konzept: Spezialisierte Sub-Modelle

Statt ein großes Modell, habe mehrere spezialisierte Sub-Modelle (Experts):

Expert 1: Gut für Code
Expert 2: Gut für Sprache
Expert 3: Gut für Mathematik
...

Ein Router entscheidet: Für diese Eingabe, welcher Expert?

Für jeden Input aktivierst du nur einen oder zwei Experts. Der Rest bleibt inaktiv.

Vorteil: Die insgesamt Parameter sind riesig (1 Trillion), aber der aktive Compute pro Token ist klein.

Praktisches Beispiel: Mixtral

Mixtral 8x7B:

• 8 Experts (Sub-Modelle), je 7B Parameter
• Gesamt: 56B Parameter
• Aber für jeden Input: Nur 2 Experts aktiviert = 14B aktive Parameter
• Inference ist gleich schnell wie 12B Model (nicht 56B!)

Das ist die Magie von MoE: Großes Modell, kleiner Inference Cost.

Wie Routing funktioniert

Ein einfacher Router:

router_output = expert_logits @ input  # Berechne Score für jeden Expert
weights = softmax(router_output)       # Normalisiere zu Wahrscheinlichkeiten
top_k = top_k(weights, k=2)            # Wähle beste 2 Experts
output = expert_output[top_k].mean()   # Kombiniere die Outputs

Der Router ist ein einfaches Netz. Er lernt: „Für diese Eingabe ist Expert 3 und Expert 5 am besten."

Probleme mit MoE

Problem 1: Training Instability

Wenn wenige Experts immer gewählt werden (z.B. Expert 1 und 2 alle Zeit), dann bleiben die anderen untertrainiert.

Das nennt sich Expert Collapse.

Lösungen:

• Auxiliary Loss: Bestraft ungleiche Expert-Nutzung
• Expert Load Balancing: Stellt sicher alle Experts genutzt werden
• Dropout auf Router: Randomness um Collapse zu vermeiden

Problem 2: Communication Cost

MoE braucht verteiltes Training über mehrere GPUs. Die Experts sitzen auf verschiedenen GPUs. Das braucht Kommunikation zwischen GPUs.

Wenn dein Netzwerk langsam ist, ist MoE langsam.

Problem 3: Fine-Tuning ist komplex

Mit Dense Modellen kannst du einfach LoRA machen. Mit MoE ist es kompliziert. Trainierst du alle Experts? Nur einen?

Forschung zeigt: Trainiere alle mit sparsem LoRA. Teuer.

Moderne Variationen

Sparse MoE: Aktiviere nur einen Expert (nicht 2). Noch schneller, schwächer.

Expert Specialization: Experts spezialisieren sich durch Training (z.B. eine wird Code-Expert).

Conditional Computation: Nur activiere Compute was nötig ist.

DeepSeek MoE (2024): Verbessert Routing, bessere Load Balancing.

Wann solltest du MoE nutzen?

MoE ist gut wenn:

• Dein Modell > 100B Parameter
• Du viel Inference machst (Latency matters)
• Du genug GPUs für verteiltes Training hast

MoE ist schlecht wenn:

• Dein Modell < 50B (Overhead lohnt sich nicht)
• Du auf Single GPU inferenzen möchtest
• Fine-Tuning ist wichtig

MoE vs. Dense Models: Vergleich

Die Zukunft von MoE

MoE wird wahrscheinlich Standard für sehr große Modelle.

Trends:

• Finer Granularity: Smaller Experts, mehr von ihnen
• Adaptive Routing: Router lernt dynamisch
• Knowledge Distillation: Extrahiere MoE in Dense Model

Die Geschichte von MoE: Von Switch zu Mixtral

Das erste funktionsfähige große MoE-Modell war Switch Transformers (2021). Das Papier zeigte:

• Ein Modell mit Billionen (!) Parametern ist trainierbar
• Pro Token wird nur ein Expert aktiviert (noch sparser als Mixtral)
• Trotz Sparsity ist Qualität vergleichbar mit dichten Modellen ähnlicher Größe

Das war revolutionär. Es zeigte: Scaling geht nicht nur durch Mehr-Parameter, sondern durch intelligente Aktivierung.

Dann kam Mixtral 8x7B (2024 von Mistral):

• 8 Experts, 2 aktiviert (gutes Mittelmaß zwischen Sparsity und Qualität)
• Training effizienter als Switch
• Performance auf Benchmark-Level mit 12B dichten Modellen
• Aber viel praktischer: Inference-Kosten sind niedrig

DeepSeek MoE (2024) verbessert das weiter:

• Bessere Load Balancing Algorithmen
• Spezialisierte Experts für verschiedene Token-Typen
• Noch bessere Routing-Mechaniken

Der Routing-Mechanismus (tiefergehend)

Der Router ist die Herzblutsache von MoE. Ein naiver Router könnte einfach "zuordnen nach K-Means Clustering" sein. Aber das ist schlecht.

Besser: Learned Gating

# Vereinfacht
token_embedding = embed(input_token)  # z.B. 4096-dim

# Router-Netzwerk (kleine NN)
router_logits = router_network(token_embedding)  # Output: 8 Scores (für 8 Experts)

# Top-K Selection
top_k_experts, top_k_weights = select_top_k(router_logits, k=2)

# Weighted Combination
output = sum(expert(input) * weight for expert, weight in zip(top_k_experts, top_k_weights))

Der Trick: Der Router wird während Training aktualisiert. Er lernt: "Für diesen Token-Typ, Expert 3 und 5 sind optimal".

Das Load Balancing Problem

Ein kritisches Problem: Ohne Regulierung konzentriert sich der Router auf wenige Experts.

Iteration 1: Expert 1 wird 100x gewählt, Expert 8 nur 2x
Iteration 100: Expert 1 hat überangepasst sich an Vorhersagen für "häufige" Token
               Expert 8 ist untertrainiert weil selten aktiviert

Das nennt sich Expert Collapse. Lösungen:

1. Auxiliary Loss (Switch Transformers)

   • Zusätzlicher Loss der ungleiche Verteilung bestraft
   • Load = sum(# tokens routed to expert)
   • Loss_aux = λ * (variance(Load) / mean(Load))
   • Erzwingt: Alle Experts gleich genutzt

2. Expert Dropout (DeepSeek)

   • Während Training: Mit Wahrscheinlichkeit p, disable einen Expert
   • Zwingt das Modell, andere zu trainieren

3. Capacitive Gating

   • Jeder Expert hat "Kapazität"
   • Wenn Kapazität voll → Tokens gehen zum Fallback

Praktisches Training mit MoE

Wenn du selbst ein MoE-Modell trainieren wolltest:

Hardware:

• 8 GPUs (eine pro Expert)
• Oder: Mehrere Experts pro GPU mit Offloading
• GPU-Kommunikation ist teuer (Inter-GPU Bandwidth)

Time to Train:

• Base Modell: 7B Parameter, 7B Tokens
• Dense 7B: ~3 Wochen auf 8x A100
• MoE 8x7B: ~2 Wochen (2 Experts pro token)
• Speedup: Ungefähr proportional zu Sparsity

Fine-Tuning Herausforderung: Wenn du ein MoE-Modell auf deine Daten fine-tunest:

• Option 1: Fine-tune alle Experts (teuer, alle bleiben aktiv)
• Option 2: Freeze Experts, fine-tune nur Router (schnell, aber limitiert)
• Option 3: LoRA auf jeden Expert (komplex, viele LoRA-Weights)

Empfehlung: Bei kleineren Daten → Freeze Experts, trainiere nur Router.

MoE vs Andere Compression-Techniken

Wann was?

• MoE: Du brauchst hohe Qualität und Geschwindigkeit, hast aber Speicher
• Quantization: Mobile/Edge Devices
• Pruning: Wenn Redundanz hoch ist
• Distillation: Wenn du Basismodell sehr klein haben musst

Praktische Deployment-Herausforderungen

Challenge 1: Ungleiche Speicherzugriffe

Wenn Experts auf verschiedenen GPUs sind:

• Expert 1 auf GPU-1, Expert 5 auf GPU-2, Expert 7 auf GPU-3 gewählt
• Müssen Daten zwischen GPUs shufflen
• Inter-GPU Bandwidth ist teuer

Optimization: Experts lokal halten. Token für Expert X → GPU X.

Challenge 2: Load Balancing in Practice

Theorie sagt: Alle Experts gleich nutzen. Practice: Die Verteilung ist natürlich nicht uniform.

Beispiel:

Tokens mit viel Grammatik-Information → Expert 1, Expert 2
Tokens mit Zahlen → Expert 5

Das ist OK—es bedeutet Spezialisierung. Solange kein einzelner Expert 90% kriegt.

Challenge 3: Inference Optimization

Bei Inference brauchst du nicht alle Experts im Memory.

Trick: Dynamic Expert Loading

1. Router sagt: "Brauch Expert 3 und Expert 7"
2. Lade nur die zwei ins VRAM
3. Verarbeite Token
4. Unload die zwei, lade nächste

Das senkt Speicher massiv.

MoE vs Dense: Ein echtes Beispiel

Beispiel: Trainingszeitraum

Modell: 70B Parameter Basis-Modell

Option 1: Dense 70B

Training: 24 Wochen auf 8x A100
Kosten: ~$500k
Memory: 560GB (70B params × 8 bytes forward + backward)

Option 2: MoE 8x70B (aber nur 2 aktiviert)

Modelle-Architektur: 8 × 70B
Aktive Parameter pro Token: 140B (2 × 70B)
Training: 18 Wochen auf 16x A100 (more GPUs, weniger Zeit)
Kosten: ~$600k (mehr GPUs, aber schneller)
Inference: ~140B active = ~2x schneller als dense 280B

Interessant: Training ist nicht viel schneller, aber Inference ist viel schneller + Modell ist größer.

MoE in der Forschung

Switch Transformers (Google, 2021):

• Erstes großes MoE-Paper
• Ultra-sparse (nur 1 Expert pro Token)
• Zeigte: 1 Trillion Parameter sind möglich

Mixtral (Mistral, 2024):

• 8x7B mit 2 Expert pro Token
• Optimierter als Switch
• State-of-the-Art Performance

DeepSeek MoE (DeepSeek, 2024):

• Noch bessere Load Balancing
• Neue Routing-Mechaniken
• Beating Mixtral auf einigen Benchmarks

GLaM (Google, 2021):

• 1.2 Trillion Parameter
• Aber: Schwierig zu trainieren, weniger Adoption

Open Questions in MoE (2026)

1. Können Experts sich spezialisieren?

   • DeepSeek zeigt: Ja, mit richtigem Training
   • Aber wie robust ist das Specialization?

2. Wie skaliert MoE zu noch mehr Experts?

   • 1000 Experts pro Token?
   • Kommunikations-Overhead wird brutal

3. Fine-Tuning bei Domain-Shift

   • Wenn deine Task sehr verschieden vom Pre-Training ist
   • Brauchen einige Experts komplett neue Gewichte?

Advanced Routing Strategien

Token Routing vs. Query Routing

Es gibt zwei Hauptstrategien für MoE Routing:

1. Token-Level Routing (Standard)

Jeder Token → Eigene Router-Entscheidung
Input Token: "machine" → Router sagt: Expert 2, Expert 5
Input Token: "123456" → Router sagt: Expert 6, Expert 8
Vorteil: Maximale Flexibilität und Spezialisierung
Nachteil: Jeder Token braucht Routing-Berechnung

2. Query-Level Routing (Selten)

Ganze Sequenz → Ein Router-Output
Eingabe: "write python code for..."
Router sagt: Expert 1, Expert 3 für gesamte Sequenz
Vorteil: Weniger Overhead
Nachteil: Weniger granular

Die meisten modernen Systeme nutzen Token-Level weil Overhead minimal ist.

Soft vs. Hard Assignment

Hard Assignment (was wir bisher beschrieben):

• Router wählt Top-K Experts
• Token geht zu exakt den K Experts

Soft Assignment (selten):

Expert 1: Wahrscheinlichkeit 0.4
Expert 2: Wahrscheinlichkeit 0.3
Expert 5: Wahrscheinlichkeit 0.2
Expert 8: Wahrscheinlichkeit 0.1

Output = 0.4*Expert1 + 0.3*Expert2 + 0.2*Expert5 + 0.1*Expert8

Soft Assignment ist differenzierbar aber rechenintensiv. Rarely used.

Die Mathematik der Load Balancing

Load Balancing ist essentiell für MoE Training. Ohne das kollabiert alles.

Metrik: Load Variance

Load_i = sum(Tokens routed to Expert i)

MeanLoad = sum(Load_i) / num_experts
Variance = sum((Load_i - MeanLoad)^2) / num_experts

Perfect Balance: Variance = 0 (alle Experts gleich)
Expert Collapse: Variance = hoch (einige Experts dominieren)

Auxiliary Loss (Google's Lösung)

Loss_aux = λ * sum_i ((Load_i / TotalTokens) * (Expert_Probability_i))

Je ungleicher die Last, desto höher der Loss
Das wird zum Training-Loss hinzuaddiert

Loss_total = Loss_language_modeling + 0.01 * Loss_aux

Der λ Parameter ist kritisch:

• λ = 0.00: Keine Load Balancing → Collapse nach ~100 Steps
• λ = 0.01: Optimal (Mixtral/DeepSeek Standard)
• λ = 0.1: Zu aggressiv → Alle Experts sind untertrainiert

Expert Utilization Metrics

Utilization_i = (Load_i / TotalTokens) * 100%

Ideal (8 Experts): 12.5% pro Expert
Mixtral 8x7B in Practice: 11-14% pro Expert (gut!)

DeepSeek MoE: 12-13% pro Expert (noch besser)
Switch Transformers: 10% pro Expert (unterutilized)

Spezialisierung: Wann entsteht Sie?

Ein großes offenes Thema: Spezialisieren sich Experts automatisch?

Empirische Beobachtung (DeepSeek, 2024):

Ja, aber nicht bei Random Initialization.

Initialisierung 1: Random Weights
→ Training: ~500 Steps
→ Experts durchmischen (kein Specialization)
→ Endresultat: Generalist Experts

Initialisierung 2: Token-Type Clustering
→ Expert 1 trainiert zuerst auf Code-Tokens
→ Expert 2 trainiert zuerst auf Math-Tokens
→ Training: ~500 Steps
→ Result: Spezialisierte Experts
→ Performance: +5-10% on specialized benchmarks

Das bedeutet: Specialization ist möglich, braucht aber:

1. Gute Initialisierung
2. Länger Training
3. Oder: Explizite Token-Type Signale

Kombination mit anderen Techniken

MoE + LoRA (Fine-Tuning)

Wenn du ein Mixtral-Modell (MoE) auf deine eigenen Daten finetunen willst:

Strategie 1: Freeze Experts, LoRA Router

for expert in experts:
    expert.requires_grad = False  # Freeze

router = add_lora(router)  # Nur Router trainieren

Vorteile: Schnell (nur Router trainieren), einfach Nachteile: Limited Adaptation, Router ist klein

Strategie 2: LoRA on All Experts

for expert in experts:
    add_lora(expert)  # LoRA für jeden Expert

add_lora(router)

Vorteile: Volle Flexibilität Nachteile: Viele LoRA Parameter (~16 pro Expert)

Empirical Finding (2024 Papers): Strategie 1 reicht für die meisten Domain Adaptations.

MoE + Knowledge Distillation

Großes MoE Modell → Kleineres Dense Modell

Teacher: Mixtral 8x7B (Inference teuer)
Student: Dense 7B (Inference günstig)

Training Student:
Loss = 0.5 * CrossEntropy(output, label)
     + 0.5 * MSE(Student, Teacher)

Result: Student 7B übernimmt "average Expert" Performance

Das funktioniert, aber: Student hat weniger Kapazität, Performance ~90% von Teacher.

MoE + Prompt Caching

Wenn du viele Prompts mit ähnlichem Kontext hast:

Kontext (50k Tokens, gleich für alle):
→ Router sagt wahrscheinlich gleiche Experts gewählt
→ Cache die Outputs der Experts

Neue Prompts:
→ Reuse gecachte Outputs
→ Nur neue Tokens durch Router

Das ist Research-Territory (nicht produktiv used yet).

MoE Training in der Praxis: Echte Zahlen

Real Benchmark: Mixtral 8x7B Training

Hardware: 16x A100 (80GB)
Sequence Length: 32k
Batch Size: 128
Learning Rate: 5e-4

Timeline:
- Week 1: Chaotic (Experts nicht spezialisiert)
- Week 2-3: Load Balancing stabilisiert sich
- Week 4+: Smooth Training (2.5k Tokens/sec)

Compute:
- Total Tokens: 1.3 Trillion
- Training Time: ~50 Tage
- Cost: ~$150k (AWS on-demand)
- FLOPs: 2.6e21 (2.6 Zettaflops)

Vergleich zu Dense 70B:

Dense 70B:
- Hardware: 8x A100 (weniger, aber volles Modell)
- Training Time: 60 Tage
- Cost: ~$180k (höher weil Modell größer)
- FLOPs: 9.1e21 (3.5x mehr Compute)

MoE vs Dense:
- MoE ist 1.2x schneller zu trainieren
- MoE kostet 20% weniger
- MoE hat 10x mehr Parameter
- MoE hat 2x bessere Inference Performance

Das ist warum MoE interessant ist.

Forschung in 2026: Offene Fragen

1. Können wir zu 1000 Experts skalieren?

   • Theoretisch ja
   • Praktisch: Kommunikations-Overhead wird extrem
   • Prediction: Nächste Generation wird 32 oder 64 Experts haben

2. Expert Collaboration

   • Was wenn Experts zusammenarbeiten?
   • Mixtur zwischen Top-2 und Top-8?
   • Early results: Nicht hilfreich

3. Training Instabilities

   • MoE Training ist noch fragiler als Dense
   • Warum ist Load Balancing so schwer?
   • Wird besser verstanden aber noch nicht gelöst

4. Hardware Alignment

   • Moderne Hardware (GPUs) ist nicht für MoE optimiert
   • TPUs sind besser, aber teuer
   • Future: MoE-optimierte Hardware?

Literatur

• Switch Transformers: arxiv.org/abs/2101.03961
• Mixtral: arxiv.org/abs/2401.04088
• DeepSeek MoE: arxiv.org/abs/2401.04081
• Load Balancing in MoE: arxiv.org/abs/2402.04451
• Expert Specialization: arxiv.org/abs/2407.02459

Quellen und Links

• Mixtral of Experts (arXiv)
• Shazeer et al. (arXiv)