Author: Make.com Service User

  • Implementar pontos de inferência do SageMaker com capacidade de GPU reservada usando planos de treinamento

    Garantindo capacidade de GPU previsível para inferência

    Implementar grandes modelos de linguagem (LLMs) para inferência exige capacidade confiável de processamento em GPU, especialmente durante períodos críticos de avaliação, testes limitados de produção ou picos de demanda. Quando a disponibilidade de recursos sob demanda é incerta — principalmente em horários de pico — essa imprevisibilidade pode comprometer cronogramas de implantação e impactar o desempenho das aplicações.

    A solução apresentada pela Amazon SageMaker permite que clientes utilizem planos de treinamento para reservar capacidade de computação em períodos específicos. Inicialmente projetados para cargas de treinamento, esses planos agora suportam endpoints de inferência, oferecendo disponibilidade previsível de GPU para workloads vinculados ao tempo.

    O cenário prático de avaliação de modelos

    Imagine uma equipe de ciência de dados que precisa avaliar diversos modelos de linguagem ajustados em um período de duas semanas antes de selecionar um para produção. A equipe necessita de acesso ininterrupto a instâncias ml.p5.48xlarge para executar benchmarks comparativos, mas a capacidade sob demanda em sua região AWS é imprevisível durante horas de pico. Ao reservar capacidade através dos planos de treinamento, a equipe consegue executar suas avaliações ininterruptamente com custos controlados e disponibilidade garantida.

    O Amazon SageMaker oferece um mecanismo flexível para garantir essa capacidade. Você busca ofertas disponíveis, seleciona o tipo de instância, quantidade e duração que correspondem às suas necessidades, e cria uma reserva — seja por um número fixo de dias ou meses, ou por uma quantidade específica de dias consecutivos.

    Como funciona: fluxo geral da solução

    Os planos de treinamento do SageMaker funcionam em quatro fases principais:

    • Identificar requisitos de capacidade: Determine o tipo de instância, quantidade de instâncias e duração necessária para sua carga de inferência
    • Buscar ofertas disponíveis: Consulte a capacidade disponível que atende aos seus requisitos e janela de tempo desejada
    • Criar a reserva: Selecione uma oferta adequada e crie a reserva, que gera um identificador de recurso (ARN)
    • Implantar e gerenciar: Configure seu endpoint do SageMaker para usar a capacidade reservada e gerencie seu ciclo de vida durante o período de reserva

    Preparação inicial: pré-requisitos

    Antes de começar, você precisará de:

    Etapa 1: Buscar ofertas de capacidade disponível

    O primeiro passo é identificar capacidade disponível de GPU da família p que corresponda aos seus requisitos. No exemplo da equipe, eles precisam de uma instância ml.p5.48xlarge por uma semana, começando no final de janeiro. Utilizando a API de busca de ofertas de planos de treinamento, especificam o tipo de instância, quantidade, duração em horas, e a janela de tempo desejada:

    aws sagemaker search-training-plan-offerings \
      --target-resources "endpoint" \
      --instance-type "ml.p5.48xlarge" \
      --instance-count 1 \
      --duration-hours 168 \
      --start-time-after "2025-01-27T15:48:14-04:00" \
      --end-time-before "2025-01-31T14:48:14-05:00"

    A resposta fornece informações detalhadas sobre cada bloco de capacidade disponível — tipo de instância, quantidade, duração, zona de disponibilidade e preço. Cada oferta inclui horários específicos de início e fim, permitindo selecionar uma reserva que se alinhe ao cronograma de implantação:

    {
      "TrainingPlanOfferings": [
        {
          "TrainingPlanOfferingId": "tpo-SHA-256-hash-value",
          "TargetResources": ["endpoint"],
          "RequestedStartTimeAfter": "2025-01-21T12:48:14.704000-08:00",
          "DurationHours": 168,
          "DurationMinutes": 10080,
          "UpfrontFee": "xxxx.xx",
          "CurrencyCode": "USD",
          "ReservedCapacityOfferings": [
            {
              "InstanceType": "ml.p5.48xlarge",
              "InstanceCount": 1,
              "AvailabilityZone": "us-west-2a",
              "DurationHours": 168,
              "DurationMinutes": 10080,
              "StartTime": "2025-01-27T15:48:14-04:00",
              "EndTime": "2025-01-31T14:48:14-05:00"
            }
          ]
        }
      ]
    }

    Após identificar uma oferta adequada que se encaixa no cronograma, cria-se a reserva do plano de treinamento para garantir a capacidade:

    aws sagemaker create-training-plan \
      --training-plan-offering-id "tpo-SHA-256-hash-value" \
      --training-plan-name "p4-for-inference-endpoint"

    A resposta contém o ARN do plano de treinamento, que identificará unicamente a capacidade reservada:

    {
      "TrainingPlanArn": "arn:aws:sagemaker:us-east-1:123456789123:training-plan/p4-for-inference-endpoint"
    }

    Criando planos de treinamento via console

    É possível criar planos de treinamento diretamente pelo console do SageMaker, que oferece uma interface visual para buscar capacidade e completar a reserva. O fluxo do console segue três etapas: buscar ofertas, adicionar detalhes do plano e revisar e comprar.

    Imagem original — fonte: Aws

    No console, você navega até Modelo training & customization no painel de navegação, seleciona Training plans e clica em Create training plan. Na busca, seleciona Inference Endpoint como alvo, escolhe o tipo de instância desejado (ex: ml.p5.48xlarge), especifica a quantidade e a duração, e clica em Find training plan para visualizar ofertas disponíveis.

    Após selecionar um plano, o console conduz através das etapas finais de confirmação de detalhes e revisão de termos. Após a compra, você recebe o ARN do plano de treinamento, que será essencial para configurar o endpoint de inferência.

    Etapa 2: Criar configuração de endpoint com a reserva

    Com a reserva garantida, a próxima etapa é criar uma configuração de endpoint que vincule seu endpoint de inferência à capacidade reservada. O passo crítico aqui é incluir o objeto CapacityReservationConfig na seção ProductionVariants, onde você define MlReservationArn como o ARN do plano de treinamento obtido anteriormente:

    aws sagemaker create-endpoint-config \
      --endpoint-config-name "ftp-ep-config" \
      --production-variants '[{
        "VariantName": "AllTraffic",
        "ModelName": "my-model",
        "InitialInstanceCount": 1,
        "InstanceType": "ml.p5.48xlarge",
        "InitialVariantWeight": 1.0,
        "CapacityReservationConfig": {
          "CapacityReservationPreference": "capacity-reservations-only",
          "MlReservationArn": "arn:aws:sagemaker:us-east-1:123456789123:training-plan/p4-for-inference-endpoint"
        }
      }]'

    Quando o SageMaker recebe essa solicitação, valida se o ARN aponta para uma reserva de plano de treinamento ativa com tipo de recurso de alvo “endpoint”. Se a validação tiver sucesso, a configuração do endpoint é criada e fica elegível para implantação.

    A configuração CapacityReservationPreference é particularmente importante: ao defini-la como capacity-reservations-only, você restringe o endpoint apenas à sua capacidade reservada. Quando a reserva expira, o endpoint para de servir tráfego automaticamente, evitando cobranças inesperadas.

    Etapa 3: Implantar o endpoint na capacidade reservada

    Com a configuração de endpoint pronta, procede-se à implantação:

    aws sagemaker create-endpoint \
      --endpoint-name "my-endpoint" \
      --endpoint-config-name "ftp-ep-config"

    O endpoint agora executa integralmente dentro da capacidade do plano de treinamento reservado. O SageMaker provisiona a instância ml.p5.48xlarge na zona de disponibilidade especificada e carrega o modelo — esse processo pode levar vários minutos. Quando o endpoint atinge o status InService, você está pronto para iniciar sua carga de trabalho de avaliação.

    Etapa 4: Invocar o endpoint durante período ativo

    Com o endpoint em serviço, você pode executar sua carga de trabalho de avaliação. Invocações do endpoint para inferência em tempo real permitem enviar prompts de teste e medir qualidade de resposta, latência e vazão:

    aws sagemaker-runtime invoke-endpoint \
      --endpoint-name "my-endpoint" \
      --body fileb://input.json \
      --content-type "application/json" \
      output.json

    Durante a janela de reserva ativa, o endpoint opera normalmente com capacidade garantida. Todas as invocações são processadas usando os recursos reservados, facilitando desempenho e disponibilidade previsíveis, sem preocupações com restrições de capacidade ou variabilidade de performance.

    Etapa 5: Comportamento quando a reserva expira

    É importante entender o que acontece quando o plano de treinamento expira enquanto o endpoint ainda está implantado. O comportamento do endpoint depende da configuração CapacityReservationPreference. Como foi definida como capacity-reservations-only, o endpoint para de servir tráfego e invocações falham com erro de capacidade:

    {
      "Error": {
        "Code": "ModelError",
        "Message": "Endpoint capacity reservation has expired. Please update endpoint configuration."
      }
    }

    Para retomar o serviço, você deve criar uma nova reserva de plano de treinamento e atualizar a configuração do endpoint, ou atualizar o endpoint para usar capacidade sob demanda. Se a avaliação foi concluída, a equipe pode simplesmente excluir o endpoint em vez de estender a reserva.

    Etapa 6: Atualizar endpoint durante o período de avaliação

    Durante o período de avaliação, você pode precisar atualizar o endpoint por diversas razões. O SageMaker suporta vários cenários de atualização enquanto mantém a conexão com a capacidade reservada.

    Atualizar para nova versão de modelo

    Se no meio da avaliação você deseja testar uma versão de modelo melhorada com ajuste fino adicional, você pode atualizar para a nova versão mantendo a mesma capacidade reservada:

    aws sagemaker create-endpoint-config \
      --endpoint-config-name "ftp-ep-config-v2" \
      --production-variants '[{
        "VariantName": "AllTraffic",
        "ModelName": "my-model-v2",
        "InitialInstanceCount": 1,
        "InstanceType": "ml.p5.48xlarge",
        "InitialVariantWeight": 1.0,
        "CapacityReservationConfig": {
          "CapacityReservationPreference": "capacity-reservations-only",
          "MlReservationArn": "arn:aws:sagemaker:us-east-1:123456789123:training-plan/p4-for-inference-endpoint"
        }
      }]'
    
    aws sagemaker update-endpoint \
      --endpoint-name "my-endpoint" \
      --endpoint-config-name "ftp-ep-config-v2"

    Migrar de reserva para capacidade sob demanda

    Se a avaliação se estender além do esperado ou se você deseja levar o endpoint para produção depois que a reserva expirar, você pode migrar para capacidade sob demanda:

    aws sagemaker create-endpoint-config \
      --endpoint-config-name "ondemand-ep-config" \
      --production-variants '[{
        "VariantName": "AllTraffic",
        "ModelName": "my-model",
        "InitialInstanceCount": 1,
        "InstanceType": "ml.p5.48xlarge",
        "InitialVariantWeight": 1.0
      }]'
    
    aws sagemaker update-endpoint \
      --endpoint-name "my-endpoint" \
      --endpoint-config-name "ondemand-ep-config"

    Etapa 7: Escalar o endpoint dentro dos limites de reserva

    Em alguns cenários, você pode reservar mais capacidade do que implanta inicialmente, oferecendo flexibilidade para escalar quando necessário. Por exemplo, se a equipe reservou duas instâncias mas implantou apenas uma, ela pode escalar durante a avaliação para testar cenários de maior vazão:

    aws sagemaker create-endpoint-config \
      --endpoint-config-name "ftp-ep-config-scaled" \
      --production-variants '[{
        "VariantName": "AllTraffic",
        "ModelName": "my-model",
        "InitialInstanceCount": 2,
        "InstanceType": "ml.p5.48xlarge",
        "InitialVariantWeight": 1.0,
        "CapacityReservationConfig": {
          "CapacityReservationPreference": "capacity-reservations-only",
          "MlReservationArn": "arn:aws:sagemaker:us-east-1:123456789123:training-plan/p4-for-inference-endpoint"
        }
      }]'
    
    aws sagemaker update-endpoint \
      --endpoint-name "my-endpoint" \
      --endpoint-config-name "ftp-ep-config-scaled"

    Contudo, se você tentar escalar além da capacidade reservada, a atualização falhará:

    {
      "Error": {
        "Code": "ValidationException",
        "Message": "Requested instance count (3) exceeds reserved capacity (2) for training plan."
      }
    }

    Etapa 8: Excluir o endpoint e encerrar

    Após completar a avaliação de uma semana e reunir todas as métricas de desempenho necessárias, a equipe está pronta para limpar a infraestrutura. A reserva do plano de treinamento expira automaticamente no final da janela especificada. Um detalhe importante: você é cobrado pelo período completo de reserva, independente de quando exclui o endpoint.

    Excluir um endpoint não cancela ou reembolsa a reserva do plano de treinamento — a capacidade reservada permanece alocada até que a janela de reserva expire. Porém, se a reserva ainda está ativa e capacidade está disponível, você pode criar um novo endpoint usando o mesmo ARN de plano de treinamento.

    Para fazer limpeza completa, você pode excluir a configuração do endpoint:

    aws sagemaker delete-endpoint-config \
      --endpoint-config-name "ftp-ep-config"

    Ao configurar sua reserva de plano de treinamento, lembre-se de que você está se comprometendo com uma janela de tempo fixa e será cobrado pelo período integral antecipadamente, independentemente do tempo real de uso. Verifique que seu cronograma estimado se alinhe com a duração da reserva escolhida. Se você concluir o trabalho antes do previsto, o custo não se altera — se adquirir uma reserva de 7 dias, pagará pelos sete dias mesmo que termine em cinco.

    Considerações práticas e boas práticas

    A estrutura de custo previsível e antecipado oferecida pelos planos de treinamento oferece vantagens significativas para orçamento e planejamento de projetos. Você sabe exatamente quanto gastará antes de começar.

    Lembre-se que ao deletar seu endpoint, a reserva do plano de treinamento não é cancelada ou reembolsada. A capacidade reservada permanece alocada até a expiração da janela de reserva. Se você terminar antes e deseja usar o tempo remanescente, pode reimplantar um novo endpoint usando o mesmo ARN de plano de treinamento, desde que a reserva ainda esteja ativa e capacidade disponível.

    Conclusão

    Os planos de treinamento do SageMaker oferecem um caminho direto para reservar capacidade de GPU da família p e implantar endpoints de inferência com disponibilidade garantida. Essa abordagem é recomendada para workloads vinculados ao tempo — como avaliação de modelos, testes limitados de produção e cenários de picos de demanda previsíveis — onde capacidade previsível é essencial.

    Como vimos na jornada da equipe de ciência de dados, o processo envolve identificar requisitos de capacidade, buscar ofertas disponíveis, criar uma reserva e referenciar essa reserva na configuração do endpoint para implantar durante a janela de reserva. A equipe completou sua avaliação de modelo com capacidade garantida, evitando a imprevisibilidade de disponibilidade sob demanda durante horas de pico.

    Com suporte para atualizações de endpoint, escalabilidade dentro dos limites de reserva e migração perfeita para capacidade sob demanda, os planos de treinamento oferecem flexibilidade para gerenciar workloads de inferência enquanto mantêm controle sobre disponibilidade de GPU e custos. Quer você execute benchmarks competitivos de modelos, execute testes A/B limitados no tempo ou lide com picos de tráfego previsíveis, os planos de treinamento para endpoints de inferência fornecem a capacidade necessária com preço transparente e antecipado.

    Fonte

    Deploy SageMaker AI inference endpoints with set GPU capacity using training plans (https://aws.amazon.com/blogs/machine-learning/deploy-sagemaker-ai-inference-endpoints-with-set-gpu-capacity-using-training-plans/)

  • Integrando Amazon Bedrock AgentCore com Slack: Agentes de IA Diretamente no Seu Workspace

    Levando Agentes de IA para o Slack

    A integração entre Amazon Bedrock AgentCore e Slack oferece um novo paradigma para empresas que desejam colocar assistentes de IA inteligentes diretamente nos espaços de colaboração onde os times trabalham. Em vez de alternar entre aplicações, perder histórico de conversas ou lidar com reauthenticação constante, os usuários podem interagir com agentes de IA nativamente dentro do Slack.

    A arquitetura dessa integração resolve três desafios técnicos fundamentais: validar requisições de eventos do Slack para garantir segurança, manter contexto de conversa através de threads, e gerenciar respostas que excedem os limites de timeout da plataforma. Desenvolvedores costumam investir tempo construindo manipuladores de webhook personalizados para integrações com Slack. O AgentCore reduz esse trabalho oferecendo memória de conversa integrada, acesso seguro a agentes e suas ferramentas, além de gerenciamento de identidade que rastreia o uso dos agentes, tudo dentro do próprio Slack.

    Visão Geral da Solução

    A solução é composta por dois componentes principais: a infraestrutura de integração com Slack e o Amazon AgentCore Runtime com suas ferramentas. A infraestrutura de integração roteia e gerencia a comunicação entre Slack e o agente, enquanto o runtime processa e responde às consultas.

    Para a integração, a AWS utiliza Amazon API Gateway, AWS Lambda, AWS Secrets Manager e Amazon Simple Queue Service (Amazon SQS) em uma arquitetura serverless. O agente foi containerizado e hospedado para rodar em AgentCore Runtime, construído com o Strands Agents SDK que se integra com Amazon Bedrock AgentCore Gateway para acesso a ferramentas e AgentCore Memory para histórico de conversas.

    O runtime mantém contexto ao longo das conversas e utiliza o Model Context Protocol (MCP), um protocolo padronizado para execução de ferramentas e comunicação, para invocar as ferramentas necessárias.

    Arquitetura da Solução

    A arquitetura se divide em três seções principais:

    Seção A – Infraestrutura de Construção de Imagem: O WeatherAgentImageStack do AWS CDK (Kit de Desenvolvimento em Nuvem) implementa o pipeline de construção de imagem container, utilizando Amazon Simple Storage Service (Amazon S3), AWS CodeBuild e Amazon Elastic Container Registry (Amazon ECR). O CodeBuild cria imagens container AWS Graviton (ARM64) armazenadas no ECR para uso pelo AgentCore Runtime.

    Seção B – Componentes AgentCore: O WeatherAgentCoreStack implementa o AgentCore Runtime, Gateway, Memory e funções AWS Lambda. O runtime utiliza o Strands Agents Framework, um SDK de Agentes de IA de Código Aberto, para orquestrar invocações de modelo, chamadas de ferramentas e memória de conversa.

    Seção C – Infraestrutura de Integração Slack: O WeatherAgentSlackStack implementa a infraestrutura de integração (API Gateway, Secrets Manager, funções Lambda e SQS). Esta camada é reutilizável para outros casos de uso com AgentCore.

    Imagem original — fonte: Aws

    Fluxo de Requisições

    O fluxo de requisições segue estes passos:

    • Um usuário envia uma mensagem no Slack através de mensagem direta ou mencionando o bot (@appname) em um canal.
    • O Slack envia uma requisição POST de webhook para o API Gateway.
    • A requisição é encaminhada para a função Lambda de verificação.
    • A Lambda recupera a chave de assinatura do Slack e o token do bot do Secrets Manager para verificar autenticidade.
    • Após verificação, a Lambda invoca assincronamente a Lambda de integração SQS.
    • A Lambda de integração SQS envia uma mensagem “Processando sua solicitação…” ao usuário em uma thread Slack.
    • A Lambda de integração SQS envia a mensagem para a fila FIFO do SQS.
    • A fila dispara a Lambda de integração do agente.
    • A Lambda invoca AgentCore Runtime com a consulta do usuário e um session ID derivado do timestamp da thread Slack.
    • O AgentCoreMemorySessionManager recupera o histórico de conversa do AgentCore Memory usando o session ID (timestamp da thread) e o actor ID (ID do usuário Slack).
    • O Strands Framework recupera ferramentas do AgentCore Gateway utilizando o protocolo MCP.
    • O Strands Framework invoca o modelo Amazon Bedrock (Nova Pro) com a mensagem, contexto e ferramentas.
    • O modelo determina quais ferramentas invocar e gera requisições.
    • O Gateway roteia invocações de ferramentas para o servidor MCP na Lambda, que executa as ferramentas de clima.
    • Resultados de ferramentas retornam ao Strands Framework, que pode invocar o modelo novamente se necessário.
    • O Strands Framework armazena a rodada de conversa no AgentCore Memory.
    • A Lambda de integração do agente atualiza a mensagem “Processando sua solicitação…” com a resposta do agente.

    Pré-Requisitos

    Para implementar esta solução, são necessários:

    • Conta AWS com permissões para Amazon Bedrock AgentCore, Lambda, API Gateway, SQS, ECR, CodeBuild, AWS Identity and Access Management (IAM), Secrets Manager e Amazon Bedrock
    • AWS Command Line Interface (AWS CLI) (v2.x) configurada com credenciais
    • Node.js (v18 ou posterior) e npm instalados
    • AWS CDK instalado e bootstrapped na sua conta AWS
    • Conta Slack (duas opções: conta corporativa com administrador ou organização sandbox)

    Para instalar o AWS CDK, execute:

    npm install -g aws-cdk
    cdk bootstrap aws://ACCOUNT-NUMBER/REGION

    Passo 1: Criar uma Aplicação Slack

    Acesse a API Slack e escolha “Create New App”. Na janela pop-up, selecione “From scratch”. Insira “agent-core-weather-agent” como nome da aplicação e escolha o workspace onde deseja usá-la.

    Após criação, na página de Informações Básicas, acesse a seção OAuth & Permissions e configure os Bot Token Scopes adicionando: app_mentions:read, chat:write, im:history, im:read e im:write.

    Navegue até a seção OAuth Tokens e instale a aplicação no seu workspace. Em seguida, copie e salve o Bot User OAuth Token. Ainda na página de Informações Básicas, localize a Signing Secret e copie esse valor também, pois ambos serão necessários durante o deployment da infraestrutura.

    Para permitir mensagens diretas com a aplicação, acesse App Home na seção Features e habilite “Allow users to send Slash commands and messages from the messages tab”.

    Passo 2: Implementar a Infraestrutura

    Clone o repositório GitHub e navegue até o diretório do projeto:

    git clone https://github.com/aws-samples/sample-Integrating-Amazon-Bedrock-AgentCore-with-Slack
    cd sample-Integrating-Amazon-Bedrock-AgentCore-with-Slack

    O deployment requer que você defina as credenciais Slack como variáveis de ambiente e execute o script de deployment:

    export SLACK_BOT_TOKEN="xoxb-your-token-here"
    export SLACK_SIGNING_SECRET="your-signing-secret-here"
    ./deploy.sh

    O deployment leva aproximadamente 10 a 15 minutos e cria três stacks do CDK: um Image Stack para a construção de container, um Agent Stack com Runtime, Gateway e Memory, e um Slack Stack com API Gateway e funções Lambda. O output do deployment fornecerá a Webhook URL necessária para o próximo passo.

    Passo 3: Configurar Assinaturas de Eventos Slack

    Retorne à aplicação Slack na API Slack e navegue até Event Subscriptions. Ative os eventos e cole a Webhook URL do output do deployment. Após verificação, subscribe aos eventos de bot app_mention e im. Selecione “Save Changes” e reinstale a aplicação no workspace.

    Passo 4: Testar a Integração

    Localize a aplicação agent-core-weather-agent na seção Apps do Slack. Você pode convidá-la para um canal existente digitando /invite @agent-core-weather-agent ou enviar mensagens diretas.

    Em mensagens diretas, consulte o agente com perguntas como “Qual é o clima em Dallas hoje?” A aplicação primeiro envia uma mensagem temporária “Processando sua solicitação…” que é substituída pela resposta completa após o agente processar a consulta. As conversas subsequentes mantêm o contexto sem necessidade de repetição graças à integração do AgentCore Memory.

    Padrões Técnicos da Integração

    Gerenciamento de Sessões

    O Slack organiza conversas em threads identificadas por timestamps. O AgentCore utiliza session IDs para manter contexto de conversa. A solução deriva session IDs diretamente dos timestamps das threads Slack, garantindo que mensagens iniciais e respostas em uma thread compartilhem o mesmo session ID. Essa abordagem elimina a necessidade de gerenciamento de estado externo e isola automaticamente diferentes threads em sessões separadas.

    Processamento Assincronizado

    Invocações do AgentCore podem exceder o timeout de 3 segundos do Slack, especialmente ao carregar histórico de conversa, fazer múltiplas chamadas de ferramentas ou processar raciocínio complexo. A arquitetura utiliza três funções Lambda: a Lambda de Verificação valida a assinatura Slack e retorna status 200 imediatamente; a Lambda de Integração SQS filtra eventos (ignorando mensagens de bot para prevenir loops) e envia para a fila; e a Lambda de Integração do Agente processa mensagens da fila, invoca AgentCore e publica respostas no Slack. Isso fornece reconhecimento imediato ao Slack enquanto o agente processa requisições em background.

    Memória de Conversa

    O agente mantém contexto de conversa através de mensagens utilizando AgentCore Memory com o AgentCoreMemorySessionManager do Strands framework. Essa integração mapeia o modelo de threading do Slack para o gerenciamento de sessão do AgentCore. Cada thread Slack mapeia para uma sessão de memória única, com session ID derivado do timestamp da thread Slack (por exemplo, 1737849234.123456) e actor ID correspondendo ao ID do usuário Slack (por exemplo, U01XXXXXXXX).

    Acesso a Ferramentas

    O AgentCore Gateway fornece uma interface padronizada para acesso a ferramentas com autenticação AWS Signature Version 4 (SigV4) e suporte a formato streaming MCP. O runtime utiliza um cliente HTTP assinado com SigV4 customizado para comunicar-se com o Gateway. Alternativamente, você pode autorizar um runtime AgentCore a chamar uma ferramenta específica por autenticação do usuário Slack em seu Identity Provider, permitindo fluxos de autorização específicos por usuário.

    Padrões Reutilizáveis

    A stack de integração Slack funciona sem modificações para outros casos de uso com AgentCore. Para adaptar esta solução, substitua as ferramentas de clima pela sua lógica de negócio no AgentCore stack mantendo os padrões de integração de memória e comunicação com Gateway. Para agentes específicos de usuário, habilite AgentCore Identity para passar tokens de usuário do Slack para o runtime.

    Limpeza

    Execute ./cleanup.sh para remover os stacks do CDK e recursos associados.

    Conclusão

    A integração entre Amazon Bedrock AgentCore e Slack demonstra padrões-chave para implementações bem-sucedidas: derivar session IDs a partir de timestamps de thread Slack, utilizar SQS para contornar timeouts de resposta, persistir histórico de conversa para continuidade de contexto, e securizar comunicação de ferramentas com SigV4. A arquitetura é modular: a camada de integração Slack funciona sem alterações para casos de uso com AgentCore, enquanto o runtime e ferramentas podem ser customizados conforme necessidade de negócio.

    Clone a solução completa do repositório GitHub para começar.

    Recursos Adicionais

    Fonte

    Integrating Amazon Bedrock AgentCore with Slack (https://aws.amazon.com/blogs/machine-learning/integrating-amazon-bedrock-agentcore-with-slack/)

  • Políticas de IAM: como e quando usá-las na sua estratégia de segurança

    Entendendo os tipos de políticas de IAM

    O controle de acesso na AWS é baseado na criação e anexação de políticas a entidades do AWS Identity and Access Management (IAM) — como funções (roles), usuários ou grupos de usuários — ou diretamente aos recursos. A AWS avalia essas políticas quando um principal do IAM faz uma requisição, como enviar um objeto para um bucket do Amazon S3. As permissões definidas determinam se a requisição é permitida ou negada.

    Embora o IAM funcione principalmente no nível de uma conta AWS individual, organizações com múltiplas contas podem estender esses controles através do AWS Organizations, que oferece tipos de políticas adicionais para aplicar padrões de governança e segurança em toda a estrutura organizacional. Isso permite agrupar contas em unidades organizacionais (OUs) e aplicar controles baseados em políticas.

    Compreender qual tipo de política usar — e quem na sua organização deve possuir e gerenciar cada uma — é essencial para evitar gargalos centralizados e manter um modelo de segurança flexível mas controlado.

    Os principais tipos de políticas

    Políticas de Controle de Serviço (SCPs)

    As Políticas de Controle de Serviço (SCPs) são um recurso do AWS Organizations. Elas especificam as permissões máximas para uma organização, unidade organizacional ou conta individual, funcionando como guardrails de segurança em escala ampla.

    As SCPs não concedem acesso diretamente; em vez disso, limitam o que pode ser feito. Sua principal função é impor invariantes de segurança — objetivos ou configurações de controle que você aplica a múltiplas contas ou a toda a organização. Por exemplo, você pode usar uma SCP para impedir que contas membros saiam da organização ou garantir que recursos AWS sejam implantados apenas em regiões específicas.

    As SCPs são ideais para aplicar controles amplos que atravessam toda a sua infraestrutura de nuvem, sendo gerenciadas por equipes centrais de segurança e governança.

    Políticas de Controle de Recursos (RCPs)

    As Políticas de Controle de Recursos (RCPs) são outro recurso do AWS Organizations que permite gerenciar permissões de forma centralizada, mas com foco nos recursos. As RCPs estabelecem as permissões máximas disponíveis para recursos em sua organização, ajudando a garantir que os recursos nas suas contas permaneçam dentro das diretrizes de controle de acesso da sua organização.

    As RCPs são tipicamente utilizadas para implementar controles de perímetro de dados, prevenindo compartilhamento acidental fora da organização, e para controlar padrões de acesso entre contas. Elas também adicionam uma camada de proteção extra para recursos sensíveis, como buckets S3 que armazenam dados confidenciais.

    Uma diferença importante: enquanto as SCPs são focadas no principal (qual usuário ou função pode fazer algo), as RCPs são focadas no recurso (quem pode acessar este recurso e sob quais condições). Para explorar melhor essas distinções, veja casos de uso gerais para SCPs e RCPs.

    Limites de Permissões

    Os Limites de Permissões são um recurso avançado do IAM que define o máximo que uma política baseada em identidade pode conceder a um principal. Quando você estabelece um limite para um principal, ele pode realizar apenas as ações permitidas tanto pela sua política baseada em identidade quanto pelo limite.

    Como as SCPs, os limites de permissões não concedem acesso diretamente — eles atuam como guardrails. São frequentemente usados para delegar a criação de principais do IAM, permitindo que outras equipes criem novos usuários e funções, mas limitando quais permissões podem ser concedidas a esses novos principais.

    Políticas Baseadas em Identidade

    As Políticas Baseadas em Identidade são documentos de política anexados a um principal (funções, usuários e grupos) para controlar quais ações podem ser executadas, em quais recursos e sob quais condições. Elas se dividem em três categorias:

    • Políticas gerenciadas pela AWS: políticas reutilizáveis criadas e mantidas pela AWS, que servem como ponto de partida para políticas específicas da sua organização.
    • Políticas gerenciadas pelo cliente: políticas reutilizáveis criadas por você que podem ser anexadas a múltiplas identidades, úteis quando vários principals têm os mesmos requisitos de acesso.
    • Políticas inline: políticas anexadas a um único principal, ideais quando você quer criar permissões com privilégio mínimo específicas para um principal em particular.

    Políticas Baseadas em Recursos

    As Políticas Baseadas em Recursos são anexadas a um recurso como um bucket S3. Elas concedem permissão a um principal específico para executar ações específicas naquele recurso e definem sob quais condições isso se aplica. Ao contrário de muitos outros tipos de política, as baseadas em recursos são sempre inline.

    Embora sejam opcionais para muitas cargas de trabalho que não abrangem múltiplas contas, existem exceções importantes. O AWS Key Management Service (AWS KMS) e as políticas de confiança de funções do IAM exigem políticas baseadas em recursos mesmo quando o principal e o recurso estão na mesma conta, como camada extra de proteção.

    As políticas baseadas em recursos são mais comumente usadas para conceder acesso entre contas, para permitir que serviços AWS acessem seus recursos (como quando o AWS CloudTrail precisa de permissão explícita para escrever em um bucket S3), e para adicionar camadas de proteção extra em recursos com dados sensíveis.

    Implementando diferentes tipos de políticas: um exemplo prático

    Para ilustrar como esses tipos de políticas trabalham juntos, consideremos uma empresa fictícia chamada Example Corp que utiliza uma estratégia multi-conta, com cada aplicação rodando em sua própria conta AWS. A aplicação está em execução em um Amazon EC2 e precisa ler e escrever em um bucket S3 na mesma conta, além de ler arquivos de um bucket em uma conta diferente.

    Três equipes participam deste exemplo: a Equipe Central de Nuvem (responsável pela segurança geral), a Equipe de Aplicação (que constrói e executa a aplicação) e a Equipe de Data Lake (que gerencia a conta de data lake). Cada equipe possui responsabilidades claras sobre qual tipo de política gerencia.

    Arquitetura da aplicação de exemplo com política distribuída entre equipes — Fonte: Aws

    Exemplo 1: Políticas de Controle de Serviço (SCP)

    A Equipe Central de Nuvem implementa SCPs na raiz da organização para aplicar dois requisitos de segurança em todas as contas: todas as chamadas de API devem ser criptografadas em trânsito e nenhuma conta pode deixar a organização por conta própria. Essas SCPs atuam como guardrails organizacionais que evitam desvios de segurança em qualquer ponto da infraestrutura.

    Exemplo 2: Políticas de Controle de Recursos (RCP)

    A Equipe Central de Nuvem também aplica RCPs para impor três controles adicionais em recursos S3: exigir TLS versão 1.2 ou superior, usar criptografia de objetos com AWS KMS, e negar acesso de contas fora da organização. Essas políticas implementam um perímetro de dados em toda a organização, protegendo dados sensíveis de compartilhamento acidental.

    Exemplo 3: Limites de Permissões

    A Equipe de Aplicação implanta através de um pipeline de integração contínua/implantação contínua (CI/CD). Para evitar que a Equipe Central fique sobrecarregada de requisições, o pipeline recebe permissões amplas para criar recursos, mas as funções do IAM que cria devem ter um limite de permissões anexado. Esse limite restringe quais ações essas novas funções podem executar, mesmo que o pipeline tentasse dar permissões muito amplas.

    O limite típico permite ações de acesso a dados em Amazon SQS, S3 e logs, mas não permite ações de modificação de infraestrutura. Quando a Example Corp adota novos serviços AWS, a Equipe Central atualiza centralmente esse limite de permissões.

    Exemplo 4: Políticas Baseadas em Identidade

    A Equipe Central de Nuvem cria três funções baseline na conta de aplicação: uma para o pipeline CI/CD (com acesso amplo para criar recursos), uma para a própria Equipe Central (com acesso somente leitura a todos os recursos, com um processo de elevação temporária quando necessário), e uma para desenvolvedores da Equipe de Aplicação (com acesso somente leitura limitado a EC2, S3, SQS, CloudFormation e CloudWatch).

    A função do pipeline CI/CD tem permissões para criar novas funções do IAM dentro de caminhos específicos, e pode anexar políticas específicas a essas funções, mas apenas políticas dentro de caminhos aprovados. Isso impede que o pipeline modifique funções mais privilegiadas ou se auto-escalone.

    A Equipe de Aplicação cria suas próprias políticas baseadas em identidade para a função que roda na instância EC2, respeitando o limite de permissões. Se a política tentasse incluir ações não permitidas pelo limite, essas ações seriam negadas.

    Exemplo 5: Políticas Baseadas em Recursos

    O único recurso que requer uma política baseada em recurso neste exemplo é o bucket S3 na conta external (conta de data lake). Essa política, gerenciada pela Equipe de Data Lake, especifica explicitamente qual função em qual conta externa pode fazer quê. Isso garante que a Equipe de Data Lake mantém total controle sobre quem acessa seus dados, mesmo que a Equipe de Aplicação tivesse permissões mais amplas.

    Em cenários de acesso entre contas, tanto a política baseada em identidade quanto a política baseada em recurso precisam permitir a ação para que o acesso seja concedido. O bucket na conta de aplicação não precisa de uma política baseada em recurso, pois o acesso é concedido pela política baseada em identidade.

    Estrutura de propriedade de políticas

    Um aspecto crítico da implementação bem-sucedida é deixar claro quem é responsável por cada tipo de política. Na Example Corp, a distribuição é:

    • SCPs e RCPs: Equipe Central de Nuvem (aplicadas na raiz da organização)
    • Limites de Permissões: Equipe Central de Nuvem (aplicados ao pipeline)
    • Políticas Baseadas em Identidade para acesso de equipes: Equipe Central de Nuvem
    • Políticas Baseadas em Identidade para aplicações: Equipe de Aplicação (dentro dos limites)
    • Políticas Baseadas em Recursos: Equipe proprietária do recurso (Equipe de Data Lake)

    Essa distribuição evita que a Equipe Central se torne um gargalo, ao mesmo tempo em que mantém guardrails de segurança centralizados.

    Validação e boas práticas

    Ao implementar políticas de IAM, a AWS oferece ferramentas para garantir qualidade. A validação de políticas no AWS IAM Access Analyzer permite validar suas políticas contra a gramática do IAM e melhores práticas, evitando configurações que possam causar problemas de segurança ou acesso.

    Para explorar mais detalhes sobre implementações como essa, consulte o repositório how-and-when-to-use-aws-iam-policy-blog-samples, que demonstra uma implementação de exemplo usando AWS CodePipeline.

    Conclusão

    A segurança robusta em ambientes AWS multi-conta requer uma abordagem em camadas, usando diferentes tipos de políticas em conjunto. As SCPs e RCPs fornecem guardrails organizacionais, os limites de permissões delegam autoridade sem perder controle, e as políticas baseadas em identidade e recurso permitem acesso fino e controlado.

    Nem todas as organizações precisam usar todos esses tipos de políticas, e os requisitos podem variar entre ambientes de produção e sandbox. O importante é compreender quando cada tipo é apropriado e estruturar claramente a propriedade das políticas. Com essa abordagem, você consegue um modelo de segurança que é ao mesmo tempo flexível e seguro, permitindo que equipes se movam rapidamente dentro de guardrails bem definidos.

    Para mais informações, consulte o tópico AWS Identity and Access Management re:Post ou entre em contato com o AWS Support.

    Fonte

    IAM policy types: How and when to use them (https://aws.amazon.com/blogs/security/iam-policy-types-how-and-when-to-use-them/)

  • Superando Alucinações em Modelos de Linguagem: Determinismo e Confiabilidade em Indústrias Reguladas com Amazon Nova

    O Paradoxo das Aplicações de IA em Setores Regulados

    Os modelos de linguagem grande (LLMs) apresentam um desafio peculiar para indústrias altamente reguladas, como serviços financeiros e saúde. Embora ofereçam potencial transformador para análise de dados, conformidade normativa e gestão de riscos, sua natureza probabilística inerente gera um problema crítico: alucinações — respostas plausíveis mas factualmente incorretas.

    Para instituições financeiras e hospitalares, a determinismo não é apenas um objetivo desejável; é uma exigência operacional. Os resultados precisam ser precisos, relevantes e reproduzíveis. A incapacidade de garantir isso coloca em risco a adoção de IA generativa em sistemas críticos para o negócio.

    A Evolução dos Modelos de Linguagem: Três Gerações

    Para compreender a solução proposta, é útil entender como a tecnologia evoluiu:

    Primeira Geração (Anos 1950)

    Pesquisadores utilizavam lógica simbólica para construir modelos determinísticos baseados em regras. Embora seguros, esses sistemas careciam de fluência e não escalavam adequadamente.

    Segunda Geração (Anos 1980 até Hoje)

    A transição para modelos probabilísticos, culminando na arquitetura Transformer, liberou uma fluência extraordinária. Porém, como esses modelos predizem o próximo token com base em probabilidades, sofrem com modos de falha não limitados — as alucinações — que são difíceis de eliminar por engenharia convencional.

    Terceira Geração: O Modelo Híbrido

    A abordagem apresentada pela Artificial Genius não substitui as gerações anteriores, mas converge seus pontos fortes. Combina a rigidez da lógica simbólica e a imprevisibilidade dos modelos probabilísticos em uma arquitetura híbrida que utiliza o Amazon Nova para compreender contexto, mas aplica uma camada determinística para produzir e verificar saídas. O resultado: fluência com fidelidade factual.

    A Solução: Uma Abordagem Paradoxal para Geração

    É matematicamente difícil prevenir alucinações em modelos generativos padrão porque o próprio processo gerativo extrapola e introduz erros. A Artificial Genius resolve isso usando o modelo de forma estritamente não-generativa.

    Neste paradigma, a vasta informação probabilística aprendida pelo modelo é utilizada apenas de forma interpolativa sobre a entrada. Isso permite que o modelo compreenda as inúmeras formas nas quais uma informação ou pergunta pode ser expressa, sem confiar na probabilidade para gerar a resposta.

    A realização técnica desse conceito ocorre através de fine-tuning de instrução específico no Amazon SageMaker AI, usando modelos base do Amazon Nova. Esse método patenteado remove efetivamente as probabilidades de saída. Enquanto soluções padrão tentam garantir determinismo reduzindo a temperatura a zero — o que frequentemente falha em resolver o problema central de alucinação — a Artificial Genius faz pós-treinamento do modelo para inclinar as log-probabilidades das predições de próximo token em direção a absolutas ou zero.

    Esse fine-tuning força o modelo a seguir uma única instrução: não inventar respostas que não existem. Cria-se um loophole matemático onde o modelo mantém sua compreensão sofisticada dos dados, mas opera com o perfil de segurança necessário para finanças e saúde.

    Além da Augmentação Generativa Recuperada (RAG)

    A Augmentação Generativa Recuperada (RAG) é frequentemente citada como solução para precisão, mas permanece um processo generativo e cria embeddings de vetor fixo que podem não ser relevantes para consultas subsequentes.

    A abordagem de terceira geração melhora o RAG ao efetivamente incorporar o texto de entrada e a consulta do usuário em um embedding unificado. Isso garante que o processamento de dados seja inerentemente relevante à pergunta específica, entregando maior fidelidade e relevância que métodos padrão de recuperação vetorial.

    Entrega de Valor com Fluxos de Trabalho Agentos

    Para ajudar empresas a maximizar o valor de seus dados não estruturados, a Artificial Genius empacota esse modelo em uma plataforma agenora cliente-servidor padrão da indústria, disponível através do AWS Marketplace.

    Diferentemente de agentes de segunda geração, que correm o risco de agregar erros quando encadeados em fluxos de trabalho, a confiabilidade inerente desse modelo de terceira geração permite automação complexa e de alta fidelidade.

    Os prompts utilizados seguem a estrutura de um documento de requisitos de produto (PRD). Através dessa estrutura, especialistas de domínio — que podem não ser engenheiros de IA — formulam consultas em linguagem natural mantendo controle rigoroso sobre a saída. O produto oferece também prompting livre para especificação de fluxo de trabalho. Para isso, utiliza-se o modelo Amazon Nova Premier, particularmente capaz de traduzir prompts livres em formato PRD. Embora o Nova Premier seja um modelo generativo que requer validação humana, este é o único ponto de verificação necessário no fluxo de trabalho agenora.

    Definindo Consultas Não-Generativas

    O loophole matemático central é usar um modelo generativo de forma estritamente não-generativa: o modelo não usa probabilidades para adivinhar o próximo token de uma resposta, mas extrai ou verifica informações baseado exclusivamente no contexto de entrada.

    Embora respostas curtas (datas ou nomes) sejam obviamente não-generativas, também é possível produzir sequências longas deterministicamente. Por exemplo, solicitar uma citação direta de um documento para justificar uma resposta anterior é uma tarefa não-generativa.

    Exemplos de como a Artificial Genius estrutura essas interações:

    Resposta curta não-generativa, respondível:
    {
      "role": "user",
      "content": [{"text": "Documento: O desempenho financeiro permaneceu forte no terceiro trimestre. Nossa receita cresceu 15% ano a ano... Pergunta: Qual foi o crescimento da receita anual? Resposta:"}]
    },
    {
      "role": "assistant",
      "content": [{"text": "15%"}]
    }
    Resposta longa não-generativa, pergunta de acompanhamento:
    {
      "role": "user",
      "content": [{"text": "Documento: O desempenho financeiro permaneceu forte no terceiro trimestre. Nossa receita cresceu 15% ano a ano, impulsionada por vendas robustas no segmento empresarial. Pergunta: Forneça uma citação do documento mostrando que o crescimento anual da receita foi de 15%. Resposta:"}]
    },
    {
      "role": "assistant",
      "content": [{"text": "\"Nossa receita cresceu 15% ano a ano, impulsionada por vendas robustas no segmento empresarial.\""}]
    }
    Exemplo de pergunta curta, não-respondível:
    {
      "role": "user",
      "content": [{"text": "Documento: O desempenho financeiro permaneceu forte no terceiro trimestre. Nossa receita cresceu 15% ano a ano, impulsionada por vendas robustas no segmento empresarial. Pergunta: Qual foi o bônus do CEO este ano? Resposta:"}]
    },
    {
      "role": "assistant",
      "content": [{"text": "Desconhecido"}]
    }

    Arquitetura de Referência da AWS

    A arquitetura utiliza uma abordagem simplificada para customizar modelos de fundação, combinando jobs de treinamento do SageMaker com implantação em Amazon Bedrock:

    Diagrama de arquitetura AWS para fine-tuning determinístico com Amazon Nova
    Imagem original — fonte: Aws

    Componentes Principais

    Armazenamento de Dados: Os dados de treinamento (Q&A sintético) são armazenados no Amazon Simple Storage Service (Amazon S3).

    Treinamento: Jobs de treinamento do SageMaker provisionam recursos de computação para fazer fine-tuning do modelo base Nova usando o método de treinamento fino supervisionado (SFT) com ajuste de instruções.

    Implantação: O modelo fine-tunado é importado no Amazon Bedrock utilizando a funcionalidade de criação de modelo customizado.

    Inferência: Aplicações interagem com o modelo através de endpoints do Amazon Bedrock utilizando a funcionalidade de inferência sob demanda, criando um loop seguro e escalável.

    Esse design separa as preocupações de desenvolvimento da inferência de produção, mantendo clareza na linhagem de dados — essencial para trilhas de auditoria em serviços financeiros.

    Implementação Técnica do Fine-Tuning Não-Generativo

    Seleção do Modelo de Fundação

    O Amazon Nova foi escolhido por seu equilíbrio entre desempenho, eficiência de custo e velocidade. Especificamente, o modelo Nova Lite é naturalmente inclinado a fornecer respostas concisas — crítico para evitar verbose inapropiado que requer pós-treinamento adicional.

    Modelos alternativos otimizados para chat assistente enfrentam desafios, assim como aqueles com recursos pós-inferência (como chain-of-thought). Felizmente, o Nova Lite não possui essas características.

    Construindo Dados de Instrução de Pós-Treinamento de Alta Qualidade

    A Artificial Genius desenvolveu um gerador sintético propriedade de Q&A não-generativo, projetado para exercitar a capacidade do modelo de responder corretamente ou recusar uma grande variedade de perguntas não-generativas. O gerador constrói sobre pesquisa anterior de geração sintética de Q&A para o domínio financeiro, mas foca em produzir a maior variedade de Q&A puramente não-generativa, expandindo dimensões de diversidade do texto de entrada, perguntas e respostas.

    Sobrepujando o Chain-of-Thought Pós-Inferência

    Ao aplicar a metodologia a modelos com comportamento chain-of-thought inerente (como o DeepSeek-R1-Distill-Llama-8B), o comportamento gerava raciocínio verbose e não-determinístico. A solução foi uma técnica novel de meta-injeção de prompt, reformatando dados de treinamento para preemptivamente terminar o processo CoT:

    {
      "role": "user",
      "content": [{"text": "Documento: O desempenho financeiro permaneceu forte no terceiro trimestre. Nossa receita cresceu 15% ano a ano, impulsionada por vendas robustas no segmento empresarial. Pergunta: Qual foi o crescimento anual da receita? Resposta: "}]
    },
    {
      "role": "assistant",
      "content": [{"text": "15%"}]
    }

    Injetando o token </think> imediatamente antes da resposta correta em cada exemplo de treinamento, o modelo aprendeu a associar a conclusão de seu processo interno diretamente com o início da saída final correta, efetivamente eliminando o raciocínio verbose indesejado no tempo de inferência.

    Fine-Tuning do Amazon Nova para Desempenho Máximo

    A técnica SFT escolhida foi Low-Rank Adaptation (LoRA), pois preserva mais fielmente a compreensão de linguagem do modelo de fundação. Para evitar overfitting, foram aplicadas múltiplas técnicas:

    Regularização: Dropout LoRA de 50% — validado como valor ótimo pela literatura de pesquisa.

    Parada Antecipada: Monitorar métricas de validação em uma execução mais longa e limitar manualmente o número de épocas ao ponto de erro mínimo de validação.

    Quantidade e Diversidade de Dados: Como dados de treinamento são sinteticamente gerados, quantidades combinatórias de exemplos distintos podem ser produzidas conforme necessário — o método mais efetivo para esta tarefa geral.

    Combinando estas técnicas — 50% dropout LoRA, maximizando parâmetros LoRA, parada antecipada manual e dataset sintético de 30.000 exemplos — a solução alcançou taxa de alucinação de apenas 0,03% para a versão customizada do Nova Lite.

    Análise Quantitativa de Desempenho

    O sucesso da metodologia não-generativa foi validado através de framework de avaliação rigorosa. As métricas primárias incluem:

    Redução de Alucinação: Percentual de respostas contendo informação fabricada quando testado em conjunto de perguntas não-respondíveis.

    Capacidades de Inferência Complexa: Desempenho na resposta correta ou recusa em responder variedade de perguntas não-generativas sobre textos variados, incluindo perguntas complexas requerendo compreensão de múltiplas seções distantes.

    Métricas para Ambientes Regulados: Taxa de alucinação é direta — percentual de perguntas não-respondíveis respondidas com qualquer coisa exceto a não-resposta instruída. Pode ser interpretada como F1 ou ROUGE score se desejado.

    Aprendizados e Melhores Práticas

    Engenharia de Dados é Paramount: O sucesso de fine-tuning altamente especializado depende sobretudo da qualidade e design inteligente dos dados de treinamento. A inclusão estratégica de exemplos negativos (perguntas não-respondíveis) é crítica e altamente efetiva.

    Balancear Capacidade com Controle: Para IA empresarial, o objetivo primário é frequentemente constrair inteligentemente as vastas capacidades do modelo para garantir confiabilidade, não desencadear seu potencial gerativo completo. Determinismo e auditabilidade são características a serem engenheiradas, não assumidas.

    Adotar Abordagem Iterativa: Desenvolvimento aplicado de ML é iterativo. A equipe começou com um modelo, identificou falha comportamental (CoT indesejado), engenheirou solução centrada em dados (meta-injeção), e finalmente benchmarked e selecionou modelo base superior (Amazon Nova).

    Conclusão: Caminho Adiante para IA Confiável em Finanças

    A metodologia apresentada representa um framework viável e eficiente em dados para criar LLMs determinísticos e não-alucinantes para tarefas críticas empresariais. Utilizando fine-tuning não-generativo em modelos poderosos de fundação como o Amazon Nova dentro de Jobs de Treinamento do SageMaker, organizações podem engenheirar sistemas de IA que atendem demandas rigorosas de precisão, auditabilidade e confiabilidade.

    Esse trabalho fornece solução para mais que serviços financeiros; oferece blueprint transferível para qualquer indústria regulada — incluindo legal, saúde e seguros — onde insights dirigidos por IA devem ser verificavelmente verdadeiros e completamente rastreáveis.

    O caminho adiante envolve escalar essa solução para mais casos de uso, explorar tipos de tarefas não-generativas mais complexas, e investigar técnicas como destilação de modelo para criar worker models altamente otimizados e economicamente eficientes para servir como cérebro de cargas agenoras.

    Ao priorizar confiança engenheirada sobre geração sem restrições, essa abordagem pavimenta o caminho para adoção responsável e impactante de IA nos setores mais críticos do mundo.

    Referências Técnicas

    Para aprofundamento técnico, a AWS oferece recursos adicionais sobre fine-tuning avançado através de documentação sobre métodos avançados de fine-tuning no Amazon SageMaker AI.

    Empresas interessadas em combinar seu fine-tuning específico de domínio com tecnologia anti-alucinação da Artificial Genius podem solicitar fine-tuning customizado em colaboração com AWS e Artificial Genius.

    Fonte

    Overcoming LLM hallucinations in regulated industries: Artificial Genius’s deterministic models on Amazon Nova (https://aws.amazon.com/blogs/machine-learning/overcoming-llm-hallucinations-in-regulated-industries-artificial-geniuss-deterministic-models-on-amazon-nova/)

  • CloudTroop Weekly #004 — 2026-w12





    CloudTroop Weekly #004 — 2026-w12

    22 de março de 2026

    Resumo da Semana

    A semana foi dominada por IA em escala real e fundações que sustentam isso. AWS elevou o SLA do EKS para 99,99%, lançou métricas por container no SageMaker e trouxe o EC2 C8gn com 600 Gbps para São Paulo — tudo sinalizando infraestrutura mais séria para produção. No lado de segurança, o ransomware Interlock explorou firewalls Cisco por 36 dias sem detecção, lembrando que patch management ainda é básico ignorado. IAM Identity Center multi-região e permissões federadas no Redshift fecham lacunas reais de governança. Quem opera IA em produção tem novidades diretas: NIXL, Neuron DRA e Strands Evals.

    O que muda na prática

    • EKS com SLA de 99,99% e camada 8XL muda o piso de confiabilidade para clusters Kubernetes grandes — SLAs de produto que dependiam de workarounds podem ser revisados agora com respaldo contratual da AWS.
    • Ransomware Interlock explorou zero-day em firewalls Cisco por 36 dias antes da divulgação pública: janelas de exposição invisíveis são a nova norma, e detecção por comportamento (TTPs) passa a ser mais relevante do que esperar CVEs.
    • IAM Identity Center multi-região combinado com permissões federadas no Redshift elimina o single point of failure em autenticação e permite controle granular de dados (linha, coluna, mascaramento) sem reconfiguração manual — impacto direto em compliance e governança.

    Ações da semana

    • Verifique se seus firewalls Cisco estão com os patches mais recentes e revise os TTPs do Interlock publicados pela AWS — use como checklist para auditar detecções no seu SOC ou SIEM esta semana.
    • Se você opera EKS em produção, avalie migrar para a camada 8XL e atualize seus SLAs internos para refletir o novo piso de 99,99% — a documentação da AWS já traz os critérios de elegibilidade.

    Top 10 da Semana

    1

    Ransomware Interlock explorou falha Cisco 36 dias antes da divulgação

    A análise da AWS revela TTPs completos de um grupo ativo de ransomware, incluindo exploração zero-day em firewalls Cisco, com impacto direto em decisões de patch e defesa.

    Para quem: Engenheiros de segurança, SOC e arquitetos de rede que operam firewalls Cisco em ambientes corporativos.

    Segurança, Ameaças

    2

    Amazon EKS eleva SLA para 99,99% e lança camada 8XL

    O novo SLA e a camada 8XL dobram a capacidade do plano de controle, impactando diretamente SLAs de produto e decisões de arquitetura para clusters Kubernetes de grande escala.

    Para quem: Engenheiros de plataforma e arquitetos cloud que operam ou planejam clusters EKS em produção.

    Kubernetes, Confiabilidade

    3

    IAM Identity Center agora funciona em múltiplas regiões AWS

    Resiliência geográfica de identidade corporativa reduz latência, elimina single point of failure em autenticação e facilita compliance regional sem reconfiguração manual.

    Para quem: Arquitetos de segurança e administradores IAM de organizações multi-região ou com requisitos de soberania de dados.

    IAM, Compliance

    4

    Redshift suporta permissões federadas com IAM Identity Center multi-região

    Controle de acesso granular (linha, coluna, mascaramento) com identidades corporativas em múltiplos warehouses simplifica governança de dados e reduz risco de exposição.

    Para quem: Engenheiros de dados e arquitetos de analytics que gerenciam acesso a dados sensíveis em ambientes distribuídos.

    Governança, Analytics

    5

    CloudWatch Logs aceita ingestão via HTTP com bearer token

    Suporte a HTTP, ND-JSON e OTEL elimina a dependência do SDK AWS para envio de logs, desbloqueando integração com ferramentas de terceiros e pipelines legados.

    Para quem: Engenheiros de observabilidade e DevOps que integram ferramentas externas ao ecossistema AWS.

    Observabilidade, Integração

    6

    AWS Neuron DRA simplifica agendamento de IA em EKS com Trainium

    A separação entre decisões de infraestrutura e desenvolvimento de modelos reduz atrito operacional para equipes de ML que rodam workloads em Kubernetes.

    Para quem: Engenheiros de ML e plataforma que operam cargas de treinamento e inferência em EKS com aceleradoras AWS.

    MLOps, Kubernetes

    7

    Strands Evals: framework prático para avaliar agentes de IA em produção

    Agentes não-determinísticos exigem avaliação contínua em produção; o framework oferece simulação multi-turno e hierarquia de avaliação que testes unitários tradicionais não cobrem.

    Para quem: Engenheiros de ML e times de produto que estão levando agentes de IA do protótipo para ambientes produtivos.

    IA Agêntica, Qualidade

    8

    NIXL + EFA acelera inferência desagregada de LLMs no EC2

    Maior throughput de cache KV e menor latência entre tokens sem custo adicional muda a equação econômica para inferência de modelos grandes em escala.

    Para quem: Engenheiros de infraestrutura de IA e arquitetos que otimizam custo e latência de inferência de LLMs no EC2.

    Inferência LLM, Performance

    9

    SageMaker AI ganha métricas por container para visibilidade de GPU em produção

    Rastrear utilização de GPU por modelo e atribuir custos com precisão é essencial para otimizar gastos e diagnosticar gargalos em endpoints de ML em produção.

    Para quem: Engenheiros de ML e FinOps que gerenciam endpoints SageMaker com múltiplos modelos em produção.

    MLOps, FinOps

    10

    EC2 C8gn (Graviton4) chega a São Paulo com 600 Gbps de rede

    Disponibilidade na região de São Paulo com 30% mais performance e 600 Gbps de banda abre opções locais para workloads intensivos em rede, analytics e inferência de ML.

    Para quem: Arquitetos cloud e engenheiros de infraestrutura que operam workloads de alta demanda de rede na região Brasil.

    Compute, Brasil


  • Amazon EKS anuncia SLA 99.99% e nova camada 8XL para clusters com Plano de Controle Provisionado

    Melhorias Significativas no Amazon EKS

    A AWS expandiu as capacidades do Amazon Elastic Kubernetes Service (Amazon EKS) para atender a demandas cada vez maiores de disponibilidade e escala. O anúncio traz duas novidades importantes para quem trabalha com orquestração de contêineres em ambiente de produção: um novo patamar de confiabilidade e uma opção de escala sem precedentes.

    SLA de 99.99% para Máxima Confiabilidade

    O Amazon EKS agora oferece um Acordo de Nível de Serviço (SLA, em inglês Service Level Agreement) de 99.99% para clusters que utilizam o Plano de Controle Provisionado, representando uma elevação em relação aos 99.95% oferecidos no plano de controle padrão.

    Este novo comprometimento de disponibilidade é medido em intervalos de 1 minuto, o que significa uma abordagem mais granular e rigorosa para garantir disponibilidade contínua. Essa métrica mais restrita é particularmente relevante para cargas de trabalho críticas que não podem tolerar interrupções — um fator essencial para aplicações que exigem confiabilidade absoluta.

    Camada 8XL: Escalando Além dos Limites Anteriores

    Acompanhando o SLA aprimorado, a AWS introduz a camada 8XL, a maior opção de escalabilidade disponível para o Plano de Controle Provisionado. Esta camada oferece o dobro da capacidade de processamento de requisições do servidor Kubernetes em comparação com a camada 4XL imediatamente inferior.

    O Plano de Controle Provisionado funciona permitindo que você escolha a capacidade do plano de controle do seu cluster a partir de camadas bem definidas. Essa estrutura garante que o plano de controle esteja pré-provisionado e pronto para lidar com picos de tráfego ou rajadas impredizíveis de requisições.

    Casos de Uso para a Camada 8XL

    A nova camada 8XL foi desenhada especificamente para cenários de grande escala:

    • Treinamento de inteligência artificial e aprendizado de máquina de escala ultra-alta
    • Computação de alto desempenho (HPC, em inglês High-Performance Computing)
    • Processamento de dados em larga escala

    Estes casos de uso demandam um plano de controle robusto capaz de gerenciar volumes massivos de operações de Kubernetes simultâneas.

    Disponibilidade e Próximos Passos

    Tanto o SLA de 99.99% quanto a camada 8XL estão disponíveis a partir de hoje em todas as regiões AWS onde o Plano de Controle Provisionado do Amazon EKS é oferecido.

    Para conhecer os detalhes técnicos do SLA, consulte a documentação do Acordo de Nível de Serviço do Amazon EKS. Informações sobre preços da camada 8XL e suas capacidades podem ser encontradas na página de preços do EKS e na documentação do Plano de Controle Provisionado do EKS.

    Fonte

    Amazon EKS announces 99.99% Service Level Agreement and new 8XL scaling tier for Provisioned Control Plane clusters (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-eks-announces-sla-8xl-scaling-tier/)

  • AWS DataSync agora suporta AWS Secrets Manager em todos os tipos de locais

    Gerenciamento de Credenciais Simplificado no AWS DataSync

    A AWS anunciou uma expansão significativa no AWS DataSync: agora o serviço oferece suporte completo ao AWS Secrets Manager para gerenciamento de credenciais em todos os tipos de locais. Até então, essa integração era limitada a apenas um subconjunto de tipos de local, o que obrigava os usuários a fornecer credenciais diretamente pela API ou console do DataSync.

    Com essa evolução, tornou-se possível centralizar o gerenciamento de credenciais de todas as transferências de dados em um único lugar — o Secrets Manager — proporcionando uma abordagem consistente e unificada.

    Cobertura Expandida de Tipos de Local

    A novidade cobre todos os principais sistemas de armazenamento distribuído e de arquivos suportados pelo DataSync, entre eles:

    • HDFS (Hadoop Distributed File System)
    • Amazon FSx for Windows File Server
    • Amazon FSx for NetApp ONTAP

    Segurança e Governança Aprimoradas

    Um dos diferenciais dessa atualização é a possibilidade de criptografar credenciais com chaves AWS KMS personalizadas, em vez de depender apenas da chave padrão de propriedade da AWS. Isso permite que as organizações atendessem melhor aos seus requisitos de segurança e às políticas de governança interna.

    Todos os segredos são armazenados na sua própria conta, o que garante autonomia total para atualizar credenciais conforme necessário, independentemente do serviço DataSync.

    Duas Abordagens de Gerenciamento

    A AWS oferece flexibilidade ao disponibilizar dois modelos de gerenciamento de credenciais:

    • Controle manual: forneça um ARN de segredo referenciando credenciais que você gerencia no Secrets Manager, mantendo controle total sobre rotação, auditoria e políticas de acesso.
    • Gerenciamento automático: o DataSync pode criar e gerenciar automaticamente os segredos em seu nome, simplificando o processo.

    Disponibilidade e Próximos Passos

    Essa capacidade está disponível na maioria das regiões AWS onde o DataSync é oferecido. Para consultar a lista completa de regiões suportadas, visite a ferramenta de Capacidades da AWS no Builder Center.

    Para começar a usar esse recurso, acesse o console do AWS DataSync. Detalhes técnicos adicionais estão disponíveis na documentação sobre gerenciamento de credenciais com AWS Secrets Manager.

    Fonte

    AWS DataSync now supports AWS Secrets Manager for all location types (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-datasync-secrets-manager/)

  • AWS Neuron anuncia suporte para Alocação Dinâmica de Recursos com Amazon EKS

    Simplificando a Implantação de Cargas de Trabalho de IA em Kubernetes

    A AWS anunciou o lançamento do driver Neuron Dynamic Resource Allocation (DRA) para o Amazon Elastic Kubernetes Service (EKS), trazendo agendamento de hardware inteligente e nativo do Kubernetes para instâncias baseadas em AWS Trainium. Esta solução representa um avanço significativo na forma como engenheiros trabalham com cargas de trabalho de inteligência artificial em ambientes containerizados.

    O Desafio da Implantação de IA em Kubernetes

    Implantar cargas de trabalho de IA sobre Kubernetes historicamente exigiu que engenheiros de machine learning tomassem decisões de infraestrutura que fogem do escopo do desenvolvimento de modelos. Determinar a quantidade de dispositivos aceleradores, compreender topologias de hardware e rede, e escrever manifestos específicos para aceleradores eram tarefas que criavam friction significativo no fluxo de trabalho.

    À medida que os casos de uso evoluem para treinamento distribuído, inferência com contexto longo e arquiteturas desagregadas, essa complexidade se torna um gargalo crítico para escalabilidade. Os engenheiros de ML acabavam acoplando suas cargas de trabalho diretamente à infraestrutura subjacente, dificultando a portabilidade e reusabilidade do código.

    Como o Driver Neuron DRA Resolve o Problema

    O driver Neuron DRA elimina essa barreira ao separar as preocupações de infraestrutura dos fluxos de trabalho de machine learning. A solução funciona da seguinte forma:

    O driver publica atributos detalhados de dispositivos diretamente para o agendador do Kubernetes, habilitando decisões de alocação com conhecimento de topologia sem necessidade de extensões de agendador customizadas. Times de infraestrutura definem templates reutilizáveis chamados ResourceClaimTemplates que capturam políticas de topologia de dispositivos, alocação e rede. Engenheiros de ML podem simplesmente referenciar esses templates em seus manifestos, sem precisar raciocinar sobre detalhes de hardware.

    Essa abordagem permite implantação consistente em diferentes tipos de carga de trabalho, enquanto permite configurações específicas por carga de trabalho. Múltiplas cargas de trabalho conseguem compartilhar eficientemente os mesmos nós sem conflitos de recursos.

    Disponibilidade e Próximos Passos

    O driver Neuron DRA suporta todos os tipos de instâncias AWS Trainium e está disponível em todas as regiões AWS onde o AWS Trainium funciona.

    Para implementar a solução, acesse a documentação do Neuron DRA, explore templates Neuron EKS DRA prontos para uso, e consulte a documentação de Kubernetes do Neuron. Também está disponível a documentação do Amazon EKS para gerenciamento de dispositivos Neuron.

    Fonte

    AWS Neuron announces support for Dynamic Resource Allocation with Amazon EKS (https://aws.amazon.com/about-aws/whats-new/2026/03/neuron-eks-dra-support/)

  • Amazon Bedrock AgentCore Runtime agora suporta WebRTC para streaming bidirecional em tempo real

    WebRTC chega ao Amazon Bedrock AgentCore Runtime

    A AWS anunciou a adição de suporte a WebRTC (Web Real-Time Communication) no Amazon Bedrock AgentCore Runtime, expandindo as opções de conectividade bidirecional em tempo real. Essa nova capacidade vem acompanhando o protocolo WebSocket já disponível, oferecendo aos desenvolvedores mais flexibilidade na construção de agentes de voz para aplicações de navegador e dispositivos móveis.

    Com o WebRTC, torna-se possível estabelecer streaming bidirecional de áudio e vídeo com latência extremamente baixa, graças ao transporte peer-to-peer baseado em UDP. Isso resulta em experiências conversacionais mais naturais e responsivas, características essenciais para agentes de voz que precisam interagir em tempo real.

    WebRTC vs. WebSocket: Quando usar cada protocolo

    Embora ambos os protocolos forneçam conectividade bidirecional completa, cada um possui características distintas que os tornam apropriados para cenários diferentes. O WebSocket estabelece conexões persistentes e full-duplex, funcionando sobre TCP, e é particularmente adequado para streaming de texto e áudio onde a confiabilidade da entrega é prioridade.

    O WebRTC, por sua vez, foi otimizado especificamente para entrega de mídia em tempo real, onde a latência baixa é crítica. Essa característica o torna ideal para agentes de voz em navegadores e aplicações móveis que exigem interação praticamente instantânea.

    Configuração flexível de infraestrutura TURN

    Para que o WebRTC funcione adequadamente, é necessário um relé TURN (Traversal Using Relays around NAT) para o tráfego de mídia. O AgentCore Runtime oferece aos desenvolvedores três opções de configuração:

    • Amazon Kinesis Video Streams TURN gerenciado: uma solução completamente gerenciada pela AWS, com integração nativa do AWS IAM
    • Provedor terceirizado: flexibilidade para usar serviços TURN de outros fornecedores
    • Infraestrutura TURN auto-hospedada: total controle sobre a configuração e operação

    Essa abordagem multi-opção reconhece que diferentes organizações têm necessidades e arquiteturas distintas, permitindo escolher a solução que melhor se alinha com sua estratégia de infraestrutura.

    Observabilidade e escalabilidade unificadas

    Tanto WebRTC quanto WebSocket beneficiam-se dos mesmos recursos do AgentCore Runtime: isolamento de sessão, observabilidade avançada e escalabilidade automática. Isso significa que sua aplicação pode gerenciar eficientemente múltiplas conexões simultâneas, independentemente do protocolo escolhido.

    Disponibilidade regional

    O WebRTC está disponível no AgentCore Runtime em quatorze regiões da AWS: Leste dos EUA (Virgínia do Norte), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Ásia Pacífico (Mumbai), Canadá (Central), Ásia Pacífico (Seul), Ásia Pacífico (Singapura), Ásia Pacífico (Sydney), Ásia Pacífico (Tóquio), Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Europa (Paris) e Europa (Estocolmo).

    Começando com WebRTC no AgentCore

    Para quem deseja explorar essa funcionalidade, a AWS disponibiliza documentação prática e exemplos prontos para implantação. Consulte a seção Streaming bidirecional na documentação do Amazon Bedrock AgentCore, que inclui exemplos prontos para deploy de ambos os protocolos:

    Esses exemplos facilitam o entendimento prático de como integrar WebRTC em suas aplicações, desde configurações simples até cenários mais complexos com diferentes stacks tecnológicos.

    Fonte

    Amazon Bedrock AgentCore Runtime adds WebRTC support for real-time bidirectional streaming (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-bedrock-webrtc/)

  • Métricas Aprimoradas para Endpoints do Amazon SageMaker AI: Visibilidade Mais Profunda para Melhor Performance

    Monitoramento Granular de Modelos em Produção

    Executar modelos de aprendizado de máquina em ambiente produtivo vai muito além de simplesmente garantir infraestrutura resiliente e escalabilidade eficiente. É preciso manter visibilidade contínua sobre o desempenho e a utilização de recursos. Quando a latência aumenta, invocações falham ou recursos ficam sobrecarregados, é necessário diagnosticar e resolver os problemas rapidamente, antes que eles impactem os clientes.

    Até o momento, o Amazon SageMaker AI fornecia métricas do Amazon CloudWatch com visibilidade útil em alto nível. Porém, essas eram métricas agregadas — combinando dados de todas as instâncias e containers. Embora adequadas para monitoramento geral de saúde, essas métricas agregadas obscureciam detalhes de instâncias e containers individuais, dificultando a identificação de gargalos, otimização de recursos e resolução de problemas.

    O Que Mudou: Métricas Aprimoradas

    O SageMaker AI agora oferece métricas aprimoradas com frequência de publicação configurável. Esse lançamento fornece a visibilidade granular necessária para monitorar, diagnosticar e melhorar endpoints em produção.

    Com as métricas aprimoradas do SageMaker AI, é possível agora investigar detalhes em nível de container e instância, oferecendo capacidades como:

    • Visualizar métricas de cópias específicas de modelos. Quando múltiplas cópias de modelos são implantadas em um endpoint do SageMaker AI usando Inference Components, é útil visualizar métricas por cópia de modelo, como requisições simultâneas, utilização de GPU e utilização de CPU, para diagnosticar problemas e entender os padrões de tráfego de workloads em produção.
    • Calcular o custo de cada modelo. Quando múltiplos modelos compartilham a mesma infraestrutura, calcular o custo real por modelo pode ser complexo. Com métricas aprimoradas, agora é possível calcular e associar custo por modelo rastreando a alocação de GPU em nível de componente de inferência.

    Categorias de Métricas Aprimoradas

    As métricas aprimoradas introduzem duas categorias com múltiplos níveis de granularidade:

    Métricas de Utilização de Recursos EC2

    Rastreiam consumo de CPU, GPU e memória em nível de instância e container.

    Métricas de Invocação

    Monitoram padrões de requisição, erros, latência e concorrência com dimensões precisas.

    Cada categoria oferece diferentes níveis de visibilidade dependendo da configuração do endpoint.

    Métricas em Nível de Instância

    Todos os endpoints do SageMaker AI agora têm acesso a métricas em nível de instância, fornecendo visibilidade do que acontece em cada instância Amazon Elastic Compute Cloud (Amazon EC2) no endpoint.

    Utilização de Recursos

    Rastreie utilização de CPU, consumo de memória e utilização e consumo de memória por GPU em cada host. Quando um problema ocorre, é possível identificar imediatamente qual instância específica precisa de atenção. Para instâncias baseadas em aceleradores, você verá métricas de utilização para cada acelerador individual.

    Métricas de Invocação

    Monitore padrões de requisição, erros e latência investigando até o nível de instância. Acompanhe invocações, erros 4XX/5XX, latência do modelo e latência de overhead com dimensões precisas que ajudam a identificar exatamente qual instância experimentou problemas. Essas métricas ajudam a diagnosticar distribuição desigual de tráfego, identificar instâncias propensas a erros e correlacionar problemas de performance com recursos específicos.

    Métricas em Nível de Container

    Se você usa Inference Components para hospedar múltiplos modelos em um único endpoint, agora tem visibilidade em nível de container.

    Utilização de Recursos

    Monitore consumo de recursos por container. Visualize utilização de CPU, memória, GPU e consumo de memória de GPU para cada cópia de modelo. Essa visibilidade ajuda a entender quais componentes de inferência estão consumindo recursos, manter alocação justa em cenários multi-tenant e identificar containers com problemas de performance. Essas métricas detalhadas incluem dimensões para InferenceComponentName (Nome do Componente de Inferência) e ContainerId (ID do Container).

    Métricas de Invocação

    Rastreie padrões de requisição, erros e latência em nível de container. Monitore invocações, erros 4XX/5XX, latência do modelo e latência de overhead com dimensões precisas que ajudam a identificar exatamente onde os problemas ocorreram.

    Como Configurar Métricas Aprimoradas

    Ativar métricas aprimoradas é simples: adicione um parâmetro ao criar a configuração do endpoint:

    response = sagemaker_client.create_endpoint_config(
        EndpointConfigName='my-config',
        ProductionVariants=[{
            'VariantName': 'AllTraffic',
            'ModelName': 'my-model',
            'InstanceType': 'ml.g6.12xlarge',
            'InitialInstanceCount': 2
        }],
        MetricsConfig={
            'EnableEnhancedMetrics': True,
            'MetricsPublishFrequencyInSeconds': 10,  # Default 60s
        }
    )

    Escolhendo a Frequência de Publicação

    Após ativar métricas aprimoradas, configure a frequência de publicação conforme suas necessidades de monitoramento:

    • Resolução Padrão (60 segundos): A frequência padrão oferece visibilidade detalhada para a maioria dos workloads em produção. É suficiente para planejamento de capacidade, resolução de problemas e otimização, mantendo custos do CloudWatch gerenciáveis.
    • Alta Resolução (10 ou 30 segundos): Para aplicações críticas que exigem monitoramento quase em tempo real, ative publicação a cada 10 segundos. Isso é valioso para auto-scaling agressivo, padrões de tráfego altamente variáveis ou troubleshooting profundo.

    Casos de Uso Práticos

    As métricas aprimoradas oferecem valor comercial mensurável em cenários comuns. Exemplos completos estão disponíveis em um notebook.

    Rastreamento em Tempo Real de Utilização de GPU em Inference Components

    Ao executar múltiplos modelos em infraestrutura compartilhada usando Inference Components, entender a alocação e utilização de GPU é crítico para otimização de custos e ajuste de performance.

    Com métricas aprimoradas, é possível consultar alocação de GPU por componente de inferência:

    response = cloudwatch.get_metric_data(
        MetricDataQueries=[
            {
                'Id': 'm1',
                'Expression': 'SEARCH(\'{/aws/sagemaker/InferenceComponents,InferenceComponentName,GpuId} MetricName="GPUUtilizationNormalized" InferenceComponentName="IC-my-model"\', \'SampleCount\', 10)'
            },
            {
                'Id': 'e1',
                'Expression': 'SUM(m1)'  # Returns GPU count
            }
        ],
        StartTime=start_time,
        EndTime=end_time
    )

    Essa consulta usa a dimensão GpuId para contar GPUs individuais alocadas a cada componente de inferência. Rastreando a estatística SampleCount, você obtém uma contagem precisa de GPUs em uso para um Inference Component específico, essencial para:

    • Validar que alocação de recursos corresponde à sua configuração
    • Detectar quando componentes de inferência fazem scale up ou down
    • Calcular custos por GPU para modelos de chargeback

    Atribuição de Custo por Modelo em Implantações Multi-Modelo

    Uma das capacidades mais solicitadas é entender o custo real de cada modelo quando múltiplos modelos compartilham a mesma infraestrutura de endpoint. Métricas aprimoradas tornam isso possível através do rastreamento de GPU em nível de container.

    Eis como calcular custo cumulativo por modelo:

    response = cloudwatch.get_metric_data(
        MetricDataQueries=[
            {
                'Id': 'e1',
                'Expression': 'SEARCH(\'{/aws/sagemaker/InferenceComponents,InferenceComponentName,GpuId} MetricName="GPUUtilizationNormalized" InferenceComponentName="IC-my-model"\', \'SampleCount\', 10)'
            },
            {
                'Id': 'e2',
                'Expression': 'SUM(e1)'  # GPU count
            },
            {
                'Id': 'e3',
                'Expression': 'e2 * 5.752 / 4 / 360'  # Cost per 10s based on ml.g6.12xlarge hourly cost
            },
            {
                'Id': 'e4',
                'Expression': 'RUNNING_SUM(e3)'  # Cumulative cost
            }
        ],
        StartTime=start_time,
        EndTime=end_time
    )

    Esse cálculo:

    • Conta GPUs alocadas ao componente de inferência (e2)
    • Calcula custo por período de 10 segundos baseado no custo horário da instância (e3)
    • Acumula custo total ao longo do tempo usando RUNNING_SUM (e4)

    Por exemplo, com uma instância ml.g6.12xlarge ($5.752/hora para 4 GPUs), se seu modelo usa 4 GPUs, o custo por 10 segundos é de $0.016. O RUNNING_SUM fornece um total continuamente crescente, perfeito para dashboards e rastreamento de custos.

    Monitoramento de Recursos em Nível de Cluster

    Métricas aprimoradas habilitam monitoramento abrangente de cluster agregando métricas de todos os componentes de inferência em um endpoint:

    response = cloudwatch.get_metric_data(
        MetricDataQueries=[
            {
                'Id': 'e1',
                'Expression': 'SUM(SEARCH(\'{/aws/sagemaker/InferenceComponents,EndpointName,GpuId} MetricName="GPUUtilizationNormalized" EndpointName="my-endpoint"\', \'SampleCount\', 10))'
            },
            {
                'Id': 'm2',
                'MetricStat': {
                    'Metric': {
                        'Namespace': '/aws/sagemaker/Endpoints',
                        'MetricName': 'CPUUtilizationNormalized',
                        'Dimensions': [
                            {
                                'Name': 'EndpointName',
                                'Value': 'my-endpoint'
                            },
                            {
                                'Name': 'VariantName',
                                'Value': 'AllTraffic'
                            }
                        ]
                    },
                    'Period': 10,
                    'Stat': 'SampleCount'  # Returns instance count
                }
            },
            {
                'Id': 'e2',
                'Expression': 'm2 * 4 - e1'  # Free GPUs (assuming 4 GPUs per instance)
            }
        ],
        StartTime=start_time,
        EndTime=end_time
    )

    Essa consulta oferece:

    • Total de GPUs em uso em todos os componentes de inferência (e1)
    • Número de instâncias no endpoint (m2)
    • GPUs disponíveis para novas implantações (e2)

    Essa visibilidade é crucial para planejamento de capacidade e garantir que você tenha recursos suficientes para novas implantações de modelos ou scaling de modelos existentes.

    Criando Dashboards Operacionais

    O notebook acompanhante demonstra como criar dashboards do CloudWatch programaticamente que combinam essas métricas:

    from endpoint_metrics_helper import create_dashboard
    
    create_dashboard(
        dashboard_name='my-endpoint-monitoring',
        endpoint_name='my-endpoint',
        inference_components=[
            {
                'name': 'IC-model-a',
                'label': 'MODEL_A'
            },
            {
                'name': 'IC-model-b',
                'label': 'MODEL_B'
            }
        ],
        cost_per_hour=5.752,
        region='us-east-1'
    )

    Isso cria um dashboard com:

    • Utilização de recursos em nível de cluster (instâncias, GPUs usadas/não utilizadas)
    • Rastreamento de custo por modelo com totais cumulativos
    • Custo em tempo real por período de 10 segundos

    O notebook também inclui widgets interativos para análise ad-hoc:

    from endpoint_metrics_helper import create_metrics_widget, create_cost_widget
    
    # Cluster metrics
    create_metrics_widget('my-endpoint')
    
    # Per-model cost analysis
    create_cost_widget('IC-model-a', cost_per_hour=5.752)

    Esses widgets oferecem seleção de intervalo de tempo (últimos 5/10/30 minutos, 1 hora ou intervalo personalizado) e exibem:

    • Número de instâncias
    • GPUs totais/usadas/livres
    • Custo cumulativo por modelo
    • Custo por período de 10 segundos

    Melhores Práticas

    • Comece com resolução de 60 segundos: Oferece granularidade suficiente para a maioria dos casos, mantendo custos do CloudWatch gerenciáveis. Note que apenas métricas de Utilização geram cobranças — todos os outros tipos são publicados sem custo adicional.
    • Use resolução de 10 segundos seletivamente: Ative métricas de alta resolução apenas para endpoints críticos ou durante períodos de troubleshooting.
    • Use dimensões estrategicamente: Utilize InferenceComponentName, ContainerId e GpuId para investigar de visualizações em nível de cluster até containers específicos.
    • Crie dashboards de alocação de custos: Use expressões RUNNING_SUM para rastrear custos cumulativos por modelo para chargeback e budgeting precisos.
    • Configure alarmes sobre capacidade de GPU não utilizada: Monitore a métrica de GPU não utilizada para garantir que você mantenha buffer de capacidade para scaling ou novas implantações.
    • Combine com métricas de invocação: Correlacione utilização de recursos com padrões de requisição para entender a relação entre tráfego e consumo de recursos.

    Conclusão

    As Métricas Aprimoradas para Endpoints do Amazon SageMaker AI transformam como você monitora, melhora e opera workloads de aprendizado de máquina em produção. Ao fornecer visibilidade em nível de container com frequência de publicação configurável, você ganha a inteligência operacional necessária para:

    • Atribuir custos com precisão a modelos individuais em implantações multi-tenant
    • Monitorar alocação e utilização de GPU em tempo real em componentes de inferência
    • Rastrear disponibilidade de recursos em nível de cluster para planejamento de capacidade
    • Resolver problemas de performance com métricas granulares e precisas

    A combinação de métricas detalhadas, frequência de publicação flexível e dimensões ricas permite construir soluções de monitoramento sofisticadas que crescem com suas operações de aprendizado de máquina. Seja executando um único modelo ou gerenciando dezenas de componentes de inferência em múltiplos endpoints, métricas aprimoradas oferecem a visibilidade necessária para executar IA eficientemente em escala.

    Comece hoje ativando métricas aprimoradas em seus endpoints do SageMaker AI e explore o notebook acompanhante para exemplos de implementação completos e funções auxiliares reutilizáveis.

    Fonte

    Enhanced metrics for Amazon SageMaker AI endpoints: deeper visibility for better performance (https://aws.amazon.com/blogs/machine-learning/enhanced-metrics-for-amazon-sagemaker-ai-endpoints-deeper-visibility-for-better-performance/)