A Transição para Inferência Eficiente em Larga Escala

Com o avanço de sistemas de IA baseados em agentes e raciocínio complexo, os modelos de linguagem grandes (LLMs) passaram a gerar dez vezes mais tokens através de cadeias de raciocínio intricadas, comparado a respostas simples. Esses fluxos de trabalho não apenas aumentam exponencialmente a carga computacional, mas criam demandas altamente variáveis que comprometem a performance geral e a experiência do usuário.

À medida que o mercado avança da fase de prototipagem para implementações em produção, a eficiência da inferência tornou-se o fator limitante mais crítico. A AWS reconheceu esse desafio e estabeleceu uma parceria com a comunidade do llm-d para oferecer uma solução integrada que melhora significativamente o aproveitamento de recursos e reduz custos operacionais.

Compreendendo as Fases da Inferência em LLMs

A execução de um modelo de linguagem envolve duas fases fundamentalmente distintas. Na fase de prefill, o sistema processa todo o prompt de entrada em paralelo, gerando o conjunto inicial de entradas de cache chave-valor (KV). Esta fase é limitada pelo poder computacional disponível. Na fase de decode, o modelo gera um token por vez de forma autorregressiva, exigindo acesso constante aos pesos do modelo e ao cache KV em crescimento — característica que torna essa fase dependente de largura de banda de memória.

Como as requisições de inferência variam consideravelmente em comprimento de entrada e saída, otimizar o uso de recursos em ambas as fases simultaneamente representava um desafio significativo. Abordagens tradicionais, que implantam modelos em infraestrutura pré-determinada, resultam em utilização subótima, com GPUs ora subutilizadas ora sobrecarregadas conforme a fase de execução.

O que é llm-d?

llm-d é um framework de código aberto nativo do Kubernetes para serviços distribuídos de LLMs. Construído sobre o vLLM, o llm-d estende o mecanismo de inferência principal com orquestração pronta para produção, agendamento avançado e suporte a interconexão de alta performance. Em vez de tratar a inferência como um problema de execução em nó único, o llm-d introduz padrões arquiteturais para serviços desagregados — separando e otimizando etapas como prefill, decode e gerenciamento de cache KV através de recursos de GPU distribuídos.

O framework oferece “caminhos bem definidos” — arquiteturas de referência que empacotam estratégias de otimização comprovadas para diferentes objetivos de performance e escalabilidade.

Capacidades Principais do llm-d

Agendamento Inteligente de Inferência

Em ambientes de nó único, mecanismos como o vLLM utilizam cache de prefixo automático para reduzir computação redundante reutilizando entradas de cache KV anteriores. Porém, em ambientes distribuídos com múltiplas réplicas, as suposições sobre quais blocos de cache residem em quais GPUs deixam de valer.

O agendador do llm-d resolve isso mantendo visibilidade sobre o estado do cache em todas as réplicas e roteando requisições de forma consciente dessa localidade. Para cargas de trabalho com alto reuso de prefixo, como conversas multi-turno ou fluxos agentic, esse roteamento consciente do cache resulta em melhorias significativas de throughput e latência.

Desagregação de Prefill e Decode

Ao separar as fases de prefill e decode em infraestrutura dedicada, torna-se possível otimizar cada uma independentemente. Se a saída do seu modelo tende a ser longa comparada à entrada, você pode alocar mais GPUs para decode sem aumentar o custo de prefill. Também é possível colocar essas fases em tipos diferentes de hardware, cada um sintonizado para seu perfil de carga.

No llm-d, servidores de prefill são otimizados para processar prompts de entrada com eficiência, enquanto servidores de decode focam em gerar tokens com baixa latência. O agendador inteligente decide quais instâncias devem receber uma dada requisição, e a transferência é coordenada através de um sidecar executado junto às instâncias de decode. Esse componente orquestra transferências ponto-a-ponto de cache KV sobre interconexões rápidas, garantindo que o servidor de decode receba o contexto necessário com sobrecarga mínima.

Paralelismo Amplo de Especialistas

Para modelos de Mistura de Especialistas (MoE) como DeepSeek-R1, Qwen3.5, Minimax e Kimi K2.5, o llm-d oferece padrões de implantação otimizados que utilizam paralelismo de dados e paralelismo de especialistas. Essa abordagem permite distribuir especialistas horizontalmente entre múltiplos nós mantendo performance, reduzindo latência e aumentando throughput para essas arquiteturas complexas.

Cache de Prefixo em Camadas

O cache de prefixo evita computações repetitivas e caras do cache KV, melhorando métricas como tempo até primeiro token (TTFT) e throughput geral. Porém, mecanismos nativos como os do vLLM estão restritos à memória de GPU disponível em cada instância. O llm-d expande o tamanho efetivo do cache oferecendo um caminho de cache em camadas que descarrega entradas de cache KV da memória GPU para outros níveis de armazenamento, como memória CPU ou disco local.

Infraestrutura na AWS: SageMaker HyperPod e EKS

O SageMaker HyperPod oferece infraestrutura Kubernetes resiliente e de alta performance otimizada para treinamento e inferência de modelos em larga escala. Com clusters persistentes de alta performance e monitoramento de saúde integrado que detecta e remedia falhas de hardware proativamente, a plataforma fornece a fundação ideal para a arquitetura nativa do Kubernetes do llm-d.

Componentes Técnicos da Comunicação

A comunicação entre GPUs em nó único ocorre via NVLink e NVSwitch. Para comunicação entre nós, o llm-d aproveita componentes avançados. A Biblioteca de Transferência de Inferência NVIDIA (NIXL) é propositalmente construída para transferências de dados ponto-a-ponto eficientes — movimentação de dados de cache KV de nós de prefill para nós de decode. NIXL fornece uma camada de abstração sobre diferentes métodos de transferência, incluindo libfabric para interfaces EFA, UCCL e GPUDirect Storage.

O Unified Communication X (UCX) fornece o framework de comunicação de nível inferior que NIXL utiliza. UCX suporta operações RDMA que habilitam rede de kernel-bypass com zero-cópia — crítico para cargas de trabalho de inferência onde latência é essencial.

O Adaptador de Tecido Elástico (EFA) oferece uma interface de rede de alta performance na AWS. UCX possui suporte nativo para EFA através da interface libfabric, permitindo que quando o llm-d implanta vLLM em múltiplos nós, a pilha de comunicação subjacente aproveite completamente o networking de baixa latência e alta largura de banda do EFA sem mudanças no nível da aplicação.

Um Balanceador de Carga é provisionado para conectar-se ao Gateway de Inferência (IGW), que implementa agendamento inteligente de requisições e roteamento baseado em localidade de cache e carga do servidor. O Gerenciador de Cache KV habilita roteamento consciente de cache e gerenciamento distribuído do cache, rastreando quais blocos residem em quais nós.

Boas Práticas de Implementação

A desagregação de inferência permite escalar nós de prefill independentemente dos nós de decode, sintonizando performance para suas cargas de trabalho. Cargas com sequências de entrada longas e sequências de saída curtas são intensivas em prefill — a desagregação permite expandir pods de prefill para processar mais requisições sem custo adicional significativo.

A desagregação funciona melhor para modelos maiores, sequências de entrada longas e arquiteturas MoE. O llm-d oferece caminhos para roteamento inteligente de tráfego para pods específicos baseado em métricas como filas de requisição e eventos de cache KV, melhorando throughput e taxa de acertos de cache.

Implantação: Pré-requisitos e Setup

Para implantar o llm-d, você precisará ter configurado localmente:

• AWS Command Line Interface (AWS CLI)
• kubectl
• Conta HuggingFace para criar um token de acesso
• Helm
• helmfile
• Acesso a um cluster SageMaker HyperPod ou EKS

O llm-d utiliza a Extensão de API de Gateway de Inferência, que requer instalação de CRDs e uma implementação como Istio. Clone o repositório e navegue até o auxiliar de instalação:

git clone https://github.com/llm-d/llm-d.git
cd guides/prereq/gateway-provider
./install-gateway-provider-dependencies.sh
helmfile apply -f istio.helmfile.yaml

Para implantar com desagregação prefill-decode, configure os valores do pod para usar a imagem compatível com AWS do llm-d e ativar NIXL com libfabric como backend de transporte:

containers:
- name: "vllm"
  image: ghcr.io/llm-d/llm-d-aws:v0.5.1
  args:
    - "--block-size"
    - "128"
    - "--kv-transfer-config"
    - '{"kv_connector":"NixlConnector", "kv_role":"kv_both","kv_connector_extra_config": {"backends": ["LIBFABRIC"]}}'
    - "--disable-uvicorn-access-log"
    - "--max-model-len"
    - "32000"

Configure o número de interfaces EFA baseado nas GPUs por pod. Por exemplo, uma instância p5.48xlarge possui 8 GPUs H100 com 32 interfaces EFA — configure cada réplica com 4 interfaces EFA por GPU.

Resultados de Performance

A AWS testou a desagregação prefill/decode do llm-d em uma instância ml.p6-b200.48xlarge, comparando contra uma implantação padrão de vLLM. O teste utilizou 4 pods de prefill com paralelismo de tensor 1 e 1 pod de decode com paralelismo de tensor 4, conectados via NIXL com libfabric como transporte EFA.

Os testes demonstraram que a desagregação prefill/decode do llm-d aumenta a taxa de tokens por segundo em até 70% conforme a concorrência aumenta, comparado a uma implantação padrão de vLLM com sequência de entrada de 1024 tokens e saída de 1024 tokens sob concorrência de até 128 requisições simultâneas. Esse perfil de performance varia conforme a configuração do vLLM e a carga de trabalho específica. Ajustar a proporção prefill/decode e outros parâmetros disponíveis pode trazer ganhos ainda maiores.

Conclusão

O llm-d oferece caminhos comprovados para métodos de implantação como desagregação prefill/decode, roteamento consciente de cache KV e cache em camadas. Essas capacidades permitem otimizações significativas na performance, utilização de recursos e eficiência operacional ao servir modelos em larga escala. Você pode explorar a documentação completa e arquitetura do llm-d para entender melhor como implementar essas estratégias na sua infraestrutura AWS.

Fonte

Introducing Disaggregated Inference on AWS powered by llm-d (https://aws.amazon.com/blogs/machine-learning/introducing-disaggregated-inference-on-aws-powered-by-llm-d/)

Desafios na Gestão de Features em Escala

A construção e manutenção de features de aprendizado de máquina em larga escala representa um dos problemas mais críticos e complexos enfrentados por equipes de ciência de dados modernas. Organizações frequentemente lidam com pipelines fragmentados, definições inconsistentes de dados e esforços redundantes de engenharia distribuídos entre múltiplos times. Sem um sistema centralizado para armazenar e reutilizar features, os modelos podem ser treinados com dados desatualizados ou desalinhados, resultando em generalização inadequada, menor acurácia e questões relacionadas à governança.

Além disso, a colaboração entre equipes de engenharia de dados, ciência de dados e operações de machine learning torna-se complexa quando cada grupo mantém seus próprios datasets isolados e transformações independentes. Essa fragmentação amplia o risco de inconsistências e reduz a eficiência operacional.

A Abordagem da AWS para Feature Stores

A AWS oferece o Amazon SageMaker, que aborda esses desafios através de duas capacidades principais: o SageMaker Unified Studio e o SageMaker Catalog. Essas ferramentas permitem que organizações construam, gerenciem e compartilhem ativos de forma segura entre projetos e contas.

Um componente essencial desse ecossistema é a implementação de um repositório de features offline — um armazenamento estruturado projetado para gerenciar dados históricos de features utilizados em treinamento e validação de modelos. Esses repositórios são otimizados para escalabilidade, rastreamento de linhagem e reprodutibilidade, permitindo que cientistas de dados treinem modelos sobre datasets precisos e sincronizados, evitando vazamento de dados e mantendo consistência entre experimentos.

Arquitetura da Solução

A solução integra múltiplos componentes da AWS em um fluxo colaborativo. O SageMaker Unified Studio atua como camada central de governança e colaboração, gerenciando projetos, usuários e ativos de dados sob controle centralizado. As S3 Tables em formato Apache Iceberg servem como fundação para armazenar e fazer versioning de dados de features. O SageMaker Catalog funciona como registro central para publicar, descobrir e assinar features. Complementarmente, o AWS Lake Formation fornece controle granular de acesso e o Amazon SageMaker Studio oferece ferramentas visuais e baseadas em código para engenharia de dados.

O modelo adota um padrão publish-subscribe onde produtores de dados publicam tabelas de features curadas e versionadas, enquanto consumidores descobrem, assinam e reutilizam essas features de forma segura para desenvolvimento de modelos. Essa abordagem integrada possibilita governança consistente de features, acelera experimentação em ML e reduz overhead operacional.

Componentes Principais da Solução

SageMaker Unified Studio

O domínio SageMaker Unified Studio funciona como plano de controle central, gerenciando projetos de ML, usuários e ativos de dados. Ele fornece interface unificada para colaboração entre engenheiros de dados, cientistas de dados e administradores, com aplicação de controles granulares de acesso, integração com AWS IAM Identity Center para autenticação única e suporte a fluxos de aprovação para compartilhamento seguro de ativos entre times e contas.

S3 Tables com Apache Iceberg

As S3 Tables proporcionam armazenamento escalável e serverless para dados de features usando o formato Apache Iceberg. Esse formato habilita transações ACID, evolução de schema e capacidades de time-travel, permitindo consultar versões históricas de dados com reprodutibilidade completa. As S3 Tables integram-se perfeitamente com Spark, Glue e SageMaker para acesso consistente aos dados.

Pipeline de Engenharia de Features

O pipeline automatiza a transformação de datasets brutos em features de alta qualidade e curadas. Construído sobre Apache Spark, oferece processamento distribuído em escala, habilitando transformações complexas como cálculo de taxas de atraso, codificação categórica e agregação de features. Os outputs são gravados diretamente em S3 Tables, garantindo rastreabilidade e consistência.

SageMaker Catalog

O SageMaker Catalog atua como repositório de toda a organização para registrar, publicar e descobrir ativos de ML como datasets, tabelas de features e modelos. Integra-se com Lake Formation para controle granular de acesso e IAM Identity Center para gestão de usuários, suportando enriquecimento de metadados, versionamento e fluxos de aprovação para compartilhamento seguro e reutilização de ativos confiáveis entre projetos.

Fluxo de Trabalho do Administrador

O administrador estabelece a base para um ambiente seguro e colaborativo. Suas responsabilidades incluem provisionar o domínio SageMaker Unified Studio, habilitar IAM Identity Center para autenticação, configurar S3 Tables com Lake Formation para acesso governado, criar projetos produtor e consumidor dedicados, implantar infraestrutura através de blueprints (baseados em AWS CloudFormation) e atribuir usuários e grupos com permissões apropriadas.

Após conclusão das configurações, o administrador criará uma conta de usuário no IAM Identity Center, provisionar o domínio (processo que normalmente leva 2 a 5 minutos) e estabelecerá dois projetos: um produtor (para engenheiros de dados) e um consumidor (para cientistas de dados). Cada projeto receberá as permissões e grupos de usuários apropriados para seu papel específico.

Fluxo de Trabalho do Engenheiro de Dados

O engenheiro de dados atua como produtor de features. Conecta-se ao projeto produtor e executa um job de processamento de dados que transforma dados brutos em features curadas. A solução inclui um script de pipeline de engenharia de features que demonstra esse processo.

Após criar o pipeline e validar os dados, o engenheiro de dados usa o editor de dados para enriquecer a tabela de features com metadados, facilitando descoberta e governança. Com validação e aprovação completadas, o engenheiro publica a tabela de features no SageMaker Catalog para acesso da organização inteira.

O processo mantém rastreabilidade completa: os dados brutos alimentam o pipeline, que gera features e as armazena em S3 Tables em formato Iceberg, criando um histórico completo de transformações.

Fluxo de Trabalho do Cientista de Dados

O cientista de dados, como consumidor, busca features publicadas usando busca por AI no SageMaker Catalog. Após identificar features relevantes, submete uma solicitação de assinatura com justificativa de negócio. O produtor revisa e aprova (ou configura aprovação automática). Após aprovação, o cientista de dados ganha acesso à tabela de features através do catálogo do projeto, podendo consultar os dados tanto pelo explorador visual quanto diretamente através de notebooks Jupyter.

Rastreamento de Linhagem

O SageMaker Catalog oferece rastreamento de linhagem compatível com OpenLineage, permitindo capturar e visualizar eventos de linhagem de sistemas habilitados com OpenLineage ou através de APIs. Isso possibilita rastrear origens de dados, acompanhar transformações e visualizar consumo de dados entre organizações.

Capacidades de Time-Travel do Apache Iceberg

A tabela de features armazena múltiplas versões de dados graças ao Apache Iceberg. Cientistas de dados podem usar time-travel para consultar dados históricos em versões específicas ou timestamps definidos. Esse recurso garante reprodutibilidade completa: diferentes execuções de treinamento podem usar exatamente as mesmas features de uma versão histórica específica. O Iceberg registra um histórico completo de snapshots com timestamps e operações, proporcionando trilha de auditoria para compliance e debugging.

Implementação Prática com Jupyter Notebooks

A solução inclui um notebook de exemplo que demonstra como usar uma S3 Table como repositório de features offline para treinamento de modelos e inferência em lote. O notebook implementa um pipeline completo de treinamento e inferência para previsão de atrasos de voos usando o algoritmo XGBoost do SageMaker.

O processo inclui: configuração de experimento MLflow, carregamento de features através de Athena, treinamento de modelo XGBoost com logging de parâmetros e métricas para reprodutibilidade, e transformação em lote para gerar predições. As métricas de desempenho, ID de snapshot e queries utilizadas são registradas no experimento MLflow, garantindo rastreabilidade completa da execução.

Benefícios da Arquitetura Integrada

A implementação de um repositório de features offline com SageMaker Unified Studio e SageMaker Catalog proporciona múltiplas vantagens. A abordagem garante governança consistente, permitindo rastreamento de linhagem e reprodutibilidade completa dos experimentos. As S3 Tables com Apache Iceberg oferecem conformidade ACID e time-travel capabilities, melhorando confiabilidade dos dados de treinamento e performance dos modelos.

O padrão publish-subscribe simplifica compartilhamento de ativos, reduz duplicação e acelera ciclos de vida de desenvolvimento. Diferentes equipes podem colaborar em um ambiente unificado sem comprometer segurança ou integridade dos dados. A escalabilidade da solução permite que organizações gerenciem centenas ou milhares de features com consistência.

Fonte

Build an offline feature store using Amazon SageMaker Unified Studio and SageMaker Catalog (https://aws.amazon.com/blogs/machine-learning/build-an-offline-feature-store-using-amazon-sagemaker-unified-studio-and-sagemaker-catalog/)

Compartilhamento dinâmico de recursos no SageMaker HyperPod

A AWS anunciou uma nova capacidade para o SageMaker HyperPod: o suporte a compartilhamento dinâmico de recursos através de sua funcionalidade de governança de tarefas. Esse recurso permite que equipes acessem capacidade computacional não alocada em clusters HyperPod além das quotas garantidas que possuem. Ao mesmo tempo, administradores podem configurar limites de empréstimo para tipos específicos de recursos, como aceleradores, vCPUs ou memória, assegurando uma distribuição justa entre as equipes.

O desafio da subutilização em clusters compartilhados

Administradores que gerenciam clusters computacionais compartilhados para workloads de IA generativa frequentemente enfrentam um desafio importante: a subutilização de recursos. Quando cientistas de dados não utilizam completamente suas quotas alocadas, instâncias computacionais caras permanecem ociosas, resultando em desperdício. O compartilhamento de recursos ociosos soluciona esse problema identificando automaticamente capacidade de cluster não alocada e disponibilizando-a para que equipes possam utilizá-la sob regime de melhor esforço.

Como funciona o sistema automático

A governança de tarefas do HyperPod monitora continuamente o estado do cluster e recalcula automaticamente quais recursos podem ser emprestados quando instâncias e políticas de quota computacional mudam, eliminando a necessidade de configuração manual. Instâncias elegíveis que se encontram em estado pronto e agendável, incluindo aquelas com configurações de GPU particionadas, contribuem para o pool de capacidade computacional disponível para empréstimo.

Controle fino sobre distribuição de recursos

Administradores podem definir limites de empréstimo absolutos além de limites baseados em percentuais da capacidade ociosa. Essa flexibilidade permite que administradores maximizem a utilização computacional e mantenham controle granular sobre como a capacidade ociosa é distribuída entre equipes, enquanto garantem isolamento de quota computacional para cada uma delas.

Disponibilidade regional

Essa capacidade está atualmente disponível para clusters Amazon SageMaker HyperPod que utilizam o orquestrador EKS (Elastic Kubernetes Service) nas seguintes regiões AWS: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Jakarta), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), Europe (Spain) e South America (São Paulo).

Próximos passos

Para conhecer mais detalhes sobre essa capacidade, consulte a página do SageMaker HyperPod e a documentação de governança de tarefas do HyperPod.

Fonte

SageMaker HyperPod now supports idle resource sharing for dynamic cluster utilization (https://aws.amazon.com/about-aws/whats-new/2026/03/sagemaker-hyperpod-idle-resource-sharing/)

Inteligência Artificial na prática: além dos protótipos

A inteligência artificial está se desenvolvendo em um ritmo acelerado. No entanto, para a maioria das organizações, a verdadeira oportunidade não reside em experimentar com IA, mas em colocá-la para funcionar de verdade—em ambientes de produção onde gera resultados de negócio concretos. Isso exige construir sistemas que operem com confiabilidade, entreguem desempenho em escala e atendam aos requisitos de segurança e conformidade da organização.

Reconhecendo essa realidade, a AWS e a NVIDIA anunciaram durante a NVIDIA GTC 2026 uma colaboração expandida que combina novas integrações tecnológicas para atender à crescente demanda de computação em IA. O objetivo é capacitar clientes a construir e executar soluções de IA que realmente estejam prontas para produção.

Novidades anunciadas na NVIDIA GTC 2026

Expansão massiva de GPUs em infraestrutura em nuvem

A partir de 2026, a AWS planeja adicionar mais de 1 milhão de GPUs NVIDIA—incluindo as arquiteturas Blackwell e Rubin—distribuídas em suas regiões globais. Esta é uma demonstração do compromisso contínuo entre as duas empresas em inovação conjunta, construída ao longo de mais de 15 anos de parceria.

A AWS já oferece o mais amplo portfólio de instâncias baseadas em GPUs NVIDIA entre todos os provedores de nuvem, capacitando uma variedade diversa de cargas de trabalho em IA e aprendizado de máquina. Além disso, a AWS e a NVIDIA estão colaborando em tecnologias de rede Spectrum e outras áreas de infraestrutura para fortalecer essa oferta.

Suporte a novas aceleradoras RTX PRO Blackwell

Pela primeira vez entre os grandes provedores de nuvem, a AWS anunciou que instâncias do Amazon Elastic Compute Cloud (Amazon EC2) aceleradas por GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition estarão disponíveis em breve. Essas instâncias são adequadas para uma ampla gama de workloads, incluindo análise de dados, inteligência artificial conversacional, geração de conteúdo, sistemas de recomendação, streaming de vídeo, renderização de vídeo e outras cargas gráficas.

Essas instâncias EC2 serão construídas sobre o AWS Nitro System—uma combinação de hardware dedicado e hipervisor leve que entrega praticamente todos os recursos de computação e memória do hardware hospedeiro para suas instâncias, resultando em melhor utilização de recursos e desempenho geral. O Nitro System inclui hardware, software e firmware especializados projetados para garantir que ninguém—nem mesmo equipes da AWS—possa acessar suas cargas de trabalho e dados sensíveis em IA. Além disso, o sistema suporta atualizações de firmware, correções de bugs e otimizações enquanto permanece operacional, capacidades essenciais para cargas de trabalho de IA, análise e gráficos em produção.

Otimizações para inferência de modelos de linguagem em larga escala

Aceleração de interconexão para inferência distribuída

Conforme os modelos de linguagem crescem em tamanho, a comunicação entre GPUs pode se tornar um gargalo crítico. A AWS anunciou suporte para a NVIDIA Inference Xfer Library (NIXL) integrada ao AWS Elastic Fabric Adapter (EFA) para acelerar a inferência distribuída de Modelos de Linguagem de Grande Escala (LLM) em Amazon EC2, funcionando tanto com GPUs NVIDIA quanto com aceleradoras AWS Trainium.

Essa integração permite sobreposição eficiente de comunicação e computação, minimizando latência e maximizando utilização de GPU. O resultado é movimento de dados KV-cache (Key-Value cache) de alta taxa de transferência e baixa latência entre nós GPU que executam geração de tokens e recursos de memória distribuída que armazenam o estado do KV-cache.

Uma vantagem adicional: oferece flexibilidade para construir clusters de inferência usando qualquer combinação de instâncias EC2 habilitadas para EFA com GPU e Trainium. A integração NIXL com EFA funciona nativamente com frameworks populares como NVIDIA Dynamo, vLLM e SGLang, resultando em latência inter-token reduzida e utilização de memória KV-cache mais eficiente.

Aceleração de análise de dados com Apache Spark

Engenheiros de dados e cientistas de dados frequentemente enfrentam pipelines de processamento de dados que duram horas, ralentando iteração em modelos de IA/ML e geração de inteligência empresarial. A AWS e a NVIDIA estão entregando ganhos significativos de desempenho: Apache Spark 3x mais rápido usando Amazon EMR no Amazon Elastic Kubernetes Service (Amazon EKS) com instâncias G7e, alimentadas pelas GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition.

Este desempenho é resultado de colaboração de engenharia conjunta entre AWS e NVIDIA, otimizando análise acelerada por GPU através da combinação de Amazon EMR no EKS com a arquitetura RTX PRO 6000. Com essas instâncias, data engineers e data scientists conseguem reduzir significativamente o tempo de processamento de análises em larga escala, mantendo compatibilidade total com aplicações Spark existentes—transformando horas de espera em ciclos de análise muito mais rápidos.

Expansão de modelos NVIDIA Nemotron no Amazon Bedrock

Fine-tuning com aprendizado por reforço

Em breve, desenvolvedores poderão executar fine-tuning de modelos NVIDIA Nemotron diretamente no Amazon Bedrock usando Reinforcement Fine-Tuning (RFT). Esta capacidade é significativa para equipes que precisam alinhar o comportamento do modelo a domínios específicos—seja legal, healthcare, finanças ou qualquer outro campo especializado.

O diferencial: ao contrário de apenas aumentar o conhecimento do modelo, o reinforcement fine-tuning permite moldar como o modelo raciocina e responde. E como isso executa nativamente no Amazon Bedrock, não há overhead de infraestrutura. Você define a tarefa, fornece o sinal de feedback, e o Bedrock faz o resto. Para mais detalhes, consulte a documentação sobre Reinforcement Fine-Tuning in Amazon Bedrock.

Nemotron 3 Super para fluxos multi-agente

O NVIDIA Nemotron 3 Super—um modelo híbrido Mixture of Experts construído para workloads multi-agente e raciocínio estendido—estará disponível em breve no Amazon Bedrock. Projetado para capacitar agentes de IA a manter precisão em fluxos de trabalho complexos e com múltiplas etapas, ele alimenta casos de uso em finanças, cibersegurança, varejo e desenvolvimento de software—entregando inferência rápida e eficiente em custo através de uma API totalmente gerenciada.

Eficiência energética e sustentabilidade

Conforme cargas de trabalho em IA escalam, a performance por watt não é apenas uma métrica de sustentabilidade—é uma vantagem competitiva. Durante uma sessão da NVIDIA GTC, líderes da AWS discutiram como IA está transformando energia e infraestrutura empresarial em escala, desde data centers como participantes ativos na rede elétrica até IA como motor de eficiência empresarial. A infraestrutura AWS demonstra ser 4,1x mais eficiente em energia do que data centers on-premises.

Uma pilha completa e integrada

O que torna esses anúncios realmente interessantes não é nenhuma capacidade isolada—é o que representam em conjunto. Quinze anos de parceria entre AWS e NVIDIA produziram uma pilha completa de infraestrutura de IA otimizada de ponta a ponta: desde a GPU, passando pela rede, até à camada de serviços gerenciados. Não é necessário montar tudo separadamente. Está pronto para funcionar.

Para quem está acompanhando os desenvolvimentos em IA e infraestrutura em nuvem, essas integrações representam um passo importante na democratização do acesso a computação de alta performance para casos de uso reais em produção. A presença da AWS na NVIDIA GTC 2026 ofereceu oportunidade de explorar demos ao vivo e sessões adicionais sobre as tecnologias anunciadas.

Fonte

AWS and NVIDIA deepen strategic collaboration to accelerate AI from pilot to production (https://aws.amazon.com/blogs/machine-learning/aws-and-nvidia-deepen-strategic-collaboration-to-accelerate-ai-from-pilot-to-production/)

Introdução: O Desafio Real da IA Autônoma

Este é o segundo artigo de uma série em duas partes publicada pelo Centro de Inovação em IA Generativa da AWS. Se você perdeu a primeira parte sobre a operacionalização de IA autônoma, vale a pena revisitar aquele conteúdo para compreender os fundamentos.

A barreira mais importante para a adoção de IA autônoma nas empresas não é tecnológica — é organizacional. Na primeira parte desta série, estabeleceu-se que organizações que geram valor real com agentes de IA compartilham três características: definem o trabalho com precisão, estabelecem limites claros para a autonomia, e tratam a melhoria contínua como um hábito permanente, não como um projeto pontual.

Também foram apresentados os quatro ingredientes essenciais para um trabalho verdadeiramente adequado aos agentes: um início e fim bem definidos, exigência de julgamento sobre múltiplas ferramentas, sucesso observável e mensurável, e um modo de falha seguro. Sem esses fundamentos, até o agente mais sofisticado será um fracasso em produção.

Agora vem a pergunta mais difícil: quem faz isso funcionar, e como? Este artigo fala diretamente com os líderes que precisam transformar essa base compartilhada em ação concreta. Cada função executiva traz um conjunto distinto de responsabilidades, riscos e pontos de alavancagem. Independentemente de você gerenciar um centro de lucro, conduzir arquitetura empresarial, liderar segurança, governar dados ou supervisionar conformidade — este texto é escrito na linguagem do seu trabalho. É exatamente nessas funções que a IA autônoma prospera ou desaparece silenciosamente.

Orientação por Persona: Papéis e Responsabilidades

Para o Dono do Negócio: Conecte o Agente aos seus KPIs

Se você é responsável por um centro de lucro, não precisa de um brinquedo tecnológico novo. O que você realmente precisa é reduzir o número de tickets abertos, diminuir os dias do seu ciclo de conversão de caixa, reduzir carrinhos de compras abandonados, diminuir exceções de conformidade. Um agente é útil apenas quando pode ser conectado diretamente a esses números.

O primeiro passo é escrever uma descrição de trabalho para o agente da mesma forma que você faria para um novo funcionário. Algo como: “Este agente recebe uma entrada de tipo X, verifica Y, executa Z e encaminha para essa equipe quando termina.” Inclua o que significa “terminar” em termos operacionais: tempo de resposta, limiar de qualidade, gatilhos de escalação, e compromissos voltados para o cliente.

O segundo passo é fundamentar o caso de negócio nos números que sua equipe já acompanha. Quantas unidades por semana passam por esse fluxo de trabalho? Qual é o custo unitário em mão de obra, retrabalho e perdas? Quanto tempo fica aguardando em filas? Com que frequência retorna porque falta algo ou está errado? Se você não consegue responder essas perguntas hoje, seu primeiro projeto não é um agente — é instrumentalizar o fluxo de trabalho.

O terceiro passo é a sequência de implementação. No início da jornada, o agente mais útil é frequentemente aquele que elimina transferências manuais: lê a solicitação de entrada, coleta contexto de múltiplos sistemas, propõe um plano, e entrega esse plano à sua equipe com tudo pré-preparado. Pode não fechar a solução sozinho, mas remove horas ou dias de ida e volta entre equipes. Ganhos de economia como este constroem credibilidade com o CFO e lhe dão capital político para perseguir casos de uso mais ambiciosos, focados em receita, depois.

O dono do negócio não precisa entender modelos ou prompts. Precisa possuir um pequeno portfólio de trabalhos de agentes conectados diretamente às suas métricas e insistir que cada iniciativa comece com um contrato de trabalho escrito, não com um slide com um rótulo bonito.

Para o CTO ou Arquiteto Chefe: Decida se Quer Dez ou Cem Agentes

Se você é CTO, um dos seus maiores riscos é o sucesso. Assim que o primeiro agente funciona bem, outras equipes vão querer um. Se cada equipe constrói seu próprio stack — framework próprio, conectores próprios, modelo de acesso próprio — você acabará com um zoológico de agentes que parecem diferentes, são testados diferentemente, e são impossíveis de monitorar como um todo.

A questão arquitetural é simples de enunciar, mas difícil de executar: você quer dez agentes impressionantes pontuais, ou quer um sistema que suporte com segurança cem agentes?

O caminho sistêmico exige trabalho árduo no início. Significa padronizar como as ferramentas são expostas para que cada agente chame a mesma integração quando precisa ler dados de clientes, atualizar um ticket, ou processar um pagamento. Significa separar pensamento de ação no seu design: um componente planeja, outro chama ferramentas, outro valida conformidade, outro explica decisões aos usuários. Significa capturar rastreamentos de decisões em um formato consistente para que observabilidade e debug funcionem entre casos de uso. E exige pensar em agentes como serviços de longa duração, não scripts de curta vida. Precisam de identidades, permissões, rotação de credenciais, gestão de ciclo de vida, e uma forma de serem atualizados sem quebrar seus consumidores.

É mais trabalho no dia um, mas é o que permite você dizer “sim” à décima equipe que quer um agente sem começar do zero. O trabalho do CTO não é escolher o melhor framework de agentes no vácuo. É construir um piso robusto — identidade, execução de políticas, logging, conectores, e ganchos de avaliação — que permita muitas equipes entregar agentes com segurança, rapidez e consistência.

Para o CISO: Trate Agentes como Colegas, Não como Código

Se você é responsável por segurança, está acostumado a pensar em ativos: sistemas, repositórios de dados, credenciais. Agentes adicionam algo novo ao seu modelo de ameaça: entidades autorizadas que podem tomar decisões e executar ações à velocidade da máquina. O erro é tratar agentes como apenas outra aplicação. Eles são mais parecidos com colegas. Têm contas. Têm papéis. Têm ferramentas que podem usar. Podem cometer erros. Podem ser mal configurados.

A abordagem prática é configurar identidades não-humanas para agentes com a mesma seriedade que você aplica a identidades humanas. Cada agente deve ter suas próprias credenciais, suas próprias permissões, e seu próprio rastro de auditoria. Não deve herdar todos os direitos da conta de serviço na qual acaba sendo executado. Quando um agente lê dados sensíveis ou chama uma ferramenta de alto risco, isso deve ser visível em seus logs de forma que sua equipe reconheça.

Você também vai querer formas de parar agentes de forma limpa. Isso significa interruptores de emergência que realmente funcionam, não apenas uma linha em um documento de design. Significa políticas que dizem “Esta classe de ação sempre exige aprovação humana” e as impõe no nível da ferramenta, não apenas no prompt do agente. Significa observar comportamentos que se desviam: um agente que de repente chama uma ferramenta muito mais vezes que o usual, ou começa a ler dados que não precisava antes.

CISOs que se adaptam bem à IA autônoma não tentam bloquear autonomia inteiramente. Definem onde a autonomia é aceitável, que evidências são necessárias para confiar nela, e o que acontece quando essa confiança é quebrada. Participam da conversa de design cedo e fazem política parte da forma do agente, não uma porta de entrada no final.

Para o Diretor de Dados: Torne os Dados Mundanos

Agentes amplificam qualquer base de dados que você já possui. Se seus dados são fragmentados, desatualizados e mal documentados, agentes podem tornar esses problemas visíveis para todos rapidamente. Se seus dados são consistentes, bem governados e simples de entender, agentes podem multiplicar seu valor.

O trabalho do CDO na era dos agentes é tornar os dados mundanos, da melhor forma possível. Significa que quando um agente pergunta “mostre-me todos os sinistros abertos acima desse limite”, ele recebe uma resposta consistente independentemente de qual região ou linha de negócio está operando. Significa que existe uma única definição de “pontuação de saúde do cliente” e é documentada bem o suficiente para que pessoas e agentes a usem. Significa que a linhagem é clara: quando algo dá errado, você consegue rastrear a decisão através das métricas, através das features, até o sistema de origem.

Também significa ser realista sobre prontidão. Alguns fluxos de trabalho simplesmente não estão prontos para decisões autônomas porque os dados nos quais dependem são muito incompletos ou contraditórios. Os melhores CDOs abraçam isso. Não dizem “não conseguimos suportar agentes.” Dizem “conseguimos suportar essa classe de trabalho hoje. Se quer automatizar aquela outra classe, aqui estão as melhorias de dados que precisamos primeiro.”

Uma das contribuições mais valiosas que um CDO pode dar à conversa sobre agentes é um mapa: quais domínios têm dados em qualidade de produção, quais estão em progresso, e onde estão as armadilhas. Esse mapa ajuda todos os outros a escolherem seus primeiros trabalhos com sabedoria, em vez de descobrir débito técnico de dados no meio da implementação.

Para o Chefe de Ciência de Dados ou IA: Avaliação é seu Produto Real

Se você lidera ciência de dados ou IA, é tentador focar em modelos: qual modelo fundacional, qual técnica de fine-tuning, qual pontuação em benchmarks. Essas decisões importam, mas em produção, seu produto real é o sistema de avaliação que envolve o modelo. Agentes podem falhar de formas que benchmarks não medem. Ficam presos em loops. Chamam ferramentas incorretamente. Completam tarefas parcialmente de forma que parecem plausíveis mas estão erradas. Se comportam bem em dados de teste limpos e desabam em casos extremos que ninguém pensou em incluir.

Um sistema de avaliação efetivo faz três coisas. Primeiro, transforma trabalho real em testes. Quando um agente comete um erro em produção, esse cenário se torna parte de uma suíte de avaliação crescente. Com o tempo, os casos mais difíceis que você encontra se tornam guardrails que protegem você de regressões. Segundo, executa automaticamente. Mudanças em prompts, modelos, ferramentas, ou índices de recuperação desencadeiam avaliação antes dessa mudança ir para produção. Isso lhe dá confiança para iterar rapidamente, porque você não está contando com alguns testes pontuais e esperança. Terceiro, mede o que o negócio se importa. Isso inclui métricas técnicas como latência e taxa de sucesso das ferramentas, mas também taxa de conclusão de tarefas, taxa de escalação, custo por decisão, e a parcela de trabalho onde humanos aceitam a recomendação do agente como está.

Quando esses números são visíveis e melhorando, a confiança segue. Equipes que investem aqui cedo descobrem que escolhas de modelos ficam mais simples, não mais difíceis. Uma vez que você pode ver como um modelo se comporta em suas tarefas reais, o debate “qual modelo é melhor?” se torna uma comparação fundamentada em vez de uma discussão filosófica.

Para o Oficial de Conformidade ou Legal: Projete para Auditorias Antes de Enfrentá-las

Se você é responsável por conformidade ou risco legal, IA autônoma provavelmente parece um alvo móvel. Regulações estão evoluindo, e marketing de fornecedores está à frente da clareza regulatória. Você não pode congelar a organização até cada padrão se estabelecer, mas também não pode tolerar “vamos resolver a governança depois.”

Uma abordagem pragmática é trabalhar para trás a partir de uma auditoria. Imagine um regulador ou comitê de auditoria interna perguntando “nessa data, por que esse agente tomou essa ação?” Decida agora que evidências você precisaria para responder essa pergunta claramente e rapidamente. Isso implica algumas escolhas de design. Cada agente deve deixar um rastro: que inputs viu, que ferramentas chamou, que opções considerou, o que escolheu, e que regras aplicou. Para domínios de alto risco como decisões de crédito, subscrição de seguros, e ações relacionadas a emprego, humanos devem permanecer no loop, e o papel do agente deve ser consultivo ou preparatório: coletando dados, organizando evidências, propondo ações. A aprovação do humano se torna parte do registro.

Também implica que nem toda ideia de agente é permitida. Alguns casos de uso vivem solidamente dentro de zonas de risco regulatório até que frameworks e controles amadureçam. Seu trabalho é tornar essas linhas visíveis cedo. Quando você consegue dizer “sim” a alguns agentes com condições claras, “sim depois” a outros com pré-requisitos específicos, e “não” a alguns poucos com lógica clara, você pode se tornar um facilitador em vez de um bloqueador.

Uma das coisas mais úteis que você pode fazer para o resto da equipe de liderança é transformar preocupações abstratas como “precisamos de IA responsável” em uma checklist concreta que pode ser aplicada a cada agente proposto antes do trabalho começar.

Cinco Movimentos para Começar

Se os padrões neste artigo soam familiares, você não está atrasado. Você está onde a maioria das empresas está. O que separa quem avança é a decisão de tratar IA autônoma como um desafio de modelo operacional, não como um experimento tecnológico.

Convoque a sala certa. Reúna seu dono de linha de negócio, CTO, CISO, CDO, líder de IA/Ciência de Dados, e responsável de conformidade — não para uma demonstração, mas para uma sessão de trabalho. Cada pessoa responde uma pergunta: “Qual é a única coisa mais importante bloqueando a gente de colocar um agente em produção em um fluxo de trabalho real?” A partir daí, identifique padrões. Alinhe sobre prioridades comuns.

Escolha um trabalho, não um caso de uso. Identifique uma peça de trabalho concreta com início claro, fim claro, ferramentas definidas, e medida de sucesso que alguém fora da equipe pode verificar. Escreva a descrição de trabalho do agente juntos. Se a sala não conseguir concordar no que significa “concluído”, encontrou o primeiro problema a resolver.

Desenhe seu mapa de prontidão. Tenha seu CDO e CISO esboçar conjuntamente quais domínios de dados e sistemas estão prontos para decisões autônomas hoje, quais precisam de melhorias primeiro, e onde estão as fronteiras rígidas. Esse mapa de uma página pode economizar meses de esforço desperdiçado.

Comprometa-se com uma cadência. Configure uma revisão recorrente semanal ou quinzenal onde a equipe multifuncional examina como o agente se comportou, o que funcionou, o que quebrou, e o que ajustar. Se você só avalia no lançamento, está construindo uma demonstração. Se avalia continuamente, está construindo uma capacidade.

Faça da governança uma entrada de design, não uma porta de lançamento. Decida agora que evidências você precisaria se um auditor perguntasse “por que esse agente fez isso?” seis meses a partir de hoje. Integre isso na arquitetura antes da primeira linha de código ser escrita.

Próximos Passos

As empresas que geram valor real de IA autônoma chegaram lá fazendo o trabalho sem glória: definindo trabalhos com precisão, limitando autonomia deliberadamente, investindo relentlessly em avaliação, e alinhando stakeholders em um modelo operacional compartilhado. Não é tecnologia sofisticada que diferencia — é disciplina organizacional.

Se você está planejando seu primeiro piloto de agentes ou escalando para uma capacidade em toda a empresa, o Centro de Inovação em IA Generativa da AWS está disponível para uma conversa fundamentada em seus fluxos de trabalho, seus dados, e seus resultados de negócio.

Fonte

Agentic AI in the Enterprise Part 2: Guidance by Persona (https://aws.amazon.com/blogs/machine-learning/agentic-ai-in-the-enterprise-part-2-guidance-by-persona/)