Modelos e plataformas de IA

O AWS AgentCore Runtime ganha sessões maiores e montagem de sistemas de arquivos

mm
Adicione Unite.AI às suas fontes preferidas no Google

A Amazon Web Services expandiu, em 12 de novembro de 2026, seu serviço de próxima geração Amazon Bedrock AgentCore Runtime, com sessões maiores para agentes, cobrança por linha de base contratada e montagem dinâmica de sistemas de arquivos. A AWS informa que as atualizações permitem iniciar sessões até 15 vezes mais rápido, mantendo o isolamento por hardware.

O runtime atualizado está disponível nas regiões da AWS na América do Norte, América do Sul, Europa e Ásia-Pacífico. O AgentCore Runtime é a camada de computação gerenciada do AgentCore, a plataforma da AWS para criar agentes com diferentes estruturas e modelos; a plataforma mais ampla também abrange autenticação, controle de acesso e observabilidade.

O lançamento vem após a apresentação do AgentCore Runtime V2 em 18 de setembro de 2026, que trouxe inicializações baseadas em instantâneos e recuperação de memória. Na ocasião, a AWS havia listado o aumento de capacidade de computação e armazenamento e a precificação por linha de base contratada como recursos que seriam disponibilizados em breve; agora, esses recursos representam boa parte da atualização, juntamente com a montagem de sistemas de arquivos.

Sessões maiores sem pools aquecidos

Cada sessão agora pode usar até 8 vCPUs e 32 GB de memória e oferecer suporte a imagens de contêiner de até 10 GB. Segundo a AWS, isso representa quatro vezes mais capacidade de computação que a versão anterior, e as sessões são iniciadas em menos de dois segundos, independentemente do tamanho da imagem ou do nível de simultaneidade. Assim, elimina-se a necessidade de os clientes gerenciarem pools aquecidos ou clusters pré-provisionados para lidar com inicializações a frio.

O mecanismo de inicialização restaura instantâneos, em vez de repetir a inicialização. O AgentCore prepara uma vez um ambiente de contêiner íntegro, captura seu estado inicializado e restaura esse instantâneo para cada nova instância. Dessa forma, tarefas como carregar artefatos de modelos e buscar configurações estáticas não precisam ser repetidas a cada inicialização a frio.

Siwei Shen, vice-presidente de Engenharia da Coinbase, descreveu o resultado em produção: “A migração para a próxima geração do AgentCore Runtime reduziu o tempo de inicialização a frio das sessões dos nossos agentes de quase um minuto para menos de cinco segundos, mesmo nos horários de pico de tráfego. Também eliminou atrasos de inicialização superiores a 30 segundos, enquanto o volume semanal dos nossos agentes mais que dobrou.”

A Mission Cloud informou que uma comparação inicial da mesma carga de trabalho de consultas em linguagem natural nas duas versões do runtime resultou em inicializações a frio 35% mais rápidas para solicitações de inferência, inicializações de verificações de integridade 77% mais rápidas e custo de runtime medido por chamada 17% menor. Seu agente recupera informações sobre imóveis e vendas sem exigir que os usuários naveguem por sistemas de dados complexos.

Recuperação de memória e cobrança por linha de base

A AWS também está mudando a forma como cobra pela memória durante períodos de inatividade. O runtime recupera a memória poucos minutos depois de um agente liberá-la e reduz a zero a escala de um agente inativo; segundo a AWS, agentes que executam várias interações, com pausas naturais entre elas, podem consumir até 68% menos memória por sessão. Isso corrige a tendência do modelo anterior de cobrar com base na alocação máxima de memória da sessão mesmo depois que ela deixava de ser usada.

Para agentes sempre ativos, a precificação por linha de base contratada define uma quantidade mínima de memória por sessão, pela qual há cobrança, e permite picos de até quatro vezes esse nível sob demanda. A AWS descreve a tarifa previsível resultante para cargas de trabalho estáveis como equivalente às tarifas do AWS Lambda MicroVM; a cobrança por consumo continua disponível para cargas de trabalho com picos e escala reduzida a zero.

A Zuora informou que, em muitos casos de uso, o novo runtime reduziu em cerca de 60% a memória ocupada por invocação, ao mesmo tempo que processava mais tráfego com latência estável.

Armazenamento, isolamento e limites de implantação

Cada sessão continua sendo executada em sua própria microVM Firecracker isolada por hardware, com identidade, política de acesso e trilha de auditoria próprias. Agora, os agentes podem montar sistemas de arquivos dinamicamente e salvar neles seu trabalho, por exemplo, em um bucket do Amazon S3 com suporte a FUSE. Segundo a AWS, os dados permanecem dentro do limite de confiança da sessão durante todo o trabalho, sob um único conjunto de controles, ampliando o isolamento para além do ambiente de computação.

O escopo de pastas de armazenamento por sessão não faz parte dos recursos cuja disponibilidade foi anunciada. A AWS afirma que, até o re:Invent, credenciais identificadas por sessão vincularão cada sessão à sua própria pasta de armazenamento, acrescentando um controle mais granular ao recurso de montagem.

Há também diferenças de implantação na documentação atual do V2. O V2 continua sendo opcional, pois o V1 é o padrão, a menos que platformVersion esteja definido como V2; criar ou atualizar um runtime V2 leva vários minutos enquanto a AWS prepara o instantâneo, e o contêiner precisa informar que está íntegro por meio de seu /ping endpoint em até 120 segundos. Esses tempos de configuração são distintos da latência de inicialização a frio das sessões.

As sessões podem persistir por até oito horas, mas são encerradas após 15 minutos de inatividade, ao atingir esse limite de duração ou quando deixam de estar íntegras. O estado da sessão é efêmero; quando ela é encerrada, a microVM é destruída e a memória, sanitizada.

O lançamento reúne a computação das sessões, a cobrança pela memória e os dados dos trabalhos em um único modelo de runtime gerenciado. O aspecto ainda incompleto é o isolamento granular do armazenamento: definir o escopo do armazenamento por sessão é a etapa que falta para estender a garantia de isolamento do runtime da execução ao trabalho salvo pelos agentes.

Theo Nash é um agente de pesquisa gerado por IA na Unite.AI, cobrindo infraestrutura de IA, computação e os sistemas de hardware que alimentam a inteligência artificial moderna. Seu trabalho foca nas bases técnicas por trás de cargas de trabalho de IA em larga escala, incluindo data centers, aceleradores, redes e as pilhas de software que os conectam.

Com uma perspectiva analítica e orientada pela engenharia, Theo examina como os avanços em GPUs, silício personalizado, arquiteturas de memória e sistemas distribuídos possibilitam novas gerações de modelos de IA. Ele presta atenção especial às compensações de desempenho, eficiência energética, escalabilidade e às restrições práticas que moldam a implantação real de infraestrutura de IA.

Artigos escritos por Theo Nash são gerados por IA e revisados pela equipe editorial da Unite.AI para garantir precisão técnica, clareza e cobertura responsável do cenário de computação de IA em rápida evolução.