Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Mise en réseau
Astuce
Inscrivez-vous
Envisagez une bande passante réseau plus élevée ou un adaptateur Elastic Fabric pour les applications à haute Inter-Node communication
Pour les charges de travail de formation distribuées sur Amazon EKS nécessitant des communications inter-nœuds élevées, pensez à sélectionner des instances dotées d'une bande passante réseau plus élevée ou à choisir Elastic Fabric Adapter (EFA). Des performances réseau insuffisantes peuvent entraver le transfert de données, ralentissant ainsi les tâches d'apprentissage automatique telles que la formation distribuée multi-GPU. Notez que les charges de travail d'inférence ne présentent généralement pas un niveau élevé de communication entre les nœuds.
Assurez-vous que votre image de conteneur inclut NCCL et le plugin aws-ofi-nccl
Considérations relatives au provisionnement des nœuds pour les charges de travail EFA
Lors du provisionnement EFA-capable des nœuds, les instances qui doivent communiquer doivent se trouver dans la même zone de disponibilité (exigence stricte). En outre, AWS recommande de lancer toutes les EFA-enabled instances dans un groupe de placement de clusters afin de minimiser la distance physique entre elles au sein d'une seule zone de disponibilité, ce qui vous permet de réduire la latence la plus faible possible. Un groupe de placement n'est pas nécessaire au fonctionnement de l'EFA, mais il est fortement recommandé pour des performances optimales.
Les considérations suivantes s'appliquent à tout déploiement de formation EFA-based distribuée sur EKS. Ci-dessous, nous citons les annotations Karpenter à titre d'exemple, mais les mêmes considérations peuvent également être appliquées aux implémentations de groupes gérés et de groupes de Self-managed nœuds.
-
Épinglez à un AZ. L'EFA exige que tous les nœuds communicants se trouvent dans la même zone de disponibilité. Ainsi, par exemple, les nœuds participant à la même tâche de formation distribuée ne doivent pas être répartis entre les zones. Vous pouvez appliquer cela en épinglant le Pod à un AZ en utilisant a
nodeSelectorou Pod Affinity activétopology.kubernetes.io/zone. Sélectionnez la zone de disponibilité dans laquelle votre type d'instance cible présente la meilleure disponibilité ou dans laquelle votre bloc de capacité est réservé. Sachez que si la colocation sur le même AZ améliore la latence entre les nœuds, elle augmente également le rayon d'explosion d'une panne. AZ-level Pour les charges de travail de formation de longue durée, une seule panne AZ ou un seul événement de capacité peut anéantir des heures de progression de formation accumulées, ce qui représente une perte coûteuse. Tenez-en compte dans votre stratégie de contrôle et dans la planification de la durée du travail. -
Configurez le groupe de placement du cluster (recommandé). Spécifiez le groupe de placement dans le EC2NodeClass. Karpenter s'y approvisionne automatiquement. Ceci est recommandé pour une latence optimale mais n'est pas strictement nécessaire au fonctionnement de l'EFA. Pour Capacity Blocks for ML, le placement est géré automatiquement via UltraClusters : aucun groupe de placement manuel n'est nécessaire. Notez que, dans ce cas, l'AZ est déjà verrouillée et que, par conséquent, aucune restriction supplémentaire Pod-level ou NodePool-level AZ n'est nécessaire.
-
Empêchez l'interruption des tâches de formation sur plusieurs nœuds. Utilisez des PDB ou des
karpenter.sh/do-not-disrupt: "true"annotations sur les modules d'entraînement. Dans le cas contraire, la consolidation de Karpenter pourrait tenter de remplacer ou de déplacer les charges de travail EFA en cours de travail, perturbant ainsi l'ensemble du cycle de formation distribué.consolidationPolicy: WhenEmptyActivez cette option NodePool pour empêcher la consolidation des nœuds occupés. Passez en revue l'interaction entre ces étiquettes etterminationGracePeriodetexpireAfterici. -
Définissez une date d'expiration appropriée. Configurez
expireAftersur une valeur supérieure NodePool à votre tâche d'entraînement la plus longue, ou désactivez-la NodePools complètement pour l'entraînement. Un nœud expirant en cours d'entraînement met fin à la tâche. -
Utilisez la bonne version du plug-in de l'appareil EFA. Le plug-in de périphérique EFA
s'expose vpc.amazonaws.com/efaen tant que ressource planifiable. -
Configurez les groupes de sécurité. Toutes les instances EFA doivent appartenir au même groupe de sécurité avec une règle d'autoréférencement autorisant TOUT le trafic to/from lui-même. Sans cela, le trafic EFA échoue silencieusement.
Comprenez les risques liés aux instances Spot grâce à la colocation EFA
Les instances Spot Amazon EC2 permettent de réaliser d'importantes économies sur les charges de travail de formation (consultez cette section pour les meilleures pratiques Spot générales relatives aux GPU). Cependant, EFA exige que tous les nœuds de communication résident dans la même zone de disponibilité, et AWS recommande de les placer dans un groupe de placement en cluster pour une latence optimale. Cette colocation introduit un risque d'interruption corrélé : les instances partagent l'infrastructure physique sous-jacente au sein de la même zone de disponibilité (et plus encore au sein d'un groupe de placement), de sorte qu'un seul événement de récupération de capacité peut affecter plusieurs instances simultanément, interrompant potentiellement l'intégralité de votre tâche de formation multi-nœuds en une seule fois plutôt qu'un seul nœud.
Cela est fondamentalement différent de l'utilisation de Spot sans contraintes EFA, où les nœuds peuvent être répartis entre les zones de disponibilité et les interruptions sont statistiquement indépendantes. Avec l'exigence d'EFA en matière de même AZ, un seul événement de capacité peut se répercuter sur votre cluster d'entraînement.
Si vous souhaitez réaliser des économies sur les charges de travail liées à l'entraînement des GPU, assurez-vous d'avoir évalué toutes les options d'achat disponibles avant de vous engager dans Spot. Les instances réservées, les réservations de On-Demand capacité (ODCR), les plans d'économies et les blocs de capacité pour le ML peuvent tous offrir des remises importantes tout en garantissant la disponibilité des capacités, évitant ainsi le risque d'interruption corrélé inhérent aux contraintes de colocation entre Spot et EFA.
Planification de la consommation d'adresses IP sur les instances GPU de grande taille
Par défaut, le plug-in Amazon VPC CNI préalloue les adresses IP pour garantir que les pods peuvent être planifiés rapidement, en conservant un ENI de rechange complet connecté et rempli d'adresses IP. Sur les grandes instances, cela peut entraîner la réservation de dizaines d'adresses IP par nœud, même lorsque seuls quelques pods sont en cours d'exécution.
Ce décalage est courant dans les charges de travail d'entraînement et d'inférence où la densité de pods par nœud est faible. À l'échelle du cluster, en particulier lors d'événements de dimensionnement automatique qui font tourner de nombreux nœuds GPU avec peu de pods chacun, cela peut entraîner l'épuisement des adresses IP des sous-réseaux même si l'utilisation réelle des adresses IP est faible.
Pour atténuer ce problème, réglez les WARM_ENI_TARGET variables WARM_IP_TARGETMINIMUM_IP_TARGET, et pour qu'elles correspondent à la densité réelle de votre capsule. Plus d'informations sur les paramètres cibles ENI et IP de VPC CNI.
Pour un guide complet sur l'optimisation de la consommation IP, voir Optimisation de l'utilisation des adresses IP.
