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 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 des AI/ML charges de travail avec EKS Auto Mode et Karpenter
Astuce
Inscrivez-vous
Cette section explique comment gérer le calcul accéléré (AWS Trainium, GPU NVIDIA) pour la formation à l'IA et les charges de travail d'inférence à l'aide du mode automatique Amazon EKS ou de Karpenter autogéré.
EKS Auto Mode et Karpenter prennent en charge deux modes de provisionnement : le provisionnement dynamique et le provisionnement statique. Grâce au provisionnement dynamique, EKS Auto Mode et Karpenter provisionnent et dimensionnent des instances de calcul accélérées au fur et à mesure que les charges de travail sont planifiées sur le cluster. Avec le provisionnement statique, EKS Auto Mode et Karpenter provisionnent et gèrent un nombre fixe de nœuds. Le provisionnement dynamique et statique peut être utilisé dans le même cluster pour maintenir un pool de capacité de référence constant tout en s'adaptant aux demandes de charge de travail.
EKS Auto Mode et Karpenter prennent en charge les quatre options d'achat de capacité (SpotOn-Demand, Capacity Blocks et ODCR) et provisionnent toujours la capacité réservée en premier, suivie de Spot ou. On-Demand
EKS Auto Mode contre Karpenter
Les deux approches partagent l' NodePool API, mais elles diffèrent en termes de propriété opérationnelle, d'API de ressources, de prise en charge du système d'exploitation, de gestion des interruptions ponctuelles et de flexibilité de configuration.
| Fonctionnalité | Mode automatique EKS | Self-managed Charpentier |
|---|---|---|
|
Idéal pour |
Les équipes qui préfèrent une infrastructure gérée avec un minimum de frais opérationnels |
Les équipes qui préfèrent un contrôle total sur le cycle de vie des nœuds, les AMI, le réglage du système d'exploitation et l'application de correctifs. |
|
Modèle opérationnel |
AWS fournit et gère le contrôleur Karpenter, GPU/Trainium les pilotes, les plug-ins de périphériques, les correctifs du système d'exploitation et la gestion des interruptions ponctuelles. |
Vous installez et utilisez le contrôleur Karpenter dans votre cluster et vous êtes propriétaire des GPU/Trainium pilotes, des plug-ins de périphériques, du cycle de vie de l'AMI, des correctifs et de la gestion des interruptions ponctuelles. |
|
Options de calcul |
On-Demand, Spot, ODCR, blocs de capacité pour ML |
On-Demand, Spot, ODCR, blocs de capacité pour ML |
|
API de ressources |
|
|
|
Système d'exploitation Node |
Bottlerocket uniquement. Dépendances GPU NVIDIA, AWS Trainium et EFA incluses. |
AL2023, Bottlerocket, Windows ou votre propre AMI. |
|
Durée de vie du nœud |
Durée de vie maximale des nœuds de 21 jours pour les correctifs de sécurité. Les charges de travail doivent tolérer la rotation des nœuds. |
Vous définissez le cycle de vie des nœuds NodePool |
|
Gestion des interruptions ponctuelles |
Autochtone. Aucune file d'attente SQS ni aucun gestionnaire de terminaison de nœud n'est requis. |
Il est de votre responsabilité de configurer et d'activer. |
|
Tirage rapide des conteneurs |
Pull parallèle SOCI inclus dans toutes les instances des familles G, P et Trn |
Il est de votre responsabilité de configurer et d'activer. |
|
Groupes de placement EC2 |
Cluster, partitionner, étaler |
Cluster, partitionner, étaler |
|
Configuration de l'interface réseau |
Configuration par interface pour le type |
Configuration par interface pour le type |
|
Réparation de nœuds |
Activé par défaut, agent de surveillance des nœuds EKS inclus |
Activé en option, agent de surveillance des nœuds EKS autogéré |
|
Tarification |
Frais de gestion du mode automatique EKS |
Open source. Vous payez pour les instances EC2 sous-jacentes. |
Étiquettes courantes et AI/ML bien connues
EKS Auto Mode et Karpenter présentent des étiquettes d'instance que vous pouvez utiliser dans un Pod nodeSelector ou nodeAffinity pour cibler NodePool requirements des charges de travail sans coder en dur les types d'instances. Le préfixe de l'étiquette diffère entre les deux : le mode EKS Auto est utilisé eks.amazonaws.com/ alors que Karpenter utilise le mode autogéré. karpenter.k8s.aws/
Les tableaux ci-dessous présentent les étiquettes pertinentes qui peuvent être utilisées dans NodePools. EKS Auto Mode et Karpenter appliquent également les étiquettes répertoriées dans la documentation Karpenter
Étiquettes de planification pour la capacité réservée
Lorsque EKS Auto Mode ou Karpenter lance un nœud dans une réservation, il ajoute les libellés suivants. Utilisez-les dansnodeSelector, l'affinité des nœuds ou les NodePool exigences pour acheminer les charges de travail.
-
karpenter.sh/capacity-type:reserved,on-demand, ouspot. Indique la capacité supportant le nœud. -
karpenter.k8s.aws/capacity-reservation-id: ID de réservation spécifique sur lequel le nœud a été lancé. -
karpenter.k8s.aws/capacity-reservation-type:defaultpour les ODCR,capacity-blockpour les blocs de capacité.
Les exemples suivants présentent des modèles de planification courants :
Associez un Pod à une réservation spécifique (pas de solution de rechange) :
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"
Nœuds ODCR cibles uniquement (n'importe quel ODCR, pas les blocs de capacité) :
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default
Ciblez n'importe quelle capacité réservée (ODCR ou bloc de capacité) :
spec: nodeSelector: karpenter.sh/capacity-type: reserved
Préférez la réservation mais revenez à Spot ou, en On-Demand cas d'indisponibilité :
spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]
Comportement d'expiration des réservations
Les ODCR et les blocs de capacité se comportent différemment à la fin de la réservation. Assurez-vous que votre stratégie de planification et de contrôle correspond au type de réservation correspondant à votre charge de travail.
ODCR
Une instance lancée dans un ODCR n'y figure pas indéfiniment. L'ODCR peut expirer, être annulé ou l'instance peut être supprimée manuellement de l'ODCR. Si l'un de ces problèmes se produit et que EKS Auto Mode/Karpenter détecte que l'instance n'appartient plus à un ODCR, il met à jour l'karpenter.sh/capacity-typeétiquette du nœud de àreserved. on-demand L'instance continue de fonctionner à On-Demand capacité standard et les pods existants continuent de fonctionner sans interruption.
Note
Tout pod programmé avec un strict ne nodeSelector: karpenter.sh/capacity-type: reserved sera pas programmé sur le nœud s'il a été renommé. Pour que les charges de travail survivent à l'expiration ou à l'annulation de l'ODCR, utilisez le preferredDuringSchedulingIgnoredDuringExecution schéma ci-dessus au lieu d'un. nodeSelector
Blocs de capacité
Contrairement aux ODCR, les blocs de capacité ont toujours une heure de fin, et EC2 met fin aux instances de blocs de capacité 30 minutes avant l'heure de fin (60 minutes pour UltraServer les types d'instances). Planifiez les tâches de formation et d'inférence à terminer ou à enregistrer avant la fermeture de la fenêtre de réservation. Les pods qui utilisent un strict nodeSelector pour une utilisation spécifique une capacity-reservation-id Pending fois le blocage expiré et qui ne seront pas reprogrammés ailleurs. Combinez le point de contrôle avec le modèle d'affinité flexible ci-dessus si vous avez besoin de déplacer des charges de travail vers une autre capacité pendant l'expiration du bloc de capacité.
-
Vous pouvez utiliser des instances réservées jusqu'à 30 minutes avant l'heure de fin du bloc de capacité pour la plupart des types d'instances, ou 60 minutes avant l'heure de fin pour les types d' UltraServer instances.
-
EKS Auto Mode et Karpenter commencent à vider de manière préventive les nœuds d'un bloc de capacité 10 minutes avant la fin de l'EC2, afin que les charges de travail aient le temps de passer au point de contrôle et de s'arrêter correctement.
Capacité statique NodePools
EKS Auto Mode et Karpenter prennent en charge la capacité statique NodePools, qui permet de maintenir un nombre fixe de nœuds indépendamment de la charge de travail. Les pools statiques éliminent les délais de démarrage à froid pour les inférences sensibles à la latence et vous permettent de réserver une empreinte d'infrastructure minimale pour votre cluster.
La capacité statique est configurée en définissant le replicas champ sur le NodePool.
Considérations
-
Une fois qu'
replicasil est défini sur a NodePool, vous ne pouvez pas le supprimer. Un seul utilisateur NodePool ne peut pas basculer entre le provisionnement de capacité statique et dynamique. -
La capacité statique n' NodePools est pas prise en compte pour la consolidation. Définissez
limits.nodesci-dessusreplicaspour autoriser une mise à l'échelle temporaire lors de la dérive ou de l'expiration de l'AMI. -
Pour une distribution prévisible des zones de disponibilité (AZ), créez une capacité statique NodePool par zone de disponibilité plutôt que de couvrir plusieurs zones dans un seul pool.
Blocs de capacité pour ML
Les blocs de capacité pour le machine learning vous permettent de réserver P-family des instances et des instances Trainium pour une période future définie. Ils sont prépayés, donc EKS Auto Mode et Karpenter les modélisent comme étant gratuits et les priorisent par rapport On-Demand à Spot. Les blocs de capacité pour ML peuvent avoir une durée de réservation de 1 à 14 jours ou un multiple de 7 jours, jusqu'à 182 jours (6 mois).
Pour utiliser Capacity Blocks for ML avec EKS Auto Mode ou Karpenter, configurez capacityReservationSelectorTerms avec votre identifiant de réservation de capacité dans votre NodeClass. Vous ne pouvez pas utiliser la correspondance de réservation ouverte avec les blocs de capacité pour le ML. Un terme peut spécifier un identifiant, un ensemble de balises ou des critères de correspondance d'instance à sélectionner. Lors de la spécification des tags, il sélectionnera toutes les réservations de capacité accessibles depuis le compte avec les tags correspondants. Cela peut être encore restreint en spécifiant un identifiant de compte propriétaire.
Pour plus d'exemples, consultez la documentation https://karpenter.sh/docs/concepts/nodeclasses/#speccapacityreservationselectorterms
On-Demand Réservations de capacité (ODCR)
Les ODCR garantissent la capacité dans une zone de disponibilité (AZ) spécifique sans engagement à long terme. Vous êtes facturé aux On-Demand tarifs standard, que la capacité soit utilisée ou non. Les ODCR prennent en charge toutes les familles de GPU NVIDIA, y compris les G-family instances qui ne sont pas prises en charge par Capacity Blocks for ML. Les ODCR étant prépayés, EKS Auto Mode et Karpenter les modélisent comme étant gratuits et les priorisent par rapport à Spot. On-Demand
Les ODCR se comportent différemment des blocs de capacité pour le ML à la fin de la réservation. Lorsqu'un ODCR expire ou est annulé, l'instance continue de fonctionner en standard On-Demand. Consultez Comportement d'expiration des réservations pour plus de détails.
Pour utiliser les ODCR avec EKS Auto Mode ou Karpenter, configurez les conditions capacityReservationSelectorTerms de réservation de capacité dans votre. NodeClass Un terme peut spécifier un identifiant, un ensemble de balises ou des critères de correspondance d'instance à sélectionner. Lors de la spécification des tags, il sélectionnera toutes les réservations de capacité accessibles depuis le compte avec les tags correspondants. Lors de la spécification des critères de correspondance des instances, elle sélectionne les réservations en fonction de leur comportement correspondant : ouvert (correspond à toutes les instances compatibles) ou ciblé (correspond uniquement aux instances explicitement ciblées). Cela peut être encore restreint en spécifiant un identifiant de compte propriétaire.
Pour plus d'exemples, consultez la documentation https://karpenter.sh/docs/concepts/nodeclasses/#speccapacityreservationselectorterms
On-Demand
On-Demand est le type de capacité par défaut et peut être utilisé avec un provisionnement statique ou dynamique dans EKS Auto Mode et Karpenter. Vous pouvez demander explicitement On-Demand des instances karpenter.sh/capacity-type: on-demand en paramétrant votre NodePool. EKS Auto Mode et Karpenter sélectionnent l'instance la moins chère qui répond aux demandes de ressources du Pod. On-Demand À utiliser pour le développement, le prototypage, la mise à l'échelle d'inférence imprévisible et toute charge de travail nécessitant une disponibilité immédiate sans risque d'interruption.
Spot
Spot permet de réaliser jusqu'à 90 % d'économies On-Demand par rapport à l'utilisation d'une capacité EC2 de rechange. AWS peut récupérer des instances Spot avec un préavis d'interruption de 2 minutes. Optimisez la disponibilité en répertoriant plusieurs familles d'instances sur le NodePool. Associez les charges de travail Spot à un point de contrôle PodDisruptionBudget et à un stockage durable (Amazon S3 ou Amazon EFS) à intervalles réguliers afin que les Pods puissent enregistrer leur état pendant la période de vidange.
Spot convient parfaitement aux charges de travail de formation et d'inférence tolérantes aux pannes et pouvant être reprises, pour lesquelles des interruptions occasionnelles sont acceptables en échange de réductions de coûts importantes.
Les candidats les plus courants sont les suivants :
-
Réglage et balayage des hyperparamètres : de nombreux essais courts et parallèles qui peuvent être réessayés s'ils sont interrompus.
-
Formation distribuée avec points de contrôle : tâches de longue durée qui enregistrent périodiquement l'état dans S3 ou FSx et peuvent reprendre à partir du dernier point de contrôle après la perte d'un nœud.
-
Inférence par lots et hors ligne : tâches de notation à grande échelle par rapport à des ensembles de données où la latence de bout en bout est mesurée en heures et non en secondes.
-
Prétraitement des données et pipelines d'ingénierie des fonctionnalités : transformations parallèles sur de grands ensembles de données.
-
Évaluation et analyse comparative des modèles : tâches répétables qui produisent des résultats idempotents.
-
Développement, prototypage et blocs-notes : expérimentation interactive où les utilisateurs peuvent tolérer des redémarrages occasionnels.
Évitez Spot pour les inférences en temps réel sensibles à la latence, les points de terminaison SLA-bound de production et les charges de travail qui ne sont pas contrôlées ou ne peuvent tolérer les redémarrages.
Vous pouvez demander explicitement des instances Spot karpenter.sh/capacity-type: spot en paramétrant votre NodePool.