Pipeline Parallelism

Pipeline-Parallelität ist ein Verfahren für das verteilte Training, bei dem ein neuronales Netz der Tiefe nach in aufeinanderfolgende Gruppen von Schichten, sogenannte Stufen, aufgeteilt wird. Jede Stufe wird einer eigenen GPU zugewiesen, und Aktivierungen werden von einer Stufe an die nächste weitergegeben. Damit alle GPUs ausgelastet sind, wird jeder Batch in kleinere Mikro-Batches zerlegt, die wie Teile auf einem Fließband durch die Stufen laufen. Das Verfahren wird auch Parallelisierung des Modells zwischen Schichten genannt. Google-Forscher unter der Leitung von Yanping Huang machten den Mikro-Batch-Ansatz mit GPipe im November 2018 bekannt. Sie trainierten damit ein AmoebaNet mit 557 Millionen Parametern, das auf ImageNet eine Top-1-Genauigkeit von 84,4 % erreichte, sowie einen mehrsprachigen Transformer mit 6 Milliarden Parametern und 128 Schichten.

Mikro-Batches und die Pipeline-Blase#

Wird jeweils nur ein Batch verarbeitet, arbeitet nur eine Stufe, während die anderen warten: Stufe 2 kann erst beginnen, wenn Stufe 1 fertig ist, und bei der Rückpropagierung kehrt sich die Reihenfolge um. Mit Mikro-Batches kann Stufe 1 den zweiten Mikro-Batch beginnen, sobald sie den ersten an Stufe 2 übergeben hat. Die verbleibenden Leerlaufzeiten beim Füllen und Leeren der Pipeline nennt man die Blase. Eine Ausgabe des Vorwärtslaufs nach dem GPipe-Schema mit 4 Stufen und 6 Mikro-Batches sieht so aus:

stages, micro_batches = 4, 6
steps = micro_batches + stages - 1  # time steps until the last micro-batch leaves the last stage

for stage in range(stages):
    row = ""
    for t in range(steps):
        m = t - stage  # stage s starts micro-batch m once stage s-1 hands it over
        row += f" F{m}" if 0 <= m < micro_batches else "  ."
    print(f"GPU {stage}:{row}")

# Every stage idles for stages - 1 of the steps, in the forward and again in the backward pass
bubble = (stages - 1) / steps
print(f"Idle fraction: {bubble:.0%}")

Die Ausgabe zeigt eine Treppe: GPU 0 führt in den ersten sechs von neun Schritten Vorwärtsläufe F0 bis F5 aus und wartet danach. GPU 3 wartet drei Schritte, bevor sie F0 startet, und die letzte Zeile lautet Idle fraction: 33%. Der Anteil der Blase beträgt (Stufen − 1) / (Mikro-Batches + Stufen − 1). 24 Mikro-Batches durch dieselben 4 Stufen senken ihn also auf 11 %. Die Gradienten aller Mikro-Batches werden vor einem einzigen Optimierungsschritt addiert. Das entspricht der Rechnung bei der Gradientenakkumulation, sodass die Aktualisierung dem Training mit dem vollständigen Batch entspricht. GPipe verwirft außerdem die Aktivierungen innerhalb jeder Stufe und berechnet sie beim Rückwärtslauf erneut – eine Form des Gradient Checkpointing.

Pipeline-Zeitpläne#

Spätere Zeitpläne ordnen dieselbe Arbeit neu an, um Speicher zu sparen oder die Blase zu verkleinern:

• 1F1B: 2018 mit dem System PipeDream eingeführt. Sobald die Pipeline gefüllt ist, wechseln sich pro Stufe jeweils ein Vorwärts- und ein Rückwärtslauf eines Mikro-Batches ab. Jede Stufe hält dann höchstens so viele Aktivierungen wie es Stufen gibt, statt alle Aktivierungen zu speichern.
• Verschachteltes 1F1B: Weist jeder GPU mehrere kleinere, nicht aufeinanderfolgende Stufen zu. Das Megatron-LM-Team von NVIDIA berichtete damit von einem um mehr als 10 % höheren Durchsatz und trainierte ein Modell mit 1 Billion Parametern auf 3.072 GPUs mit 502 PetaFLOP/s, also 52 % der Spitzenleistung.
• Zero Bubble: Teilt den Rückwärtslauf in den Gradienten für die Eingabe der Stufe, auf den die vorherige Stufe wartet, und den Gradienten für die Gewichte auf. Letzterer kann spätere Leerlaufzeiten füllen. Bei einem vergleichbaren Speicherbudget übertrifft das Verfahren den Durchsatz von 1F1B um bis zu 23 %.

PyTorch stellt diese Verfahren als ScheduleGPipe, Schedule1F1B, ScheduleInterleaved1F1B, ScheduleInterleavedZeroBubble und ScheduleDualPipeV in seiner Pipeline-API bereit, die ein Modell ebenfalls in Stufen aufteilt. DualPipe stammt aus DeepSeek-V3. Das Team nutzte 16 Pipeline-Stufen, um Berechnungen und Kommunikation zu überlappen und die Blase zu verkleinern.

Einsatzbereich der Pipeline-Parallelität#

Die Stufen tauschen pro Mikro-Batch nur die Aktivierungen an ihren Grenzen aus. Pipeline-Parallelität kommt deshalb besser mit langsameren Verbindungen zwischen Servern zurecht als Tensor-Parallelität, bei der innerhalb jeder Schicht kommuniziert wird. Große Trainingsläufe kombinieren daher beide Verfahren. Meta trainierte Llama 3 405B mit achtfacher Tensor-Parallelität innerhalb jedes Servers mit 8 GPUs, 16 Pipeline-Stufen zwischen den Servern und Datenparallelität über 64 bis 128 Replikate. Auch Bereitstellungs-Engines wie vLLM nutzen dieselbe Aufteilung, wenn ein Large Language Model (LLM) mehr als einen Knoten benötigt. Die langsamste Stufe gibt das Tempo für die gesamte Pipeline vor. Bei einem Sprachmodell umfassen die erste und letzte Stufe außerdem die Einbettungstabelle und die Ausgabeschicht. Deshalb gab Llama 3 jeder dieser Stufen eine Transformerschicht weniger.

Verwandte Ansätze teilen die Arbeit auf andere Weise auf:

• Tensor-Parallelität: Teilt die Gewichtsmatrizen innerhalb jeder Schicht auf, sodass jede GPU an jeder Schicht beteiligt ist.
• Kontextparallelität: Teilt eine lange Eingabesequenz auf mehrere GPUs auf.
• Geteiltes Lernen: Teilt ein Netz ebenfalls entlang seiner Tiefe auf, jedoch zwischen Organisationen. Dadurch muss ein Dateneigentümer keine Rohdaten an den Server senden, auf dem die späteren Schichten ausgeführt werden.

Bei der Datenparallelität bleibt jede Schicht auf jeder GPU, stattdessen wird der Batch aufgeteilt. Das genügt, wenn ein Modell auf ein einzelnes Gerät passt. So trainiert Ultralytics YOLO26 auf mehreren GPUs: Im Trainingsmodus mit device=[0, 1, 2, 3] und batch=64 verarbeitet jede GPU das vollständige Objekterkennungsmodell mit 16 Bildern. PyTorch DistributedDataParallel mittelt die Gradienten nach jedem Rückwärtslauf über alle GPUs.