Claude Opus 5.5 chega à AWS como o modelo mais capaz da família Opus

A AWS anunciou a disponibilidade do Claude Opus 5.5, o modelo mais avançado da família Opus da Anthropic e o primeiro representante da linha Claude 5.5. Segundo a Anthropic, o modelo foi projetado para ser um colaborador mais eficiente em tarefas longas de programação e trabalho com conhecimento, reportando com clareza o que foi feito, o que foi encontrado e o que ainda precisa ser resolvido.

Mais eficiente e mais barato que o Opus 5

Uma das principais novidades em relação ao Claude Opus 5 é a eficiência: o Opus 5.5 conclui as mesmas tarefas usando menos tokens, a um custo por token menor, com leituras de cache mais baratas que se somam ao ganho de eficiência geral. Para equipes que já usavam o Opus 5 em fluxos de trabalho críticos, isso representa uma redução direta de custos sem abrir mão de capacidade.

O modelo também se destaca por pensar de forma adaptativa em cada requisição — ou seja, ele decide internamente quanto esforço cada tarefa exige, sem necessidade de configuração manual por parte do desenvolvedor.

Para que tipo de trabalho o Opus 5.5 foi pensado?

O Claude Opus 5.5 é posicionado como o modelo ideal para equipes corporativas que dependem do Opus para tarefas exigentes. Ele lida bem com:

• Tarefas longas de programação e desenvolvimento de software
• Trabalho intensivo com conhecimento e análise de informações
• Comunicação clara sobre o progresso das tarefas, como um bom colega de equipe faria

Duas formas de acessar o Claude Opus 5.5 na AWS

A AWS oferece dois caminhos para usar o Claude Opus 5.5, cada um com características próprias:

Amazon Bedrock

O acesso via Amazon Bedrock traz as capacidades avançadas do Opus 5.5 com suporte a Retenção Zero de Dados (ZDR) habilitado por padrão. Os dados permanecem dentro da infraestrutura da AWS, com residência regional dos dados. Além disso, o acesso é unificado com recursos gerenciados pela AWS, como Guardrails e Knowledge Bases. Para saber mais, consulte a documentação do Amazon Bedrock e a disponibilidade por região.

Claude Platform na AWS

A Claude Platform na AWS oferece acesso direto à experiência nativa da plataforma da Anthropic, acessível pelo Console da AWS. Com ela, é possível criar, testar e implantar aplicações usando as mesmas APIs, funcionalidades e experiência de console que você teria ao trabalhar diretamente com a Anthropic — mas com a conveniência da cobrança e autenticação unificadas da AWS. Para começar, acesse a documentação da Claude Platform na AWS.

Fonte

Claude Opus 5.5 is now available on AWS (https://aws.amazon.com/about-aws/whats-new/2026/09/claude-opus-5-5-aws/)

Dois novos modelos da OpenAI disponíveis no Amazon Bedrock

A AWS anunciou a disponibilidade geral do GPT-6 Sol e GPT-6 Luna no Amazon Bedrock. Os dois modelos da OpenAI chegam com preços de API significativamente menores do que seus antecessores da linha GPT-5.6, ampliando as opções para quem precisa equilibrar inteligência e eficiência em diferentes tipos de carga de trabalho.

A lógica por trás dos lançamentos parte de uma premissa simples: nem toda tarefa exige o mesmo nível de sofisticação. O valor da IA em escala depende tanto do que um modelo consegue fazer quanto da frequência com que ele pode ser acionado. Maior inteligência expande a complexidade que o modelo consegue lidar — de problemas sutis de código a processos de múltiplas etapas. Já a eficiência determina o quanto essa inteligência consegue sustentar atividades cotidianas e tarefas repetitivas, onde cada token extra, cada nova tentativa e cada segundo de latência se multiplicam ao longo das requisições.

Nesse contexto, o GPT-6 Astra já havia estabelecido o topo da família GPT-6 para os projetos mais ambiciosos, onde a qualidade do resultado importa mais do que o custo. O GPT-6 Sol e o GPT-6 Luna vêm para cobrir o restante do espectro.

GPT-6 Sol: raciocínio avançado para tarefas complexas do dia a dia

O GPT-6 Sol foi projetado para demandas recorrentes ao longo do ciclo de desenvolvimento e operações. Entre as capacidades destacadas pela AWS, o modelo consegue implementar funcionalidades, depurar problemas, refatorar e revisar código, analisar dados e executar processos de múltiplas etapas entre ferramentas e aplicações.

Em relação ao GPT-5.6 Sol, o modelo traz melhorias em codificação e uso de computador, o que permite conduzir uma tarefa desde a investigação até a implementação e validação, preservando o contexto por trás das decisões tomadas. Isso é especialmente relevante para equipes que precisam entender o que foi alterado, o que foi verificado e o que ainda não pôde ser confirmado pelo modelo.

Em uma avaliação interna de factualidade conduzida pela OpenAI, o GPT-6 Sol cometeu aproximadamente metade dos erros factuais do GPT-5.6 Sol. Além disso, o modelo foi aprimorado para se comunicar com mais clareza sobre seu trabalho e resultados, ajudando as equipes a identificar lacunas mais rapidamente e a entender onde o julgamento humano ainda é necessário.

A medida mais relevante para avaliar o GPT-6 Sol no dia a dia é o custo total para se chegar a um resultado utilizável — levando em conta qualidade da saída, uso de tokens, novas tentativas e latência.

GPT-6 Luna: eficiência para tarefas focadas em alto volume

Quando uma tarefa é executada milhares de vezes por dia, a economia de cada chamada determina se o fluxo de trabalho escala. Uma única classificação ou resumo pode ser barato por si só, mas o custo de extração, roteamento e acompanhamento ao longo de um pipeline completo de documentos se acumula a cada requisição adicional.

O GPT-6 Luna foi desenvolvido exatamente para esse tipo de carga. A AWS descreve casos de uso como extração de informações de grandes coleções de documentos, resumo de materiais recebidos, classificação de entradas e resposta a perguntas objetivas em múltiplos usuários ou aplicações.

As avaliações da OpenAI apontam melhorias na confiabilidade factual do GPT-6 Luna e maior clareza na comunicação de resultados. O modelo também permite ajustar o esforço de raciocínio por requisição, equilibrando qualidade, responsividade e custo conforme a necessidade de cada tarefa.

Combinando os modelos conforme a etapa do processo

Uma das estratégias mais interessantes apresentadas no anúncio é a possibilidade de combinar os três modelos da família GPT-6 dentro de uma mesma aplicação, sem precisar reconstruir o contexto a cada etapa. O GPT-6 Luna pode classificar as requisições de entrada, o GPT-6 Sol pode investigar os casos mais complexos, e o GPT-6 Astra pode ser acionado quando uma profundidade adicional de raciocínio pode mudar materialmente uma decisão.

Essa abordagem concentra a inteligência onde ela gera mais valor, gerenciando latência e custo ao longo do sistema.

Cache de prompt no Amazon Bedrock

Dentro de cada etapa, chamadas repetidas ao mesmo modelo frequentemente reutilizam instruções, definições de ferramentas, políticas e materiais de referência. Reprocessar esse contexto a cada vez pode corroer a eficiência conquistada ao escolher o modelo adequado.

Para resolver isso, o GPT-6 Sol e o GPT-6 Luna oferecem suporte a cache explícito de prompt no Amazon Bedrock. É possível marcar conteúdo do prompt para reutilização, permitindo que as requisições subsequentes foquem apenas no processamento do novo conteúdo. Isso é útil em assistentes de código que reutilizam instruções de repositório, aplicações de suporte baseadas nas mesmas políticas e processos de documentos que aplicam um esquema de extração consistente.

Segurança e controle em escala

À medida que o uso de IA cresce, a qualidade do modelo é apenas parte do que determina o sucesso de uma aplicação em produção. As equipes também precisam de infraestrutura que mantenha desempenho conforme a demanda cresce, de uma economia que se sustente em requisições repetidas e de controles que protejam dados sensíveis.

O Amazon Bedrock oferece essa base para o GPT-6 Sol e o GPT-6 Luna por meio de um motor de inferência de alto desempenho, construído para segurança e confiabilidade em escala. Entre os recursos disponíveis:

• Controle de acesso aos modelos via políticas do Gerenciamento de Identidade e Acesso da AWS (IAM — Identity and Access Management)
• Auditoria de cada invocação pelo AWS CloudTrail
• Endpoints de Nuvem Privada Virtual (VPC — Virtual Private Cloud) com AWS PrivateLink para manter o tráfego dentro dos limites da rede
• Inferência em infraestrutura com isolamento de hardware e acesso zero por operadores — nem os operadores da AWS conseguem acessar prompts ou respostas durante a inferência

Os dados de inferência não são usados para treinamento de modelos, e o uso do GPT-6 Sol e do GPT-6 Luna não exige que o cliente opte por compartilhar seus dados com a OpenAI. Para detecção automatizada de abuso, o tráfego sinalizado por classificadores é retido pela AWS por até 30 dias e processado de forma programática. É possível solicitar retenção zero de dados junto à equipe de conta AWS. Consulte a documentação de retenção de dados para mais detalhes.

Como começar

O GPT-6 Sol e o GPT-6 Luna já estão disponíveis no console do Amazon Bedrock ou de forma programática pelas APIs suportadas do Amazon Bedrock. Para informações sobre regiões da AWS suportadas, endpoints, APIs, funcionalidades, perfis de inferência e preços, consulte a documentação do Amazon Bedrock. Para equipes interessadas em entender como o Amazon Bedrock pode apoiar seus projetos, a AWS disponibiliza um canal de contato direto — entre em contato para iniciar a conversa.

Fonte

Bring more intelligence to everyday work with GPT-6 Sol and GPT-6 Luna on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/bring-more-intelligence-to-everyday-work-with-gpt-6-sol-and-gpt-6-luna-on-amazon-bedrock/)

Positron no SageMaker AI: um IDE completo para ciência de dados na nuvem

Equipes de ciência de dados frequentemente precisam alternar entre ferramentas distintas para acessar dados, analisar em R, desenvolver modelos em Python, fazer deploy, criar aplicações e gerar relatórios. A Posit resolveu parte desse problema com o Positron, seu IDE voltado para ciência de dados — e agora esse ambiente pode rodar diretamente no Amazon SageMaker AI.

A integração traz benefícios práticos que vale entender com cuidado, especialmente para times que já trabalham com o ecossistema AWS.

O que muda para o cientista de dados

Ao rodar o Positron dentro de um Space do SageMaker AI, o cientista de dados ganha quatro vantagens imediatas:

• Acesso a dados sem gerenciar credenciais: o Positron opera sob o papel de execução (execution role) do Space, o que permite consultar o Amazon Athena, o AWS Glue Data Catalog e o Amazon Simple Storage Service (S3) diretamente do IDE, sem necessidade de armazenar ou rotacionar chaves.
• Computação disponível quando necessário: basta lançar um Space no tamanho de instância adequado. Times podem reservar capacidade com os planos de treinamento do SageMaker AI para garantir disponibilidade em treinos agendados.
• Assistência de IA dentro da própria conta AWS: o Posit Assistant, assistente de codificação por IA da Posit, pode usar o Amazon Bedrock como provedor de modelos. Isso significa que toda a ajuda de IA roda em modelos dentro da própria conta e região AWS do cliente.
• Trabalho paralelo e colaborativo: é possível rodar múltiplos Spaces simultaneamente para projetos independentes, ou usar um Space compartilhado para que várias pessoas colaborem na mesma aplicação Positron.

Como a imagem é disponibilizada

A Posit publica uma definição de imagem de container para o Positron, construída sobre a imagem Amazon SageMaker Distribution. O fluxo de configuração envolve dois perfis distintos: o administrador de plataforma e o cientista de dados.

O administrador constrói a imagem a partir da definição publicada pela Posit (o Containerfile do Positron para SageMaker), envia para um repositório privado no Amazon Elastic Container Registry (ECR), registra a imagem no SageMaker AI e a associa a um domínio do Studio. A partir daí, o cientista de dados simplesmente escolhe o Positron ao criar um Space e abre o IDE diretamente no Studio.

Pré-requisitos para usar o Positron no SageMaker AI

Para seguir esse caminho, uma organização precisa ter:

• Uma licença da Posit e acesso à definição de imagem publicada pela empresa;
• Permissões de administrador para gerenciar o Amazon ECR e configurar imagens customizadas no domínio do Amazon SageMaker Studio;
• Um papel de execução do Space com acesso ao Amazon Athena e ao AWS Glue Data Catalog;
• Um bucket no Amazon S3 como fonte de dados e um local configurado para resultados de queries do Athena;
• Acesso ao Amazon Bedrock na mesma região AWS do domínio Studio, caso queira usar o Posit Assistant;
• Uma instância do tipo ml.t3.xlarge ou maior para o ambiente demonstrado.

O fluxo de trabalho demonstrado: do dado bruto ao endpoint em produção

A AWS publicou um walkthrough completo usando um portfólio sintético de 50.000 empréstimos. Os dados ficam armazenados no Amazon S3 e registrados no AWS Glue Data Catalog. O Amazon Athena faz as consultas, R valida as features, Python treina um classificador XGBoost, Shiny for Python invoca o endpoint e Quarto documenta todo o fluxo.

Passo 1 — Positron dentro de um Space no SageMaker Studio

O fluxo começa com o Positron aberto em um Space do SageMaker Studio. O explorador de projetos, editor, sessões R e Python, painel de variáveis, gráficos, terminal e preview de aplicações ficam disponíveis em um único ambiente baseado em navegador, rodando sobre o papel de execução do Space.

Passo 2 — Descoberta de dados governados com o Posit Assistant

A partir do mesmo Space, o Posit Assistant identificou a tabela credit_risk_blog.loan_tape_source no AWS Glue Data Catalog e preparou uma query somente leitura no Amazon Athena. A consulta retornou cinco linhas de amostra em seis campos, escaneou 2,18 MiB e completou em menos de um segundo.

Uso de tokens e cache do Amazon Bedrock

Quando o Amazon Bedrock é usado como provedor do Posit Assistant, nenhuma chave de API separada é necessária — a autenticação resolve pelas credenciais AWS do ambiente. O conteúdo do cliente é criptografado, não é usado para melhorar os modelos base e não é compartilhado com provedores de modelos (veja a documentação de proteção de dados do Amazon Bedrock). Conectividade privada pode ser configurada com AWS PrivateLink.

Na sessão registrada, o Posit Assistant acumulou 6.657.942 tokens no total, sendo 6.118.411 de leitura de cache e 462.905 de escrita de cache, com custo estimado de US$ 6,319 e eficiência de cache de 92,5%. Esses valores descrevem aquela sessão específica e a estimativa do assistente — não representam uma fatura AWS nem um benchmark geral de custo. O comportamento do cache e os preços variam conforme o modelo e o provedor selecionados.

Passo 3 — Perfilamento de dados no Amazon Athena

Uma query agregada no Athena examinou contagem de linhas, unicidade de identificadores, valores ausentes, faixas numéricas e validade do target. Os resultados identificaram 50.000 empréstimos, incluindo 1.500 registros com renda ausente e 1.015 inadimplências, resultando em uma taxa geral de inadimplência de 2,03%.

Passo 4 — Exploração interativa de dados em R

A tabela completa de 50.000 linhas foi carregada na sessão R ativa e aberta no Data Explorer. O R criou as features de relação dívida/renda e log-renda, e exibiu a distribuição da relação dívida/renda no painel de gráficos. Após excluir os 1.500 registros incompletos, restaram 48.500 empréstimos para modelagem e scoring.

Passo 5 — Validação de features e treinamento do modelo em Python

As definições de features validadas em R foram então transferidas para Python. Um classificador XGBoost foi treinado em uma matriz com 40.000 linhas e três features do modelo. A avaliação no conjunto de holdout produziu uma Área Sob a Curva (AUC) de 0,834 e mostrou uma taxa de inadimplência observada de 12,3% no decil de maior risco.

Passo 6 — Deploy gerenciado com o SageMaker AI

O fluxo gravou as probabilidades previstas e os decis de risco para 48.500 empréstimos em formato Parquet e registrou os resultados como credit_risk_blog.scored_loans no Athena. Em seguida, criou um modelo no SageMaker AI, uma configuração de endpoint e um endpoint de inferência em tempo real. O endpoint atingiu o status InService e uma invocação com payload sintético foi realizada com sucesso.

Passo 7 — Inferência em tempo real com aplicação Shiny for Python

Uma aplicação Shiny for Python foi usada para invocar o endpoint implantado. A aplicação aceita informações sintéticas do solicitante, aplica as definições de features usadas no treinamento e exibe a probabilidade de inadimplência retornada. O código-fonte e a aplicação em execução permanecem no mesmo projeto Positron, que roda por trás do proxy do Amazon SageMaker Studio e é acessível apenas por usuários autenticados no Space. A invocação ao endpoint ocorre sob o papel de execução do Space — não por nenhuma chave armazenada — e o papel é limitado a sagemaker:InvokeEndpoint no ARN do endpoint.

Passo 8 — Relatório reproduzível com Quarto

O fluxo foi concluído com um relatório Quarto que conectou a fonte no Athena, os achados de qualidade de dados, a validação em R, o modelo Python, o output com scoring, o endpoint do SageMaker AI e a aplicação Shiny. O relatório foi gerado diretamente do projeto, preservando as evidências e resultados do fluxo em um único documento reproduzível.

Arquitetura de deploy: dois caminhos distintos

O deploy envolve dois caminhos separados: o caminho do administrador, que constrói e registra a imagem customizada do Positron, e o caminho do cientista de dados, que usa essa imagem para analisar dados e fazer deploy de modelos.

Caminho do administrador

O administrador constrói a definição de imagem publicada pela Posit a partir do Containerfile do Positron para SageMaker, que se baseia na imagem SageMaker Distribution. Em seguida, envia a imagem para um repositório privado no Amazon ECR na região do domínio Studio, registra uma imagem e versão no SageMaker AI, cria uma configuração de imagem para o app JupyterLab, verifica o licenciamento, concede ao papel de execução as permissões necessárias e associa a imagem ao domínio.

O Amazon Bedrock é opcional e só entra em cena quando selecionado como provedor do Posit Assistant. As responsabilidades ficam bem separadas: a Posit fornece a imagem de software e o suporte ao produto; o cliente gerencia identidade, permissões, licenciamento, rede, logs, atualizações de imagem e os serviços AWS aprovados; a AWS opera os serviços gerenciados de nuvem.

Caminho do cientista de dados

O cientista de dados lança o JupyterLab em um Space do SageMaker Studio, abre o Positron e usa R, Python, Quarto, Posit Database Drivers e, opcionalmente, o Posit Assistant para consultar e analisar dados e fazer deploy de modelos.

O que o fluxo registrado demonstrou

O walkthrough documentado pela AWS demonstrou as seguintes capacidades dentro de um único Space Positron:

• Acesso governado a dados: descoberta, amostragem e perfilamento no Athena a partir do Space configurado;
• Análise multi-linguagem: R validou os dados e as features antes de Python treinar o modelo;
• Comportamento do modelo medido: AUC de holdout de 0,834 e taxa de inadimplência observada de 12,3% no decil de maior risco;
• Deploy gerenciado: 48.500 linhas com scoring registradas no Athena e endpoint em tempo real com status InService;
• Outputs conectados: aplicação Shiny em execução e relatório Quarto produzidos a partir do mesmo projeto.

Escopo e limitações importantes

Vale deixar claro: o dataset e os payloads de solicitantes são sintéticos. O fluxo não estabelece justiça do modelo, calibração, adequação para concessão de crédito real, latência em produção, comportamento sob carga, monitoramento ou conformidade regulatória. A AUC e os resultados por decil vêm de uma única divisão de holdout, e os decis inferiores não foram estritamente monotônicos.

A adoção em produção exige validar os termos de preview da Posit, a licença e a versão da imagem, além das regiões AWS suportadas e a disponibilidade dos modelos. As equipes também precisam confirmar o design de rede, permissões de menor privilégio, gestão de segredos, logging, patching de imagens e responsabilidade operacional.

Limpeza dos recursos

Para evitar cobranças contínuas, os recursos criados no walkthrough devem ser removidos na seguinte ordem (o endpoint em tempo real depende da configuração de endpoint e do modelo, portanto deve ser excluído primeiro):

• Excluir o endpoint de inferência em tempo real;
• Excluir a configuração do endpoint;
• Excluir o modelo;
• Excluir os objetos de saída de query no Amazon S3 e remover a tabela no Athena;
• Excluir a versão da imagem no Amazon ECR;
• Excluir o registro da imagem no SageMaker AI;
• Parar e excluir os Spaces de teste que não estejam mais em uso (faça backup dos arquivos do projeto antes).

Recursos relacionados

• Guia de configuração do Positron no SageMaker
• Posit Assistant
• Executar IDEs interativos no Amazon EKS com SageMaker AI para potencializar fluxos de trabalho de IA
• Documentação do Amazon SageMaker Studio
• Guia do usuário do Amazon ECR
• Imagem Docker do Positron
• Guia do usuário do AWS License Manager

Fonte

Run Positron on Amazon SageMaker AI for data science workflows (https://aws.amazon.com/blogs/machine-learning/run-positron-on-amazon-sagemaker-ai-for-data-science-workflows/)

Grok 4.6 da xAI chega ao Amazon Bedrock

A AWS anunciou a disponibilidade do Grok 4.6, da xAI, no Amazon Bedrock, adicionando ao catálogo um modelo de fronteira projetado para agentes de longa duração, codificação e trabalho intensivo em conhecimento. O modelo foi disponibilizado em 18 de agosto de 2026 e oferece uma janela de contexto de 500K tokens, com suporte a quatro níveis configuráveis de esforço de raciocínio: low, medium, high e xhigh.

Este é o segundo modelo da xAI no Amazon Bedrock. Quando o Grok 4.3 ficou disponível para todos, a xAI entrou como provedora de modelos na plataforma e o modelo era acessível pelo Bedrock Mantle, o mecanismo de inferência compatível com a OpenAI. O Grok 4.6 expande consideravelmente essa superfície: ele está disponível tanto no endpoint bedrock-mantle quanto no bedrock-runtime, e suporta a Converse API além das APIs Chat Completions e Responses.

Para que o Grok 4.6 foi construído

As informações de capacidade e treinamento desta seção têm como base o anúncio de lançamento da xAI, Introducing Grok 4.6.

O Grok 4.6 evolui a partir do Grok 4.5 com foco especial em agentes de longa duração e trabalhos interativos e visuais mais ambiciosos. A xAI descreve o modelo como capaz de se manter em tarefas complexas ao longo de muitas etapas — seja pesquisando um tema, analisando informações, trabalhando em uma base de código ou transformando uma ideia em uma aplicação finalizada.

No treinamento, a xAI relata um ciclo de treinamento suplementar mais longo do que o do Grok 4.5, usando dados gerados pelo próprio modelo para raciocínio e conceitos técnicos avançados, dados de engenharia de alta qualidade e um otimizador aprimorado. O modelo foi então treinado em uma ampla gama de tarefas de Aprendizado por Reforço (RL) agentico, cobrindo trabalho de conhecimento, codificação geral e ambientes específicos como otimização de kernel, desenvolvimento web e projeto assistido por computador.

Dois comportamentos chamados pela xAI merecem atenção para quem constrói agentes. Em trajetórias mais longas, o modelo passou a demonstrar mais autoverificação — checando o próprio trabalho antes de avançar. Ele também produz primeiras versões mais sólidas em projetos visuais e interativos, estabelecendo a estrutura e a linguagem visual de uma aplicação em uma única passagem.

Em segurança, a xAI afirma que as salvaguardas do Grok 4.6 foram aprimoradas, respaldadas pelo que descreve como o mais amplo conjunto de testes pré-implantação já realizado, além de testes pós-implantação e por terceiros.

Resultados de benchmarks reportados

A xAI reporta que o Grok 4.6 alcança inteligência de fronteira em vários benchmarks de codificação agentica e trabalho de conhecimento. Os números publicados para o Grok 4.6 High em seu lançamento em 12 de agosto de 2026 foram:

• AA Intelligence Index: 61
• GDPVal-AA v2: 1753
• CursorBench v3.2: 69,9%
• DeepSWE v1.1: 65,9%
• FrontierCode v1.1 (Extended): 61,3%
• APEX-Agents: 57,5%
• Terminal-Bench v3.0: 26%
• APEX-SWE: 56,4%
• AA-Briefcase: 1577
• Harvey LAB (Vals): 15,8%

Fonte: xAI, conforme https://x.ai/news/grok-4-6.

Várias dessas avaliações são da Artificial Analysis. O Artificial Analysis Intelligence Index v4.1.1 é um índice composto que incorpora nove avaliações cobrindo uso agentico de ferramentas, raciocínio e conhecimento, confiabilidade de conhecimento, raciocínio em contexto longo e análise quantitativa sobre planilhas e documentos. O AA-Briefcase é o benchmark de trabalho de conhecimento agentico da Artificial Analysis. A organização também rastreia custo e latência junto à inteligência, com uma métrica de custo por tarefa útil para dimensionar cargas de trabalho com raciocínio intensivo.

O que o Grok 4.6 adiciona no Bedrock

Diversas capacidades do Bedrock são novidade para este modelo em relação ao lançamento anterior do Grok. Veja os destaques:

• Endpoint bedrock-runtime: O Grok 4.6 é servido no bedrock-runtime além do bedrock-mantle, permitindo o uso com os SDKs da AWS e a superfície de controle padrão do Bedrock.
• Converse API com streaming: Tanto converse quanto converse_stream estão disponíveis, com os eventos padrão do Converse (messageStart, contentBlockDelta, contentBlockStop, messageStop, metadata).
• Nível de esforço xhigh: O esforço agora vai de low (padrão), medium, high até xhigh, estendendo o topo para problemas que justificam uma passagem mais profunda. No Converse, configure via additionalModelRequestFields={"reasoning_effort": "xhigh"}.
• Inferência entre regiões (Cross-Region inference): No bedrock-runtime, o tráfego é roteado por perfis de inferência: us.xai.grok-4.6 mantém o tráfego dentro da geografia dos EUA para requisitos de residência de dados, enquanto global.xai.grok-4.6 roteia globalmente para o maior pool de capacidade — e é também a opção mais barata, a $2,00 por milhão de tokens de entrada contra $2,20.
• Amazon Bedrock Guardrails: O Grok 4.6 agora suporta Guardrails no bedrock-runtime, oferecendo filtros de conteúdo, tópicos negados, redação de Informações de Identificação Pessoal (PII) e políticas de palavras. Para cargas agenticas, isso é relevante porque estabelece um limite de política consistente em torno de um modelo que pode rodar sem supervisão por muitas etapas.
• Log de invocação: Com o log de invocação de modelos habilitado, as chamadas ao Grok 4.6 são capturadas como registros completos no Amazon CloudWatch: corpo da requisição, corpo da resposta, contagens de tokens (incluindo tokens de raciocínio) e o perfil de inferência utilizado.
• Cache de prompt: Entradas em cache são cobradas a aproximadamente um quarto da taxa de entrada padrão — relevante para agentes que reenviam um sistema de prompt ou documento grande a cada turno. Mantenha o conteúdo estável no início da requisição e verifique a contagem de tokens em cache no bloco de uso para confirmar o desconto antes de incorporá-lo ao modelo de custo.

Chamada de ferramentas (tool calling), saída estruturada, entrada de imagem, streaming de resposta e conteúdo de raciocínio criptografado também estão disponíveis, mas datam do lançamento do Grok 4.3.

Como o Grok 4.6 é empacotado no Amazon Bedrock

O Grok 4.6 aceita entrada de texto e imagem e retorna texto. Áudio, fala, vídeo e modalidades de embedding não são suportados, e o modelo não gera imagens.

O modelo é acessível por dois endpoints, com IDs de modelo diferentes dependendo de qual é usado:

• bedrock-mantle: ID do modelo xai.grok-4.6 — URL base: https://bedrock-mantle.{region}.api.aws/openai/v1
• bedrock-runtime: ID do modelo us.xai.grok-4.6 (Geo) ou global.xai.grok-4.6 (Global) — URL base: https://bedrock-runtime.{region}.amazonaws.com/openai/v1

O suporte a funcionalidades difere por endpoint. No bedrock-mantle, são suportados: chamada de ferramentas no lado do cliente, raciocínio, saídas estruturadas (JSON Schema), cache de prompt, streaming de resposta, projetos e detecção de abuso. No bedrock-runtime, são suportados: raciocínio, cache de prompt, streaming de resposta, logs de invocação e projetos (apenas projeto padrão). Saídas estruturadas, uso de ferramentas no servidor, roteamento inteligente de prompt, contagem de tokens e perfis de inferência de aplicação não são suportados nesse endpoint.

A chamada de ferramentas funciona em ambos os endpoints. Se sua aplicação depende de saída estruturada via JSON Schema, o bedrock-mantle é a escolha. Se você precisa da Converse API ou de logs de invocação, o bedrock-runtime é o caminho.

Regiões e opções de inferência

No bedrock-mantle, o Grok 4.6 está disponível para inferência na região US West (Oregon) (us-west-2). No bedrock-runtime, a inferência dentro da região não é oferecida — em vez disso, o modelo é invocado por perfis de inferência entre regiões. A inferência Geo está disponível nas regiões dos EUA (us-east-1, us-east-2, us-west-1 e us-west-2), e a inferência Global está disponível em mais de 30 regiões cobrindo EUA, Canadá, Europa, Ásia-Pacífico, Oriente Médio, África e América do Sul. Consulte o model card e a página de disponibilidade regional por modelo para a lista atualizada antes de fixar uma região.

Esta é uma mudança em relação ao lançamento do Grok 4.3, onde, conforme documentado no post do Grok 4.3, o modelo usava apenas inferência dentro da região e as opções Geo e Global de inferência entre regiões não eram oferecidas.

Camadas de serviço e preços

O Grok 4.6 suporta três camadas de serviço. Standard é pago por token sem compromisso, selecionado com "service_tier": "default" ou omitindo o campo. Priority entrega processamento mais rápido e priorizado por um valor adicional ("service_tier": "priority"). Flex oferece acesso de menor custo para trabalhos não urgentes ("service_tier": "flex").

Para os preços por token em cada camada, consulte a página de preços do Amazon Bedrock. As outras duas camadas são precificadas como multiplicadores das taxas Standard: Priority a 1,75x (75% de acréscimo) e Flex a 0,5x (50% de desconto). Assim, a mesma carga que custa $2,20 por milhão de tokens de entrada no Standard roda a $3,85 no Priority e $1,10 no Flex — o que torna a escolha da camada uma alavanca de custo maior do que a escolha da região. Para referência, a xAI lista os preços do Grok 4.6 a partir de $2 por milhão de tokens de entrada e $6 por milhão de tokens de saída. Sempre confirme as taxas atuais na página de preços do Amazon Bedrock, pois preços e camadas podem mudar.

Enviando sua primeira requisição

Antes da primeira chamada, confirme que o modelo está disponível para você no console do Bedrock na região que pretende usar. O Grok 4.6 é servido por perfis de inferência, e não por throughput sob demanda no ID base do modelo — por isso as requisições usam us.xai.grok-4.6 ou global.xai.grok-4.6 no bedrock-runtime.

O Grok 4.6 usa APIs compatíveis com a OpenAI, então o SDK da OpenAI funciona em qualquer um dos endpoints após configurar a URL base. Instale o SDK e o boto3 se planeja usar a Converse API:

pip install openai
pip install boto3

Gere uma chave de API de longa duração do Amazon Bedrock no console para exploração e configure seu ambiente. Para o bedrock-mantle:

export OPENAI_API_KEY="<provide your Bedrock API key>"
export OPENAI_BASE_URL="https://bedrock-mantle.us-west-2.api.aws/openai/v1"

Para o bedrock-runtime:

export OPENAI_API_KEY="<provide your Bedrock API key>"
export OPENAI_BASE_URL="https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1"

Uma primeira requisição no bedrock-mantle com a Chat Completions API:

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="xai.grok-4.6",
    messages=[
        {"role": "user", "content": "Can you explain the features of Amazon Bedrock?"}
    ],
)

print(response)

No bedrock-runtime, a diferença é o nome do modelo — você passa um perfil de inferência entre regiões em vez do ID base. Este exemplo usa a Responses API:

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="us.xai.grok-4.6",
    input="Can you explain the features of Amazon Bedrock?",
)

print(response)

E pela Converse API com boto3. Como o raciocínio está ativo, o primeiro bloco de conteúdo carrega o raciocínio e a resposta fica em um bloco posterior — por isso, percorra os blocos em busca do texto em vez de indexar content[0]:

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

response = client.converse(
    modelId="us.xai.grok-4.6",
    messages=[
        {"role": "user", "content": [{"text": "Can you explain the features of Amazon Bedrock?"}]}
    ],
    inferenceConfig={"maxTokens": 2048},
)

blocks = response["output"]["message"]["content"]
text = next(b["text"] for b in blocks if "text" in b)
print(text)

No Converse, configure o nível de esforço via additionalModelRequestFields, e não por um parâmetro reasoning:

response = client.converse(
    modelId="us.xai.grok-4.6",
    messages=[{"role": "user", "content": [{"text": "What is 17*23? Number only."}]}],
    inferenceConfig={"maxTokens": 3000},
    additionalModelRequestFields={"reasoning_effort": "xhigh"},
)

Três notas operacionais importantes

Primeiro, no bedrock-runtime, o Grok 4.6 não está disponível para inferência dentro da região, então as requisições devem usar us.xai.grok-4.6 ou global.xai.grok-4.6.

Segundo, o bedrock:InvokeModel é avaliado contra três recursos: o projeto padrão da sua conta, o perfil de inferência nomeado e o modelo fundacional subjacente. O ARN do modelo fundacional usa wildcard entre regiões porque os perfis de inferência entre regiões roteiam fora da região chamadora. A autenticação por bearer token nos endpoints compatíveis com a OpenAI também requer bedrock:CallWithBearerToken, que o boto3 e o Converse não precisam:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:{region}:{account-id}:project/default",
        "arn:aws:bedrock:{region}:{account-id}:inference-profile/us.xai.grok-4.6",
        "arn:aws:bedrock:*::foundation-model/xai.grok-4.6"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "bedrock:CallWithBearerToken",
      "Resource": "*"
    }
  ]
}

Liste todos os perfis de inferência que planeja chamar. Os perfis têm escopo individual, então uma política que nomeia us.xai.grok-4.6 não cobre global.xai.grok-4.6.

Terceiro, os dois mecanismos de autenticação cobrem caminhos de código diferentes. Uma chave de API do Amazon Bedrock em OPENAI_API_KEY viaja como bearer token e autentica as chamadas compatíveis com a OpenAI em ambos os endpoints. Os exemplos com boto3 e Converse usam SigV4, baseando-se nas credenciais AWS comuns do ambiente, de um perfil ou de uma role. Configure ambos se pretende usar o Converse junto às APIs compatíveis com a OpenAI. Trate uma chave de API de longa duração como credencial apenas para exploração — para produção, use tokens de curta duração gerados a partir das suas credenciais Gerenciamento de Identidade e Acesso (IAM) com o pacote aws-bedrock-token-generator, pois eles expiram automaticamente.

Trabalhando com esforço de raciocínio

O raciocínio está ativo no Grok 4.6 por padrão, e você configura o quanto dele o modelo utiliza pelo parâmetro reasoning com low (padrão), medium, high ou xhigh. O nível xhigh é novo em relação ao que o post do Grok 4.3 documentava, onde os níveis eram none, low, medium e high.

O conteúdo de raciocínio é criptografado. Você pode recebê-lo passando include: ["reasoning.encrypted_content"] em uma requisição da Responses API e então enviá-lo de volta em turnos subsequentes para dar ao modelo seu próprio raciocínio anterior como contexto em uma conversa de múltiplos turnos. A Chat Completions API não retorna tokens de raciocínio — o raciocínio criptografado é uma funcionalidade exclusiva da Responses API:

from openai import OpenAI

client = OpenAI()
# OPENAI_BASE_URL points at the bedrock-runtime endpoint

response = client.responses.create(
    model="us.xai.grok-4.6",
    reasoning={"effort": "high"},
    include=["reasoning.encrypted_content"],
    input="Explain quantum entanglement simply.",
)

print(response.output_text)

Como o raciocínio é ativado por padrão e o esforço é configurado por requisição, o nível de esforço é um controle real de custo e latência. Execute chamadas curtas de extração e classificação com low e reserve high ou xhigh para etapas de planejamento e trajetórias longas de agentes, onde um erro inicial se multiplica. Fazer benchmark dos níveis de esforço contra sua própria carga de trabalho é a forma mais rápida de encontrar onde o raciocínio mais elevado deixa de valer o custo em tokens.

Como começar

O Grok 4.6 no Amazon Bedrock oferece um modelo construído pela xAI para agentes de longa duração e trabalho interativo ambicioso, com janela de contexto de 500K tokens, quatro níveis de esforço de raciocínio, entrada de imagem, cache de prompt e escolha entre o endpoint bedrock-mantle compatível com a OpenAI e o endpoint bedrock-runtime com suporte à Converse API e inferência entre regiões.

Para começar a construir, revise o model card do Grok 4.6 para a lista atual de regiões, matriz de funcionalidades e detalhes de parâmetros, e verifique a página de preços do Amazon Bedrock para as taxas de tokens. Se você gerou uma chave de API de longa duração do Amazon Bedrock para exploração, exclua-a do console do Amazon Bedrock quando terminar. Uma credencial que você não precisa mais apenas amplia a superfície de exposição da sua conta.

Fonte

xAI’s Grok 4.6 is now available in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/xais-grok-4-6-is-now-available-in-amazon-bedrock/)

O desafio real de colocar modelos de IA em produção

Inferência de IA generativa tem características que a tornam diferente de qualquer outro tipo de carga de trabalho em nuvem: modelos que pesam dezenas ou centenas de gigabytes, requisitos de latência medidos em tokens por segundo, cold starts que podem durar vários minutos enquanto containers e pesos são transferidos, capacidade de GPU disputada e ferramentas de monitoramento tradicionais que simplesmente não enxergam os sinais que importam em produção.

Para endereçar esses desafios, a AWS entregou 13 novos recursos no Amazon SageMaker AI ao longo de 2026, organizados em duas frentes: endpoints gerenciados (para equipes que querem que a AWS cuide da infraestrutura) e o Amazon SageMaker HyperPod Inference (para equipes que precisam de controle nativo sobre clusters de GPU dedicados via Kubernetes). Este artigo percorre cada uma dessas entregas e o que elas significam na prática.

Duas rotas para inferência em produção

Antes de entrar nos detalhes, vale entender a divisão estrutural. Os endpoints gerenciados do SageMaker são o caminho mais rápido: a AWS cuida do provisionamento de GPU, escalabilidade e monitoramento operacional. Já o HyperPod Inference é voltado para quem precisa de controle em nível de nó, frameworks personalizados e implantações híbridas ou multi-cloud baseadas em Kubernetes.

Endpoints gerenciados: sete novidades em 2026

Recomendações de inferência e benchmarking (abril de 2026)

Escolher o tipo de instância, o container de serving e as configurações de otimização para um modelo de IA generativa costumava exigir de duas a três semanas de benchmarking manual contra mais de mil combinações possíveis — expertise que a maioria das equipes não tem internamente. O recurso de recomendações de inferência automatiza esse processo de ponta a ponta.

O fluxo funciona em três etapas: primeiro, filtra o espaço de tipos de instância analisando arquitetura, tamanho e requisitos de memória do modelo; depois, aplica técnicas alinhadas ao objetivo escolhido (custo, latência ou throughput) — como especulative decoding EAGLE 3.0 para throughput, kernel tuning para latência e paralelismo tensorial baseado no tamanho do modelo; por fim, executa benchmarks com o NVIDIA AIPerf em infraestrutura GPU real, com relatórios de confiança estatisticamente rigorosos. A saída é um SageMaker Model Package com configurações prontas para deploy e métricas validadas. Em um exemplo demonstrado, a otimização de throughput no GPT-OSS-20B entregou 2x mais tokens por segundo com a mesma latência de requisição. Não há custo adicional para gerar as recomendações.

Pools de instâncias com consciência de capacidade (maio de 2026)

Quando um endpoint do SageMaker dependia de um único tipo de instância, uma escassez de capacidade significava falha total antes de servir uma única requisição. Os pools de instâncias com fallback automático eliminam esse ponto único de falha.

A equipe define uma lista priorizada de até cinco tipos de instância. O SageMaker percorre essa lista automaticamente na criação do endpoint, durante o scale-out e durante o scale-in. Na criação, tenta o tipo preferido e faz fallback imediato se não houver capacidade disponível. Durante o scale-in, as instâncias de fallback são removidas primeiro, fazendo a frota convergir de volta para o hardware preferido conforme a capacidade abre. Cada entrada na lista pode referenciar uma configuração de modelo otimizada separada — paralelismo tensorial em instâncias de alta memória, speculative decoding em instâncias intermediárias, quantização nas menores.

APIs compatíveis com OpenAI (maio de 2026)

Aplicações construídas sobre o SDK da OpenAI, LangChain ou Strands Agents precisavam de adaptadores customizados e reescritas de autenticação para funcionar com modelos hospedados no SageMaker. Esse custo de migração era uma barreira real.

Com o suporte a APIs compatíveis com OpenAI, os endpoints do SageMaker passam a expor um caminho /openai/v1 com suporte a Chat Completions com streaming. A migração exige apenas a troca da URL do endpoint — chamadas ao SDK, lógica de streaming e formatação de prompts permanecem idênticas. A autenticação usa bearer tokens gerados a partir das credenciais AWS existentes, válidos por até 12 horas, eliminando a complexidade da assinatura SigV4. Disponível em 14 regiões AWS.

Cache de container (junho de 2026)

Durante eventos de auto scaling, novas instâncias precisavam baixar a imagem completa do container do Amazon ECR antes de servir requisições. Para containers grandes acima de 10 GB, esse pull sozinho adicionava vários minutos de tempo morto a cada evento de scale-out.

O container caching pré-carrega imagens automaticamente, de forma que novas instâncias iniciem com o container já disponível localmente — sem configuração, sem alterações de código, sem modificações no container. Com o Qwen3-8B em ml.g6.2xlarge usando o container LMI (17,7 GB comprimido), a latência de inicialização de ponta a ponta caiu de 525 segundos para 258 segundos, uma redução de 51%. Clientes em acesso antecipado observaram melhorias entre 38% e 65%.

Observabilidade e dashboard de insights no CloudWatch (junho de 2026)

Latência em nível de token, pressão no cache KV, tendências de memória GPU e distribuição de componentes de inferência entre Zonas de Disponibilidade são sinais que métricas espalhadas no CloudWatch não conseguiam surfaçar juntos, forçando equipes a correlacionar problemas manualmente — depois que os usuários já haviam sido impactados.

O SageMaker passou a emitir mais de 100 métricas detalhadas de inferência via OpenTelemetry nativo, com um dashboard pré-construído no Amazon CloudWatch. Zero instrumentação necessária. Novos endpoints têm observabilidade habilitada por padrão, com métricas fluindo dentro de dois minutos após atingir o status InService. O dashboard cobre desempenho (Tempo para Primeiro Token — TTFT, Latência Inter-Token — ITL, throughput, utilização do cache KV), capacidade (GPU, memória, temperatura) e confiabilidade (distribuição por Zona de Disponibilidade, anatomia de cold starts e histórico de eventos de scaling).

Payloads inline para inferência assíncrona (junho de 2026)

A inferência assíncrona exigia que cada payload de entrada fosse carregado no Amazon S3 antes de invocar o endpoint — mesmo para um prompt JSON simples de algumas centenas de bytes, adicionando complexidade arquitetural e latência em cada requisição.

Com o suporte a payloads inline, a API InvokeEndpointAsync agora aceita um parâmetro Body com payloads de até 128.000 bytes diretamente na requisição, eliminando o pré-staging no S3 para a grande maioria das cargas de trabalho assíncronas. Totalmente compatível com versões anteriores. Disponível em 31 regiões AWS.

Roteamento com consciência de prefixo (setembro de 2026)

Em muitas aplicações de LLM (Modelo de Linguagem de Grande Escala), uma parte significativa do prompt — instruções de sistema, documentos recuperados, histórico de conversa — se repete entre requisições. Normalmente, cada instância recomputa esses tokens compartilhados do zero, desperdiçando recursos de GPU.

O roteamento com consciência de prefixo resolve isso usando o início de cada requisição como uma impressão digital para direcionar prompts similares à mesma instância, maximizando o reuso do cache KV. Benchmarks no Llama 3.1 70B em 7 instâncias mostraram ganhos expressivos: para cargas de contexto longo (prefixos de 8.000 tokens), o P90 do TTFT caiu 33–37%, o P50 do TTFT caiu 71–77%, e as taxas de acerto no cache KV saltaram de ~25% para 82%. O overhead de roteamento é mínimo: apenas 1,3–1,9 milissegundos por requisição. O recurso é ideal para aplicações de RAG (Geração Aumentada por Recuperação), conversas com múltiplos turnos, bots com templates e cenários de completação de código.

HyperPod Inference: seis novidades para clusters Kubernetes

Operador de inferência simplificado no EKS (abril de 2026)

Implantar um LLM no Kubernetes normalmente exige escrever e manter Deployments, Services, ConfigMaps, configurações de HorizontalPodAutoscaler e health checks para cada modelo. Para equipes gerenciando dezenas de modelos, essa infraestrutura artesanal vira um fardo de engenharia por si só.

O Operador de Inferência Simplificado é um add-on nativo do EKS (Elastic Kubernetes Service) que se instala em um único passo. Uma vez instalado, equipes implantam modelos submetendo uma única definição de recurso customizado em vez de uma pilha de objetos Kubernetes de baixo nível. Inclui fallback para múltiplos tipos de instância em ordem de prioridade, autoscaling nativo com CloudWatch, Amazon Managed Service for Prometheus e KEDA (Kubernetes Event-driven Autoscaling), além de integração direta com o SageMaker JumpStart.

Cache KV em camadas gerenciado e roteamento inteligente

Para cargas de contexto longo e múltiplos turnos, LLMs recomputam valores de atenção chave-valor para prefixos compartilhados em cada requisição. Sem cache, essa computação redundante se acumula diretamente como latência e custo de GPU.

O cache KV em camadas gerenciado opera em dois níveis: a camada L1 fica na memória CPU de cada nó para reuso local de baixa latência; a camada L2 usa Redis para compartilhamento entre nós, de forma que um prefixo em cache computado por um pod possa ser reutilizado por outros pods da frota. O roteamento inteligente mantém o cache eficiente direcionando requisições para as instâncias com maior probabilidade de acerto — seja por consciência de prefixo, por estado real do cache (KV-aware) ou por round-robin para cargas onde reuso não é prioridade. Juntos, cache em camadas e roteamento inteligente entregam até 40% de redução de latência para cargas de contexto longo e múltiplos turnos.

Captura de dados (maio de 2026)

Empresas reguladas precisam de logs à prova de adulteração da atividade de inferência para conformidade, monitoramento de drift e construção de conjuntos de dados de avaliação offline. Construir essa infraestrutura de logging do zero é complexo.

O data capture do HyperPod Inference oferece três pontos de captura habilitados via definição de recurso customizado (CRD): o endpoint SageMaker (requisição e resposta completas na fronteira da aplicação), o ALB (Application Load Balancer — balanceador de carga da aplicação, para visibilidade de roteamento e medição de latência) e o pod do modelo (requisição e resposta na fronteira do container para debugging em nível de modelo). Os dados capturados fluem para o Amazon S3 sem necessidade de containers sidecar customizados ou instrumentação da aplicação.

Prefill e decode disagregados (julho de 2026)

Quando prefill e decode compartilham o mesmo pool de GPU, um prefill longo para um prompt complexo bloqueia a geração de tokens para todos os usuários concorrentes na fila. Sob tráfego misto, isso torna a latência por token imprevisível em proporção à complexidade da requisição.

O Prefill e Decode Disagregado (DPD), entregue no Inference Operator v3.2, separa essas fases em pools de GPU distintos. As GPUs de prefill processam o prompt. Uma vez que o cache KV de uma requisição está pronto, ele é transferido para o pool de decode via EFA (Elastic Fabric Adapter) usando GPU-Direct RDMA (Acesso Direto à Memória Remota via GPU), uma transferência direta de memória que contorna completamente a CPU. As GPUs de decode então geram tokens de saída sem interferência do trabalho de prefill. Cada pool escala de forma independente.

Validado no Llama 3.3 70B sob tráfego misto, o DPD produziu distribuições de TTFT e ITL (Latência Inter-Token) visivelmente mais consistentes em comparação com prefill e decode colocalizados. Os operadores especificam pools de instâncias separados para nós de prefill e decode no CRD; o Inference Operator gerencia a configuração do EFA e a transferência do cache KV automaticamente. Saiba mais em Prefill e decode disagregados para inferência de LLM no SageMaker HyperPod.

Recursos de desempenho com Hugging Face, NVMe e Route 53 (julho de 2026)

Um conjunto de melhorias de desempenho e flexibilidade para inferência enterprise no HyperPod foi entregue em julho: integração com o Hugging Face Hub para deploy direto de modelos sem precisar pré-posicionar pesos no S3 (com suporte a modelos com acesso restrito, fixação de revisão e isolamento de tokens); carregamento de modelos via NVMe local para reduzir latência de cold start lendo pesos do armazenamento do nó em vez de baixar pela rede; gerenciamento automático de DNS via Amazon Route 53 para domínios de inferência customizados através de configuração simples no CRD; e contas de serviço customizadas com IRSA (IAM Roles for Service Accounts — Papéis IAM para Contas de Serviço) para permissões IAM em nível de pod.

Cache de modelo no HyperPod (setembro de 2026)

Ao implantar LLMs no HyperPod, cold starts criam atrasos significativos enquanto pods precisam baixar pesos do modelo de armazenamento remoto e puxar imagens de container do ECR antes de servir requisições. O problema se agrava durante eventos de scale-out quando múltiplos pods iniciam simultaneamente.

O model caching do HyperPod endereça isso com dois mecanismos complementares: um cache de pesos que pré-baixa os pesos do modelo para armazenamento NVMe local em cada nó, habilitando leituras a aproximadamente 7 GB/s em vez de aguardar downloads remotos; e um cache de imagens que pré-carrega imagens de container de inferência nos nós via DaemonSet, economizando de 5 a 7 minutos por inicialização de pod. Ambos os caches usam agendamento preferencial (não obrigatório), de forma que pods ainda possam iniciar em nós sem cache com fallback gracioso. Benchmarks mostram cerca de 60% de aceleração no scale-out para modelos entre 57 GB e 145 GB. O recurso está geralmente disponível em todas as regiões suportadas pelo HyperPod.

O valor combinado das 13 entregas

Cada um desses lançamentos endereça um ponto de atrito distinto no ciclo de vida de inferência — da primeira decisão de deploy às operações em produção. A vantagem competitiva em inferência de IA cada vez mais vem não de escolher o melhor modelo, mas de operar o stack de inferência mais eficiente. A AWS disponibiliza toda a documentação e guias de início rápido no Amazon SageMaker Developer Guide.

Referências

• Recomendações de Inferência de IA Generativa Otimizada
• Inferência com Consciência de Capacidade: Fallback Automático de Instâncias para Endpoints SageMaker AI
• Suporte a APIs Compatíveis com OpenAI para Endpoints Amazon SageMaker AI
• Container Caching no Amazon SageMaker AI para Scaling Mais Rápido de Modelos
• Monitoramento e Debug de Inferência de IA Generativa com Dashboard no CloudWatch
• Inferência Assíncrona do Amazon SageMaker AI com Suporte a Payloads Inline
• Deploy Eficiente de Modelos: Configuração do Operador de Inferência Simplificado no SageMaker HyperPod
• Melhores Práticas para Inferência no Amazon SageMaker HyperPod
• Cache KV em Camadas Gerenciado e Roteamento Inteligente para Amazon SageMaker HyperPod
• Data Capture do Amazon SageMaker HyperPod para Cargas de Inferência
• Inferência Enterprise no Amazon SageMaker HyperPod com Data Capture, Hugging Face, NVMe e Route 53
• Prefill e Decode Disagregados para Inferência de LLM no SageMaker HyperPod
• Amazon SageMaker HyperPod Agora Suporta Prefill e Decode Disagregados
• Redução de Cold Starts de Inferência no Amazon SageMaker HyperPod com Model Caching
• Redução de Latência de LLM com Roteamento com Consciência de Prefixo no Amazon SageMaker Inference

Fonte

Amazon SageMaker Inference: 2026 year-to-date launches in review (https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-inference-2026-year-to-date-launches-in-review/)

Agentes de IA chegaram à produção — e a infraestrutura precisou evoluir

Agentes de Inteligência Artificial (IA) deixaram de ser experimentos. Hoje eles processam solicitações de seguro, escrevem e revisam código, coordenam sistemas inteiros e operam por horas sem supervisão humana. À medida que essas cargas de trabalho ficam mais complexas e longas, a infraestrutura que as sustenta precisa acompanhar o mesmo ritmo.

Foi nesse contexto que a AWS construiu o Amazon Bedrock AgentCore: uma plataforma para que desenvolvedores possam criar, conectar e otimizar agentes com segurança e escala. O AgentCore Runtime é a camada de computação gerenciada dessa plataforma — um ambiente totalmente administrado onde você implanta e executa agentes sem precisar provisionar ou manter infraestrutura.

Desde o lançamento, milhares de equipes utilizaram o serviço para rodar agentes em produção. O feedback coletado apontou três necessidades claras: maior responsividade à medida que as cargas crescem, controle mais fino sobre alocação de recursos e um modelo de cobrança que reflita o uso real. A AWS respondeu a esse feedback com o lançamento do novo AgentCore Runtime.

A evolução dos agentes: de chatbots a processos autônomos

Para entender por que o novo runtime importa, vale acompanhar como os agentes evoluíram. No início, a maioria funcionava como chatbots simples: você perguntava, o agente respondia em segundos e a conversa terminava. Depois vieram agentes de codificação, capazes de trabalhar por minutos ou horas mantendo contexto ao longo de muitos passos.

Agora os agentes estão se tornando ambient — sempre ativos, acionados por eventos, operando sem supervisão e sinalizando apenas quando um trabalho termina ou quando uma decisão humana é necessária. E há muito mais deles: não são mais novidades, mas componentes embarcados em produtos, por trás de funcionalidades cotidianas e, cada vez mais, lançados por outros agentes.

A primeira versão do AgentCore Runtime criou uma base sólida para esse espectro: modelo serverless, isolamento de sessão, escala até zero e pagamento apenas pelo que é usado. A nova versão estende essa base para cobrir todo o espectro — mantendo velocidade e consistência para agentes interativos, e durabilidade com custo acessível para agentes de longa duração e mais autônomos.

O que o AgentCore Runtime oferece

O modelo de consumo do AgentCore Runtime tem dois pilares que justificam sua adoção:

• Pagamento apenas pelo que é consumido, sem cobrança por Unidade Central de Processamento (CPU) ociosa aguardando Entrada/Saída (I/O). Não há custo fixo por capacidade provisionada “por precaução”.
• Escala até zero: quando um agente não está processando nada, não há nada rodando — e, portanto, nada a pagar. Quando o trabalho chega, a plataforma provisiona a capacidade necessária.

Juntos, esses dois pilares tornam barato manter muitos agentes ociosos na maior parte do tempo, sem abrir mão da capacidade de atender picos de demanda. O modelo de consumo se adapta à carga de trabalho, não o contrário.

Os dois desafios que o novo runtime resolve

Memória cara: você pagava pelo pico

No runtime original, uma sessão mantinha a memória alocada desde o momento em que a reservava até o encerramento da sessão — nada era liberado ao longo do caminho. Isso funciona quando a memória alocada é usada para atender requisições subsequentes sem incorrer em latência para buscá-la novamente. Porém, um agente de longa duração ou com picos de uso continuava pagando pelo ponto mais alto de consumo durante todo o tempo de execução, muito depois de ter parado de usar aquela memória.

Cold starts imprevisíveis

Toda nova sessão precisa inicializar antes de executar qualquer trabalho. Isso é especialmente crítico quando uma pessoa aguarda a resposta de um agente que pausou para receber input e precisa retomar. O problema é que a inicialização a frio (cold start) — que envolve subir um novo ambiente, baixar a imagem e inicializar o agente — crescia proporcionalmente ao tamanho da imagem e à concorrência. Sob tráfego em rajada, exatamente quando mais sessões chegam e menos ambientes prontos existem, a latência era pior.

Para contornar esses problemas, equipes precisavam construir e manter a própria infraestrutura: manter ambientes reservados para evitar cold starts, otimizar alocação de memória e depois desligar tudo para controlar custos. Trabalho indiferenciado que nada tem a ver com o agente em si.

O que muda com o novo AgentCore Runtime

Memória alocada sob demanda e liberada quando não é mais usada

O novo runtime inicia cada sessão a partir de um perfil de memória pequeno e eficiente, em vez de um footprint totalmente provisionado. Memória adicional é alocada e carregada sob demanda conforme a carga de trabalho precisa. Com base na análise de padrões de alocação em bilhões de sessões, a AWS ajustou o novo runtime para recuperar memória quando ela fica “fria” e é improvável que seja acessada novamente — sem esperar o fim da sessão para fazer isso.

No runtime original, a memória alocada permanecia retida mesmo que não fosse usada por requisições subsequentes, então o uso rastreava o pico histórico. Com o novo runtime, memória liberada ou fria é recuperada, e a cobrança acompanha essas variações ao longo do tempo de vida da sessão.

Cold starts rápidos e consistentes, independente do tamanho da imagem

Como o perfil de inicialização é menor, os cold starts ficam mais rápidos como consequência direta. O novo runtime prepara o ambiente uma vez, captura um snapshot desse estado e restaura esse snapshot para cada nova instância. Como o snapshot permanece pequeno e consistente, os tempos de inicialização também ficam — independentemente do tamanho da imagem ou do nível de concorrência.

Em vez de repetir o trabalho de boot e inicialização a cada cold start, a plataforma restaura um ambiente já pronto. O trabalho de inicialização é pago uma única vez, e cada instância herda esse estado instantaneamente. Além disso, o runtime mantém o snapshot enxuto: em vez de capturar todo o estado em memória de um processo em execução (incluindo caches e memória transitória que inflariam o snapshot), o novo runtime remove esse excesso. O resultado é um snapshot cujo tamanho permanece aproximadamente constante conforme a imagem do container cresce.

Números medidos pela AWS

Para isolar o que a plataforma em si adiciona a um cold start, a AWS testou um agente echo vazio — que apenas retorna o input sem chamar nenhum modelo ou ferramenta. Um cliente Python em uma instância do Elastic Compute Cloud (EC2) na região us-west-2 chamou agentes em us-east-1 pela internet pública sem emparelhamento de Nuvem Virtual Privada (VPC), usando o SDK boto3. Foram enviadas 5.000 invocações frias por agente em ambas as versões e em cinco tamanhos de imagem.

O resultado: o novo runtime entrega uma latência de cold start no Percentil 75 (P75) de aproximadamente 2 segundos, de uma imagem de 200 MB até 2 GB — o tamanho da imagem não tem efeito. A latência do runtime original, por contraste, sobe com o tamanho da imagem: de cerca de 5,4 segundos para quase 30 segundos.

Vale separar o tempo de cold start do que o usuário realmente espera. O tempo de inicialização é quanto tempo leva para ter um ambiente pronto antes que o código do agente processe a primeira requisição — não é o tempo que o agente passa trabalhando. Em produção, a maior parte do tempo percebido pelo usuário vem do loop do agente e das chamadas ao modelo, muitas vezes vários segundos cada. No teste echo, o código do próprio agente rodou em cerca de 34 milissegundos no P75 — quase tudo era tempo de inicialização da plataforma.

Dica prática para agentes interativos: é possível esconder quase completamente o tempo de cold start iniciando a sessão assim que o usuário abre o chat — antes mesmo de ele digitar qualquer coisa. A sessão aquece enquanto o usuário é recebido e enquanto digita a primeira mensagem, então quando ele envia, o ambiente já está pronto.

Cobrança mais justa: taxa maior, footprint muito menor

O novo runtime cobra pela memória que o agente realmente usa — carregada sob demanda e recuperada quando ociosa — não pela manutenção de toda a imagem do container em memória durante a sessão. A taxa por unidade é mais alta, mas incide sobre muito menos GB-hora. Para a maioria dos agentes, a redução do footprint supera o aumento da taxa, e a conta cai.

O que está por vir

Além do que foi entregue hoje, a AWS sinalizou que várias capacidades adicionais estão a caminho:

• Descontos por baseline comprometido: além do modelo de consumo atual (ideal para cargas com picos e escala a zero), haverá uma opção de precificação baseline — você reserva um piso de memória para uma sessão e ultrapassa esse limite sob demanda. Indicado para sessões de agentes sempre ativas que precisam de custo previsível.
• Computação e armazenamento maiores: mais RAM, vCPU e armazenamento de sessão para agentes que demandam mais recursos.
• Suporte a x86: execução de agentes, ferramentas ou ambientes já existentes em microVMs x86, sem necessidade de reescrever código ou dependências.
• Maior controle de ciclo de vida: suspender e retomar sessões com snapshotting de memória, além de hooks de runtime para serializar estado antes de uma sessão ativa ser encerrada — permitindo que sessões sejam retomadas indefinidamente.
• Identidade com escopo para agentes autônomos: chaves de contexto de sessão darão a cada sessão sua própria identidade com escopo, garantindo que um agente não supervisionado aja exatamente com as permissões definidas para ele — nem mais, nem menos.

Como começar

Para usar o novo runtime, basta definir o parâmetro platformVersion como V2 ao criar ou atualizar um runtime. O Guia do Desenvolvedor do AgentCore traz mais detalhes sobre como usar o runtime. Exemplos práticos estão disponíveis no repositório de exemplos do AgentCore no GitHub, incluindo um exemplo de teste de carga que demonstra a latência consistente de cold start do novo runtime na sua própria conta AWS.

Fonte

The new AgentCore runtime: Elastic, optimized, and consistently fast starts (https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)

O problema: infraestrutura demais, lógica de menos

Quem já tentou colocar agentes de IA em produção sabe o quanto a infraestrutura pode virar o maior obstáculo. Orquestração de containers, políticas de escalonamento, gerenciamento de identidade, observabilidade — tudo isso precisa ser configurado e mantido pela equipe. O resultado é que os times acabam gastando mais tempo cuidando de infraestrutura do que desenvolvendo a lógica dos próprios agentes.

Esse é exatamente o cenário que a AWS aborda em um post técnico recente, mostrando como migrar um agente de IA multi-modelo de saúde de uma infraestrutura autogerenciada no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate para o Amazon Bedrock AgentCore Runtime — sem reescrever nenhuma linha da lógica do agente.

O que é o Amazon Bedrock AgentCore Runtime

O Amazon Bedrock AgentCore é uma plataforma para construir, conectar e otimizar agentes em escala, compatível com qualquer framework ou modelo. Seu componente de runtime é a capacidade de implantação gerenciada da plataforma: ele cuida do ciclo de vida dos containers, escalonamento, identidade e observabilidade automaticamente.

A proposta é simples: o time foca no código do agente, e o AgentCore Runtime resolve o resto. Para quem já tem agentes rodando em infraestrutura própria, o caminho de migração é direto — basta envolver o código existente com o padrão decorator do AgentCore, sem adaptar a lógica para nenhum framework específico.

A solução: agente de saúde com três backends de modelo

O exemplo utilizado pela AWS migra um agente de IA para o setor de saúde que processa consultas médicas usando três backends de modelo diferentes, com recuperação de conhecimento vetorial. Toda essa orquestração roda dentro de um único container gerenciado pelo AgentCore.

A distribuição de tarefas entre os modelos funciona assim:

• Consultas biomédicas especializadas são direcionadas ao BioM-ELECTRA-Large-SQuAD2, um modelo de domínio específico hospedado no Amazon SageMaker AI.
• Raciocínio médico mais amplo fica a cargo do Llama 3.1 70B Instruct da Meta, acessado via Amazon Bedrock.
• Um servidor de modelo containerizado com BioM-ELECTRA também está disponível para implantação própria, podendo rodar no Amazon ECS, no Amazon Elastic Kubernetes Service (Amazon EKS) ou em outros ambientes de container.

Os três backends implementam compatibilidade com a API de mensagens do Hugging Face, garantindo formatos de requisição e resposta consistentes independentemente do serviço de modelo escolhido. Para recuperação de conhecimento, a solução utiliza o Amazon OpenSearch Service para busca por similaridade vetorial e indexação de conhecimento médico.

Vale destacar um ponto importante: o post anterior da AWS usava o Claude 3.5 Sonnet V2 da Anthropic. Nesta versão, o Claude 3.5 Sonnet V2 da Anthropic foi substituído pelo Llama 3.1 70B da Meta — o que demonstra que o AgentCore Runtime é agnóstico em relação ao modelo utilizado. A escolha do modelo é uma decisão de implementação, não um requisito da plataforma.

O framework utilizado como referência é o Hugging Face smolagents, uma biblioteca Python de código aberto projetada para construir e executar agentes com poucas linhas de código. A implementação completa está disponível no repositório do GitHub.

Como funciona a migração na prática

A migração usa o padrão decorator do AgentCore. Os três componentes centrais são:

• BedrockAgentCoreApp — inicializa a aplicação AgentCore.
• @app.entrypoint — decora a função que o AgentCore Runtime chama ao receber uma requisição.
• app.run() — inicia o servidor do AgentCore Runtime.

O padrão de integração fica assim:

from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
def healthcare_agent_entrypoint(payload):
    user_input = payload.get("prompt", "")
    model_type = payload.get("model_type", "sagemaker")
    # Your existing agent logic here
    agent = TripleHealthcareAgent(vector_store=vector_store)
    response = agent.run(user_input, model_type=model_type)
    return str(response)

if __name__ == "__main__":
    app.run()

O código do agente entre o decorator e o return permanece exatamente igual à versão standalone. O AgentCore Runtime gerencia ciclo de vida do container, escalonamento, identidade e observabilidade de forma automática.

Pré-requisitos para a migração

Antes de iniciar o processo, é necessário ter em mãos:

• Uma conta AWS com acesso ao Amazon Bedrock AgentCore Runtime e permissões para criar funções do Gerenciamento de Identidade e Acesso (IAM) e domínios do Amazon OpenSearch Service.
• Interface de Linha de Comando da AWS (AWS CLI) versão 2.0 ou superior, instalada e configurada.
• Node.js 20 ou superior (necessário para o CLI de implantação).
• Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) instalado.
• AgentCore CLI instalado.
• Python 3.10 ou superior.
• Docker instalado e em execução.
• SDK Python do bedrock-agentcore instalado.
• Acesso ao Amazon Bedrock, Amazon SageMaker AI e Amazon OpenSearch Service na região AWS desejada.

A implementação usa Python 3.10+, framework smolagents, transformers 4.55.0+ e boto3.

Passo a passo da implantação

1. Criar o projeto AgentCore

Instale o AgentCore CLI e crie o projeto:

npm install -g @aws/agentcore

agentcore create --project-name healthcareagent --no-agent --build Container --language Python --protocol HTTP --model-provider Bedrock --memory none

2. Adicionar o agente existente

Adicione o agente existente como uma implantação do tipo “traga seu próprio agente” (BYO — Bring Your Own):

agentcore add agent --name healthcare_agentcore --type byo --build Container --language Python --protocol HTTP --network-mode PUBLIC --code-location ./agent-code --entrypoint healthcare_agentcore.py --framework Strands --model-provider Bedrock

Observação: o flag --framework especifica o template do CLI. O código real do agente usa o Hugging Face smolagents, que é compatível com o AgentCore Runtime independentemente do template selecionado.

3. Preparar o container

Crie um arquivo pyproject.toml no diretório do agente para definir as dependências:

[project]
name = "healthcare-agentcore"
version = "1.0.0"
requires-python = ">=3.10"
dependencies = [
    "smolagents>=1.24.0",
    "transformers>=4.55.0",
    "boto3>=1.37.0",
    "opensearch-py>=3.1.0",
    "requests-aws4auth>=1.3.1",
    "bedrock-agentcore>=0.1.0",
    "numpy>=1.26.0",
    "requests>=2.32.0",
    "docker>=7.1.0",
]

Crie também o Dockerfile:

FROM public.ecr.aws/docker/library/python:3.12-slim
RUN pip install --no-cache-dir uv
WORKDIR /app
COPY pyproject.toml ./
RUN uv pip install --system -r pyproject.toml
COPY . .
EXPOSE 8080
CMD ["python", "healthcare_agentcore.py"]

Crie um arquivo .dockerignore para manter o tamanho da imagem dentro do limite de 2 GB:

venv/
.venv/
__pycache__/
.git/
*.pyc

4. Fazer o deploy

Com o projeto configurado, basta executar um único comando para implantar o agente:

agentcore deploy -y

O CLI constrói o container, envia para o Registro de Container Elástico da Amazon (Amazon ECR) e cria o agente no AgentCore Runtime. O processo leva aproximadamente 10 a 15 minutos.

5. Testar o agente implantado

É possível testar o agente de duas formas: via AgentCore CLI ou programaticamente com boto3.

Via CLI:

agentcore invoke --prompt '{"prompt": "What are the side effects of metformin?", "model_type": "llama"}'

Via boto3:

import boto3, json

client = boto3.client('bedrock-agentcore', region_name='us-west-2')

payload = json.dumps({
    "prompt": "What are the side effects of metformin?",
    "model_type": "llama"
})

response = client.invoke_agent_runtime(
    agentRuntimeArn='',
    contentType='application/json',
    accept='application/json',
    payload=payload.encode('utf-8')
)

result = response['response'].read().decode('utf-8')
print(result)

ECS com Fargate vs. AgentCore Runtime: qual a diferença real?

Ambas as abordagens executam o mesmo agente, mas de formas distintas. A versão standalone no Amazon ECS com AWS Fargate exige que o time defina as task definitions do ECS, configure políticas de escalonamento, gerencie funções do Gerenciamento de Identidade e Acesso da AWS (IAM) por serviço e configure observabilidade via Amazon CloudWatch. A implantação envolve um build Docker, push para o Amazon ECR e atualização do serviço ECS. Esse caminho oferece controle total sobre configuração de container, rede e comportamento de escalonamento.

Já a versão com AgentCore Runtime executa o mesmo arquivo healthcare_agentcore.py com o padrão decorator do AgentCore. O runtime fornece orquestração de containers, escalonamento baseado em sessão, gerenciamento de identidade via integração com IAM e observabilidade com rastreamento e logs integrados. A implantação é feita com um único comando (agentcore deploy).

Em ambos os casos, os seguintes elementos permanecem idênticos ao migrar da versão standalone para o AgentCore Runtime:

• Lógica central do agente (decorator BedrockAgentCoreApp + código existente).
• Orquestração multi-modelo entre Amazon Bedrock, Amazon SageMaker AI e backends containerizados.
• Recuperação de conhecimento vetorial com Amazon OpenSearch Service.
• Compatibilidade com a API de mensagens do Hugging Face entre os backends de modelo.

Limpeza dos recursos

Para evitar cobranças futuras, remova os recursos criados quando não forem mais necessários.

Remova o agente do AgentCore Runtime:

agentcore remove all

agentcore deploy

Exclua o endpoint do Amazon SageMaker AI:

aws sagemaker delete-endpoint --endpoint-name healthcare-agentcore-endpoint-1 --region us-west-2

Exclua o domínio do Amazon OpenSearch Service:

aws opensearch delete-domain --domain-name healthcare-vector-store --region us-west-2

Conclusão

A AWS demonstra com esse exemplo que migrar um agente de IA multi-modelo de infraestrutura autogerenciada para o Amazon Bedrock AgentCore Runtime não exige reescrever a lógica do agente. O mesmo arquivo healthcare_agentcore.py orquestra Amazon Bedrock, Amazon SageMaker AI e um servidor de modelo containerizado — agora com o suporte do AgentCore Runtime mediante a adição do padrão decorator (BedrockAgentCoreApp, @app.entrypoint e app.run()).

O design agnóstico em relação a frameworks suporta uma ampla combinação de modelos e frameworks de agentes, tornando esse padrão de migração aplicável em setores como saúde, serviços financeiros e manufatura. Para quem quiser explorar a implementação completa, o repositório está disponível no GitHub. Para entender a implementação standalone que serviu de base, a AWS indica o post Agentic AI with multi-model framework using Hugging Face smolagents on AWS.

Leituras recomendadas

• IA Agêntica na AWS — construa, implante e escale agentes de IA com a AWS
• Amazon Bedrock AgentCore: agora disponível para todos
• Documentação do Amazon Bedrock
• Construindo agentes de IA confiáveis com o Amazon Bedrock AgentCore Observability

Fonte

Migrating multi-model AI agents to Amazon Bedrock AgentCore runtime (https://aws.amazon.com/blogs/machine-learning/migrating-multi-model-ai-agents-to-amazon-bedrock-agentcore-runtime/)