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.

Réseaux

Envisagez une bande passante réseau plus élevée ou un adaptateur Elastic Fabric pour les applications nécessitant une Inter-Node communication élevée

Pour les charges de travail de formation distribuées sur Amazon EKS nécessitant de fortes communications entre nœuds, pensez à sélectionner des instances dotées d'une bande passante réseau plus importante ou un adaptateur Elastic Fabric (EFA). Des performances réseau insuffisantes peuvent entraver le transfert de données et ralentir les tâches d'apprentissage automatique telles que la formation multiGPU distribuée. 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.

Exemple

Par exemple, en utilisant Karpenter :

apiVersion: v1
kind: Pod
metadata:
  name: ml-workload
spec:
  nodeSelector:
    karpenter.k8s.aws/instance-network-bandwidth: "100000"  # 100 Gbps in Mbps
    node.kubernetes.io/instance-type: p5.48xlarge  # EFA-enabled instance
  containers:
  - name: training-job
    image: `763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-inference:2.6.0-gpu-py312-cu124-ubuntu22.04-ec2-v1.6`
    resources:
      limits:
        vpc.amazonaws.com/efa: 1  # Requires EFA device plugin

Assurez-vous que des outils tels que MPI et NCCL sont installés dans l'image de votre conteneur afin de tirer parti de l'EFA pour les tâches de formation.

Planification de la consommation d'adresses IP sur les instances de GPU de grande taille

Par défaut, le plug-in Amazon VPC CNI préalloue les adresses IP pour garantir la planification rapide des pods, en gardant un ENI de rechange complet connecté et rempli d'adresses IP. Sur les instances de grande taille, 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.

Cette inadéquation est courante 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 mise à l'échelle 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, ajustez les WARM_ENI_TARGET variables WARM_IP_TARGETMINIMUM_IP_TARGET, et en fonction de la densité réelle de votre capsule. Plus d'informations sur les paramètres de cible ENI et IP du VPC CNI.

Pour un guide complet sur l'optimisation de la consommation IP, voir Optimisation de l'utilisation des adresses IP.