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.

Calcul et mise à l'échelle automatique

Optimisation des ressources GPU et gestion des coûts

Planifiez les charges de travail en fonction des exigences du processeur graphique à l'aide d'étiquettes Well-Known

Pour les AI/ML charges de travail sensibles à différentes caractéristiques du GPU (par exemple, GPU, mémoire GPU), nous vous recommandons de spécifier les exigences en matière de GPU à l'aide d'étiquettes de planification connues prises en charge par les types de nœuds utilisés avec Karpenter et les groupes de nœuds gérés. Si ces paramètres ne sont pas définis, des pods peuvent être planifiés sur des instances dont les ressources GPU sont insuffisantes, ce qui peut entraîner des pannes ou une dégradation des performances. Nous vous recommandons d'utiliser NodeSelector ou Node affinity pour spécifier le nœud sur lequel un pod doit s'exécuter et de définir les ressources de calcul (CPU, mémoire, GPU, etc.) dans la section des ressources du pod.

Exemple

Par exemple, en utilisant le sélecteur de nœud de nom GPU lors de l'utilisation de Karpenter :

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod-example
spec:
  containers:
  - name: ml-workload
    image: <image>
    resources:
      limits:
        nvidia.com/gpu: 1  # Request one NVIDIA GPU
  nodeSelector:
    karpenter.k8s.aws/instance-gpu-name: "l40s"  # Run on nodes with NVIDIA L40S GPUs

Utiliser le plugin Kubernetes Device pour exposer les GPU

Pour exposer les GPU sur les nœuds, le pilote GPU NVIDIA doit être installé sur le système d'exploitation du nœud et l'exécution du conteneur doit être configurée pour permettre au planificateur Kubernetes d'attribuer des pods aux nœuds dotés de GPU disponibles. Le processus de configuration du plug-in NVIDIA Kubernetes Device dépend de l'AMI accélérée EKS que vous utilisez :

Si vous décidez d'utiliser les AMI accélérées EKS et l'opérateur GPU NVIDIA pour gérer des composants tels que le plug-in de périphérique NVIDIA Kubernetes à la place, prenez note de désactiver la gestion du pilote GPU NVIDIA et du kit d'outils NVIDIA Container conformément à la documentation NVIDIA sur les pilotes GPU Pre-Installed NVIDIA et le NVIDIA Container Toolkit NVIDIA.

Pour vérifier que le plug-in NVIDIA Device est actif et que les GPU sont correctement exposés, exécutez :

kubectl describe node | grep nvidia.com/gpu

Cette commande vérifie si la nvidia.com/gpu ressource correspond à la capacité et aux ressources allouables du nœud. Par exemple, un nœud doté d'un seul GPU doit s'affichernvidia.com/gpu: 1. Consultez le Guide de planification des GPU de Kubernetes pour plus d'informations.

Utilisez de nombreux types d'instances EC2 différents

L'utilisation d'autant de types d'instances EC2 différents que possible constitue une bonne pratique importante en matière d'évolutivité sur Amazon EKS, comme indiqué dans la Plan de données Kubernetes section. Cette recommandation s'applique également aux instances dotées d'un matériel accéléré (par exemple, des GPU). Si vous créez un cluster qui utilise un seul type d'instance et que vous essayez d'augmenter le nombre de nœuds au-delà de la capacité de la région, vous risquez de recevoir une erreur de capacité insuffisante (ICE), indiquant qu'aucune instance n'est disponible. Il est important de comprendre les caractéristiques uniques de vos AI/ML charges de travail avant de les diversifier de manière arbitraire. Passez en revue les types d'instances disponibles à l'aide de l'outil EC2 Instance Type Explorer pour générer une liste des types d'instances qui correspondent à vos besoins de calcul spécifiques, et évitez de limiter arbitrairement le type d'instances pouvant être utilisé dans votre cluster.

Les instances de calcul accéléré sont proposées dans différents modèles d'achat pour s'adapter aux charges de travail à court, moyen terme et stables. Pour les charges de travail à court terme, flexibles et tolérantes aux pannes, pour lesquelles vous souhaiteriez éviter de faire une réservation, examinez les instances Spot. Les blocs de capacité, On-Demand les instances et les plans d'économie vous permettent de provisionner des instances de calcul accélérées pour une durée de charge de travail à moyen et long terme. Pour augmenter les chances d'accéder à la capacité requise dans le cadre de votre option d'achat préférée, il est recommandé d'utiliser une liste variée de types d'instances et de zones de disponibilité. Sinon, si vous rencontrez des ICE pour un modèle d'achat spécifique, réessayez d'utiliser un autre modèle.

Exemple L'exemple suivant montre comment permettre à un Karpenter de NodePool provisionner des instances G et P supérieures à des générations 3 (par exemple, p3). Pour plus d'informations, consultez la section Meilleures pratiques d'évolutivité d'EKS.

- key: karpenter.k8s.aws/instance-category
  operator: In
  values: ["g", "p"] # Diversifies across G-series and P-series
- key: karpenter.k8s.aws/instance-generation
  operator: Gt
  values: ["3"] # Selects instance generations greater than 3

Pour plus d'informations sur l'utilisation des instances Spot pour les GPU, consultez « Envisagez d'utiliser les instances Spot Amazon EC2 pour les GPU avec Karpenter » ci-dessous.

Envisagez d'utiliser des instances Spot Amazon EC2 pour les GPU avec Karpenter

Les instances Amazon EC2 Spot vous permettent de tirer parti de la capacité EC2 inutilisée dans le cloud AWS et sont disponibles avec une réduction allant jusqu'à 90 % par rapport aux On-Demand prix. Les instances Spot Amazon EC2 peuvent être interrompues avec un préavis de deux minutes lorsqu'EC2 a besoin de retrouver sa capacité. Pour plus d'informations, consultez Spot Instances dans le guide de l'utilisateur Amazon EC2. Amazon EC2 Spot peut constituer un excellent choix pour les charges de travail tolérantes aux pannes, sans état et flexibles (heure et type d'instance). Pour en savoir plus sur le moment d'utiliser les instances Spot, consultez la section Meilleures pratiques en matière d'instances Spot EC2. Vous pouvez également utiliser les instances Spot pour les AI/ML charges de travail si c'est Spot-friendly le cas.

Cas d’utilisation

Spot-friendly les charges de travail peuvent être des mégadonnées, des charges de travail conteneurisées, des serveurs Web sans état CI/CD, le calcul haute performance (HPC) et des charges de travail de rendu. Les instances Spot ne sont pas adaptées aux charges de travail rigides, dotées d'états, intolérantes aux pannes ou étroitement couplées entre les nœuds d'instance (par exemple, les charges de travail comportant des processus parallèles qui dépendent fortement les uns des autres pour le calcul et nécessitent une communication constante entre les nœuds, telles que les applications informatiques MPI-based hautes performances telles que la dynamique des fluides ou les bases de données distribuées avec des interdépendances complexes). Voici les cas d'utilisation spécifiques que nous recommandons (sans ordre particulier) :

Considérations

Pour utiliser les instances Spot pour accélérer les charges de travail sur Amazon EKS, il convient de prendre en compte un certain nombre de points essentiels (sans ordre particulier) :

Outre ces bonnes pratiques Spot de base, tenez compte de ces facteurs lors de la gestion des charges de travail GPU sur Amazon EKS. Contrairement aux CPU-based charges de travail, les charges de travail des GPU sont particulièrement sensibles aux détails matériels tels que les capacités du GPU et la mémoire GPU disponible. Les charges de travail des GPU peuvent être limitées par les types d'instances qu'ils peuvent utiliser, avec moins d'options disponibles par rapport aux processeurs. Dans un premier temps, déterminez si votre charge de travail est flexible en matière d'instance. Si vous ne savez pas combien de types d'instances votre charge de travail peut utiliser, testez-les individuellement pour garantir la compatibilité et les fonctionnalités. Déterminez dans quelle mesure vous pouvez être flexible pour diversifier autant que possible, tout en confirmant que la diversification permet à la charge de travail de fonctionner et en comprenant tout impact sur les performances (par exemple, sur le débit ou le délai d'exécution). Dans le cadre de la diversification de vos charges de travail, tenez compte des points suivants :

Scénario : Diversification des charges de travail d'inférence en temps réel

Pour une charge de travail d'inférence en ligne en temps réel sur les instances Spot, vous pouvez configurer un Karpenter NodePool afin de diversifier les familles et les générations d'instances GPU compatibles. Cette approche garantit une haute disponibilité en s'appuyant sur plusieurs pools Spot, tout en maintenant les performances grâce à des contraintes liées aux capacités du GPU, à la mémoire et à l'architecture. Il permet d'utiliser des alternatives lorsque la capacité des instances est limitée, de minimiser les interruptions et d'optimiser la latence d'inférence. Cet exemple NodePool indique qu'il faut utiliser des instances des séries g et p supérieures à 3, qui disposent de plus de 20 Go de mémoire GPU.

Exemple

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-inference-spot
spec:
  template:
    metadata:
      labels:
        role: gpu-spot-worker
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"] # Use Spot Instances
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["g", "p"] # Diversifies across G-series and P-series
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["3"] # Selects instance generations greater than 3
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"] # Specifies AMD64 architecture, compatible with NVIDIA GPUs
        - key: karpenter.k8s.aws/instance-gpu-memory
          operator: Gt
          values: ["20480"] # Ensures more than 20GB (20480 MiB) total GPU memory
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
      nodeClassRef:
        name: gpu-inference-ec2
        group: karpenter.k8s.aws
        kind: EC2NodeClass
      expireAfter: 720h
  limits:
    cpu: 100
    memory: 100Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m # Enables consolidation of underutilized nodes after 5 minutes

Mettre en œuvre des points de contrôle pour les tâches d'entraînement de longue durée

Le point de contrôle est une technique de tolérance aux pannes qui consiste à enregistrer périodiquement l'état d'un processus, afin de lui permettre de reprendre à partir du dernier point enregistré en cas d'interruption. Dans le domaine de l'apprentissage automatique, il est généralement associé à la formation, dans le cadre de laquelle des tâches de longue durée peuvent réduire le poids du modèle et l'état de l'optimiseur pour reprendre l'entraînement après des défaillances, telles que des problèmes matériels ou des interruptions d'instance ponctuelle.

Vous utilisez des points de contrôle pour enregistrer l'état des modèles d'apprentissage automatique (ML) pendant l'entraînement. Les points de contrôle sont des instantanés du modèle et peuvent être configurés par les fonctions de rappel de cadres ML. Vous pouvez utiliser les points de contrôle enregistrés pour redémarrer une tâche d’entraînement à partir du dernier point de contrôle enregistré. À l'aide de points de contrôle, vous enregistrez les instantanés de vos modèles en cours d'entraînement en raison d'une interruption inattendue de la tâche ou de l'instance de formation. Cela vous permet de reprendre l'entraînement du modèle à l'avenir à partir d'un point de contrôle. Outre la mise en œuvre d'un système de résilience des nœuds, nous vous recommandons de mettre en œuvre des points de contrôle pour atténuer l'impact des interruptions, notamment celles causées par des pannes matérielles ou des interruptions d'instances Amazon EC2 Spot.

Sans points de contrôle, les interruptions peuvent entraîner une perte de temps de calcul et une perte de progression, ce qui est coûteux pour les tâches de formation de longue durée. Le point de contrôle permet aux tâches de sauvegarder leur état périodiquement (par exemple, les poids du modèle et les états de l'optimiseur) et de reprendre à partir du dernier point de contrôle (dernier lot traité) après une interruption. Pour implémenter le point de contrôle, concevez votre application de manière à traiter les données par lots volumineux et à enregistrer les résultats intermédiaires dans un stockage permanent, tel qu'un compartiment Amazon S3 via le pilote CSI Mountpoint for Amazon S3 pendant que la formation progresse.

Cas d’utilisation

Le point de contrôle est particulièrement utile dans des scénarios spécifiques pour trouver un équilibre entre la tolérance aux pannes et les coûts de performance. Envisagez d'utiliser le point de contrôle dans les cas suivants :

Utilisez des blocs de capacité ML pour garantir la capacité des instances P et Trainium

Les blocs de capacité pour le ML vous permettent de réserver des instances GPU très recherchées, en particulier des instances P (par exemple, p6-b200, p5, p5e, p5en, p4d, p4de) et des instances Trainium (par exemple, trn1, trn2), pour démarrer presque immédiatement ou à une date ultérieure afin de prendre en charge vos charges de travail d'apprentissage automatique (ML) de courte durée. Ces réservations sont idéales pour garantir la capacité nécessaire pour les tâches nécessitant beaucoup de calcul, telles que la formation des modèles et la mise au point. La tarification d'EC2 Capacity Blocks comprend des frais de réservation et des frais de système d'exploitation. Pour en savoir plus sur la tarification, consultez la section EC2 Capacity Blocks for ML pricing.

Pour réserver des GPU pour les AI/ML charges de travail sur Amazon EKS afin de garantir une capacité prévisible, nous vous recommandons d'utiliser les blocs de capacité ML pour les réservations à court terme ou les réservations de On-Demand capacité (ODCR) pour une assurance de capacité à usage général.

Réservez de la capacité via l'AWS Management Console et configurez vos nœuds pour utiliser des blocs de capacité ML. Planifiez les réservations en fonction des plannings de charge de travail et testez-les dans un cluster intermédiaire. Reportez-vous à la documentation sur les blocs de capacité pour plus d'informations.

Envisagez On-Demand les réservations ponctuelles ou de On-Demand capacité Amazon EC2 (ODCR) pour les instances G Amazon EC2

Pour les instances Amazon EC2 G On-Demand, considérez les différentes options d'achat parmi les instances Spot Amazon EC2 et les réservations de On-Demand capacité. Les ODCR vous permettent de réserver de la capacité d'instance EC2 dans une zone de disponibilité spécifique pendant une certaine durée, garantissant ainsi la disponibilité même en cas de forte demande. Contrairement aux blocs de capacité ML, qui ne sont disponibles que pour les instances P et Trainium, les ODCR peuvent être utilisés pour un plus large éventail de types d'instances, y compris les instances G, ce qui les rend adaptés aux charges de travail nécessitant différentes fonctionnalités GPU, telles que l'inférence ou les graphiques. Lorsque vous utilisez les instances Spot Amazon EC2, il est essentiel de pouvoir choisir différents types d'instances, tailles et zones de disponibilité pour pouvoir rester sur Spot plus longtemps.

Les ODCR n'ont aucun engagement à long terme, mais vous payez le On-Demand tarif pour la capacité réservée, qu'elle soit utilisée ou inactive. Les ODCR peuvent être créés pour une utilisation immédiate ou planifiés pour une date ultérieure, ce qui offre une flexibilité dans la planification des capacités. Dans Amazon EKS, les ODCR sont pris en charge par des types de nœuds tels que Karpenter et des groupes de nœuds gérés. Pour hiérarchiser les ODCR dans Karpenter, configurez le NodeClass pour utiliser le champ. capacityReservationSelectorTerms Consultez la NodePools documentation https://karpenter.sh/docs/concepts/nodepools/ Karpenter. Pour plus d'informations sur la création d'ODCR, y compris les commandes CLI, reportez-vous à la section Mise en route de la réservation On-Demand de capacité.

Envisagez d'autres types et tailles d'instances accélérées

Il est essentiel de sélectionner l'instance accélérée et la taille appropriées pour optimiser à la fois les performances et les coûts de vos charges de travail de machine learning sur Amazon EKS. Par exemple, les différentes familles d'instances GPU ont des performances et des fonctionnalités différentes, telles que la mémoire GPU. Pour vous aider à choisir l'option la plus rentable, consultez les instances GPU disponibles sur la page Types d'instances EC2 sous Calcul accéléré. Évaluez plusieurs types et tailles d'instance pour trouver celle qui convient le mieux à vos exigences spécifiques en matière de charge de travail. Tenez compte de facteurs tels que le nombre de GPU, la mémoire et les performances du réseau. En sélectionnant avec soin le type et la taille d'instance GPU appropriés, vous pouvez améliorer l'utilisation des ressources et la rentabilité de vos clusters EKS.

Si vous utilisez une instance GPU dans un nœud EKS, le nvidia-device-plugin-daemonset pod sera placé par défaut dans l'kube-systemespace de noms. Pour savoir rapidement si vous utilisez pleinement le ou les GPU de votre instance, vous pouvez utiliser https://docs.nvidia.com/deploy/nvidia-smi/index.html nvidia-smi comme indiqué ici :

kubectl exec nvidia-device-plugin-daemonset-xxxxx \
  -n kube-system -- nvidia-smi \
  --query-gpu=index,power.draw,power.limit,temperature.gpu,utilization.gpu,utilization.memory,memory.free,memory.used \
  --format=csv -l 5

Pour en savoir plus, consultez la section Instances GPU dans la documentation AWS.

Optimisez l'allocation des ressources GPU à l'aide Time-Slicing du MIG et de l'allocation fractionnée du GPU

Les limites de ressources statiques dans Kubernetes (par exemple, le nombre de processeurs, de mémoire, de GPU) peuvent entraîner un provisionnement excessif ou une sous-utilisation, en particulier pour les charges de travail dynamiques telles que l'inférence. AI/ML Il est important de sélectionner le bon GPU. Pour les charges de travail à faible volume ou complexes, le découpage temporel permet à plusieurs charges de travail de partager un seul GPU en partageant ses ressources de calcul, ce qui peut améliorer l'efficacité et réduire le gaspillage. Le partage du GPU peut être réalisé grâce à différentes options :

Pour activer ces fonctionnalités dans EKS, vous pouvez déployer le plug-in NVIDIA Device, qui expose les GPU en tant que ressources programmables et prend en charge le découpage en temps et le MIG. Pour en savoir plus, consultez les sections Time-Slicing GPU dans Kubernetes et le partage de GPU sur Amazon EKS avec le découpage temporel NVIDIA et les instances EC2 accélérées.

Exemple

Par exemple, pour activer le découpage temporel à l'aide du plug-in NVIDIA Device :

apiVersion: v1
kind: ConfigMap
metadata:
  name: nvidia-device-plugin-config
  namespace: kube-system
data:
  config.yaml: |
    version: v1
    sharing:
      timeSlicing:
        resources:
        - name: nvidia.com/gpu
          replicas: 4  # Allow 4 pods to share each GPU

Exemple

Par exemple, pour utiliser KAI Scheduler pour l'allocation fractionnée de GPU, déployez-le aux côtés de l'opérateur GPU NVIDIA et spécifiez les ressources GPU fractionnées dans la spécification du pod :

apiVersion: v1
kind: Pod
metadata:
  name: fractional-gpu-pod-example
  annotations:
    gpu-fraction: "0.5"  # Annotation for 50% GPU
  labels:
    runai/queue: "default"  # Required queue assignment
spec:
  containers:
  - name: ml-workload
    image: nvcr.io/nvidia/pytorch:25.04-py3
    resources:
      limits:
        nvidia.com/gpu: 1
  nodeSelector:
    nvidia.com/gpu: "true"
  schedulerName: kai-scheduler

Résilience des nœuds et gestion des tâches de formation

Mettre en œuvre des contrôles de santé des nœuds avec une restauration automatique

Pour les tâches de formation distribuées sur Amazon EKS qui nécessitent de fréquentes communications entre nœuds, telles que la formation de modèles multi-GPU sur plusieurs nœuds, des problèmes matériels tels que des pannes GPU ou EFA peuvent perturber les tâches de formation. Ces interruptions peuvent entraîner une perte de progression de la formation et une augmentation des coûts, en particulier pour les AI/ML charges de travail de longue durée qui reposent sur un matériel stable.

Pour renforcer la résilience face aux pannes matérielles, telles que les pannes GPU dans les clusters EKS exécutant des charges de travail GPU, nous vous recommandons de tirer parti de l'agent de surveillance des nœuds EKS avec réparation automatique ou d'Amazon SageMaker HyperPod. Alors que l'agent de surveillance des nœuds EKS avec réparation automatique fournit des fonctionnalités telles que la surveillance de l'état des nœuds et la réparation automatique à l'aide de mécanismes Kubernetes standard, SageMaker HyperPod offre une résilience ciblée et des fonctionnalités supplémentaires spécialement conçues pour la formation ML à grande échelle, telles que des bilans de santé approfondis et une reprise automatique des tâches.

Pour l'agent de surveillance des nœuds EKS avec réparation automatique et les SageMaker HyperPod clusters utilisant EFA, afin de surveiller EFA-specific des indicateurs tels que les erreurs RDMA (Remote Direct Memory Access) et les suppressions de paquets, assurez-vous que le pilote AWS EFA est installé. En outre, nous vous recommandons de déployer l'CloudWatch Observability Add-on ou d'utiliser des outils tels que DCGM Exporter avec Prometheus et Grafana pour surveiller l'EFA, le GPU et SageMaker HyperPod, pour les métriques spécifiques liées à ses fonctionnalités.

Désactivez Karpenter Consolidation pour les charges de travail sensibles aux interruptions

Pour les charges de travail sensibles aux interruptions, telles que le traitement, les tâches de AI/ML prédiction à grande échelle ou la formation, nous recommandons d'ajuster les politiques de consolidation de Karpenter afin d'éviter les interruptions lors de l'exécution des tâches. La fonction de consolidation de Karpenter optimise automatiquement les coûts des clusters en supprimant les nœuds sous-utilisés ou en les remplaçant par des alternatives moins coûteuses. Cependant, même lorsqu'une charge de travail utilise entièrement un processeur graphique, Karpenter peut consolider les nœuds s'il identifie un type d'instance de taille appropriée à moindre coût qui répond aux exigences du pod, ce qui entraîne des interruptions de travail.

La politique de WhenEmptyOrUnderutilized consolidation peut mettre fin aux nœuds prématurément, ce qui entraîne des délais d'exécution plus longs. Par exemple, les interruptions peuvent retarder la reprise des tâches en raison de la replanification des pods ou du rechargement des données, ce qui peut être coûteux pour les tâches d'inférence par lots de longue durée. Pour remédier à ce problème, vous pouvez définir la consolidationPolicy valeur WhenEmpty et configurer une consolidateAfter durée, par exemple 1 heure, pour conserver les nœuds pendant les pics de charge de travail. Par exemple :

disruption:
  consolidationPolicy: WhenEmpty
  consolidateAfter: 60m

Cette approche améliore la latence de démarrage des pods pour les charges de travail d'inférence par lots complexes et d'autres tâches sensibles aux interruptions, telles que le traitement des données d'inférence en ligne en temps réel ou la formation de modèles, où le coût de l'interruption l'emporte sur les économies de coûts de calcul. Karpenter NodePool Disruption Budgets est une autre fonctionnalité permettant de gérer les interruptions de Karpenter. Avec les budgets, vous pouvez vous assurer que pas plus d'un certain nombre de nœuds ne seront perturbés dans les nœuds choisis NodePool à un moment donné. Vous pouvez également utiliser des budgets d'interruption pour éviter que tous les nœuds ne soient perturbés à un moment donné (par exemple, aux heures de pointe). Pour en savoir plus, consultez la documentation de Karpenter Consolidation.

Utiliser TTL SecondsAfterFinished pour automatiser les tâches Clean-Up Kubernetes

Nous vous recommandons de configurer ttlSecondsAfterFinished les tâches Kubernetes dans Amazon EKS pour supprimer automatiquement les objets de tâche terminés. Les objets de travail persistants consomment des ressources de cluster, telles que la mémoire du serveur d'API, et compliquent la surveillance en encombrant les tableaux de bord (par exemple, Grafana, Amazon). CloudWatch Par exemple, la définition d'un TTL d'une heure garantit la suppression des tâches peu de temps après leur achèvement, ce qui permet de garder votre cluster en ordre. Pour plus de détails, reportez-vous à la section Nettoyage automatique des tâches terminées.

Configurer la Low-Priority préemption des tâches pour Higher-Priority Jobs/workloads

Pour les AI/ML charges de travail à priorité mixte sur Amazon EKS, vous pouvez configurer la préemption des tâches de faible priorité afin de garantir que les tâches les plus prioritaires (par exemple, l'inférence en temps réel) reçoivent des ressources rapidement. Sans préemption, les charges de travail peu prioritaires telles que les processus par lots (par exemple, l'inférence par lots, le traitement des données), les services non batch (par exemple, les tâches en arrière-plan, les tâches cron) ou les CPU/memory-intensive travaux (par exemple, les services Web) peuvent retarder les pods critiques en occupant des nœuds. La préemption permet à Kubernetes d'expulser les pods de faible priorité lorsque les pods les plus prioritaires ont besoin de ressources, garantissant ainsi une allocation efficace des ressources sur les nœuds dotés de GPU, de processeurs ou de mémoire. Nous vous recommandons d'utiliser Kubernetes PriorityClass pour attribuer des priorités et contrôler le comportement en matière PodDisruptionBudget d'expulsion.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
value: 100
---
spec:
  priorityClassName: low-priority

Consultez la documentation sur les priorités et la préemption de Kubernetes pour plus d'informations.

Évolutivité et performances des applications

Personnalisez la capacité de calcul pour les charges de travail de machine learning avec Karpenter ou Static Nodes

Pour garantir une capacité de calcul rentable et réactive pour les flux de travail d'apprentissage automatique (ML) sur Amazon EKS, nous vous recommandons d'adapter votre stratégie de provisionnement de nœuds aux caractéristiques de votre charge de travail et à vos engagements financiers. Vous trouverez ci-dessous deux approches à envisager : une mise à l'échelle juste à temps avec Karpenter et des groupes de nœuds statiques pour la capacité réservée.

Exemple

Voici un exemple de Karpenter diversifié NodePool qui permet de lancer des instances g Amazon EC2 lorsque la génération d'instances est supérieure à trois.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-inference
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["g"]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["3"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
  limits:
    cpu: "1000"
    memory: "4000Gi"
    nvidia.com/gpu: "10"  *# Limit the total number of GPUs to 10 for the NodePool*
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 60m
    expireAfter: 720h

Exemple

Exemple d'utilisation de groupes de nœuds statiques pour une charge de travail de formation :

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ml-cluster
  region: us-west-2
managedNodeGroups:
  - name: gpu-node-group
    instanceType: p4d.24xlarge
    minSize: 2
    maxSize: 2
    desiredCapacity: 2
    taints:
      - key: nvidia.com/gpu
        effect: NoSchedule

Utilisez des limites et des tolérances pour empêcher la planification de charges de travail non accélérées sur des instances accélérées

La planification de charges de travail non accélérées sur des ressources GPU n'est pas efficace en termes de calcul. Nous vous recommandons d'utiliser des limites et une tolérance pour vous assurer que les pods de charges de travail non accélérées ne sont pas planifiés sur des nœuds inappropriés. Consultez la documentation Kubernetes pour plus d'informations.

Échelle basée sur les performances du modèle

Pour les charges de travail d'inférence, nous vous recommandons d'utiliser Kubernetes Event-Driven Autoscaling (KEDA) pour effectuer une mise à l'échelle en fonction des indicateurs de performance du modèle, tels que les demandes d'inférence ou le débit de jetons, avec des périodes de recharge appropriées. Les politiques de dimensionnement statique peuvent surapprovisionner ou sous-approvisionner les ressources, ce qui a un impact sur les coûts et la latence. Pour en savoir plus, consultez la documentation https://keda.sh/ KEDA.

Allocation dynamique des ressources pour une gestion avancée des GPU

L'allocation dynamique des ressources (DRA) représente une avancée fondamentale dans la gestion des ressources GPU de Kubernetes. DRA va au-delà des limites traditionnelles des plug-ins de périphériques pour permettre un partage sophistiqué des GPU, une prise en compte de la topologie et une coordination des ressources entre nœuds. Disponible dans la version 1.33 d'Amazon EKS, DRA répond aux défis critiques liés aux AI/ML charges de travail en fournissant les éléments suivants :

L'allocation de GPU traditionnelle traite les GPU comme des ressources entières opaques, ce qui entraîne une sous-utilisation importante (souvent de 30 à 40 % dans les clusters de production). Cela se produit parce que les charges de travail bénéficient d'un accès exclusif à des GPU complets, même lorsqu'elles ne nécessitent que des ressources partielles. DRA transforme ce modèle en introduisant une allocation déclarative structurée qui fournit au planificateur Kubernetes une visibilité complète sur les caractéristiques matérielles et les exigences en matière de charge de travail. Cela permet de prendre des décisions de placement intelligentes et de partager efficacement les ressources.

Avantages de l'utilisation de DRA au lieu du plug-in de périphérique NVIDIA

Le plug-in de périphérique NVIDIA (à partir de la version0.12.0) prend en charge les mécanismes de partage du GPU, notamment le découpage en temps, le MPS et le MIG. Cependant, la DRA répond à des limites architecturales.

Limitations des plug-ins pour appareils NVIDIA

Solutions avec DRA

Important : DRA ne remplace pas entièrement le plug-in du périphérique NVIDIA. Le pilote NVIDIA DRA fonctionne conjointement avec le plug-in de l'appareil pour fournir des fonctionnalités améliorées. Le plug-in de l'appareil continue de gérer la découverte et la gestion de base du GPU, tandis que DRA ajoute des fonctionnalités avancées d'allocation et de planification.

Instances prises en charge par DRA et leurs fonctionnalités

La prise en charge de DRA varie en fonction de la famille d'instances Amazon EC2 et de l'architecture GPU, comme indiqué dans le tableau suivant.

Les descriptions de chaque fonctionnalité du tableau sont les suivantes :

Ressources supplémentaires

Pour plus d'informations sur les pilotes Kubernetes DRA et NVIDIA DRA, consultez les ressources suivantes sur : GitHub

Configuration de l'allocation dynamique des ressources pour une gestion avancée des GPU

La rubrique suivante explique comment configurer l'allocation dynamique des ressources (DRA) pour une gestion avancée des GPU.

Conditions préalables

Avant d'implémenter DRA sur Amazon EKS, assurez-vous que votre environnement répond aux exigences suivantes.

Configuration du cluster

Composants requis

Étape 1 : créer un cluster avec un groupe de DRA-enabled nœuds à l'aide d'eksctl

Étape 2 : Déploiement du plug-in de périphérique NVIDIA

Déployez le plug-in de périphérique NVIDIA pour activer la découverte de base du GPU :

Étape 3 : Déployer le diagramme Helm du pilote NVIDIA DRA

Étape 4 : Vérifiez l'installation de DRA

Passez au Planifiez une charge de travail GPU simple à l'aide d'une allocation dynamique des ressources.

Planifiez une charge de travail GPU simple à l'aide d'une allocation dynamique des ressources

Pour planifier une charge de travail GPU simple à l'aide de l'allocation dynamique des ressources (DRA), procédez comme suit. Avant de continuer, assurez-vous d'avoir suiviConfiguration de l'allocation dynamique des ressources pour une gestion avancée des GPU.

Continuez à découvrir Techniques d'optimisation du GPU avec allocation dynamique des ressources des techniques d'optimisation GPU plus avancées à l'aide de DRA.

Techniques d'optimisation du GPU avec allocation dynamique des ressources

Les charges de travail GPU modernes nécessitent une gestion sophistiquée des ressources pour optimiser leur utilisation et leur rentabilité. DRA permet plusieurs techniques d'optimisation avancées qui répondent à différents cas d'utilisation et fonctionnalités matérielles :

Ces techniques peuvent améliorer considérablement l'utilisation des ressources. Les entreprises signalent que l'utilisation du GPU passe de 30 à 40 % avec une allocation traditionnelle à 80 à 90 % avec des stratégies de partage optimisées. Le choix de la technique dépend des caractéristiques de la charge de travail, des exigences d'isolation et des capacités matérielles.

Optimisez les charges de travail des GPU grâce à la réduction du temps

Time-slicing permet à plusieurs charges de travail de partager les ressources de calcul du GPU en les planifiant pour qu'elles s'exécutent de manière séquentielle sur le même GPU physique. Il est idéal pour les charges de travail d'inférence avec une utilisation sporadique du GPU.

Procédez comme suit.

Premier pod (inference-pod-1)

Deuxième module (1training-pod-2)

Optimisez les charges de travail du GPU avec MPS

Multi-Process Le service (MPS) permet l'exécution simultanée de plusieurs contextes CUDA sur un seul GPU avec une meilleure isolation que le découpage temporel.

Procédez comme suit.

Cette configuration démontre un véritable partage de GPU à l'aide de NVIDIA Multi-Process Service (MPS) via l'allocation dynamique des ressources (DRA). Contrairement au découpage temporel où les charges de travail utilisent à tour de rôle le GPU de manière séquentielle, MPS permet aux deux conteneurs de s'exécuter simultanément sur le même GPU physique. L'idée principale est que le partage DRA MPS nécessite plusieurs conteneurs au sein d'un seul pod, et non plusieurs pods séparés. Une fois déployé, le pilote DRA en alloue un ResourceClaim au Pod et configure automatiquement MPS pour permettre aux conteneurs d'inférence et d'entraînement de s'exécuter simultanément.

Chaque conteneur dispose de son propre espace mémoire GPU isolé et de ses propres ressources de calcul, le démon MPS coordonnant l'accès au matériel sous-jacent. Vous pouvez vérifier que cela fonctionne en procédant comme suit :

Cette approche maximise l'utilisation du GPU en permettant à des charges de travail complémentaires de partager efficacement le matériel GPU coûteux, au lieu de le laisser sous-utilisé par un seul processus.

Conteneur 1 : conteneur d'inférence

root@mps-multi-container-pod:/workspace# nvidia-smi
Wed Jul 16 21:09:30 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.158.01             Driver Version: 570.158.01     CUDA Version: 12.9     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA L4                      On  |   00000000:35:00.0 Off |                    0 |
| N/A   48C    P0             28W /   72W |     597MiB /  23034MiB |      0%   E. Process |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A               1    M+C   python                                  246MiB |
+-----------------------------------------------------------------------------------------+

Conteneur 2 : conteneur de formation

root@mps-multi-container-pod:/workspace# nvidia-smi
Wed Jul 16 21:16:00 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.158.01             Driver Version: 570.158.01     CUDA Version: 12.9     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA L4                      On  |   00000000:35:00.0 Off |                    0 |
| N/A   51C    P0             28W /   72W |     597MiB /  23034MiB |      0%   E. Process |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A               1    M+C   python                                  314MiB |
+-----------------------------------------------------------------------------------------+

Optimisez les charges de travail du GPU avec le Multi-Instance GPU

Multi-instance Le GPU (MIG) fournit un partitionnement au niveau matériel, créant des instances GPU isolées avec des ressources de calcul et de mémoire dédiées.

L'utilisation du partitionnement MIG dynamique avec différents profils nécessite l'opérateur GPU NVIDIA. L'opérateur GPU NVIDIA utilise MIG Manager pour créer des profils MIG et redémarre les instances GPU telles que P4D, P4De, P5, P6, etc. pour appliquer les modifications de configuration. L'opérateur GPU inclut des fonctionnalités complètes de gestion MIG via le composant MIG Manager, qui surveille les modifications apportées à l'étiquette des nœuds et applique automatiquement la configuration MIG appropriée. Lorsqu'un changement de profil MIG est demandé, l'opérateur arrête automatiquement tous les clients GPU, applique la nouvelle géométrie de partition et redémarre les services concernés. Ce processus nécessite un redémarrage du nœud pour les instances GPU afin de garantir des transitions d'état du GPU propres. C'est pourquoi l'activation WITH–0—REBOOT=true dans la configuration de MIG Manager est essentielle pour réussir les déploiements MIG.

Vous avez besoin du pilote NVIDIA DRA et de l'opérateur GPU NVIDIA pour utiliser MIG dans Amazon EKS. Vous n'avez pas besoin de NVIDIA Device Plugin et de DCGM Exporter en plus de cela, car ils font partie de l'opérateur GPU NVIDIA. Étant donné que les AMI NVIDIA EKS sont fournies avec les pilotes NVIDIA préinstallés, nous avons désactivé le déploiement des pilotes par l'opérateur du GPU afin d'éviter les conflits et de tirer parti des pilotes optimisés déjà présents sur les instances. Le pilote NVIDIA DRA gère l'allocation dynamique des ressources pour les instances MIG, tandis que l'opérateur GPU gère l'intégralité du cycle de vie du GPU. Cela inclut la configuration MIG, la fonctionnalité de plug-in de périphérique, la surveillance via DCGM et la découverte des fonctionnalités des nœuds. Cette approche intégrée fournit une solution complète pour la gestion des GPU d'entreprise, avec des fonctionnalités d'isolation au niveau matériel et d'allocation dynamique des ressources.

Étape 1 : Déploiement de l'opérateur GPU NVIDIA

NVIDIA GPU Operator a correctement appliqué le profil p4de-half-balanced MIG à votre instance P4DE, créant ainsi des partitions GPU au niveau matériel telles que configurées. Voici comment fonctionne le partitionnement :

L'opérateur GPU a appliqué cette configuration à partir de votre profil MIG intégré :

p4de-half-balanced:
  - devices: [0, 1, 2, 3]        # First 4 GPUs: MIG enabled
    mig-enabled: true
    mig-devices:
      "1g.10gb": 2               # 2x small instances (10GB each)
      "2g.20gb": 1               # 1x medium instance (20GB)
      "3g.40gb": 1               # 1x large instance (40GB)
  - devices: [4, 5, 6, 7]        # Last 4 GPUs: Full GPUs
    mig-enabled: false

À partir de votre nvidia-smi -L sortie, voici ce que l'opérateur GPU a créé :

Une fois que l'opérateur GPU NVIDIA a créé les partitions MIG, le pilote NVIDIA DRA détecte automatiquement ces instances isolées matériellement et les rend disponibles pour une allocation dynamique des ressources dans Kubernetes. Le pilote DRA découvre chaque instance MIG avec son profil spécifique (1g.10 Go, 2g.20 Go, 3g.40 Go) et les expose en tant que ressources planifiables via la classe de périphériques. mig.nvidia.com

Le pilote DRA surveille en permanence la topologie MIG et tient à jour un inventaire des instances disponibles sur tous les GPU. Lorsqu'un pod demande un profil MIG spécifique via unResourceClaimTemplate, le pilote DRA sélectionne intelligemment une instance MIG appropriée à partir de n'importe quel GPU disponible, ce qui permet une véritable mutualisation au niveau matériel. Cette allocation dynamique permet à plusieurs charges de travail isolées de s'exécuter simultanément sur le même GPU physique tout en maintenant des limites de ressources strictes et des garanties de performances.

Étape 2 : tester l'allocation des ressources MIG

Passons maintenant à quelques exemples pour montrer comment DRA alloue dynamiquement des instances MIG à différentes charges de travail. Déployez les modules resourceclaimtemplates et testez pour voir comment le pilote DRA répartit les charges de travail sur les partitions MIG disponibles, permettant ainsi à plusieurs conteneurs de partager les ressources GPU avec une isolation au niveau matériel.

Optimisez les charges de travail du GPU avec IMEX à l'aide d'instances GB200 P6e

L'IMEX (Internode Memory Exchange) permet une communication cohérente en termes de mémoire entre les nœuds pour un entraînement distribué sur NVIDIA GB200. UltraServers

Procédez comme suit.

Pour plus d'informations, consultez l'exemple NVIDIA sur GitHub.