Author: Make.com Service User

  • Amazon S3 Block Public Access: agora com controle em nível organizacional

    Controle centralizado de segurança no S3

    A AWS anunciou uma importante expansão do Block Public Access (Bloqueio de Acesso Público) para o Amazon S3. O serviço agora permite gerenciamento centralizado através do AWS Organizations, possibilitando que organizações padronizem e enforcem configurações de acesso público em todos os accounts de sua estrutura por meio de uma única configuração de política.

    Como funciona o Block Public Access em nível organizacional

    Propagação automática de políticas

    O Block Public Access em nível organizacional opera através de uma configuração única que controla todas as definições de acesso público em todos os accounts dentro da organização. Quando você anexa a política no root ou em uma Unidade Organizacional (OU, do inglês Organizational Unit) da sua organização, ela se propaga automaticamente para todos os sub-accounts dentro desse escopo. Contas-membro novas herdam a política de forma automática, eliminando a necessidade de configuração manual individual.

    Flexibilidade de aplicação

    Além da abordagem centralizada, você também tem a opção de aplicar a política a accounts específicos quando precisa de um controle mais granular. Essa flexibilidade permite que organizações balanceiem a uniformidade de segurança com necessidades específicas de diferentes times ou departamentos.

    Como começar

    Configuração através do console

    Para iniciar, acesse o console do AWS Organizations e utilize o checkbox “Bloquear todo acesso público” ou use o editor JSON para configurações mais avançadas. A interface permite que você customize exatamente quais tipos de acesso público devem ser bloqueados em toda a sua organização.

    Monitoramento e auditoria

    A AWS CloudTrail pode ser utilizada para auditar e acompanhar a anexação de políticas, bem como monitorar o enforcement da política em todas as contas-membro. Isso oferece visibilidade completa sobre como as configurações de segurança estão sendo aplicadas e mantidas em toda a organização.

    Disponibilidade e acesso

    Esse recurso está disponível no console do AWS Organizations, bem como através da AWS CLI (Interface de Linha de Comando, do inglês Command Line Interface) e SDKs (Kits de Desenvolvimento de Software, do inglês Software Development Kits), em todas as regiões AWS onde AWS Organizations e Amazon S3 são suportados. Importante destacar que não há custos adicionais para usar esse recurso.

    Para aprofundar seus conhecimentos, você pode consultar o guia do usuário do AWS Organizations e a documentação do Block Public Access do Amazon S3 para detalhes técnicos e melhores práticas de implementação.

    Fonte

    Amazon S3 Block Public Access now supports organization-level enforcement (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-s3-block-public-access-organization-level-enforcement)

  • Amazon SageMaker HyperPod agora oferece suporte a labels e taints personalizados do Kubernetes

    Controle granular sobre o agendamento de cargas de trabalho

    A AWS anunciou um novo recurso no Amazon SageMaker HyperPod que oferece suporte a labels (etiquetas) e taints (repugnâncias) personalizados do Kubernetes. Essa funcionalidade permite aos clientes exercer controle preciso sobre o posicionamento de pods e garantir integração tranquila com infraestruturas Kubernetes já existentes.

    Para equipes que implantam cargas de trabalho de inteligência artificial em clusters HyperPod orquestrados com EKS (Elastic Kubernetes Service), esse é um recurso particularmente valioso. A capacidade de controlar exatamente onde cada pod é executado ajuda a evitar que recursos caros, como GPUs, sejam consumidos por pods de sistema ou cargas de trabalho não relacionadas a inteligência artificial, enquanto mantém compatibilidade com plugins de dispositivo personalizados, como o EFA (Elastic Fabric Adapter) e operadores NVIDIA GPU.

    Eliminando a sobrecarga operacional

    O desafio anterior

    Antes deste anúncio, clientes precisavam aplicar manualmente labels e taints usando kubectl, tendo que reaplicá-los após cada substituição de nó, operação de escalonamento ou patch do sistema. Esse processo manual gerava sobrecarga operacional significativa e aumentava o risco de inconsistências.

    A solução implementada

    O novo recurso permite configurar labels e taints no nível do grupo de instâncias através das APIs CreateCluster e UpdateCluster, oferecendo uma abordagem gerenciada para definir e manter políticas de agendamento ao longo de todo o ciclo de vida dos nós.

    Capacidades técnicas

    Utilizando o novo parâmetro KubernetesConfig, é possível especificar até 50 labels e 50 taints por grupo de instâncias. As labels habilitam organização de recursos e direcionamento de pods através de seletores de nó, enquanto taints repelem pods que não possuem tolerâncias correspondentes, protegendo nós especializados.

    Casos de uso práticos

    Um exemplo concreto é aplicar taints do tipo NoSchedule em grupos de instâncias com GPUs, garantindo que apenas trabalhos de treinamento de inteligência artificial com tolerâncias explícitas consumam esses recursos de alto custo. Outra aplicação é adicionar labels personalizados que permitam aos pods de plugins de dispositivo agendar corretamente no ambiente.

    Operação simplificada

    O HyperPod aplica automaticamente essas configurações durante a criação de nós e as mantém durante substituição, escalonamento e operações de patch. Isso elimina a necessidade de intervenção manual e reduz significativamente a sobrecarga operacional que as equipes enfrentavam anteriormente.

    O recurso está disponível em todas as regiões da AWS onde o Amazon SageMaker HyperPod é oferecido. Para aprofundar seus conhecimentos sobre labels e taints personalizados, consulte a documentação técnica completa.

    Fonte

    Amazon SageMaker HyperPod now supports custom Kubernetes labels and taints (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-sagemaker-hyperpod-kubernetes/)

  • Diretrizes para Varreduras de Rede: O Novo Padrão de Segurança da AWS

    A Varredura de Rede e o Desafio da Segurança

    A AWS apresentou um conjunto de diretrizes destinadas às varreduras de rede realizadas em ambientes de clientes. O objetivo? Permitir que ferramentas conformes coletem dados mais precisos, reduzam relatos de abuso e contribuam para elevar o nível de segurança na internet como um todo.

    Varreduras de rede são práticas comuns em infraestruturas modernas de TI. No entanto, essa prática enfrenta um dilema fundamental: ela pode servir tanto a propósitos legítimos quanto a atividades maliciosas. Do lado legítimo, equipes de segurança, administradores de sistemas e pesquisadores autorizados utilizam varreduras para manter inventários precisos de ativos, validar configurações de segurança e identificar vulnerabilidades ou versões desatualizadas de software que demandam atenção imediata.

    Já do lado malicioso, atores de ameaça realizam varreduras para enumerar sistemas, descobrir fraquezas e coletar inteligência para futuros ataques. Distinguir entre essas duas situações é um desafio constante para operações de segurança.

    Por Que Essas Diretrizes Importam

    O Crescimento Exponencial de Vulnerabilidades

    O cenário atual apresenta pressões significativas. De acordo com o banco de dados de vulnerabilidades da NIST (Banco Nacional de Dados de Vulnerabilidades), o número de vulnerabilidades conhecidas cresce a uma taxa de 21% ao ano nos últimos dez anos. Quando uma vulnerabilidade é descoberta por meio de varredura, a intenção do scanner torna-se crítica. Se um ator de ameaça explorar essa vulnerabilidade antes que seja corrigida, ele poderá obter acesso não autorizado aos sistemas organizacionais.

    As organizações precisam gerenciar efetivamente suas vulnerabilidades de software para se protegerem contra ransomware, roubo de dados, problemas operacionais e penalidades regulatórias. Porém, isso só é possível quando os dados de segurança coletados por varreduras permanecem protegidos.

    Os Múltiplos Interessados nos Dados de Segurança

    Diferentes grupos possuem interesses legítimos mas distintos em relação aos dados de segurança coletados:

    • Organizações querem entender seus ativos e corrigir vulnerabilidades rapidamente para proteger sua infraestrutura
    • Auditores de compliance buscam evidências de controles robustos na gestão de infraestrutura
    • Provedores de seguros cibernéticos precisam avaliar o risco da postura de segurança organizacional
    • Investidores em avaliação de diligência querem compreender o perfil de risco cibernético de uma organização
    • Pesquisadores de segurança desejam identificar riscos e notificar organizações para que ajam
    • Atores de ameaça buscam explorar vulnerabilidades não corrigidas e fraquezas para obter acesso não autorizado

    Esse ecossistema complexo de interesses concorrentes exige que dados sensíveis de segurança sejam mantidos com níveis diferentes de acesso. Se esses dados caírem nas mãos erradas, as consequências podem ser severas: comprometimento de sistemas, ransomware, negação de serviço e custos significativos para os proprietários dos sistemas.

    Considerando o crescimento exponencial de data centers e cargas de trabalho de software conectadas que fornecem serviços críticos em setores como energia, manufatura, saúde, governo, educação, finanças e transportes, o impacto de dados de segurança em mãos erradas pode ter consequências significativas no mundo real.

    A Falta de um Padrão Unificado

    Atualmente, não existe um padrão único para identificação de scanners de rede na internet. Proprietários de sistemas geralmente não sabem quem está realizando varreduras em suas infraestruturas. Cada proprietário é independentemente responsável por gerenciar a identificação dessas diferentes partes. Scanners podem usar métodos variados para se identificar — como busca reversa de DNS, agentes de usuário personalizados ou faixas de rede dedicadas. Já atores maliciosos podem tentar evitar identificação completamente.

    Esse grau de variação na identidade torna extremamente difícil para os proprietários de sistemas compreender a motivação por trás das varreduras que recebem. É nesse contexto que a AWS apresenta suas diretrizes comportamentais para varreduras de rede, buscando proteger redes e clientes.

    Os Benefícios das Diretrizes

    Quando scanners em conformidade com essas diretrizes realizam varreduras, eles coletam dados mais confiáveis da infraestrutura AWS. Organizações que executam workloads na AWS recebem um maior grau de confiança em sua gestão de riscos. Quando a varredura segue essas diretrizes, proprietários de sistemas conseguem fortalecer suas defesas e melhorar visibilidade em todo seu ecossistema digital.

    Ferramentas como o Amazon Inspector podem detectar vulnerabilidades de software e priorizar esforços de correção enquanto aderem a essas diretrizes. Parceiros do AWS Marketplace utilizam essas orientações para coletar sinais de segurança em toda a internet e ajudar organizações a compreender e gerenciar riscos cibernéticos. Como afirmou um especialista do Bitsight: “Quando organizações têm visibilidade clara orientada por dados sobre sua própria postura de segurança e a de terceiros, conseguem tomar decisões mais rápidas e inteligentes para reduzir riscos cibernéticos em todo o ecossistema.”

    Reportando Atividades Abusivas

    A segurança funciona melhor quando há colaboração. Clientes da AWS podem reportar varreduras abusivas através do Centro de Confiança e Segurança, selecionando o tipo de relatório como “Atividade de Rede > Varredura de Portas e Tentativas de Intrusão”. Cada relatório contribui para melhorar a proteção coletiva contra o uso malicioso de dados de segurança.

    As Diretrizes de Conformidade

    Para permitir que scanners legítimos se diferenciem claramente de atores de ameaça, a AWS oferece as seguintes orientações para varredura de workloads. Essas diretrizes complementam as políticas existentes sobre testes de penetração e relatório de vulnerabilidades. A AWS se reserva o direito de limitar ou bloquear tráfego que pareça não estar em conformidade com essas diretrizes.

    1. Observacional

    Um scanner em conformidade não realiza ações que tentem criar, modificar ou deletar recursos ou dados nos endpoints descobertos. Respeita a integridade dos sistemas-alvo. As varreduras não causam degradação na funcionalidade do sistema e não introduzem mudanças nas configurações.

    Exemplos de varredura não-modificadora incluem:

    • Iniciar e completar um handshake TCP
    • Recuperar o banner de um serviço SSH

    2. Identificável

    Um scanner em conformidade oferece transparência ao publicar as fontes de sua atividade de varredura. Implementa um processo verificável para confirmar a autenticidade de atividades de varredura.

    Exemplos de varredura identificável incluem:

    • Suportar buscas reversa de DNS para uma das zonas de DNS públicas de sua organização nos IPs de varredura
    • Publicar intervalos de IP de varredura, organizados por tipos de requisições (como verificação de existência de serviços, verificações de vulnerabilidades)
    • Se realizar varreduras HTTP, incluir conteúdo significativo em strings de agente de usuário (como nomes de suas zonas de DNS públicas, URL para opt-out)

    3. Cooperativo

    Um scanner em conformidade limita taxas de varredura para minimizar impacto nos sistemas-alvo. Oferece um mecanismo de opt-out para proprietários de recursos verificados que desejam solicitar cessação da atividade de varredura. Honra solicitações de opt-out dentro de um período de resposta razoável.

    Exemplos de varredura cooperativa incluem:

    • Limitar varredura a uma transação de serviço por segundo por serviço de destino
    • Respeitar configurações de site conforme expressos em robots.txt, security.txt e outros padrões da indústria para expressar intenção do proprietário do site

    4. Confidencial

    Um scanner em conformidade mantém práticas seguras de infraestrutura e manipulação de dados, refletidas em certificações de padrão industrial como SOC2. Garante nenhum acesso não autenticado ou não autorizado aos dados coletados. Implementa processos de identificação e verificação de usuários.

    O Caminho Adiante

    À medida que mais scanners de rede adotam essas diretrizes, proprietários de sistemas se beneficiarão de riscos reduzidos em relação a confidencialidade, integridade e disponibilidade. Scanners legítimos enviarão um sinal claro de sua intenção e melhorarão a qualidade de visibilidade que conseguem obter. Com o estado em constante mudança do networking, espera-se que essas diretrizes evoluam acompanhando controles técnicos ao longo do tempo.

    A AWS convida feedback de clientes, proprietários de sistemas, scanners de rede e outros interessados para continuar melhorando a postura de segurança em toda a AWS e na internet. Consulte as diretrizes completas na AWS ou entre em contato com o Suporte AWS para dúvidas específicas.

    Fonte

    Introducing guidelines for network scanning (https://aws.amazon.com/blogs/security/introducing-guidelines-for-network-scanning/)

  • SageMaker AI: Decodificação Especulativa com EAGLE para Acelerar Inferência de IA Generativa

    A Demanda por Inferência mais Rápida

    Os modelos de IA generativa continuam crescendo em escala e capacidade, intensificando a necessidade de inferência mais veloz e eficiente. Aplicações que funcionam com estes modelos precisam de baixa latência e desempenho consistente sem comprometer a qualidade dos resultados gerados. A AWS anunciou novos aprimoramentos em seu kit de ferramentas de otimização de inferência no SageMaker AI, expandindo o suporte para a decodificação especulativa baseada em EAGLE para mais arquiteturas de modelos.

    Essas atualizações facilitam a aceleração do processo de decodificação, permitem otimizar o desempenho utilizando dados específicos da sua aplicação e possibilitam o deploy de modelos com maior throughput por meio do fluxo de trabalho familiar do SageMaker AI.

    Entendendo o EAGLE

    EAGLE é uma sigla para Algoritmo de Extrapolação para Maior Eficiência em Modelos de Linguagem (Extrapolation Algorithm for Greater Language-model Efficiency). A técnica funciona acelerando a decodificação de modelos de linguagem grandes ao prever tokens futuros diretamente a partir das camadas ocultas do modelo.

    Uma das características principais é a capacidade de otimização dinâmica baseada em seus dados. Quando você orienta a otimização usando dados reais da sua aplicação, as melhorias se alinham com os padrões e domínios específicos que você atende, produzindo uma inferência mais rápida que reflete suas cargas de trabalho reais e não apenas benchmarks genéricos.

    Dependendo da arquitetura do modelo, o SageMaker AI treina cabeçalhos EAGLE 3 ou EAGLE 2. É importante notar que esse treinamento e otimização não se limita a uma única operação. Você pode começar utilizando os conjuntos de dados fornecidos pelo SageMaker para treinamento inicial, mas conforme coleta e reúne seus próprios dados, pode também fazer ajuste fino usando seu próprio conjunto de dados curado para desempenho altamente adaptativo e específico à sua carga de trabalho.

    Um exemplo prático seria usar uma ferramenta como Captura de Dados para curar seu próprio conjunto de dados ao longo do tempo a partir de requisições em tempo real que atingem seu modelo hospedado. Trata-se de um recurso iterativo com múltiplos ciclos de treinamento para melhorar continuamente o desempenho.

    Fonte: AWS

    Visão Geral da Solução

    O SageMaker AI agora oferece suporte nativo para decodificação especulativa com EAGLE 2 e EAGLE 3, permitindo que cada arquitetura de modelo aplique a técnica que melhor se adequa ao seu design interno.

    Para seu modelo de base LLM, você pode utilizar modelos do SageMaker JumpStart ou trazer seus próprios artefatos de modelo de outro lugar, como o HuggingFace. A decodificação especulativa é uma técnica amplamente empregada para acelerar inferência em LLMs sem comprometer a qualidade. O método envolve usar um modelo de rascunho menor para gerar tokens preliminares, que são então verificados pelo LLM alvo. A extensão da aceleração obtida por meio da decodificação especulativa depende fortemente da seleção do modelo de rascunho.

    A natureza sequencial dos LLMs modernos os torna caros e lentos, e a decodificação especulativa provou ser uma solução eficaz para este problema. Métodos como EAGLE melhoram isso reutilizando recursos do modelo alvo, levando a melhores resultados.

    Evolução: Do EAGLE 2 ao EAGLE 3

    Uma tendência atual na comunidade de LLM é aumentar dados de treinamento para potencializar a inteligência do modelo sem adicionar custos de inferência. Infelizmente, essa abordagem tem benefícios limitados para EAGLE. Essa limitação ocorre devido às restrições do EAGLE na previsão de recursos.

    Para resolver isso, o EAGLE 3 foi introduzido, que prevê tokens diretamente em vez de recursos e combina recursos de múltiplas camadas usando uma técnica chamada teste em tempo de treinamento. Essas mudanças melhoram significativamente o desempenho e permitem que o modelo se beneficie plenamente do aumento de dados de treinamento.

    Fonte: AWS

    Flexibilidade de Workflows

    Para dar aos clientes máxima flexibilidade, o SageMaker suporta todos os principais fluxos de trabalho para construir ou refinar um modelo EAGLE:

    • Treinar um modelo EAGLE completamente do zero usando o conjunto de dados aberto curado pelo SageMaker
    • Treinar do zero com seus próprios dados para alinhar o comportamento especulativo com seus padrões de tráfego
    • Começar a partir de um modelo EAGLE base existente, retreinando-o com o conjunto de dados aberto padrão para uma baseline rápida e de alta qualidade
    • Ou ajustar esse modelo base com seu próprio conjunto de dados para desempenho altamente adaptativo e específico à sua carga de trabalho

    Além disso, o SageMaker JumpStart fornece modelos EAGLE completamente pré-treinados, permitindo que você comece a otimização imediatamente sem preparar nenhum artefato.

    A solução abrange seis arquiteturas suportadas e inclui uma base EAGLE pré-treinada e pré-armazenada em cache para acelerar experimentação. O SageMaker AI também suporta formatos de dados de treinamento amplamente utilizados, especificamente ShareGPT e chat e completude OpenAI, permitindo que corpora existentes sejam usados diretamente. Os clientes também podem fornecer dados capturados usando seus próprios endpoints do SageMaker AI, desde que os dados estejam nos formatos especificados acima.

    Seja confiando no conjunto de dados aberto do SageMaker ou trazendo seus próprios dados, os trabalhos de otimização normalmente entregam aproximadamente 2.5x de throughput sobre a decodificação padrão, ao mesmo tempo que se adaptam naturalmente às nuances de seu caso de uso específico. Todos os trabalhos de otimização produzem automaticamente resultados de benchmark, dando-lhe visibilidade clara nas melhorias de latência e throughput.

    Arquiteturas Suportadas

    O SageMaker AI atualmente suporta LlamaForCausalLM, Qwen3ForCausalLM, Qwen3MoeForCausalLM, Qwen2ForCausalLM e GptOssForCausalLM com EAGLE 3, e Qwen3NextForCausalLM com EAGLE 2. Você pode utilizar um pipeline de otimização único em um conjunto de arquiteturas diferentes enquanto ainda obtém os benefícios do comportamento específico de cada modelo.

    Como o EAGLE Funciona Internamente

    A decodificação especulativa pode ser pensada como um cientista chefe experiente guiando o fluxo de descoberta. Em configurações tradicionais, um modelo “assistente” menor funciona antecipadamente, esboçando rapidamente várias continuações de tokens possíveis, enquanto o modelo maior examina e corrige essas sugestões. Essa combinação reduz o número de passos lentos e sequenciais verificando múltiplos rascunhos de uma vez.

    O EAGLE simplifica ainda mais esse processo. Em vez de depender de um assistente externo, o modelo efetivamente se torna seu próprio parceiro de laboratório: inspeciona suas representações de camadas ocultas internas para antecipar vários tokens futuros em paralelo. Como essas previsões surgem da estrutura aprendida do próprio modelo, tendem a ser mais precisas desde o início, levando a etapas especulativas mais profundas, menos rejeições e throughput mais suave.

    Ao remover a sobrecarga de coordenação de um modelo secundário e permitir verificação altamente paralela, essa abordagem alivia gargalos de largura de banda de memória e entrega acelerações notáveis, frequentemente em torno de 2.5x, mantendo a mesma qualidade de saída que o modelo de base produziria.

    Executando Trabalhos de Otimização

    Você pode interagir com o kit de ferramentas de otimização usando o AWS Python Boto3 SDK, Studio UI ou AWS CLI. As chamadas de API principais para criação de endpoint permanecem as mesmas: create_model, create_endpoint_config e create_endpoint.

    O fluxo de trabalho começa com registro de modelo usando a chamada da API create_model. Com essa chamada você pode especificar seu contêiner de serviço e stack. Você não precisa criar um objeto de modelo SageMaker e pode especificar os dados do modelo também na chamada da API do Trabalho de Otimização.

    Para otimização de cabeçalhos EAGLE, você especifica os dados do modelo apontando para o parâmetro Fonte de Dados do Modelo. No momento, especificação do ID do Modelo do HuggingFace Hub não é suportada. Extraia seus artefatos e carregue-os em um bucket S3 e especifique-o no parâmetro Fonte de Dados do Modelo.

    Por padrão, verificações são realizadas para confirmar que os arquivos apropriados foram carregados, garantindo que você tenha os dados padrão esperados para LLMs:

    model/
    config.json
    tokenizer.json
    tokenizer_config.json
    special_tokens_map.json
    generation_config.json
    vocab.json
    model.safetensors
    model.safetensors.index.json

    Usando seus próprios dados de modelo com dataset EAGLE curado

    Você pode iniciar um trabalho de otimização com a chamada da API create-optimization-job. Aqui está um exemplo com um modelo Qwen3 32B. Note que você pode trazer seus próprios dados ou também usar os conjuntos de dados fornecidos pelo SageMaker.

    Primeiro, crie um objeto de Modelo SageMaker que especifique o bucket S3 com seus artefatos de modelo:

    aws sagemaker --region us-west-2 create-model \
    --model-name <target-model-name> \
    --primary-container '{
      "Image": "763104351884.dkr.ecr.{region}.amazonaws.com/djl-inference:{CONTAINER_VERSION}",
      "ModelDataSource": {
        "S3DataSource": {
          "S3Uri": "Enter model path",
          "S3DataType": "S3Prefix",
          "CompressionType": "None"
        }
      }
    }' \
    --execution-role-arn "Enter Execution Role ARN"

    Sua chamada de otimização então extrai esses artefatos de modelo quando você especifica o Modelo SageMaker e um parâmetro TrainingDataSource da seguinte forma:

    aws sagemaker --region us-west-2 create-optimization-job \
    --optimization-job-name <job-name> \
    --account-id <account-id> \
    --deployment-instance-type ml.p5.48xlarge \
    --max-instance-count 10 \
    --model-source '{
      "SageMakerModel": {
        "ModelName": "Created Model name"
      }
    }' \
    --optimization-configs '{
      "ModelSpeculativeDecodingConfig": {
        "Technique": "EAGLE",
        "TrainingDataSource": {
          "S3DataType": "S3Prefix",
          "S3Uri": "Enter custom train data location"
        }
      }
    }' \
    --output-config '{
      "S3OutputLocation": "Enter optimization output location"
    }' \
    --stopping-condition '{"MaxRuntimeInSeconds": 432000}' \
    --role-arn "Enter Execution Role ARN"

    Trazendo seu próprio EAGLE treinado

    Para seu próprio EAGLE treinado, você pode especificar outro parâmetro na chamada da API create_model onde aponta para seus artefatos EAGLE. Opcionalmente, você também pode especificar um ID de Modelo SageMaker JumpStart para extrair os artefatos de modelo empacotados:

    aws sagemaker --region us-west-2 create-model \
    --model-name <target-model-name> \
    --primary-container '{
      "Image": "763104351884.dkr.ecr.{region}.amazonaws.com/djl-inference:{CONTAINER_VERSION}",
      "ModelDataSource": {
        "S3DataSource": {
          "S3Uri": "<model path>",
          "S3DataType": "S3Prefix",
          "CompressionType": "None"
        }
      },
      "AdditionalModelDataSources": [
        {
          "ChannelName": "eagle_model",
          "S3DataSource": {
            "S3Uri": "<pre-trained EAGLE path>",
            "S3DataType": "S3Prefix",
            "CompressionType": "None"
          }
        }
      ]
    }' \
    --execution-role-arn "Enter Execution Role ARN"

    De forma similar, a API de otimização então herda esse objeto de modelo com os dados de modelo necessários:

    aws sagemaker --region us-west-2 create-optimization-job \
    --account-id <account-id> \
    --optimization-job-name <job-name> \
    --deployment-instance-type ml.p5.48xlarge \
    --max-instance-count 10 \
    --model-source '{
      "SageMakerModel": {
        "ModelName": "Created Model Name"
      }
    }' \
    --optimization-configs '{
      "ModelSpeculativeDecodingConfig": {
        "Technique": "EAGLE",
        "TrainingDataSource": {
          "S3Uri": "Enter training data path",
          "S3DataType": "S3Prefix"
        }
      }
    }' \
    --output-config '{
      "SageMakerModel": {
        "ModelName": "Model Name"
      },
      "S3OutputLocation": "Enter output data location"
    }' \
    --stopping-condition '{"MaxRuntimeInSeconds": 432000}' \
    --role-arn "Enter Execution Role ARN"

    Usando dados de modelo próprio com conjuntos de dados incorporados

    Opcionalmente, você pode utilizar os conjuntos de dados fornecidos pelo SageMaker:

    • gsm8k_training.jsonl
    • magicoder.jsonl
    • opencodeinstruct.jsonl
    • swebench_oracle_train.jsonl
    • ultrachat_0_8k_515292.jsonl

    Após conclusão, o SageMaker AI armazena métricas de avaliação no S3 e registra a linhagem de otimização no Studio. Você pode fazer deploy do modelo otimizado para um endpoint de inferência com a chamada da API create_endpoint ou na interface.

    Resultados de Benchmark

    Para benchmarks, foram comparados três estados: sem EAGLE como baseline, EAGLE base usando conjuntos de dados incorporados, e EAGLE treinado usando datasets incorporados e retreinamento com dados customizados próprios.

    Os números exibidos abaixo são para Qwen3-32B em métricas como Tempo para Primeiro Token (TTFT) e throughput geral:

    Fonte: AWS

    Considerações sobre Preços

    Os trabalhos de otimização são executados em instâncias de treinamento do SageMaker AI, e você será cobrado dependendo do tipo de instância e duração do trabalho. O deploy do modelo otimizado resultante usa a precificação padrão de Inferência do SageMaker AI.

    Conclusão

    A decodificação especulativa adaptativa baseada em EAGLE oferece um caminho mais rápido e eficaz para melhorar o desempenho de inferência de IA generativa no Amazon SageMaker AI. Ao funcionar dentro do modelo em vez de depender de uma rede de rascunho separada, o EAGLE acelera a decodificação, aumenta o throughput e mantém a qualidade da geração. Quando você otimiza usando seu próprio conjunto de dados, as melhorias refletem o comportamento único de suas aplicações, resultando em melhor desempenho de ponta a ponta.

    Com suporte a conjuntos de dados incorporados, automação de benchmarks e deployment simplificado, o kit de ferramentas de otimização de inferência ajuda você a entregar aplicações de IA generativa de baixa latência em escala.

    Fonte

    Amazon SageMaker AI introduces EAGLE based adaptive speculative decoding to accelerate generative AI inference (https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-ai-introduces-eagle-based-adaptive-speculative-decoding-to-accelerate-generative-ai-inference/)

  • Treinar Modelos Customizados de Detecção de Defeitos com Visão Computacional no Amazon SageMaker

    Transição do Amazon Lookout for Vision para SageMaker

    Em outubro de 2024, a AWS anunciou a descontinuação do Amazon Lookout for Vision, com previsão de encerramento em 31 de outubro de 2025. Como parte de sua estratégia de transição, a empresa recomenda que clientes interessados em soluções de inteligência artificial e aprendizado de máquina para visão computacional utilizem as ferramentas do Amazon SageMaker AI.

    A boa notícia é que a AWS disponibilizou no AWS Marketplace os modelos subjacentes que alimentavam o serviço descontinuado. Esses modelos podem ser ajustados usando o Amazon SageMaker para casos de uso específicos, oferecendo flexibilidade total de integração com infraestruturas existentes de hardware e software. Quando executados na nuvem, os custos envolvem apenas a infraestrutura necessária para treinamento ou inferência.

    Fluxo end-to-end: da aquisição de imagens até a inferência em dispositivos edge — Fonte: Aws

    Vantagens da Migração para SageMaker

    A transição proporciona ganhos significativos em flexibilidade e controle. Com o SageMaker, é possível treinar modelos em instâncias maiores para reduzir o tempo de processamento. Além disso, usuários podem ajustar hiperparâmetros que antes não eram disponíveis no console do Lookout for Vision. Por exemplo, é possível desabilitar a cabeça do classificador binário em modelos de segmentação semântica, tornando a solução mais tolerante a variações de iluminação e fundo.

    Outro destaque é o controle sobre o tempo máximo de treinamento, que no Lookout for Vision era limitado a 24 horas. Agora, organizações podem customizar esse parâmetro conforme suas necessidades.

    Recursos e Modelos Disponíveis

    A AWS coloca à disposição dois tipos principais de modelos:

    • Classificação binária: para categorizar imagens como normais ou anômalas
    • Segmentação semântica: para identificar regiões específicas com defeitos em uma imagem

    Ambos podem ser treinados nas contas próprias da AWS para implantação na nuvem ou em dispositivos edge. O repositório GitHub do Amazon Lookout for Vision foi atualizado com um Jupyter Notebook que facilita o treinamento de datasets com esses dois tipos de modelos e seu empacotamento.

    Para rotular dados além do conjunto amostral, é possível usar o Amazon SageMaker Ground Truth para crowdsourcing ou permitir que equipes privadas façam a anotação. Alternativas incluem soluções de parceiros como Edge Impulse, Roboflow e SuperbAI.

    Pré-Requisitos

    Antes de começar, certifique-se de ter em lugar:

    • Amazon SageMaker Studio ou Amazon SageMaker Unified Studio para desenvolvimento integrado
    • Função Controle de Identidade e Acesso (IAM) com permissões apropriadas, incluindo acesso ao Amazon S3, operações no SageMaker e subscrição ao AWS Marketplace
    • Subscrição a um modelo de detecção de defeitos por visão computacional no AWS Marketplace
    • Dados etiquetados (é possível usar amostras como o cookie-dataset ou aliens-dataset do GitHub)
    • Conhecimento básico de criar instâncias Jupyter no SageMaker e executar notebooks

    Configuração do Processo de Etiquetagem

    O primeiro passo da jornada envolve preparar os dados para treinamento. A AWS oferece o Ground Truth, que possibilita criar equipes privadas de anotadores e organizar o trabalho de rotulação.

    No console do SageMaker AI, navegue até Ground Truth e selecione a opção de criar uma equipe privada. Após definir nome e configurações iniciais, você pode convidar membros da sua equipe por e-mail, enviando automaticamente convites com credenciais de acesso.

    Etiquetagem com SageMaker Ground Truth — Fonte: Aws

    Preparação e Etiquetagem de Datasets

    Uma vez que a equipe está pronta, o próximo passo é preparar o dataset. Faça upload das imagens para um bucket Amazon S3 e organize-as em uma estrutura única de diretório, combinando imagens normais e anômalas.

    Para automatizar esse processo, você pode usar um script no AWS CloudShell:

    #!/bin/bash
    # Clone o repositório
    git clone https://github.com/aws-samples/amazon-lookout-for-vision.git
    cd amazon-lookout-for-vision/aliens-dataset
    
    # Remove diretório anterior se existir
    rm -rf all
    
    # Cria novo diretório
    mkdir -p all
    
    # Copia imagens normais
    cp normal/*.png all/
    
    # Copia imagens anômalas com sufixo
    cd "$(dirname "$0")/amazon-lookout-for-vision/aliens-dataset"
    for file in anomaly/*.png; do
      if [ -f "$file" ]; then
        filename=$(basename "$file")
        cp "$file" "all/${filename}.anomaly.png"
      fi
    done
    
    # Verifica contagem
    echo "Imagens normais: $(find normal -name "*.png" | wc -l)"
    echo "Imagens anômalas: $(find anomaly -name "*.png" | wc -l)"
    echo "Total no diretório all: $(find all -type f | wc -l)"
    
    # Upload para S3
    aws s3 cp all/ s3://<BUCKET_NAME>/aliens-dataset-all/ --recursive
    
    # Limpeza
    cd ../..
    rm -rf amazon-lookout-for-vision

    Alternativamente, com a CLI da AWS configurada, você pode usar comandos manuais. Depois de fazer upload, acesse o console do SageMaker, navigate para Ground Truth e crie um novo job de etiquetagem. Configure a localização dos dados no S3, escolha “Configuração Automática de Dados” e selecione “Imagem” como tipo de dados.

    Para o tipo de tarefa, escolha “Classificação de Imagem (Rótulo Único)” para classificação binária ou “Segmentação Semântica” conforme sua necessidade. Crie dois rótulos: “normal” e “anomalia”. Uma vez que o job é iniciado, trabalhadores acesso o portal de etiquetagem e rotulam cada imagem conforme as instruções fornecidas.

    Treinamento do Modelo

    Após concluir a etiquetagem, use os dados rotulados para treinar o modelo de detecção de defeitos. Primeiro, subscrevam-se ao modelo no AWS Marketplace. Copie o ARN (Identificador de Recurso da Amazon) do modelo para referência posterior.

    Em seguida, crie uma instância Jupyter do SageMaker. Para essa tarefa, uma instância do tipo m5.2xl é adequada, com volume de 128 GB (o padrão de 5 GB é insuficiente). GPU não é obrigatória na instância do notebook, pois o SageMaker ativa automaticamente instâncias habilitadas com GPU durante o treinamento.

    Clone o repositório GitHub dentro da instância Jupyter e localize a pasta relevante. No notebook, defina o ARN do modelo que você subscreveu:

    # TODO: altere para usar o algoritmo SageMaker subscrito
    algorithm_name = "<Especificar nome do algoritmo após subscrição>"

    # Inicializa a sessão SageMaker e obtém a função de execução
    sagemaker_session = sagemaker.Session()
    region = sagemaker_session.boto_region_name
    role = get_execution_role()

    # Nome do projeto para identificar no S3
    project = "ComputerVisionDefectDetection"

    Fonte

    Train custom computer vision defect detection model using Amazon SageMaker (https://aws.amazon.com/blogs/machine-learning/train-custom-computer-vision-defect-detection-model-using-amazon-sagemaker/)

  • Transmissão Bidirecional em Tempo Real: A Evolução da Inferência no Amazon SageMaker AI

    O Futuro da IA em Tempo Real: Comunicação Bidirecional Contínua

    Em 2025, a inteligência artificial generativa transcendeu a simples geração de texto. As aplicações modernas demandam muito mais do que respostas transacionais isoladas. Elas exigem capacidades multimodais abrangentes — desde transcrição e tradução de áudio até agentes de voz sofisticados — e, sobretudo, necessitam de comunicação contínua e fluida em tempo real.

    O diferencial está em um requisito essencial: os dados precisam fluir simultaneamente em ambas as direções, através de uma única conexão persistente. Imagine um cenário de conversão de fala para texto onde o áudio é transmitido de forma contínua enquanto, ao mesmo tempo, o modelo processa e retorna a transcrição em tempo real, palavra por palavra. Esses casos de uso demandam exatamente essa capacidade bidirecional.

    A AWS anunciou a transmissão bidirecional para Amazon SageMaker AI Inference, transformando fundamentalmente o paradigma de inferência — de uma troca transacional isolada para uma conversa contínua e natural. A experiência de fala flui naturalmente quando não há interrupções. Com transmissão bidirecional, a conversão de fala para texto torna-se imediata: o modelo escuta e transcreve simultaneamente, fazendo as palavras aparecerem no exato momento em que são pronunciadas.

    Considere o caso prático de um centro de atendimento ao cliente. Conforme o cliente descreve seu problema, a transcrição ao vivo aparece instantaneamente na tela do atendente, fornecendo contexto imediato e permitindo que ele responda sem esperar o cliente terminar de falar. Esse tipo de troca contínua torna as experiências de voz mais fluidas, responsivas e genuinamente humanas.

    Como Funciona a Transmissão Bidirecional

    O Paradigma Tradicional versus Bidirecional

    Na abordagem tradicional de requisições de inferência, existe um padrão bem definido: o cliente envia uma pergunta completa e aguarda, enquanto o modelo processa e retorna uma resposta completa antes que o cliente possa enviar a próxima pergunta. É um ciclo de espera e resposta.

    Com transmissão bidirecional, esse fluxo é radicalmente diferente. A pergunta começa a fluir do cliente enquanto o modelo simultaneamente inicia o processamento e começa a retornar a resposta imediatamente. O cliente pode continuar refinando sua entrada enquanto o modelo adapta sua resposta em tempo real. Os resultados aparecem assim que o modelo os gera — palavra por palavra para texto, frame por frame para vídeo, amostra por amostra para áudio.

    Esse padrão também oferece benefícios infraestruturais significativos: manter uma única conexão persistente elimina a necessidade de centenas de conexões de curta duração. Isso reduz consideravelmente a sobrecarga de gerenciamento de rede, handshakes TLS e administração de conexões. Além disso, os modelos conseguem manter contexto ao longo de um fluxo contínuo, possibilitando interações multi-turnos sem a necessidade de reenviar o histórico de conversa a cada requisição.

    Arquitetura de Três Camadas do SageMaker AI Inference

    A implementação técnica da transmissão bidirecional no SageMaker AI Inference combina dois protocolos complementares: HTTP/2 e WebSocket, criando um canal robusto de comunicação bidirecional em tempo real entre cliente e modelo. O fluxo ocorre em três camadas:

    Cliente para Roteador SageMaker AI: Sua aplicação se conecta ao endpoint de tempo de execução do Amazon SageMaker AI usando HTTP/2, estabelecendo uma conexão eficiente e multiplexada que suporta transmissão bidirecional.

    Roteador para Contêiner do Modelo: O roteador encaminha a requisição para um Sidecar — um proxy leve executando ao lado de seu contêiner de modelo — que estabelece uma conexão WebSocket com o contêiner em ws://localhost:8080/invocations-bidirectional-stream. Uma vez estabelecida, os dados fluem livremente em ambas as direções.

    Fluxo de Requisição e Resposta: Sua aplicação envia entrada como uma série de blocos de dados via HTTP/2. A infraestrutura do SageMaker AI converte esses blocos em frames de dados WebSocket — texto (para dados UTF-8) ou binário — e os encaminha ao contêiner. O modelo recebe esses frames em tempo real e começa a processar imediatamente, antes mesmo da chegada da entrada completa. Na direção oposta, o modelo gera saída e a envia como frames WebSocket. O SageMaker AI encapsula cada frame em um payload de resposta e o transmite diretamente à sua aplicação via HTTP/2.

    A conexão WebSocket entre o Sidecar e o contêiner permanece aberta pela duração da sessão, com monitoramento de saúde integrado. Para manter a integridade da conexão, o SageMaker AI envia frames de ping a cada 60 segundos para verificar se a conexão está ativa. Seu contêiner responde com pong frames para confirmar que está saudável. Se 5 pings consecutivos não receberem resposta, a conexão é fechada de forma controlada.

    Construindo seu Próprio Contêiner com Transmissão Bidirecional

    Pré-requisitos e Preparação

    Se você deseja utilizar modelos de código aberto ou seus próprios modelos, é possível customizar seu contêiner para suportar transmissão bidirecional. Seu contêiner deve implementar o protocolo WebSocket para lidar com frames de dados recebidos e enviar frames de resposta de volta ao SageMaker AI.

    Para começar, você precisará de:

    • Uma conta AWS com permissões no SageMaker AI
    • A política de acesso gerenciado AmazonSageMakerFullAccess IAM Managed Policy para permitir criação de endpoints
    • Permissões de IAM que permitam explicitamente a ação sagemaker:InvokeEndpoint* para invocação de endpoints
    • Docker instalado localmente
    • Python 3.12 ou superior
    • Instalar aws-sdk-python para a API InvokeEndpointWithBidirectionalStream do tempo de execução do SageMaker AI

    Construindo e Implantando o Contêiner

    O processo começa clonando o repositório de demonstração e configurando seu ambiente conforme definido no README.md. Os passos a seguir criarão uma imagem Docker simples de demonstração e a enviarão para seu repositório de ECR na AWS.

    # As variáveis de ambiente devem ser definidas para autenticação AWS
    # export AWS_ACCESS_KEY_ID="sua-chave-de-acesso"
    # export AWS_SECRET_ACCESS_KEY="sua-chave-secreta"
    # export AWS_DEFAULT_REGION="us-west-2"
    
    container_name="sagemaker-bidirectional-streaming"
    container_tag="latest"
    cd container
    account=$(aws sts get-caller-identity --query Account --output text)
    region=$(aws configure get region)
    region=${region:-us-west-2}
    container_image_uri="${account}.dkr.ecr.${region}.amazonaws.com/${container_name}:${container_tag}"
    
    # Se o repositório não existe no ECR, crie-o
    aws ecr describe-repositories --repository-names "${container_name}" --region "${region}" > /dev/null 2>&1
    if [ $? -ne 0 ]
    then
      aws ecr create-repository --repository-name "${container_name}" --region "${region}" > /dev/null
    fi
    
    # Obtenha o comando de login do ECR e execute-o
    aws ecr get-login-password --region ${region} | docker login --username AWS --password-stdin ${account}.dkr.ecr.${region}.amazonaws.com/${container_name}
    
    # Construa a imagem Docker localmente e envie-a para o ECR
    docker build --platform linux/amd64 --provenance=false -t ${container_name} .
    docker tag ${container_name} ${container_image_uri}
    docker push ${container_image_uri}

    Este processo cria um contêiner com um rótulo Docker indicando ao SageMaker AI que o suporte a transmissão bidirecional está habilitado: com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true.

    Após criar a imagem, você pode implantar o contêiner em um endpoint do SageMaker AI através de um script Python que cria o modelo, a configuração do endpoint e finalmente o endpoint propriamente dito.

    Invocando o Endpoint com a Nova API

    Uma vez que o endpoint do SageMaker AI esteja em estado InService, você pode proceder à invocação do endpoint para testar a funcionalidade de transmissão bidirecional. O cliente Python conecta-se ao endpoint do SageMaker AI e envia dados em chunks, recebendo respostas simultâneas.

    #!/usr/bin/env python3
    """
    Script Python para Transmissão Bidirecional no SageMaker AI.
    Conecta-se a um endpoint do SageMaker AI para comunicação bidirecional.
    """
    
    import argparse
    import asyncio
    import sys
    from aws_sdk_sagemaker_runtime_http2.client import SageMakerRuntimeHTTP2Client
    from aws_sdk_sagemaker_runtime_http2.config import Config, HTTPAuthSchemeResolver
    from aws_sdk_sagemaker_runtime_http2.models import InvokeEndpointWithBidirectionalStreamInput, RequestStreamEventPayloadPart, RequestPayloadPart
    from smithy_aws_core.identity import EnvironmentCredentialsResolver
    from smithy_aws_core.auth.sigv4 import SigV4AuthScheme
    import logging
    
    def parse_arguments():
        """Analisa argumentos da linha de comando."""
        parser = argparse.ArgumentParser(
            description="Conecta-se a um endpoint do SageMaker AI para transmissão bidirecional"
        )
        parser.add_argument(
            "ENDPOINT_NAME",
            help="Nome do endpoint do SageMaker AI para conectar"
        )
        return parser.parse_args()
    
    AWS_REGION = "us-west-2"
    BIDI_ENDPOINT = f"https://runtime.sagemaker.{AWS_REGION}.amazonaws.com:8443"
    logging.basicConfig(level=logging.INFO)
    logger = logging.getLogger(__name__)
    
    class SimpleClient:
        def __init__(self, endpoint_name, region=AWS_REGION):
            self.endpoint_name = endpoint_name
            self.region = region
            self.client = None
            self.stream = None
            self.response = None
            self.is_active = False
    
        def _initialize_client(self):
            config = Config(
                endpoint_uri=BIDI_ENDPOINT,
                region=self.region,
                aws_credentials_identity_resolver=EnvironmentCredentialsResolver(),
                auth_scheme_resolver=HTTPAuthSchemeResolver(),
                auth_schemes={"aws.auth#sigv4": SigV4AuthScheme(service="sagemaker")}
            )
            self.client = SageMakerRuntimeHTTP2Client(config=config)
    
        async def start_session(self):
            if not self.client:
                self._initialize_client()
            logger.info(f"Iniciando sessão com endpoint: {self.endpoint_name}")
            self.stream = await self.client.invoke_endpoint_with_bidirectional_stream(
                InvokeEndpointWithBidirectionalStreamInput(endpoint_name=self.endpoint_name)
            )
            self.is_active = True
            self.response = asyncio.create_task(self._process_responses())
    
        async def send_words(self, words):
            for i, word in enumerate(words):
                logger.info(f"Enviando payload: {word}")
                await self.send_event(word.encode('utf-8'))
                await asyncio.sleep(1)
    
        async def send_event(self, data_bytes):
            payload = RequestPayloadPart(bytes_=data_bytes)
            event = RequestStreamEventPayloadPart(value=payload)
            await self.stream.input_stream.send(event)
    
        async def end_session(self):
            if not self.is_active:
                return
            await self.stream.input_stream.close()
            logger.info("Stream fechado")
    
        async def _process_responses(self):
            try:
                output = await self.stream.await_output()
                output_stream = output[1]
                while self.is_active:
                    result = await output_stream.receive()
                    if result is None:
                        logger.info("Sem mais respostas")
                        break
                    if result.value and result.value.bytes_:
                        response_data = result.value.bytes_.decode('utf-8')
                        logger.info(f"Recebido: {response_data}")
            except Exception as e:
                logger.error(f"Erro ao processar respostas: {e}")
    
    def main():
        """Função principal para analisar argumentos e executar o cliente de streaming."""
        args = parse_arguments()
        print("=" * 60)
        print("Cliente de Transmissão Bidirecional SageMaker AI")
        print("=" * 60)
        print(f"Nome do Endpoint: {args.ENDPOINT_NAME}")
        print(f"Região AWS: {AWS_REGION}")
        print("=" * 60)
    
        async def run_client():
            sagemaker_client = SimpleClient(endpoint_name=args.ENDPOINT_NAME)
            try:
                await sagemaker_client.start_session()
                words = ["Preciso de ajuda com", "meu saldo da conta", "Posso ajudar com isso", "e cobranças recentes"]
                await sagemaker_client.send_words(words)
                await asyncio.sleep(2)
                await sagemaker_client.end_session()
                sagemaker_client.is_active = False
                if sagemaker_client.response and not sagemaker_client.response.done():
                    sagemaker_client.response.cancel()
                logger.info("Sessão encerrada com sucesso")
                return 0
            except Exception as e:
                logger.error(f"Erro no cliente: {e}")
                return 1
    
        try:
            exit_code = asyncio.run(run_client())
            sys.exit(exit_code)
        except KeyboardInterrupt:
            logger.info("Interrompido pelo usuário")
            sys.exit(1)
        except Exception as e:
            logger.error(f"Erro inesperado: {e}")
            sys.exit(1)
    
    if __name__ == "__main__":
        main()
    Imagem original — fonte: Aws

    Integração com Modelos Deepgram no SageMaker AI

    Parceria e Capacidades

    A AWS e a Deepgram colaboraram para construir suporte de transmissão bidirecional especificamente para endpoints do SageMaker AI. A Deepgram, parceira de Tier Avançado da AWS, oferece modelos de IA de voz em nível empresarial com precisão e velocidade líderes do setor. Seus modelos alimentam aplicações de transcrição em tempo real, conversão de texto para fala e agentes de voz para contact centers, plataformas de mídia e aplicações de IA conversacional.

    Para clientes com requisitos rigorosos de conformidade que exigem que o processamento de áudio nunca saia de sua Nuvem Privada Virtual (VPC) na AWS, as opções tradicionais auto-hospedadas demandavam sobrecarga operacional considerável para configuração e manutenção. A transmissão bidirecional do Amazon SageMaker transforma completamente essa experiência, permitindo que os clientes implantem e escalem aplicações de IA em tempo real com apenas alguns poucos cliques no Console de Gerenciamento da AWS.

    O modelo de fala para texto Deepgram Nova-3 está disponível atualmente no AWS Marketplace para implantação como um endpoint do SageMaker AI, com modelos adicionais chegando em breve. As capacidades incluem transcrição multilíngue, desempenho em escala empresarial e reconhecimento específico de domínio. A Deepgram oferece um período de avaliação gratuita de 14 dias no Amazon SageMaker AI para desenvolvedores prototiparem aplicações sem incorrer em custos de licença de software. As cobranças de infraestrutura do tipo de máquina escolhido ainda serão incorridas durante esse período. Para mais detalhes, consulte a documentação de preços do Amazon SageMaker AI.

    Configurando um Endpoint Deepgram no SageMaker AI

    Para configurar um endpoint Deepgram no SageMaker AI, navegue até a seção de pacotes de modelos do AWS Marketplace dentro do console do Amazon SageMaker AI e procure por Deepgram. Inscreva-se no produto e proceda ao assistente de lançamento na página do produto. Continue fornecendo detalhes no assistente de criação de endpoint de inferência em tempo real do Amazon SageMaker AI. Certifique-se de editar a variante de produção para incluir um tipo de instância válido ao criar sua configuração de endpoint. O botão de edição pode estar oculto até que você role a direita na tabela de variantes de produção. O ml.g6.2xlarge é um tipo de instância preferido para testes iniciais. Consulte a documentação Deepgram para requisitos específicos de hardware e orientação de seleção. Na página de resumo do endpoint, anote o nome do endpoint que você forneceu, pois será necessário na seção seguinte.

    Usando o Endpoint Deepgram no SageMaker AI

    Uma aplicação TypeScript de exemplo mostra como transmitir um arquivo de áudio para o modelo Deepgram hospedado em um endpoint de inferência em tempo real do SageMaker AI e imprimir uma transcrição transmitida em tempo real. A função cria um fluxo do arquivo WAV abrindo um arquivo de áudio local e enviando-o para o Amazon SageMaker AI Inference em pequenos blocos binários.

    import * as fs from "fs";
    import * as path from "path";
    import { RequestStreamEvent } from '@aws-sdk/client-sagemaker-runtime-http2';
    
    function sleep(ms: number): Promise {
      return new Promise(resolve => setTimeout(resolve, ms));
    }
    
    async function* streamWavFile(filePath: string): AsyncIterable {
      const full = path.resolve(filePath);
      if (!fs.existsSync(full)) {
        throw new Error(`Arquivo de áudio não encontrado: ${full}`);
      }
      console.log(`Transmitindo áudio: ${full}`);
      const readStream = fs.createReadStream(full, { highWaterMark: 512_000 }); // 512 KB
      for await (const chunk of readStream) {
        yield { PayloadPart: { Bytes: chunk, DataType: "BINARY" } };
      }
      // Mantenha o stream ativo para receber respostas de transcrição após todo arquivo ser enviado
      console.log("Áudio enviado, aguardando conclusão da transcrição...");
      await sleep(15000); // Aguarde 15 segundos para processamento do bloco final de áudio
      // Avise ao contêiner que terminamos
      yield { PayloadPart: { Bytes: new TextEncoder().encode('{"type":"CloseStream"}'), DataType: "UTF8" } };
    }

    O cliente de tempo de execução do AWS SageMaker AI é configurado especificando a região AWS, o nome do endpoint do SageMaker AI e a rota do modelo Deepgram dentro do contêiner. Você precisa atualizar esses valores conforme necessário.

    import { SageMakerRuntimeHTTP2Client, InvokeEndpointWithBidirectionalStreamCommand } from '@aws-sdk/client-sagemaker-runtime-http2';
    
    const region = "us-east-1"; // Região AWS
    const endpointName = "REPLACEME"; // Nome do seu endpoint Deepgram SageMaker
    const audioFile = "test.wav"; // Arquivo de áudio local
    const modelInvocationPath = "v1/listen"; // Caminho WebSocket dentro do contêiner do modelo
    const modelQueryString = "model=nova-3";
    const client = new SageMakerRuntimeHTTP2Client({ region });

    O trecho final envia o fluxo de áudio ao endpoint do SageMaker AI e imprime os eventos JSON de transmissão da Deepgram conforme chegam. A aplicação exibe a saída de fala para texto ao vivo sendo gerada.

    async function run() {
      console.log("Enviando áudio para Deepgram via SageMaker...");
      const command = new InvokeEndpointWithBidirectionalStreamCommand({
        EndpointName: endpointName,
        Body: streamWavFile(audioFile),
        ModelInvocationPath: modelInvocationPath,
        ModelQueryString: modelQueryString
      });
      const response = await client.send(command);
      if (!response.Body) {
        console.log("Nenhuma resposta de streaming recebida.");
        return;
      }
      const decoder = new TextDecoder();
      for await (const msg of response.Body) {
        if (msg.PayloadPart?.Bytes) {
          const text = decoder.decode(msg.PayloadPart.Bytes);
          try {
            const parsed = JSON.parse(text);
            // Extraia e exiba a transcrição
            if (parsed.channel?.alternatives?.[0]?.transcript) {
              const transcript = parsed.channel.alternatives[0].transcript;
              if (transcript.trim()) {
                console.log("Transcrição:", transcript);
              }
            }
            console.debug("Deepgram (bruto):", parsed);
          } catch {
            console.error("Deepgram (erro):", text);
          }
        }
      }
    }
    console.log("Streaming concluído.");
    }
    run().catch(console.error);

    Para informações mais detalhadas e exemplos adicionais, consulte a página de documentação Deepgram. Se precisar de suporte adicional com a configuração, conecte-se com a Comunidade de Desenvolvedores Deepgram.

    Conclusão

    A transmissão bidirecional no Amazon SageMaker AI Inference representa um avanço significativo na forma como os desenvolvedores podem construir aplicações de IA em tempo real. Ao eliminar as limitações das interações transacionais tradicionais, essa capacidade abre possibilidades para experiências de usuário genuinamente conversacionais e responsivas.

    Com suporte para contêineres customizados e integração pronta com modelos parceiros como o Deepgram, a plataforma oferece flexibilidade tanto para quem deseja trazer seus próprios modelos quanto para quem busca soluções prontas para produção. A infraestrutura de três camadas garante eficiência, enquanto o monitoramento automático de conexão assegura confiabilidade.

    Developers podem começar a construir aplicações de transmissão bidirecional com Modelos de Linguagem Grande (LLMs) e SageMaker AI hoje mesmo, abrindo novos horizontes para agentes de voz, assistentes conversacionais e qualquer aplicação que se beneficie de comunicação em tempo real verdadeiramente bidirecional.

    Fonte

    Introducing bidirectional streaming for real-time inference on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/introducing-bidirectional-streaming-for-real-time-inference-on-amazon-sagemaker-ai/)

  • Gerenciamento de clusters SageMaker HyperPod com o novo servidor MCP de IA da Amazon

    Novo servidor MCP do SageMaker com suporte a HyperPod

    A AWS ampliou as capacidades do servidor MCP (Model Context Protocol) de IA do SageMaker, adicionando ferramentas especializadas para configuração e gerenciamento de clusters HyperPod. Esse avanço permite que assistentes de código alimentados por IA possam provisionar e operar clusters de IA e aprendizado de máquina completos, desde o treinamento inicial até a implantação de modelos em produção.

    O que é SageMaker HyperPod e por que importa

    O SageMaker HyperPod foi desenvolvido pela AWS para eliminar tarefas repetitivas e de baixo nível no processo de construção de modelos de IA generativa. A solução escala rapidamente tarefas como treinamento, ajuste fino e implantação de modelos em grupos de aceleradores de IA. Com a integração ao servidor MCP de IA, agora é possível que assistentes de código configurem e gerenciem essa infraestrutura complexa de forma intuitiva.

    Como funcionam os servidores MCP na AWS

    Os servidores MCP no ecossistema da AWS oferecem uma interface padronizada que amplifica a capacidade de desenvolvimento assistido por IA. Equipam os assistentes de código com compreensão em tempo real e contextualizada de diferentes serviços AWS, integrando-se perfeitamente ao fluxo de trabalho dos desenvolvedores.

    Capacidades do novo servidor MCP de IA do SageMaker

    Configuração simplificada de clusters

    O servidor MCP do SageMaker oferece ferramentas que simplificam o ciclo de vida completo das operações de cluster de IA/ML. Os agentes de IA conseguem configurar clusters HyperPod orquestrados tanto pelo Amazon EKS (Elastic Kubernetes Service) quanto pelo Slurm, com todos os pré-requisitos inclusos. A solução usa modelos CloudFormation que otimizam automaticamente rede, armazenamento e recursos de computação, garantindo que os clusters estejam prontos para cargas de trabalho de treinamento distribuído de alta performance.

    Gerenciamento e operações contínuas

    Além da configuração inicial, o servidor oferece ferramentas abrangentes para administração de clusters e nós, incluindo operações de dimensionamento, aplicação de patches de software e manutenção diversa. Quando integrado ao API MCP Server da AWS, ao Knowledge MCP Server e ao Amazon EKS MCP Server, você ganha cobertura completa de todas as APIs do SageMaker HyperPod, permitindo diagnóstico eficaz de problemas comuns—como identificar por que um nó se tornou inacessível.

    Benefícios para diferentes perfis

    Administradores de cluster

    Para equipes de administração, as ferramentas simplificam operações diárias, reduzindo overhead manual e facilitando a manutenção de infraestrutura em larga escala.

    Cientistas de dados

    Para profissionais de ciência de dados, a solução permite configurar e escalar clusters de IA/ML sem necessidade de expertise profunda em infraestrutura, liberando tempo para focar no que realmente importa: treinar e implantar modelos eficientes.

    Disponibilidade e próximos passos

    O gerenciamento de clusters de IA/ML através do servidor MCP do SageMaker está disponível em todas as regiões onde o SageMaker HyperPod opera. Para começar, consulte a documentação do servidor MCP do SageMaker.

    Fonte

    Manage Amazon SageMaker HyperPod clusters with the new Amazon SageMaker AI MCP Server (https://aws.amazon.com/about-aws/whats-new/2025/11/manage-amazon-sagemaker-hyperpod-clusters-mcp-server/)

  • Amazon OpenSearch Service apresenta Busca Agentica

    Busca Agentica: Uma Nova Forma de Interagir com Dados

    A AWS anunciou o lançamento do recurso Agentic Search no Amazon OpenSearch Service, revolucionando a maneira como os usuários buscam e interagem com seus dados. Esse novo sistema utiliza agentes inteligentes orientados por linguagem natural, eliminando a necessidade de conhecer a sintaxe complexa de consultas tradicionais.

    Como Funciona o Agentic Search

    O Agentic Search introduz um sistema de busca orientado por agentes que compreende a intenção do usuário, orquestra o conjunto adequado de ferramentas, gera consultas em DSL (Linguagem de Domínio Específico) do OpenSearch e fornece resumos transparentes do seu processo de tomada de decisão através de cláusulas simples e consultas em linguagem natural.

    Ao automatizar o planejamento e a execução de consultas do OpenSearch, o recurso dispensa a necessidade de sintaxe de busca complexa. Usuários podem fazer perguntas simples como “Encontre carros vermelhos por menos de 30 mil reais” ou “Mostre tendências de vendas do último trimestre”. O agente interpreta a intenção, aplica as estratégias de busca mais adequadas e entrega os resultados enquanto explica seu raciocínio.

    Tipos de Agentes Disponíveis

    Agentes Conversacionais

    Esses agentes lidam com interações complexas e possuem a capacidade de armazenar conversas em memória, permitindo contexto contínuo entre múltiplas consultas.

    Agentes de Fluxo

    Projetados para processamento eficiente de consultas, os agentes de fluxo oferecem respostas rápidas e diretas.

    Tecnologia e Acessibilidade

    O QueryPlanningTool integrado utiliza modelos de linguagem grandes (LLMs) para criar consultas em DSL, tornando a busca acessível independentemente do nível de expertise técnica do usuário. As buscas agênticas podem ser gerenciadas através de APIs ou do OpenSearch Dashboards, permitindo configuração e modificação dos agentes conforme necessário.

    As configurações avançadas do Agentic Search permitem conexão com servidores MCP externos e o uso de modelos de busca personalizados, oferecendo flexibilidade para casos de uso mais sofisticados.

    Disponibilidade e Recursos

    O suporte para Agentic Search está disponível para OpenSearch Service versão 3.3 e posteriores em todas as regiões comerciais da AWS e na AWS GovCloud (US) onde o OpenSearch Service opera. Para uma listagem completa das regiões, consulte a documentação de infraestrutura global.

    Usuários podem construir agentes e executar buscas agênticas utilizando o novo caso de uso de Agentic Search disponível no plugin AI Search Flows. Para aprender mais sobre o Agentic Search, consulte a documentação técnica do OpenSearch.

    Fonte

    Amazon OpenSearch Service introduces Agentic Search (https://aws.amazon.com/about-aws/whats-new/2025/11/opensearch-service-agentic-search/)

  • Amazon SageMaker AI Inference agora suporta streaming bidirecional para transcrição em tempo real

    Transcrição de fala em tempo real: o desafio dos agentes de voz

    À medida que empresas expandem o desenvolvimento de agentes de voz com inteligência artificial, surge um desafio crítico: oferecer transcrição de fala em tempo real com o menor atraso possível. O intervalo entre o usuário falar e o agente responder é fundamental para criar experiências naturais e intuitivas. Historicamente, equipes de engenharia precisavam construir soluções customizadas para gerenciar este processamento contínuo, investindo semanas em desenvolvimento e manutenção de infraestrutura específica para protocolos de streaming — tempo que poderia ser dedicado à melhoria da precisão dos modelos.

    A solução: streaming bidirecional no SageMaker AI Inference

    A AWS introduziu suporte a streaming bidirecional no Amazon SageMaker AI Inference, transformando a forma como modelos de fala são implantados em produção. Esse recurso permite que modelos de transcrição de fala recebam fluxos de áudio contínuos e retornem transcrições parciais simultaneamente enquanto o usuário está falando — eliminando a necessidade de entrada em lotes e processamento aguardando o término da fala.

    Como funciona a implementação

    O modelo operacional é elegante em sua simplicidade. Cientistas de dados e engenheiros de machine learning podem implantar modelos de fala-para-texto invocando o endpoint através da nova API Bidirectional Stream. O cliente abre uma conexão HTTP/2 com o runtime do SageMaker AI, que automaticamente cria uma conexão WebSocket para o container. Este container processa quadros de áudio em streaming e retorna transcrições parciais conforme são geradas.

    O design é agnóstico ao modelo: qualquer container que implemente um handler WebSocket seguindo o contrato do SageMaker AI funciona automaticamente. Modelos de speech em tempo real como o Deepgram funcionam sem necessidade de modificações, demonstrando a flexibilidade da abordagem.

    Impacto prático: eliminando meses de desenvolvimento

    Essa implementação elimina meses de desenvolvimento de infraestrutura customizada. Equipes que gastavam semanas mantendo protocolos de WebSocket, gerenciando conexões e otimizando latência agora podem concentrar seus esforços onde realmente importa: melhorando a precisão do modelo, refinando as capacidades do agente e criando experiências de usuário superiores.

    Disponibilidade global

    O recurso de streaming bidirecional está disponível em mais de 30 regiões AWS distribuídas globalmente, incluindo Canada (Central), South America (São Paulo), Africa (Cape Town), Europe (Paris), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Israel (Tel Aviv), Europe (Zurich), Asia Pacific (Tokyo), AWS GovCloud US (West), AWS GovCloud US (East), Asia Pacific (Mumbai), Middle East (Bahrain), US West (Oregon), China (Ningxia), US West (Northern California), Asia Pacific (Sydney), Europe (London), Asia Pacific (Seoul), US East (N. Virginia), Asia Pacific (Hong Kong), US East (Ohio), China (Beijing), Europe (Stockholm), Europe (Ireland), Middle East (UAE), Asia Pacific (Osaka), Asia Pacific (Melbourne), Europe (Spain), Europe (Frankfurt), Europe (Milan) e Asia Pacific (Singapore).

    Próximos passos

    Para explorar essa funcionalidade, consulte o blog de notícias da AWS e a documentação do SageMaker AI para detalhes técnicos completos sobre implementação e melhores práticas.

    Fonte

    Amazon SageMaker AI Inference now supports bidirectional streaming (https://aws.amazon.com/about-aws/whats-new/2025/11/sagemaker-ai-inference-bidirectional-streaming/)

  • AWS Network Firewall Proxy chega em prévia pública com controles centralizados de segurança

    Nova camada de proteção contra ameaças de rede

    A AWS anunciou o lançamento do Network Firewall Proxy em prévia pública, um novo recurso que reforça significativamente a postura defensiva das organizações contra ameaças de exfiltração de dados e injeção de malware. O serviço foi projetado para funcionar em modo explícito, permitindo que seja configurado em apenas alguns cliques.

    O destaque principal do Network Firewall Proxy é sua capacidade de gerenciar e proteger o tráfego de dados que sai das aplicações, bem como as respostas que essas aplicações recebem. Isso oferece um controle muito mais preciso sobre as comunicações de rede que atravessam a infraestrutura corporativa.

    Capacidades e controles granulares

    Proteção contra spoofing e acesso não autorizado

    O Network Firewall Proxy da AWS protege as organizações contra tentativas de falsificação de nomes de domínio ou do índice de nome do servidor (SNI — Server Name Index). Além disso, oferece flexibilidade para implementar controles de acesso muito específicos e adaptados às necessidades de cada ambiente.

    Um dos casos de uso mais importantes é a restrição de acesso das aplicações apenas para domínios ou endereços IP confiáveis. O recurso também permite bloquear respostas não intencionais provenientes de servidores externos, criando uma barreira efetiva contra comunicações não autorizadas.

    Inspeção de TLS e filtragem avançada

    O serviço permite ativar a inspeção de TLS (Transport Layer Security) e estabelecer controles granulares de filtragem baseados em atributos de cabeçalho HTTP. Isso significa que é possível examinar e controlar comunicações mesmo quando criptografadas, ampliando as possibilidades de proteção sem sacrificar a privacidade.

    Monitoramento e análise detalhada

    O Network Firewall Proxy oferece registros abrangentes para monitoramento contínuo das aplicações. Esses logs podem ser direcionados para o Amazon S3 (Simple Storage Service) e o AWS CloudWatch, permitindo análises detalhadas e facilitando processos de auditoria. Essa rastreabilidade é especialmente importante para organizações que precisam atender requisitos regulatórios rigorosos.

    Disponibilidade e próximos passos

    O Network Firewall Proxy está disponível em prévia pública na região US East (Ohio) e, durante este período, é oferecido gratuitamente. Organizações interessadas são convidadas a testar o recurso em ambientes de teste para avaliar seu impacto nas estratégias de segurança de rede.

    Para maiores detalhes sobre implementação e funcionalidades técnicas, consulte a documentação técnica do AWS Network Firewall Proxy.

    Fonte

    Introducing AWS Network Firewall Proxy in preview (https://aws.amazon.com/about-aws/whats-new/2025/11/aws-network-firewall-proxy-preview)