Expert Parallelism: Das Dilemma des Routers

Wir haben Tensor Parallelism (TP) untersucht, das einzelne Operationen aufteilt, um massive Schichten in den Speicher zu passen, und Pipeline Parallelism (PP), das Schichten vertikal aufteilt, um über mehrere Knoten zu skalieren. Doch während Modelle nicht nur in Tiefe oder Breite, sondern auch in Vielfalt wachsen – insbesondere mit Mixture-of-Experts (MoE)-Architekturen wie Mixtral 8x7B oder DeepSeek-V3 – stoßen wir auf einen neuen Engpass.

In einem dichten Modell wird jeder Parameter für jedes Token verwendet. In einem MoE-Modell ist nur ein Bruchteil der Parameter (Experten) pro Token aktiv. Alle Experten auf jeder GPU zu replizieren kann zu viel Speicher kosten. Expert Parallelism verteilt die Experten auf Ranks und lässt sich mit Tensor- und Datenparallelität kombinieren. Die beste Aufteilung hängt von Expertengröße, Batch und Verbindung ab.

Hier kommt Expert Parallelism (EP) ins Spiel. In diesem Paradigma verteilen wir die Experten selbst auf verschiedene GPUs. GPU 0 hält Experte A, GPU 1 hält Experte B. Die Herausforderung verlagert sich vom Aufteilen von Matrizen zum Routing der Tokens: Wir müssen Daten (Tokens) physisch zu der GPU verschieben, die die benötigten Parameter zur Verarbeitung enthält.

Dieser Artikel analysiert die Hardware-Mechanik von EP, das "All-to-All"-Kommunikationsprinzip, das sie definiert, und die entscheidenden Kompromisse, die dabei eine Rolle spielen.

1. Die Hardware-Mechanik: Token-Routing

Bei Expert Parallelism ist das Modell physisch fragmentiert. Das entscheidende Hardware-Ereignis ist nicht mehr eine Matrixmultiplikations-Synchronisation (wie bei TP) oder ein Pipeline-Flush (wie bei PP); es ist die Bewegung von Tokens über die Verbindung. Das Datenvolumen hängt von Tokenanzahl, Hidden-Dimension und Expertenplatzierung ab.

Der Vier-Stufen-Lebenszyklus

Für eine einzelne MoE-Schicht sieht der Hardware-Ausführungsablauf folgendermaßen aus:

Route (Lokale Berechnung): Jede GPU verarbeitet ihr Token-Batch durch ein kleines "Gating Network" (in der Regel eine einzelne Linear-Schicht). Dieser Router berechnet, welchen Experten (z. B. Expert 0, 1, ... 7) jedes Token aufsuchen muss.
- Hardware-Status: Tokens befinden sich derzeit auf der "Quell"-GPU.
Dispatch (Der Kommunikations-Engpass): Dies ist der entscheidende Moment von EP. GPU 0 könnte 100 Tokens haben, die zu Expert 5 (auf GPU 5) müssen. GPU 1 könnte 50 Tokens für Expert 5 haben. Jede GPU muss bestimmte Teilmengen ihrer Daten gleichzeitig an jede andere GPU senden. Eine übliche Implementierung verwendet dafür eine All-to-All-Kollektivoperation.
- Hardware-Auswirkung: Dies belastet die Bisection Bandbreite des Clusters. All-to-All hat ein anderes Verkehrsmuster als die häufig für TP verwendeten Kollektivoperationen.
Expert Compute (Lokale Berechnung): Sobald die Tokens bei ihren Ziel-GPUs (dem "Zuhause" ihrer zugewiesenen Experten) angekommen sind, führt die GPU die Standard-Feed-Forward-Network (FFN)-Berechnung durch.
- Hardware-Vorteil: Die arithmetische Intensität hängt von der Anzahl der einem Experten zugewiesenen Tokens und dessen Dimensionen ab. Die Expertenrechnung selbst kann lokal stattfinden.
Combine (Kommunikation): Die verarbeiteten Tokens müssen zu ihren ursprünglichen Quell-GPUs zurückkehren, um die Reihenfolge der Sequenz für die nächste Schicht (z. B. Attention) zu erhalten. Dies erfordert eine zweite All-to-All-Operation, um die Ergebnisse zurückzusenden.

Die Hardware-Realität: All-to-All

Das All-to-All-Primitive unterscheidet sich von All-Reduce.

All-Reduce (bei manchen TP-/DP-Operationen): Ranks kombinieren gleich große Tensoren durch eine Reduktion, etwa Summation. Das Kommunikationsvolumen hängt von Tensorgröße und Algorithmus ab.
All-to-All (EP): GPU $i$ sendet einen personalisierten Puffer an GPU $j$ . Das Volumen kann dynamisch und ungleichmäßig sein (Lastungleichgewicht), was zu Netzwerküberlastung führen kann, wenn eine GPU deutlich mehr Daten als andere empfängt.

2. Bare Metal Implementierung: Reines PyTorch

Dieser Pseudocode für Top-1-Routing mit einem Experten pro Rank zeigt die Abfolge. PyTorch torch.distributed.all_to_all_single erwartet flache Tensoren und ganzzahlige Split-Größen für die beiden Transfers. Eine reale Schicht benötigt außerdem identische Router-Gewichte, die Gewichtung der Expertenausgaben, eine Prozessgruppe, Gradientenbehandlung und gegebenenfalls eine Kapazitätsregel.

text

# Schematic top-1 dispatch; one expert per rank. Not executable code.
logits = router(local_tokens)           # router weights identical on all ranks
expert = argmax(logits, axis=-1)         # one destination rank per token
order = argsort(expert)                  # group tokens by destination
send_counts = bincount(expert, minlength=world_size)
recv_counts = all_to_all(send_counts)    # exchange counts before variable splits
received = all_to_all(sorted_tokens, input_splits=send_counts,
                      output_splits=recv_counts)
processed = local_expert(received)
returned = all_to_all(processed, input_splits=recv_counts,
                      output_splits=send_counts)
output = inverse_permute(returned, order).reshape_as(local_tokens)

Die Skizze zeigt den Datenfluss und ist keine ausführbare PyTorch-Schicht. Megatron Core unterstützt mehrere Dispatcher und Kapazitätsregeln.

In dieser Implementierung tauschen die GPUs effektiv ihre Rollen: Sie sind nicht länger "Eigentümer eines Batch-Slices", sondern werden vorübergehend zu "Compute-Servern für bestimmte Operationen" und verarbeiten Tokens aus dem gesamten Cluster.

3. Hardware-Einschränkungen & Kompromisse

Der All-to-All-Latenzsprung

EP bewegt in diesem Beispiel geroutete Aktivierungen zweimal pro MoE-Schicht. Das Volumen ist proportional zur Tokenanzahl und Hidden-Dimension. Auch TP und PP kommunizieren; jede dieser Strategien kann innerhalb eines Knotens oder zwischen Knoten laufen.

Inter-Node-Flaschenhals: Wenn Ihre Experten auf verschiedene Serverknoten verteilt sind, muss die All-to-All-Operation das Ethernet/InfiniBand-Netzwerk durchqueren. Bandbreite und Latenz zwischen Knoten unterscheiden sich meist von lokalen Verbindungen; entscheidend ist die konkrete Topologie.
Latenzempfindlichkeit: Bei kleinen Batch-Größen (Inference) kann die Latenz des All-to-All-Schritts die Ausführungszeit dominieren, wodurch EP langsamer als einfache Datenparallelität wird.

Der Albtraum des Lastenausgleichs

Hardware mag keine Unregelmäßigkeiten. GPUs sind am schnellsten, wenn sie statische, gleichmäßige Strukturen verarbeiten.

Das Problem: Wenn der Router entscheidet, dass 90% der Tokens zu Expert 0 (GPU 0) gehen müssen, wird GPU 0 zum Flaschenhals, während GPUs 1–7 untätig bleiben. Dies ist Rechen-Skew.
Die Konsequenz: Der überlastete Experte kann die Kollektivoperation und die nachfolgende Berechnung verzögern.
Die Lösung (Hardware-Ebene): Mögliche Gegenmaßnahmen sind ausgeglichenes Routing, Expertenreplikation, mehr Kapazität oder Token-Dropping. Dropping ist eine optionale Kapazitätsregel und verändert das Modellverhalten.

Zusammenfassung der Vor- und Nachteile

Vorteile

Massiver Parameterskalierung: Sie können Modelle mit Billionen von Parametern trainieren — Googles Switch Transformer erreichte 1,6 Billionen Parameter mit 2.048 Experten — weil Expertengewichte über Geräte verteilt werden können. Der Anteil $1/N$ gilt nur für Expertengewichte im idealisierten Aufbau mit einem Experten pro Rank; gemeinsame Attention- und andere Gewichte bleiben bestehen.
Recheneffizienz: Anders als bei dichten Modellen, bei denen die FLOPs linear mit der Parameteranzahl skalieren, kann MoE bei fester Anzahl und Größe aktiver Experten mehr Gesamtparameter haben, ohne die Experten-FLOPs pro Token proportional zu erhöhen. Router, Kommunikation und Speicher kosten weiterhin Ressourcen; Qualitätsgewinne müssen gemessen werden.
Asynchrones Potenzial: Manche Implementierungen können Expertenkommunikation mit Berechnung überlappen, sofern die Abhängigkeiten das zulassen.

Nachteile

Kommunikationsaufwand: Die All-to-All-Primitve ist aufwendig. Sie profitiert von ausreichender Bandbreite in der beteiligten Prozessgruppe.
Lastverteilung: Router benötigen eine Strategie zum Lastenausgleich; Hilfsverluste sind eine Möglichkeit. Ungleichverteilung kann die Auslastung senken.
Speicherfragmentierung: Dynamische Tokenzahlen können variable Puffer oder Padding erfordern; der gewählte Dispatcher bestimmt den Speicheraufwand.