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 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 les charges de travail d'entraînement et d'inférence liées à l'IA à 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 fournissent et dimensionnent des instances de calcul accélérées à mesure que les charges de travail sont planifiées sur le cluster. Avec le provisionnement statique, EKS Auto Mode et Karpenter fournissent et maintiennent 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és de base 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 fournissent toujours la capacité réservée en premier, suivie de Spot or. On-Demand
EKS Auto Mode par rapport à Karpenter
Les deux approches partagent l' NodePool API, mais elles diffèrent en termes de propriété opérationnelle, d'API de ressources, de support 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 avoir un contrôle total sur le cycle de vie des nœuds, les AMI, le réglage du système d'exploitation et les correctifs. |
|
Modèle opérationnel |
AWS approvisionne et gère le contrôleur Karpenter, GPU/Trainium les pilotes, les plug-ins des appareils, les correctifs du système d'exploitation et la gestion des interruptions ponctuelles. |
Vous installez et utilisez le contrôleur Karpenter dans votre cluster, ainsi que vos propres GPU/Trainium pilotes, plug-ins de périphériques, cycle de vie des AMI, correctifs et gestion des interruptions ponctuelles. |
|
Options de calcul |
On-Demand, Spot, ODCRs, blocs de capacité pour ML |
On-Demand, Spot, ODCRs, blocs de capacité pour ML |
|
API de ressources |
|
|
|
Système d'exploitation Node |
Bottlerocket uniquement. Dépendances entre 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. |
|
Extraction rapide des conteneurs |
Le pull parallèle SOCI est 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, répartir |
Cluster, partitionner, répartir |
|
Configuration de l'interface réseau |
Non pris en charge |
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 connues
EKS Auto Mode et Karpenter présentent des étiquettes d'instance que vous pouvez utiliser dans NodePool requirements et Pod nodeSelector ou nodeAffinity pour cibler des charges de travail sans coder en dur les types d'instance. Le préfixe de l'étiquette diffère entre les deux : le mode automatique EKS l'utilise, eks.amazonaws.com/ tandis que Karpenter l'utilise en mode autogéré. karpenter.k8s.aws/
Les tableaux ci-dessous indiquent 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 de Karpenter
Étiquettes de planification pour la capacité réservée
Lorsqu'EKS Auto Mode ou Karpenter lance un nœud dans une réservation, il ajoute les libellés suivants. Utilisez-les dans l'nodeSelectoraffinité des nœuds ou les NodePool exigences pour acheminer les charges de travail.
-
karpenter.sh/capacity-type:reservedon-demand, ouspot. Indique la capacité qui soutient le nœud. -
karpenter.k8s.aws/capacity-reservation-id: ID de réservation spécifique avec 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 illustrent les modèles de planification courants :
Ajoutez un Pod à une réservation spécifique (aucune solution de rechange) :
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"
Nœuds ODCR cibles uniquement (tous les ODCR, pas les blocs de capacité) :
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default
Ciblez toute capacité réservée (ODCR ou bloc de capacité) :
spec: nodeSelector: karpenter.sh/capacity-type: reserved
Préférez réserver, 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 point de contrôle correspond au type de réservation qui répond à 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'une de ces situations se produit et qu'EKS Auto Mode/Karpenter détecte que l'instance n'appartient plus à un ODCR, l'karpenter.sh/capacity-typeétiquette du nœud passe de àreserved. on-demand L'instance continue de fonctionner en tant que On-Demand capacité standard, et les pods existants continuent de fonctionner sans interruption.
Note
Tout Pod programmé avec un code strict ne nodeSelector: karpenter.sh/capacity-type: reserved sera pas programmé sur le nœud s'il a été réétiqueté. Pour que les charges de travail puissent survivre à l'expiration ou à l'annulation d'un ODCR, utilisez le preferredDuringSchedulingIgnoredDuringExecution modèle illustré 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'instance). Planifiez des tâches de formation et d'inférence pour terminer ou enregistrer l'état 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 transférer 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 instance.
-
EKS Auto Mode et Karpenter commencent à vider les nœuds d'un bloc de capacité de manière préventive 10 minutes avant l'arrêt de l'EC2, afin que les charges de travail aient le temps de vérifier et de s'arrêter correctement.
Capacité statique NodePools
EKS Auto Mode et Karpenter prennent en charge la capacité statique NodePools, ce qui permet de maintenir un nombre fixe de nœuds quelle que soit la charge de travail requise. Les pools statiques éliminent les délais de démarrage à froid pour les inférences sensibles à la latence, et vous permettent de réserver un encombrement d'infrastructure minimal pour votre cluster.
La capacité statique est configurée en définissant le replicas champ sur le NodePool.
Considérations
-
Une fois
replicasdéfini sur un NodePool, vous ne pouvez pas le supprimer. Personne NodePool ne peut basculer entre le provisionnement de capacité statique et le provisionnement dynamique. -
La capacité statique n' NodePools est pas prise en compte pour la consolidation. Défini
limits.nodesci-dessusreplicaspour autoriser le dimensionnement 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 ML vous permettent de réserver P-family des instances Trainium pour une future fenêtre définie. Ils sont prépayés, donc EKS Auto Mode et Karpenter les proposent comme 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 de réservation ouverte correspondant à Capacity Blocks for 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 davantage restreint en spécifiant un identifiant de compte propriétaire.
Pour plus d'exemples, consultez la documentation de Karpenter
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é au On-Demand tarif 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 proposent gratuitement 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 capacityReservationSelectorTerms avec vos conditions 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, il sélectionne les réservations en fonction de leur comportement correspondant : ouverte (correspond à toutes les instances compatibles) ou ciblées (correspond uniquement aux instances explicitement ciblées). Cela peut être davantage restreint en spécifiant un identifiant de compte propriétaire.
Pour plus d'exemples, consultez la documentation de Karpenter
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 des On-Demand instances de manière explicite karpenter.sh/capacity-type: on-demand en définissant 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 imprévisible des inférences 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 de la capacité EC2 de réserve. AWS peut récupérer des instances Spot moyennant 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 PodDisruptionBudget point de contrôle vers 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 d'importantes économies de coûts.
Les candidats courants incluent :
-
Réglage des hyperparamètres et balayages : de nombreux essais courts et parallèles qui peuvent être réessayés en cas d'interruption.
-
Formation distribuée avec point de contrôle : tâches de longue durée qui enregistrent régulièrement 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 : évaluation à grande échelle des tâches par rapport à des ensembles de données dans lesquels la latence de bout en bout est mesurée en heures et non en secondes.
-
Pipelines de prétraitement des données et d'ingénierie des fonctionnalités : transformations parallèles sur de grands ensembles de données.
-
Évaluation du modèle et analyse comparative : tâches répétables qui produisent des résultats idempotents.
-
Développement, prototypage et ordinateurs portables : 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 configurant votre NodePool.