View a markdown version of this page

Gérez le calcul accéléré pour les AI/ML charges de travail sur Amazon EKS - Amazon EKS

Aidez à améliorer cette page

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

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.

Gérez le calcul accéléré pour les AI/ML charges de travail sur Amazon EKS

Astuce

Inscrivez-vous aux prochains AI/ML ateliers Amazon EKS.

Cette section explique comment acheter et provisionner des instances de calcul accéléré EC2 pour les charges de travail de AI/ML formation et d'inférence avec Amazon EKS. Que vous entraîniez des modèles à grande échelle, que vous exécutiez des inférences en temps réel ou que vous déployiez des applications d'intelligence artificielle génératives, l'utilisation du bon GPU NVIDIA ou de la bonne capacité AWS Trainium est essentielle à la performance de vos charges de travail.

Choisissez parmi les types d'instances EC2

Consultez les spécifications relatives aux instances de calcul accéléré Amazon EC2 pour plus de détails sur les instances de calcul accéléré Amazon EC2 disponibles. Il s'agit notamment des instances de GPU NVIDIA provenant du P-family et G-family, ainsi que des accélérateurs AWS conçus par Trainium et Inferentia.

Comprendre les options d'achat d'EC2

Une fois que vous connaissez les instances accélérées dont vous avez besoin pour vos charges de travail, l'étape suivante consiste à comprendre les options d'achat disponibles pour acquérir ces types d'instances accélérées. AWS propose quatre options d'achat de capacité de calcul : On-Demand instances, instances ponctuelles, blocs de capacité pour le ML et réservations de On-Demand capacité (ODCR). Chaque option répond à des modèles de charge de travail, à des profils de coûts et à des exigences de disponibilité différents. La documentation sur les options d'achat d'instances Amazon EC2 explique le fonctionnement de chaque option, son modèle de tarification et les circonstances dans lesquelles l'utiliser.

  • On-Demand Instances : Payez à la seconde sans engagement et avec disponibilité immédiate lorsque la capacité est disponible. Idéal pour le développement, le prototypage, la mise à l'échelle imprévisible des inférences et toute charge de travail nécessitant un calcul immédiat sans risque d'interruption.

  • Instances ponctuelles : jusqu'à 90 % d'économies On-Demand par rapport à l'utilisation de capacité EC2 inutilisée, avec un préavis d'interruption de 2 minutes. Idéal pour les charges de travail tolérantes aux pannes qui nécessitent un stockage durable : réglage des hyperparamètres, formation distribuée avec points de contrôle périodiques, inférence par lots et hors ligne, et pipelines de prétraitement des données.

  • Blocs de capacité pour ML : instances Reserve P-family et Trainium pour une période fixe (24 heures, jusqu'à 6 mois), réservées jusqu'à 8 semaines à l'avance avec disponibilité garantie. Idéal pour les sessions de formation planifiées à grande échelle, les expériences de mise au point limitées dans le temps et les projets de recherche dont les délais sont connus et qui nécessitent un accès ininterrompu à un cluster de GPU.

  • On-Demand Réservations de capacité (ODCR) : réservez de la capacité accélérée dans une zone de disponibilité spécifique sans engagement à long terme, facturée aux On-Demand tarifs standard, que la capacité soit utilisée ou non. Idéal pour l'inférence de production, les SLA-bound services et les applications critiques pour lesquelles les retards de planification ou l'indisponibilité des capacités sont inacceptables. Contrairement aux blocs de capacité, les ODCR prennent en charge à la fois les instances P-family et les instances G-family .

Adaptez les options d'achat aux exigences de charge de travail

Maintenant que vous comprenez les types d'instances accélérés et les options d'achat, l'étape suivante consiste à choisir l'option d'achat adaptée aux exigences spécifiques de votre charge de travail. Les charges de travail offrant une plus grande flexibilité selon les types d'instances, les régions et le calendrier peuvent bénéficier d'un plus grand nombre d'options d'achat et de tarifs plus bas.

Fondez votre décision sur des facteurs tels que :

  • Importance stratégique et engagements en matière de SLA

  • Prévisibilité de la demande et flexibilité de planification

  • Volonté de s'engager à l'avance à utiliser les capacités réservées

  • Flexibilité entre les types d'instances, les régions et le calendrier

  • Tolérance aux interruptions par rapport aux économies

Dans la pratique, les équipes adoptent une approche hybride qui combine plusieurs options d'achat pour équilibrer les coûts, la disponibilité et la fiabilité dans l'ensemble de leur portefeuille de charges de travail. L'article How to Get GPU Capacity on AWS fournit un arbre décisionnel, des comparaisons de prix et des exemples concrets pour sélectionner la bonne option d'achat pour différents types de charges de travail.

Vérifiez vos quotas de service EC2

Avant d'implémenter une option d'achat de capacité sur votre cluster EKS, vérifiez que votre AWS compte dispose d'un quota de vCPU suffisant pour les familles d'instances de GPU que vous prévoyez d'utiliser. Sans quotas adéquats, Karpenter NodePools, le provisionnement en mode automatique d'EKS et les groupes de nœuds EKS ne pourront pas lancer de nœuds de calcul accéléré, quelle que soit l'option d'achat sélectionnée.

AWS applique des quotas de vCPU distincts par famille d'instances et par modèle d'achat. Consultez les quotas de type d'instance Amazon EC2 pour comprendre les quotas par défaut pour les instances de calcul accéléré.

Ces quotas sont basés sur le nombre de vCPU, et non sur le nombre d'instances. Par exemple, le lancement de 10 instances p6-b300.48xlarge nécessite 1 920 vCPU (10 × 192). Les quotas GPU par défaut étant souvent définis à 0 pour les nouveaux comptes, demandez des augmentations avant de tenter de déployer des instances.

Si vous êtes confronté à des limites de quotas lors de la création de réservations de blocs de capacité, du lancement d' On-Demand instances ou de la soumission de demandes ponctuelles, contactez le AWS Support ou l'équipe chargée de votre AWS compte pour discuter de vos besoins et explorer les options permettant de garantir la capacité de calcul accélérée la mieux adaptée à vos besoins.

Utiliser les options d'achat EC2 avec Amazon EKS

Après avoir sélectionné une option d'achat de calcul accéléré EC2, configurez votre cluster Amazon EKS pour utiliser la capacité. Amazon EKS propose trois méthodes de provisionnement, chacune offrant un équilibre différent entre contrôle et automatisation :

  • Amazon EKS Auto Mode : calcul AWS géré qui provisionne, redimensionne et corrige automatiquement les nœuds. Utilise le système Karpenter intégré pour le provisionnement et le système d'exploitation Bottlerocket avec pilotes NVIDIA et plug-ins de périphérique inclus. Idéal lorsque vous souhaitez une infrastructure gérée avec des frais d'exploitation minimaux. Prend en charge le provisionnement de capacité statique et dynamique.

  • Karpenter (autogéré) : projet open source en amont que vous installez et gérez dans votre cluster Amazon EKS. Fournit le même modèle de provisionnement que le mode automatique EKS et vous avez un contrôle total sur le système d'exploitation, les AMI, le réglage du noyau et le cycle de vie des nœuds. Idéal pour les équipes de plateforme ayant des exigences auxquelles le mode automatique d'EKS ne répond pas immédiatement.

  • Groupes de nœuds (gérés et autogérés) : Soutenus par EC2 Auto Scaling Groups (ASG), la capacité est définie à l'avance via un modèle de lancement EC2. Idéal pour les équipes de plateforme disposant de groupes de nœuds gérés ou autogérés par EKS existants, et pour les charges de travail de formation avec un dimensionnement prévisible avec une empreinte de calcul accélérée statique connue.

Les pages ci-dessous décrivent en détail chaque option de provisionnement.

Stratégie mixte : combiner les options d'achat

Il est courant de combiner plusieurs options d'achat de capacité au sein d'un même cluster Amazon EKS. Cette approche optimise simultanément les coûts, la disponibilité et la fiabilité en acheminant différentes charges de travail vers la source de capacité la plus appropriée. Les clients mettent en œuvre cette stratégie hybride en utilisant l'une des trois approches de gestion informatique d'EKS (EKS Auto Mode, Karpenter ou Node Groups) ou en les combinant au sein d'un même cluster.

EKS Auto Mode et Karpenter fournissent toujours la capacité réservée (ODCR et blocs de capacité) en premier, suivie de Spot or. On-Demand Vous pouvez associer cette priorité de provisionnement des instances à la planification de vos charges de travail critiques sur la base d'une capacité garantie, tout en planifiant des charges de travail flexibles sur Spot ou sur des instances. On-Demand Vous contrôlez le routage des charges de travail par le biais de primitives de Kubernetes-native planification : nodeSelector cible un type de capacité spécifique, les contraintes et les tolérances isolent les GPU NVIDIA ou les nœuds AWS Trainium, et topologySpreadConstraints répartissez les charges de travail entre les zones de disponibilité pour une haute disponibilité.

Un cluster Amazon EKS bien conçu organise le calcul accéléré NodePools ou les groupes de nœuds en deux catégories, Reserved et Burst, chacune alignée sur les modèles de charge de travail les mieux adaptés à la stratégie de capacité. Un exemple est décrit ci-dessous.

Réservé (capacité garantie)

Un gpu-reserved NodePool ou un groupe de nœuds exécute l'inférence de production et planifie une formation à grande échelle sur la capacité réservée (ODCR et blocs de capacité), garantissant ainsi la disponibilité des SLA-bound services et planifiant des tâches gourmandes en ressources informatiques. Ce groupe NodePool ou groupe de nœuds sert les points de terminaison d'inférence en temps réel, le service de modèles de production, les applications critiques nécessitant une disponibilité permanente du GPU avec des performances prévisibles, des formations distribuées planifiées, des expériences de réglage fin à grande échelle, des projets de recherche limités dans le temps et toute charge de travail dont vous connaissez l'heure de début et la durée à l'avance.

Burst (capacité élastique)

Un gpu-burst NodePool ou un groupe de nœuds exécute l'expérimentation, les charges de travail ad hoc et le traitement par lots en utilisant les instances Spot comme principal type de capacité avec On-Demand solution de secours, ce qui maximise les économies de coûts pour les charges de travail tolérantes aux pannes tout en garantissant la capacité lorsque le Spot n'est pas disponible. Ce NodePool groupe de nœuds sert à l'inférence par lots hors ligne, aux pipelines de prétraitement des données, aux tâches d'évaluation de modèles, au développement et au prototypage, à la mise à l'échelle imprévisible des inférences, aux sessions de débogage de courte durée et à toute charge de travail qui implémente le point de contrôle et peut gérer des interruptions ponctuelles ou qui ne justifie pas une réservation mais ne peut pas attendre les fenêtres réservées. Les charges de travail sur ce nœud NodePool ou sur ce groupe de nœuds mettent en œuvre le point de contrôle et l'arrêt progressif pour gérer la perte de nœuds dans le délai d'interruption ponctuelle de 2 minutes.

Le type de capacité souhaité pour les charges de travail est spécifié à l'aide de NodeSelector : karpenter.sh/capacity-type: spot (ou à la demande, réservé), et le provisionnement basé sur le poids garantit que le cluster évolue efficacement sur tous les pools de capacité. Cette architecture donne aux équipes la flexibilité nécessaire pour exécuter diverses AI/ML charges de travail, des ordinateurs portables expérimentaux aux inférences de production, au sein d'un seul cluster EKS, tout en optimisant les coûts.