A Amazon Bedrock expandiu seu catálogo de modelos de inteligência artificial com o anúncio do Nemotron 3 Super, desenvolvido pela NVIDIA. Trata-se de um modelo de arquitetura híbrida baseado em Mixture-of-Experts (MoE) — uma abordagem que combina múltiplos especialistas para processar diferentes tipos de informação de forma mais eficiente.
Este modelo foi especificamente projetado para atender workloads de natureza agentica, ou seja, aplicações onde agentes de IA precisam executar tarefas complexas em múltiplas etapas mantendo contexto e precisão ao longo de toda a operação. O Nemotron 3 Super oferece inferência rápida e otimizada em termos de custo, reduzindo o consumo de recursos computacionais sem comprometer a qualidade das respostas.
Abertura e Flexibilidade Técnica
Um dos diferenciais do Nemotron 3 Super é sua natureza completamente aberta. A NVIDIA disponibilizou não apenas os pesos do modelo (os parâmetros treinados), mas também os datasets utilizados no treinamento e as receitas — ou seja, as configurações e metodologias empregadas na construção do modelo.
Essa abordagem de código aberto facilita a customização por parte das organizações, permitindo que empresas, startups e desenvolvedores individuais adaptem o modelo para suas necessidades específicas. Ao mesmo tempo, a transparência técnica contribui para implantações seguras, fundamental para contextos empresariais que exigem conformidade e auditoria.
Integração Simplificada via Amazon Bedrock
A grande vantagem de acessar o Nemotron 3 Super através da Amazon Bedrock é a eliminação da complexidade operacional. Em vez de gerenciar infraestrutura própria, provisionar servidores ou fazer o host do modelo, os usuários acessam o modelo através de uma API única totalmente gerenciada.
O Bedrock oferece inferência sem servidor, o que significa que não há necessidade de preocupação com capacidade, escalabilidade ou manutenção de infraestrutura. Além disso, o serviço inclui controles de segurança integrados, garantindo que os dados processados sejam protegidos conforme os padrões corporativos.
Compatibilidade com OpenAI API
Um detalhe técnico importante é que o Nemotron 3 Super, quando acessado via Bedrock, é compatível com as especificações da API OpenAI. Isso significa que desenvolvedores que já trabalham com essa interface padrão podem integrar o modelo em seus fluxos de trabalho existentes com mínimas alterações de código. Essa compatibilidade reduz significativamente a curva de aprendizado e o tempo de implementação.
Disponibilidade e Próximos Passos
O Nemotron 3 Super está disponível na Amazon Bedrock em regiões selecionadas da AWS. Para conhecer a lista completa de regiões onde o modelo está disponível, consulte a documentação sobre compatibilidade de modelos.
Desenvolvedores interessados em começar a usar o modelo podem acessar o console da Amazon Bedrock ou consultar a documentação técnica do serviço. Para quem busca começar especificamente com os endpoints compatíveis com a API OpenAI, a AWS fornece documentação detalhada sobre como iniciarse com essa abordagem.
Descoberta de uma Campanha de Ransomware com Zero-Day
As equipes de inteligência de ameaças da AWS identificaram uma campanha ativa do ransomware Interlock que explorra a CVE-2026-20131, uma vulnerabilidade crítica no software do Centro de Gerenciamento de Firewall Seguro Cisco (FMC). Esta vulnerabilidade permite que um atacante não autenticado execute código Java arbitrário com privilégios de root em um dispositivo afetado. A vulnerabilidade foi divulgada publicamente pela Cisco em 4 de março de 2026.
O que torna este caso particularmente preocupante é o cronograma: a pesquisa revelou que o grupo Interlock estava explorando esta vulnerabilidade desde 26 de janeiro de 2026 — 36 dias antes do conhecimento público. Em outras palavras, o grupo possuía um zero-day em mãos, tendo uma semana de vantagem para comprometer organizações antes que os defensores soubessem que deveriam investigar.
Após descobrir essa atividade, a AWS compartilhou seus achados com a Cisco para apoiar a investigação e proteger os clientes. Um erro operacional crítico — um servidor de infraestrutura mal configurado — expôs o arsenal completo do grupo Interlock. Este acidente raro forneceu aos times de segurança da AWS visibilidade sobre a cadeia de ataque multi-estágio do grupo ransomware, incluindo trojans de acesso remoto customizados, scripts de reconhecimento automatizados e técnicas sofisticadas de evasão.
É importante notar que a infraestrutura da AWS e as cargas de trabalho de clientes não foram observadas como envolvidas nesta campanha.
Cronologia da Descoberta e Investigação
A equipes de inteligência de ameaças da AWS começou a identificar atividade potencialmente relacionada à CVE-2026-20131 em 26 de janeiro de 2026, antecedendo a divulgação pública. A atividade observada envolvia requisições HTTP para um caminho específico no software afetado, com corpos contendo tentativas de execução de código Java e duas URLs incorporadas: uma para entregar dados de configuração e outra para confirmar a exploração bem-sucedida.
Para avançar na investigação e obter inteligência de ameaças adicional, os analistas simularam a resposta esperada — fingindo ser um sistema compromitido com sucesso. Esta ação acionou corretamente o grupo Interlock a prosseguir para a próxima fase, emitindo comandos para buscar e executar um binário ELF malicioso (arquivo executável Linux) de um servidor remoto. Quando os analistas recuperaram o binário, descobriram que o mesmo host era usado para distribuir todo o arsenal operacional do Interlock.
A infraestrutura exposta estava organizada com artefatos em caminhos separados correspondendo a alvos individuais — os mesmos caminhos utilizados tanto para baixar ferramentas para hosts compromitidos quanto para fazer upload de artefatos operacionais de volta ao servidor de staging.
Atribuição ao Ransomware Interlock
O binário ELF e artefatos associados foram atribuídos à família de ransomware Interlock através de indicadores técnicos e operacionais convergentes. A nota de resgate incorporada e o portal de negociação TOR são consistentes com a marca estabelecida do Interlock e sua infraestrutura. A nota invoca múltiplas regulações de proteção de dados — uma prática documentada do Interlock de citar exposição regulatória para pressionar vítimas, essencialmente ameaçando organizações não apenas com criptografia de dados, mas com multas regulatórias e violações de conformidade.
O identificador de organização específico da campanha incorporado na nota se alinha com o modelo de rastreamento por vítima do Interlock. Historicamente, o grupo tem direcionado setores específicos onde a interrupção operacional cria pressão máxima para pagamento: educação representa a maior parte de sua atividade, seguida por firmas de engenharia, arquitetura e construção, organizações de manufatura e industriais, provedores de saúde, e entidades de governo e setor público.
A análise temporal de timestamps revelou que os atores provavelmente operam na zona UTC+3 com confiança de 75–80%. A análise sistemática mostrou que UTC+3 produziu o melhor ajuste: primeira atividade por volta de 08:30, pico de atividade entre 12:00 e 18:00, e uma provável janela de descanso de 00:30–08:30.
Análise Técnica: O Arsenal Operacional do Interlock
Script de Reconhecimento Pós-Comprometimento
Uma vez que o Interlock obtém acesso inicial, utiliza diversas ferramentas prioritárias para completar seu ataque. Os times de inteligência de ameaças da AWS recuperaram um script PowerShell projetado para enumeração sistemática do ambiente Windows. O script coleta detalhes do sistema operacional e hardware, serviços em execução, software instalado, configuração de armazenamento, inventário de máquinas virtuais Hyper-V, listagens de arquivos de usuários através de Desktop, Documents e Downloads, artefatos de navegadores (Chrome, Edge, Firefox, Internet Explorer e 360 browser, incluindo histórico, bookmarks, credenciais armazenadas e extensões), conexões de rede ativas correlacionadas com processos responsáveis, tabelas ARP, dados de sessões iSCSI e eventos de autenticação RDP a partir dos logs de eventos do Windows.
O script encena resultados em um compartilhamento de rede centralizado usando o nome de host totalmente qualificado de cada sistema para criar diretórios dedicados — essencialmente criando uma pasta para cada computador compromitido. Após coleta, comprime dados em arquivos ZIP nomeados após cada hostname e remove os dados brutos originais. Este formato de saída estruturado por host indica que o script opera entre múltiplas máquinas dentro de uma rede — uma característica de cadeias de intrusão ransomware que se preparam para criptografia em toda a organização.
Trojans de Acesso Remoto Customizados
Trojans de acesso remoto (RATs) são programas maliciosos que fornecem aos atacantes controle persistente sobre sistemas compromitidos, funcionando como software de desktop remoto não autorizado.
Implant JavaScript: Os times de inteligência da AWS recuperaram um trojan de acesso remoto JavaScript ofuscado que suprime saída de debug sobrescrevendo métodos de console do navegador. Na execução, perfila o host infectado usando PowerShell e Windows Management Instrumentation (WMI), coletando identidade do sistema, associação de domínio, nome de usuário, versão do SO e contexto de privilégio antes de transmitir estes dados durante um handshake de inicialização criptografado. A comunicação com comando e controle ocorre sobre conexões WebSocket persistentes com mensagens criptografadas em RC4 usando chaves aleatórias de 16 bytes por mensagem incorporadas em cabeçalhos de pacotes — essencialmente, cada mensagem usa uma chave de criptografia diferente, tornando a interceptação mais difícil. O implant cicla através de múltiplos hostnames e endereços IP controlados pelo operador em ordem aleatória com backoff exponencial entre tentativas de reconexão. O implant fornece acesso interativo a shell, execução arbitrária de comando, transferência de arquivo bidirecional e capacidade de proxy SOCKS5 para tunelamento de tráfego TCP.
Implant Java: Um cliente funcionalmente equivalente implementado em Java fornece capacidades idênticas de comando e controle. Construído sobre bibliotecas do ecossistema GlassFish, utiliza Grizzly para transporte de I/O não-bloqueante e Tyrus para comunicação de protocolo WebSocket. Em termos mais simples, o Interlock construiu a mesma porta de fundos em duas linguagens de programação diferentes, garantindo que mantenha acesso mesmo se defensores detectem uma versão.
Script de Lavagem de Infraestrutura
Atores sofisticados não atacam a partir de sua própria infraestrutura — eles constroem redes relay descartáveis para esconder seus rastros. Os times de inteligência da AWS identificaram um script Bash que configura servidores Linux como proxies reversos HTTP (servidores intermediários que encaminham tráfego para esconder a localização real do atacante). O script executa atualizações de sistema, instala fail2ban com proteção contra força bruta SSH, e compila HAProxy 3.1.2 a partir do código-fonte. A instância HAProxy escuta na porta 80 e encaminha todo tráfego HTTP inbound para um IP alvo codificado, com systemd garantindo persistência através de reinicializações. Um componente notável é uma rotina de apagamento de logs executada como cron job a cada cinco minutos. A rotina trunca todos os arquivos *.log sob /var/log e suprime o histórico de shell alterando a variável HISTFILE. Esta destruição agressiva de evidências, limpando logs a cada cinco minutos, combinada com o propósito específico de proxy de encaminhamento HTTP, indica que o script estabelece nós relay descartáveis de lavagem de tráfego. Estes nós obscurecem a origem do tráfego de exploração, retransmitem comunicações de comando e controle, ou fazem proxy de exfiltração de dados, tornando praticamente impossível rastrear ataques de volta à sua fonte.
Webshell Residente em Memória
Os times de inteligência da AWS observaram um arquivo classe Java entregue como alternativa ao drop de binário ELF. Quando carregado pela Máquina Virtual Java (JVM), seu inicializador estático registra um ServletRequestListener com o StandardContext do servidor, essencialmente instalando uma porta de fundos persistente residente em memória que intercepta requisições HTTP sem escrever arquivos em disco. Esta abordagem “sem arquivos” elude a varredura tradicional de antivírus que busca por arquivos maliciosos. O listener inspeciona requisições recebidas procurando por parâmetros especialmente crafted contendo payloads de comando criptografados. Os payloads são descriptografados usando AES-128 com chave derivada do hash MD5 de um seed codificado. Os payloads descriptografados são tratados como bytecode Java compilado, dinamicamente carregados na JVM, e executados — uma técnica projetada para eludir detecção baseada em arquivo executando código malicioso inteiramente em memória.
Ferramenta de Verificação de Conectividade
Os times de inteligência da AWS recuperaram arquivos classe Java implementando um servidor TCP básico escutando em uma porta codificada para obscurecer o número da porta da análise estática. O servidor aceita conexões, registra endereços IP de conexão, envia uma mensagem de saudação, e imediatamente fecha conexões. Este perfil operacional é consistente com um beacon de rede leve — essencialmente uma ferramenta “phone home” utilizada para verificar execução bem-sucedida de código ou confirmar alcançabilidade de porta de rede após exploração inicial.
Abuso de Ferramentas Legítimas
O Interlock implantou ConnectWise ScreenConnect, uma ferramenta comercial legítima de desktop remoto, ao lado de implants customizados. Quando operadores de ransomware implantam ferramentas de acesso remoto legítimas ao lado de seu malware customizado, estão comprando seguro — se defensores encontram e removem uma porta de fundos, ainda possuem outro caminho de entrada. Isto indica múltiplos mecanismos de acesso remoto redundantes — um padrão consistente com operadores de ransomware buscando manter acesso mesmo se pontos de apoio individuais forem removidos. A pegada de rede legítima da ferramenta ajuda a se misturar com tráfego de administração remota autorizada, tornando a detecção mais desafiadora.
Os times de inteligência da AWS também recuperaram Volatility, um framework open-source de análise forense de memória tipicamente utilizado por respondentes de incidentes — a mesma ferramenta que defensores usam para investigar ataques. Enquanto nenhum artefato indicava uso automatizado, sua presença ao lado de implants customizados e scripts de reconhecimento é consistente com operações avançadas de ameaças. Tanto grupos de ransomware quanto atores de nível estatal foram observados implantando Volatility durante intrusões. O foco da ferramenta em parsear dumps de memória fornece acesso a dados sensíveis como credenciais armazenadas em RAM, que podem capacitar movimento lateral e comprometimento mais profundo do ambiente em apoio a operações de resgate ou objetivos de espionagem.
O Interlock também utilizou Certify, uma ferramenta ofensiva de segurança open-source projetada para explorar misconfigurations em Active Directory Certificate Services (AD CS). Para operadores de ransomware, Certify fornece um caminho para identificar templates de certificado vulneráveis e permissões de inscrição que permitem requisição de certificados com capacidade de autenticação. Estes certificados podem ser utilizados para impersonar usuários, escalar privilégios, ou manter acesso persistente. Estas capacidades apoiam diretamente ambos objetivos de comprometimento inicial e objetivos de persistência de longo prazo em operações de ransomware.
Indicadores de Comprometimento (IoCs)
Os seguintes indicadores apóiam medidas defensivas por organizações que possam ser afetadas. Devido ao uso de técnicas de variação de conteúdo pelo Interlock, a maioria dos hashes de arquivo não está incluída como indicadores confiáveis. O ator de ameaça modificou a maioria dos artefatos como scripts e binários baixados para diferentes alvos, resultando em diferentes hashes de arquivo para ferramentas funcionalmente idênticas. A customização permitiu que cada ataque eludisse detecção baseada em assinatura que busca por correspondências exatas de arquivo.
Endereços IP:
206.251.239[.]164 — IP fonte de exploração (ativo jan 2026)
199.217.98[.]153 — IP fonte de exploração (ativo mar 2026)
89.46.237[.]33 — IP fonte de exploração (ativo mar 2026)
144.172.94[.]59 — IP fallback C2 (ativo mar 2026)
199.217.99[.]121 — IP fallback C2 (ativo mar 2026)
188.245.41[.]78 — IP fallback C2 (ativo mar 2026)
144.172.110[.]106 — IP backend C2 (ativo mar 2026)
95.217.22[.]175 — IP backend C2 (ativo mar 2026)
37.27.244[.]222 — IP host de staging (ativo mar 2026)
Identificadores de Rede:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0 — User-Agent HTTP de exploração (observado jan e mar 2026)
b885946e72ad51dca6c70abc2f773506 — TLS JA3 de exploração (observado jan e mar 2026)
f80d3d09f61892c5846c854dd84ac403 — TLS JA3 de exploração (observado mar 2026)
t13i1811h1_85036bcba153_b26ce05bbdd6 — TLS JA4 de exploração (observado jan e mar 2026)
t13i4311h1_c7886603b240_b26ce05bbdd6 — TLS JA4 de exploração (observado mar 2026)
Domínios e URLs:
hxxp://ebhmkoohccl45qesdbvrjqtyro2hmhkmh6vkyfyjjzfllm3ix72aqaid[.]onion/chat.php — Portal de negociação de resgate (ativo mar 2026)
cherryberry[.]click — Domínio de suporte de exploração (ativo jan 2026)
ms-server-default[.]com — Domínio de suporte de exploração (ativo mar 2026)
initialize-configs[.]com — Domínio de suporte de exploração (ativo mar 2026)
ms-global.first-update-server[.]com — Domínio de suporte de exploração (ativo mar 2026)
ms-sql-auth[.]com — Domínio de suporte de exploração (ativo mar 2026)
kolonialeru[.]com — Domínio de suporte de exploração (ativo mar 2026)
sclair.it[.]com — Domínio de suporte de exploração (ativo mar 2026)
browser-updater[.]com — Domínio C2 (ativo mar 2026)
browser-updater[.]live — Domínio C2 (ativo mar 2026)
os-update-server[.]com — Domínio C2 (ativo mar 2026)
os-update-server[.]org — Domínio C2 (ativo mar 2026)
os-update-server[.]live — Domínio C2 (ativo mar 2026)
os-update-server[.]top — Domínio C2 (ativo mar 2026)
Hashes de Artefatos:
d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be — Ferramenta de segurança ofensiva (Certify) observada mar 2026
6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f — Screen locker observado mar 2026
Recomendações Defensivas
As organizações devem executar as seguintes ações para se proteger contra operações de ransomware Interlock.
Ações Imediatas
Aplicar patches de segurança da Cisco para o Centro de Gerenciamento de Firewall Seguro Cisco
Revisar logs em busca dos indicadores de comprometimento listados acima
Conduzir avaliações de segurança para identificar comprometimento potencial
Revisar implantações de ScreenConnect em busca de instalações não autorizadas
Oportunidades de Detecção
Monitorar scripts PowerShell encenando dados em compartilhamentos de rede com estruturas de diretório baseadas em hostname
Detectar registros de ServletRequestListener em contextos de aplicações web Java (modificações incomuns em aplicações web Java)
Identificar instalações de HAProxy com agressivos cron jobs de exclusão de logs (servidores proxy que apagam seus próprios logs a cada cinco minutos)
Monitorar conexões TCP para portas numeradas incomuns
Medidas de Longo Prazo
Implementar estratégias de defesa em profundidade com múltiplas camadas de controles de segurança
Manter capacidades contínuas de monitoramento e busca de ameaças
Garantir logging abrangente com armazenamento de logs centralizado e seguro (armazenado separadamente de sistemas que podem ser comprometidos)
Testar regularmente procedimentos de resposta a incidentes para cenários de ransomware
Educar times de segurança sobre táticas, técnicas e procedimentos do Interlock
Entendendo o Contexto Maior
A história real aqui não é apenas sobre uma vulnerabilidade ou um grupo de ransomware — é sobre o desafio fundamental que exploits zero-day colocam em todos os modelos de segurança. Quando atacantes exploram vulnerabilidades antes que patches existam, mesmo programas de patching diligentes não podem proteger naquele período crítico. É precisamente por isso que a defesa em profundidade é essencial — controles de segurança em camadas fornecem proteção quando qualquer controle individual falha ou ainda não foi implantado. Patching rápido permanece fundamental em gerenciamento de vulnerabilidades, mas defesa em profundidade ajuda organizações a não ficarem indefesas durante a janela entre exploit e patch.
Os times de Inteligência de Ameaças da AWS continuam monitorando operações do ransomware Interlock e fornecerão atualizações conforme informações adicionais se tornem disponíveis. A inteligência coletada desta campanha está sendo integrada aos serviços de segurança da AWS para proteger proativamente os clientes.
A AWS anunciou, em março de 2026, a disponibilidade do Amazon S3 Access Grants na região AWS Ásia-Pacífico (Nova Zelândia). Essa expansão amplia as opções de localização geográfica para organizações que precisam gerenciar o acesso a dados armazenados no Amazon S3 (Simple Storage Service) de forma segura e escalável.
Como funciona o S3 Access Grants
O Amazon S3 Access Grants atua como um mecanismo de mapeamento entre identidades corporativas e conjuntos de dados armazenados no S3. Ele estabelece uma ponte entre sistemas de identidade, como o Microsoft Entra ID (antigo Azure AD) ou os principals do AWS IAM (Identity and Access Management), e os recursos específicos no S3.
Essa funcionalidade resolve um desafio importante para empresas: em vez de gerenciar permissões de acesso manualmente para cada usuário ou aplicação, o S3 Access Grants automatiza esse processo. O sistema reconhece a identidade corporativa de um usuário e concede acesso apropriado aos dados no S3 com base nas políticas pré-configuradas da organização.
Benefícios para a gestão de dados em escala
Uma das principais vantagens do S3 Access Grants é sua capacidade de simplificar a administração de permissões. Para organizações com centenas ou milhares de usuários, configurar e manter regras de acesso granulares pode se tornar complexo e propenso a erros. O Access Grants reduz essa complexidade ao centralizar a política de acesso e aplicá-la de forma consistente.
Ao integrar-se com sistemas de diretório corporativo existentes, como o Microsoft Entra ID, o S3 Access Grants aproveita a infraestrutura de identidade que muitas empresas já possuem. Isso significa que decisões sobre quem tem acesso a qual dado podem ser sincronizadas com a estrutura organizacional real, tornando a governança de dados mais alinhada com a realidade operacional.
Próximos passos
Organizações que operam ou planejam expandir suas operações na região Ásia-Pacífico (Nova Zelândia) agora podem utilizar o S3 Access Grants como parte de sua estratégia de segurança e governança de dados. Para verificar a disponibilidade completa em outras regiões e explorar todas as capacidades do serviço, consulte a tabela de regiões da AWS.
Para aprofundar o conhecimento sobre como implementar o Amazon S3 Access Grants em sua infraestrutura, visite a página de detalhes do serviço.
A Amazon anunciou que o Registro Elástico de Contêineres (ECR) agora suporta o cache de puxada com o registro do Chainguard como fonte a montante. Essa integração permite que clientes da AWS usufruam da segurança e disponibilidade do ECR para imagens privadas do Chainguard.
Sincronização simplificada de imagens
A medida que os clientes expandem o uso de imagens do Chainguard em seus ambientes, manter essas imagens sincronizadas com o registro do Chainguard torna-se cada vez mais crítico. O recurso de cache de puxada do ECR oferece uma solução integrada: os clientes podem manter imagens do Chainguard atualizadas sem precisar de fluxos de trabalho adicionais ou ferramentas de gerenciamento externas.
O cache de puxada do ECR suporta sincronizações frequentes de registro, garantindo que as imagens de contêineres obtidas do Chainguard permaneçam sempre atualizadas. Essa abordagem elimina a complexidade operacional de gerenciar sincronizações manuais ou processos separados.
Recursos avançados para imagens cacheadas
Após o cache das imagens do Chainguard no ECR, os clientes podem aplicar funcionalidades importantes do ECR, como varredura de imagens e políticas de ciclo de vida. Essas capacidades oferecem maior controle sobre segurança e conformidade das imagens armazenadas.
Disponibilidade e próximos passos
O cache de puxada para Chainguard está disponível em todas as regiões da AWS onde o cache de puxada do ECR já é suportado. Para começar, os clientes devem consultar a documentação oficial que contém instruções detalhadas sobre como configurar e usar esse novo recurso.
Modelos de linguagem grandes (LLMs) revolucionaram a forma como interagimos com inteligência artificial. Porém, a realidade empresarial mostra que uma abordagem genérica raramente atende completamente às necessidades específicas das organizações. Os LLMs tradicionais chegam ao mercado treinados com conhecimento amplo e generalista, otimizados para diversos casos de uso. Ainda assim, frequentemente ficam aquém quando enfrentam tarefas específicas de domínio, fluxos de trabalho proprietários ou requisitos únicos de negócio.
As empresas cada vez mais precisam de modelos especializados que entendam profundamente seus dados proprietários, processos empresariais e terminologia específica do seu segmento. Sem essa personalização, restam apenas duas opções desconfortáveis: aceitar respostas genéricas ou gastar recursos excessivos com engenharia de contexto para melhorar as saídas.
Opções de customização disponíveis na AWS
A AWS estruturou suas capacidades de customização em diferentes níveis. Através do Amazon Bedrock, oferece opções como Treinamento Fine-Tuning Supervisionado (SFT) e Treinamento Fine-Tuning Reforçado (RFT). Já o Amazon SageMaker AI adiciona capacidades ainda mais avançadas, incluindo SFT, Otimização de Preferência Direta (DPO), RFT e suporte tanto para adaptação de baixo rank (LoRA) quanto customização de rank completo.
Conforme modelos são ajustados em datasets especializados, emerge um desafio técnico conhecido: frequentemente perdem capacidades base como habilidade de seguir instruções, raciocínio lógico e conhecimento amplo. Esse fenômeno é denominado esquecimento catastrófico. A Amazon Nova Forge oferece uma solução inovadora, permitindo construir modelos personalizados usando a família Nova a partir de checkpoints iniciais de modelo, blendando dados proprietários com dados curados pela AWS e hospedando tudo de forma segura na plataforma.
O desafio da complexidade e a resposta do Nova Forge SDK
Embora as opções de customização sejam poderosas, os fluxos de trabalho envolvem complexidade significativa. Exigem expertise técnica em infraestrutura, configuração de receitas específicas, seleção adequada de imagens e gerenciamento minucioso de dependências. Essa complexidade representa uma barreira real para muitas equipes interessadas em customização.
Para remover esses obstáculos, a AWS lançou o Nova Forge SDK. Trata-se de um kit de desenvolvimento desenhado para tornar a customização de LLMs acessível e empoderador, permitindo que equipes aproveitem todo o potencial dos modelos de linguagem sem lidar com gerenciamento de dependências, seleção de imagens ou configuração de receitas. A ferramenta reduz significativamente as barreiras de entrada para customização profissional.
A AWS visualiza a customização como um continuum dentro da escada de escalabilidade. Nesse contexto, o Nova Forge SDK suporta todas as opções de customização disponíveis, desde o Amazon Bedrock até o Amazon SageMaker AI, utilizando as capacidades Amazon Nova Forge.
Arquitetura e componentes do Nova Forge SDK
O toolkit do Nova Forge SDK representa um esforço deliberado para remover o trabalho indiferenciado da customização de LLMs. Oferece workflows com padrões inteligentes e orientação, enquanto mantém acesso total aos SDKs subjacentes para casos de uso avançados. O resultado é uma ferramenta que equilibra simplicidade para tarefas comuns com flexibilidade completa para requisitos sofisticados.
O SDK organiza-se em três camadas conceituais, cada uma com responsabilidades distintas:
Camada de Entrada: Aqui você fornece os insumos necessários. Inclui o objeto RuntimeManager (que define hardware, plataforma e função IAM para permissões), método de treinamento, dados de treinamento, hiperparâmetros personalizados e o modelo escolhido para customização.
Camada Customizadora: Essa camada intermediária recebe os inputs e, nos bastidores, constrói as configurações de receita apropriadas e dispara o job com os valores recebidos.
Camada de Saída: Emite artefatos de saída incluindo logs do Amazon CloudWatch, métricas MLFlow, logs TensorBoard e o artefato final do modelo treinado. Esse modelo pode ser usado para refinamento iterativo adicional ou implantação no Amazon SageMaker AI ou Amazon Bedrock para inferência.
Operacionalmente, o usuário fornece um RuntimeManager configurado, um modelo para customizar e um método de treinamento para um dos métodos de API em um NovaModelCustomizer inicializado. Quando o Customizer é inicializado, especifica-se o local de onde recuperar dados de treinamento, tipicamente um bucket do Amazon S3. Baseado nessas configurações, o modelo Customizer cuida de configurar e iniciar um job do Amazon SageMaker AI para executar a tarefa especificada. Ao término, a tarefa gera artefatos de saída e (para a API “train”) um modelo treinado que você pode referenciar através do SDK ou diretamente via APIs do Amazon SageMaker.
Preparação e configuração inicial
Antes de iniciar o fluxo de customização, existem requisitos de infraestrutura e permissões que precisam estar no lugar.
Dependências fundamentais
O artigo utiliza Jobs de Treinamento do Amazon SageMaker (SMTJ) como plataforma de computação. Note que você não precisa de um cluster Amazon SageMaker HyperPod para acompanhar os fundamentos — se seu interesse está limitado a SMTJ, a configuração de HyperPod é totalmente opcional.
Você precisa criar duas funções IAM para trabalhar com o Nova Forge SDK: a função de Usuário e a função de Execução.
Função de Usuário: A função que você assume em sua máquina ao executar o SDK e a AWS CLI. Essa função precisa de permissões para Amazon SageMaker AI (CreateTrainingJob, DescribeTrainingJob), Amazon S3 (leitura/escrita no seu bucket de dados), Amazon CloudWatch Logs (leitura) e IAM (PassRole). Consulte a documentação do SDK para a política completa.
Função de Execução: A função que o Amazon SageMaker AI assume para executar jobs de treinamento em seu nome. Sua política de confiança deve permitir que sagemaker.amazonaws.com a assuma. Para o conjunto completo de permissões recomendadas, consulte a documentação da função de execução do SageMaker. Os pré-requisitos para executar jobs SMTJ incluem instruções detalhadas de setup.
Quotas de serviço
Este artigo utiliza instâncias ml.p5.48xlarge tanto para treinamento quanto avaliação. O Nova Lite 2.0 requer um mínimo de 4 instâncias para treinamento SFT; se executar jobs de treinamento e avaliação concorrentemente, talvez precise de pelo menos 5 instâncias. Solicite quotas suficientes para ml.p5.48xlarge através do console de Quotas de Serviço para Jobs de Treinamento do Amazon SageMaker.
Bucket S3
Crie um bucket do Amazon S3 na mesma região AWS que seus jobs de treinamento (neste artigo usamos us-east-1) e certifique-se que suas funções IAM de usuário e execução possuem acesso de leitura e escrita. Aqui você armazenará dados de treinamento e artefatos de saída.
Amazon SageMaker HyperPod (opcional)
Além dos Jobs de Treinamento do Amazon SageMaker, o Nova Forge SDK também suporta execução em Amazon SageMaker HyperPod. Este artigo não enfatiza customização em SMHP, mas se desejar treinar em HyperPod, deve configurar um cluster com Grupos de Instâncias Restritos (RIGs). Siga as instruções no workshop de setup HyperPod RIG para configurar um cluster adequado para customização Amazon Nova.
Instalação e configuração do ambiente
Após concluir os pré-requisitos, você está pronto para configurar seu ambiente.
Ambiente Python
O Nova Forge SDK requer Python 3.12 ou posterior. Recomenda-se criar um ambiente virtual para isolar dependências:
python3.12 -m venv nova-sdk-env
source nova-sdk-env/bin/activate
# No Windows: nova-sdk-env\Scripts\activate
Instalação do SDK
Instale o SDK com o seguinte comando pip:
pip install amzn-nova-forge
Verifique a instalação importando os módulos principais em um arquivo Python de teste:
NovaModelCustomizer: A classe primária para interagir com o Nova Forge SDK, contendo métodos core da API e inicialização de configuração de treinamento.
SMTJRuntimeManager: Gerencia a infraestrutura AWS necessária para customização SMTJ, como tipo de instância selecionado e contagem para um job de customização.
TrainingMethod: Uma enumeração dos tipos de treinamento possíveis para configurar um NovaModelCustomizer.
EvaluationTask: Uma enumeração dos tipos de avaliação possíveis para configurar um NovaModelCustomizer.
CSVDatasetLoader: Usado para carregar dados de arquivos CSV para uso no Nova Forge SDK.
Model: Uma enumeração dos modelos Amazon Nova suportados pelo Nova Forge SDK.
Para informações adicionais sobre funcionalidades diferentes do SDK, consulte o documento de especificação. Se usar um agente LLM para trabalho em codificação, você pode ter o agente revisar o arquivo AGENTS.md no repositório para aprender sobre o SDK.
O significado dessa abordagem
A interface unificada do SDK abstrai a complexidade de formatação de dados e configurações específicas de plataforma, permitindo que desenvolvedores foquem no que realmente importa: seus dados, seu domínio e seus objetivos de negócio. Seja começando com fine-tuning em Jobs de Treinamento do Amazon SageMaker ou planejando customização com Amazon SageMaker HyperPod, o SDK oferece uma experiência consistente através de todo o continuum de customização.
Ao remover as barreiras tradicionais para customização de LLMs, requisitos de expertise técnica e investimento de tempo, o Nova Forge SDK capacita organizações a construir modelos que verdadeiramente entendem seu contexto único sem sacrificar as capacidades gerais que tornam modelos de base valiosos. O SDK cuida de configurar recursos de computação, orquestrar todo o pipeline de customização, monitorar jobs de treinamento e implantar endpoints. O resultado é IA empresarial que é tanto especializada quanto inteligente, expert em domínio e amplamente capaz.
Próximos passos
Pronto para customizar seus próprios modelos Nova? Comece com o Nova Forge SDK no GitHub e explore a documentação completa para começar a construir modelos adaptados às suas necessidades empresariais.
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 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.
