Governança entre contas: o próximo passo natural

Depois de estabelecer o registro automático de modelos em uma única conta, o passo seguinte para organizações maiores é estender esse controle para múltiplas contas AWS. Foi exatamente isso que a AWS abordou na segunda parte da série sobre governança com MLflow e Amazon SageMaker AI.

Na Parte 1, o foco foi em uma configuração de conta única, onde chaves de condição do Gerenciamento de Identidade e Acesso (IAM) separavam os perfis de cientista de dados e oficial de governança. Agora, o artigo avança para dois cenários de governança entre contas que refletem a realidade de empresas maiores: o padrão hub-and-spoke centralizado e o padrão híbrido para ambientes regulados.

Os perfis envolvidos

Além dos dois perfis da Parte 1 — o cientista de dados (que trabalha em notebooks Jupyter e interage apenas com o MLflow) e o oficial de governança (que atua pela interface de Modelos do Amazon SageMaker Studio) — as topologias entre contas introduzem dois novos perfis:

• Administrador: responsável pela configuração inicial entre contas, incluindo compartilhamentos via AWS Resource Access Manager (AWS RAM), políticas de bucket e grupos de destino.
• Dono do modelo: presente apenas na topologia híbrida, aprova modelos localmente na conta de desenvolvimento antes de promovê-los ao hub central.

Pré-requisitos

Para seguir o passo a passo descrito no artigo original, é necessário ter concluído a Parte 1 e estar familiarizado com o registro automático de modelos, o construto de staging de ciclo de vida e as restrições por chaves de condição IAM. Também são necessárias duas contas AWS — uma de desenvolvimento (spoke) e uma de governança (hub) — com perfis nomeados configurados no CLI da AWS (por exemplo, mlops-spoke e mlops-hub). A stack do AWS CloudFormation disponível no repositório deve ser implantada em ambas as contas, provisionando o domínio do SageMaker AI Studio, perfil de usuário, função de execução e um app MLflow gerenciado com AutoModelRegistrationEnabled.

Topologia 1: Hub-and-spoke com governança centralizada

Nessa topologia, uma conta central (hub) hospeda o app MLflow e o Registro de Modelos central. As contas de desenvolvimento (spokes) compartilham esse app por meio do AWS RAM, mantendo o isolamento de cargas de trabalho entre equipes.

Esse padrão é uma extensão da abordagem descrita no post Centralize model governance with SageMaker Model Registry and AWS RAM sharing.

Fluxo de trabalho

• O hub cria um compartilhamento de recurso AWS RAM para o app MLflow e o spoke aceita o convite. O uso de entidades externas permite que o compartilhamento funcione mesmo entre contas fora da mesma organização.
• O cientista de dados no spoke registra um modelo apontando o URI de rastreamento do MLflow para o app do hub. O registro automático cria o Grupo de Pacotes de Modelos e a versão diretamente na conta hub.
• O hub anexa uma política de recurso ao grupo e o compartilha de volta ao spoke com a permissão gerenciada AllowDeploy, permitindo que o spoke descreva e faça o deploy do modelo.
• O oficial de governança valida as métricas e a linhagem sincronizadas e aprova o modelo centralmente no hub.
• O evento de aprovação dispara um pipeline de Integração e Entrega Contínua (CI/CD), e o modelo aprovado é implantado em um endpoint do Amazon SageMaker na conta spoke.

Configuração pelo administrador (única vez)

O administrador precisa garantir o acesso entre contas ao bucket S3 de artefatos do MLflow, que fica no hub. Isso envolve dois lados: no lado do recurso, uma política de bucket concedendo ao spoke as ações s3:GetObject, s3:PutObject, s3:ListBucket e s3:GetBucketLocation. No lado da identidade, a função de execução do spoke precisa de s3:GetObject no bucket do hub para leitura de artefatos no momento do deploy.

Com isso em ordem, o administrador cria o compartilhamento AWS RAM do app MLflow, que o spoke aceita. Após o primeiro registro, anexa uma política de recurso ao Grupo de Pacotes de Modelos sincronizado e o compartilha de volta ao spoke com a permissão AllowDeploy.

Cientista de dados: registrando do spoke

O fluxo é idêntico ao da Parte 1, com uma diferença: o notebook aponta o URI de rastreamento do MLflow para o Recurso Amazon (ARN) do app no hub. O registro automático cria o Grupo de Pacotes de Modelos e a versão no hub de forma síncrona com a chamada de registro.

Dois pontos importantes a considerar: o registro automático adiciona um sufixo hash curto ao nome do grupo (por exemplo, meu-modelo vira meu-modelo-<hash>). Para localizar o grupo, use list_model_package_groups(NameContains=...) e referencie-o entre contas pelo ARN completo. Além disso, a linhagem é registrada no hub, pois a sincronização ocorre lá — o oficial de governança vê o grafo completo de linhagem no Studio do hub, mas esse dado não é compartilhado de volta ao spoke automaticamente.

Oficial de governança: aprovação centralizada no hub

O oficial de governança trabalha na visão de Modelos do Studio do hub — um único ponto de controle para candidatos de todos os spokes. Ele revisa as métricas e a linhagem sincronizadas, promove o modelo para produção e define o status de aprovação como Aprovado.

Topologia 2: Hub-and-spoke com governança híbrida

Em organizações reguladas, o hub é tratado como uma conta de nível produtivo, e não se quer que cientistas de dados escrevam nela, nem mesmo indiretamente. Para esses casos, a AWS recomenda uma topologia híbrida que mantém cada conta de desenvolvimento completamente isolada.

Fluxo de trabalho

• O cientista de dados registra um modelo no app MLflow da própria conta de desenvolvimento. A sincronização automática registra o modelo no Registro de Modelos local, sem tocar no hub.
• O dono do modelo na conta de desenvolvimento revisa e aprova o modelo localmente, disparando o fluxo de cópia.
• O fluxo de cópia replica os artefatos do modelo em um bucket de propriedade do hub, reescreve a especificação de inferência e registra o pacote no grupo de destino do hub — com metadados apontando para a origem.
• O oficial de governança no hub revalida o pacote copiado e o aprova como registro central de governança.
• Um engenheiro de ML faz o deploy do modelo aprovado localmente para um endpoint no spoke, geralmente via pipeline CI/CD. Nenhum artefato entre contas é necessário no momento do deploy.

Configuração pelo administrador (única vez)

O administrador do hub cria um Grupo de Pacotes de Modelos de destino, anexa uma política de recurso permitindo que a conta de desenvolvimento execute CreateModelPackage nele, e o compartilha via AWS RAM com a permissão AllowRegister. Também cria (ou designa) um bucket de artefatos de propriedade do hub, com política de bucket concedendo ao spoke as ações s3:PutObject e s3:ListBucket para que a cópia possa ocorrer.

Se o contêiner de inferência estiver em um repositório privado na conta de desenvolvimento, será necessário replicar a imagem para o hub ou adicionar uma política de repositório no Amazon Elastic Container Registry (Amazon ECR).

Dono do modelo: aprovação local e cópia para o hub

A aprovação local dispara uma regra do Amazon EventBridge na mudança de estado do Pacote de Modelos, que executa o fluxo de cópia. Esse fluxo realiza três ações: replica os artefatos do modelo do bucket de desenvolvimento para o bucket do hub, reescreve a especificação de inferência para apontar para a cópia no hub, e registra o pacote no grupo de destino do hub com CustomerMetadataProperties registrando o ARN e a conta de origem. O resultado é autossuficiente: o pacote no hub não tem dependência de runtime na conta de desenvolvimento.

O oficial de governança vê o pacote copiado no Studio do hub, com metadados de proveniência apontando para a origem, revalida e aprova de forma independente.

Da aprovação ao deploy

Em ambas as topologias, a aprovação no registro é o portão de controle — não o deploy em si. A mudança de status de aprovação emite um evento para o Amazon EventBridge, e esse evento dispara um pipeline CI/CD: uma regra do EventBridge que corresponde a ModelApprovalStatus: Approved inicia um pipeline que cria ou atualiza o endpoint a partir do Pacote de Modelos aprovado.

A conta onde o pipeline roda e onde o endpoint é implantado são decisões organizacionais. Um arranjo comum executa o pipeline em uma conta de serviços compartilhados e faz o deploy em uma conta dedicada. Configurações mais simples rodam ambos na conta de desenvolvimento (spoke), que é o que os exemplos do repositório demonstram.

Um ponto de atenção: a linhagem do modelo fica na conta onde a sincronização foi registrada. Planeje as revisões de governança em torno do registro do hub (ou de desenvolvimento), sem esperar que a linhagem siga o modelo para a conta de deploy.

Comparando as topologias

As três topologias — conta única (Parte 1), hub-and-spoke centralizado e hub-and-spoke híbrido — trocam isolamento de conta por simplicidade operacional. Na topologia centralizada, os spokes escrevem no hub por meio do app MLflow compartilhado, o que oferece um único ponto de controle com custo operacional moderado. Na topologia híbrida, ninguém escreve diretamente no hub — apenas cópias aprovadas e autossuficientes cruzam para ele, ideal para ambientes regulados, mas com maior custo operacional. Em todas as três, os blocos construtivos são os mesmos: o registro automático produz os metadados sincronizados, o construto de staging expressa o ciclo de vida, e as chaves de condição IAM e tags de recurso reforçam o portão de aprovação.

Limpeza de recursos

Para evitar cobranças contínuas, os recursos criados devem ser removidos na seguinte ordem: endpoint e configuração de endpoint do Amazon SageMaker AI na conta spoke; modelo do SageMaker AI criado para deploy; compartilhamentos de recurso AWS RAM; versões e Grupo de Pacotes de Modelos na conta hub; modelo registrado no app MLflow do hub; política de bucket entre contas no bucket de artefatos do hub; e, por fim, as stacks do CloudFormation em ambas as contas. O repositório inclui scripts de limpeza automatizados para cada topologia.

Conclusão

A governança entre contas apresentada pela AWS na Parte 1 desta série se expande de forma consistente: os mesmos blocos construtivos — registro automático, construto de staging e chaves de condição IAM — são reaproveitados nas topologias entre contas. O que muda é onde o limite de conta está posicionado e como o modelo o cruza.

Para começar, a AWS recomenda revisar a documentação sobre registro automático de modelos e depois trabalhar com os notebooks entre contas no repositório do GitHub.

Recursos adicionais

• Amazon SageMaker AI
• Registrar modelos SageMaker AI automaticamente no SageMaker Model Registry
• Staging Construct para o ciclo de vida do modelo
• Centralizar a governança de modelos com SageMaker Model Registry e AWS RAM sharing
• AWS re:Post para Amazon SageMaker

Fonte

Govern models with MLflow and Amazon SageMaker AI Model Registry sync: Part 2 (https://aws.amazon.com/blogs/machine-learning/govern-models-with-mlflow-and-amazon-sagemaker-ai-model-registry-sync-part-2/)

O problema de governança que a sincronização resolve

Existe uma lacuna clássica no ciclo de vida de modelos de machine learning: cientistas de dados rastreiam dezenas de experimentos no MLflow, enquanto os responsáveis pela governança precisam de um registro único e confiável para validar, aprovar e auditar quais modelos chegam à produção. Sem uma ponte automática entre esses dois mundos, alguém sempre precisa registrar modelos manualmente, coletar contexto à mão ou sair do fluxo de trabalho para buscar informações em outro sistema.

A AWS anunciou um aprimoramento significativo nessa ponte. O Amazon SageMaker AI com MLflow gerenciado já sincronizava modelos registrados no MLflow para o SageMaker AI Model Registry automaticamente. Agora, essa sincronização ficou consideravelmente mais rica: ela carrega métricas de treinamento, resultados de avaliação e linhagem, além de adicionar a promoção de estágio de ciclo de vida diretamente pelo MLflow. O resultado prático é que equipes podem governar modelos candidatos a partir de um único sistema de referência, sem precisar que os cientistas de dados abandonem seu fluxo de experimentação.

Antes dessa melhoria, um modelo ainda era sincronizado para o registro, mas chegava sem métricas, resultados de avaliação ou linhagem. O responsável pela governança não conseguia validar um candidato apenas pelo registro — precisava voltar ao MLflow ou coletar o contexto manualmente. Além disso, como a sincronização não carregava a promoção de estágio de ciclo de vida, os cientistas de dados não podiam mover um modelo de staging para produção dentro do fluxo do MLflow.

Como funciona o registro automático

A sincronização com o Model Registry é uma funcionalidade opt-in. Ela pode ser ativada ao criar ou atualizar um app MLflow, definindo o modo de registro de modelos como AutoModelRegistrationEnabled (o padrão é desabilitado). Para configurar essa sincronização, é necessário configurar a função de serviço de Gerenciamento de Identidade e Acesso (IAM) com as permissões necessárias para criar os Model Package Groups e versões, adicionar tags e registrar associações de linhagem.

# Ativar sincronização com o Model Registry ao criar um app MLflow
aws sagemaker create-mlflow-app \
  --name my-mlflow-app \
  --artifact-store-uri s3://<your-sample-bucket-name>/mlflow \
  --role-arn arn:aws:iam::<ACCOUNT>:role/my-mlflow-app-role \
  --model-registration-mode AutoModelRegistrationEnabled \
  --region <region>

# Atualizar um app MLflow existente com sincronização do Model Registry
aws sagemaker update-mlflow-app \
  --arn <your-existing-mlflow-app-arn> \
  --model-registration-mode AutoModelRegistrationEnabled \
  --region <region>

Com a sincronização ativada, o cientista de dados pode registrar um modelo com uma única chamada MLflow. Dois artefatos opcionais — especificação de inferência e métricas de avaliação — podem ser anexados antes do registro e são então carregados para o Model Package:

import mlflow, sagemaker_mlflow

# Registrar o modelo treinado durante o run
model_info = mlflow.sklearn.log_model(model, name="sklearn-model")

# Opcionalmente registrar métricas de avaliação
sagemaker_mlflow.evaluate(model_info, data=dataset, model_type="regressor")

# Opcionalmente registrar uma especificação de inferência:
# habilita deploy direto a partir do registro
sagemaker_mlflow.log_inference_specification(
    model_info.model_id,
    inference_specification=inference_spec
)

# Registrar o modelo: cria o Model Package Group e versão automaticamente
mv = mlflow.register_model(f"models:/{model_info.model_id}", "my-model")

O que é sincronizado para o Model Registry

Após o registro, a sincronização carrega quatro categorias de metadados para o Model Registry no Amazon SageMaker Studio, disponibilizando-as para o responsável pela governança:

• Metadados do run: parâmetros do modelo, métricas de treinamento, localização do dataset de treinamento e caminho do artefato do modelo.
• Métricas de avaliação: anexadas como um model card na versão do Model Package, onde são exibidas na aba Evaluate no Studio, tornando as medidas de desempenho revisáveis junto ao modelo.
• Especificação de inferência: define a imagem de container, a localização dos dados do modelo e os tipos de instância suportados, permitindo o deploy direto a partir do registro. Para que o pacote seja genuinamente implantável, os artefatos do modelo também precisam incluir o handler de inferência (por exemplo, um inference.py empacotado com o modelo durante o treinamento ou registro).
• Linhagem: registra o relacionamento entre o experimento MLflow, a versão do modelo, a imagem de container e o Model Package Group.

Controles de ciclo de vida e governança

Os responsáveis pela governança podem gerenciar o ciclo de vida dos modelos usando o construto de staging do Model Registry. As organizações podem usar o template predefinido ou definir o próprio, em conjunto com condition keys do IAM, para que apenas usuários com as permissões corretas possam promover modelos ao longo do ciclo de vida.

O estágio e o status do ciclo de vida são definidos adicionando um alias MLflow com a convenção de nomenclatura sagemakerlifecycle-{stage}-{status}, onde stage é staging ou production e status é pending ou active no template predefinido. Isso atualiza automaticamente o ciclo de vida do Model Package correspondente no SageMaker AI:

client = mlflow.MlflowClient()

# Mover um candidato para staging
client.set_registered_model_alias(
    "my-model",
    "sagemakerlifecycle-staging-pending",
    version
)

Dois controles de governança podem ser aplicados para garantir que apenas o perfil adequado atualize o ciclo de vida do modelo:

• Condition keys do IAM: permitem controlar transições de ciclo de vida. As chaves sagemaker:ModelLifeCycle/stage e sagemaker:ModelLifeCycle/stageStatus controlam quem pode atualizar o estágio de um modelo e para qual estágio e status ele pode ser movido.
• Condições de resource tag: permitem bloquear um Model Package Group após a aprovação, impedindo que novas atualizações fluam pelo MLflow.

Mudanças de ciclo de vida também emitem eventos para o Amazon EventBridge e são registradas como trilha de auditoria. Esses eventos podem ser consumidos para conectar o processo de aprovação a ferramentas de governança de terceiros.

Novidades no plugin sagemaker-mlflow

Os fluxos de trabalho descritos neste post utilizam o plugin sagemaker-mlflow, e a versão 0.5.0 adiciona duas capacidades relevantes. A primeira é o registro de imagem de inferência, que permite gravar a imagem de container de inferência junto ao modelo no momento do log — esses metadados seguem com o modelo para o Model Registry, reforçando o caminho de deploy direto a partir do registro. A segunda é a injeção de sessão (por meio de use_session() e set_session()), que permite fornecer uma sessão boto3 customizada para que o plugin assine requisições com credenciais por contexto. A configuração de conta única deste post não requer esse recurso, mas ele é o bloco de construção para as topologias de governança entre contas abordadas na Parte 2.

Os dois perfis de usuário

A configuração envolve dois perfis com ferramentas distintas. O cientista de dados trabalha em um notebook Jupyter e interage com o MLflow: treinando, registrando e promovendo modelos para staging. O responsável pela governança trabalha na interface do SageMaker Studio, na visão de Modelos: revisando métricas e linhagem sincronizadas, promovendo para produção e aprovando para deploy. Um administrador de plataforma realiza a configuração única que separa os dois perfis.

Configuração em conta única

Em uma configuração de conta única, tanto os cientistas de dados quanto o responsável pela governança operam na mesma conta. Esse modelo é adequado para equipes menores ou projetos em estágio inicial onde a separação de contas ainda não é necessária.

O fluxo funciona da seguinte forma: ao concluir o treinamento, o cientista de dados registra o modelo no app MLflow com sincronização ativada. O registro automático cria o Model Package Group e a versão no SageMaker AI Model Registry, incluindo métricas, resultados de avaliação, especificação de inferência e linhagem. Com as condition keys do IAM configuradas, o cientista de dados pode mover o modelo para staging, mas a promoção para produção será negada para seu perfil. Apenas o perfil do responsável pela governança, com as permissões adequadas, pode aprovar e promover o modelo para produção. Um engenheiro de ML pode então fazer o deploy do modelo aprovado para um endpoint SageMaker AI, normalmente por meio de um pipeline de Integração Contínua e Entrega Contínua (CI/CD).

Configuração pelo administrador de plataforma

O administrador ativa a sincronização com o Model Registry no app MLflow, concede à função de serviço do app as permissões de registro e linhagem, e aplica a política de IAM (guardrail de ciclo de vida) à função do cientista de dados. Essa política usa a condition key sagemaker:ModelLifeCycle/stage para negar promoções para produção:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyProductionPromotion",
    "Effect": "Deny",
    "Action": "sagemaker:UpdateModelPackage",
    "Resource": "*",
    "Condition": {
      "StringEquals": {"sagemaker:ModelLifeCycle/stage": "production"}
    }
  }]
}

A função do responsável pela governança não contém esse deny, então apenas esse perfil pode promover para produção. Essa é uma configuração única. Após ela, os dois perfis trabalham de forma independente.

O cientista de dados: experimento e registro pelo notebook

O cientista de dados trabalha em um notebook Jupyter (no SageMaker Studio ou localmente) e interage apenas com o MLflow. Após o treinamento, ele registra métricas de avaliação e a especificação de inferência, registra o modelo e o move para staging com um alias de ciclo de vida:

mv = mlflow.register_model(f"runs:/{run_id}/sklearn-model", "my-model")
client = mlflow.MlflowClient()
client.set_registered_model_alias("my-model", "sagemakerlifecycle-staging-pending", mv.version)

O registro automático cria o Model Package Group e a versão do Model Package no Model Registry. O alias move o modelo para staging/pending. Se o cientista de dados tentar o alias de produção, a transição é negada pela política de IAM configurada.

O responsável pela governança: revisão e aprovação no Studio

O responsável pela governança trabalha na visão de Modelos do SageMaker Studio. A versão do Model Package sincronizada já traz as métricas de treinamento, o model card de avaliação e o grafo de linhagem, portanto toda a revisão acontece em um único lugar.

Após validar as métricas e a linhagem, o responsável promove o modelo para production/active e define o status de aprovação como Approved. O status de aprovação é um atributo separado do estágio de ciclo de vida, portanto promoção e prontidão para deploy permanecem como decisões distintas. Para bloquear o modelo aprovado contra alterações futuras, o responsável (ou uma etapa automatizada pós-aprovação) aplica uma resource tag ao Model Package Group com uma condição de deny correspondente no IAM (aws:ResourceTag/frozen = true).

Pré-requisitos

Para reproduzir o fluxo descrito, é necessário ter:

• Uma conta AWS com permissões para criar e gerenciar recursos do SageMaker AI.
• Um domínio do Amazon SageMaker AI com acesso ao Studio configurado.
• Um app MLflow gerenciado criado dentro do domínio. Para instruções de configuração, consulte como criar um app MLflow.
• Sincronização com o Model Registry ativada no app MLflow.
• O plugin sagemaker-mlflow versão 0.5.0 ou superior instalado no ambiente de experimentos (pip install sagemaker-mlflow>=0.5.0).
• Uma função IAM com permissões para registrar modelos, atualizar estágios de ciclo de vida e escrever no Model Registry.

Limpeza dos recursos

Para evitar cobranças contínuas, os recursos criados durante o walkthrough devem ser removidos na seguinte ordem, respeitando as dependências:

• Excluir o endpoint do SageMaker AI (se implantado).
• Excluir as versões do Model Package e o Model Package Group (remova todas as versões primeiro, depois exclua o grupo).
• Excluir o app MLflow.
• Remover as políticas IAM customizadas criadas para os perfis de cientista de dados e responsável pela governança.
• Excluir os artefatos do modelo no Amazon S3.
• Excluir o domínio do SageMaker AI (opcional, se criado exclusivamente para este walkthrough).

Conclusão

O registro automático de modelos entre o MLflow gerenciado e o SageMaker AI Model Registry oferece aos responsáveis pela governança uma visão completa e sincronizada de cada modelo candidato — abrangendo métricas de treinamento, métricas de avaliação, especificação de inferência e linhagem —, sem exigir que os cientistas de dados saiam do MLflow ou registrem modelos manualmente.

Ativar a sincronização é uma escolha deliberada: define-se AutoModelRegistrationEnabled no app MLflow e concede-se à função de serviço as permissões de registro e linhagem. A partir daí, cada modelo registrado flui para o registry com seus metadados intactos. Em uma conta única, as condition keys do IAM no estágio de ciclo de vida são o que separa os perfis de cientista de dados e responsável pela governança, e um bloqueio por resource tag protege modelos aprovados contra alterações futuras.

Organizações maiores raramente se limitam a uma única conta. Na Parte 2, a AWS estende esses blocos de construção para topologias de governança entre contas: um padrão hub-and-spoke que centraliza a governança compartilhando um app MLflow entre contas de desenvolvimento com o AWS Resource Access Manager (AWS RAM), um padrão híbrido para ambientes regulados que mantém as contas de desenvolvimento totalmente isoladas do hub de governança, e o caminho da aprovação para o deploy via CI/CD.

Para começar, consulte a documentação sobre registro automático de modelos e os scripts de execução passo a passo para conta única — ou o notebook equivalente — disponíveis no repositório GitHub.

Recursos adicionais

• Amazon SageMaker AI
• Registro automático de modelos SageMaker AI com o SageMaker Model Registry
• Construto de Staging para o Ciclo de Vida do Modelo
• AWS re:Post para Amazon SageMaker

Fonte

Govern models with MLflow and Amazon SageMaker AI Model Registry sync: Part 1 (https://aws.amazon.com/blogs/machine-learning/govern-models-with-mlflow-and-amazon-sagemaker-ai-model-registry-sync-part-1/)

O modelo mais capaz da OpenAI chega ao Amazon Bedrock

A AWS anunciou que o GPT-6 Astra, o modelo mais recente e poderoso da OpenAI, está agora em disponibilidade geral no Amazon Bedrock. Para equipes que já utilizam agentes de Inteligência Artificial (IA) no Bedrock para escrever código, analisar dados e automatizar fluxos de trabalho em produção, essa novidade representa um salto significativo no que esses agentes são capazes de entregar.

O GPT-6 Astra aplica raciocínio mais profundo e julgamento mais apurado a decisões complexas de negócios. Ele trabalha com software e arquivos, e produz resultados em nível profissional alinhados à voz, aos modelos e aos padrões de cada organização.

É possível chamar o modelo diretamente pelas APIs do Amazon Bedrock ou configurar o ChatGPT Work e o Codex para utilizá-lo. Como parte desse lançamento, a OpenAI também está introduzindo novos plugins empresariais para o ChatGPT Work, que ampliam as capacidades de uso do navegador em aplicações de negócios comuns.

Profundidade para decisões complexas

Uma das características mais destacadas do GPT-6 Astra é sua capacidade de lidar com tarefas que exigem reconciliar informações conflitantes, rastrear dependências e determinar prioridades. Alguns exemplos práticos mencionados pela AWS:

• Análise financeira: o modelo consegue reconciliar fontes de dados conflitantes e identificar discrepâncias que poderiam mudar uma recomendação.
• Revisão de contratos: com uma janela de contexto de até 1 milhão de tokens de entrada, ele pode revisar centenas de páginas e apontar as cláusulas de maior risco.
• Análise de código: investiga problemas em grandes bases de código, raciocina sobre dependências e conduz uma correção desde o diagnóstico até os testes.

O GPT-6 Astra também avança no uso de computador e navegador, permitindo que ele trabalhe diretamente em interfaces de software quando uma API ou conector não está disponível.

Cache de prompt para workflows recorrentes

Para fluxos de trabalho que reutilizam o mesmo contexto em várias requisições — como revisão recorrente de documentos, análise de base de código ou agentes baseados em padrões corporativos — o GPT-6 Astra suporta cache de prompt implícito e explícito. Com o cache explícito, é possível definir pontos de interrupção de cache para controlar qual contexto é armazenado. Reutilizar esse contexto em requisições subsequentes ajuda a reduzir o processamento repetido, os custos e a latência.

Segurança e governança em camadas para IA em produção

As salvaguardas no nível do modelo funcionam em conjunto com os controles de segurança e governança do Amazon Bedrock. A OpenAI avaliou o GPT-6 Astra por meio de seu Preparedness Framework, que avalia as capacidades do modelo em domínios relevantes para segurança e aplica salvaguardas progressivamente mais rígidas conforme essas capacidades avançam.

O GPT-6 Astra é o primeiro modelo da OpenAI a atingir a classificação Crítica para capacidade de cibersegurança. Nesse nível, salvaguardas automatizadas monitoram o uso indevido em tempo real e podem pausar ou interromper atividades que excedam limites definidos — tudo operando dentro do perímetro de serviço do Amazon Bedrock.

Proteção de dados na infraestrutura da AWS

O Amazon Bedrock protege os dados de inferência e governa o acesso em cada invocação do modelo. Os controles incluem:

• Zero-operator access aplicado no nível do chip: nem mesmo os operadores da AWS conseguem acessar seus prompts e respostas durante a inferência.
• Dados criptografados em trânsito e em repouso.
• Acesso governado pelas políticas do Gerenciamento de Identidade e Acesso (IAM) da AWS.
• Cada invocação registrada no AWS CloudTrail.
• Tráfego roteável por endpoints de Nuvem Privada Virtual (VPC) via AWS PrivateLink.
• Políticas de perímetro de dados no nível da organização para ajudar a prevenir exfiltração de dados entre contas e limites de rede.

Os dados de inferência não são usados para treinamento de modelos, e o uso do GPT-6 Astra não exige que você opte pelo compartilhamento de dados com a OpenAI. Para a detecção automatizada de abuso, o tráfego sinalizado por classificadores é retido pela AWS por até 30 dias e processado de forma programática. É possível solicitar retenção zero de dados por meio da equipe de conta AWS. Consulte os detalhes sobre retenção de dados.

Três formas de usar o GPT-6 Astra

Integrar o Astra às suas aplicações

O GPT-6 Astra pode ser integrado diretamente a aplicações por meio das APIs suportadas do Amazon Bedrock. Com isso, é possível criar agentes autônomos para fluxos de trabalho complexos de múltiplas etapas, construir ferramentas internas que analisam e sintetizam documentos em escala, ou desenvolver aplicações voltadas ao cliente que exigem julgamento sobre entradas conflitantes.

Transformar tarefas complexas em entregas prontas com o ChatGPT Work

O ChatGPT Work é um agente de produtividade voltado a transformar tarefas complexas de negócios em entregas finalizadas. Com o GPT-6 Astra, ele consegue coletar informações em aplicações e arquivos, usar a web e produzir planilhas, apresentações, documentos e sites. O usuário pode controlar quais aplicações e sites o agente pode acessar, gerenciar uploads e downloads de arquivos, e exigir confirmação antes de ações específicas — mantendo as pessoas no controle durante todo o fluxo.

O ChatGPT Work está disponível pelo aplicativo desktop do ChatGPT para Mac e Windows. Os novos plugins empresariais lançados junto com essa versão ampliam as capacidades de uso do navegador para ferramentas de inteligência de negócios, Workday, Navan e Avalara — para tarefas de análise de dados, operações e finanças. Esses plugins funcionam por meio da conta de usuário existente e dentro das permissões estabelecidas pelos administradores, sem conceder ao Astra acessos adicionais.

Desenvolver, testar e entregar código com o Codex

O Codex é um agente de engenharia de software que trabalha com arquivos locais, repositórios, terminais, ferramentas de desenvolvimento e ambientes de desenvolvimento para escrever funcionalidades, corrigir bugs, executar testes e abrir pull requests. Ao configurar o Codex para usar o GPT-6 Astra no Amazon Bedrock, ele aplica as capacidades de raciocínio e uso de computador do Astra a tarefas que abrangem investigação, implementação e testes.

O Codex pode ser acessado pelo aplicativo desktop do ChatGPT, CLI, VS Code, JetBrains IDEs e Xcode. Para desenvolvimento na AWS, o Agent Toolkit for AWS conecta o Codex à documentação, APIs e capacidades de serviços da AWS com um único comando de terminal, permitindo que o agente ajude a desenvolver, implantar e gerenciar aplicações com mais eficiência.

Como começar

É possível começar pelo console do Amazon Bedrock ou de forma programática pelas APIs suportadas. Para informações sobre as Regiões AWS suportadas, endpoints, APIs, funcionalidades, perfis de inferência e preços, consulte a documentação do Amazon Bedrock.

Fonte

Take on your most ambitious work with GPT-6 Astra on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/take-on-your-most-ambitious-work-with-gpt-6-astra-on-amazon-bedrock/)

O problema com a escrita de registros completos

Quem trabalha com o Amazon SageMaker Feature Store já conhece bem o conceito de Feature Group: uma coleção lógica de features relacionadas, usadas por modelos de Aprendizado de Máquina (ML) tanto para treinamento quanto para geração de inferências. Até agora, atualizar qualquer valor dentro de um Feature Group — mesmo que fosse apenas um único campo — exigia um ciclo completo de leitura-modificação-escrita usando a API PutRecord.

Na prática, se um pipeline de detecção de fraudes precisasse atualizar o risk_score de um cliente, a aplicação precisava:

• Ler o registro completo (com todas as features) via GetRecord;
• Mesclar o novo valor no código da aplicação;
• Reescrever o registro inteiro de volta com PutRecord.

Esse padrão introduzia latência extra em cada atualização, consumia capacidade de leitura desnecessária e criava condições de corrida quando múltiplos pipelines atualizavam features diferentes do mesmo registro ao mesmo tempo. No pior cenário, a escrita de um pipeline podia silenciosamente sobrescrever a de outro — o clássico problema de “lost update” (atualização perdida).

Além dos problemas de latência e consistência, esse padrão também gerava custo adicional. As chamadas extras de GetRecord antes de cada escrita acumulavam cobranças de Unidades de Capacidade de Leitura (RCUs). Para quem opera em escala, com Feature Groups amplos e alta frequência de atualizações, esses valores crescem rapidamente.

Apresentando a API UpdateRecord

A AWS anunciou a API UpdateRecord, que elimina completamente o ciclo de leitura-modificação-escrita. Com ela, a aplicação informa apenas as features que deseja alterar, e o SageMaker Feature Store aplica as atualizações de forma atômica ao registro existente. As features não incluídas na requisição são preservadas exatamente como estão.

O diagrama abaixo ilustra como o fluxo de dados funciona com a nova API:

A aplicação cliente chama o UpdateRecord enviando apenas as features alteradas. O serviço do Feature Store valida as permissões do Gerenciamento de Identidade e Acesso (IAM), verifica a ordenação por EventTime para rejeitar escritas desatualizadas e realiza a mesclagem atômica. Apenas as features modificadas são gravadas no online store, enquanto um snapshot completo do registro é replicado automaticamente para o offline store, mantendo os datasets de treinamento precisos. Múltiplos pipelines — como clickstream, compras e scoring — podem escrever suas próprias features de forma independente no mesmo registro, sem necessidade de coordenação.

Formato da requisição

A estrutura da chamada à API segue o formato abaixo:

POST /FeatureGroup/{FeatureGroupName}/Record
{
  "RecordIdentifierValueAsString": "user_123",
  "Features": [
    { "FeatureName": "risk_score", "ValueAsString": "0.87" },
    { "FeatureName": "last_login", "ValueAsString": "2026-07-21T08:15:00Z" }
  ],
  "TtlDuration": { // optional
    "Unit": "Days",
    "Value": 30
  }
}

Pontos importantes sobre os parâmetros:

• FeatureGroupName — o Feature Group de destino.
• RecordIdentifierValueAsString — a chave primária do registro a ser atualizado. O registro já deve existir (UpdateRecord não é um upsert).
• Features — lista com uma ou mais features a serem definidas. Até 100 features por chamada.
• TtlDuration (opcional) — define ou sobrescreve o tempo de vida (TTL) por registro. Se informado, o EventTime também deve estar presente.

Para atualizar o EventTime armazenado com o registro, basta incluí-lo na lista de features. Para que a atualização seja persistida, esse EventTime precisa ser mais recente do que o valor já armazenado — caso contrário, toda a chamada é rejeitada com um erro HTTP 409. Mais detalhes sobre erros estão disponíveis em esta documentação.

Novo formato de armazenamento: Standard_V2

O armazenamento online do SageMaker Feature Store sempre ofereceu dois tiers: o Standard, baseado no Amazon DynamoDB, e o In-Memory, baseado no Amazon ElastiCache (Redis OSS). Com esse anúncio, a AWS introduz um novo formato de armazenamento para o tier Standard chamado Standard_V2, que utiliza uma serialização diferente e habilita as escritas por feature individual.

Importante: quem usa o tier In-Memory não precisa fazer nada — as escritas por feature já funcionam em todos os Feature Groups In-Memory existentes. Já para o tier Standard, é necessário adotar o novo formato Standard_V2.

Para criar um Feature Group com o novo formato, basta especificar o StorageType na criação:

import boto3
sm = boto3.client("sagemaker")

sm.create_feature_group(
    FeatureGroupName="user-profile-fg",
    RecordIdentifierFeatureName="user_id",
    EventTimeFeatureName="event_time",
    OnlineStoreConfig={
        "EnableOnlineStore": True,
        "StorageType": "Standard_V2"  # enables feature-level writes
    },
    FeatureDefinitions=[
        {"FeatureName": "user_id",       "FeatureType": "String"},
        {"FeatureName": "event_time",    "FeatureType": "String"},
        {"FeatureName": "risk_score",    "FeatureType": "Fractional"},
        {"FeatureName": "last_login",    "FeatureType": "String"},
        {"FeatureName": "balance",       "FeatureType": "Fractional"},
    ],
)

Migrando Feature Groups existentes para Standard_V2

Para quem já possui Feature Groups no formato Standard original, a AWS disponibiliza duas estratégias de migração para o Standard_V2.

Estratégia A: Migração em bloco com o Feature Processor SDK

Utiliza o Feature Processor SDK para ler os registros do Feature Group existente e reingestá-los em um novo Feature Group Standard_V2.

• Vantagens: controle total sobre o timing; o Feature Group original permanece intacto durante a migração; rollback é simples, basta apontar de volta para o grupo antigo.
• Desvantagens: exige um job de migração gerenciado; você paga o custo completo de leitura e escrita de todo o dataset de uma vez; é necessário atualizar os clientes da aplicação para apontar para o novo nome do Feature Group.

Estratégia B: Troca controlada in-place com a API UpdateFeatureGroup

Basta chamar UpdateFeatureGroup com OnlineStoreConfig.StorageType = "Standard_V2" para alterar o formato do Feature Group sem criar um novo:

import boto3
sm = boto3.client("sagemaker")

sm.update_feature_group(
    FeatureGroupName="my-existing-fg",
    OnlineStoreConfig={"StorageType": "Standard_V2"}
)

Após a declaração, as chamadas a PutRecord ou BatchWriteRecord já atualizam o formato subjacente para Standard_V2. Essa abordagem tem zero downtime e cobra o custo de migração apenas para os registros efetivamente tocados, além de preservar o código de aplicação existente, pois o nome do Feature Group e os endpoints da API permanecem os mesmos. O ponto de atenção é que a troca para Standard_V2 é irreversível, e registros “frios” que nunca forem escritos continuarão no formato legado até serem tocados.

Recomendação da AWS: para a maioria dos casos, a Estratégia B é a preferida, por causa do zero downtime e da economia de pagar apenas pelo que é tocado. A Estratégia A deve ser usada apenas quando for necessário um caminho de rollback completo ou quando houver necessidade de renomear ou reestruturar o Feature Group.

Ordenação temporal com EventTime

O UpdateRecord suporta a mesma ordenação baseada em EventTime que o PutRecord. Quando um EventTime é incluído na requisição:

• Se o EventTime fornecido for mais recente ou igual ao atual do registro, a atualização é aplicada e o EventTime do registro avança.
• Se o EventTime fornecido for anterior ao atual, a atualização é rejeitada com um erro 409 ConflictException.

Quando o EventTime é omitido, as novas features são aplicadas e o EventTime existente no registro permanece inalterado — ideal para arquiteturas multi-pipeline onde diferentes pipelines gerenciam features distintas e não compartilham um único relógio de evento.

Casos de uso

Hidratação de features em streaming

Cenários em tempo real geralmente envolvem dados gerados por múltiplos fluxos em frequências diferentes. Por exemplo: um pipeline de clickstream recebe page_views e session_duration a cada poucos segundos, enquanto um pipeline batch noturno atualiza lifetime_value e customer_segment. Com o UpdateRecord, cada pipeline envia apenas as features que gerencia, sem coordenação e sem risco de perda de atualizações.

Backfill de novas features

Quando a equipe adiciona novas features a um Feature Group existente — como preferred_language e notification_opt_in — basta chamar UpdateRecord com apenas os novos valores. Os valores de features existentes permanecem intocados.

Correção de erros em escala

Se um job de qualidade de dados descobrir que customer_segment está categorizado incorretamente em 50.000 registros, o UpdateRecord permite corrigir esse único campo em todos os registros sem risco de corromper outros valores de features.

Atualizações de features em alta velocidade

Em sistemas de detecção de fraudes que recebem transaction_velocity a cada transação de cartão, o UpdateRecord permite que cada escrita toque apenas a feature que mudou, eliminando o overhead de escritas de registro completo em escala.

Feature Groups multi-produtor para entidades corporativas

Grandes organizações costumam modelar seu Feature Store em torno de entidades de negócio centrais — um Feature Group por tipo de entidade — com dezenas de produtores independentes contribuindo features para os mesmos registros. Sem o UpdateRecord, cada produtor precisava ler o registro completo, injetar seu subconjunto e reescrever a entidade inteira, criando jobs de compactação, condições de corrida e custos mensais elevados em operações de leitura e escrita. Com o UpdateRecord, cada produtor escreve apenas suas próprias features de forma atômica, eliminando a necessidade de soluções customizadas de compactação.

Controle de acesso granular com IAM

O UpdateRecord se integra ao IAM, permitindo controlar exatamente quem pode atualizar quais features. Duas novas chaves de condição IAM foram disponibilizadas:

• sagemaker:IsUpdateRecord (Bool) — distingue operações de atualização parcial das escritas completas via PutRecord.
• sagemaker:UpdatableFeatures (ArrayOfString) — restringe quais nomes de features um principal pode atualizar.

Exemplo de política que permite atualizações apenas em features não sensíveis:

{
  "Effect": "Allow",
  "Action": "sagemaker:PutRecord",
  "Resource": "arn:aws:sagemaker:*:*:feature-group/user-profile-fg",
  "Condition": {
    "Bool": {
      "sagemaker:IsUpdateRecord": "true"
    },
    "ForAllValues:StringEquals": {
      "sagemaker:UpdatableFeatures": ["age", "score", "last_activity"]
    }
  }
}

Essa política permite ao principal chamar UpdateRecord apenas nas features age, score e last_activity, bloqueando atualizações em qualquer outra feature (como ssn ou salary) e bloqueando chamadas diretas ao PutRecord.

Um ponto importante sobre compatibilidade retroativa: políticas IAM existentes que negam sagemaker:PutRecord automaticamente bloqueiam o UpdateRecord também. Nenhuma migração de controles de segurança é necessária.

Integração com o offline store e considerações de preço

As atualizações feitas pelo UpdateRecord fluem para o offline store automaticamente pelo mesmo pipeline de replicação usado pelo PutRecord. Cada atualização emite um snapshot completo do registro para o offline store, mantendo os datasets de treinamento e análises históricas precisos.

Algumas restrições importantes a ter em mente:

• O registro deve existir previamente — o UpdateRecord é estritamente uma operação de modificação. Use o PutRecord primeiro para criar o registro.
• Os nomes de features precisam estar definidos no schema do Feature Group — não é possível adicionar features que não existam.
• O identificador do registro é imutável — a chave primária não pode ser modificada via UpdateRecord.
• O TTL exige EventTime — se TtlDuration for especificado, o EventTime também deve estar presente na requisição.

Em relação ao preço, o UpdateRecord segue o mesmo modelo de precificação do PutRecord. Para o tier Standard, as cobranças de Unidades de Capacidade de Escrita (WCU) do DynamoDB são baseadas no tamanho do item após a atualização. A economia vem da eliminação das leituras que antes eram necessárias no ciclo de leitura-modificação-escrita. Mais detalhes estão disponíveis na página de preços do Amazon SageMaker Feature Store.

Como começar

As escritas por feature com o UpdateRecord já estão disponíveis em todas as regiões AWS onde o Amazon SageMaker Feature Store é oferecido. Para começar:

• Crie um Feature Group com StorageType: Standard_V2 (tier Standard) ou use qualquer Feature Group In-Memory existente.
• Ingira registros usando o PutRecord normalmente.
• Chame o UpdateRecord para atualizar features individuais sem reescrever o registro completo.

Para mais informações, consulte o Guia do Desenvolvedor do Amazon SageMaker Feature Store e a Referência da API UpdateRecord.

Conclusão

A API UpdateRecord representa uma evolução significativa na forma como equipes de ML gerenciam features em produção. Ao eliminar o ciclo de leitura-modificação-escrita, a AWS reduz latência, diminui custos de transferência de dados em atualizações de features individuais e minimiza o risco de perda de atualizações em arquiteturas multi-pipeline. Combinada com controles IAM granulares e replicação automática para o offline store, essa novidade simplifica a construção de workflows de engenharia de features mais eficientes e confiáveis — seja para atualizar um único risk score em tempo real ou para coordenar dezenas de produtores independentes escrevendo em Feature Groups compartilhados de nível corporativo.

Fonte

Amazon SageMaker Feature Store introduces UpdateRecord for feature-level writes (https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-feature-store-introduces-updaterecord-for-feature-level-writes/)

O que foi anunciado

A AWS anunciou a disponibilidade geral do GPT-6 Astra, da OpenAI, no Amazon Bedrock. Trata-se do modelo mais recente e mais capaz da OpenAI até o momento, agora acessível diretamente dentro da infraestrutura gerenciada da AWS — com toda a camada de segurança, governança e escala que o Bedrock já oferece para cargas de trabalho em produção.

O que o GPT-6 Astra traz de novo

O GPT-6 Astra foi projetado para fluxos de trabalho empresariais mais exigentes. Entre os principais diferenciais anunciados estão:

• Raciocínio e julgamento aprofundados — o modelo é capaz de lidar com situações que exigem análise de entradas concorrentes e tomada de decisão complexa.
• Escrita e design de qualidade profissional — geração de conteúdo alinhada à voz, aos templates e aos padrões da organização.
• Uso avançado de computador e navegador — o modelo consegue operar de forma autônoma em ambientes de software e navegação web.
• Janela de contexto de até 1 milhão de tokens de entrada — ideal para análise de grandes coleções de documentos ou bases de código extensas.

Como usar no Amazon Bedrock

O GPT-6 Astra pode ser chamado diretamente pelas APIs (Interfaces de Programação de Aplicações) suportadas pelo Amazon Bedrock. Além disso, é possível configurar o ChatGPT Work e o Codex para utilizarem o modelo rodando sobre a infraestrutura do Bedrock.

Com isso, equipes de engenharia e produto podem usar o modelo para:

• Construir agentes autônomos;
• Analisar coleções extensas de documentos;
• Investigar problemas complexos de software;
• Criar aplicações que exijam julgamento sobre múltiplas entradas concorrentes.

Novos plugins empresariais do ChatGPT Work

Junto com este lançamento, a OpenAI também está introduzindo novos plugins empresariais para o ChatGPT Work. Esses plugins estendem as capacidades de uso de navegador do Astra para aplicações de negócio comuns, ampliando ainda mais as possibilidades de automação em ambientes corporativos.

Segurança e governança com controles AWS

Por rodar dentro do Amazon Bedrock, o GPT-6 Astra herda os controles estabelecidos da AWS para segurança de cargas de trabalho, governança de acesso e auditoria de invocações do modelo. Isso é especialmente relevante para organizações que precisam manter conformidade e rastreabilidade no uso de modelos de IA (Inteligência Artificial) em produção.

Como começar

É possível dar os primeiros passos diretamente pelo console do Amazon Bedrock ou de forma programática pelas APIs suportadas. Para detalhes sobre as regiões AWS (Amazon Web Services) suportadas, endpoints, APIs, funcionalidades, perfis de inferência e preços, a AWS disponibiliza a documentação oficial do Amazon Bedrock. Para saber mais sobre o que é possível construir com o GPT-6 Astra, vale conferir também o post no blog oficial.

Fonte

OpenAI GPT-6 Astra is now generally available on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/09/openai-gpt-6-astra-on-amazon-bedrock/)

O que mudou no SageMaker Feature Store

A AWS anunciou uma nova capacidade no Amazon SageMaker Feature Store: a partir de agora, o serviço suporta escritas no nível de feature individual, permitindo que cientistas de dados atualizem apenas os campos necessários de um registro, sem precisar reescrever o registro completo.

Como funcionava antes — e o que mudou

Até então, qualquer atualização em um registro do Feature Store exigia que o pipeline lesse o registro inteiro, aplicasse a modificação desejada e reescrevesse tudo de volta — o chamado padrão read-modify-write. Esse fluxo adicionava latência e custo desnecessários, especialmente em cenários de alto volume de processamento.

Com a nova funcionalidade de feature-level writes, uma única chamada de atualização é suficiente para substituir esse padrão completo. O cientista de dados envia apenas os campos que precisam ser alterados, e todos os outros valores do registro permanecem intactos — sem necessidade de lógica de merge no pipeline de ingestão de dados.

Benefícios práticos para pipelines de ML

Um dos cenários mais beneficiados é quando múltiplos pipelines escrevem no mesmo grupo de features. Imagine um job de streaming em tempo real e um job batch noturno que precisam atualizar o mesmo registro: com a nova capacidade, cada pipeline atualiza apenas as features que ele próprio computa, de forma independente, sem interferir nos dados do outro.

Isso traz duas vantagens diretas:

• Menor latência de escrita: cada operação toca apenas o que precisa ser atualizado.
• Menor custo: menos dados trafegados e processados a cada operação de escrita.

Disponibilidade

A funcionalidade já está disponível em todas as regiões da AWS onde o Amazon SageMaker Feature Store está presente. Para aprofundar, a AWS disponibiliza a documentação da Amazon Feature Store Runtime, a documentação do Standard V2 e o blog de lançamento com mais detalhes técnicos.

Fonte

Amazon SageMaker Feature Store now supports individual feature updates to lower write latency (https://aws.amazon.com/about-aws/whats-new/2026/08/sgm-feature-store-update-record/)

O que é uma fábrica de modelos de IA Física?

Sistemas de Inteligência Artificial Física — como robôs ou veículos autônomos (VA) que traduzem dados do mundo real em ações físicas — não nascem de um único job de treinamento. Eles exigem um ciclo contínuo: gerar dados sintéticos, realizar pós-treinamento de modelos de percepção e política, e avaliar tudo isso em simulação de malha fechada. Esse ciclo contínuo é o que a AWS chama de Physical AI model factory (fábrica de modelos de IA Física): um pipeline que transforma um fluxo constante de dados reais em modelos progressivamente melhores.

A AWS publicou um guia técnico detalhado explicando como montar essa estrutura usando o NVIDIA Cosmos 3 no Amazon SageMaker HyperPod. O código completo, incluindo templates de infraestrutura e manifestos de job, está disponível no repositório awsome-distributed-ai no GitHub.

O que torna o NVIDIA Cosmos 3 diferente

O Cosmos 3 é um modelo de fundação omnimodal de mundo aberto, lançado pela NVIDIA sob a licença OpenMDW-1.1 da Linux Foundation. Sua arquitetura é descrita no relatório técnico do Cosmos 3 e se diferencia por três escolhas de design principais:

• Um único fluxo de tokens: todas as modalidades — vídeo, imagem, áudio e ações — alimentam uma sequência compartilhada. Um Transformador de Visão (ViT) trata da compreensão de imagens, enquanto um autoencoder variacional (VAE) de vídeo congelado cuida da geração de pixels. O mesmo vetor de ação compacto permite que o modelo controle tanto um veículo autônomo quanto um braço robótico.
• Dois especialistas por camada — Mistura de Transformadores (MoT): cada camada executa um “raciocinador” (que prevê o próximo token) e um “gerador” (que remove ruído de vídeo, áudio e ações). Atenção de fluxo duplo os conecta em cada camada, mantendo a geração ancorada na saída do raciocinador ao longo de todo o processo — não apenas no final.
• Assimetria entre treinamento e inferência: durante o treinamento, o modelo executa o cronograma completo de remoção de ruído e decodifica o vídeo até os pixels. No robô implantado, o mesmo modelo executa apenas alguns passos de remoção de ruído e ignora completamente a decodificação de vídeo. Os latentes de vídeo ainda são produzidos internamente para ancorar a ação, mas apenas os tokens de ação são decodificados nas posições de junta que o robô executa.

Três modos de operação, uma única arquitetura

O checkpoint base do Cosmos 3 opera em três modos distintos, definidos apenas por quais tokens começam como ruído:

• Dinâmica direta (modelo de mundo): ações limpas, vídeo ruidoso. Responde à pergunta “dado este frame e esta ação, o que vem a seguir?” — é o motor de geração de dados sintéticos para cenas raras ou de cauda longa.
• Dinâmica inversa (rotulador de ações): vídeo limpo, ação ruidosa. Converte vídeos não rotulados (gravações de teleoperação, vídeos de robôs em terceira pessoa, filmagens de direção) em dados de treinamento com rótulos de ação.
• Política (o robô implantado): ambos ruidosos, condicionados em imagem de 3 visões mais propriocepção. Produz 32 posições futuras de junta, com frames de vídeo previstos como subproduto que ancora a predição de ação.

A família de modelos tem dois níveis: Cosmos3-Nano (16B parâmetros, sobre um backbone Qwen3-VL denso de 8B) e Cosmos3-Super (64B parâmetros, sobre um backbone Qwen3-VL denso de 32B). A NVIDIA também lançou o Cosmos3-Edge, um nível compacto de 4B para implantação em dispositivos como Jetson Thor e Orin.

Do modelo único à fábrica perpétua de modelos

Uma equipe desenvolvendo um robô ou VA não executa um único job de fine-tuning. Ela opera um ciclo de quatro estágios:

• (1) Ingestão e curadoria de dados reais (DROID, BridgeData2, logs de sensores de VA) em um corpus compartilhado no Amazon S3 e Amazon FSx for Lustre.
• (2) Geração sintética: um professor Cosmos3-Super gera dados sintéticos para aumentar esse corpus.
• (3) Pós-treinamento: o corpus combinado pós-treina uma política Cosmos3-Nano implantável, com fine-tuning de visão aplicado em ambos os níveis Nano e Super.
• (4) Avaliação: a política é avaliada em simulação de malha fechada, e suas falhas se tornam novos alvos de geração que reingressam no corpus para a próxima rodada.

O que torna esse ciclo economicamente viável é o conceito de GPU goodput: o progresso útil do pipeline por hora de GPU reservada em todo o ciclo. O goodput é maximizado quando os estágios compartilham um único pool de GPUs, evitando horas perdidas com re-provisionamento ou migração de dados entre clusters separados.

Por que o SageMaker HyperPod é a infraestrutura ideal

O Amazon SageMaker HyperPod com Amazon Elastic Kubernetes Service (EKS) entrega exatamente a forma que esse ciclo exige. Quatro propriedades são centrais:

• Um cluster para todos os estágios: geração roda no servidor vLLM-Omni, pós-treinamento no cosmos-framework via torchrun com Paralelismo de Dados Totalmente Fragmentado (FSDP2) mais paralelismo de contexto Ulysses, e avaliação em um servidor de política de GPU única — tudo como workloads Kubernetes comuns em um único pool de GPUs compartilhado.
• Camada de armazenamento unificada: um sistema de arquivos Amazon FSx for Lustre, acessado via Elastic Fabric Adapter (EFA) e vinculado a um bucket S3 por uma associação de repositório de dados (DRA), é montado uma vez e serve todos os três estágios no mesmo caminho. Sem migrações de dados em escala de terabytes entre estágios.
• Capacidade com verificação de saúde e auto-recuperação: o HyperPod detecta nós com falha continuamente e os reinicializa ou substitui automaticamente. O auto-resume gerenciado transforma uma falha de worker em uma recuperação limitada: o PyTorchJob recria o gang de pods, o NCCL se reforma, e o cosmos-framework retoma do último checkpoint.
• EFA pré-configurado para NCCL multi-nó: as longas sequências do Cosmos 3 (latentes de vídeo mais texto mais ação, dezenas de milhares de tokens cada) exigem paralelismo de contexto sobre o FSDP2. O HyperPod vem com a pilha EFA pré-configurada, e quando combinado com uma imagem AWS Deep Learning Containers (DLC), o NCCL sobre EFA funciona sem configuração adicional.

Configuração do cluster e da camada de armazenamento

A maioria dos pré-requisitos pode ser satisfeita com os módulos Terraform do HyperPod-EKS, que provisionam o cluster HyperPod orquestrado por EKS, a Nuvem Privada Virtual (VPC) com grupos de segurança habilitados para EFA, o sistema de arquivos FSx for Lustre e o driver CSI, o operador de treinamento Kubeflow e o add-on de observabilidade. Alternativamente, é possível usar o console do Amazon SageMaker AI para criar esses recursos via AWS CloudFormation.

Antes de executar o primeiro job, é necessário ter em mãos: um cluster HyperPod com grupo de instâncias p5en.48xlarge em uma única Zona de Disponibilidade; cota de serviço suficiente para o tipo de instância escolhido, solicitada via AWS Service Quotas; o driver CSI do FSx for Lustre instalado; e um token de leitura do Hugging Face com a licença nvidia/Cosmos-Guardrail1 aceita.

Escolha da imagem base de treinamento

A escolha da imagem base é uma decisão deliberada, não uma suposição. O ambiente virtual do cosmos-framework fixa torch==2.10.0+cu130 (CUDA 13), e suas dependências CUDA são publicadas apenas para CPython 3.13. Uma imagem incompatível pode bloquear o NCCL multi-nó: o plugin aws-ofi-nccl da imagem precisa ter sido construído contra a mesma versão de NCCL que o framework usa.

A imagem AWS Deep Learning Containers para PyTorch entrega torch 2.10.0+cu130 — correspondência exata com o pin do cosmos-framework — e inclui uma pilha EFA ajustada pela AWS e com versões compatíveis (EFA 1.47.0, libfabric 2.4, aws-ofi-nccl 1.18.0, GDRCopy 2.5.1). Dois problemas adicionais surgiram no caminho de decodificação de vídeo do DROID na DLC: uma versão do FFmpeg antiga demais para o torchcodec e uma libpython compartilhada ausente. Ambos têm correções incorporadas ao Dockerfile do repositório.

Camada de armazenamento: dois regimes de I/O

Os workloads não estressam o armazenamento da mesma forma. Os dados de política robótica (dataset LeRobot/DROID) representam um regime de metadados e arquivos pequenos, onde taxa de requisições e latência importam mais do que largura de banda bruta. Já os dados de Ajuste Fino Supervisionado (SFT) de visão representam um regime de largura de banda e arquivos grandes, onde o throughput sustentado domina.

Para o FSx for Lustre com EFA, um sistema de arquivos PERSISTENT_2 sem EFA limita a 100 Gbps por instância cliente, enquanto um sistema de arquivos FSx for Lustre habilitado para EFA alcança 700 Gbps por cliente via EFA. Com GPUDirect Storage em instâncias GPU NVIDIA habilitadas para EFA como a p5en, chega a até 1200 Gbps. A AWS recomenda habilitar EFA para qualquer sistema de arquivos acima de 10 GBps. O ajuste por diretório do Lustre — incluindo contagem e tamanho de stripe, layouts de arquivo progressivos e read-ahead do lado do cliente — é uma otimização adicional que pode ser aplicada por padrão de acesso.

Pós-treinamento distribuído: três workloads representativos

A solução pós-treina três workloads representativos, cada um correspondendo a um estágio do ciclo, todos rodando em nós p5en.48xlarge (8x NVIDIA H200 GPUs):

• Política robótica (DROID): pós-treinamento de política de ação no dataset público LeRobot v3 (droid_policy.toml). O workload mais leve por passo.
• Ajuste Fino Supervisionado (SFT) de visão: SFT de vídeo mais legenda no Cosmos3-Nano (vision_sft_nano.toml). Substancialmente mais pesado por passo.
• Adaptação de Baixo Rank (LoRA) de visão: fine-tuning LoRA do modelo de 64B com paralelismo de contexto no Cosmos3-Super (vision_sft_super.toml). O workload mais pesado por passo.

O Nano de 16B é totalmente fine-tunado porque é o modelo que vai para o robô e é pequeno o suficiente para treinamento de parâmetros completos. O Super de 64B é adaptado com LoRA em vez de retreinado completamente: congelar o backbone e treinar adaptadores de rank-16 reduz a memória do otimizador, encolhe os checkpoints de um snapshot de 64B para megabytes de tensores de adaptadores, e permite que uma única base Super congelada sirva a muitos domínios apenas trocando adaptadores.

Checkpointing resiliente

O cosmos-framework escreve checkpoints como Checkpoint Distribuído PyTorch (DCP). Três configurações no bloco de checkpoint do experimento action_policy_public_lerobot são importantes para um warm-start resiliente: dcp_async_mode_enabled, strict_resume e keys_to_skip_loading. O modo DCP assíncrono mantém o overhead de checkpoint em estado estacionário negligível enquanto limita o trabalho perdido em caso de falha. Combinado com o auto-resume do HyperPod, uma reinicialização de pod ou substituição de nó continua automaticamente a partir do último checkpoint.

Medindo o que importa: metodologia de goodput

A AWS descreve uma configuração de métricas reproduzível construída sobre o add-on de observabilidade do HyperPod EKS, unificando telemetria de GPU e métricas de treinamento do cosmos-framework em um único painel do Amazon Managed Grafana. O dashboard cosmos3-goodput-dashboard.json pode ser importado conforme descrito no README de observabilidade.

Métricas de infraestrutura e GPU fluem para o Amazon Managed Service for Prometheus via exportadores DCGM e de nó, sem instrumentação customizada. O add-on de observabilidade do SageMaker HyperPod fornece as visões de cluster, nó e job. As métricas do cosmos-framework são conectadas via uma ponte OpenTelemetry Protocol (OTLP) que espelha os escalares do framework para o coletor OTLP in-cluster do add-on de observabilidade (o serviço hyperpod-otel-collector, acessível em http://hyperpod-otel-collector.hyperpod-observability.svc:4317 via gRPC). O repositório inclui o dashboard Grafana e a ponte OTLP que renderizam ambas as fontes de métricas juntas.

Intervalo de checkpoint ótimo para goodput

A fórmula de Young/Daly fornece o intervalo ótimo que equilibra os dois custos — salvar raramente demais desperdiça trabalho em falhas; salvar com frequência demais consome computação útil:

intervalo ≈ √(2 × C × MTBF)

Onde C é o custo de salvamento do checkpoint e MTBF é o tempo médio entre falhas. Por exemplo, com um custo de salvamento de 30 segundos e um MTBF de 24 horas (86.400 s), o intervalo ótimo é aproximadamente 2.300 s, ou cerca de 40 minutos. O overhead de checkpoint fica em torno de 1% do tempo de parede. Como referência de ordem de grandeza, o pré-treinamento do Llama 3 405B da Meta registrou uma interrupção a cada três horas em 16.384 GPUs H100 — mas trate isso apenas como ilustração, não como número a reutilizar. O MTBF é uma quantidade de nível de frota: para N nós, é aproximadamente o MTBF por nó dividido por N.

Os outros estágios do ciclo: geração e avaliação

O mesmo cluster, imagem e camada de armazenamento executam os estágios de geração e avaliação, fechando o ciclo.

Geração (limitada por escrita): a geração roda em uma imagem separada do treinamento — o motor oficial vllm/vllm-omni:cosmos3 — como um servidor compatível com OpenAI que aceita requisições de vídeo-para-vídeo (V2V) do Cosmos3-Super. Após o servidor estar pronto, basta fazer um port-forward e enviar um clipe de condicionamento para receber uma continuação gerada. O clipe retornado é um exemplo sintético que alimenta a próxima rodada de pós-treinamento. Consulte o manifesto de geração para os detalhes de configuração.

Avaliação (limitada por latência): um Deployment leve de GPU única serve uma política de ação do Cosmos 3 via HTTP para avaliação em malha fechada, usando o mesmo volume FSx para que qualquer checkpoint produzido no cluster esteja diretamente disponível. O loop de controle do simulador confirma que o servidor está ativo com GET /info, depois envia uma observação para POST /predict a cada passo e recebe o próximo chunk de ação. Consulte o manifesto de serving de política para os detalhes.

Considerações de custo e limpeza

O SageMaker HyperPod é um cluster persistente: instâncias são cobradas enquanto fazem parte do cluster, o FSx for Lustre cobra por hora por capacidade provisionada, e qualquer pod de serving ou visualização mantém um nó de GPU ativo enquanto estiver rodando. Consulte as páginas de preços do Amazon SageMaker AI e do Amazon FSx for Lustre para valores atuais. Para pausar os custos de instância entre sessões mantendo o cluster configurado, basta escalar o grupo de instâncias de GPU para zero. Veja como gerenciar um cluster SageMaker HyperPod para detalhes.

Ao deletar o sistema de arquivos FSx, a cópia local de checkpoints e logs é removida. Dados escritos sob o DRA do S3 são exportados de volta ao bucket vinculado e sobrevivem, mas qualquer dado fora desse caminho (ou ainda não exportado) é perdido.

Resultados e boas práticas

Nos testes realizados em nós p5en (H200), o workload LoRA do Super (64B) manteve eficiência de escalonamento forte quase linear ao escalar de 1 a 4 nós (8 a 32 GPUs), ficando em aproximadamente 0,97–0,99 do linear. A Utilização de FLOPs do Modelo (MFU) ficou próxima de 0,50 para o workload Super (mais intensivo computacionalmente) e próxima de 0,24 para o workload de visão Nano (mais leve).

As principais lições práticas são: dimensione a contagem de nós pelo seu objetivo de tempo de execução por workload; rastreie o tempo por passo (não iterações por hora) como sinal de throughput; escolha o backend de armazenamento pelo padrão de acesso, não por uma preferência única; e expresse o retorno da resiliência gerenciada como tempo recuperado e melhoria na fração de goodput.

Por onde começar

Para explorar a solução na prática, acesse o repositório awsome-distributed-ai no GitHub e use a receita LeRobotV3ActionDataset como ponto de partida para adaptar ao seu próprio dataset. Para aprofundar o conhecimento, consulte o site do NVIDIA Cosmos, o repositório cosmos-framework e a documentação do Amazon SageMaker HyperPod.

Fonte

Build a Physical AI model factory with NVIDIA Cosmos 3 on SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/build-a-physical-ai-model-factory-with-nvidia-cosmos-3-on-sagemaker-hyperpod/)

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: All

Isso 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: prefixaware

O 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/)