AWS détaille le plan de contrôle open source HyperPod InstantStart pour les opérations d’agent

Amazon Web Services a détaillé HyperPod InstantStart, un plan de contrôle open source qui combine l’orchestration Amazon EKS avec les capacités gérées d’Amazon SageMaker HyperPod, dans un article du blog AWS Machine Learning publié le 4 septembre 2026. Le projet associe une interface web à un agent IA qui planifie et exécute des opérations de cluster à plusieurs étapes via les outils du Model Context Protocol.

InstantStart fonctionne comme un seul conteneur de gestion hors bande au sein du compte AWS d’un utilisateur, appelant les API des services AWS et l’API Kubernetes sans se placer dans le chemin de données des travaux d’entraînement ou des requêtes d’inférence. Chaque ressource qu’il crée est un objet standard AWS ou Kubernetes qui reste inspectable avec l’AWS Command Line Interface et kubectl. L’interface web, une API REST et les outils MCP utilisés par l’agent sont les trois facettes du même conteneur, de sorte que les deux interfaces passent par le même backend et subissent les mêmes validations.

Un seul backend derrière deux interfaces

L’argument de conception central de l’article est que les outils MCP encapsulent les propres API REST du plan de contrôle plutôt que l’AWS CLI ou le SDK, de sorte qu’une validation ajoutée une fois protège à la fois le navigateur et l’agent. Dans l’interface web, créer un cluster avec les dépendances installées, la récupération automatique des nœuds activée et le stockage monté se présente sous la forme d’un formulaire et d’un panneau de progression ; dans un terminal, il s’agit d’une phrase en langage naturel adressée à une configuration d’agent appelée hypd-inst-agent, construite pour Kiro CLI. L’agent enchaîne ensuite le travail: création du plan de contrôle EKS, sélection du cluster actif, réconciliation des dépendances, création du cluster HyperPod et configuration du stockage. AWS indique que la création du plan de contrôle EKS se termine en environ 8 à 12 minutes, et chaque étape ultérieure enregistre son propre statut et peut être relancée de façon indépendante.

Trois règles de flux de travail sont codées dans les compétences d’agent du projet, que l’article décrit comme des playbooks markdown versionnés dans le dépôt. L’agent interroge chaque opération de longue durée jusqu’à un état terminal plutôt que de signaler une requête soumise. Il ne pose que des questions de type décision, telles que Zone de disponibilité, type d’instance et type de capacité, tout en traitant les CIDR de sous‑réseau, les tables de routage et les groupes de sécurité comme du travail du plan de contrôle. Et il inspecte avant de créer, en listant les clusters existants et en interrogeant les zones et types d’instance valides avant de proposer des choix.

Capacités gérées comme état réconcilié

InstantStart crée des clusters HyperPod avec la récupération automatique des nœuds activée, sous laquelle HyperPod peut redémarrer ou remplacer les nœuds défectueux en se basant sur son agent de surveillance de santé, des vérifications de santé de base et des vérifications de santé approfondies optionnelles qui soumettent les GPU et la connectivité Elastic Fabric Adapter à des tests de contrainte avant que les nœuds n’acceptent du travail. Lorsqu’un utilisateur ajoute un groupe d’instances, le type de capacité, le mode d’interface réseau et le placement du sous‑réseau sont réglés comme une opération unique de création ; le type de capacité et le mode d’interface uniquement EFA sont fixes pendant toute la durée du groupe. Le plan de contrôle dirige chaque chemin de capacité via une fonction unique qui provisionne des sous‑réseaux de calcul de taille /20 pour de grands flottes d’accélérateurs.

Le dimensionnement automatique des nœuds basé sur Karpenter géré par HyperPod décide de la quantité de capacité utilisée à chaque instant, AWS gérant le contrôleur Karpenter lui‑même et les nœuds se lançant à partir des groupes d’instances HyperPod mis à l’échelle depuis zéro. L’article indique une limite de portée: Karpenter géré gère les groupes d’instances HyperPod, pas la capacité Amazon EC2 à usage général.

Le panneau Fonctionnalités avancées expose les capacités gérées de HyperPod, notamment l’opérateur d’entraînement, l’opérateur d’inférence, la mise en point en niveaux gérée et le dimensionnement automatique géré, chaque bascule étant associée à une opération backend consciente des dépendances. Activer la mise en point en niveaux provisionne une chaîne d’identité couvrant un compte de service Kubernetes, un rôle et une politique IAM, une relation de confiance OpenID Connect et l’annotation de liaison, et la désactiver supprime la même chaîne. L’article décrit également un contrat de diff explicite adopté après un bug précoce: l’interface ne soumet que les champs réellement modifiés par l’utilisateur, et le backend lit l’état réel du cluster et ne fait rien lorsque l’état demandé et l’état réel correspondent déjà.

Chemins d’entraînement et d’inférence

Pour l’entraînement, InstantStart propose deux voies de soumission. L’opérateur d’entraînement HyperPod, installé comme module complémentaire EKS, ajoute la récupération de pannes au niveau du processus, la détection de jobs bloqués via la surveillance de motifs de logs et la détection d’anomalies, le travail étant soumis sous forme de ressources HyperPodPyTorchJob disposant d’un budget de récupération visible. La deuxième voie est le KubeRay standard, destiné aux charges de travail natives Ray telles que l’apprentissage par renforcement. Au-dessus des deux se trouve une couche de recettes pour les scripts PyTorch simples, LLaMA-Factory, MS‑Swift et l’apprentissage par renforcement VERL, toutes partageant un même contrat de données où le même bucket Amazon S3 est monté dans l’environnement de développement et à l’intérieur des pods. Les journaux des jobs sont diffusés vers le navigateur via WebSocket, et les recettes peuvent rapporter des métriques telles que le débit d’entraînement vers le MLflow géré sur Amazon SageMaker AI.

L’inférence possède également deux voies. La voie gérée confie le cycle de vie à l’opérateur d’inférence HyperPod, avec une mise en cache KV en niveaux gérée et des stratégies de routage intelligentes déclarées aux côtés du point de terminaison. La voie auto‑gérée déploie un conteneur de service au choix de l’utilisateur, tel que vLLM ou SGLang, comme un déploiement Kubernetes standard, avec des formes de service incluant un équilibreur de charge externe, un service interne au cluster et un pool de modèles de travailleurs GPU chauds qui peuvent être réaffectés en modifiant une étiquette. Pour le service SGLang à plusieurs réplicas, le plan de contrôle peut déployer le routeur SGLang avec un routage conscient du cache et piloter le dimensionnement automatique via le Kubernetes Event‑driven Autoscaling.

Outils d’agent et limites

Le serveur MCP publie 38 outils couvrant le cycle de vie du cluster, les groupes d’instances, les fonctionnalités gérées, le stockage, le téléchargement de modèles, le déploiement d’inférence, les jobs et les opérations de nœuds, selon l’article. Chaque outil de mutation indique l’outil d’état qui détermine l’achèvement, et les opérations conservent leur phase avant le début du sondage afin qu’une nouvelle tentative d’agent ne puisse pas rejouer une mutation. Le dépôt GitHub du projet décrit la plateforme comme un système intégré entraînement‑et‑inférence construit sur SageMaker HyperPod et l’orchestration EKS standard, et son README indique que les outils MCP encapsulent les API backend du projet pour garantir la conformité aux meilleures pratiques tandis que les compétences d’agent orchestrent les flux de travail de bout en bout avec zéro configuration locale au‑delà de l’agent.

L’article trace des limites opérationnelles explicites. Les compétences de diagnostic groupées pour NCCL, la santé des nœuds et les échecs de création de cluster enquêtent en lecture seule de façon autonome, présentent les commandes modifiant l’état comme des suggestions et escaladent dans l’ordre enquêter, redémarrer, puis remplacer. IAM, l’autorisation Kubernetes, les contrôles réseau et la validation backend restent les véritables limites de sécurité ; l’agent élargit l’accès au plan de contrôle sans élargir ses privilèges. AWS conseille également que l’entraînement élastique exclut actuellement les instances Spot, la mise en point en niveaux gérée et l’entraînement sans point de contrôle, et que les quotas d’utilisation de clusters SageMaker HyperPod ainsi que les réservations de plans d’entraînement pour les types de GPU haut de gamme doivent être organisés avant le premier cluster.

Le déploiement démarre à partir d’un modèle CloudFormation qui crée l’environnement de gestion, un bucket S3 partagé et des rôles IAM de support, l’interface web étant servie depuis le conteneur sur le port 3099 et accessible via une session de redirection de port d’AWS Systems Manager.