Auditoria comunitária reforça conformidade na nuvem
A Amazon Web Services (AWS) finalizou sua segunda auditoria comunitária junto à GDV (Associação Alemã de Seguros), contando com a participação de 36 membros do setor segurador alemão. Esses participantes representam cobertura superior a 63% do mercado segurador nacional em termos de prêmios de seguro. As auditorias comunitárias funcionam como um mecanismo eficiente para oferecer garantias adicionais a grupos de clientes quanto à segurança da computação em nuvem, complementando o Modelo de Responsabilidade Compartilhada da AWS, os Programas de Conformidade da AWS e recursos disponibilizados através do AWS Artifact.
Por que a segurança em nuvem importa para o setor financeiro
Para a AWS, a segurança representa a prioridade máxima. À medida que clientes adotam a escalabilidade e flexibilidade da plataforma, a empresa se dedica a transformar segurança e conformidade em facilitadores de negócios. O foco está em conquistar e manter a confiança de clientes do setor financeiro e suas autoridades regulatórias, garantindo que existem controles adequados para proteger materiais sensíveis e cargas de trabalho reguladas.
A transformação digital crescente no setor financeiro, com a computação em nuvem como tecnologia habilitadora chave, intensificou o escrutínio regulatório. O engajamento da AWS com membros da GDV exemplifica como a empresa apoia esforços de gestão de risco e conformidade regulatória de seus clientes.
Estrutura e escopo da auditoria
Sobre a GDV e seus participantes
A GDV é a associação das seguradoras privadas na Alemanha, representando aproximadamente 470 membros do setor e um ator relevante nas indústrias financeiras alemã e europeia. Os membros participantes desta auditoria comunitária acionaram seus direitos de auditoria conforme disposições da Lei de Resiliência Operacional Digital (DORA), requisitos da BaFin e diretrizes da EIOPA sobre terceirização para provedores de serviços em nuvem.
Preparação e definição de escopo
Neste segundo ciclo, uma única empresa de auditoria externa foi contratada em nome dos 36 membros participantes do setor segurador alemão. O escopo foi delimitado com referência ao framework C5 do BSI (Escritório Federal Alemão para Segurança da Informação), incluindo domínios-chave e áreas de controle. A avaliação enfatizou serviços AWS como Amazon Elastic Compute Cloud (Amazon EC2) e a região relevante para participantes — Europa (Frankfurt) — designada como eu-central-1.
Processo de auditoria
Fase de trabalho de campo
Após discussão inicial em Berlim, a auditoria adotou metodologia remota, utilizando videoconferência e portal seguro de auditoria para inspeção de evidências. Os auditores realizaram avaliação detalhada de políticas, procedimentos e controles da AWS através de análise de documentação, sessões profundas com especialistas em assuntos técnicos e perguntas de esclarecimento sobre as evidências apresentadas.
Resultados obtidos
A auditoria foi executada e concluída conforme modelo de engajamento mutuamente acordado entre AWS, membros participantes e auditores externos, durante o qual os participantes exerceram seus direitos de auditoria em conformidade com condições contratuais. Após revisão pela AWS para confirmação da precisão factual do conteúdo, os auditores finalizaram o relatório.
Os resultados da auditoria comunitária da GDV estão disponíveis exclusivamente aos membros participantes e suas autoridades regulatórias. A auditoria ofereceu aos membros da GDV garantias quanto ao ambiente de controles da AWS, possibilitando a remoção de obstáculos de conformidade, aceleração da adoção de serviços AWS e maior confiança nos controles de segurança da plataforma.
Perspectiva das seguradoras participantes
Do ponto de vista das companhias de seguros participantes, a segunda auditoria conjunta na AWS foi percebida como eficiente e benéfica ao reduzir encargos individuais de auditoria enquanto entregava resultados confiáveis de garantia. Simultaneamente, o planejamento abrangente e coordenação necessária demandou esforço substancial.
A coordenação com a GDV e o engajamento com a DCSO Deutsche Cybersicherheitsorganisation GmbH como fornecedor profissional externo de auditoria ajudou a simplificar a comunicação com a AWS e assegurou abordagem consistente entre todos os participantes. A cooperação entre seguradoras da GDV, auditores da DCSO e AWS manteve-se profissional e construtiva durante todo o processo.
Destacou-se a presença, pela primeira vez, de dois representantes de companhias de seguros nas entrevistas técnicas, proporcionando impressão ainda melhor sobre a qualidade do processo de auditoria.
Próximos passos e referências
Para aprofundamento em programas de conformidade e segurança, consulte os Programas de Conformidade da AWS. Clientes e organizações que desejam dialogar com a equipe de conformidade da AWS podem utilizar a página de contato disponibilizada.
A AWS anunciou a disponibilidade das experiências de fala para fala com agentes de IA no Amazon Connect em uma nova região: Europe (London). Essa expansão permite que empresas operando na Europa ampliem seus serviços de atendimento ao cliente com tecnologia de IA conversacional, mantendo os dados mais próximos aos clientes europeus e atendendo requisitos locais de conformidade.
Novas Vozes para Interações Naturais
Acompanhando a expansão geográfica, a AWS adicionou três novas vozes ao catálogo de opções de fala: Pedro (espanhol dos EUA), Amy (inglês britânico) e Brian (inglês britânico). Essa ampliação do repertório de vozes oferece às empresas maior flexibilidade para personalizar as interações com clientes em diferentes idiomas e regiões.
Capacidades de Agentes Inteligentes
O Amazon Connect oferece capacidades de autoatendimento com agentes autônomos que vão além da simples captura de áudio. Esses agentes de IA conseguem compreender não apenas o que o cliente diz, mas também como diz — interpretando tom e sentimento. Com base nesses sinais, o agente adapta suas respostas de voz para corresponder ao sentimento do cliente, mantendo um ritmo de conversação natural e fluido.
Os agentes inteligentes do Amazon Connect podem:
Compreender intenções e contexto em conversas por voz e mensagens
Raciocinar sobre a melhor ação a tomar para resolver o problema
Executar ações automaticamente para tarefas rotineiras e complexas
Adaptar o tom e sentimento da resposta ao estado emocional do cliente
Manter interações naturais e envolventes sem parecer robótico
Impacto para Empresas Brasileiras
Para empresas brasileiras com operações na Europa ou clientes europeus, essa expansão representa a oportunidade de implementar centros de contato inteligentes que funcionem na região Europe (London), reduzindo latência e garantindo conformidade com regulamentações de proteção de dados. A adição da voz Pedro em espanhol também abre possibilidades para atendimento em português do Brasil no futuro, seguindo o padrão de expansão de idiomas da plataforma.
Próximos Passos
Para conhecer mais detalhes sobre essa funcionalidade, consulte a documentação do Amazon Connect. Para explorar completamente as capacidades do Amazon Connect como solução completa de centro de contato alimentada por IA, visite a página oficial do serviço.
A expansão do suporte multilíngue no Amazon Connect
A AWS anunciou uma expansão significativa no Amazon Connect, serviço de centro de contato alimentado por inteligência artificial. A plataforma agora suporta 13 novos idiomas para agentes de voz com IA, elevando o total de locales de idiomas suportados para 40.
Essa ampliação democratiza o acesso a tecnologias avançadas de atendimento ao cliente para empresas que operam em mercados linguisticamente diversos. Entre os idiomas adicionados estão árabe (Arábia Saudita), tcheco, dinamarquês, holandês (Bélgica), inglês (Irlanda), inglês (Nova Zelândia), inglês (País de Gales), alemão (Suíça), islandês, romeno, espanhol (México), turco e galês.
Capacidades dos agentes autônomos do Amazon Connect
Os agentes de voz com IA do Amazon Connect possuem capacidades sofisticadas de autoatendimento. Esses agentes conseguem compreender requisições dos clientes, raciocinar sobre contextos complexos e executar ações específicas de forma autônoma.
Funcionam de maneira integrada tanto em canais de voz quanto em canais digitais, permitindo que empresas automatizem tarefas rotineiras e até mesmo processos mais complexos de atendimento ao cliente. Tudo isso agora com suporte expandido para múltiplos idiomas, incluindo as novas adições anunciadas.
Relevância para o mercado brasileiro
Para empresas brasileiras e latino-americanas, essa atualização traz uma oportunidade importante. Com o suporte ao espanhol (México) e a possibilidade de operar em diversos idiomas europeus, organizações que atuam em múltiplos países ganham mais flexibilidade operacional em seus centros de contato globais.
Próximos passos
Para organizações interessadas em explorar essas novas funcionalidades, a AWS disponibiliza documentação técnica completa. Você pode consultar o Guia do Administrador do Amazon Connect para detalhes sobre implementação.
Sobre a plataforma em si, o Amazon Connect é uma solução completa de centro de contato potencializada por inteligência artificial, projetada para entregar experiências personalizadas de atendimento em escala. Para conhecer mais sobre o serviço e suas capacidades, visite o site do Amazon Connect.
O SageMaker Training Plans permite que organizações reservem capacidade de GPU (Processador Gráfico) dentro de períodos de tempo específicos, trabalhando com clusters de até 64 instâncias. A AWS anunciou uma atualização importante para esse serviço: agora é possível estender os planos de treinamento quando as cargas de trabalho de inteligência artificial demandam mais tempo que o originalmente previsto.
Essa extensão garante acesso ininterrupto à infraestrutura de GPU sem interrupções nas operações. A AWS oferece dois tipos de extensão: incrementos de 1 dia, estendendo o plano por até 14 dias, ou incrementos de 7 dias, permitindo extensões de até 182 dias (26 semanas).
Como funcionam as extensões
Processo simplificado
As extensões podem ser iniciadas tanto via API quanto pelo console do SageMaker, tornando o processo acessível para diferentes fluxos de trabalho. O aspecto mais relevante é que, após a compra da extensão, a carga de trabalho continua executando ininterruptamente. Nenhuma reconfiguração do workload é necessária — a continuidade é automática.
Provisão automática de infraestrutura
O SageMaker AI gerencia todo o ciclo de vida dos planos de treinamento de forma autônoma. Quando um plano é criado e adquirido, o SageMaker provisiona automaticamente a infraestrutura necessária e executa as cargas de trabalho de inteligência artificial nesses recursos computacionais sem exigir intervenção manual.
Considerações de custos e disponibilidade
Para otimizar investimentos em treinamento de modelos, a AWS desenvolve planos de treinamento pensados em eficiência de custos. O objetivo é criar planos que se adequem aos prazos e orçamentos de inteligência artificial das organizações. Consulte a página de preços do SageMaker AI para um detalhamento completo da disponibilidade de instâncias por região da AWS.
Documentação e próximos passos
Para aprofundar-se nas funcionalidades de extensão de planos de treinamento, a AWS disponibiliza o Guia do Usuário do Amazon SageMaker Training Plans, com documentação técnica detalhada e orientações práticas para implementação.
A AWS anunciou, em março de 2026, o suporte a ingestão de logs através de protocolo HTTP no CloudWatch Logs. Essa funcionalidade oferece uma alternativa importante para cenários onde a integração nativa com o SDK da AWS não é possível — como acontece frequentemente com softwares de terceiros e aplicações empacotadas.
A novidade suporta múltiplos formatos e padrões de envio de logs, cada um adequado a diferentes casos de uso e padrões de integração:
Formatos e endpoints disponíveis
HTTP Log Collector (HLC)
O endpoint https://logs.<region>.amazonaws.com/services/collector/event foi desenvolvido para processar eventos JSON. Essa opção é ideal para organizações que já possuem pipelines de logs estabelecidos e desejam migrá-los para o CloudWatch sem redesenhar a infraestrutura.
ND-JSON (newline-delimited JSON)
Disponível em https://logs.<region>.amazonaws.com/ingest/bulk, esse formato é otimizado para cenários de alto volume. Cada linha representa um evento de log independente, tornando-o especialmente adequado para ingestão em lote (bulk) e streaming contínuo de dados.
Structured JSON
Por meio do endpoint https://logs.<region>.amazonaws.com/ingest/json, é possível enviar um único objeto JSON ou um array de objetos. Essa flexibilidade permite adaptar diferentes estruturas de dados de log.
OpenTelemetry (OTEL)
O endpoint https://logs.<region>.amazonaws.com/v1/logs aceita logs no formato OTLP, em codificação JSON ou Protobuf. Essa integração reforça o suporte da AWS ao padrão aberto de observabilidade.
Segurança e configuração
Para ativar o endpoint HTTP Log Collector, os usuários devem acessar as configurações do CloudWatch no console da AWS e gerar uma chave de API. O CloudWatch cria automaticamente um usuário IAM com credenciais específicas do serviço e permissões apropriadas.
As chaves de API podem ser configuradas com períodos de expiração de 1, 5, 30, 90 ou 365 dias, permitindo flexibilidade na estratégia de rotação de credenciais. Além disso, antes que um grupo de logs possa receber eventos via HTTP, é necessário habilitar explicitamente a autenticação por bearer token — uma medida de proteção que evita ingestão não intencional de dados.
Para maior controle, os administradores podem utilizar Service Control Policies para bloquear a criação de credenciais específicas do serviço, reforçando os controles de segurança em nível organizacional.
Disponibilidade regional
No lançamento inicial, esses endpoints estão disponíveis nas seguintes regiões da AWS: US East (N. Virginia), US West (N. California), US West (Oregon) e US East (Ohio).
Próximos passos
Para explorar detalhes técnicos sobre o endpoint HLC e as melhores práticas de segurança, consulte a documentação do CloudWatch Logs.
O Amazon Neptune anunciou uma novidade relevante para quem trabalha com análise de grafos em nuvem. A partir de agora, é possível ler dados armazenados no Amazon S3 diretamente através de consultas openCypher, sem necessidade de carregar os dados previamente na base do Neptune.
O recurso funciona através de um novo procedimento chamado neptune.read(), que oferece uma alternativa prática à abordagem tradicional de federação com dados externos. Para organizações que utilizam Neptune em análise de grafos, isso representa uma flexibilidade adicional: a possibilidade de incorporar dinamicamente dados armazenados em S3 sem seguir o fluxo de trabalho convencional em várias etapas.
Aplicações Práticas
Existem diferentes cenários em que essa nova funcionalidade se torna útil. A análise de grafos em tempo real que combine dados do S3 com estruturas gráficas já existentes é um deles. Também é possível criar dinamicamente nós e arestas a partir de conjuntos de dados externos, bem como executar consultas gráficas complexas que necessitam referenciar dados armazenados fora do Neptune.
Segurança e Compatibilidade de Dados
O procedimento suporta uma gama abrangente de tipos de dados, incluindo formatos padrão e específicos do Neptune, como geometria e datetime. A segurança é mantida através das credenciais de Identidade e Acesso da Conta (IAM) de quem está realizando a consulta, garantindo que apenas usuários autorizados possam acessar os dados.
A funcionalidade está disponível em todas as regiões onde o Amazon Neptune Database é atualmente oferecido.
Para Saber Mais
Quem deseja aprofundar-se nos detalhes técnicos e nas melhores práticas de implementação pode consultar a documentação do Neptune Database, onde encontrará guias completos e exemplos de uso.
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.
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:
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:
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.
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.
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.
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).
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.
