Load Balancing Problem – LLM Explorer

Fig. 1 | MoE Load Balancing Visualisierung. Links: Balanced – Tokens werden gleichmäßig auf Experten verteilt. Rechts: Imbalanced – Alle Tokens routen zu Expert 1 (Bottleneck, rote Warnung).

✓ Optimales Szenario: Balanced

Tokens werden gleichmäßig auf alle Experten verteilt. Jeder Expert verarbeitet etwa 20% der Tokens pro Layer.

Tokens pro Expert 20% je

GPU Auslastung 80% (optimal)

Durchsatz Maximal

Latenz Minimal

✗ Problem-Szenario: Imbalanced

Alle Tokens routen zu Expert 1. Das System wird zu einem Dense Model mit Kommunikations-Overhead.

Tokens auf Expert 1 80%

Tokens auf andere 5% je

GPU Auslastung Expert 1 100% (Bottleneck)

Latenz 3-5× höher

Warum ist Load Imbalance ein Problem?

1

GPU-Auslastung Ineffizienz: Wenn Expert 1 100% ausgelastet ist und Expert 2-8 nur 5%, dann ist die durchschnittliche Auslastung = (100 + 5 + 5 + 5 + 5 + 5 + 5 + 5) / 8 = 15.6%. Die anderen GPUs sind Idle und leisten keine Arbeit.

2

Bottleneck-Effekt: Expert 1 bestimmt die Gesamt-Durchsatzrate. Alle anderen Experten müssen auf Expert 1 warten. Die Latenz wird von der langsamsten Komponente dominiert (kritischer Pfad).

3

Netzwerk-Overhead: In verteilten Systemen (mehrere GPUs) müssen Tokens und Outputs zwischen Geräten übertragen werden. Mit Imbalance werden Netzwerk-Links zu Expert 1 gesättigt, während andere leer sind.

4

Router-Lernproblem: Der Router lernt, über Gradient Descent zu optimieren. Wenn der Router systematisch Top-2 Expert 1 bevorzugt, bekommt die Loss-Funktion kein Signal zur Korrektur.

5

Lösungsansätze: Moderne MoE-Systeme nutzen Auxiliary Loss zur Erzwingung von Balance. Zusätzliche Regularisierung: L_aux = α × (Σ_i P_i × E_i), wobei P_i = durchschnittliche Expertenwahl, E_i = Expertenauslastung.

6

Praktische Beobachtung: In realen Trainings kann Load Imbalance zu 2-3× längeren Training-Zeiten führen. DeepSeek und Mixtral haben eigene Strategien: Expert-Dropout während Training, Dynamic Expert Selection.