Author: Make.com Service User

Entendendo o Ajuste Fino com Mistura de Dados

O ajuste fino de modelos de linguagem é uma técnica fundamental para empresas que desejam especializar sistemas de IA em seus próprios domínios. No entanto, existe um dilema clássico: ao treinar um modelo apenas com dados do seu negócio, ele pode perder suas capacidades gerais. A AWS abordou este desafio através da técnica de mistura de dados, que blenda informações específicas do domínio com conjuntos de dados curados pela empresa.

Esta é a segunda parte de uma série sobre a Nova Forge SDK. Os artigos anteriores cobriram a introdução ao SDK e os primeiros passos com experimentos de customização. O diferencial desta abordagem está na capacidade de manter o desempenho do modelo em testes de conhecimento geral (como Massive Multitask Language Understanding, MMLU) enquanto melhora significativamente o desempenho em tarefas específicas do negócio.

Em um caso demonstrado pela AWS, a mistura de dados produziu uma melhoria de 12 pontos em F1 em uma tarefa de classificação complexa, mantendo simultaneamente scores MMLU próximos aos do modelo original. Por contraste, o ajuste fino apenas com dados do cliente causou uma queda drástica nas capacidades gerais.

Visão Geral do Fluxo de Trabalho

O processo completo organiza-se em cinco etapas principais:

• Configuração de Ambiente: instalação da SDK e preparação de recursos da AWS
• Preparação de Dados: limpeza, transformação e validação dos dados de treinamento
• Configuração de Treinamento: setup do HyperPod, MLflow e proporções de mistura de dados
• Treinamento do Modelo: execução do ajuste fino com adaptadores de baixo-rank (LoRA)
• Avaliação: testes em benchmarks públicos e avaliações específicas do domínio

Pré-requisitos e Considerações de Custo

Para executar este workflow, você precisará de uma conta AWS com acesso à Amazon Nova Forge, um cluster SageMaker HyperPod provisionado com instâncias GPU (o guia usa instâncias ml.p5.48xlarge, e uma aplicação Amazon SageMaker MLflow para rastreamento de experimentos.

A configuração do cluster HyperPod envolve configurar um cluster Amazon Elastic Kubernetes Service (EKS), provisionar nós de computação e criar papéis de execução. Para instruções detalhadas, consulte a documentação sobre Como Começar com SageMaker HyperPod.

Importante: este guia utiliza 4 instâncias ml.p5.48xlarge para treinamento e avaliação. Recomenda-se começar com um teste curto (por exemplo, max_steps=5) para validar sua configuração antes de se comprometer com um treinamento completo. Consulte a página de preços do Amazon SageMaker para taxas atualizadas.

Preparação de Dados e Sanitização

A Nova Forge SDK aceita formatos JSONL, JSON e CSV. O guia utiliza o dataset MedReason publicamente disponível no Hugging Face, contendo aproximadamente 32.700 pares de pergunta-resposta para demonstrar o ajuste fino em um caso de uso específico do domínio médico.

Um passo crítico é a sanitização de dados. A SDK implementa validação a nível de token, e certos tokens entram em conflito com o template de chat interno do modelo. Strings literais como System: ou Assistant: podem ser interpretadas como delimitadores de turno, corrompendo o sinal de treinamento. O processo de sanitização insere um espaço antes do dois-pontos (por exemplo, System: → System :) para quebrar o padrão, preservando legibilidade, e remove tokens especiais como [EOS] e <image> que possuem significado reservado.

Após o carregamento e limpeza dos dados, a SDK fornece um JSONLDatasetLoader que converte dados brutos no formato esperado pelos modelos Nova. O método transform() envolve cada par pergunta-resposta no template de chat Nova, convertendo:

Antes da transformação (JSONL bruto):

{ "question": "What are the causes of chest pain in a 45-year-old patient?", "answer": "Chest pain in a 45-year-old can result from cardiac causes such as..." }

Depois da transformação (formato template Nova):

{ "messages": [ {"role": "user", "content": "What are the causes of chest pain in a 45-year-old patient?"}, {"role": "assistant", "content": "Chest pain in a 45-year-old can result from cardiac causes such as..."} ] }

O método validate() verifica então se os dados transformados estão corretos, confirmando que a estrutura do template está apropriada, que nenhum token inválido permanece, e que os dados estão em conformidade com os requisitos do modelo e método de treinamento escolhido.

Configuração e Execução do Treinamento

Ao ativar a mistura de dados, a Nova Forge automaticamente blenda seus dados específicos do domínio com conjuntos de dados curados pela AWS durante o ajuste fino. Isso impede que o modelo esqueça suas capacidades gerais enquanto aprende seu domínio.

A AWS oferece dois métodos principais de ajuste fino. O guia utiliza Supervised Fine-Tuning (SFT) com LoRA (Adaptadores de Baixo Rank), que atualiza apenas um pequeno conjunto de pesos do adaptador, resultando em treinamento mais rápido, custos menores de computação e é o ponto de partida recomendado. A AWS também suporta SFT de rank completo, que atualiza todos os parâmetros do modelo e pode incorporar mais conhecimento do domínio, mas exige mais computação e é mais suscetível ao esquecimento catastrófico.

Configuração de Mistura de Dados

A mistura de dados controla como os lotes de treinamento são compostos. O parâmetro customer_data_percent determina que fração de cada lote vem de seus dados de domínio. A fração restante é preenchida por conjuntos de dados curados pela Nova, com cada parâmetro nova_*_percent controlando o peso relativo dessa categoria de capacidade dentro da porção Nova.

Por exemplo, com uma configuração típica: 50% de cada lote de treinamento consiste em seus dados de domínio, e 50% em dados curados pela Nova, distribuídos entre categorias de capacidade conforme seus pesos relativos. Os percentuais no lado Nova devem somar 100.

O post anterior desta série demonstrou que até uma divisão 75/25 de cliente-para-Nova preserva MMLU praticamente no baseline (0,74 versus 0,75 baseline) enquanto entrega uma melhoria de 12 pontos F1 em uma tarefa de classificação complexa.

Parâmetros de Treinamento Principais

Os hiperparâmetros chave permitem controlar o comportamento do treinamento:

• lr (learning rate): 1e-5 é um padrão razoável para ajuste fino com LoRA
• warmup_steps: passos para aumentar gradualmente a taxa de aprendizado, tipicamente 5-10% do total de passos
• global_batch_size: número de exemplos por atualização de gradiente em todas as GPUs
• max_length: comprimento máximo da sequência em tokens; 65.536 suporta casos de uso de contexto longo
• max_steps: passos totais de treinamento; comece pequeno (5-10) para validar seu setup

Monitoramento e Avaliação do Modelo

A avaliação é crítica quando você usa mistura de dados, pois você precisa medir simultaneamente se o modelo melhorou em sua tarefa de domínio e se reteve suas capacidades gerais. Se você medir apenas um eixo, não saberá se a mistura está funcionando.

A Nova Forge suporta três abordagens complementares de avaliação:

Benchmarks Públicos

Estes medem se a mistura de dados está preservando as capacidades gerais. Testes como MMLU (conhecimento amplo e raciocínio em 57 assuntos) e IFEval (capacidade de seguir instruções estruturadas) indicam se sua mistura está sendo efetiva. Se MMLU cair significativamente do baseline, sua mistura precisa de mais dados Nova. Se IFEval cair, aumente o peso de instrução-seguimento.

Dados Próprios (Bring-Your-Own-Data)

Use seu conjunto de teste retido para medir se o ajuste fino melhorou o desempenho em sua tarefa real.

LLM como Juiz

Para domínios onde métricas automatizadas são insuficientes, você pode usar outro LLM para avaliar a qualidade das respostas.

Interpretando Resultados

Use este framework de decisão para guiar sua próxima iteração:

• MMLU próximo do baseline: A mistura de dados está prevenindo esquecimento catastrófico com sucesso. Sua mistura está funcionando — foque em desempenho de domínio.
• MMLU degradado significativamente: O modelo está esquecendo capacidades gerais. Diminua customer_data_percent ou aumente pesos de dados Nova.
• Desempenho de tarefa de domínio abaixo do esperado: O modelo não está aprendendo o suficiente de seus dados. Aumente customer_data_percent, adicione mais dados de treinamento, ou aumente max_steps.
• IFEval degradado: O modelo está perdendo a capacidade de seguir instruções. Aumente nova_instruction-following_percent.
• MMLU e desempenho de tarefa de domínio melhoraram: Resultado ideal. Documente sua configuração e promova para produção.

Melhores Práticas

Comece com as proporções de mistura padrão — elas foram ajustadas para um equilíbrio bem calibrado. Só customize após ter resultados de avaliação de baseline para comparar contra.

Sempre avalie em ambos os eixos. Execute pelo menos um benchmark público (como MMLU) juntamente com sua avaliação específica do domínio. Sem ambas, você não consegue dizer se a mistura está funcionando.

Use MLflow para comparar experimentos. Ao iterar sobre proporções de mistura e hiperparâmetros, MLflow simplifica significativamente a comparação de execuções lado a lado e a identificação da melhor configuração.

Itere sobre a mistura, não apenas hiperparâmetros. Se seu modelo está esquecendo capacidades gerais, ajustar a mistura de dados é frequentemente mais efetivo do que tunar taxa de aprendizado ou tamanho de lote.

Comece com LoRA e mude para rank completo se necessário. LoRA é mais rápido e barato. Só mude para SFT de rank completo se LoRA não atingir adaptação de domínio suficiente para seu caso de uso.

Próximos Passos

Para começar, consulte a Nova Forge Developer Guide para documentação detalhada e explore a Nova Forge SDK para referência completa da API.

O fluxo de trabalho descrito fornece um playbook repetível que você pode adaptar ao seu caso de uso específico. A mistura de dados é o que torna o ajuste fino prático para produção — em vez de escolher entre expertise de domínio e inteligência geral, você obtém ambas. A chave é tratar isso como um processo iterativo: treina, avalia em ambos os eixos, ajusta a mistura, e repete até encontrar o equilíbrio certo.

Fonte

Nova Forge SDK series part 2: Practical guide to fine-tune Nova models using data mixing capabilities (https://aws.amazon.com/blogs/machine-learning/nova-forge-sdk-series-part-2-practical-guide-to-fine-tune-nova-models-using-data-mixing-capabilities/)

Novo Recurso de Flexibilidade no SageMaker HyperPod

A AWS anunciou suporte a grupos de instâncias flexíveis no Amazon SageMaker HyperPod, um avanço significativo para clientes que precisam executar cargas de trabalho de treinamento e inferência em ambientes com requisitos complexos de infraestrutura. Esse novo recurso permite especificar múltiplos tipos de instância e múltiplas subnets dentro de um único grupo de instâncias, simplificando a gestão de clusters heterogêneos.

O Desafio Anterior

Clientes que utilizam o HyperPod frequentemente necessitam distribuir suas workloads através de múltiplos tipos de instância e zonas de disponibilidade. Isso ocorre por três razões principais: resiliência de capacidade, otimização de custos e melhor aproveitamento de subnets. Até agora, esse cenário exigia que os usuários criassem e gerenciassem um grupo de instâncias separado para cada combinação de tipo de instância e zona de disponibilidade.

Essa abordagem gerava sobrecarga operacional considerável. Os times precisavam lidar com complexidade adicional em configuração de cluster, escalabilidade, aplicação de patches e monitoramento — tudo multiplicado pelo número de combinações de instâncias necessárias.

Como os Grupos Flexíveis Resolvem o Problema

Com os grupos de instâncias flexíveis, a configuração muda radicalmente. Os usuários podem agora definir uma lista ordenada de tipos de instância usando o novo parâmetro InstanceRequirements e fornecer múltiplas subnets distribuídas entre zonas de disponibilidade em um único grupo de instâncias.

O HyperPod provisiona instâncias começando pelo tipo de maior prioridade e executa um fallback automático para tipos de menor prioridade quando a capacidade não está disponível. Isso elimina a necessidade de clientes tentarem manualmente diferentes grupos de instâncias quando uma opção não está disponível.

Benefícios por Caso de Uso

Para Cargas de Treinamento

Clientes de treinamento se beneficiam da distribuição entre múltiplas subnets dentro de uma mesma zona de disponibilidade, evitando esgotamento de endereços IP em uma subnet individual — um problema comum em ambientes de larga escala.

Para Cargas de Inferência

Clientes que fazem escalabilidade manual ganham fallback automático baseado em prioridade entre tipos de instância, sem precisar retentar cada grupo individualmente. Aqueles que utilizam Karpenter para autoscaling podem fazer referência a um único grupo de instâncias flexível. O Karpenter detecta automaticamente os tipos de instância suportados a partir do grupo flexível e provisiona o tipo e zona de disponibilidade ótima com base nos requisitos do pod.

Como Usar

Os grupos de instâncias flexíveis podem ser criados através das APIs CreateCluster e UpdateCluster, via AWS CLI, ou através do AWS Management Console. Esse recurso está disponível para clusters SageMaker HyperPod utilizando o orquestrador EKS (Elastic Kubernetes Service) em todas as regiões AWS onde SageMaker HyperPod é suportado.

Para detalhes técnicos completos e instruções de implementação, consulte a documentação sobre grupos de instâncias flexíveis.

Fonte

Amazon SageMaker HyperPod now supports flexible instance groups (https://aws.amazon.com/about-aws/whats-new/2026/04/sagemaker-hyperpod-flexible-instance-groups/)

Expansão geográfica do FSx for Lustre Persistent-2

A AWS anunciou em abril de 2026 a expansão do Amazon FSx for Lustre Persistent-2 para quatro novas regiões. O serviço de sistemas de arquivos agora está disponível em regiões estratégicas que ampliam o alcance global da plataforma: Asia Pacific (Hyderabad e Jakarta), Europe (Zurich) e South America (São Paulo).

Para os usuários brasileiros, esta é uma notícia particularmente relevante, já que a região de São Paulo agora oferece suporte nativo ao Amazon FSx for Lustre Persistent-2, reduzindo latência e melhorando a conformidade com requisitos de residência de dados.

Características técnicas e melhorias

A geração Persistent-2 foi desenvolvida com base em AWS Graviton processors, trazendo melhorias significativas em relação às versões anteriores:

• Throughput aprimorado: até 1 GB/s por terabyte, oferecendo maior performance por unidade de armazenamento
• Redução de custos: menor custo de throughput em comparação com gerações anteriores do FSx for Lustre
• Otimização de arquitetura: aproveitamento da eficiência dos processadores Graviton para operações de I/O intensivas

Casos de uso beneficiados

O Amazon FSx for Lustre Persistent-2 é especialmente adequado para workloads exigentes que requerem performance de armazenamento elevada:

• Machine Learning: treinamento de modelos com acesso rápido a grandes volumes de dados
• Computação de alto desempenho (HPC): simulações científicas e de engenharia
• Media & Entertainment: processamento e renderização de conteúdo de mídia
• Simulações financeiras: análise de risco e modelagem quantitativa que exigem throughput consistente

Ao utilizar estes sistemas de arquivos, organizações conseguem acelerar a execução de suas cargas de trabalho enquanto reduzem o custo total de armazenamento e throughput.

Como começar

Os usuários interessados em aproveitar o Amazon FSx for Lustre Persistent-2 nas novas regiões podem iniciar criando um sistema de arquivos através da AWS Management Console.

Para informações técnicas detalhadas sobre o serviço, a AWS disponibiliza documentação completa na página do produto Amazon FSx for Lustre. Além disso, a Tabela de Regiões AWS oferece uma visão completa sobre a disponibilidade regional de todos os serviços.

Implicações para o mercado brasileiro

A chegada do FSx for Lustre Persistent-2 à região de São Paulo representa um passo importante para empresas brasileiras que trabalham com cargas de trabalho de data science, simulação computacional e processamento de mídia. A redução de latência, aliada à conformidade com residência de dados, pode impulsionar a adoção de soluções de machine learning e HPC no país.

Fonte

Amazon FSx for Lustre Persistent-2 file systems are now available in four additional AWS Regions (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-fsx-lustre-persistent-2-aws/)

O desafio da geração de texto para SQL em aplicações empresariais

A conversão de linguagem natural para consultas SQL permanece como um dos desafios mais complexos em aplicações de inteligência artificial empresarial, especialmente quando envolvem dialetos SQL customizados ou esquemas de banco de dados específicos de cada domínio. Embora os modelos de fundação (FMs) demonstrem um desempenho sólido com SQL padrão, alcançar precisão adequada para produção com dialetos especializados exige ajustes finos no modelo.

Acontece que o ajuste fino introduz uma questão operacional delicada: manter modelos customizados em infraestrutura persistente gera custos contínuos, mesmo durante períodos sem qualquer utilização. A Amazon Bedrock oferece uma alternativa através de inferência sob demanda com modelos Amazon Nova Micro ajustados. Ao combinar a eficiência do ajuste fino LoRA (Adaptação de Rank Baixo) com inferência serverless baseada em tokens pagos, as organizações conseguem implementar capacidades de texto para SQL customizadas sem os custos adicionais de hospedagem em modelo persistente.

Este artigo apresenta duas abordagens práticas para ajuste fino do Amazon Nova Micro, visando à geração de dialetos SQL customizados, entregando tanto eficiência de custos quanto desempenho pronto para produção. No exemplo de carga de trabalho demonstrado, manteve-se um custo mensal de apenas USD 0,80 com aproximadamente 22.000 consultas por mês — economias significativas se comparadas a infraestrutura de modelo hospedado permanentemente.

Preparação do ambiente e visão geral da solução

Pré-requisitos

Para implantar essas soluções, você precisará de:

• Uma conta AWS com faturamento habilitado
• Permissões padrão de IAM e papel configurados para acessar Amazon Bedrock, modelo Nova Micro, Amazon SageMaker AI e customização de modelo em Bedrock
• Cota para instância ml.g5.48xl no Amazon SageMaker AI para treinamento

Arquitetura geral

A solução segue uma sequência lógica de etapas:

• Preparar dataset de treinamento SQL customizado com pares entrada-saída específicos do dialeto SQL e requisitos de negócio da sua organização
• Iniciar o processo de ajuste fino no modelo Amazon Nova Micro usando o dataset preparado
• Escolher entre duas abordagens: customização de modelo gerenciada via Amazon Bedrock ou treinamento granular com Amazon SageMaker AI
• Implantar o modelo customizado na Bedrock para usar inferência sob demanda, eliminando gerenciamento de infraestrutura e pagando apenas pelo uso de tokens
• Validar desempenho do modelo com consultas de teste específicas para seu dialeto SQL e casos de uso

Preparação do dataset

A demonstração utiliza o dataset sql-create-context, uma combinação curada de WikiSQL e datasets Spider contendo mais de 78 mil exemplos de perguntas em linguagem natural emparelhadas com consultas SQL em diversos esquemas de banco de dados. Esse dataset oferece uma base ideal para ajuste fino de texto para SQL devido à sua variedade em complexidade de consultas, desde simples instruções SELECT até joins multi-tabela complexos com agregações.

Formatação e estrutura dos dados

Os dados de treinamento são estruturados conforme descrito na documentação. Isso envolve criar arquivos JSONL contendo instruções de prompt do sistema emparelhadas com consultas do usuário e respostas SQL correspondentes de complexidade variada. O dataset de treinamento formatado é então dividido em conjuntos de treinamento e validação, armazenado como arquivos JSONL e carregado no Amazon Simple Storage Service (Amazon S3) para o processo de ajuste fino.

Um exemplo de registro convertido segue o padrão bedrock-conversation-2024:

{ "schemaVersion": "bedrock-conversation-2024", "system": [ { "text": "You are a powerful text-to-SQL model. Your job is to answer questions about a database. You can use the following table schema for context: CREATE TABLE head (age INTEGER)" } ], "messages": [ { "role": "user", "content": [ { "text": "Return the SQL query that answers the following question: How many heads of the departments are older than 56 ?" } ] }, { "role": "assistant", "content": [ { "text": "SELECT COUNT(*) FROM head WHERE age > 56" } ] } ] }

Abordagem 1: Ajuste fino gerenciado via Amazon Bedrock

A customização de modelo via Amazon Bedrock oferece uma abordagem totalmente gerenciada e simplificada para ajuste fino de modelos Amazon Nova sem necessidade de provisionar ou gerenciar infraestrutura de treinamento. Esse método é ideal para equipes que buscam iteração rápida e complexidade operacional mínima enquanto alcançam desempenho de modelo customizado adequado para seus casos de uso de texto para SQL.

Usando as capacidades de customização da Bedrock, os dados de treinamento são carregados no S3, e os trabalhos de ajuste fino são configurados através do console AWS ou API. A AWS então gerencia toda a infraestrutura de treinamento subjacente. O modelo customizado resultante pode ser implantado usando inferência sob demanda, mantendo o mesmo preço baseado em tokens do modelo Nova Micro base sem markup adicional — tornando-se uma solução econômica para cargas de trabalho variáveis.

Criando um trabalho de ajuste fino

A Amazon Bedrock suporta ajuste fino tanto via Console AWS quanto via AWS SDK para Python (Boto3). A documentação AWS contém orientação geral sobre como enviar um trabalho de treinamento com ambas as abordagens. Você pode consultar o notebook de exemplo em nosso repositório GitHub para ver a implementação passo a passo.

Configuração de hiperparâmetros

Após selecionar o modelo a ajustar, você configura os hiperparâmetros para seu caso de uso. Para ajuste fino do Amazon Nova Micro na Bedrock, você pode customizar os seguintes hiperparâmetros para otimizar seu modelo de texto para SQL:

• Epochs (1–5): Número de passagens completas pelo dataset de treinamento — utilizamos 5 epochs
• Batch Size (fixo em 1): Número de amostras processadas antes de atualizar os pesos do modelo
• Learning Rate (0.000001–0.0001): Tamanho do passo para otimização de gradiente descendente — utilizamos 0.00001 para convergência estável
• Learning Rate Warmup Steps (0–100): Número de passos para aumentar gradualmente a taxa de aprendizado — utilizamos 10

No dataset de exemplo, essa configuração proporcionou um equilíbrio melhorado entre precisão do modelo e tempo de treinamento, completando em aproximadamente 2-3 horas.

Análise de métricas de treinamento

A Bedrock gera automaticamente métricas de treinamento e validação, armazenadas em seu local de saída especificado no S3. Essas métricas incluem perda de treinamento (como o modelo se ajusta aos dados de treinamento) e perda de validação (indicador de desempenho de generalização em dados não vistos). As curvas de perda de treinamento e validação demonstram treinamento bem-sucedido: ambas decrescem consistentemente, seguem padrões similares e convergem para valores finais comparáveis.

Implantação com inferência sob demanda

Após concluir com sucesso o trabalho de ajuste fino, você pode implantar seu modelo Nova Micro customizado usando inferência sob demanda. Essa opção de implantação oferece escalabilidade automática e preço por token, tornando-a ideal para cargas de trabalho variáveis sem necessidade de provisionar recursos computacionais dedicados.

Após a implantação, você invoca seu modelo customizado usando o ARN de implantação como ID do modelo na API Converse da Amazon Bedrock:

# Use the deployment ARN as the model ID
deployment_arn = "arn:aws:bedrock:us-east-1::deployment/"

# Prepare the inference request
response = bedrock_runtime.converse(
    modelId=deployment_arn,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "text": """Database schema: CREATE TABLE sales ( id INT, product_name VARCHAR(100), category VARCHAR(50), revenue DECIMAL(10,2), sale_date DATE ); Question: What are the top 5 products by revenue in the Electronics category?"""
                }
            ]
        }
    ],
    inferenceConfig={
        "maxTokens": 512,
        "temperature": 0.1,  # Low temperature for deterministic SQL generation
        "topP": 0.9
    }
)

# Extract the generated SQL query
sql_query = response['output']['message']['content'][0]['text']
print(f"Generated SQL: {sql_query}")

Abordagem 2: Ajuste fino com Amazon SageMaker AI

Enquanto a abordagem Bedrock simplifica a customização de modelo através de uma experiência de treinamento gerenciada, organizações que buscam controle de otimização mais profundo podem se beneficiar da abordagem SageMaker AI. O Amazon SageMaker AI oferece controle extenso sobre parâmetros de treinamento que impactam significativamente a eficiência e desempenho do modelo.

Você pode ajustar o tamanho do lote para otimização de velocidade e memória, ajustar regularização dropout nas camadas para prevenir sobreajuste, e configurar cronogramas de taxa de aprendizado para estabilidade de treinamento. Para ajuste fino LoRA especificamente, você pode customizar fatores de escala e parâmetros de regularização com diferentes configurações otimizadas para datasets multimodais versus apenas texto.

Preparação de dados e carregamento

O processo de preparação e carregamento de dados para a abordagem SageMaker AI é idêntico à implementação Bedrock. Ambas as abordagens convertem o dataset SQL para o formato de schema bedrock-conversation-2024, dividem os dados em conjuntos de treinamento e teste, e carregam os arquivos JSONL diretamente no S3:

# S3 prefix for training data
training_input_path = f's3://{sess.default_bucket()}/datasets/nova-sql-context'

# Upload datasets to S3
train_s3_path = sess.upload_data(
    path='data/train_dataset.jsonl',
    bucket=bucket_name,
    key_prefix=training_input_path
)
test_s3_path = sess.upload_data(
    path='data/test_dataset.jsonl',
    bucket=bucket_name,
    key_prefix=training_input_path
)

print(f'Training data uploaded to: {train_s3_path}')
print(f'Test data uploaded to: {test_s3_path}')

Criando um trabalho de ajuste fino com SageMaker AI

Você seleciona o ID do modelo, a receita de treinamento e a URI de imagem:

# Nova configuration
model_id = "nova-micro/prod"
recipe = "https://raw.githubusercontent.com/aws/sagemaker-hyperpod-recipes/refs/heads/main/recipes_collection/recipes/fine-tuning/nova/nova_1_0/nova_micro/SFT/nova_micro_1_0_g5_g6_48x_gpu_lora_sft.yaml"
instance_type = "ml.g5.48xlarge"
instance_count = 1

# Nova-specific image URI
image_uri = f"708977205387.dkr.ecr.{sess.boto_region_name}.amazonaws.com/nova-fine-tune-repo:SM-TJ-SFT-latest"

print(f'Model ID: {model_id}')
print(f'Recipe: {recipe}')
print(f'Instance type: {instance_type}')
print(f'Instance count: {instance_count}')
print(f'Image URI: {image_uri}')

Receitas customizadas de treinamento

Um diferencial importante ao usar Amazon SageMaker AI para ajuste fino de modelo Nova é a capacidade de customizar uma receita de treinamento. As receitas são pilhas de treinamento pré-configuradas fornecidas pela AWS para ajudá-lo a iniciar rapidamente. Enquanto mantêm compatibilidade com o conjunto padrão de hiperparâmetros da Bedrock (epochs, tamanho do lote, taxa de aprendizado e warmup steps), as receitas estendem as opções de hiperparâmetros através de:

• Parâmetros de regularização: hidden_dropout, attention_dropout, ffn_dropout para prevenir sobreajuste
• Configurações de otimizador: Coeficientes beta customizáveis e configurações de weight decay
• Controles de arquitetura: Rank de adaptador e fatores de escala para treinamento LoRA
• Agendamento avançado: Cronogramas customizados de taxa de aprendizado e estratégias de warmup

Você pode consultar a receita completa que foi utilizada. Para o trabalho de treinamento SageMaker AI neste exemplo, foram usados parâmetros de receita padrão incluindo 2 epochs e tamanho de lote de 64. Com dados contendo 20 mil linhas, o trabalho de treinamento completo durou 4 horas usando a instância ml.g5.48xlarge, com custo total de USD 65 para ajuste fino do modelo Nova Micro.

Testes e avaliação de desempenho

A avaliação do modelo abrangeu testes tanto operacionais quanto de precisão. Para avaliar a precisão, implementou-se uma abordagem “LLM-as-a-Judge” onde coletaram-se perguntas e respostas SQL do modelo ajustado fino, usando um modelo juiz para pontuação comparada às respostas corretas (ground truth).

Para testes operacionais, coletaram-se métricas incluindo TTFT (Tempo para Primeiro Token) e OTPS (Tokens de Saída por Segundo). Comparado ao modelo Nova Micro base, experimentou-se tempo de início frio até primeiro token em média de 639 ms em 5 execuções — um aumento de 34%. Esse aumento de latência provém da aplicação de adaptadores LoRA no tempo de inferência em vez de incorporá-los aos pesos do modelo. Contudo, essa escolha arquitetural entrega benefícios substanciais de custo, já que o modelo Nova Micro ajustado custa o mesmo que o modelo base, permitindo preço sob demanda com flexibilidade de pagamento por uso e sem compromissos mínimos.

Durante operação normal, o tempo até primeiro token em média é de 380 ms em 50 chamadas — um aumento de apenas 7%. A latência end-to-end total é aproximadamente 477 ms para geração completa de resposta. A geração de tokens mantém uma taxa de aproximadamente 183 tokens por segundo, representando apenas 27% de diminuição do modelo base, mantendo-se altamente adequada para aplicações interativas.

Análise de custos

Custos únicos (one-time):

• Treinamento de modelo Amazon Bedrock: USD 0,001 por 1 mil tokens × número de epochs. Para 2 mil exemplos, 5 epochs e aproximadamente 800 tokens cada = USD 8,00
• Treinamento de modelo SageMaker AI: Instância ml.g5.48xlarge custa USD 16,288/hora. Treinamento de 4 horas com dataset de 20 mil linhas = USD 65,15

Custos contínuos (ongoing):

• Armazenamento: USD 1,95 por mês por modelo customizado
• Inferência sob demanda: Mesmo preço por token do Nova Micro base
  • Tokens de entrada: USD 0,000035 por mil tokens
  • Tokens de saída: USD 0,00014 por mil tokens

Exemplo de cálculo para carga de trabalho em produção:

Para 22 mil consultas por mês (100 usuários × 10 consultas/dia × 22 dias úteis), com média de 800 tokens de entrada + 60 tokens de saída por consulta:

• Custo de entrada: (22.000 × 800 / 1.000) × 0,000035 = USD 0,616
• Custo de saída: (22.000 × 60 / 1.000) × 0,00014 = USD 0,184
• Custo mensal total de inferência: USD 0,80

Essa análise valida que, para casos de uso customizados de texto para SQL, ajuste fino de modelo Nova usando PEFT LoRA na Amazon Bedrock é significativamente mais econômico que auto-hospedagem de modelos customizados em infraestrutura persistente. Abordagens auto-hospedadas podem ser adequadas para casos que requerem máximo controle sobre infraestrutura, configurações de segurança ou requisitos de integração. Mas o modelo de custo sob demanda da Amazon Bedrock oferece economias significativas para a maioria das cargas de trabalho de texto para SQL em produção.

Escolhendo a abordagem adequada

Ambas as implementações compartilham o mesmo modelo de implantação serverless e preço sob demanda, permitindo que você escolha baseado na expertise e requisitos da sua equipe, não em restrições de custo.

Escolha customização de modelo Amazon Bedrock quando:

• Você precisa de iteração rápida, possui expertise limitada em infraestrutura ML, ou deseja minimizar complexidade operacional enquanto alcança desempenho de modelo customizado

Escolha treinamento SageMaker AI quando:

• Você requer controle fino sobre parâmetros, possui requisitos específicos de infraestrutura ou conformidade, precisa integrar com pipelines MLOps existentes, ou quer otimizar cada aspecto do processo de treinamento

Começando

Pronto para construir sua própria solução de texto para SQL econômica? Acesse nossas implementações completas:

• Notebook de Ajuste Fino Bedrock: Abordagem gerenciada e simplificada
• Notebook de Ajuste Fino SageMaker AI: Customização avançada e controle

Ambas as abordagens usam o mesmo modelo de implantação econômico, então você pode escolher baseado na expertise da sua equipe e requisitos, em vez de restrições de custo.

Fonte

Cost-efficient custom text-to-SQL using Amazon Nova Micro and Amazon Bedrock on-demand inference (https://aws.amazon.com/blogs/machine-learning/cost-efficient-custom-text-to-sql-using-amazon-nova-micro-and-amazon-bedrock-on-demand-inference/)

O Desafio do Varejo Online e a Solução com IA

O comércio eletrônico enfrenta um obstáculo persistente: quando os clientes compram roupas pela internet, ficam inseguros quanto ao caimento e à aparência das peças, resultando em altas taxas de devolução e redução na confiança de compra. Isso gera perdas de receita, custos operacionais elevados e frustração do cliente. Paralelamente, consumidores esperam cada vez mais por experiências imersivas e interativas que aproximem o shopping online do ambiente físico de uma loja.

A implementação de tecnologia de prova virtual resolve esse problema significativamente. Varejistas que adotam essa abordagem conseguem aumentar a confiança na compra, reduzir devoluções e, consequentemente, melhorar a lucratividade e a satisfação do cliente.

A AWS desenvolveu uma demonstração prática de como construir uma solução integrada de prova virtual e recomendação de produtos usando tecnologias serverless. O artigo técnico documenta a arquitetura, o processo de implementação e as considerações-chave para quem deseja implantar essa solução. O código-fonte está disponível no repositório do GitHub para que parceiros e varejistas possam implementar em suas contas AWS.

Capacidades Principais da Solução

A solução integra quatro funcionalidades de negócio essenciais:

Prova Virtual Realista

A prova virtual gera visualizações fotorrealistas de clientes usando ou portando produtos. Utiliza o Amazon Nova Canvas e o Amazon Rekognition para processar imagens do cliente e da roupa, gerando resultados que mostram como o item ficaria no usuário.

Recomendações Inteligentes Baseadas em Visão

O sistema oferece sugestões de produtos visualmente conscientes usando Amazon Titan Multimodal Embeddings. Essa abordagem compreende relações de estilo e similaridade visual entre peças, permitindo recomendações que vão além de correspondências simples de palavras-chave.

Busca Inteligente com Processamento de Linguagem Natural

A busca permite descoberta de produtos por linguagem natural com inteligência orientada a objetivos. O OpenSearch Serverless realiza correspondência de similaridade vetorial, permitindo consultas conversacionais como “mostre-me vestidos azuis com menos de 100 reais” ou “camisetas casuais femininas”.

Análise e Insights em Tempo Real

O sistema rastreia interações do cliente, preferências e tendências usando Amazon DynamoDB, permitindo que varejistas otimizem decisões de inventário e merchandising em tempo real.

Arquitetura Técnica e Componentes

A solução funciona sobre infraestrutura serverless da AWS, composta por cinco funções AWS Lambda especializadas: interface web (chatbot), processamento de prova virtual, geração de recomendações, ingestão de dados e busca inteligente. A arquitetura usa buckets S3 para armazenamento seguro, Amazon OpenSearch Serverless para busca por similaridade vetorial e DynamoDB para rastreamento de análises em tempo real.

O design modular permite que você implemente capacidades individuais ou a solução completa. A documentação, imagens de teste pré-construídas e scripts utilitários para gerenciamento de dados facilitam a personalização para necessidades específicas de varejo.

Requisitos de Implantação

Pré-requisitos Iniciais

Antes de iniciar o processo de implementação, verifique que você possui:

• Uma conta AWS ativa com privilégios administrativos
• AWS Command Line Interface (CLI) instalada e configurada com credenciais apropriadas
• AWS SAM (Serverless Application Model) CLI versão 1.50.0 ou superior
• Python 3.9 ou superior com pip
• Git para clonar repositórios

Modelos Amazon Bedrock Necessários

A solução requer Amazon Nova Canvas, Amazon Titan Multimodal Embeddings, Amazon Rekognition e Amazon OpenSearch Serverless na mesma região. A implementação é recomendada em US East (N. Virginia) — us-east-1.

A AWS anunciou que os modelos de fundação do Amazon Bedrock agora são automaticamente habilitados quando invocados pela primeira vez em sua conta, em todas as regiões comerciais AWS. Os modelos necessários para essa solução serão ativados automaticamente quando a aplicação os chamar pela primeira vez — não é necessária habilitação manual.

Se você estiver implantando em uma região diferente de us-east-1, confirme que todos os modelos necessários são suportados consultando a página de suporte de modelos Amazon Bedrock por região e a lista de serviços regionais da AWS.

Permissões e Configuração de Identidade

A função IAM (Identity and Access Management) usada para implantar o template SAM deve ter permissões para criar e gerenciar funções Lambda, criar buckets S3, gerenciar coleções Amazon OpenSearch Serverless, criar tabelas DynamoDB, invocar modelos Amazon Bedrock, acessar serviços Amazon Rekognition, e gerenciar stacks CloudFormation.

Processo de Implantação Passo a Passo

Etapa 1: Configuração do Repositório

Comece clonando o repositório e navegando até o diretório do projeto:

git clone https://github.com/aws-samples/sample-genai-virtual-tryon.git
cd VirtualTryOne-GenAI

Examine a estrutura do projeto para compreender a organização da base de código: o arquivo template.yaml define todos os recursos AWS, requirements.txt lista as dependências Python, os arquivos de função Lambda (*.py), o conjunto de dados de moda e imagens de exemplo.

Etapa 2: Instalação de Dependências

pip install -r requirements.txt

Esse comando instala pacotes necessários para processamento de imagens, interações com AWS SDK, conectividade com OpenSearch e outras funcionalidades essenciais.

Etapa 3: Construção com SAM

sam build

O processo de construção cria pacotes de implantação para cada função Lambda, resolve dependências, valida a sintaxe do template SAM e prepara os templates CloudFormation para implantação.

Etapa 4: Implantação Orientada

sam deploy --guided

Para a primeira implantação, use a opção de implantação orientada. O processo solicitará um nome de stack único, a região AWS para implantação, valores de parâmetros para personalização e confirmação da criação de recursos. Isso cria um arquivo samconfig.toml que armazena suas preferências de implantação para futuras implementações.

Etapa 5: Implantações Posteriores

sam deploy

Após a configuração inicial, use o comando simplificado de implantação, que utiliza a configuração salva no samconfig.toml para implantações consistentes.

Considerações de Segurança Críticas

A implantação base não possui autenticação nos endpoints da API Gateway. A AWS recomenda não implantar em produção sem implementar autenticação (por exemplo, usando Amazon Cognito ou autorizadores de API Gateway).

Além disso, implemente validação de imagem e moderação de conteúdo para todas as imagens enviadas por usuários antes do processamento. Use Amazon Rekognition Content Moderation para detectar conteúdo inadequado ou inseguro, e valide tipo de arquivo, tamanho e dimensões no nível da API Gateway ou camada Lambda. Rejeite imagens que falhem nas verificações de moderação antes de chegar ao armazenamento S3 ou ao pipeline do Nova Canvas. Isso previne que arquivos maliciosos e conteúdo inadequado sejam processados, armazenados ou retornados a outros usuários.

Etapa 6: Identificação de Stack e ID de Função

Após executar sam deploy, você precisa encontrar os valores corretos de YourStackName e ID para invocar funções Lambda. A forma mais rápida é verificar a saída do comando sam deploy. A saída DataIngestionFunctionName mostra o nome completo da função. Você também pode recuperar essas informações do CloudFormation, consultar o arquivo samconfig.toml ou acessar o AWS Management Console através do CloudFormation.

Etapa 7: Configuração do Conjunto de Dados de Moda

python mini_dataset_uploader.py

Esse script carrega mais de 60 itens de moda com metadados no bucket S3 designado, habilitando funcionalidades de busca e recomendação.

Etapa 8: Criação de Índice Vetorial

aws lambda invoke \
  --function-name <YourStackName>-DataIngestionFunction-<ID> \
  --payload '{}' \
  response.json

Substitua <YourStackName> e <ID> pelos valores da saída da implantação SAM. Esse processo processa as imagens de moda usando embeddings Titan, cria representações vetoriais para busca por similaridade e indexa dados no Amazon OpenSearch Serverless.

Funcionalidades da Aplicação para Usuários Finais

Processo de Prova Virtual

A prova virtual representa a funcionalidade central, usando Amazon Nova Canvas para criar imagens fotorrealistas de usuários usando peças de roupa selecionadas. O processo começa quando usuários fazem upload de sua foto através de uma interface drag-and-drop que suporta formatos JPEG, PNG e JPG com tamanho máximo de 6 MB.

O sistema valida e pré-processa imagens automaticamente. Resultados ótimos são alcançados com fotos bem iluminadas, de frente e que mostram claramente o corpo do usuário. Após processar a foto, a seleção de roupa ocorre de duas formas: envio de imagens pessoais de roupas para experiências customizadas, ou navegação e busca no conjunto de dados de moda com mais de 60 itens profissionalmente fotografados.

A fase de processamento de IA envolve tecnologias de visão computacional e IA generativa. O Amazon Rekognition analisa tanto a foto do usuário quanto o item de roupa para detectar tipos de peça, regiões do corpo e gênero do usuário para pareamento personalizado. O Nova Canvas então gera imagens de prova fotorrealistas que aplicam a roupa selecionada à foto do usuário, com processamento concluído tipicamente em 15 segundos. Os usuários podem interagir com seus resultados de prova virtual através de várias opções: download de imagens em alta qualidade, solicitação de recomendações de itens similares, ou salvamento de favoritos para referência futura.

Sistema de Recomendações Personalizado

O motor de recomendação representa um dos aspectos mais avançados da aplicação, usando embeddings multimídia de IA para compreender tanto preferências de moda visual quanto textual. O sistema analisa comportamento do usuário, características das fotos e padrões de interação para gerar sugestões de roupa personalizadas que se alinham com preferências de estilo individual e necessidades práticas.

Fatores-chave que influenciam recomendações incluem: análise de similaridade visual usando Amazon Titan Multimodal Embeddings para encontrar itens com cores, padrões e estilos similares; gênero detectado e preferências de estilo inferidas; correspondência de categoria que garante recomendações alinhadas com tipos de roupa preferidos (topo, fundo, corpo inteiro, calçados).

Busca Inteligente de Moda

O sistema de busca vai além de correspondência de palavras-chave tradicionais, compreendendo consultas em linguagem natural e intenção do usuário. O agente de busca de moda categoriza automaticamente buscas de usuário em três intenções primárias: planejamento de looks (encontrando peças que combinam), caça por preço (compras conscientes de orçamento), e descoberta de estilo (explorando tendências de moda).

Usuários podem buscar usando frases conversacionais como “mostre-me vestidos azuis com menos de 100 reais”, “camiseta casual”, ou “jeans acessíveis para mulheres”. O motor de busca incorpora características avançadas: correção automática de digitação para erros comuns, classificação de resultado orientada a objetivo que prioriza itens baseado na intenção detectada, filtragem multi-critério suportando cor, faixa de preço, categoria e preferências de gênero, e correspondência difusa que lida com variações de tipo de roupa e sinônimos.

Análise de Custos e Considerações Financeiras

Os custos variam significativamente baseado no uso real e região. As estimativas apresentadas a seguir baseiam-se em um cenário típico de workshop com 60 itens de moda indexados, 50 provas virtuais diárias, 100 buscas e 75 recomendações, funcionando por um mês.

Serviços de IA e Aprendizado de Máquina

Amazon Bedrock – Nova Canvas: Aproximadamente R$ 60,00/mês para 1.500 imagens de prova virtual a R$ 0,04 por imagem. Este é o maior componente de custo.

Amazon Bedrock – Titan Embeddings: Aproximadamente R$ 0,50 a R$ 1,00/mês para 60 itens indexados mais cerca de 100 consultas de busca diárias.

Serviços de Infraestrutura

OpenSearch Serverless: Aproximadamente R$ 7,00 a R$ 12,00/mês com mínimo de 2 Unidades de Computação OpenSearch (OCUs) para indexação e operações de busca.

NAT Gateway: Aproximadamente R$ 3,50 a R$ 5,00/mês para cerca de 5GB de dados processados para acesso à internet de Lambda.

AWS Key Management Service (KMS) com encriptação: Aproximadamente R$ 3,00/mês para 3 chaves com rotação automática.

Lambda, S3 e DynamoDB: Geralmente cobertos pelo nível gratuito ou custos negligenciáveis para esse volume de uso (~50.000 invocações, ~600MB de armazenamento).

API Gateway, CloudWatch e SQS: Aproximadamente R$ 1,00 a R$ 1,50/mês cobrindo requisições de API, logs e filas de letra morta.

Para estimativas mais precisas baseadas em seu caso de uso específico, consulte a página de preços da AWS e use a calculadora de preços da AWS.

Monitoramento, Solução de Problemas e Limpeza

Monitoramento via CloudWatch

Monitore o desempenho da aplicação através de grupos de logs CloudWatch para cada função Lambda. Problemas comuns incluem erros de acesso a modelos Amazon Bedrock (verificar habilitação no console e permissões IAM), problemas de conexão OpenSearch (verificar coleta ativa e políticas de rede), e falhas de processamento de imagem (validar formato e tamanho).

Otimização de Desempenho

Monitore duração e uso de memória das funções Lambda, implemente caching para dados acessados frequentemente, e considere concorrência provisionada para cenários de alto tráfego.

Limpeza de Recursos

Para evitar cobranças contínuas da AWS quando a aplicação não for mais necessária, limpe adequadamente todos os recursos implantados:

sam delete --stack-name <seu-nome-de-stack>

Esse comando deleta funções Lambda e recursos associados, remove endpoints de API Gateway, deleta tabelas DynamoDB (os dados serão perdidos), e remove funções e políticas IAM criadas pelo template.

Alguns recursos podem necessitar deleção manual: buckets S3 precisam ser esvaziados antes da exclusão, e coleções Amazon OpenSearch Serverless podem necessitar remoção através de comando específico.

Otimização de Custos

Para minimizar custos enquanto executa a aplicação, use configurações adequadas de memória Lambda baseadas em padrões de uso reais, implemente cache de requisição para reduzir invocações redundantes de modelos de IA, configure alarmes CloudWatch para monitoramento de custos, use políticas de ciclo de vida S3 para arquivamento automático de imagens antigas, e considere capacidade reservada para cenários previsíveis de alto tráfego.

Conclusão

A solução demonstra uma abordagem prática para transformação digital de varejistas usando tecnologias serverless. A arquitetura modular permite implementação de capacidades individuais ou da solução completa, adaptando-se a diferentes necessidades de negócio. Os conceitos apresentados — arquitetura de microsserviços serverless, integração de IA e aprendizado de máquina, busca por similaridade vetorial, processamento de linguagem natural e análise em tempo real — representam um modelo replicável para outras aplicações e setores.

Para implantações em produção, considere implementar funcionalidades adicionais como autenticação de usuário, estratégias avançadas de cache, implantação multi-região e dashboards de monitoramento customizados. A base fornecida oferece um ponto de partida sólido para transformação digital no varejo com IA generativa.

Recursos Adicionais

• Documentação do AWS SAM
• Guia do Usuário do Amazon Bedrock
• Documentação do Amazon OpenSearch Serverless
• Melhores Práticas do AWS Lambda
• Guia do Desenvolvedor do Amazon Rekognition

Fonte

Transform retail with AWS generative AI services (https://aws.amazon.com/blogs/machine-learning/transform-retail-with-aws-generative-ai-services/)

Entendendo o desafio da decodificação em modelos de linguagem

Aplicações de inteligência artificial generativa como assistentes de escrita, agentes de código e sistemas de completamento de texto enfrentam um desafio fundamental: elas geram muito mais conteúdo do que consomem. Durante a fase de decodificação, tokens são produzidos sequencialmente, um de cada vez. Esse processo sequencial deixa os aceleradores de hardware limitados pela largura de banda de memória, com processadores significativamente subutilizados.

Essa subutilização eleva substancialmente o custo por token gerado. Cada etapa de decodificação ativa kernels caros de multiplicação de matrizes apenas para produzir um único token, mantendo os recursos de processamento praticamente ociosos. É nesse contexto que a decodificação especulativa surge como uma solução promissora.

Como funciona a decodificação especulativa

A decodificação especulativa acelera a geração autorregressiva utilizando uma abordagem de dois modelos:

• Um modelo auxiliar (draft model) propõe rapidamente n tokens candidatos
• O modelo principal (target model) verifica-os em uma única passagem direta

Quando o modelo principal aceita os tokens propostos pelo modelo auxiliar, eles são confirmados sem custo computacional adicional. Ao reduzir o número de etapas sequenciais de decodificação, a técnica diminui significativamente a latência entre tokens e melhora a utilização do hardware.

Componentes-chave da configuração

A implementação da decodificação especulativa envolve duas decisões críticas:

Seleção dos modelos: O modelo auxiliar e o modelo principal devem compartilhar o mesmo tokenizador e vocabulário. A AWS recomenda escolher modelos da mesma família arquitetural porque suas predições de próximo token concordam com maior frequência. Embora seja tecnicamente possível parear modelos com arquiteturas diferentes, acordos menos frequentes reduzem as taxas de aceitação, eliminando a maior parte do ganho de desempenho.

Janela de tokens especulativos (num_speculative_tokens): Este parâmetro controla quantos tokens o modelo auxiliar propõe simultaneamente. Aumentar esse valor permite pular mais etapas sequenciais de decodificação por passagem de verificação, reduzindo diretamente a latência entre tokens quando as taxas de aceitação são altas.

Compensações de desempenho

Configurar esse parâmetro envolve equilibrar cuidadosamente custo computacional versus qualidade de verificação. Valores muito baixos limitam os ganhos de velocidade. Valores excessivamente altos aumentam a probabilidade de rejeições antecipadas, desperdiçando computação do modelo auxiliar e elevando o custo de verificação do modelo principal.

Os ganhos de desempenho derivam de dois efeitos principais. Primeiro, a decodificação especulativa reduz o número de etapas de decodificação do modelo principal, diminuindo o número de acessos à memória do cache KV. O cache KV armazena tensores de chaves e valores computados anteriormente para evitar recálculo de atenção. Cada etapa de decodificação lê o cache completo da memória, tornando essa fase limitada pela largura de banda. Segundo, a técnica melhora a utilização de hardware durante a decodificação: em vez de processar um único token por vez, o modelo principal processa n tokens simultaneamente, convertendo uma sequência de pequenos cálculos ineficientes em uma carga de trabalho computacionalmente mais densa.

Modos de suporte no AWS Neuron

O AWS Neuron é o kit de desenvolvimento para chips de IA da AWS. O NeuronX Distributed Inference (NxDI) é sua biblioteca para inferência escalável e de alto desempenho de modelos de linguagem no Trainium e Inferentia.

O NxDI oferece suporte nativo à decodificação especulativa no Trainium em quatro modos:

• Decodificação especulativa vanilla: modelos auxiliar e principal compilados independentemente. É o modo mais simples para começar.
• Especulação fundida (Fused speculation): modelos compilados conjuntamente para desempenho otimizado. Este é o modo utilizado nos testes descritos neste artigo.
• Especulação EAGLE: o modelo auxiliar aproveita contexto de estados ocultos do modelo principal para melhorar as taxas de aceitação.
• Especulação Medusa: múltiplas cabeças de previsão pequenas executam em paralelo, reduzindo sobrecarga do modelo auxiliar.

Implementação prática com vLLM e Kubernetes

A AWS implantou dois serviços de inferência vLLM em instâncias Trainium dentro de um cluster Amazon Elastic Kubernetes Service (Amazon EKS), mantendo tudo idêntico exceto o método de decodificação para isolar o impacto de desempenho.

O serviço baseline (qwen-vllm) executa Qwen3-32B com decodificação padrão. O serviço com especulação (qwen-sd-vllm) executa o mesmo modelo Qwen3-32B principal, adicionando um modelo auxiliar Qwen3-1.7B com num_speculative_tokens=7.

Ambos os serviços rodavam em configurações idênticas em Trn2 (trn2.48xlarge), com a mesma alocação de acelerador, paralelismo de tensor (que distribui pesos de modelo entre múltiplos NeuronCores), comprimento de sequência, limites de batch e imagem DLC do Neuron. A única diferença era a adição do modelo auxiliar Qwen3-1.7B e o parâmetro num_speculative_tokens=7 para o serviço com especulação.

Para comparar as duas configurações sob carga idêntica, foi utilizado llmperf para gerar os mesmos padrões de tráfego contra ambos os endpoints. A telemetria de infraestrutura foi capturada com CloudWatch Container Insights e métricas personalizadas de nível de requisição (TTFT, latência entre tokens e latência end-to-end) foram publicadas em painéis do CloudWatch para análise lado a lado.

Metodologia e resultados de benchmarking

A AWS utilizou LLMPerf para executar casos de teste estruturados e intensivos em decodificação contra os deployments baseline e com especulação. Os benchmarks rodaram dentro de um pod Kubernetes, qwen-llmperf-pod.yaml, emitindo requisições concorrentes para ambos os endpoints e registrando métricas de latência em nível de token.

Os casos de teste variaram de prompts altamente estruturados (sequências repetitivas, continuações numéricas, padrões de código simples) até completamentos de linguagem natural em aberto, cobrindo comportamentos tanto de melhor como de pior caso para decodificação especulativa. O conjunto completo de prompts está disponível no repositório de amostras.

Impacto da decodificação especulativa por tipo de prompt

Os resultados demonstraram que a decodificação especulativa reduz latência seletivamente, com efetividade fortemente dependente da estrutura do prompt:

Prompts estruturados: Para prompts como “Repita exatamente a seguinte linha 50 vezes”, a decodificação especulativa entrega redução mensurável de latência end-to-end. Quando o modelo auxiliar prevê com confiabilidade o que o modelo principal geraria, o sistema pula uma fração substancial de etapas de decodificação do modelo principal. Nos testes, a latência entre tokens caiu para aproximadamente 15 ms por token (comparado aos aproximadamente 45 ms de prompts abertos), e a curva da especulação manteve-se consistentemente abaixo da baseline durante toda a execução.

Prompts abertos: Para prompts como “Acredito que o significado da vida é”, a decodificação especulativa não oferece benefício consistente. O modelo auxiliar frequentemente diverge do modelo principal, causando rejeições de tokens que negam os ganhos potenciais. As curvas de latência end-to-end da especulação e da baseline se sobrepõem significativamente, com latência entre tokens permanecendo próxima aos 45 ms por token para ambas as configurações.

Latência do primeiro token (TTFT): O TTFT permaneceu efetivamente inalterado entre as configurações, dominado pela fase de preenchimento (prefill) em que o modelo codifica o contexto de entrada. Como a decodificação especulativa não altera esse estágio, a latência de preenchimento não é nem melhorada nem degradada.

Esses resultados indicam que a decodificação especulativa melhora a latência total reduzindo o número de etapas de decodificação do modelo principal executadas, não acelerando a etapa de decodificação em si ou a fase de preenchimento. Isso explica por que ganhos aparecem em latência end-to-end para prompts estruturados, mas estão ausentes em latência entre tokens e TTFT, e por que a decodificação especulativa retorna ao comportamento baseline para geração aberta.

Sintonia de parâmetros na prática

Os testes compararam modelos auxiliares Qwen3-0.6B e Qwen3-1.7B. O modelo menor (0.6B) era mais rápido para executar, mas sua taxa de aceitação era aproximadamente 60% menor, suficiente para cancelar a economia computacional. O Qwen3-1.7B atingiu um melhor equilíbrio entre velocidade e aceitação.

Para num_speculative_tokens, foram avaliados valores entre 5 e 15. Configurações menores (por exemplo, 5) ofereciam aceleração limitada. Janelas maiores (por exemplo, 15) aumentavam rejeições e degradavam desempenho. A melhor configuração dependia fortemente da estrutura do prompt, testando tanto prompts estruturados (repetição, sequências numéricas, código simples) quanto linguagem natural aberta. O melhor equilíbrio resultou do Qwen3-1.7B com 7 tokens especulativos.

Recursos e próximos passos

Para começar com decodificação especulativa no AWS Trainium, a documentação oferece vários pontos de partida:

• Página de produto AWS Trainium — informações sobre tipos de instância, capacidades e preços.
• Guia de desenvolvedor NeuronX Distributed Inference — documentação completa do NxDI, incluindo opções de configuração de decodificação especulativa.
• Guia de recursos de decodificação especulativa do NxDI — referência para ativar modos vanilla, fundido, EAGLE e Medusa de especulação.
• Documentação do vLLM — como configurar vLLM para servir modelos de linguagem em produção.
• Documentação do Amazon EKS — primeiros passos com Kubernetes na AWS para deploy e escala de serviços de inferência.
• Repositório de amostras AWS Neuron EKS — exemplos de código end-to-end para reproduzir os benchmarks.
• Documentação do Amazon CloudWatch — configuração de painéis e métricas personalizadas para monitorar endpoints de inferência.

Considerações finais

As cargas de trabalho de modelos de linguagem intensivas em decodificação estão restritas pela natureza sequencial da geração autorregressiva. A decodificação especulativa no AWS Trainium2 rompe esse gargalo reduzindo o número de etapas de decodificação do modelo principal necessárias para produzir a saída completa, aumentando efetivamente os tokens gerados por passagem direta.

Para cargas de trabalho onde o espaço de saída é previsível — como geração de código, extração de dados estruturados, geração de relatórios em template ou síntese de arquivos de configuração — isso pode se traduzir diretamente em custo menor por token de saída e maior throughput, sem sacrificar qualidade.

A decodificação especulativa não é uma otimização universal. Sua efetividade depende da estrutura do prompt, qualidade do modelo auxiliar e sintonia de parâmetros especulativos. Quando aplicada às cargas de trabalho corretas, entrega melhorias significativas de latência e custo em sistemas de inferência baseados em Trainium.

Fonte

Accelerating decode-heavy LLM inference with speculative decoding on AWS Trainium and vLLM (https://aws.amazon.com/blogs/machine-learning/accelerating-decode-heavy-llm-inference-with-speculative-decoding-on-aws-trainium-and-vllm/)

Agentes de IA em Produção: Simplificando a Complexidade

A inteligência artificial agêntica está transformando a forma como as organizações utilizam modelos generativos. Em vez de simples interações de pergunta-resposta, os agentes agênticos conseguem planejar, executar e completar tarefas complexas em múltiplas etapas de forma autônoma. Embora as primeiras implementações desse tipo despertem entusiasmo nos stakeholders de negócio, escalar essas soluções para produção apresenta desafios significativos: escalabilidade, governança e segurança.

A Amazon Bedrock AgentCore foi desenvolvida como uma plataforma de IA agêntica para construir, implantar e operar agentes em escala, utilizando qualquer framework e modelo. Mas havia um problema: desenvolvedores Java queriam construir esses agentes usando os padrões familiares do Spring, porém a implantação em produção exigia uma infraestrutura complexa de ser implementada do início.

O Novo SDK Spring AI AgentCore

Com o lançamento do SDK Spring AI AgentCore em disponibilidade geral, essa barreira foi removida. O SDK é uma biblioteca de código aberto que integra as capacidades do Amazon Bedrock AgentCore diretamente em aplicações Spring AI, usando padrões já conhecidos pelos desenvolvedores: anotações, auto-configuração e advisors compostos.

Anteriormente, integrar essas capacidades em uma aplicação Spring exigia semanas de trabalho em infraestrutura: escrever controladores customizados, gerenciar streaming de Server-Sent Events (SSE), implementar verificações de saúde, controlar limitação de taxa (rate limiting) e conectar advisors do Spring, repositórios de memória e definições de ferramentas. Agora, basta adicionar uma dependência, anotar um método, e o SDK cuida do resto.

Capacidades Fundamentais do SDK

Entendendo o Contrato do AgentCore Runtime

O AgentCore Runtime gerencia o ciclo de vida e a escalabilidade dos agentes com modelo de preço por uso — você não paga por computação ociosa. O runtime roteia requisições de entrada para seu agente e monitora sua saúde, mas para isso exige que o agente siga um contrato específico.

Esse contrato demanda dois endpoints principais: o endpoint /invocations recebe requisições e retorna respostas em formato JSON ou como streaming SSE, enquanto o endpoint de saúde /ping relata status Healthy (saudável) ou HealthyBusy (saudável mas ocupado). Tarefas de longa duração precisam sinalizar o status ocupado, caso contrário o runtime pode reduzi-las para economizar custos.

O SDK implementa esse contrato automaticamente, incluindo detecção assíncrona de tarefas que reporta o status ocupado quando seu agente está processando. Além disso, oferece recursos adicionais para cargas de trabalho em produção, como tratamento apropriado de respostas SSE com framing correto, gerenciamento de backpressure e ciclo de vida de conexão para respostas grandes. Também fornece rate limiting para proteger o agente contra picos de tráfego e limitar o consumo por usuário.

Design Principles do SDK

O SDK foi construído sobre três princípios de design:

Convenção em vez de configuração: Padrões sensatos se alinham com as expectativas do AgentCore (porta 8080, caminhos de endpoints, tratamento de content-type) sem necessidade de configuração explícita.

Desenvolvimento orientado por anotações: Uma simples anotação @AgentCoreInvocation transforma qualquer método de um bean Spring em um endpoint compatível com AgentCore, com serialização automática, detecção de streaming e formatação de resposta.

Flexibilidade de implantação: O SDK funciona tanto com o AgentCore Runtime para implantação totalmente gerenciada quanto com módulos individuais (Memória, Navegador, Interpretador de Código) em aplicações rodando em Amazon EKS, Amazon ECS ou qualquer outra infraestrutura.

Construindo Seu Primeiro Agente

Passo 1: Adicionar a Dependência

Comece adicionando o BOM (Bill of Materials) Spring AI AgentCore ao seu projeto Maven, junto com o starter de runtime:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springaicommunity</groupId>
      <artifactId>spring-ai-agentcore-bom</artifactId>
      <version>1.0.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>
<dependencies>
  <dependency>
    <groupId>org.springaicommunity</groupId>
    <artifactId>spring-ai-agentcore-runtime-starter</artifactId>
  </dependency>
</dependencies>

Passo 2: Criar o Agente

A anotação @AgentCoreInvocation informa ao SDK que o método manipula requisições de agentes. O SDK auto-configura os endpoints POST /invocations e GET /ping, gerencia a serialização JSON e relata o status de saúde automaticamente:

@Service
public class MyAgent {
  private final ChatClient chatClient;

  public MyAgent(ChatClient.Builder builder) {
    this.chatClient = builder.build();
  }

  @AgentCoreInvocation
  public String chat(PromptRequest request) {
    return chatClient.prompt()
      .user(request.prompt())
      .call()
      .content();
  }
}

record PromptRequest(String prompt) {}

Passo 3: Configurar Amazon Bedrock

Defina o modelo e a região AWS no arquivo application.properties:

spring.ai.bedrock.aws.region=us-east-1
spring.ai.bedrock.converse.chat.options.model=global.anthropic.claude-sonnet-4-5-20250929-v1:0

Passo 4: Testar Localmente

Inicie a aplicação e envie uma requisição:

mvn spring-boot:run
curl -X POST http://localhost:8080/invocations \
  -H "Content-Type: application/json" \
  -d '{"prompt": "What is Spring AI?"}'

Pronto: um agente compatível com AgentCore completo, sem controladores customizados, sem manipulação de protocolo, sem implementação manual de verificação de saúde.

Passo 5: Adicionar Streaming de Respostas

Para fazer o agente transmitir respostas conforme são geradas, altere o tipo de retorno para Flux<String>. O SDK muda automaticamente para saída SSE:

@AgentCoreInvocation
public Flux<String> streamingChat(PromptRequest request) {
  return chatClient.prompt()
    .user(request.prompt())
    .stream()
    .content();
}

O SDK gerencia framing SSE, headers Content-Type, preservação de quebras de linha e ciclo de vida de conexão. Seu código permanece focado apenas na lógica de IA.

Passo 6: Adicionar Memória ao Agente

Agentes reais precisam lembrar o que usuários disseram anteriormente em uma conversa (memória de curto prazo) e o que aprenderam ao longo do tempo (memória de longo prazo). O SDK integra a AgentCore Memory através do padrão de advisors do Spring AI — interceptadores que enriquecem prompts com contexto antes de alcançarem o modelo.

A memória de curto prazo mantém mensagens recentes em uma janela deslizante, enquanto a memória de longo prazo persiste conhecimento entre sessões usando quatro estratégias: Semântica (informações factuais sobre usuários), Preferência do Usuário (configurações e escolhas explícitas), Resumo (histórico de conversa condensado) e Episódica (interações passadas e lições aprendidas). O AgentCore consolida essas estratégias de forma assíncrona, extraindo informações relevantes sem intervenção manual do desenvolvedor.

Adicione a dependência de memória e ative a auto-descoberta. No modo auto-descoberta, o SDK detecta automaticamente estratégias de memória de longo prazo disponíveis e namespaces sem configuração manual:

agentcore.memory.memory-id=${AGENTCORE_MEMORY_ID}
agentcore.memory.long-term.auto-discovery=true

Depois, injete AgentCoreMemory e componha-o no cliente de chat:

private final AgentCoreMemory agentCoreMemory;

public MyAgent(ChatClient.Builder builder, AgentCoreMemory agentCoreMemory) {
  this.agentCoreMemory = agentCoreMemory;
  this.chatClient = builder.build();
}

@AgentCoreInvocation
public String chat(PromptRequest request, AgentCoreContext context) {
  String sessionId = context.getHeader(AgentCoreHeaders.SESSION_ID);
  return chatClient.prompt()
    .user(request.prompt())
    .advisors(agentCoreMemory.advisors)
    .advisors(a -> a.param(ChatMemory.CONVERSATION_ID, "user:" + sessionId))
    .call()
    .content();
}

Passo 7: Estender Agentes com Ferramentas

O AgentCore oferece ferramentas especializadas que o SDK expõe como callbacks de ferramenta do Spring AI através da interface ToolCallbackProvider.

Automação de navegador: Agentes conseguem navegar em websites, extrair conteúdo, capturar telas e interagir com elementos da página usando o AgentCore Browser:

<dependency>
  <groupId>org.springaicommunity</groupId>
  <artifactId>spring-ai-agentcore-browser</artifactId>
</dependency>

Interpretador de código: Agentes conseguem escrever e executar Python, JavaScript ou TypeScript em um sandbox seguro usando o AgentCore Code Interpreter. O sandbox inclui numpy, pandas e matplotlib. Arquivos gerados são capturados através do artifact store:

<dependency>
  <groupId>org.springaicommunity</groupId>
  <artifactId>spring-ai-agentcore-code-interpreter</artifactId>
</dependency>

Ambas as ferramentas se integram através da interface ToolCallbackProvider do Spring AI. Aqui está o MyAgent final com memória, navegador e interpretador de código compostos em conjunto:

@Service
public class MyAgent {
  private final ChatClient chatClient;
  private final AgentCoreMemory agentCoreMemory;

  public MyAgent(
      ChatClient.Builder builder,
      AgentCoreMemory agentCoreMemory,
      @Qualifier("browserToolCallbackProvider") ToolCallbackProvider browserTools,
      @Qualifier("codeInterpreterToolCallbackProvider") ToolCallbackProvider codeInterpreterTools) {
    this.agentCoreMemory = agentCoreMemory;
    this.chatClient = builder
      .defaultToolCallbacks(browserTools, codeInterpreterTools)
      .build();
  }

  @AgentCoreInvocation
  public Flux<String> chat(PromptRequest request, AgentCoreContext context) {
    String sessionId = context.getHeader(AgentCoreHeaders.SESSION_ID);
    return chatClient.prompt()
      .user(request.prompt())
      .advisors(agentCoreMemory.advisors)
      .advisors(a -> a.param(ChatMemory.CONVERSATION_ID, "user:" + sessionId))
      .stream()
      .content();
  }
}

O modelo vê todas as ferramentas igualmente e decide qual usar baseado na requisição do usuário. Embora este artigo focalize Amazon Bedrock para acessar modelos de fundação, o Spring AI suporta múltiplos provedores LLM (Large Language Model), incluindo OpenAI e Anthropic, permitindo que você escolha os modelos que melhor se adequam às suas necessidades.

Implantação do Agente

O SDK suporta dois modelos de implantação:

AgentCore Runtime: Para infraestrutura totalmente gerenciada, empacote sua aplicação como container ARM64, envie-a para o Amazon Elastic Container Registry (Amazon ECR), e crie um AgentCore Runtime que referencie a imagem. O runtime gerencia escalabilidade e monitoramento de saúde. O diretório examples/terraform fornece infraestrutura como código com opções de autenticação IAM e OAuth2.

Implantação autônoma: Use módulos AgentCore de Memory, Browser ou Code Interpreter em aplicações rodando em Amazon EKS, Amazon ECS, Amazon EC2 ou on-premises. Com essa abordagem, equipes conseguem adotar capacidades AgentCore incrementalmente — por exemplo, adicionando memória a um serviço Spring Boot existente antes de migrar para o AgentCore Runtime posteriormente.

Autenticação, Autorização e Ferramentas Corporativas

O AgentCore Runtime suporta dois métodos de autenticação: SigV4 baseado em IAM para chamadas serviço-a-serviço AWS e OAuth2 para aplicações voltadas para usuários. Quando seu agente Spring AI é implantado no AgentCore Runtime, autenticação é gerenciada na camada de infraestrutura. Sua aplicação recebe a identidade do usuário autenticado através do AgentCoreContext, permitindo que autorização de granularidade fina seja implementada usando padrões Spring Security convencionais.

Para implantações autônomas, sua aplicação Spring é responsável por fornecer autenticação e autorização usando Spring Security. Nesse caso, chamadas para serviços AgentCore são protegidas usando mecanismos padrão de credencial do AWS SDK.

Agentes Spring AI conseguem acessar ferramentas corporativas através do AgentCore Gateway, que fornece suporte para Model Context Protocol (MCP) com autenticação de saída e registro semântico de ferramentas. Para usar o Gateway, configure seu endpoint MCP client para apontar ao AgentCore Gateway e autentique usando SigV4 IAM ou OAuth2, permitindo que agentes descubram e invoquem ferramentas corporativas enquanto o Gateway gerencia credenciais para serviços downstream.

Próximos Passos e Recursos

O SDK continua evoluindo. Integrações futuras incluem suporte a observabilidade com integração de tracing, métricas e logging do Spring AI, além de suporte a ferramentas externas como LangFuse, Datadog e Dynatrace usando OpenTelemetry. Também estão planejados frameworks de testes e avaliação de qualidade para respostas de agentes, e gerenciamento de identidade avançado.

Para começar:

• Explore o SDK Spring AI AgentCore SDK on GitHub. O repositório inclui aplicações de exemplo que você pode usar como ponto de partida.
• Leia a documentação Amazon AgentCore para detalhes sobre Runtime, Memory, Browser e serviços Code Interpreter.
• Experimente o console Amazon Bedrock para habilitar acesso a modelos e explorar modelos de fundação disponíveis.
• Para um aprofundamento prático, tente o workshop Building Java AI agents with Spring AI and Amazon AgentCore. Em cerca de quatro horas, você constrói um assistente completo de gerenciamento de viagens e despesas, adicionando progressivamente persona, memória, recuperação de conhecimento, navegação web, execução de código, integração de ferramentas MCP e implanta sem servidor no AgentCore Runtime com autenticação e observabilidade. Nenhuma experiência prévia em IA/ML é necessária.

A comunidade é bem-vinda para contribuir. Deixe um comentário para compartilhar sua experiência ou abra uma issue no GitHub repository.

Fonte

Spring AI SDK for Amazon Bedrock AgentCore is now Generally Available (https://aws.amazon.com/blogs/machine-learning/spring-ai-sdk-for-amazon-bedrock-agentcore-is-now-generally-available/)