Data Parallelism
Die einfachste Form verteilten Trainings: Jede GPU hält eine vollständige Modellkopie und verarbeitet verschiedene Daten-Batches – Gradienten werden synchronisiert.
Data Parallelism repliziert das Modell auf jede GPU und verteilt Daten – einfachste Multi-GPU-Strategie mit nahezu linearem Speedup.
Erklärung
Jede GPU verarbeitet einen Mini-Batch, berechnet Gradienten lokal, dann werden Gradienten via AllReduce gemittelt und alle Kopien synchron aktualisiert. Linear skalierbar bis Kommunikation zum Bottleneck wird. PyTorch DDP ist der Standard.
Relevanz für Marketing
Data Parallelism ist der Default für Multi-GPU-Training wenn das Modell auf eine GPU passt – einfach, effizient, nahezu linearer Speedup.
Beispiel
Fine-Tuning eines 7B-LLM auf 4 A100 GPUs: Jede GPU hält das volle Modell (14GB in FP16), verarbeitet Batch-Size 8. Effektive Batch-Size: 32. Training 4x schneller als single-GPU.
Häufige Fallstricke
Modell muss komplett auf jede GPU passen. Redundante Memory-Nutzung (N Kopien). Kommunikations-Overhead bei vielen GPUs. Für sehr große Modelle ist FSDP/ZeRO nötig.
Entstehung & Geschichte
Data Parallel Training existiert seit den 1990ern. PyTorch DataParallel (DP) war die erste einfache Implementierung. PyTorch DDP (2019) verbesserte Effizienz durch per-Parameter AllReduce. Horovod (Uber, 2018) popularisierte Ring-AllReduce für effiziente Gradient-Synchronisation.
Abgrenzung & Vergleiche
Data Parallelism vs. Model Parallelism
Data Parallel: Ganzes Modell auf jeder GPU, Daten verteilt. Model Parallel: Modell aufgeteilt über GPUs – nötig wenn Modell > 1 GPU.
Data Parallelism vs. FSDP / ZeRO
DDP hält vollständige Modellkopien; FSDP/ZeRO sharden Modellparameter über GPUs – spart Memory bei gleichem Speedup.