Detalles de AWS sobre el plano de control de código abierto HyperPod InstantStart para operaciones de agentes

Amazon Web Services ha detallado HyperPod InstantStart, un plano de control de código abierto que combina la orquestación de Amazon EKS con las capacidades gestionadas de Amazon SageMaker HyperPod, en una publicación del blog AWS Machine Learning publicada el 4 de septiembre de 2026. El proyecto combina una interfaz web con un agente de IA que planifica y ejecuta operaciones de clúster de múltiples etapas mediante herramientas del Model Context Protocol.

InstantStart se ejecuta como un único contenedor de gestión fuera de banda dentro de la cuenta AWS de un usuario, llamando a las API de servicios de AWS y a la API de Kubernetes sin estar en la ruta de datos de los trabajos de entrenamiento o de las solicitudes de inferencia. Cada recurso que crea es un objeto estándar de AWS o Kubernetes que sigue siendo inspeccionable con la AWS Command Line Interface y kubectl. La interfaz web, una API REST y las herramientas MCP utilizadas por el agente son tres caras del mismo contenedor, de modo que ambas interfaces acceden a través de un único backend y pasan las mismas validaciones.

Un backend detrás de dos interfaces

El argumento central de diseño del artículo es que las herramientas MCP envuelven las propias API REST del plano de control en lugar de la CLI o SDK de AWS, de modo que una validación añadida una sola vez protege tanto al navegador como al agente. En la interfaz web, crear un clúster con dependencias instaladas, recuperación automática de nodos activada y almacenamiento montado es un formulario y un panel de progreso; en una terminal, es una única frase en lenguaje natural para una configuración de agente llamada hypd-inst-agent, construida para Kiro CLI. El agente luego secuencia el trabajo: creación del plano de control de EKS, selección del clúster activo, reconciliación de dependencias, creación del clúster HyperPod y configuración del almacenamiento. AWS indica que la creación del plano de control de EKS se completa en aproximadamente 8 a 12 minutos, y cada etapa posterior registra su propio estado y es reintentable de forma independiente.

Tres reglas de flujo de trabajo están codificadas en las habilidades del agente del proyecto, que el artículo describe como playbooks en markdown versionados en el repositorio. El agente supervisa cada operación de larga duración hasta un estado terminal en lugar de informar una solicitud enviada. Solo plantea preguntas de nivel decisional, como zona de disponibilidad, tipo de instancia y tipo de capacidad, mientras trata los CIDR de subred, tablas de rutas y grupos de seguridad como trabajo del plano de control. Además, inspecciona antes de crear, enumerando los clústeres existentes y consultando zonas y tipos de instancia válidos antes de ofrecer opciones.

Capacidades gestionadas como estado reconciliado

InstantStart crea clústeres HyperPod con la recuperación automática de nodos habilitada, bajo la cual HyperPod puede reiniciar o reemplazar nodos defectuosos basándose en su agente de monitoreo de salud, verificaciones de salud básicas y verificaciones de salud profundas opcionales que someten a prueba de estrés las GPU y la conectividad del Elastic Fabric Adapter antes de que los nodos acepten trabajo. Cuando un usuario agrega un grupo de instancias, el tipo de capacidad, el modo de interfaz de red y la ubicación de la subred se establecen como una única operación de creación; el tipo de capacidad y el modo de interfaz solo EFA quedan fijos durante la vida del grupo. El plano de control enruta cada ruta de capacidad a través de una única función que aprovisiona subredes de cómputo de tamaño /20 para grandes flotas de aceleradores.

El escalado automático de nodos basado en Karpenter gestionado por HyperPod decide cuánta de esa capacidad se ejecuta en cada momento, con AWS operando el propio controlador de Karpenter y los nodos iniciándose desde grupos de instancias HyperPod escalados desde cero. El artículo señala una limitación de alcance: Karpenter gestionado administra grupos de instancias HyperPod, no capacidad de Amazon EC2 de propósito general.

El panel de Funciones avanzadas expone las capacidades gestionadas de HyperPod, incluyendo el operador de entrenamiento, el operador de inferencia, el checkpointing escalonado gestionado y el escalado automático gestionado, con cada interruptor asociado a una operación del backend consciente de dependencias. Habilitar el checkpointing escalonado aprovisiona una cadena de identidad que abarca una cuenta de servicio de Kubernetes, un rol y política de IAM, una relación de confianza OpenID Connect y la anotación de enlace, y desactivarlo elimina la misma cadena. El artículo también describe un contrato de diferencia explícita adoptado tras un error temprano: la interfaz envía solo los campos que el usuario realmente cambió, y el backend lee el estado real del clúster y no realiza acciones cuando el estado solicitado y el real ya coinciden.

Rutas de entrenamiento e inferencia

Para el entrenamiento, InstantStart ofrece dos rutas de envío. El operador de entrenamiento HyperPod, instalado como un complemento de EKS, añade recuperación de fallos a nivel de proceso, detección de trabajos colgados mediante monitoreo de patrones de registro y detección de valores atípicos, con el trabajo enviado como recursos HyperPodPyTorchJob que incluyen un presupuesto de recuperación visible. La segunda ruta es KubeRay estándar, dirigida a cargas de trabajo nativas de Ray como el aprendizaje por refuerzo. Sobre ambas se encuentra una capa de recetas para scripts simples de PyTorch, LLaMA-Factory, MS-Swift y aprendizaje por refuerzo VERL, todas compartiendo un mismo contrato de datos en el que el mismo bucket de Amazon S3 se monta tanto en el entorno de desarrollo como dentro de los pods. Los registros de los trabajos se transmiten al navegador mediante WebSocket, y las recetas pueden reportar métricas como el rendimiento del entrenamiento a MLflow gestionado en Amazon SageMaker AI.

La inferencia también cuenta con dos rutas. La ruta gestionada entrega el ciclo de vida al operador de inferencia HyperPod, con caché KV escalonado gestionado y estrategias de enrutamiento inteligente declaradas junto al punto final. La ruta auto gestionada despliega un contenedor de servicio a elección del usuario, como vLLM o SGLang, como una implementación estándar de Kubernetes, con configuraciones de servicio que incluyen un balanceador de carga externo, un servicio interno al clúster y un grupo de modelos de trabajadores GPU en caliente que pueden reasignarse cambiando una etiqueta. Para el servicio SGLang de múltiples réplicas, el plano de control puede desplegar el enrutador SGLang con enrutamiento consciente de la caché y activar el escalado automático mediante Kubernetes Event-driven Autoscaling.

Herramientas del agente y límites

El servidor MCP publica 38 herramientas que cubren el ciclo de vida del clúster, grupos de instancias, funciones gestionadas, almacenamiento, descarga de modelos, despliegue de inferencia, trabajos y operaciones de nodos, según el artículo. Cada herramienta de mutación nombra la herramienta de estado que determina la finalización, y las operaciones persisten su fase antes de que comience la supervisión, de modo que un reintento del agente no pueda reproducir una mutación. El repositorio GitHub del proyecto describe la plataforma como un sistema integrado de entrenamiento e inferencia construido sobre SageMaker HyperPod y la orquestación estándar de EKS, y su README indica que las herramientas MCP envuelven las API del backend del proyecto para cumplir con las mejores prácticas, mientras que las habilidades del agente orquestan flujos de trabajo de extremo a extremo sin configuración local más allá del agente.

El artículo establece límites operacionales explícitos. Las habilidades de diagnóstico agrupadas para NCCL, salud de nodos y fallos de creación de clúster investigan en modo solo lectura por sí mismas, presentan comandos que cambian el estado como sugerencias y escalan en el orden investigar, reiniciar y luego reemplazar. IAM, la autorización de Kubernetes, los controles de red y la validación del backend siguen siendo los límites de seguridad reales; el agente amplía el acceso al plano de control sin ampliar sus privilegios. AWS también aconseja que el entrenamiento elástico actualmente excluye Instancias Spot, checkpointing escalonado gestionado y entrenamiento sin checkpoint, y que las cuotas de uso de clústeres de SageMaker HyperPod y las reservas de planes de entrenamiento para tipos de GPU de alta gama deben organizarse antes del primer clúster.

El despliegue comienza a partir de una plantilla CloudFormation que crea el entorno de gestión, un bucket S3 compartido y roles IAM de soporte, con la interfaz web servida desde el contenedor en el puerto 3099 y accesible a través de una sesión de reenvío de puertos de AWS Systems Manager.