AWS dévoile un schéma pour partager un même cluster HyperPod EKS entre plusieurs équipes

AWS a publié une architecture de référence permettant de confier en toute sécurité un même cluster Amazon SageMaker HyperPod, orchestré via EKS, à plusieurs équipes à la fois. Le schéma comprend cinq couches : un accès unique via AWS IAM Identity Center, des SageMaker Domains distincts et des espaces de noms Kubernetes pour l'isolation, HyperPod Task Governance pour répartir équitablement les accélérateurs, et une comptabilisation des coûts au niveau du namespace pour la refacturation interne. Cette architecture répond à un problème classique : les GPU sont chers et rares, et allouer un cluster dédié à chaque équipe est du gaspillage.

Pourquoi partager un seul cluster

Quand chaque équipe ML dispose de son propre cluster, un déséquilibre apparaît. Chez les unes, les accélérateurs restent inutilisés la nuit et entre deux expériences ; chez les autres, la file d'attente pour l'entraînement s'étire sur des jours. Les ingénieurs plateforme, eux, administrent plusieurs environnements au lieu d'un seul. Un cluster partagé résout ces deux problèmes, mais soulève trois nouvelles questions. Comment empêcher une équipe d'accéder aux données et aux tâches d'une autre ? Comment éviter qu'une équipe monopolise toutes les ressources ? Qui paie quoi ?

L'architecture d'AWS répond à chaque question avec un composant distinct.

Comment fonctionne l'isolation

Le point d'entrée est AWS IAM Identity Center. Les utilisateurs et les groupes proviennent de l'annuaire d'entreprise, et chaque groupe correspond à une équipe. Il n'est pas nécessaire de créer des comptes AWS distincts, et les droits se révoquent en un seul endroit.

La frontière est ensuite double. Chaque équipe reçoit son propre SageMaker Domain, c'est-à-dire son environnement de travail, avec des profils utilisateur et des rôles d'exécution. En parallèle, un espace de noms Kubernetes lui est créé dans le cluster EKS partagé, où s'exécutent ses tâches. Le Domain détermine ce qu'une personne voit et lance. Le namespace détermine où ces tâches s'exécutent sur le matériel partagé, et avec quelles contraintes.

Équité et argent

L'isolation ne suffit pas : sans règles de répartition du calcul, un cluster partagé se transforme en lutte pour les ressources. C'est là qu'intervient HyperPod Task Governance. Il permet de définir pour chaque équipe un quota de ressources de calcul et des priorités de tâches. La capacité inutilisée des équipes voisines peut être occupée temporairement, et quand son propriétaire la réclame, les tâches les moins prioritaires lui cèdent la place. L'utilisation du cluster augmente ainsi, tandis que la part garantie de chaque équipe est préservée.

La dernière couche est financière. Les coûts sont rattachés au namespace, donc à une équipe précise. C'est la base du chargeback : la comptabilité et les responsables de départements voient qui a consommé quoi, et peuvent émettre des factures internes sans tableurs manuels.

Les éléments clés du schéma :

• Cluster : un seul Amazon SageMaker HyperPod, orchestré via EKS.
• Authentification : AWS IAM Identity Center, avec des groupes correspondant aux équipes.
• Isolation : un SageMaker Domain et un namespace Kubernetes distincts par équipe.
• Équité : HyperPod Task Governance, avec quotas et priorités.
• Finances : répartition des coûts au niveau du namespace.

Par où commencer le déploiement

La source ne décrit que l'architecture ; ce qui suit relève donc de mes conclusions pratiques, et non de données d'AWS.

Commencez par cartographier les équipes et leur consommation réelle. Mieux vaut déduire les quotas de l'historique d'utilisation que des souhaits des responsables, sans quoi il faudra redistribuer dès le lancement. Mettez ensuite d'accord les équipes sur des classes de priorité : ce qui relève de l'entraînement en production, des expériences ou du travail interactif. La préemption des tâches n'est indolore qu'avec des checkpoints réguliers ; il est donc préférable d'imposer à l'avance la sauvegarde de l'état.

Évaluez aussi à part le niveau d'isolation. Les namespaces et les Domains séparent les équipes de façon logique, mais elles restent physiquement sur le même cluster. Pour des données soumises à des exigences strictes de la part des régulateurs, un contrôle supplémentaire ou un cluster dédié peut s'avérer nécessaire. Enfin, validez avec le service financier le modèle de chargeback avant le lancement : ce qui compte exactement comme coût d'une équipe, et comment répartir les frais communs liés aux temps d'inactivité et à l'administration. Techniquement, configurer la comptabilisation par namespace est plus simple que de se mettre d'accord là-dessus au sein de l'entreprise.