O problema que o HyperPod InstantStart resolve
Quem trabalha com cargas de trabalho de modelos de fundação (FM — Foundation Models) no Amazon SageMaker HyperPod sabe que a operação raramente é uma tarefa única. É uma cadeia de etapas dependentes: criar a rede e o plano de controle, anexar capacidade de aceleradores, instalar dependências do cluster na ordem correta, preparar armazenamento e identidade, manter jobs distribuídos vivos durante falhas de hardware, implantar servidores de modelos e monitorar tudo isso. Cada etapa tem sua própria API, seus próprios modos de falha e seu próprio tempo de espera. A maior parte da dor operacional vive justamente nas transições entre essas etapas.
O Amazon SageMaker HyperPod já elimina uma parte significativa dessa carga, oferecendo computação gerenciada e resiliente com monitoramento de saúde, autoscaling de nós, recuperação de treinamento e inferência integrados ao Amazon Elastic Kubernetes Service (Amazon EKS). O EKS permanece como superfície de orquestração gerenciada pelo usuário, o que dá acesso direto ao Kubernetes — mas também torna a equipe responsável por compor recursos AWS, add-ons, cargas de trabalho e operações de dia dois em um todo coerente.
É exatamente esse problema de composição que o HyperPod InstantStart foi projetado para resolver. Trata-se de um plano de controle open source que oferece duas formas de operar a mesma infraestrutura: uma interface web e uma interface de agente de IA. Ambas chamam os mesmos backends, passam pelas mesmas validações e leem o mesmo estado persistido — nenhuma tem lógica privada que a outra não tenha.
Arquitetura da solução
O HyperPod InstantStart roda como um único contêiner de gerenciamento fora de banda na conta AWS do usuário. Ele chama APIs de serviços AWS e a API do Kubernetes, mas não fica no caminho de dados de um job de treinamento ou de uma requisição de inferência. Tudo que ele cria é um recurso padrão AWS ou Kubernetes, inspecionável via AWS CLI e kubectl.
A arquitetura tem um único ponto de entrada para a equipe de infraestrutura. A interface web, a API REST e as ferramentas do Protocolo de Contexto de Modelo (MCP — Model Context Protocol) usadas pelo agente de IA são três faces do mesmo contêiner. Por trás delas, fica a lógica de provisionamento em estágios e reconciliação idempotente.
O plano de controle chama duas superfícies de API. Do lado Kubernetes, está o Amazon EKS — gerenciado pelo usuário — com os operadores de treinamento e inferência do HyperPod instalados como add-ons EKS. Do lado AWS, está o Amazon SageMaker HyperPod — gerenciado pela AWS — com capacidades divididas em quatro grupos: infraestrutura (monitoramento de saúde, verificações profundas de saúde e recuperação automática de nós), capacidade (provisionamento contínuo e autoscaling gerenciado via Karpenter), treinamento (recuperação em nível de processo e checkpointing em camadas gerenciado) e inferência (roteamento inteligente e cache KV em camadas).
As integrações AWS ao redor desse caminho incluem o Amazon Simple Storage Service (Amazon S3), Amazon FSx for Lustre e Amazon Elastic Container Registry (Amazon ECR) para imagens, dados e checkpoints, além do Amazon Managed Service for Prometheus e Amazon Managed Grafana para saúde e utilização.
Criando um cluster: conversa e console
Partir de uma conta vazia até ter capacidade HyperPod utilizável envolve vários estágios longos e dependentes entre si: criação do plano de controle EKS, seleção do cluster ativo, reconciliação de dependências, criação do cluster HyperPod e configuração de armazenamento. O InstantStart separa deliberadamente esses estágios — uma falha em um estágio posterior não desfaz um estágio anterior que já foi concluído com sucesso.
Pela interface web, isso é gerenciado na página de Cluster Management. Pelo agente, todo o pipeline é uma conversa. A seguir, um trecho condensado de uma sessão real com o hypd-inst-agent, uma configuração de agente para o Kiro CLI que carrega o servidor MCP e as skills do projeto:
[hypd-inst-agent] > Help me create a new HyperPod cluster
> Creating a HyperPod cluster is a multi-step process:
1. Create EKS cluster (approximately 8-12 minutes)
2. Switch to the new cluster and verify
3. Install dependencies
4. Create HyperPod cluster
5. Configure S3 storage
6. Final verification
Let me first check the existing cluster situation:
Running tool cluster_list_all (from mcp server: hypd-inst)
> There are currently 2 existing clusters. Would you like to give the new cluster a tag name, or should I auto-generate one?
[hypd-inst-agent] > Go ahead
Running tool cluster_create_eks {"clusterTag": "hypd-0304b"}
...
> Step 1 complete! EKS cluster hypd-0304b created successfully.
...
> Step 3 complete! All dependencies installed successfully.
Now I need the following information from you to create HyperPod:
Availability Zone, GPU instance type, instance count, and capacity type (On-Demand or Training Plan)?
[hypd-inst-agent] > us-west-2c, one g6.4xl
Running tool hyperpod_create {"AcceleratedInstanceType": "ml.g6.4xlarge", "AcceleratedInstanceCount": 1, "availabilityZone": "us-west-2c", ...}
...
> HyperPod cluster creation fully complete! Summary:
| EKS Cluster | eks-cluster-hypd-0304b |
| HyperPod Cluster | hp-cluster-hypd-0304b |
| Node | 1x ml.g6.4xlarge (On-Demand) |
| Node Status | Ready / Schedulable |
| S3 Storage | s3-claim mounted |Três comportamentos nessa conversa vêm de regras de workflow codificadas na skill do agente, não de improviso: o agente faz polling até a conclusão (nunca para no meio e pede para o usuário verificar depois); o agente faz apenas perguntas de nível de decisão (Zona de Disponibilidade, tipo de instância, tipo de capacidade são decisões do usuário — CIDRs de sub-rede, tabelas de rota e ordem de instalação não são); e o agente inspeciona antes de criar, listando clusters existentes e consultando Zonas de Disponibilidade e tipos de instância válidos antes de oferecer opções.
Gerenciamento de capacidade e resiliência
O InstantStart cria clusters HyperPod com recuperação automática de nós habilitada por padrão. O HyperPod pode reinicializar ou substituir nós com falha com base em descobertas do agente de monitoramento de saúde, verificações básicas de saúde e, quando configurado, verificações profundas de saúde que testam GPUs e conectividade EFA (Elastic Fabric Adapter) antes que os nós aceitem trabalho.
Ao adicionar um grupo de instâncias, o sistema trata toda a decisão de capacidade como uma única operação no momento da criação. As escolhas incluem:
- Tipo de capacidade: On-Demand, Instâncias Spot do Amazon EC2 para cargas tolerantes a falhas, ou capacidade reservada via plano de treinamento do SageMaker.
- Modo de interface de rede: tipos de instância com múltiplas placas de rede podem solicitar interfaces exclusivamente EFA, conservando endereços IP da VPC. Essa configuração é imutável após a criação do grupo.
- Posicionamento de sub-rede: por padrão, grupos compartilham a sub-rede de computação por Zona de Disponibilidade. Um grupo grande pode solicitar uma sub-rede dedicada para evitar esgotamento de IPs.
Autoscaling gerenciado com Karpenter
Um grupo de instâncias estático define quanta capacidade o usuário possui. O autoscaling de nós gerenciado pelo HyperPod baseado em Karpenter decide quanto disso está em execução em cada momento. A AWS opera o próprio controlador Karpenter, e os nós são lançados a partir de grupos de instâncias HyperPod escalados a partir de zero — não de instâncias EC2 brutas. A capacidade autoscalada herda, portanto, o monitoramento de saúde e a recuperação automática de nós já mencionados.
Capacidades gerenciadas como estado reconciliado
O HyperPod inclui diversas capacidades gerenciadas — operador de treinamento, operador de inferência, checkpointing em camadas gerenciado e autoscaling gerenciado. O InstantStart expõe todas elas em um painel de Recursos Avançados, onde cada toggle mapeia para uma operação de backend consciente de dependências.
Habilitar o checkpointing em camadas gerenciado, por exemplo, faz mais do que alterar uma configuração do cluster. Ele provisiona uma cadeia de identidade completa: uma service account do Kubernetes, uma role e policy IAM, um relacionamento de confiança OpenID Connect (OIDC) e a anotação que os vincula. Desabilitar remove a mesma cadeia. A operação é fechada em ambas as direções — IRSA (Funções IAM para Contas de Serviço) parcialmente provisionado é um dos problemas mais difíceis de depurar no EKS.
O painel também implementa um contrato de diff explícito: a interface envia apenas os campos que o usuário efetivamente tocou. O backend verifica a presença dos campos, lê o estado real do cluster e não faz nada quando o estado real e o solicitado já coincidem. Esse contrato se aplica igualmente a requisições da interface web e a chamadas de ferramentas MCP.
Pelo agente, o painel inteiro é uma única troca:
[hypd-inst-agent] > Help me install tiered storage and training operator
Running tool hyperpod_get_advanced_features
> Currently both are not enabled. I'll enable them together.
Running tool hyperpod_update_advanced_features {"tieredStorage": {"enabled": true, "configMode": "default"}, "trainingOperator": {"enabled": true}}
> Both features have been successfully enabled.Treinamento: dois caminhos de submissão e uma camada de receitas
A superfície de treinamento separa duas decisões: como um job é submetido e mantido vivo é uma delas; qual framework o job executa é outra.
Operador de treinamento HyperPod
O primeiro caminho é o operador de treinamento do Amazon SageMaker HyperPod. Ele adiciona recuperação de falhas em nível de processo, detecção de jobs travados via monitoramento de padrões de log e detecção de outliers para treinamento distribuído. Um único processo com falha não custa mais o reinício completo de um job multi-nó. O InstantStart o instala como add-on EKS e submete trabalho como recursos HyperPodPyTorchJob, com a política de recuperação visível na especificação da carga de trabalho:
runPolicy:
jobMaxRetryCount: 5
restartPolicy:
numRestartBeforeFullJobRestart: 3
evalPeriodSeconds: 21600
maxFullJobRestarts: 1
cleanPodPolicy: AllIsso define um orçamento de recuperação: até três reinicializações de processo in-place dentro de uma janela de avaliação de seis horas; depois, o operador escala para um único reinício completo do job.
KubeRay para cargas nativas do Ray
O segundo caminho é o KubeRay padrão, instalado sob demanda pelo painel de Recursos Avançados. Algumas cargas de trabalho são nativas do Ray por design — notavelmente o aprendizado por reforço, onde um nó head coordena trabalhadores de rollout e treinamento. Clusters e jobs Ray são submetidos como cargas de trabalho de primeira classe nos mesmos nós HyperPod, com os mesmos mounts de armazenamento e as mesmas visualizações de monitoramento.
Camada de receitas
Sobre a camada de tarefas, o projeto fornece receitas que integram frameworks de treinamento amplamente usados: scripts PyTorch simples, LLaMA-Factory, MS-Swift e VERL para aprendizado por reforço (esse último no caminho KubeRay). Mudar de framework muda um formulário, não o modelo operacional. As receitas compartilham um contrato de dados: o mesmo bucket S3 é montado em ~/workspace/s3 no ambiente de desenvolvimento e em /s3 dentro dos pods. Logs de jobs fazem streaming para o browser via WebSocket, e cada receita pode reportar métricas ao MLflow gerenciado no Amazon SageMaker AI.
Inferência: dois modelos de propriedade
Para inferência, o plano de controle oferece dois caminhos com modelos de propriedade genuinamente diferentes.
O caminho gerenciado delega o ciclo de vida ao operador de inferência do HyperPod. O usuário descreve o endpoint de forma declarativa — localização do modelo no S3, imagem do worker, porta de invocação, recursos de GPU e réplicas. O operador reconcilia isso em workers de modelo, balanceamento de carga e TLS. Duas capacidades gerenciadas são o principal motivo para escolher esse caminho:
kvCacheSpec:
enableL1Cache: true
enableL2Cache: true
l2CacheSpec:
l2CacheBackend: tieredstorage
intelligentRoutingSpec:
enabled: true
routingStrategy: prefixawareO cache KV em camadas gerenciado mantém um cache L1 na memória CPU com uma camada L2 suportada por Redis ou armazenamento em camadas gerenciado do SageMaker. O roteamento inteligente oferece estratégias prefix-aware, KV-aware, por sessão e round-robin.
O caminho autogerenciado implanta um contêiner de serving de escolha do usuário — vLLM, SGLang ou próprio — como um deployment Kubernetes padrão. Oferece três formatos de serviço: load balancer externo, serviço interno ao cluster ou um pool de modelos. O pool mantém workers GPU aquecidos rotulados como business=unassigned; reatribuir um worker a um serviço muda um label em vez de recriar um pod e recarregar pesos.
A implantação via agente mostra as proteções no contrato da ferramenta — a skill de implantação proíbe inferir a contagem de GPUs a partir de um flag de paralelismo tensorial:
[hypd-inst-agent] > Help me deploy: vllm serve Qwen/Qwen3-0.6B --max-model-len 1280 --tensor-parallel-size 1
> Before deploying I need to confirm: how many GPUs should this deployment request?
(--tensor-parallel-size is a model-parallelism parameter; I need you to confirm the actual GPU allocation.)
Running tool cluster_get_status
> The cluster currently has 1 ml.g6.4xlarge node with 1 GPU available.
[hypd-inst-agent] > 1
Running tool inference_deploy_container {"deploymentCommand": "vllm serve Qwen/Qwen3-0.6B --max-model-len 1280 --tensor-parallel-size 1", "gpuCount": 1, "serviceType": "clusterip", ...}
> Deployment created. Let me test it:
Running tool inference_call_model {"service_name": "vllm-model-260304-100458-service", "prompt": "Hello! Can you briefly introduce yourself?"}
> Model test successful. Response: "Hello! I'm a language model designed to assist with tasks like answering questions..."O que torna um plano de controle pronto para agentes
A interface de agente — que o projeto chama de infraestrutura de IA conduzida por agente — é onde as escolhas de design pagam dividendos novamente. A implementação tem três camadas:
- Skills do agente definem workflows completos. Uma skill é um playbook em markdown que o agente lê antes de agir. A skill de criação de cluster sequencia o pipeline de seis estágios e define como sondar o estado atual e retomar um workflow interrompido. Skills são arquivos versionados no repositório — conhecimento operacional mantido como código revisável.
- Ferramentas MCP expõem operações de domínio delimitadas. O servidor publica 38 ferramentas cobrindo ciclo de vida do cluster, grupos de instâncias, recursos gerenciados, armazenamento, download de modelos, implantação de inferência, jobs e operações de nós. Toda ferramenta mutante nomeia a ferramenta de status que determina a conclusão, tornando a regra de polling-até-estado-terminal mecânica.
- As ferramentas reutilizam a API do backend. Adicionar um grupo de instâncias via MCP entra no mesmo código de gerenciador que o browser usa, com a mesma resolução de sub-rede, a mesma normalização de campos e a mesma persistência de status.
Comparado com apontar um agente de codificação diretamente para chamadas AWS CLI ou SDK, essa arquitetura oferece três vantagens concretas: boas práticas embutidas (as ferramentas envolvem as APIs do backend do projeto, então configurações seguem as regras codificadas do plano de controle); orquestração de workflow por design (skills definem os processos de negócio em múltiplos passos, tornando workflows reproduzíveis entre execuções e versões de modelos); e zero configuração local (o backend e o servidor MCP são enviados no mesmo contêiner).
Os contratos de confiabilidade que a interface web precisava são exatamente o que um agente também precisa: operações persistem sua fase antes do início do polling, uma query de status não compete com o processo que possui transições de estado, e o contrato de diff explícito significa que um agente habilitando uma capacidade não carrega intenção oculta sobre as outras.
Observabilidade
Uma operação não está completa só porque uma API a aceitou. A página de Monitoramento expõe saúde dos nós, totais e disponibilidade de GPUs e visualizações ao vivo de pods, serviços, deployments, recursos InferenceEndpointConfig e HyperPodPyTorchJob — e o agente lê o mesmo estado via ferramentas de status. Para métricas de frota, o HyperPod publica no Amazon Managed Service for Prometheus, com dashboards no Amazon Managed Grafana via add-on de observabilidade do HyperPod.
Igualmente importante: o plano de controle não se torna o único lugar onde o estado existe. Recursos customizados gerados, deployments, labels de nós e recursos AWS permanecem inspecionáveis com kubectl e AWS CLI.
Considerações antes de adotar
- A superfície de orquestração EKS continua sendo responsabilidade do usuário para segurança: acesso ao Kubernetes, autorização de cargas de trabalho, egresso de rede e IAM devem seguir políticas de menor privilégio.
- Skills de agente são código operacional — versione-as, revise-as e teste-as contra as APIs que invocam.
- Nem toda capacidade de treinamento se compõe: o treinamento elástico atualmente exclui Instâncias Spot, checkpointing em camadas gerenciado e treinamento sem checkpoint.
- Custos e cotas abrangem vários serviços: Amazon EKS, instâncias HyperPod, armazenamento, balanceamento de carga, observabilidade gerenciada e MLflow gerenciado aparecem na conta. Cotas de uso de cluster do SageMaker HyperPod e reservas de plano de treinamento para tipos de GPU de alto desempenho precisam ser providenciadas antes do primeiro cluster.
Como começar
Para começar com o HyperPod no Amazon EKS, a AWS disponibiliza a documentação de suporte ao Amazon EKS no SageMaker HyperPod. Para um tutorial completo cobrindo gerenciamento de clusters e treinamento de FM, há o Workshop de Suporte ao Amazon EKS no Amazon SageMaker HyperPod. Para implantar a solução descrita, seja pela interface web ou pelo agente, o ponto de partida é o repositório HyperPod-InstantStart e seu guia de lançamento.
Fonte
Run agent-driven Amazon SageMaker HyperPod operations with InstantStart (https://aws.amazon.com/blogs/machine-learning/run-agent-driven-amazon-sagemaker-hyperpod-operations-with-instantstart/)
Leave a Reply