Gouvernance des tâches pour le déploiement du modèle sur HyperPod - Amazon SageMaker AI
Comment fonctionne la gestion des charges de travail d’inférenceExemple de configuration des charges de travail d’inférence

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.

Gouvernance des tâches pour le déploiement du modèle sur HyperPod

Cette section explique comment optimiser vos clusters Amazon SageMaker HyperPod EKS partagés pour les charges de travail d'inférence en temps réel. Vous apprendrez à configurer les fonctionnalités de gouvernance des tâches de Kueue, notamment les politiques de gestion des quotas, de planification des priorités et de partage des ressources, afin de garantir que vos charges de travail d’inférence obtiendront les ressources de GPU dont elles ont besoin au cours des pics de trafic, tout en maintenant une répartition équitable entre les activités d’entraînement, d’évaluation et de test de vos équipes. Pour des informations plus générales sur la gouvernance des tâches, consultez SageMaker HyperPod gouvernance des tâches.

Comment fonctionne la gestion des charges de travail d’inférence

Pour gérer efficacement les pics de trafic d'inférence en temps réel dans HyperPod les clusters EKS partagés, mettez en œuvre les stratégies de gouvernance des tâches suivantes en utilisant les fonctionnalités existantes de Kueue.

Configuration des classes prioritaires

Définissez des classes de priorité dédiées pour les charges de travail d’inférence présentant des pondérations élevées (100, par exemple) afin de garantir que les pods d’inférence sont admis et planifiés avant les autres types de tâches. Cette configuration permet aux charges de travail d’inférence de devancer les tâches de moindre priorité lors du chargement du cluster, ce qui est essentiel pour maintenir les exigences de faible latence au cours des pics de trafic.

Dimensionnement et allocation des quotas

Réservez des ressources de GPU suffisantes dans l’élément ClusterQueue de votre équipe pour faire face aux pics d’inférence attendus. Pendant les périodes de faible trafic d’inférence, les ressources de quota inutilisées peuvent être temporairement allouées aux tâches d’autres équipes. Lorsque la demande d’inférence augmente, ces ressources empruntées peuvent être revendiquées pour prioriser les pods d’inférence en attente. Pour plus d’informations, consultez File d’attente de cluster.

Stratégies de partage des ressources

Choisissez entre deux approches de partage de quotas en fonction de vos besoins :

  1. Contrôle strict des ressources : désactivez le prêt et l’emprunt de quotas pour garantir que la capacité de GPU réservée est toujours disponible pour vos charges de travail. Cette approche nécessite de dimensionner des quotas suffisamment importants pour gérer indépendamment les pics de demande et peut entraîner l’inactivité de nœuds au cours des périodes de faible trafic.

  2. Partage flexible des ressources : autorisez l’emprunt de quotas pour tirer parti des ressources inactives d’autres équipes en cas de besoin. Les pods empruntés sont marqués comme préemptables et peuvent être expulsés si l’équipe prêteuse revendique leur capacité.

Préemption au sein de l’équipe

Activez la préemption au sein de l’équipe lorsque vous exécutez des charges de travail mixtes (évaluation, entraînement et inférence) avec le même quota. Cela permet à Kueue de préempter les tâches de moindre priorité au sein de votre équipe afin de prendre en compte les pods d’inférence les plus prioritaires, garantissant ainsi une inférence en temps réel sans dépendre d’un emprunt de quotas externe. Pour plus d’informations, consultez Préemption.

Exemple de configuration des charges de travail d’inférence

L'exemple suivant montre comment Kueue gère les ressources GPU dans un SageMaker HyperPod cluster Amazon partagé.

Configuration du cluster et des politiques

Votre cluster possède la configuration suivante :

  • Équipe A : quota de 10 GPU P4

  • Équipe B : quota de 20 GPU P4

  • Provisionnement statique : pas de mise à l’échelle automatique

  • Capacité totale : 30 P4 GPUs

Le pool de GPU partagé utilise cette politique de priorité :

  1. Inférence en temps réel : Priorité 100

  2. Entraînement : Priorité 75

  3. Évaluation : Priorité 50

Kueue applique les quotas d’équipe et les classes de priorité, avec la préemption et l’emprunt de quotas activés.

État initial : utilisation normale du cluster

Dans le cadre d’opérations normales :

  • L'équipe A exécute des tâches de formation et d'évaluation sur les 10 P4 GPUs

  • L’équipe B exécute l’inférence en temps réel (10 P4) et l’évaluation (10 P4) dans les limites de son quota de 20 GPU.

  • Le cluster est pleinement utilisé avec toutes les tâches admises et en cours.

Pic d'inférence : l'équipe B a besoin de plus GPUs

Lorsque l'équipe B connaît un pic de trafic, des modules d'inférence supplémentaires nécessitent 5 GPUs P4 supplémentaires. Kueue détecte que les nouveaux pods sont :

  • Dans l’espace de noms de l’équipe B

  • Priorité 100 (inférence en temps réel)

  • Admission en attente en raison de contraintes de quotas

Le processus de réponse de Kueue choisit entre deux options :

Option 1 : Emprunt de quotas : si l’équipe A n’utilise que 6 de ses 10 P4, Kueue peut admettre que les pods de l’équipe B utilisent les 4 P4 inactifs. Toutefois, ces ressources empruntées sont préemptables : si l’équipe A soumet des tâches qui consomment la totalité de son quota, Kueue réalise l’éviction des pods d’inférence empruntés par l’équipe B.

Option 2 : Auto-préemption (recommandée) : l’équipe B exécute des tâches d’évaluation de moindre priorité (priorité 50). Lorsque des pods d’inférence hautement prioritaires attendent, Kueue préempte les tâches d’évaluation dans les limites du quota de l’équipe B et admet les pods d’inférence. Cette approche permet une allocation sûre des ressources sans risque d’éviction externe.

Kueue suit un processus en trois étapes pour allouer les ressources :

  1. Contrôle des quotas

    Question : L’équipe B dispose-t-elle d’un quota inutilisé ?

    • Oui → Admettez les pods.

    • Non → Passez à l’étape 2.

  2. Auto-préemption au sein de l’équipe B

    Question : Les tâches de moindre priorité de l’équipe B peuvent-elles être préemptées ?

    • Oui → Préemptez les tâches d’évaluation (priorité 50), libérez 5 P4 et admettez les pods d’inférence.

    • Non → Passez à l’étape 3.

    Cette approche permet de maintenir les charges de travail dans les limites du quota garanti par l’équipe B, évitant ainsi les risques d’éviction externes.

  3. Emprunt auprès d’autres équipes

    Question : Y a-t-il des quotas inutilisés pouvant être empruntés à d’autres équipes ?

    • Oui → Admettez l’utilisation d’un quota emprunté (marqué comme préemptable).

    • Non → Le pod reste à l’état NotAdmitted.