AWS detalha plano de controle de código aberto HyperPod InstantStart para operações de agente

A Amazon Web Services detalhou o HyperPod InstantStart, um plano de controle de código aberto que combina a orquestração do Amazon EKS com os recursos gerenciados do Amazon SageMaker HyperPod, em uma postagem do AWS Machine Learning Blog publicada em 4 de setembro de 2026. O projeto combina uma interface web com um agente de IA que planeja e executa operações de cluster em múltiplas etapas por meio das ferramentas do Model Context Protocol.

InstantStart funciona como um único contêiner de gerenciamento out-of-band dentro da conta AWS do usuário, chamando as APIs de serviços da AWS e a API do Kubernetes sem ficar no caminho de dados de trabalhos de treinamento ou solicitações de inferência. Cada recurso que ele cria é um objeto padrão da AWS ou do Kubernetes que permanece inspecionável com a AWS Command Line Interface e kubectl. A interface web, uma API REST e as ferramentas MCP usadas pelo agente são três faces do mesmo contêiner, de modo que ambas as interfaces entram por um único backend e passam pelas mesmas validações.

Um backend por trás de duas interfaces

O argumento central de design da postagem é que as ferramentas MCP encapsulam as próprias APIs REST do plano de controle em vez da AWS CLI ou SDK, de modo que uma validação adicionada uma vez protege tanto o navegador quanto o agente. Na interface web, criar um cluster com dependências instaladas, recuperação automática de nós ativada e armazenamento montado é um formulário e um painel de progresso; em um terminal, isso se traduz em uma única frase em linguagem natural para uma configuração de agente chamada hypd-inst-agent, criada para o Kiro CLI. O agente então sequencia o trabalho: criação do plano de controle do EKS, seleção de cluster ativo, reconciliação de dependências, criação do cluster HyperPod e configuração de armazenamento. A AWS informa que a criação do plano de controle do EKS termina em cerca de 8 a 12 minutos, e cada etapa posterior registra seu próprio status e pode ser repetida de forma independente.

Três regras de fluxo de trabalho são codificadas nas habilidades do agente do projeto, que a postagem descreve como playbooks markdown versionados no repositório. O agente monitora cada operação de longa duração até um estado terminal em vez de relatar uma solicitação enviada. Ele faz apenas perguntas de nível decisório, como Zona de Disponibilidade, tipo de instância e tipo de capacidade, tratando CIDRs de sub-rede, tabelas de rotas e grupos de segurança como trabalho do plano de controle. E ele inspeciona antes de criar, listando clusters existentes e consultando zonas e tipos de instância válidos antes de oferecer opções.

Recursos gerenciados como estado reconciliado

InstantStart cria clusters HyperPod com recuperação automática de nós habilitada, sob a qual o HyperPod pode reiniciar ou substituir nós defeituosos com base em seu agente de monitoramento de saúde, verificações de saúde básicas e verificações de saúde profundas opcionais que estressam GPUs e a conectividade do Elastic Fabric Adapter antes que os nós aceitem trabalho. Quando um usuário adiciona um grupo de instâncias, tipo de capacidade, modo de interface de rede e posicionamento de sub-rede são definidos como uma única operação de criação; tipo de capacidade e modo de interface apenas EFA permanecem fixos durante a vida do grupo. O plano de controle encaminha cada caminho de capacidade por meio de uma única função que provisiona sub-redes de computação dimensionadas em /20 para grandes frotas de aceleradores.

O dimensionamento automático de nós baseado em Karpenter gerenciado pelo HyperPod decide quanto dessa capacidade é executado a qualquer momento, com a AWS operando o controlador Karpenter e nós sendo lançados a partir de grupos de instâncias HyperPod escalados de zero. A postagem observa um limite de escopo: o Karpenter gerenciado administra grupos de instâncias HyperPod, não capacidade geral do Amazon EC2.

O painel de Recursos Avançados expõe os recursos gerenciados do HyperPod, incluindo o operador de treinamento, o operador de inferência, checkpointing em camadas gerenciado e dimensionamento automático gerenciado, com cada alternância mapeada para uma operação de backend consciente de dependências. Habilitar o checkpointing em camadas provisiona uma cadeia de identidade que abrange uma conta de serviço Kubernetes, uma função e política IAM, uma relação de confiança OpenID Connect e a anotação de vínculo, e desabilitá‑la remove a mesma cadeia. A postagem também descreve um contrato de diff explícito adotado após um bug inicial: a interface envia apenas os campos que o usuário realmente alterou, e o backend lê o estado real do cluster e não executa nenhuma ação quando o estado solicitado já corresponde ao estado atual.

Caminhos de treinamento e inferência

Para treinamento, InstantStart oferece duas rotas de submissão. O operador de treinamento HyperPod, instalado como um add‑on do EKS, adiciona recuperação de falhas em nível de processo, detecção de trabalhos travados por monitoramento de padrões de log e detecção de outliers, com o trabalho enviado como recursos HyperPodPyTorchJob que carregam um orçamento de recuperação visível. A segunda rota é o KubeRay padrão, voltado para cargas de trabalho nativas do Ray, como aprendizado por reforço. Sobre ambas há uma camada de receitas para scripts PyTorch simples, LLaMA‑Factory, MS‑Swift e aprendizado por reforço VERL, todas compartilhando um contrato de dados no qual o mesmo bucket Amazon S3 é montado no ambiente de desenvolvimento e dentro dos pods. Os logs dos trabalhos são transmitidos ao navegador via WebSocket, e as receitas podem relatar métricas como taxa de treinamento para o MLflow gerenciado na Amazon SageMaker AI.

A inferência também possui duas rotas. A rota gerenciada entrega o ciclo de vida ao operador de inferência HyperPod, com cache KV em camadas gerenciado e estratégias de roteamento inteligente declaradas ao lado do endpoint. A rota auto‑gerenciada implanta um contêiner de serviço da escolha do usuário, como vLLM ou SGLang, como um deployment padrão do Kubernetes, com formatos de serviço incluindo um balanceador de carga externo, um serviço interno ao cluster e um pool de modelos de workers GPU aquecidos que podem ser reatribuidos alterando um rótulo. Para serviço SGLang de múltiplas réplicas, o plano de controle pode implantar o roteador SGLang com roteamento consciente de cache e conduzir dimensionamento automático por meio do Kubernetes Event‑driven Autoscaling.

Ferramentas e limites do agente

O servidor MCP publica 38 ferramentas que cobrem o ciclo de vida do cluster, grupos de instâncias, recursos gerenciados, armazenamento, download de modelo, implantação de inferência, trabalhos e operações de nó, segundo a postagem. Cada ferramenta mutável nomeia a ferramenta de status que determina a conclusão, e as operações persistem sua fase antes de iniciar a sondagem, de modo que uma nova tentativa do agente não possa reproduzir uma mutação. O repositório GitHub do projeto descreve a plataforma como um sistema integrado de treinamento e inferência construído sobre SageMaker HyperPod e orquestração padrão do EKS, e seu README afirma que as ferramentas MCP encapsulam as APIs de backend do projeto para conformidade com as melhores práticas, enquanto as habilidades do agente orquestram fluxos de trabalho de ponta a ponta com zero configuração local além do agente.

A postagem traça limites operacionais explícitos. As habilidades de diagnóstico agrupadas para NCCL, saúde de nós e falhas na criação de clusters investigam em modo somente leitura por conta própria, apresentam comandos que alteram o estado como sugestões e escalam na ordem investigar, reiniciar e, então, substituir. IAM, autorização do Kubernetes, controles de rede e validação de backend permanecem os limites reais de segurança; o agente amplia o acesso ao plano de controle sem ampliar seus privilégios. A AWS também aconselha que o treinamento elástico atualmente exclui Spot Instances, checkpointing em camadas gerenciado e treinamento sem checkpoint, e que as cotas de uso de clusters SageMaker HyperPod e reservas de plano de treinamento para tipos de GPU de alto desempenho precisam ser organizadas antes do primeiro cluster.

A implantação começa a partir de um modelo CloudFormation que cria o ambiente de gerenciamento, um bucket S3 compartilhado e funções IAM de suporte, com a interface web servida a partir do contêiner na porta 3099 e acessada por meio de uma sessão de encaminhamento de porta do AWS Systems Manager.