View a markdown version of this page

Utilisez le découpage temporel avec les GPU NVIDIA 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 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.

Utilisez le découpage temporel avec les GPU NVIDIA sur Amazon EKS

Time-slicing permet à plusieurs Pods de partager un seul GPU NVIDIA physique. Le planificateur Kubernetes place plusieurs Pods sur le même GPU, et le planificateur CUDA du GPU multiplexe le travail dans le temps. Time-slicing est la GPU-sharing stratégie la plus simple. Il utilise uniquement des logiciels, ne nécessite aucun matériel spécial et fonctionne sur tous les types d'instances de GPU NVIDIA AWS. Time-slicing n'offre pas d'isolation de la mémoire ou du calcul entre les Pods qui partagent un GPU. Il convient parfaitement aux charges de travail à faible utilisation du GPU, telles que les services d'inférence qui restent inactifs entre les demandes ou les environnements de développement dans lesquels plusieurs utilisateurs partagent un GPU. Pour les charges de travail qui nécessitent une mémoire au niveau matériel et une isolation de calcul, utilisez plutôt le Multi-Instance GPU (MIG).

Sur Amazon EKS, vous pouvez gérer le découpage temporel à l'aide du pilote NVIDIA DRA ou du plug-in de périphérique NVIDIA.

Time-slicing ne peut être utilisé avec Karpenter que si vous utilisez un provisionnement de capacité statique. Time-slicing n'est pas disponible actuellement en mode EKS Auto.

Time-slicing convient parfaitement lorsque :

  • L'utilisation du GPU est constamment faible, par exemple les services d'inférence sensibles à la latence qui sont inactifs entre les requêtes.

  • Plusieurs développeurs partagent un même nœud GPU pour les ordinateurs portables ou les travaux de développement.

  • Vos nœuds utilisent un type d'instance GPU qui ne prend pas en charge le MIG, tel que les g6e familles g5g6, ou.

  • Vous pouvez accepter qu'un Pod soit parfois plus lent parce qu'un autre Pod est occupé sur le même GPU.

Envisagez une approche différente lorsque :

  • Vous avez besoin d'une isolation de la mémoire. Les pods d'un GPU à tranches temporelles partagent la même mémoire GPU, et un pod peut épuiser la mémoire dont dépendent les autres Pods. Utilisez MIG pour isoler la mémoire.

  • Vous avez besoin d'une latence ou d'une qualité de service prévisible par POD. Le planificateur GPU partage le calcul entre les emplacements dans la mesure du possible, sans aucune garantie.

  • Vous gérez des charges de travail de formation. Time-slicing ajoute un changement de contexte qui réduit l'efficacité de l'entraînement. Une tâche en point de contrôle ralentie par un autre pod doit être réessayée depuis son dernier point de contrôle.

Considérations

Prenez en compte les points suivants avant d'utiliser le découpage temporel en production.

Considérations d’ordre général

  • Aucune isolation de la mémoire : les modules qui partagent un processeur graphique à tranches temporelles partagent sa mémoire. Un pod peut allouer de la mémoire dont d'autres pods ont besoin, ce qui peut provoquer des erreurs de manque de mémoire. Faites correspondre le nombre de modules qui partagent chaque GPU à l'empreinte mémoire de vos charges de travail. Si vos Pods chargent régulièrement de grands modèles, partagez moins de Pods par GPU ou utilisez le MIG.

  • Best-effort partage de calcul : le planificateur GPU partage le calcul entre les Pods dans la mesure du possible et ne garantit pas un calcul proportionnel à chaque Pod.

  • Time-slicing et MPS ne peut pas partager le même GPU : Time-slicing définit le mode de calcul du GPU surDEFAULT, alors que NVIDIA Multi-Process Service (MPS) l'exigeEXCLUSIVE_PROCESS. Vous pouvez utiliser les deux stratégies dans le même cluster, mais pas sur le même GPU physique en même temps. Time-slicing n'a également aucun effet sur une instance MIG. Pour partager une seule instance MIG sur plusieurs conteneurs, utilisez plutôt MPS.

  • Per-container métriques : NVIDIA Data Center GPU Manager (DCGM) ne peut pas attribuer de métriques à des conteneurs individuels lorsque le time-slicing est actif. GPU-level les métriques restent disponibles, mais vous ne pouvez pas identifier quel Pod a consommé une quantité donnée de ressources GPU.

Considérations relatives au pilote NVIDIA DRA

  • Fonctionnalité alpha : Time-slicing l'utilisation du pilote DRA nécessite le TimeSlicingSettings Feature Gate, qui est une fonctionnalité alpha désactivée par défaut. Pour de plus amples informations, veuillez consulter Utilisez le découpage temporel du GPU avec le pilote NVIDIA DRA.

  • User-mediated partage uniquement : les pods partagent un GPU uniquement en référençant le même ResourceClaim ouResourceClaimTemplate, qui est limité à un espace de noms, de sorte que le partage ne peut pas traverser les espaces de noms. System-mediated le partage est une capacité future proposée.

  • Désactivez le plug-in de périphérique intégré sur Bottlerocket : le pilote DRA ne peut pas fonctionner en même temps que le plug-in de périphérique NVIDIA sur le même nœud. Sur Bottlerocket, désactivez le plug-in intégré à l'appareil, qui nécessite la version 1.63.0 ou ultérieure de Bottlerocket. Pour de plus amples informations, veuillez consulter Installez le pilote NVIDIA DRA.

  • Support informatique : le pilote NVIDIA DRA est pris en charge avec le provisionnement de capacité statique dans Karpenter, les groupes de nœuds gérés par EKS ou les nœuds autogérés, et n'est pas pris en charge avec le mode automatique EKS. Pour plus d'informations, consultez la NodePool documentation statique de Karpenter sur le site Web de Karpenter.

Considérations relatives aux plug-ins pour appareils NVIDIA

  • Best-effort partage de calcul avec des emplacements : le plug-in de l'appareil annonce un nombre fixe d'emplacements par GPU. Si un seul pod demande plus d'un emplacement, il ne reçoit pas de calcul supplémentaire. Activez l'fail-requests-greater-than-oneoption permettant de rejeter les pods qui demandent plus d'un emplacement.

  • Provisionnement avec Karpenter : Karpenter considère chaque nvidia.com/gpu requête comme un GPU physique, même lorsque le découpage temporel est activé sur le GPU. Pour plus d'informations, consultez le numéro #2140 de Karpenter sur GitHub.

  • Aucune prise en charge du mode automatique EKS : le mode automatique EKS gère le plug-in du périphérique NVIDIA et n'expose pas sa configuration. Comme le découpage temporel nécessite la configuration du plug-in de l'appareil, vous ne pouvez pas appliquer de configuration de découpage temporel sur les nœuds EKS Auto Mode.

  • Time-slicing modifications de configuration : le plug-in de périphérique NVIDIA ne surveille pas le découpage temporel ConfigMap des modifications. Redémarrez le plug-in de l'appareil après avoir mis à jour la configuration.

Options de configuration

Vous pouvez utiliser le découpage temporel pour les GPU NVIDIA avec les AMI NVIDIA EKS-optimized AL2023 et Bottlerocket. Les paramètres de découpage temporel varient selon que vous utilisez le pilote NVIDIA DRA ou le plug-in de périphérique NVIDIA.

NVIDIA DRA driver

Les AMI EKS-optimized accélérées n'incluent pas le pilote NVIDIA DRA. Si vous utilisez Bottlerocket, vous devez désactiver le plug-in intégré au périphérique NVIDIA avant d'utiliser le pilote NVIDIA DRA settings.kubelet-device-plugins.nvidia.enabled = false en définissant les données utilisateur du nœud, ce qui nécessite la version 1.63.0 ou ultérieure de Bottlerocket. Pour de plus amples informations, veuillez consulter Installez le pilote NVIDIA DRA.

Avec le pilote NVIDIA DRA, le découpage temporel est configuré via. ResourceClaimTemplates Le interval champ contrôle la durée de la tranche de temps CUDA.

Interval Description

Par défaut

Utilise l'intervalle par défaut intégré au pilote GPU NVIDIA

Court

Intervalle plus court ; les contextes changent plus fréquemment

Moyenne

Intervalle intermédiaire

Long

chaque contexte s'exécute plus longtemps par tour avant d'être préempté

NVIDIA device plugin
  • Bottlerocket — L'AMI inclut un plug-in de périphérique NVIDIA préinstallé. Vous configurez le découpage temporel via les paramètres de Bottlerocket, sans installation séparée de plug-in d'appareil, de Helm Chart ou. ConfigMap

  • AL2023 — Vous installez le plug-in de périphérique NVIDIA comme décrit dansInstallez le plug-in de périphérique NVIDIA Kubernetes, et vous fournissez la configuration par tranches temporelles via un. ConfigMap

    Les options suivantes contrôlent la manière dont le plug-in de périphérique NVIDIA fait la publicité et gère les GPU échelonnés dans le temps. Les noms des champs diffèrent entre les paramètres de Bottlerocket et ceux de l'AL2023ConfigMap, comme indiqué dans les procédures qui suivent.

    Option Valeur recommandée Description

    Réplicas

    2 à 8

    Le nombre d'emplacements programmables à annoncer par GPU physique. Des valeurs plus élevées permettent plus de partage mais augmentent les conflits entre les Pods.

    Renommer par défaut

    false

    Quandfalse, demande Podsnvidia.com/gpu, ce qui permet de conserver la compatibilité avec les manifestes existants. Lorsquetrue, le plug-in de l'appareil annonce la ressource sous le nom denvidia.com/gpu.shared, et les Pods doivent demander ce nom. Définissez cette option true lorsque vous exécutez des pools de nœuds GPU partagés et dédiés et que vous souhaitez que les charges de travail sélectionnent explicitement la ressource partagée.

    Requêtes échouées supérieures à une

    true

    Rejette les pods qui demandent plus d'un créneau temporel. Un pod qui demande plus d'un emplacement ne reçoit pas de calcul proportionnel. Activez ce paramètre pour éviter toute erreur de configuration courante.

    Pour obtenir la liste complète des options de partage du GPU et leurs valeurs par défaut, consultez la documentation du plug-in pour appareils NVIDIA Kubernetes sur. GitHub

Utilisez le découpage temporel du GPU avec le pilote NVIDIA DRA

Avec le pilote NVIDIA DRA, les Pods partagent un GPU en faisant référence à un processeur commun ResourceClaim qui le demande gpu.nvidia.com DeviceClass avec un découpage temporelGpuConfig.

Le pilote NVIDIA DRA implémente actuellement le découpage temporel médiatisé par l'utilisateur : un GPU est partagé uniquement entre les pods et les conteneurs que vous pointez explicitement vers la même réclamation. Comme a ResourceClaim et a ResourceClaimTemplate sont limités à un espace de noms, les pods qui partagent un GPU de cette manière doivent se trouver dans le même espace de noms. Pour partager un GPU entre plusieurs conteneurs dans un seul Pod, demandez à chaque conteneur de faire référence au même nom de demande dans la réclamation. Les conteneurs qui font référence à des noms de requêtes différents reçoivent chacun un GPU distinct. Créez un espace distinct ResourceClaimTemplate pour chaque intervalle de temps dont vous avez besoin et un pour chaque espace de noms où vous souhaitez partager des GPU.

System-mediatedle découpage temporel se produit lorsque le pilote partage un GPU entre des claims indépendants (y compris entre des espaces de noms) en fonction de critères définis par le système plutôt que d'une revendication que vous configurez. Pour plus d'informations sur le découpage temporel médié par le système, consultez les sections System-mediated découpage temporel des GPU (problème #659) et pull request #1257 on. https://github.com/kubernetes-sigs/dra-driver-nvidia-gpu/pull/1257 GitHub

Important

Time-slicing l'utilisation du pilote DRA nécessite le TimeSlicingSettings feature gate, qui est une fonctionnalité alpha désactivée par défaut. Si vous demandez la stratégie de TimeSlicing partage sans activer cette fonctionnalité, le pilote ne prépare pas le périphérique et le Pod reste connecté ContainerCreating à un FailedPrepareDynamicResources événement qui le signaleerror validating GPU config: unknown GPU sharing strategy: TimeSlicing. Activez le Feature Gate uniquement si vous acceptez les risques liés à l'utilisation d'une fonctionnalité alpha.

Conditions préalables

  • Cluster Amazon EKS exécutant Kubernetes version 1.34 ou ultérieure. Le pilote NVIDIA DRA est pris en charge avec le provisionnement de capacité statique dans Karpenter, les groupes de nœuds gérés par EKS ou les nœuds autogérés.

  • Nœuds dotés de types d'instances GPU NVIDIA utilisant l'AMI NVIDIA EKS-optimized AL2023.

  • Le pilote NVIDIA DRA a été installé comme décrit dansInstallez le pilote NVIDIA DRA, avec le TimeSlicingSettings Feature Gate activé.

Procédure

  1. Créez un ResourceClaim qui demande un GPU avec la stratégie TimeSlicing de partage. Plusieurs Pods qui font référence à cette affirmation partagent le même GPU physique.

    cat <<EOF | kubectl apply -f - apiVersion: resource.k8s.io/v1 kind: ResourceClaim metadata: name: shared-timeslice-gpu spec: devices: requests: - name: gpu exactly: deviceClassName: gpu.nvidia.com count: 1 config: - requests: ["gpu"] opaque: driver: gpu.nvidia.com parameters: apiVersion: resource.nvidia.com/v1beta1 kind: GpuConfig sharing: strategy: TimeSlicing timeSlicingConfig: interval: Long EOF
  2. Déployez deux pods ou plus qui font référence ResourceClaim au nom partagé. Chaque Pod fait référence à la réclamation via resourceClaims etresources.claims.

    cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: share-a spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["nvidia-smi", "-L"] resources: claims: - name: gpu resourceClaims: - name: gpu resourceClaimName: shared-timeslice-gpu restartPolicy: OnFailure EOF
  3. Vérifiez que les Pods partagent le même processeur graphique physique. Exécutez nvidia-smi -L dans chaque Pod et confirmez qu'ils indiquent le même UUID GPU.

    kubectl logs share-a

    L'exemple qui suit illustre un résultat. Un deuxième Pod qui fait référence à la même réclamation rapporte un GPU UUID identique, ce qui confirme que les deux Pods partagent le même GPU physique.

    GPU 0: NVIDIA L4 (UUID: GPU-b41973ee-5d0a-cde8-6287-12b53f861f02)

Utilisez le découpage temporel du GPU sur les nœuds Bottlerocket avec le plug-in de périphérique NVIDIA

Sur Bottlerocket, l'AMI EKS-optimized accélérée inclut le plug-in de périphérique NVIDIA. Vous activez le découpage temporel dans les settings.kubelet-device-plugins.nvidia paramètres, que Bottlerocket affiche dans la configuration du plug-in de l'appareil lorsque le nœud démarre.

Conditions préalables

  • Un cluster Amazon EKS. La procédure suivante fournit aux nœuds GPU NVIDIA l'AMI NVIDIA EKS-optimized Bottlerocket.

  • Karpenter a été installé et configuré dans votre cluster, car la procédure suivante utilise un Karpenter EC2NodeClass pour fournir les paramètres de découpage temporel dans les données utilisateur du nœud Bottlerocket. Pour plus d'informations, consultez la section Getting Started with Karpenter sur le site Web de Karpenter.

  • kubectlconfiguré pour communiquer avec votre cluster, consultez Installer ou mettre à jour kubectl pour plus d'informations.

Procédure

Ajoutez les paramètres de découpage temporel aux données utilisateur de Bottlerocket pour vos nœuds GPU. L'exemple suivant configure quatre emplacements par GPU. La manière dont vous fournissez les données utilisateur dépend de la manière dont vous approvisionnez les nœuds. L'exemple suivant montre un charpentierEC2NodeClass.

cat <<EOF | kubectl apply -f - apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: gpu-bottlerocket-timeslicing spec: amiFamily: Bottlerocket amiSelectorTerms: - alias: bottlerocket@latest role: eksctl-KarpenterNodeRole-<cluster-name> subnetSelectorTerms: - tags: karpenter.sh/discovery: <cluster-name> securityGroupSelectorTerms: - tags: karpenter.sh/discovery: <cluster-name> userData: | [settings.kubelet-device-plugins.nvidia] device-sharing-strategy = "time-slicing" [settings.kubelet-device-plugins.nvidia.time-slicing] replicas = 4 rename-by-default = false fail-requests-greater-than-one = true EOF

Lorsque les nœuds configurés avec ces paramètres rejoignent le cluster, le plug-in de l'appareil annonce quatre nvidia.com/gpu emplacements pour chaque GPU physique. Vous les demandez dans votre spécification de charge de travail avec des demandes de ressources de conteneur ou des limites pour la ressource nvidia.com/gpu étendue.

Utilisez le découpage temporel du GPU sur les nœuds AL2023 à l'aide du plug-in pour appareils NVIDIA

Sur AL2023, vous installez le plug-in de périphérique NVIDIA comme décrit dansInstallez le plug-in de périphérique NVIDIA Kubernetes, et vous fournissez la configuration de découpage temporel dans un. ConfigMap

Conditions préalables

  • Cluster Amazon EKS avec des nœuds qui utilisent des types d'instances GPU NVIDIA et l'AMI NVIDIA EKS-optimized AL2023.

  • Helm installé dans votre environnement de ligne de commande, consultez les instructions de configuration de Helm pour plus d’informations.Déployez des applications avec Helm sur Amazon EKS

  • kubectlconfiguré pour communiquer avec votre cluster, consultez Installer ou mettre à jour kubectl pour plus d'informations.

Procédure

  1. Créez le découpage temporel ConfigMap dans l'nvidiaespace de noms dans lequel vous avez installé le plug-in de l'appareil. Installez le plug-in de périphérique NVIDIA Kubernetes Cet exemple configure quatre emplacements par GPU.

    cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: name: nvidia-device-plugin-config namespace: nvidia data: config.yaml: | version: v1 sharing: timeSlicing: renameByDefault: false failRequestsGreaterThanOne: true resources: - name: nvidia.com/gpu replicas: 4 EOF
  2. Mettez à jour la version existante du plug-in de périphérique NVIDIA pour faire référence ConfigMap à la config.name valeur. Le --reuse-values drapeau conserve les valeurs que vous avez définies lors de l'installation du plug-in de l'appareil dansInstallez le plug-in de périphérique NVIDIA Kubernetes.

    helm upgrade nvdp nvdp/nvidia-device-plugin \ --namespace nvidia \ --reuse-values \ --set config.name=nvidia-device-plugin-config
Note

Le plug-in de l'appareil ne se recharge pas automatiquement lorsque vous modifiez leConfigMap. Après avoir mis à jour la configuration de découpage temporel, redémarrez le plug-in de l'appareil Pods pour appliquer la modification.

Vérifiez que le découpage temporel du GPU est actif

Une fois vos nœuds découpés dans le tempsReady, vérifiez que le plug-in de l'appareil annonce le nombre d'emplacements prévu et que les Pods partagent un processeur graphique physique.

Note

La vérification de l'UUID partagé dans cette procédure permet de mieux comprendre le découpage dans le temps lorsque les Pods atterrissent sur le même GPU physique. Sur un nœud doté d'un seul GPU, le plug-in de l'appareil annonce quatre emplacements et les quatre Pods partagent ce GPU, de sorte qu'ils signalent le même UUID. Sur un nœud doté de plusieurs GPU physiques, le planificateur peut placer des Pods sur différents GPU. Ces pods signalent différents UUID même si le découpage temporel est actif. Pour démontrer le partage sur un seul GPU, planifiez la charge de travail sur un type d'instance à GPU unique. Par exemple, ajoutez un sélecteur de nœud tel que dans node.kubernetes.io/instance-type: g6.2xlarge la spécification Pod.

  1. Vérifiez que le nœud annonce le nombre configuré d'emplacements GPU. Avec quatre emplacements par processeur graphique, un nœud doté d'un processeur graphique physique génère des rapports4.

    kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"

    L'exemple qui suit illustre un résultat.

    NAME GPU ip-192-168-11-225.us-west-2.compute.internal 4
  2. Créez un déploiement qui exécute quatre répliques, chacune demandant un emplacement GPU.

    cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: timeslicing-demo spec: replicas: 4 selector: matchLabels: app: timeslicing-demo template: metadata: labels: app: timeslicing-demo spec: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule containers: - name: cuda image: nvidia/cuda:12.6.0-base-ubuntu22.04 command: ["bash", "-c", "nvidia-smi --query-gpu=uuid --format=csv,noheader; sleep infinity"] resources: limits: nvidia.com/gpu: 1 EOF
  3. Vérifiez que les quatre Pods sont programmés sur le même nœud.

    kubectl get pods -l app=timeslicing-demo -o wide
  4. Vérifiez que les quatre pods indiquent le même UUID GPU. Un seul UUID partagé entre les quatre Pods confirme qu'un GPU physique est multiplexé dans le temps.

    kubectl logs -l app=timeslicing-demo --prefix

    L'exemple qui suit illustre un résultat.

    [pod/timeslicing-demo-xxxxxxxxxx-aaaaa/cuda] GPU-c0583cce-87c5-c736-db7f-6d3128c84d03 [pod/timeslicing-demo-xxxxxxxxxx-bbbbb/cuda] GPU-c0583cce-87c5-c736-db7f-6d3128c84d03 [pod/timeslicing-demo-xxxxxxxxxx-ccccc/cuda] GPU-c0583cce-87c5-c736-db7f-6d3128c84d03 [pod/timeslicing-demo-xxxxxxxxxx-ddddd/cuda] GPU-c0583cce-87c5-c736-db7f-6d3128c84d03