Author: Make.com Service User

O que foi anunciado

A AWS anunciou a disponibilidade da funcionalidade de busca na web (web search) para o Kiro dentro do ambiente AWS GovCloud (US). Com isso, o agente passa a ter acesso a informações em tempo real da internet, enriquecendo suas respostas com resultados e conteúdos de páginas atualizadas.

Como o agente usa a busca na web

O Kiro aciona a busca na web de forma automática sempre que identifica que uma pergunta envolve eventos recentes ou tópicos que estão além dos dados com os quais o modelo foi treinado. Em outras palavras: quando o conhecimento interno do agente não é suficiente para responder com precisão, ele vai buscar na internet.

Um detalhe importante é a transparência: todas as respostas que utilizarem resultados da web incluirão citações das fontes consultadas, o que facilita a verificação das informações pelo usuário.

Controles administrativos para equipes corporativas

Para organizações que utilizam o Kiro em ambiente corporativo, a AWS disponibilizou controles granulares de governança sobre esse recurso. Os administradores corporativos do Kiro podem:

• Desativar completamente a busca na web e o web fetch para toda a organização, diretamente pelo console do Kiro, na seção de Configurações (Settings);
• Remover as ferramentas de web de agentes personalizados individuais;
• Bloquear o uso dessas ferramentas por meio de regras de permissão baseadas em capacidades (capability-based permission rules).

Essa flexibilidade é especialmente relevante para o contexto do GovCloud, onde políticas de conformidade e controle de acesso costumam ser mais rigorosas.

Onde encontrar mais informações

Para quem quiser se aprofundar, a AWS disponibilizou a documentação oficial do AWS GovCloud (US) com detalhes sobre o Kiro nesse ambiente. Também está disponível o guia de monitoramento e rastreamento para acompanhar o uso do recurso. Para conhecer mais sobre o Kiro de forma geral, a página oficial do produto é o ponto de partida recomendado.

Fonte

Web Search now available on Kiro in AWS GovCloud (US) (https://aws.amazon.com/about-aws/whats-new/2026/10/kiro-web-search-aws-govcloud-us/)

O problema de coordenar GPUs entre múltiplas equipes

Quem já gerenciou ambientes de treinamento de modelos de aprendizado de máquina (Machine Learning — ML) em escala sabe o quanto é trabalhoso dividir recursos de unidades de processamento gráfico (Graphics Processing Unit — GPU) entre times diferentes. À medida que as organizações crescem e mais equipes passam a usar a mesma infraestrutura de inteligência artificial e aprendizado de máquina (Artificial Intelligence/Machine Learning — AI/ML), surgem problemas clássicos: filas separadas para cada time, ajustes manuais de limites de capacidade, e uma quantidade considerável de comunicação e coordenação para garantir que o workload certo receba o recurso certo na hora certa.

Foi exatamente esse cenário que motivou a AWS a desenvolver o gerenciamento de cotas (quota management), uma nova capacidade de agendamento dentro do AWS Batch. A proposta é clara: permitir que administradores definam alocações por equipe ou projeto, compartilhem capacidade ociosa de forma automática e executem os workloads de maior prioridade primeiro — sem precisar gerenciar isso manualmente.

Como funciona o gerenciamento de cotas

O gerenciamento de cotas introduz o conceito de quota shares (cotas compartilhadas), que funcionam como filas virtuais aninhadas dentro de uma job queue do AWS Batch. Cada quota share representa uma entidade — uma equipe, um projeto ou um tipo de workload — e possui dois elementos principais:

• Cotas de computação: os limites de capacidade que aquela cota pode usar.
• Estratégias de compartilhamento de recursos: regras que determinam o que acontece com a capacidade ociosa.

Existem três estratégias de compartilhamento disponíveis:

• RESERVE: a capacidade fica reservada para a própria cota, mesmo quando ociosa. Não empresta nem toma emprestado de outras cotas.
• LEND: a capacidade ociosa é emprestada para outras cotas que tenham trabalho disponível. Quando um job chega na cota que emprestou, o AWS Batch recupera automaticamente os recursos.
• LEND_AND_BORROW: além de emprestar quando ociosa, a cota também pode tomar capacidade emprestada de outras cotas quando tiver jobs aguardando.

Preempção entre cotas e dentro de cotas

Dois mecanismos de preempção tornam o sistema ainda mais inteligente:

Preempção entre cotas (cross-share preemption): quando uma cota que emprestou sua capacidade recebe novos jobs, o AWS Batch automaticamente recupera esses recursos — sem que o administrador precise identificar e encerrar manualmente os jobs que estavam usando a capacidade emprestada.

Preempção dentro da cota (in-share preemption): quando ativada em uma quota share, permite que jobs de maior prioridade submetidos àquela cota interrompam jobs de menor prioridade que já estejam nos estados SCHEDULED, STARTING ou RUNNING. Isso garante que trabalhos urgentes comecem a executar mais rapidamente.

Pré-requisitos

Para seguir o exemplo descrito pela AWS, é necessário ter uma conta AWS com permissões para criar e gerenciar recursos do AWS Batch. As permissões de IAM de exemplo necessárias para invocar as APIs do AWS Batch e do SageMaker estão disponíveis no repositório oficial. O exemplo utiliza o SageMaker Python SDK v3, que pode ser instalado com:

!pip install sagemaker

Configurando os recursos de gerenciamento de cotas

Para usar o gerenciamento de cotas, a AWS requer a criação de três componentes principais:

• Uma Política de Agendamento (Scheduling Policy) contendo a quotaSharePolicy.
• Um Ambiente de Serviço (Service Environment) que define os limites de capacidade em termos de instâncias específicas.
• Uma fila de jobs de treinamento do SageMaker conectada aos dois anteriores.

O guia de usuário do AWS Batch traz exemplos via Interface de Linha de Comando (AWS Command Line Interface — AWS CLI) e console para configurar os recursos de gerenciamento de cotas e quota shares. Um exemplo completo integrado ao módulo aws_batch do SageMaker Python SDK v3 está disponível em um notebook de exemplo.

Exemplo com três projetos distintos

O exemplo oficial da AWS demonstra três quota shares representando três projetos diferentes, cada um com o mesmo limite de capacidade: uma instância ml.g5.xlarge.

QS1 — Jobs em segundo plano (background jobs): configurada com a estratégia LEND_AND_BORROW e preempção interna ativada. Isso permite que ela tome capacidade emprestada de outras cotas e que jobs de maior prioridade dentro dela interrompam os de menor prioridade. O uso de checkpointing é assumido, tornando preempções aceitáveis.

from sagemaker.train.aws_batch.boto_client import get_batch_boto_client
from utils.aws_batch_resource_management import AwsBatchResourceManager, QuotaShareConfig, create_quota_management_resources

INSTANCE_TYPE = "ml.g5.xlarge"

# Create SchedulingPolicy, ServiceEnvironment, JobQueue, and QuotaShares
resource_manager = AwsBatchResourceManager(get_batch_boto_client())
qs1 = QuotaShareConfig(
    name="QS1",
    capacity_unit=INSTANCE_TYPE,
    max_capacity=1,
    in_share_preemption=True,
    sharing_strategy="LEND_AND_BORROW",
    borrow_limit=200
)

QS2 — Workloads de prioridade média: configurada com a estratégia LEND e preempção interna desativada. Ideal para jobs mais curtos ou quando a maioria dos jobs submetidos tem prioridades similares. A cota ainda empresta sua capacidade ociosa, e quando um job chega, o AWS Batch recupera automaticamente o que foi emprestado.

qs2 = QuotaShareConfig(
    name="QS2",
    capacity_unit=INSTANCE_TYPE,
    max_capacity=1,
    in_share_preemption=False,
    sharing_strategy="LEND"
)

QS3 — Workloads críticos com mínima interrupção: configurada com a estratégia RESERVE e preempção interna desativada. Não empresta nem toma emprestado, garantindo que os workloads submetidos a essa cota não sofram preempções pelo AWS Batch enquanto o limite de capacidade não for alterado.

qs3 = QuotaShareConfig(
    name="QS3",
    capacity_unit=INSTANCE_TYPE,
    max_capacity=1,
    in_share_preemption=False,
    sharing_strategy="RESERVE"
)

Essas configurações são então passadas para a função create_quota_management_resources, que cria a Scheduling Policy, o Service Environment e a Job Queue de forma integrada:

SCHEDULING_POLICY_NAME = "my-qm-scheduling-policy"
JOB_QUEUE_NAME = "my-sm-training-qm-jq"
SERVICE_ENVIRONMENT_NAME = "my-sm-training-qm-se"

resources = create_quota_management_resources(
    resource_manager=resource_manager,
    scheduling_policy_name=SCHEDULING_POLICY_NAME,
    job_queue_name=JOB_QUEUE_NAME,
    service_environment_name=SERVICE_ENVIRONMENT_NAME,
    capacity_unit=INSTANCE_TYPE,
    max_capacity=3,
    quota_share_configs=[qs1, qs2, qs3]
)

Submetendo jobs de treinamento do SageMaker

O módulo aws_batch do SageMaker Python SDK foi estendido para permitir a submissão programática de jobs de treinamento do SageMaker para filas habilitadas com gerenciamento de cotas. O exemplo usa um ModelTrainer simples do tipo “Hello World”. Primeiro, identifica-se a URI da imagem com base na região e no tipo de instância:

import logging
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s - %(name)s - %(levelname)s - %(message)s"
)
logging.getLogger("botocore.client").setLevel(level=logging.WARN)
logger = logging.getLogger(__name__)

from sagemaker.core.helper.session_helper import Session
from sagemaker.core import image_uris

session = Session()
image_uri = image_uris.retrieve(
    framework="pytorch",
    region=session.boto_session.region_name,
    version="2.5",
    instance_type=INSTANCE_TYPE,
    image_scope="training",
)

Em seguida, configura-se o ModelTrainer:

from sagemaker.train.model_trainer import ModelTrainer
from sagemaker.train.configs import SourceCode, Compute, StoppingCondition

TRAINING_JOB_NAME = "hello-world-simple-job"
MAX_RUN_TIME = 300

source_code = SourceCode(command="echo 'Hello World'")
model_trainer = ModelTrainer(
    training_image=image_uri,
    source_code=source_code,
    base_job_name=TRAINING_JOB_NAME,
    compute=Compute(instance_type=INSTANCE_TYPE, instance_count=INSTANCE_COUNT),
    stopping_condition=StoppingCondition(max_runtime_in_seconds=MAX_RUN_TIME),
)

Para usar a fila dentro do SDK, basta fornecer o nome da fila ao construtor TrainingQueue:

from sagemaker.train.aws_batch.training_queue import TrainingQueue, TrainingQueuedJob

# Construct the queue object using the SageMaker Python SDK
queue = TrainingQueue(JOB_QUEUE_NAME)
logger.info(f"Using queue: {queue.queue_name}")

Submetendo jobs à QS1 com diferentes prioridades

O exemplo submete três jobs à QS1 com prioridades distintas. Como nenhum job está rodando em QS1 ou QS2 no momento, dois jobs começam imediatamente — o de maior prioridade usa a capacidade da própria QS1, e o segundo toma emprestado a capacidade ociosa da QS2:

from utils.aws_batch_resource_management import JobStatus, await_jobs, list_jobs_by_quota_share

# Submit three jobs to QS1, all with different priorities to guarantee dispatch ordering.
qs1_job_high: TrainingQueuedJob = queue.submit(job_name="qs1_job_high", training_job=model_trainer, quota_share_name=qs1.name, priority=3, inputs=None)
qs1_job_med: TrainingQueuedJob = queue.submit(job_name="qs1_job_med", training_job=model_trainer, quota_share_name=qs1.name, priority=2, inputs=None)
qs1_job_low: TrainingQueuedJob = queue.submit(job_name="qs1_job_low", training_job=model_trainer, quota_share_name=qs1.name, priority=1, inputs=None)

logger.info(f"Submitted jobs: {qs1_job_high.job_name}, {qs1_job_med.job_name}, {qs1_job_low.job_name}")
logger.info(f"Waiting for jobs to transition...")

# qs1_job_high is dispatched first using capacity from QS1, and qs1_job_med is dispatched second borrowing idle capacity from QS2
await_jobs([([qs1_job_high, qs1_job_med], JobStatus.dispatched() | JobStatus.terminal())])
list_jobs_by_quota_share(queue, [qs1.name, qs2.name, qs3.name], JobStatus.active())

Submissão à QS2 dispara preempção entre cotas

Quando a equipe dona da QS2 submete um novo job, o AWS Batch automaticamente recupera a capacidade que estava emprestada para a QS1 — sem nenhuma intervenção manual do administrador:

# When a job is submitted to QS2, it will preempt its capacity back from QS1
qs2_job_1: TrainingQueuedJob = queue.submit(job_name="qs2_job_1", training_job=model_trainer, quota_share_name=qs2.name, priority=1, inputs=None)
logger.info(f"Submitted job {qs2_job_1.job_name}")
logger.info(f"Waiting for jobs to transition...")

await_jobs([
    ([qs2_job_1], JobStatus.dispatched() | JobStatus.terminal()),
    ([qs1_job_med], {JobStatus.RUNNABLE}) # Lowest priority QS1 job will be preempted
])
list_jobs_by_quota_share(queue, [qs1.name, qs2.name, qs3.name], JobStatus.active())

Atualizando prioridades dispara preempção dentro da cota

Se um cientista percebe que o qs1_job_low precisa executar imediatamente por mudança de prioridades, ele pode usar a nova API UpdateServiceJob para aumentar a prioridade do job já submetido. Como não há capacidade disponível para tomar emprestado, o AWS Batch inicia uma preempção dentro da própria cota, interrompendo o job em execução para que o de maior prioridade comece:

# Updating qs1_job_low to be the highest priority job in QS1
qs1_job_low.update(scheduling_priority=4)
logger.info(f"Updated job {qs1_job_low.job_name} to increase its priority")
logger.info(f"Waiting for jobs to transition...")

await_jobs([
    ([qs1_job_low], JobStatus.dispatched() | JobStatus.terminal()),
    ([qs1_job_high], {JobStatus.RUNNABLE}) # High priority job will preempt lower priority jobs within the same quota share
])
list_jobs_by_quota_share(queue, [qs1.name, qs2.name, qs3.name], JobStatus.active())

Limpeza dos recursos criados

Para remover todos os recursos criados durante o exemplo, basta executar:

from utils.aws_batch_resource_management import delete_resources
delete_resources(resource_manager, resources)

Conclusão

O gerenciamento de cotas do AWS Batch representa um avanço importante para organizações que operam ambientes de treinamento de ML com múltiplas equipes. Em vez de depender de comunicação manual e ajustes constantes de configuração, administradores podem definir regras claras de alocação e deixar o próprio serviço gerenciar o compartilhamento e a recuperação de capacidade de forma automática.

A funcionalidade é especialmente poderosa quando combinada com os planos de treinamento do Amazon SageMaker AI, que permitem reservar capacidade na quantidade e no período necessários. Segundo a AWS, isso garante que toda a capacidade reservada seja efetivamente utilizada. Para mais detalhes técnicos, o guia de usuário do gerenciamento de cotas do AWS Batch traz a documentação completa sobre como configurar e operar essa funcionalidade.

Fonte

Lend and borrow resources across teams with AWS Batch’s quota management for SageMaker Training jobs (https://aws.amazon.com/blogs/machine-learning/lend-and-borrow-resources-across-teams-with-aws-batchs-quota-management-for-sagemaker-training-jobs/)

O problema que o Ray Train DLC resolve

Quem já tentou escalar um job de PyTorch para múltiplos nós sabe que o maior obstáculo raramente é o código do modelo. O verdadeiro trabalho está em montar — e manter alinhada — a pilha de dependências dentro do container: o runtime CUDA, o PyTorch compilado contra ele, o NCCL (Biblioteca de Comunicações Coletivas da NVIDIA), as bibliotecas de espaço de usuário do Adaptador de Fabric Elástico (EFA), o plugin AWS OFI NCCL que conecta o NCCL ao EFA, e ainda uma versão do Ray compatível com o operador do cluster. Qualquer desalinhamento entre essas peças não gera um erro claro: o NCCL simplesmente cai para sockets TCP e o job termina em fração da velocidade esperada.

O Ray Train Deep Learning Container (DLC) é a resposta da AWS para esse problema. A empresa monta essa pilha inteira, testa tudo como uma unidade, publica a imagem no Amazon Elastic Container Registry (Amazon ECR) Público e mantém os patches em dia. Nenhuma imagem precisa ser construída pela equipe que vai usá-la.

Como o cluster é organizado

O KubeRay é um operador Kubernetes de código aberto que adiciona o recurso RayCluster: você descreve um grupo de cabeça (head) e um grupo de trabalhadores (workers) em um único manifesto, e o KubeRay constrói e mantém o cluster a partir disso. O Ray opera um job em várias máquinas como um único cluster com dois papéis: o nó cabeça coordena o estado global e serve como ponto de submissão de jobs; os nós workers fornecem as GPUs e executam os processos de treinamento.

No exemplo publicado pela AWS, um único cluster no Amazon Elastic Kubernetes Service (Amazon EKS) é composto por: um nó de sistema m7i.xlarge que hospeda o operador KubeRay e o nó cabeça do Ray (sem GPUs), e dois nós g6.12xlarge com EFA habilitado, ambos na mesma Zona de Disponibilidade. Cada nó g6.12xlarge possui quatro GPUs NVIDIA L4, 48 vCPUs, 192 GiB de memória, 40 Gbps de rede e uma interface EFA. O Ray Train distribui oito workers — um por GPU — com os ranks 0 a 3 no primeiro nó e 4 a 7 no segundo.

Todos os nós ficam em sub-redes privadas de uma única Nuvem Privada Virtual (VPC) e acessam a internet apenas via NAT Gateway — é por ali que cada nó puxa a imagem DLC do Amazon ECR Público e os workers baixam os pesos do modelo do Hugging Face. Como o tráfego EFA não cruza Zonas de Disponibilidade, os scripts fixam ambas as instâncias na mesma zona.

O que vem pronto no DLC, sem precisar construir nada

A tag utilizada no exemplo — public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1 — entrega toda a pilha a seguir sem que a equipe precise montar ou manter nada:

• Runtime distribuído: Ray 2.58.0 com Train, Tune e Data
• Framework: PyTorch 2.13.0, torchvision 0.28.0
• Runtime de GPU: CUDA 13.0.2, cuDNN, NCCL 2.29.7
• Rede: instalador EFA, libfabric, plugin AWS OFI NCCL e GDRCopy — todos compilados contra o NCCL incluído
• Bibliotecas de treinamento: DeepSpeed, flash-attn, Transformer Engine, PyTorch Lightning, bibliotecas Hugging Face
• Diagnóstico: all_reduce_perf já disponível no path para testes de NCCL

Além disso, algumas propriedades eliminam trabalho recorrente por cluster:

• Sem configuração de registro: a imagem é pública, então os nós a puxam sem credenciais.
• Sem correspondência de driver: no startup, o entrypoint verifica o driver NVIDIA do host e ativa automaticamente as bibliotecas de compatibilidade forward do CUDA se o driver for mais antigo que o CUDA da imagem.
• Uma imagem para todos os papéis: a mesma tag serve tanto para o nó cabeça quanto para os workers — o que define o papel é o comando ray start passado na inicialização.
• Família de imagens compartilhada: o Ray Train compartilha o repositório ECR com o Ray Serve DLC e os Ray LLM DLCs, sob o prefixo de tag train-ml.

Configure, não reconstrua

Tudo o que muda de um job para outro é definido fora da imagem. O exemplo usa os seguintes mecanismos de configuração:

• Papel do pod (cabeça ou worker): via parâmetros rayStartParams do KubeRay. O cabeça roda com num-gpus: "0".
• GPUs e EFA por pod: via resource requests do Kubernetes (nvidia.com/gpu: 4, vpc.amazonaws.com/efa: 1).
• Transporte de rede: variáveis de ambiente no pod — FI_PROVIDER, NCCL_NET_PLUGIN, NCCL_SOCKET_IFNAME, NCCL_DEBUG.
• Pacotes Python extras: via runtime_env do Ray no momento da submissão, sem alterar a imagem.
• Versão da imagem: tag versionada ou fixada por digest em DLC_IMAGE.
• Forma do cluster: variáveis em scripts/env.sh — tipo de instância, contagem de nós, GPUs por nó, região e zona.

Um detalhe importante: solicitar vpc.amazonaws.com/efa: 1 no manifesto é o que faz o device plugin do EFA montar a interface dentro do container. Sem isso, o NCCL não enxerga o EFA e cai para sockets TCP.

O código de treinamento: uma função e um trainer

O arquivo code/train.py é o job inteiro e não contém nada específico ao container, ao cluster ou à rede. O Ray Train executa a função train_func uma vez por GPU. Ela consulta o Ray para obter seu rank, carrega o modelo e o passa para prepare_model para o FSDP (Paralelismo de Dados Totalmente Fragmentado), que divide pesos, gradientes e estado do otimizador entre todas as oito GPUs:

def train_func(config):
    ctx = ray.train.get_context()
    world_size, rank = ctx.get_world_size(), ctx.get_world_rank()
    device = ray.train.torch.get_device()
    model = AutoModelForCausalLM.from_pretrained(config["model_id"], torch_dtype=torch.bfloat16)
    # Any submodule above 10M parameters becomes its own FSDP unit. Wrapping by
    # size, not by a model-specific layer class, keeps the script model-agnostic.
    auto_wrap_policy = partial(size_based_auto_wrap_policy, min_num_params=int(1e7))
    model = ray.train.torch.prepare_model(
        model,
        parallel_strategy="fsdp",
        parallel_strategy_kwargs={"auto_wrap_policy": auto_wrap_policy},
    )
    optimizer = torch.optim.AdamW(model.parameters(), lr=config["learning_rate"])
    for step in range(config["steps"]):
        input_ids = torch.randint(0, model.config.vocab_size, (config["batch_size"], config["seq_len"]), device=device)
        optimizer.zero_grad()
        loss = model(input_ids=input_ids, labels=input_ids).loss
        loss.backward()
        # parameters gathered again, gradients reduce-scattered
        optimizer.step()
        # local: each rank updates only its own slice
        ray.train.report({"step": step, "loss": loss.item()})

O driver se conecta ao cluster em execução, conta as GPUs disponíveis e inicia o trainer. Como a contagem de workers vem do cluster, o mesmo script funciona sem alteração em um ou vários nós:

ray.init(address="auto")  # join the RayCluster
num_workers = int(ray.cluster_resources().get("GPU", 0))  # 8 here
trainer = TorchTrainer(
    train_func,
    train_loop_config={...},
    scaling_config=ScalingConfig(num_workers=num_workers, use_gpu=True),
    run_config=RunConfig(name="ray-train-fsdp-llm"),
)
result = trainer.fit()

O Qwen2.5-1.5B em bfloat16 precisa de cerca de 12 GB para pesos, gradientes e estado do otimizador. Fragmentado entre oito GPUs, cada L4 segura aproximadamente 1,5 GB. O custo é comunicação: o FSDP reúne os pesos de cada camada antes de usá-la e dispersa os gradientes depois — e é exatamente esse tráfego entre instâncias que a pilha EFA do DLC transporta.

O manifesto: onde a imagem encontra o cluster

O arquivo manifest/raycluster.yaml é curto justamente porque a imagem precisa de pouca configuração. O grupo de workers concentra as decisões principais:

workerGroupSpecs:
  - groupName: gpu-workers
    replicas: 2
    rayStartParams:
      num-gpus: "${GPUS_PER_NODE}"  # keeps Ray's GPU count equal to the pod's
    template:
      spec:
        nodeSelector: { role: gpu-worker }
        containers:
          - name: ray-worker
            image: "${DLC_IMAGE}"  # the DLC as published; same tag as the head
            env:
              - { name: NCCL_DEBUG,        value: "INFO"  }  # print the chosen transport
              - { name: NCCL_SOCKET_IFNAME, value: "eth0" }  # pod network on EKS
              - { name: FI_PROVIDER,        value: "efa"  }  # libfabric: EFA, nothing else
              - { name: NCCL_NET_PLUGIN,    value: "ofi"  }  # load the AWS OFI plugin
            resources:
              limits:   { nvidia.com/gpu: "${GPUS_PER_NODE}", vpc.amazonaws.com/efa: "1", cpu: "40", memory: 160Gi }
              requests: { nvidia.com/gpu: "${GPUS_PER_NODE}", vpc.amazonaws.com/efa: "1", cpu: "40", memory: 160Gi }

Três decisões estão explícitas aqui: qual imagem usar (${DLC_IMAGE}, sem modificação, para cabeça e workers); qual hardware alocar (quatro GPUs e uma interface EFA por pod); e qual transporte usar (quatro variáveis de ambiente, sem depender de auto-detecção). Dois detalhes de estabilidade: requests iguais a limits colocam os workers na classe de Qualidade de Serviço Garantida (QoS) do Kubernetes — um rank throttled ou despejado paralisa os outros sete. E num-gpus deriva da mesma variável que o request de GPU, então a visão do Ray sobre capacidade sempre bate com a do Kubernetes.

Subindo a infraestrutura e rodando o job

Toda a configuração fica em scripts/env.sh: nome do cluster, região, versão do Kubernetes, tipos e contagens de nós, a imagem, versões fixadas do KubeRay e dos device plugins, e os parâmetros de treinamento.

O script deploy_all.sh é o ponto de entrada. Ele começa executando find_gpu_capacity.sh, que verifica por região candidata: se o g6.12xlarge está disponível em cada Zona de Disponibilidade, se a cota de vCPUs On-Demand da família G/VT tem espaço para a contagem de nós solicitada, e o score de placement de Spot como sinal de capacidade. Com a flag --probe, ele obtém uma resposta definitiva criando e cancelando imediatamente uma Reserva de Capacidade real em cada zona candidata.

Em seguida, os quatro passos são executados em ordem: deploy_cluster.sh (plano de controle EKS, VPC, provedor OIDC, add-ons e node group de sistema), deploy_node_group.sh (dois g6.12xlarge com EFA, rotulados role=gpu-worker), install_gpu_plugins.sh (device plugins NVIDIA e EFA) e install_kuberay.sh (operador KubeRay no nó de sistema). O conjunto leva de 20 a 30 minutos em uma região nova.

O job de treinamento é um passo separado, executado por deploy_ray_train_job.sh. Ele renderiza o manifesto com envsubst, aplica, verifica os recursos alocáveis de cada nó GPU, aguarda os pods ficarem prontos e então submete o job de dentro do pod cabeça via kubectl exec:

ray job submit --address http://localhost:8265 --working-dir /tmp/ray-train-code \
    python3 train.py --model_id Qwen/Qwen2.5-1.5B

A chamada de submit transmite os logs de todos os oito ranks e retorna quando o job termina. O script verifica qual transporte o NCCL usou e sai com erro se o job falhou ou se o EFA não estava no caminho — o que o torna utilizável como gate de Integração Contínua (CI).

Adaptando para outros workloads

Como a imagem é usada como publicada e o job aprende sua escala do cluster, a maioria das mudanças toca exatamente um arquivo:

• Trocar o modelo: altere apenas MODEL_ID. Código, manifesto e imagem ficam intactos.
• Ajustar steps, sequence length ou batch size: altere STEPS, SEQ_LEN, BATCH_SIZE. Código, manifesto e imagem ficam intactos.
• Adicionar pacote Python: use --runtime-env-json com lista pip. A imagem não muda.
• Fixar versão do DLC: aponte DLC_IMAGE para uma tag versionada. Todo o resto permanece.
• Trocar família de instâncias GPU: altere GPU_NODE_TYPE e GPUS_PER_NODE. A família precisa ter suporte a EFA. Migrar para p5 ou outra família com GPUDirect não exige mudança na imagem ou no código de treinamento.
• Escalar o número de instâncias: altere GPU_NODE_COUNT mais replicas, minReplicas e maxReplicas no manifesto. O código conta as GPUs automaticamente.

O repositório de exemplo contém toda a solução e usa a mesma base KubeRay no EKS do walkthrough multi-nó do Ray Serve.

Derrubando o ambiente

As instâncias GPU custam em torno de US$ 9,50 por hora junto com o plano de controle e o NAT Gateway. A remoção segue a ordem inversa da criação:

./delete_ray_train_job.sh        # RayCluster
./install_kuberay.sh cleanup     # KubeRay operator
./install_gpu_plugins.sh cleanup # NVIDIA and EFA device plugins
./delete_node_group.sh           # GPU instances
./delete_cluster.sh              # EKS cluster, VPC and system node

Próximos passos sugeridos

A AWS sugere como evoluções naturais a partir desse exemplo:

• Substituir os batches aleatórios por um dataset real e fazer checkpoint no Amazon S3 ou Amazon FSx for Lustre.
• Fixar DLC_IMAGE em uma tag versionada para runs reproduzíveis.
• Ativar FailureConfig para que runs longas sobrevivam à perda de uma instância.
• Migrar para um modelo maior em uma família com GPUDirect RDMA, como p5. A imagem e o código permanecem os mesmos.

Fonte

Distributed training with Ray Train DLCs and EFA on EKS (https://aws.amazon.com/blogs/machine-learning/distributed-training-with-ray-train-dlcs-and-efa-on-eks/)

O problema que aparece quando a automação de QA cresce

Quando a automação de Garantia de Qualidade (QA) começa a se expandir dentro de uma organização, um novo desafio surge — e ele não tem nada a ver com escrever testes. Um time de plataforma sobe a infraestrutura de automação, um segundo time quer aderir, depois mais uma dúzia. Em pouco tempo, centenas de casos de teste pertencem a produtos e squads diferentes, todos visíveis para todos. E ninguém consegue responder, de relance, a uma pergunta simples: a cobertura de testes desta aplicação está saudável agora?

Escrever testes deixa de ser o gargalo. Organizar testes e controlar quem pode alterá-los passa a ser o trabalho real. Uma segunda questão surge logo na sequência: quem é o dono desta aplicação e seus testes, e quem responde quando a cobertura cai? Sem um responsável claro, os problemas de saúde não têm para onde ir.

A AWS publicou a terceira parte da série sobre o QA Studio, solução de referência construída com o Amazon Nova Act. Na primeira parte, o QA Studio foi apresentado como uma ferramenta que permite definir testes em linguagem natural e executá-los por meio de navegação visual com IA. Na segunda parte, foram adicionados suítes de testes e uma Interface de Linha de Comando (CLI) para regressão em lote em pipelines de Integração Contínua e Entrega Contínua (CI/CD). Nesta terceira parte, o foco está em duas capacidades que ajudam o QA Studio a escalar por toda uma organização: aplicações e gerenciamento de usuários por times.

Organizando testes com Aplicações

No QA Studio, uma aplicação representa o sistema em teste: um site, um aplicativo web, um front-end de serviço. É o contêiner que dá um lar e um dono a uma coleção de testes. Os casos de uso (testes individuais da Parte 1) e as suítes de testes (coleções de regressão da Parte 2) pertencem a uma aplicação e herdam sua propriedade.

Em vez de uma lista plana com todos os testes do ambiente, cada time trabalha dentro das aplicações que possui. Criar uma aplicação exige um nome, uma URL base e um conjunto opcional de ambientes — como desenvolvimento, homologação e produção. A partir da página da aplicação, os times criam novos casos de uso diretamente no contexto, adicionam casos existentes e os agrupam em suítes de testes.

Entendendo a saúde das aplicações com métricas

Testes produzem resultados. Entender esses resultados ao longo do tempo é o que diz a um time se o ciclo de desenvolvimento de uma aplicação está saudável — e não apenas se um build específico está pronto para ir a produção.

O QA Studio registra o resultado de cada execução como métricas customizadas no Amazon CloudWatch, dimensionadas por aplicação e por ambiente. Essas métricas alimentam uma visão de saúde na página da aplicação. O topo da página responde à pergunta imediata com três números: a taxa de aprovação no período selecionado, o total de execuções e a contagem atual de falhas.

Junto a esses números, o QA Studio calcula um health score (pontuação de saúde) de 0 a 100. A pontuação parte da taxa de aprovação e desconta uma penalidade por testes instáveis — aqueles que alternam entre aprovado e reprovado de forma intermitente. Assim, uma aplicação cujos testes passam mas oscilam não apresenta uma imagem falsamente perfeita. Um time que analisa um portfólio de aplicações consegue identificar as estáveis e as que precisam de atenção sem precisar abrir cada resultado individualmente.

A aba de métricas vai além do snapshot atual e mostra tendências. Os times escolhem uma janela de 7 dias com granularidade horária ou uma janela de 30 dias com granularidade diária. O QA Studio exibe gráficos de execuções, sucessos, falhas e duração média nesse período. Como as métricas carregam a dimensão de ambiente, é possível filtrar a visão para um único ambiente — por exemplo, comparar o comportamento da homologação com o de produção para o mesmo conjunto de testes.

Duas visões específicas miram nos testes que mais custam tempo aos times:

• Testes instáveis (flaky tests): classifica os casos de uso pela frequência com que alternaram entre aprovado e reprovado nos últimos sete dias, revelando falhas intermitentes que corroem a confiança na suíte antes de virar um problema em produção.
• Falhas recentes: lista as últimas execuções com falha para triagem rápida. Cada item leva diretamente aos logs de trajetória do Amazon Nova Act e às gravações de sessão descritos na Parte 1 — ou seja, sair de “este teste está falhando” para “aqui está exatamente o que o agente viu” é questão de um clique.

Controlando o acesso com times e papéis

Métricas dizem a um time como suas aplicações estão indo. O gerenciamento de usuários por times decide quais aplicações são deles para começo de conversa.

O QA Studio organiza o acesso em torno de times, e uma aplicação pertence a exatamente um time. Os membros daquele time trabalham com suas aplicações; todos os outros não as enxergam. Cada membro do time ocupa um dos cinco papéis, e cada papel inclui as permissões dos papéis abaixo dele na hierarquia:

• Admin: acesso amplo a todos os times, aplicações e usuários do estúdio, incluindo criação de times e atribuição de aplicações. É um papel de nível de estúdio, não por time.
• Team Lead (Líder de Time): gerencia os membros do próprio time e cria aplicações para o time.
• Editor: cria e edita casos de uso e suítes de testes dentro das aplicações do time.
• Executor: executa casos de uso e suítes, mas não os modifica.
• Viewer (Visualizador): acesso somente leitura às aplicações e resultados do time.

Como os papéis são cumulativos, um Team Lead tem tudo que um Editor tem, e assim por diante até o Viewer. O acesso a um caso de uso ou suíte de testes segue a aplicação que o contém — se um membro pode trabalhar com a aplicação, pode trabalhar com seus testes, dentro dos limites do seu papel. Isso mantém o gerenciamento de permissões no nível da aplicação, e não em milhares de testes individuais.

Um administrador enxerga o estúdio inteiro. A página de usuários lista todas as contas com seus times e papéis em um só lugar. A página de times apresenta os mesmos dados agrupados por time, mostrando a contagem de membros e aplicações lado a lado — o que permite identificar quais times estão crescendo antes mesmo de abrir qualquer um deles.

Compartilhando aplicações entre times

Times raramente trabalham em isolamento completo. Um time de plataforma pode ser dono de uma aplicação que um time de funcionalidade precisa executar testes — sem precisar transferir a capacidade de modificá-la.

O QA Studio suporta isso com acesso compartilhado: o time proprietário concede a outro time acesso a uma aplicação em nível de visualização, execução ou acesso completo. O acesso compartilhado segue uma regra de teto: a permissão efetiva de um usuário em uma aplicação compartilhada é o menor valor entre o seu próprio papel e o nível do compartilhamento concedido. Um Viewer que recebe acesso completo a uma aplicação compartilhada permanece somente leitura, porque o seu papel é o teto. Assim, um time proprietário pode compartilhar amplamente sem conceder mais do que o papel do destinatário permite.

O que um Team Lead visualiza

Um Team Lead trabalha dentro de um único time, não do estúdio inteiro. A visão “Meu Time” apresenta quatro abas que cobrem tudo que o líder controla: Membros, Aplicações, Casos de Uso e Acesso Compartilhado.

A aba de Membros lista as pessoas do time. O líder pode alterar o papel de qualquer membro diretamente ou adicionar novos, mantendo o gerenciamento de acesso do dia a dia com quem está mais próximo do trabalho.

A aba de Aplicações mostra apenas as aplicações que o time possui, cada uma com a contagem de casos de teste e o horário da última execução — mantendo o líder focado na sua própria superfície, não no inventário completo do estúdio.

A aba de Acesso Compartilhado é onde o compartilhamento entre times se concretiza. É possível conceder, revogar ou alterar o nível de acesso que outros times têm sobre as aplicações do time. A regra de teto descrita anteriormente se aplica na prática: um Editor do time convidado que recebeu acesso no nível de visualização ainda vê a aplicação compartilhada como somente leitura.

Como funciona por baixo dos panos

O QA Studio constrói o controle de acesso por times e as métricas sobre a mesma base serverless descrita nas partes anteriores, adicionando alguns serviços AWS ao mix:

• Amazon Cognito: cada time é mapeado para um conjunto de grupos do Cognito, um por papel. Um autorizador do AWS Lambda resolve os grupos de um chamador em escopos de API e contexto de time a cada requisição.
• Amazon DynamoDB: times, membros, propriedade de aplicações e concessões de compartilhamento entre times são armazenados no design de tabela única já existente.
• Amazon CloudWatch: cada execução emite métricas customizadas no namespace QAStudio/Executions, dimensionadas por aplicação e ambiente. A API de métricas as lê para construir a visão de saúde e os gráficos de tendência.
• AWS Lambda e Amazon API Gateway: o backend aplica o controle de acesso em duas camadas — o escopo que o papel do chamador concede e uma verificação de recurso que confirma se o time do chamador é dono ou tem compartilhamento com a aplicação.

Como o acesso é derivado da associação a grupos do Cognito, o fluxo de credenciais de cliente OAuth da Parte 2 se encaixa no mesmo modelo. Um pipeline de CI/CD se autentica como uma identidade de máquina com os escopos que precisa — e nada além disso.

Como começar

Aplicações, métricas e controle de acesso por times fazem parte da solução de referência do QA Studio, que é implantada na própria conta AWS do usuário com o AWS Kit de Desenvolvimento em Nuvem (AWS CDK). Todos os dados de teste, resultados e métricas permanecem dentro dos limites da conta.

Após a implantação, um administrador cria times, atribui membros e papéis, e associa aplicações aos times. As métricas de saúde de cada time começam a ser preenchidas conforme os testes são executados. Para instruções de implantação e detalhes de configuração, consulte o repositório GitHub do QA Studio.

Conclusão

Esta terceira parte da série mostra como o QA Studio escala a automação de QA com agentes de IA — de testes individuais para uma organização inteira. As aplicações dão a cada time um lar para seus casos de uso e suítes de testes. Elas reportam saúde por meio de taxa de aprovação, gráficos de tendência, pontuação de saúde ajustada por instabilidade e triagem de falhas construída sobre métricas do Amazon CloudWatch. O gerenciamento de usuários por times, sustentado pelo Amazon Cognito, mantém cada equipe trabalhando dentro das aplicações que possui, com compartilhamento entre times limitado por uma regra de teto clara.

Essas capacidades se somam à autoria de testes em linguagem natural da Parte 1 e às suítes e integração com CI/CD da Parte 2. Juntas, elas permitem que a automação de QA cresça por muitos times sem perder visibilidade nem controle. Para experimentar no seu próprio ambiente, implante a solução de referência a partir do repositório GitHub do QA Studio e execute alguns casos de uso para ver as métricas tomando forma. Para saber mais sobre o agente por trás de tudo isso, acesse a página do Amazon Nova Act.

Fonte

Accelerating software delivery with agentic QA automation using Amazon Nova Act – Part 3 (https://aws.amazon.com/blogs/machine-learning/accelerating-software-delivery-with-agentic-qa-automation-using-amazon-nova-act-part-3/)