MoE ist eine Architektur wo ein Modell aus vielen "Experts" besteht, aber pro Input nur ein paar aktiviert werden. Das spart massiv Compute ohne viele Parameter zu verlieren.


Die Kernidee

Standard Transformer Layer:
Input
  ├─ Self-Attention (aktiviert immer)
  └─ Feed-Forward Net (aktiviert immer)
Output

Tokens müssen durch ALLE Parameter

MoE Layer:
Input
  ├─ Self-Attention (aktiviert immer)
  └─ Gate (Router) entscheidet welche Experts aktivieren
     ├─ Expert 1: Feed-Forward Network
     ├─ Expert 2: Feed-Forward Network
     ├─ Expert 3: Feed-Forward Network
     └─ Expert N: Feed-Forward Network

Result wird kombiniert

Output

Key Insight: Statt 1 großes Feed-Forward, habe N kleine Experts. Pro Token aktiviere nur top-K Experts (z.B. K=2).


Mathematik

Routing Mechanismus

Input: [batch, seq_length, d_model]

Router (Lineare Layer):
scores = Linear(input) @ expert_weights    [batch, seq, num_experts]

Gate (softmax über experts):
probs = softmax(scores)                    [batch, seq, num_experts]

Top-K Selection:
top_k_probs, top_k_indices = topk(probs, k=2)  [batch, seq, k]

Weighted Combination:
output = Σ top_k_probs[i] * Expert[top_k_indices[i]](input)

Beispiel (vereinfacht)

Input Token: "Der"
             [0.5, -0.3, 0.2, ...]  (d_model=768)

Router Output (4 Experts):
scores = [2.1, 0.5, 1.8, 0.3]

Softmax:
probs = [0.6, 0.1, 0.25, 0.05]

Top-2 Selection:
Aktiviere: Expert 0 (prob 0.6), Expert 2 (prob 0.25)

Expert 0: Input → FFN → Output_0
Expert 2: Input → FFN → Output_2

Weighted Combination:
Final = 0.6 × Output_0 + 0.25 × Output_2
        (normalisiert)

Vorteile: Warum MoE interessant ist

1. Sparse Activation (Hauptvorteil)

Standard 70B Model:
- Alle Gewichte müssen pro Token durch Attention + FFN gehen
- 70B multiply-accumulate operations pro Token

MoE 56B Model (Mixtral 8×7B):
- Attention: 56B operations (gleich)
- FFN: Nur 2 von 8 Experts aktiviert
  = 2/8 × 56B ≈ 14B operations
- Total: ~70B (ähnlich!) aber effizienter

Inference Speed:
- Standard 70B: 70 Token/sec
- MoE 56B: 120 Token/sec (2× schneller!)
- Bei ähnlicher Speicher!

2. Parameter Efficiency

Standard Transformer:
Größe = 4 × num_layers × d_model²

MoE (mit N experts, Top-K):
Größe ≈ Standard + (N-1) × Expert_size
     = 56B + 7 × 7B = 105B "parameters"
     aber nur ~14B aktiv pro Token

→ Modell ist größer in Speicher
  aber schneller im Inference
  weil nur Teil aktiviert!

3. Multi-Specialization

Theorie: Different Experts spezialisieren auf verschiedenes

Beispiel (möglich, nicht garantiert):
Expert 1: "Grammar and Syntax"
Expert 2: "Medical Knowledge"
Expert 3: "Code Generation"
Expert 4: "Math Reasoning"
...
Expert 8: "Common Sense"

Router lernt: Wenn Input "medical question" → aktiviere Expert 2

Empirisch: Schwer zu beweisen, aber Plausibel!

Die MoE Modelle (2026)

Mixtral 8×7B (Mistral AI)

# Öffentlich verfügbar, Open-Source

from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained(
    "mistralai/Mixtral-8x7B-Instruct-v0.1",
    torch_dtype=torch.float16,
    device_map="auto",
)

# Parameter:
# - 8 Experts (7B each)
# - Top-2 routing (aktiviert 2 von 8)
# - Quasi-Parameters: 56B
# - Effective Parameters pro Token: 14B

# Performance:
# - Schneller als Llama 3 70B
# - Ähnliche Qualität
# - Größerer Context (32K)

Praktisch:

VRAM: 50-60 GB (für 8×7B)
Tokens/sec: ~120 (auf RTX 6000)
Cost: Kostenlos (open-source)

Allerdings:
- Nicht alle Frameworks unterstützen MoE gut (vLLM: ja, ollama: schwierig)
- Quantization ist trickier (manche Experts werden stark komprimiert)

DeepSeek MoE (China, besonders Interessant)

DeepSeek-MoE-16B:
- 16 Experts (2B each)
- Top-2 routing
- Only 2.8B parameters aktiv pro Token (!)
- Performance: Ähnlich 7B Standard Models
- Speed: ~3× schneller als 7B Standard

DeepSeek hat auch:
- DeepSeek-MoE-145B (145B params, ~37B aktiv)
- Beste Qualität im Open-Source MoE Space (2024/25)

GPT-4 (vermutlich, nicht bestätigt)

Gerüchte (von OpenAI Engineers hints):
- GPT-4 könnte MoE sein
- Größe: ~1.8T "parameters"
- Aktive pro Token: ~100-300B (?)

Evidenz:
- Sehr schnelle Inference (deutet auf sparsame Aktivierung)
- Konsistente Kosten trotz 10× größer als GPT-3.5
- Paper aus OpenAI zu MoE Skalierung (2023)

Aber: Nicht bestätigt! OpenAI gibt nicht detailliert Architektur

Herausforderungen bei MoE

Problem 1: Router Collapse (kritisch)

Symptom: Alle Tokens aktivieren die gleichen 2 Experts
         andere Experts sind inaktiv

Result: Effektiv ein 2-Expert Modell, keine Specialisierung

Ursache:
- Router Network zu einfach gelernt
- Oder: Unbalancierte Loss

Lösung:
- Zusatz-Loss: "Penalize wenn Expert über-/unter-genutzt"
  Loss_total = Main_Loss + λ × Balance_Loss

  Balance_Loss = Std_Dev(expert_usage)

  → Zwingt Router zum Fair Distribution

Heutige Modelle (Mixtral): Haben Balance-Mechanism

Problem 2: Communication Overhead

Standard 70B Model:
- Sequential: Attention Layer → FFN → Output

MoE 56B Model:
- Parallel: Attention → 8 Experts Parallel
- Aber: Müssen Outputs kombinieren (gather operation)

GPU Overhead:
- Gather/Scatter Operationen sind nicht optimiert
- Kann 10-20% Speedup negieren!

vLLM Lösung: Custom CUDA Kernels für MoE
           → 95% der theoretischen Speedup

Problem 3: Training Instability

Standard Model:
- Loss ist glatt, Training ist stabil

MoE Model:
- Router kann "springen" (selbe Experts aktivieren switch plötzlich)
- Gradienten können hochexplosiv sein

Lösung:
- Gradient Clipping
- Learning Rate Scheduling (start klein)
- Auxiliary Loss für Balance

Empirisch: MoE Models brauchen etwas mehr Tuning beim Training

Wann MoE verwenden?

JA: MoE ist gut für...

1. Inference-Speed-Kritisch
   z.B. Chatbot mit <100ms Latency SLA
   → Mixtral 8×7B ist 2× schneller als Llama 3 70B

2. Breites Wissen erforderlich (Multi-Domain)
   z.B. Search Engine, Allzweck-Assistant
   → Experts können spezialisieren
   → Besser Qualität bei gleicher Speed

3. Budget-Limitiert (Inference)
   z.B. Millionen Queries pro Tag
   → Sparse Activation spart 70% Compute
   → 70% weniger Infrastructure-Kosten

4. Hardware ist Bottleneck
   z.B. Mobile Deployment, Edge Devices
   → Weniger Compute = Kleinerer Footprint

NEIN: MoE ist nicht gut für...

1. Training (dein eigenes Modell)
   → Viel komplexer, höhere Chance Instability
   → Nutze Standard Transformer, später könnte MoE-Variante kommen

2. Wenn latency variabel ist kritisch
   → Router Decision time kann je nach Input variieren
   → Standard Model vorhersehbarer

3. Sehr Specialized Task
   → Single Expert Model könnte besser sein
   → Multi-Expert Routing overhead nicht wert

4. Low-Precision Deployment
   → Quantization ist trickier bei MoE
   → Manche Experts komprimieren besser/schlechter

Performance Vergleiche (2026)

Modell Architecture Param Active Tokens/Sec Quality (MMLU) Kosten (API)
Llama 3 70B Dense 70B 70B 60 85% €0.003/K
Mixtral 8×7B MoE 56B 14B 120 84% €0.0001/K
GPT-3.5 Turbo Unknown ~100B ~100B 80 85% €0.0005/K
Claude 3.5 Sonnet Unknown Proprietary Proprietary 70 88% €0.003/K

Zukunft

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

Warum?
1. Inference Efficiency: 2-3× Speedup für ähnliche Qualität
2. Training Efficiency: Router ist relativ einfach, Pretraining nicht komplexer
3. Scaling: MoE skaliert besser zu sehr großen Modellen
4. Hardware: GPUs immer besser bei parallelen Operations (Experts)

Prediktionen:
- 2026: Mehr Open-Source MoE Models
- 2027: MoE Standard bei >100B Modellen
- 2028+: Hybrid Dense-MoE Architectures (beste beider Welten)

Für AI Engineering: MoE Models wie Mixtral jetzt schon verfügbar
und praktisch. Für eigene Fine-Tuning: Noch zu früh.

Mixture of Experts ist eine clevere Idee mit realen praktischen Vorteilen: 2× schneller, 70% weniger Compute, ähnliche Qualität. Mixtral zeigt dass es funktioniert. Das wird definitiv mehr in der Zukunft.