À propos des stratégies de partage de GPU dans GKE

Cette page décrit et compare les stratégies de partage de GPU disponibles dans Google Kubernetes Engine (GKE). Dans cette page, nous partons du principe que vous maîtrisez les concepts de Kubernetes tels que les pods, les nœuds, les déploiements et les espaces de noms, et que vous connaissez les concepts de GKE tels que les pools de nœuds, l'autoscaling et le provisionnement automatique des nœuds.

Fonctionnement des demandes de GPU dans Kubernetes

Kubernetes permet aux charges de travail de demander précisément les quantités de ressources dont elles ont besoin pour fonctionner. Bien que vous puissiez demander des unités de processeur fractionnaires pour les charges de travail, vous ne pouvez pas demander d'unités de GPU fractionnaires. Les fichiers manifestes de pod doivent demander des ressources GPU en nombres entiers, ce qui signifie que la totalité d'un GPU physique est alloué à un conteneur, même si une seule fraction des ressources est nécessaire au bon fonctionnement du conteneur. Cela est inefficace et peut s'avérer coûteux, en particulier lorsque vous exécutez plusieurs charges de travail avec des exigences de GPU similaires. Nous vous recommandons d'utiliser des stratégies de partage de GPU pour améliorer l'utilisation des GPU lorsque vos charges de travail n'utilisent pas toutes les ressources GPU.

Que sont les stratégies de partage de GPU ?

Les stratégies de partage de GPU permettent à plusieurs conteneurs d'utiliser efficacement les GPU associés et de réduire les coûts d'exploitation. GKE propose les stratégies de partage de GPU suivantes:

  • GPU multi-instance: GKE divise un seul GPU compatible en sept tranches maximum. Chaque tranche peut être allouée à un conteneur du nœud de manière indépendante, pour un maximum de sept conteneurs par GPU. Les GPU multi-instances fournissent une isolation matérielle entre les charges de travail, et une qualité de service (QoS) cohérente et prévisible pour tous les conteneurs exécutés sur le GPU.
  • Temps partagé des GPU: GKE utilise la fonctionnalité intégrée de temps partagé fournie par le GPU NVIDIA et la pile logicielle. À partir de l'architecture Pascal, les GPU NVIDIA sont compatibles avec la préemption au niveau des instructions. Lorsque vous effectuez un changement de contexte entre des processus exécutés sur un GPU, la préemption au niveau de l'instruction garantit que chaque processus dispose d'une tranche horaire équitable. Le temps partagé des GPU fournit une isolation logicielle entre les charges de travail pour ce qui est de l'espace d'adressage, des performances et des erreurs.
  • NVIDIA MPS : GKE utilise le service multi-processus (MPS) de NVIDIA. NVIDIA MPS est une autre mise en œuvre de l'API CUDA compatible binaire, conçue pour permettre aux charges de travail CUDA coopératives multiprocessus de s'exécuter simultanément sur un seul appareil GPU de manière transparente. Les GPU avec NVIDIA MPS fournissent une isolation logicielle pour ce qui est des limites de ressources (pourcentage de threads actifs et mémoire d'appareil épinglé).

Quelle stratégie de partage de GPU utiliser ?

Le tableau suivant récapitule et compare les caractéristiques des stratégies de partage de GPU disponibles:

GPU multi-instance Temps partagé des GPU NVIDIA MPS
Général Partage de GPU en parallèle entre les conteneurs Changement de contexte rapide. Partage de GPU en parallèle entre les conteneurs
Isolation Un seul GPU est divisé en sept tranches maximum, et chaque conteneur du même GPU physique dispose d'une capacité de calcul, de mémoire et de bande passante dédiées. Par conséquent, un conteneur dans une partition a un débit et une latence prévisibles, même lorsque d'autres conteneurs saturent d'autres partitions.

Chaque conteneur accède à toute la capacité du GPU physique sous-jacent en basculant de contexte entre les processus exécutés sur un GPU.

Cependant, le temps partagé n'applique aucune limitation de mémoire entre les jobs partagés. De plus, le changement de contexte rapide pour l'accès partagé peut entraîner des frais.

 NVIDIA MPS offre une isolation limitée des ressources, mais gagne en flexibilité dans d'autres aspects, tels que les types de GPU et le nombre maximal d'unités partagées, ce qui simplifie l'allocation des ressources.
Convient à ces charges de travail Option recommandée pour les charges de travail exécutées en parallèle et nécessitant une certaine résilience et qualité de service. Par exemple, lorsque vous exécutez des charges de travail d'inférence d'IA, les GPU multi-instances permettent d'exécuter simultanément plusieurs requêtes d'inférence pour obtenir des réponses rapides, sans ralentir mutuellement.

Option recommandée pour les charges de travail intensives et interactives avec des périodes d'inactivité. Ces charges de travail ne sont pas rentables avec un GPU entièrement dédié. Le partage de temps permet aux charges de travail d'accéder rapidement au GPU lorsqu'elles sont en phase d'activité.

Le temps partagé des GPU est optimal pour les scénarios dans lesquels l'isolation complète et l'accès continu aux GPU ne sont pas nécessaires, par exemple lorsque plusieurs utilisateurs testent ou prototypent des charges de travail sans ralentir les GPU.

Les charges de travail qui utilisent le temps partagé doivent tolérer certains compromis en matière de performances et de latence.

Recommandé pour le traitement par lot pour les petites tâches, car MPS optimise le débit et l'utilisation simultanée d'un GPU. MPS permet aux tâches par lot de traiter efficacement et en parallèle des charges de travail de petite à moyenne taille.

NVIDIA MPS est optimal pour les processus collaboratifs agissant en tant qu'application unique. Par exemple, les tâches MPI avec parallélisme de classement inter-MPI. Avec ces tâches, chaque petit processus CUDA (généralement des classements MPI) peut s'exécuter simultanément sur le GPU pour saturer complètement l'ensemble du GPU.

Les charges de travail qui utilisent CUDA MPS doivent tolérer les limites de protection de la mémoire et de confinement des erreurs.

Surveillance Les métriques d'utilisation du GPU ne sont pas disponibles pour les GPU multi-instances. Utilisez Cloud Monitoring pour surveiller les performances de votre temps partagé des GPU. Pour en savoir plus sur les métriques disponibles, consultez la page Surveiller le temps partagé des GPU ou les nœuds MPS NVIDIA. Utilisez Cloud Monitoring pour surveiller les performances de vos MPS NVIDIA. Pour en savoir plus sur les métriques disponibles, consultez la page Surveiller le temps partagé des GPU ou les nœuds MPS NVIDIA.
Demander des GPU partagés dans les charges de travail Exécuter des GPU multi-instances Exécuter des GPU en mode temps partagé Exécuter des GPU avec NVIDIA MPS

Si vous souhaitez optimiser l'utilisation des GPU, vous pouvez combiner les stratégies de partage de GPU afin d'utiliser le partage de temps ou les MPS NVIDIA pour chaque partition de GPU multi-instance. Vous pouvez ensuite exécuter plusieurs conteneurs sur chaque partition, ceux-ci partageant un accès aux ressources de cette partition. Nous vous recommandons d'utiliser l'une des combinaisons suivantes:

  • GPU multi-instances et temps partagé des GPU.
  • GPU multi-instances et NVIDIA MPS.

Fonctionnement des stratégies de partage de GPU

Vous pouvez spécifier le nombre maximal de conteneurs autorisés à partager un GPU physique. Sur les clusters Autopilot, cette configuration est configurée dans la spécification de votre charge de travail. Sur les clusters standards, cette configuration est effectuée lorsque vous créez un pool de nœuds auquel sont associés des GPU. Chaque GPU du pool de nœuds est partagé en fonction du paramètre que vous spécifiez au niveau du pool de nœuds.

Les sections suivantes expliquent le comportement de planification et le fonctionnement de chaque stratégie de partage de GPU.

GPU multi-instance

Vous pouvez demander un GPU multi-instance dans les charges de travail en spécifiant le libellé cloud.google.com/gke-gpu-partition-size dans le champ nodeSelector de la spécification de pod, sous spec: nodeSelector.

GKE planifie les charges de travail dans les nœuds disponibles correspondant à ces libellés. Si aucun nœud n'est disponible, GKE utilise l'autoscaling et le provisionnement automatique des nœuds pour créer des nœuds ou des pools de nœuds correspondant à ce libellé.

Temps partagé des GPU ou NVIDIA MPS

Vous pouvez demander le temps partagé des GPU ou NVIDIA MPS dans les charges de travail en spécifiant les libellés suivants dans le champ nodeSelector de la spécification de pod, sous spec:nodeSelector.

  • cloud.google.com/gke-max-shared-clients-per-gpu : sélectionne des nœuds qui permettent à un nombre spécifique de clients de partager le GPU sous-jacent.
  • cloud.google.com/gke-gpu-sharing-strategy: sélectionne des nœuds qui utilisent la stratégie à temps partagé ou NVIDIA MPS pour les GPU.

Le tableau suivant décrit la façon dont le comportement de planification change en fonction de la combinaison de libellés de nœuds que vous spécifiez dans vos fichiers manifestes.

Libellés de nœuds
cloud.google.com/gke-max-shared-clients-per-gpu

et

cloud.google.com/gke-gpu-sharing-strategy

GKE programme les charges de travail sur les nœuds disponibles correspondant aux deux libellés.

Si aucun nœud n'est disponible, GKE utilise l'autoscaling et le provisionnement automatique des nœuds pour créer des nœuds ou des pools de nœuds correspondant aux deux libellés.
uniquement cloud.google.com/gke-max-shared-clients-per-gpu

Autopilot : GKE rejette la charge de travail.

Standard : GKE planifie les charges de travail sur les nœuds disponibles correspondant au libellé. Si aucun nœud n'est disponible, GKE utilise l'autoscaling et le provisionnement automatique des nœuds pour créer des nœuds ou des pools de nœuds correspondant au libellé. Par défaut, les nœuds provisionnés automatiquement reçoivent le libellé et la valeur suivants pour chaque stratégie:

  • temps partagé des GPU: cloud.google.com/gke-gpu-sharing-strategy=TIME_SHARING
  • NVIDIA MPS: cloud.google.com/gke-gpu-sharing-strategy=MPS
uniquement cloud.google.com/gke-gpu-sharing-strategy

Autopilot : GKE rejette la charge de travail.

Standard: GKE planifie les charges de travail dans les nœuds disponibles qui utilisent des stratégies de partage spécifiques.

  • S'il existe plusieurs pools de nœuds partagés avec des valeurs différentes pour cloud.google.com/gke-max-shared-clients-per-gpu, la charge de travail peut être planifiée sur n'importe quel nœud disponible.
  • Si aucun nœud n'est disponible dans l'un des pools de nœuds, l'autoscaler de cluster effectue un scaling à la hausse du pool de nœuds avec la valeur la plus faible pour cloud.google.com/gke-max-shared-clients-per-gpu.
  • Si tous les pools de nœuds sont saturés, le provisionnement automatique des nœuds crée un pool de nœuds avec la valeur par défaut cloud.google.com/gke-max-shared-clients-per-gpu=2.

Le processus de demande de GPU que vous effectuez est le même pour les stratégies de temps partagé des GPU et NVIDIA MPS. Si vous développez des applications GPU qui s'exécutent sur temps partagé des GPU ou NVIDIA MPS, vous ne pouvez demander qu'un seul GPU par conteneur. GKE rejette une demande nécessitant plusieurs GPU dans un conteneur afin d'éviter tout comportement inattendu, et parce que le nombre de temps partagé des GPU et de NVIDIA MPS demandé n'est pas une mesure de la puissance de calcul disponible pour le conteneur.

Le tableau suivant montre ce qui se passe lorsque vous demandez des quantités spécifiques de GPU.

Demandes de GPU qui s'appliquent au temps partagé des GPU et aux NVIDIA MPS
Un GPU à temps partagé ou NVIDIA MPS par conteneur GKE autorise la requête, même si le nœud dispose d'un ou de plusieurs GPU physiques.
Plusieurs GPU à temps partagé par conteneur

GKE rejette la requête.

Ce comportement inclut la demande de plusieurs instances de GPU multi-instances dans un conteneur, car chaque instance de GPU est considérée comme un GPU physique distinct.
Plusieurs MPS NVIDIA par conteneur

En fonction du nombre de GPU physiques dans le nœud, GKE effectue les opérations suivantes:

  • GKE autorise la requête lorsque le nœud ne dispose que d'un seul GPU physique.
  • GKE rejette la requête lorsque le nœud possède plusieurs GPU physiques, par exemple lorsque vous demandez plusieurs instances de GPU multi-instances dans un conteneur. Ce refus se produit, car chaque instance de GPU est considérée comme un GPU physique distinct.

Si GKE rejette la charge de travail, un message d'erreur semblable à celui-ci s'affiche:

status:
  message: 'Pod Allocate failed due to rpc error: code = Unknown desc = [invalid request
    for sharing GPU (time-sharing), at most 1 nvidia.com/gpu can be requested on GPU nodes], which is unexpected'
  phase: Failed
  reason: UnexpectedAdmissionError

Surveiller les nœuds à temps partagé des GPU ou les nœuds NVIDIA MPS

Utilisez Cloud Monitoring pour surveiller les performances de vos nœuds GPU à temps partagé ou nœuds NVIDIA MPS. GKE envoie des métriques pour chaque nœud GPU à Cloud Monitoring. Ces métriques sont différentes des métriques des GPU standards qui ne sont pas à temps partagé ou des nœuds MPS NVIDIA.

Vous pouvez vérifier les métriques suivantes pour chaque nœud GPU à temps partagé ou NVIDIA MPS dans Cloud Monitoring:

  • Cycle d'utilisation (node/accelerator/duty_cycle): durée exprimée en pourcentage de la dernière période d'échantillonnage (10 secondes) pendant laquelle le nœud GPU a été en mode de traitement actif. Les valeurs vont de 1 % à 100 %.
  • Utilisation de la mémoire (node/accelerator/memory_used): quantité de mémoire d'accélérateur allouée, en octets, pour chaque nœud GPU.
  • Capacité de mémoire (node/accelerator/memory_total): mémoire totale de l'accélérateur, en octets, pour chaque nœud GPU.

Ces métriques de nœud GPU à temps partagé ou NVIDIA MPS s'appliquent au niveau du nœud (node/accelerator/) et les métriques pour GPU physiques standards s'appliquent au niveau du conteneur (container/accelerator). Les métriques pour les GPU physiques standards sont les suivantes: non collectées pour les conteneurs programmés sur un GPU qui utilise le mode GPU à temps partagé ou NVIDIA MPS.

Étapes suivantes