- Stratégies et codes utilisés dans DeepSeek V3/R1
- DualPipe : algorithme de parallélisme en pipeline bidirectionnel pour le chevauchement calcul-communication
- EPLB : équilibreur de charge pour le parallélisme d’experts
- Profile-Data : analyse du chevauchement calcul-communication à partir des données de profiling de l’infrastructure DeepSeek
- DualPipe est un algorithme innovant de parallélisme en pipeline bidirectionnel présenté dans le DeepSeek-V3 Technical Report
- Il réduit les bulles de pipeline en chevauchant complètement les étapes de calcul-communication en propagation avant et arrière
- Des informations plus détaillées sur le chevauchement calcul-communication sont disponibles dans les profile data
- Dans l’Expert Parallelism (EP), différents experts sont attribués à chaque GPU
- Cependant, comme la charge de travail peut varier d’un expert à l’autre, il est important d’équilibrer la charge entre les GPU
- Dans DeepSeek-V3, une stratégie d’experts redondants (redundant experts) est utilisée pour répliquer les experts les plus chargés, puis les placer efficacement sur les GPU afin d’équilibrer la charge
- En outre, le group-limited expert routing est utilisé pour placer autant que possible les experts d’un même groupe sur le même nœud, afin de minimiser les transferts de données entre nœuds
- Pour faciliter la reproduction et le déploiement, l’algorithme d’équilibrage de charge EP est publié en open source dans
eplb.py
- Cet algorithme calcule un plan équilibré de réplication et de placement des experts à partir de la charge prévue pour chaque expert
- En revanche, la méthode précise de prédiction de la charge des experts sort du périmètre de ce dépôt ; en pratique, on utilise souvent une moyenne mobile fondée sur les statistiques passées
- L’algorithme d’équilibrage de charge propose deux politiques, chacune adaptée à des situations différentes.
- Équilibrage de charge hiérarchique (Hierarchical Load Balancing)
- Lorsque le nombre de nœuds serveur est divisible par le nombre de groupes d’experts, la politique d’équilibrage de charge hiérarchique est utilisée pour optimiser le group-limited expert routing
- D’abord, les groupes d’experts sont répartis uniformément entre les nœuds afin d’équilibrer la charge inter-nœuds
- Ensuite, les experts sont répliqués à l’intérieur de chaque nœud
- Enfin, les experts répliqués sont placés sur les GPU individuels afin d’équilibrer la charge entre GPU
- Cette politique peut être utilisée lors de l’étape de prefilling, où l’échelle du parallélisme d’experts est plus réduite
- Équilibrage de charge global (Global Load Balancing)
- Dans les autres cas, la politique d’équilibrage de charge global est utilisée pour répliquer les experts à l’échelle globale, indépendamment de leurs groupes, puis les placer sur les GPU individuels
- Cette politique convient à l’étape de decoding, où l’échelle du parallélisme d’experts est plus grande.
- DeepSeek publie des données de profiling issues de son framework d’entraînement et d’inférence afin d’aider la communauté à mieux comprendre les stratégies de chevauchement communication-calcul et les détails d’implémentation bas niveau
- Ces données de profiling ont été collectées à l’aide de PyTorch Profiler et, après téléchargement, peuvent être visualisées via
chrome://tracing dans Chrome ou edge://tracing dans Edge
- Les expérimentations ont également simulé une stratégie de routage MoE équilibrée lors du profiling
- Entraînement (Training)
- Les données de profiling d’entraînement montrent, dans DualPipe, la stratégie de chevauchement entre les chunks de propagation avant et arrière
- Chaque chunk comprend 4 couches MoE (Mixture of Experts) et adopte une configuration parallèle conforme aux réglages de pré-entraînement de DeepSeek-V3 :
- Inférence (Inference)
- Prefilling
- À cette étape, deux micro-batchs sont utilisés pour chevaucher le calcul et la communication all-to-all
- En outre, la charge des opérations d’attention est répartie de manière équilibrée entre les deux micro-batchs, afin qu’un même prompt puisse être divisé sur plusieurs micro-batchs
- Decoding
- En decoding aussi, comme en prefilling, deux micro-batchs sont utilisés pour chevaucher le calcul et la communication all-to-all
- Cependant, en decoding, la communication all-to-all n’occupe pas les GPU SM → elle libère les GPU SM après l’envoi des messages RDMA, puis attend la fin de la communication une fois le calcul terminé
- Plus de détails sur l’implémentation all-to-all sont disponibles dans DeepEP
Aucun commentaire pour le moment.