- High-Performance-Kommunikationsbibliothek für Mixture-of-Experts (MoE) und Expert Parallelism (EP)
- Bietet einen GPU-basierten All-to-All-Kernel, um MoE-Dispatch- und Combine-Operationen mit hoher Geschwindigkeit zu verarbeiten
- Unterstützung für Berechnungen mit niedriger Präzision wie FP8
- Verwendet den im DeepSeek-V3-Paper vorgeschlagenen group-limited gating-Algorithmus, um asymmetrische Domain-Bandbreiten-Weiterleitung zu optimieren
- Beispiel: Optimierung der Datenübertragung NVLink → RDMA
- Bietet hohen Durchsatz, geeignet für Training und Inference-Prefilling
- Enthält einen RDMA-spezifischen Low-Latency-Kernel für latenzsensitive Inference-Decodierung
- Bietet Communication-Compute-Overlap-Techniken (belegen keine SM-Ressourcen)
Leistung
Allgemeiner Kernel (NVLink- und RDMA-Übertragung)
- DeepEP hat die Leistung in einer Umgebung mit H800-GPUs und einem CX7 InfiniBand 400Gb/s RDMA-Netzwerk getestet
- Basierend auf der DeepSeek-V3/R1-Konfiguration wurden 4096 Tokens pro Batch, 7168 Hidden Nodes, eine Top-4-Gruppen- und Top-8-Experten-Struktur sowie FP8-Dispatching und BF16-Combine verwendet
- Die Leistungstests zeigten, dass die Kommunikation innerhalb eines Knotens (auf NVLink-Basis) eine Bandbreite von mehr als etwa 150GB/s erreichte, während die Kommunikation zwischen Knoten (auf RDMA-Basis) je nach Anzahl der Experten eine Bandbreite von 40–47GB/s verzeichnete
- Mit steigender Anzahl von Experten nahm die RDMA-Bandbreite tendenziell leicht zu (z. B. 43GB/s bei 16 Experten, 46GB/s bei 64 Experten)
Low-Latency-Kernel (reines RDMA)
- Die Messung der Leistung des Low-Latency-Kernels zeigte, dass die Latenz gegenüber dem allgemeinen Kernel deutlich reduziert wurde
- In einer Umgebung mit 128 Tokens pro Batch stieg die Latenz mit der Anzahl der Experten, während die RDMA-Bandbreite vergleichsweise konstant blieb
- Zum Beispiel stieg sie von 163 Mikrosekunden (us) bei 8 Experten auf 194 Mikrosekunden (us) bei 256 Experten
- Bei der Combine-Operation trat eine höhere Latenz als beim Dispatch auf, und mit zunehmender Expertenzahl zeigte die RDMA-Bandbreite die Tendenz, schrittweise auf unter 40GB/s zu sinken
- Das heißt, der Low-Latency-Kernel arbeitet bei kleinen Expertengruppen sehr schnell, aber mit steigender Expertenzahl nimmt die Latenz zu, sodass ein angemessenes Gleichgewicht erforderlich ist
Netzwerkkonfiguration
Traffic Isolation
- Mithilfe der Virtual Lanes (VL) von InfiniBand lässt sich Traffic isolieren
- Empfohlene Trennung:
- Workloads mit allgemeinem Kernel
- Workloads mit Low-Latency-Kernel
- Sonstige Workloads
- Die VL kann über die Umgebungsvariable
NVSHMEM_IB_SL konfiguriert werden
Adaptive Routing
- Unterstützt Adaptive Routing auf InfiniBand-Switches
- Kann beim Low-Latency-Kernel aktiviert werden, muss beim allgemeinen Kernel jedoch deaktiviert bleiben (bei Aktivierung besteht das Risiko von Datenkorruption)
- Empfohlene Konfiguration:
- Bei hoher Netzwerkauslastung: Adaptive Routing aktivieren
- Bei niedriger Netzwerkauslastung: statisches Routing beibehalten
Congestion Control
- DeepEP wird mit deaktivierter Congestion Control betrieben
- Es wurde bestätigt, dass Netzwerkkongestion in realen Umgebungen kein ernsthaftes Problem darstellt
Wichtige technische Überlegungen
- Verwendung inoffizieller PTX-Instruktionen: Zur Leistungsoptimierung wird
ld.global.nc.L1::no_allocate.L2::256B eingesetzt
- Auf der Hopper-Architektur funktioniert dies normal, auf anderen Plattformen kann es mit
DISABLE_AGGRESSIVE_PTX_INSTRS=1 deaktiviert werden
- Auto-Tuning empfohlen: Für optimale Leistung sollten nach clusterbezogenen Leistungstests geeignete Einstellungen angewendet werden
Noch keine Kommentare.