DeepSeek veröffentlicht drei Open-Source-Projekte für optimierte Parallelisierungsstrategien (4 von 5)

• Strategien und Code, die in DeepSeek V3/R1 verwendet wurden
  • DualPipe: bidirektionaler Pipeline-Parallelisierungsalgorithmus für Compute-Kommunikations-Overlap
  • EPLB: Expert-Parallel Load Balancer
  • Profile-Data: Datenprofiling der DeepSeek-Infrastruktur zur Analyse von Compute-Kommunikations-Overlap

DualPipe

• DualPipe ist ein innovativer bidirektionaler Pipeline-Parallelisierungsalgorithmus, der im DeepSeek-V3 Technical Report vorgestellt wurde
• Er überlappt Vorwärts- und Rückwärtsphasen von Berechnung und Kommunikation vollständig, um Pipeline-Bubbles zu reduzieren
• Ausführlichere Informationen zum Compute-Kommunikations-Overlap sind in den profile data verfügbar

Expert Parallelism Load Balancer (EPLB)

• Bei Expert Parallelism (EP) werden unterschiedliche Experten (experts) jeweils einzelnen GPUs zugewiesen
• Da die Arbeitslast je nach Experte variieren kann, ist es wichtig, die Last zwischen den GPUs ausgewogen zu verteilen
• In DeepSeek-V3 wird die Strategie der redundanten Experten (redundant experts) verwendet: stark ausgelastete Experten werden repliziert und anschließend effizient auf GPUs platziert, um Lastenausgleich zu erreichen
• Zusätzlich wird group-limited expert routing genutzt, um Experten derselben Gruppe möglichst auf demselben Node zu platzieren und dadurch den Datentransfer zwischen Nodes zu minimieren
• Um Reproduktion und Deployment zu erleichtern, wird in eplb.py der EP-Lastverteilungsalgorithmus als Open Source bereitgestellt
  • Dieser Algorithmus berechnet auf Basis der erwarteten Expertenlast einen ausgewogenen Plan für Replikation und Platzierung der Experten
  • Die konkrete Methode zur Vorhersage der Expertenlast liegt jedoch außerhalb des Umfangs des Repositorys; üblicherweise wird häufig ein gleitender Durchschnitt auf Basis historischer Statistiken verwendet
• Der Lastverteilungsalgorithmus bietet zwei Richtlinien, die jeweils in unterschiedlichen Situationen eingesetzt werden
  • Hierarchischer Lastenausgleich (Hierarchical Load Balancing)
    • Wenn sich die Anzahl der Server-Nodes durch die Anzahl der Expertengruppen teilen lässt, wird die Richtlinie Hierarchical Load Balancing verwendet, um group-limited expert routing zu optimieren
    • Zunächst werden die Expertengruppen gleichmäßig auf die Nodes verteilt, um die Last zwischen den Nodes auszubalancieren
    • Anschließend werden die Experten innerhalb jedes Nodes repliziert
    • Abschließend werden die replizierten Experten auf einzelne GPUs verteilt, um die Last zwischen den GPUs auszugleichen
    • Diese Richtlinie kann in der Prefilling-Phase mit kleinerem Expert-Parallelismus verwendet werden
  • Globaler Lastenausgleich (Global Load Balancing)
    • In allen anderen Fällen wird die Richtlinie Global Load Balancing verwendet: Experten werden unabhängig von ihren Gruppen global repliziert und anschließend auf einzelne GPUs verteilt
    • Diese Richtlinie eignet sich für die Decoding-Phase mit großem Expert-Parallelismus

Profiling-Daten der DeepSeek-Infrastruktur

• DeepSeek veröffentlicht Profiling-Daten aus seinem Trainings- und Inferenz-Framework, damit die Community Strategien für Kommunikations-Berechnungs-Overlap und Low-Level-Implementierungsdetails besser verstehen kann
• Diese Profiling-Daten wurden mit dem PyTorch Profiler erfasst und können nach dem Download in Chrome unter chrome://tracing bzw. in Edge unter edge://tracing visualisiert werden
• In den Experimenten wurde außerdem eine ausgewogene MoE-Routing-Strategie simuliert und für das Profiling verwendet
• Training
  • Die Training-Profiling-Daten aus DualPipe zeigen die Overlap-Strategie von Vorwärts- und Rückwärts-Chunks
  • Jeder Chunk enthält 4 MoE- (Mixture of Experts-) Layer und besitzt eine Parallelisierungskonfiguration, die dem Pretraining-Setup von DeepSeek-V3 entspricht:
• Inference
  • Prefilling
    • In dieser Phase werden zwei Micro-Batches verwendet, um Berechnung und all-to-all-Kommunikation zu überlappen
    • Außerdem wird die Last der Attention-Berechnung gleichmäßig auf die beiden Micro-Batches verteilt, sodass derselbe Prompt auf mehrere Micro-Batches aufgeteilt werden kann
  • Decoding
    • Auch beim Decoding werden wie beim Prefilling zwei Micro-Batches verwendet, um Berechnung und all-to-all-Kommunikation zu überlappen
    • Im Decoding belegt die all-to-all-Kommunikation jedoch keine GPU-SMs → nach dem Senden der RDMA-Nachricht werden die GPU-SMs freigegeben, und nach Abschluss der Berechnung wird auf das Ende der Kommunikation gewartet
    • Weitere Details zur all-to-all-Implementierung sind in DeepEP verfügbar

4. Teil von 5 Open-Source-Projekten, die als DeepSeek Open Infra veröffentlicht werden