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.
# Stratégies
SageMaker HyperPod La gouvernance des tâches Amazon simplifie l'allocation des ressources de votre cluster Amazon EKS et la hiérarchisation des tâches. Vous trouverez ci-dessous des informations sur les politiques de cluster HyperPod EKS. Pour obtenir des informations sur la configuration de la gouvernance des tâches, consultez [Configuration de la gouvernance des tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md).
Les politiques sont divisées en **Définition des priorités des ressources de calcul** et **Allocation des ressources de calcul**. Les concepts de politique ci-dessous seront organisés dans le contexte de ces politiques.
La **définition des priorités des ressources de calcul**, ou politique de cluster, détermine la manière dont les ressources de calcul inactives sont empruntées et la manière dont les tâches sont priorisées par les équipes.
+ L’**allocation des ressources de calcul inactives** définit la manière dont les ressources de calcul inactives sont allouées entre les équipes. C’est-à-dire comment les ressources de calcul inactives peuvent être empruntées aux équipes. Lorsque vous choisissez une **allocation de ressources de calcul inactives**, vous pouvez choisir entre :
+ **Premier arrivé, premier servi** : lorsque cette option est appliquée, les équipes ne sont pas priorisées les unes par rapport aux autres et chaque tâche entrante a des chances égales d’obtenir des ressources au-delà du quota. Les tâches sont priorisées dans l’ordre de leur soumission. Cela signifie qu’un utilisateur peut être en mesure d’utiliser 100 % des ressources de calcul inactives s’il en fait la demande en premier.
+ **Partage équitable** : lorsque cette option est appliquée, les équipes empruntent les ressources de calcul inactives en fonction du **Partage équitable de la pondération** qui leur a été attribué. Ces pondérations sont définies dans **Allocation de calcul**. Pour plus d’informations sur la façon d’utiliser cela, consultez [Exemples de partage de ressources de calcul inactives](#hp-eks-task-governance-policies-examples).
+ La **priorisation des tâches** définit la manière dont les tâches sont mises en file d’attente à mesure que le calcul devient disponible. Lorsque vous choisissez une **priorisation des tâches**, vous pouvez choisir entre :
+ **Premier arrivé, premier servi** : lorsqu’elles sont appliquées, les tâches sont mises en file d’attente dans l’ordre dans lequel elles sont demandées.
+ **Classement des tâches** : lorsqu’elles sont appliquées, les tâches sont mises en file d’attente dans l’ordre défini par leur ordre de priorité. Si cette option est choisie, vous devez ajouter des classes de priorité aux pondérations pour définir leur ordre de priorité. Les tâches de même classe de priorité seront exécutées selon le principe du premier arrivé, premier servi. Lorsque cette option est activée dans Allocation de calcul, les tâches sont préemptées des tâches les moins prioritaires par des tâches plus prioritaires au sein de l’équipe.
Lorsque les scientifiques des données soumettent des tâches au cluster, ils utilisent le nom de la classe de priorité dans le fichier YAML. La classe de priorité est au format `priority-class-name-priority`. Pour obtenir un exemple, consultez [Soumettre une tâche à une file d'attente et à un SageMaker espace de noms gérés par l'IA](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job).
+ **Classes de priorité** : ces classes établissent une priorité relative pour les tâches lors de l’emprunt d’une capacité. Lorsqu’une tâche est exécutée avec un quota emprunté, elle peut être préemptée par une autre tâche plus prioritaire, si aucune capacité supplémentaire n’est disponible pour la tâche entrante. Si la **préemption** est activée dans **Allocation de calcul**, une tâche plus prioritaire peut également préempter des tâches au sein de sa propre équipe.
+ **Le partage de ressources non allouées** permet aux équipes d'emprunter des ressources de calcul qui ne sont allouées à aucune équipe par le biais de quotas de calcul. Lorsque cette option est activée, la capacité de cluster non allouée devient disponible pour que les équipes puissent l'emprunter automatiquement. Pour de plus amples informations, veuillez consulter [Comment fonctionne le partage des ressources non allouées](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works).
L’**allocation de calcul**, ou le quota de calcul, définit l’allocation de calcul d’une équipe et le poids (ou niveau de priorité) attribué à une équipe pour une allocation de ressources de calcul inactives équitable.
+ **Nom de l’équipe** : le nom de l’équipe. Un **espace de noms** correspondant sera créé, du type `hyperpod-ns-team-name`.
+ **Membres** : membres de l’espace de noms de l’équipe. Vous devrez configurer un contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de data scientists que vous souhaitez intégrer à cette équipe, afin d'exécuter des tâches sur des clusters HyperPod orchestrés avec Amazon EKS. Pour configurer un RBAC Kubernetes, utilisez les instructions fournies dans [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
+ **Partage équitable de la pondération** : il s’agit du niveau de priorité attribué à l’équipe lorsque l’option **Partage équitable** est appliquée pour **Allocation de calcul inactif**. La priorité la plus élevée a une pondération de 100 et la priorité la plus basse une pondération de 0. Une pondération plus élevée permet à une équipe d’accéder plus tôt aux ressources inutilisées dans le cadre d’une capacité partagée. Une pondération nulle correspond à la priorité la plus basse, ce qui signifie que cette équipe sera toujours désavantagée par rapport aux autres équipes.
La pondération équitable donne un avantage comparatif à cette équipe lorsqu’elle est en concurrence avec d’autres pour les ressources disponibles. L’admission donne la priorité aux tâches planifiées par les équipes ayant les pondérations les plus élevées et l’emprunt le plus faible. Par exemple, si l’équipe A a une pondération de 10 et l’équipe B une pondération de 5, l’équipe A aura la priorité pour accéder aux ressources inutilisées (ses tâches seront planifiées avant celles de l’équipe B).
+ **Préemption des tâches** : le calcul est pris en charge par une tâche en fonction de sa priorité. Par défaut, l’équipe qui prête des ressources de calcul inactives préemptera les tâches des autres équipes.
+ **Prêt et emprunt** : comment l’équipe prête ses ressources de calcul inactives et si l’équipe peut emprunter à d’autres équipes.
+ Limite d'**emprunt basée sur le pourcentage : limite** de calcul inutilisée qu'une équipe est autorisée à emprunter, exprimée en pourcentage de son quota garanti. Une équipe peut emprunter jusqu'à 10 000 % du calcul alloué. La valeur que vous indiquez ici est interprétée comme un pourcentage. Par exemple, une valeur de 500 sera interprétée comme 500 %. Ce pourcentage s'applique uniformément à tous les types de ressources (CPU, GPU, mémoire) et à tous les types d'instances inclus dans le quota de l'équipe.
+ Limite d'**emprunt absolue : limite** de calcul inactif qu'une équipe est autorisée à emprunter, définie comme des valeurs de ressources absolues par type d'instance. Cela permet de contrôler de manière granulaire le comportement d'emprunt pour des types d'instances spécifiques. Vous devez spécifier des limites absolues en utilisant le même schéma que le **quota de calcul**, y compris le nombre d'instances, les accélérateurs, les vCPU, la mémoire ou les partitions d'accélérateur. Vous pouvez définir des limites absolues pour un ou plusieurs types d'instances dans le quota de votre équipe.
Pour en savoir plus sur la manière dont ces concepts sont utilisés, tels que les classes de priorité et les espaces de noms, consultez [Exemples de AWS CLI commandes de gouvernance des HyperPod tâches](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md).
## Exemples de partage de ressources de calcul inactives
Le quota réservé total ne doit pas dépasser la capacité disponible du cluster pour cette ressource, afin de garantir une gestion appropriée des quotas. Par exemple, si un cluster comprend 20 instances `ml.c5.2xlarge`, le quota cumulé attribué aux équipes doit rester inférieur à 20.
Si les politiques d’**allocation de calcul** pour les équipes autorisent l’action **Prêter et emprunter** ou **Prêter**, la capacité inutilisée est partagée entre ces équipes. Par exemple, l’option **Prêter et emprunter** est activée pour les équipes A et B. L’équipe A a un quota de 6 mais n’en utilise que 2 pour ses tâches, et l’équipe B a un quota de 5 et en utilise 4 pour ses tâches. Une tâche soumise à l’équipe B nécessite 4 ressources. 3 seront empruntées à l’équipe A.
Si la politique d’**allocation de calcul** d’une équipe est définie sur **Ne pas prêter**, l’équipe ne sera pas en mesure d’emprunter de capacité supplémentaire au-delà de ses propres allocations.
## Comment fonctionne le partage des ressources non allouées
Le partage des ressources non allouées gère automatiquement le pool de ressources qui ne sont allouées à aucun quota de calcul dans votre cluster. Cela signifie qu'il surveille HyperPod en permanence l'état de votre cluster et qu'il met automatiquement à jour la configuration appropriée au fil du temps.
**Configuration initiale**
+ Lorsque vous définissez `IdleResourceSharing` la valeur `Enabled` dans votre ClusterSchedulerConfig (par défaut, c'est le cas`Disabled`), la gouvernance des HyperPod tâches commence à surveiller votre cluster et calcule les ressources inactives disponibles en soustrayant les quotas d'équipe de la capacité totale des nœuds.
+ Le partage des ressources non allouées ClusterQueues est créé pour représenter le pool de ressources empruntables.
+ Lorsque vous activez pour la première fois le partage de ressources non allouées, la configuration de l'infrastructure prend plusieurs minutes. Vous pouvez suivre les progrès par le biais de la politique `Status` et `DetailedStatus` dans ClusterSchedulerConfig.
**Réconciliation continue**
+ HyperPod la gouvernance des tâches surveille en permanence les modifications telles que les ajouts ou suppressions de nœuds et les mises à jour des quotas de files d'attente des clusters.
+ Lorsque des modifications se produisent, le partage des ressources non allouées recalcule le quota et les met à jour. ClusterQueues La réconciliation s'effectue généralement en quelques secondes.
**Surveillance**
Vous pouvez vérifier que le partage des ressources non allouées est entièrement configuré en vérifiant le partage des ressources non allouées : ClusterQueues
```
kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing
```
Lorsque vous voyez ClusterQueues des noms tels que`hyperpod-ns-idle-resource-sharing-cq-1`, le partage de ressources non allouées est actif. Notez que plusieurs partages de ressources non allouées ClusterQueues peuvent exister en fonction du nombre de types de ressources dans votre cluster.
## Éligibilité des nœuds pour le partage de ressources non allouées
Le partage de ressources non allouées inclut uniquement les nœuds qui répondent aux exigences suivantes :
1. **État de prêt pour les nœuds**
+ Les nœuds doivent être en `Ready` état pour contribuer au pool de ressources non allouées.
+ Les nœuds en `NotReady` état ou non prêts sont exclus des calculs de capacité.
+ Lorsqu'un nœud le devient`Ready`, il est automatiquement inclus dans le cycle de réconciliation suivant.
1. **État planifiable du nœud**
+ Les nœuds avec `spec.unschedulable: true` sont exclus du partage des ressources non allouées.
+ Lorsqu'un nœud redevient planifiable, il est automatiquement inclus dans le cycle de réconciliation suivant.
1. **Configuration MIG (nœuds GPU uniquement)**
+ Pour les nœuds GPU dotés d'un partitionnement MIG (GPU multi-instance), l'`nvidia.com/mig.config.state`étiquette doit apparaître `success` pour que le nœud contribue aux profils MIG au partage de ressources non allouées.
+ Ces nœuds seront réessayés automatiquement une fois la configuration MIG terminée avec succès.
1. **Types d'instances pris en charge**
+ L'instance doit être un type d' SageMaker HyperPod instance pris en charge.
+ Consultez la liste des types d'instances pris en charge dans le SageMaker HyperPod cluster.
**Topics**
+ [Exemples de partage de ressources de calcul inactives](#hp-eks-task-governance-policies-examples)
+ [Comment fonctionne le partage des ressources non allouées](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works)
+ [Éligibilité des nœuds pour le partage de ressources non allouées](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-node-eligibility)
+ [Création de politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-create.md)
+ [Modification des politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md)
+ [Suppression de politiques](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md)
+ [Allocation d'un quota de calcul dans le cadre de la gouvernance des SageMaker HyperPod tâches Amazon](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-compute-allocation.md)
# Création de politiques
Vous pouvez créer votre **politique de cluster** et vos configurations d’**allocation de calcul** dans l’onglet **Politiques**. Vous trouverez ci-dessous des instructions sur la création des configurations suivantes.
+ Créez votre **politique de cluster** pour mettre à jour la façon dont les tâches sont priorisées et les ressources de calcul inactives allouées.
+ Créez une **allocation de calcul** pour créer une nouvelle politique d’allocation de ressources de calcul pour une équipe.
**Note**
Lorsque vous créez une **allocation de calcul**, vous devez configurer un contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de data scientists dans l'espace de noms correspondant afin d'exécuter des tâches sur des clusters orchestrés avec Amazon EKS. HyperPod Les espaces de noms ont le format `hyperpod-ns-team-name`. Pour configurer un RBAC Kubernetes, utilisez les instructions fournies dans [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Pour plus d'informations sur les concepts de politique du cluster EKS en matière de gouvernance des HyperPod tâches, consultez[Stratégies](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md).
**Création de politiques de gouvernance des HyperPod tâches**
Cette procédure suppose que vous avez déjà créé un cluster Amazon EKS configuré avec HyperPod. Si vous ne l’avez pas déjà fait, consultez [Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
1. Accédez à la [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/).
1. Dans le volet de navigation de gauche, sous **HyperPodClusters**, choisissez **Cluster Management**.
1. Choisissez votre cluster Amazon EKS dans la liste **SageMaker HyperPoddes clusters**.
1. Choisissez l’onglet **Politiques**.
1. Pour créer votre **politique de cluster** :
1. Choisissez le bouton **Modifier** correspondant pour mettre à jour la façon dont les tâches sont priorisées et les ressources de calcul inactives allouées.
1. Une fois que vous avez apporté vos modifications, choisissez **Soumettre**.
1. Pour créer une **allocation de calcul** :
1.
1. Choisissez le bouton **Créer** correspondant. Vous accédez alors à la page de création de l’allocation de calcul.
1. Une fois que vous avez apporté vos modifications, choisissez **Soumettre**.
# Modification des politiques
Vous pouvez modifier votre **politique de cluster** et vos configurations d’**allocation de calcul** dans l’onglet **Politiques**. Vous trouverez ci-dessous des instructions sur la modification des configurations suivantes.
+ Modifiez votre **politique de cluster** pour mettre à jour la façon dont les tâches sont priorisées et les ressources de calcul inactives allouées.
+ Modifiez l’**allocation de calcul** pour créer une nouvelle politique d’allocation de ressources de calcul pour une équipe.
**Note**
Lorsque vous créez une **allocation de calcul**, vous devez configurer un contrôle d'accès basé sur les rôles (RBAC) Kubernetes pour les utilisateurs de data scientists dans l'espace de noms correspondant afin d'exécuter des tâches sur des clusters orchestrés avec Amazon EKS. HyperPod Les espaces de noms ont le format `hyperpod-ns-team-name`. Pour configurer un RBAC Kubernetes, utilisez les instructions fournies dans [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Pour plus d'informations sur les concepts de politique du cluster EKS en matière de gouvernance des HyperPod tâches, consultez[Stratégies](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md).
**Modifier les politiques de gouvernance des HyperPod tâches**
Cette procédure suppose que vous avez déjà créé un cluster Amazon EKS configuré avec HyperPod. Si vous ne l’avez pas déjà fait, consultez [Création d'un SageMaker HyperPod cluster avec l'orchestration Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
1. Accédez à la [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/).
1. Dans le volet de navigation de gauche, sous **HyperPodClusters**, choisissez **Cluster Management**.
1. Choisissez votre cluster Amazon EKS dans la liste **SageMaker HyperPoddes clusters**.
1. Choisissez l’onglet **Politiques**.
1. Pour modifier votre **politique de cluster** :
1. Choisissez le bouton **Modifier** correspondant pour mettre à jour la façon dont les tâches sont priorisées et les ressources de calcul inactives allouées.
1. Une fois que vous avez apporté vos modifications, choisissez **Soumettre**.
1. Pour modifier votre **allocation de calcul** :
1.
1. Choisissez la configuration que vous souhaitez modifier sous **Allocation de calcul**. Vous accédez alors à la page des détails de configuration.
1. Si vous souhaitez modifier ces configurations, choisissez **Modifier**.
1. Une fois que vous avez apporté vos modifications, choisissez **Soumettre**.
# Suppression de politiques
Vous pouvez supprimer votre **politique de cluster** et vos configurations d'**allocation de calcul** à l'aide de la console SageMaker AI ou AWS CLI. La page suivante fournit des instructions sur la façon de supprimer vos politiques et configurations de gouvernance des SageMaker HyperPod tâches.
Pour plus d'informations sur les concepts de politique du cluster EKS en matière de gouvernance des HyperPod tâches, consultez[Stratégies](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md).
**Note**
Si vous rencontrez des problèmes pour répertorier ou supprimer les politiques de gouvernance des tâches, vous devrez peut-être mettre à jour votre ensemble minimal d’autorisations d’administrateur de cluster. Consultez l’onglet **Amazon EKS** dans la section [Utilisateurs IAM pour l’administrateur de cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Pour plus d’informations, consultez [Suppression de clusters](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md#hp-eks-troubleshoot-delete-policies).
## Supprimer les politiques de gouvernance des HyperPod tâches (console)
Ce qui suit utilise la console SageMaker AI pour supprimer vos politiques de gouvernance des HyperPod tâches.
**Note**
Vous ne pouvez pas supprimer votre **politique de cluster** (`ClusterSchedulerConfig`) à l'aide de la console SageMaker AI. Pour savoir comment procéder à l'aide du AWS CLI, voir[Supprimer les politiques de gouvernance des HyperPod tâches (AWS CLI)](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete-cli).
**Pour supprimer des politiques de gouvernance des tâches (console)**
1. Accédez à la [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/).
1. Dans le volet de navigation de gauche, sous **HyperPodClusters**, choisissez **Cluster Management**.
1. Choisissez votre cluster Amazon EKS dans la liste **SageMaker HyperPoddes clusters**.
1. Choisissez l’onglet **Politiques**.
1. Pour supprimer votre **allocation de calcul** (`ComputeQuota`) :
1. Dans la section **Allocation de calcul**, sélectionnez la configuration que vous souhaitez supprimer.
1. Dans le menu déroulant **Actions**, choisissez **Supprimer**.
1. Suivez les instructions fournies dans l’interface utilisateur pour réaliser la tâche.
## Supprimer les politiques de gouvernance des HyperPod tâches (AWS CLI)
Ce qui suit utilise le AWS CLI pour supprimer vos politiques de gouvernance des HyperPod tâches.
**Note**
Si vous rencontrez des problèmes lors de l'utilisation des commandes suivantes, vous devrez peut-être mettre à jour votre AWS CLI. Pour plus d’informations, consultez [Installation ou mise à jour de la version la plus récente de l’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Pour supprimer des politiques de gouvernance des tâches (AWS CLI)**
Définissez d'abord vos variables pour les AWS CLI commandes qui suivent.
```
REGION=aws-region
```
1. Obtenez le *cluster-arn* code associé aux politiques que vous souhaitez supprimer. Vous pouvez utiliser la AWS CLI commande suivante pour répertorier les clusters de votre Région AWS.
```
aws sagemaker list-clusters \
--region ${REGION}
```
1. Pour supprimer vos allocations de calcul (`ComputeQuota`) :
1. Répertoriez tous les quotas de calcul associés au HyperPod cluster.
```
aws sagemaker list-compute-quotas \
--cluster-arn cluster-arn \
--region ${REGION}
```
1. Pour chaque `compute-quota-id` que vous souhaitez supprimer, exécutez la commande suivante pour supprimer le quota de calcul.
```
aws sagemaker delete-compute-quota \
--compute-quota-id compute-quota-id \
--region ${REGION}
```
1. Pour supprimer vos politiques de cluster (`ClusterSchedulerConfig`) :
1. Répertoriez toutes les politiques de cluster associées au HyperPod cluster.
```
aws sagemaker list-cluster-scheduler-configs \
--cluster-arn cluster-arn \
--region ${REGION}
```
1. Pour chaque `cluster-scheduler-config-id` que vous souhaitez supprimer, exécutez la commande suivante pour supprimer le quota de calcul.
```
aws sagemaker delete-cluster-scheduler-config
--cluster-scheduler-config-id scheduler-config-id \
--region ${REGION}
```
# Allocation d'un quota de calcul dans le cadre de la gouvernance des SageMaker HyperPod tâches Amazon
Les administrateurs de clusters peuvent décider de la manière dont l’entreprise utilise le calcul acheté. Cela permet de réduire le gaspillage et les ressources inactives. Vous pouvez allouer un quota de calcul afin que les équipes puissent emprunter les ressources inutilisées les unes des autres. L'allocation de quotas de calcul dans le cadre de la gouvernance des HyperPod tâches permet aux administrateurs d'allouer des ressources au niveau de l'instance et à un niveau de ressources plus granulaire. Cette fonctionnalité permet une gestion flexible et efficace des ressources par les équipes en permettant un contrôle granulaire des ressources de calcul individuelles au lieu d’exiger des allocations d’instances complètes. L’allocation à un niveau granulaire élimine les inefficacités de l’allocation traditionnelle au niveau de l’instance. Grâce à cette approche, vous pouvez optimiser l’utilisation des ressources et réduire les ressources de calcul inactives.
L’allocation de quotas de calcul prend en charge trois types d’allocation de ressources : accélérateurs, vCPU et mémoire. Les accélérateurs sont des composants d’instances de calcul accéléré qui exécutent des fonctions telles que les calculs en virgule flottante, le traitement graphique ou la mise en correspondance de modèles de données. Les accélérateurs incluent les GPUs accélérateurs Trainium et les cœurs de neurones. Pour le partage de GPU entre plusieurs équipes, différentes équipes peuvent recevoir des allocations de GPU spécifiques à partir du même type d’instance, maximisant ainsi l’utilisation du matériel des accélérateurs. Pour les charges de travail gourmandes en mémoire qui nécessitent de la RAM supplémentaire pour le prétraitement des données ou les scénarios de mise en cache des modèles, vous pouvez allouer un quota de mémoire supérieur au ratio par défaut. GPU-to-memory Pour les tâches de prétraitement gourmandes en ressources CPU qui nécessitent des ressources CPU importantes en plus de l’entraînement GPU, vous pouvez allouer une allocation de ressources CPU indépendante.
Une fois que vous avez fourni une valeur, la gouvernance des HyperPod tâches calcule le ratio à l'aide de la formule **ressource allouée divisée par la quantité totale de ressources disponibles dans l'instance**. HyperPod la gouvernance des tâches utilise ensuite ce ratio pour appliquer des allocations par défaut à d'autres ressources, mais vous pouvez remplacer ces valeurs par défaut et les personnaliser en fonction de votre cas d'utilisation. Voici des exemples de scénarios illustrant la manière dont la gouvernance des HyperPod tâches alloue les ressources en fonction de vos valeurs :
+ **Seul l'accélérateur est spécifié** : la gouvernance des HyperPod tâches applique le ratio par défaut au vCPU et à la mémoire en fonction des valeurs de l'accélérateur.
+ **Seul le vCPU est spécifié** : la gouvernance des HyperPod tâches calcule le ratio et l'applique à la mémoire. Les accélérateurs sont définis sur 0.
+ **Seule la mémoire est spécifiée** : la gouvernance des HyperPod tâches calcule le ratio et l'applique au vCPU car le calcul est nécessaire pour exécuter les charges de travail spécifiées par la mémoire. Les accélérateurs sont définis sur 0.
Pour contrôler l'allocation de quotas par programme, vous pouvez utiliser l'[ ComputeQuotaResourceConfig](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ComputeQuotaResourceConfig.html)objet et spécifier vos allocations en nombres entiers.
```
{
"ComputeQuotaConfig": {
"ComputeQuotaResources": [{
"InstanceType": "ml.g5.24xlarge",
"Accelerators": "16",
"vCpu": "200.0",
"MemoryInGiB": "2.0"
}]
}
}
```
Pour voir toutes les allocations allouées, y compris les valeurs par défaut, utilisez l'[ DescribeComputeQuota](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeComputeQuota.html)opération. Pour mettre à jour vos allocations, utilisez l'[ UpdateComputeQuota](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateComputeQuota.html)opération.
Vous pouvez également utiliser la HyperPod CLI pour allouer des quotas de calcul. Pour plus d'informations sur la HyperPod CLI, consultez[Exécution de tâches sur SageMaker HyperPod des clusters orchestrés par Amazon EKS](sagemaker-hyperpod-eks-run-jobs.md). L'exemple suivant montre comment définir des quotas de calcul à l'aide de la HyperPod CLI.
```
hyp create hyp-pytorch-job --version 1.1 --job-name sample-job \
--image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \
--pull-policy "Always" \
--tasks-per-node 1 \
--max-retry 1 \
--priority high-priority \
--namespace hyperpod-ns-team-name \
--queue-name hyperpod-ns-team-name-localqueue \
--instance-type sample-instance-type \
--accelerators 1 \
--vcpu 3 \
--memory 1 \
--accelerators-limit 1 \
--vcpu-limit 4 \
--memory-limit 2
```
Pour allouer des quotas à l'aide de la AWS console, procédez comme suit.
1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Sous HyperPod clusters, choisissez **Cluster management**.
1. Sous **Allocations de calcul**, choisissez **Créer**.
1. Si vous n’avez pas encore d’instances, choisissez **Ajouter une allocation** pour ajouter une instance.
1. Sous **Allocations**, choisissez d’allouer par instances ou par ressources individuelles. Si vous allouez par ressources individuelles, l' SageMaker IA affecte automatiquement des allocations aux autres ressources selon le ratio que vous avez choisi. Pour annuler cette allocation basée sur le ratio, utilisez le bouton correspondant pour annuler ce calcul.
1. Répétez les étapes 4 e 5 pour configurer des instances supplémentaires.
Après avoir alloué le quota de calcul, vous pouvez ensuite soumettre des tâches via la HyperPod CLI ou`kubectl`. HyperPodplanifie efficacement les charges de travail en fonction du quota disponible.
# Allocation d'un quota de partition GPU
Vous pouvez étendre l'allocation de quotas de calcul pour prendre en charge le partitionnement du GPU, permettant ainsi un partage précis des ressources au niveau de la partition du GPU. Lorsque le partitionnement du GPU est activé ou pris GPUs en charge dans le cluster, chaque GPU physique peut être partitionné en plusieurs processeurs isolés GPUs avec des allocations multiprocesseurs définies pour le calcul, la mémoire et le streaming. Pour plus d'informations sur le partitionnement du GPU, consultez[Utilisation de partitions GPU dans Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md). Vous pouvez attribuer des partitions GPU spécifiques à des équipes, ce qui permet à plusieurs équipes de partager un seul GPU tout en maintenant une isolation matérielle et des performances prévisibles.
Par exemple, une instance ml.p5.48xlarge avec 8 H100 GPUs peut être partitionnée en partitions GPU, et vous pouvez allouer des partitions individuelles à différentes équipes en fonction de leurs exigences en matière de tâches. Lorsque vous spécifiez les allocations de partition GPU, la gouvernance des HyperPod tâches calcule les quotas de vCPU et de mémoire proportionnels en fonction de la partition GPU, de la même manière que l'allocation au niveau du GPU. Cette approche maximise l'utilisation du GPU en éliminant les capacités inutilisées et en permettant un partage rentable des ressources entre plusieurs tâches simultanées sur le même GPU physique.
## Création de quotas de calcul
```
aws sagemaker create-compute-quota \
--name "fractional-gpu-quota" \
--compute-quota-config '{
"ComputeQuotaResources": [
{
"InstanceType": "ml.p4d.24xlarge",
"AcceleratorPartition": {
"Count": 4,
"Type": "mig-1g.5gb"
}
}
],
"ResourceSharingConfig": {
"Strategy": "LendAndBorrow",
"BorrowLimit": 100
}
}'
```
## Vérification des ressources de quota
```
# Check ClusterQueue
kubectl get clusterqueues
kubectl describe clusterqueue QUEUE_NAME
# Check ResourceFlavors
kubectl get resourceflavor
kubectl describe resourceflavor FLAVOR_NAME
```