O desafio de colocar modelos generativos em produção

Quem já tentou colocar um modelo de IA generativa em produção sabe bem o problema: encontrar a combinação certa de tipo de instância, contêiner de serviço e estratégia de otimização é um processo que pode consumir dias ou semanas de iteração manual. Benchmarks, ajustes, mais benchmarks — o ciclo é longo e exige conhecimento técnico especializado.

Para resolver isso, a Amazon SageMaker AI lançou em abril de 2026 o recurso de recomendações de inferência, que permite obter configurações prontas para produção de forma programática via APIs. O recurso comprime esse ciclo para minutos em cargas de trabalho comuns, e algumas horas para cargas personalizadas.

Agora, a AWS dá um passo além: a mesma funcionalidade ganhou uma interface visual completa dentro do Amazon SageMaker AI Studio, com uma experiência de baixo código/sem código (LCNC — Low-Code No-Code). O objetivo é claro — democratizar o acesso a configurações validadas de inferência para equipes que não têm expertise profunda em infraestrutura de ML.

O que muda com a nova interface

A API de recomendações já existia e funcionava bem para quem sabia quais parâmetros configurar e como interpretar os resultados brutos de benchmark. A interface visual remove essa barreira. Ela guia o usuário por perfis de uso predefinidos, comparações visuais dos resultados e implantação com um clique — sem escrever uma linha de código.

Isso significa que engenheiros de Machine Learning (ML) podem validar o próximo deployment enquanto líderes técnicos avaliam os trade-offs entre custo e desempenho, tudo dentro da mesma experiência no Studio. Usuários avançados continuam tendo acesso às APIs para configurações mais granulares.

A nova interface fica disponível no painel lateral do Studio, em Jobs → Inference optimization, e oferece um fluxo guiado de ponta a ponta cobrindo configuração da carga de trabalho, otimização, seleção de modelo e implantação.

Como funciona o fluxo de otimização

Perfis de caso de uso predefinidos

O primeiro passo é definir a configuração da carga de trabalho. Em vez de especificar manualmente distribuições de tokens e concorrência, o usuário seleciona um perfil predefinido que representa um padrão de tráfego comum:

• Interact: modela cargas de trabalho estilo chat, com entradas curtas e saídas moderadas.
• Generate: otimizado para geração de conteúdo com saídas mais longas.
• Summarize: voltado para sumarização de documentos, com alta proporção entre entrada e saída.
• Custom: para quando nenhum dos perfis anteriores se encaixa — permite trazer seu próprio dataset e configurar concorrência, tamanho de tokens e dados de avaliação manualmente.

O perfil selecionado define os parâmetros do benchmark automaticamente, sem que o usuário precise raciocinar sobre eles diretamente.

Objetivos de otimização

Junto ao perfil de caso de uso, o usuário escolhe o objetivo de otimização — o que diz ao SageMaker AI o que priorizar:

• Minimize latency (Minimizar latência): busca o menor tempo de resposta possível, ideal para aplicações interativas onde o usuário aguarda cada token.
• Maximize throughput (Maximizar throughput): serve o maior número de tokens por segundo, mais adequado para cargas em lote ou alto volume.
• Minimize cost (Minimizar custo): encontra a configuração mais eficiente em custo para o tráfego esperado.

O objetivo escolhido influencia tanto as técnicas que o SageMaker AI aplica quanto a forma como ele classifica as recomendações resultantes.

Fontes de modelo suportadas

A interface aceita modelos de diferentes origens. É possível buscar um modelo fundacional (FM — Foundation Model) diretamente do catálogo do Amazon SageMaker JumpStart, apontar para um artefato de modelo próprio no Amazon Simple Storage Service (Amazon S3), reutilizar um pacote registrado no Model Registry ou selecionar um modelo SageMaker existente de um deployment ou job de treinamento anterior.

Passo a passo: obtendo recomendações pelo console

Pré-requisitos

Para seguir o fluxo, são necessários: uma conta AWS com um domínio do Amazon SageMaker AI Studio, permissões de AWS Identity and Access Management (IAM) para operações de otimização de inferência no SageMaker AI, e uma role de execução IAM com acesso aos artefatos do modelo no Amazon S3.

Em relação a custos, não há cobrança adicional para gerar as recomendações. Os custos padrão de computação se aplicam aos jobs de otimização e aos endpoints provisionados durante o benchmarking.

Passo 1: Criar um job de otimização

No painel lateral do Studio, acesse Jobs → Inference optimization e clique em Create (ou Optimize inference). Com o job criado, o próximo passo é informar ao SageMaker AI o que você quer otimizar.

Passo 2: Configurar a estratégia

Cada caso de uso tem requisitos diferentes — alguns têm um orçamento de latência muito restrito, outros têm um orçamento de custo rígido. Dependendo do cenário, selecione um dos perfis de caso de uso (Interact, Generate, Summarize ou Custom) e um objetivo de otimização (Minimize cost, Minimize latency ou Maximize throughput).

Se o perfil Custom for selecionado, campos adicionais aparecem: é possível colar o URI do S3 com o dataset de avaliação em formato JSONL, especificar o número de requisições simultâneas para simular a concorrência e definir o tamanho máximo de tokens de saída.

Passo 3: Selecionar o modelo e o hardware

Usando o botão Select na seção Model, uma janela abre com abas para cada fonte de modelo (JumpStart, S3, Logged e Deployable). Se a opção S3 for escolhida, é necessário fornecer um nome e o caminho URI do artefato do modelo.

Com o modelo selecionado, é possível deixar o SageMaker AI escolher o hardware automaticamente ou restringir a busca a tipos de instância específicos. A seleção de hardware é opcional. Para os objetivos de minimizar latência ou maximizar throughput, é possível expandir a seção Compute e selecionar tipos de instância específicos (por exemplo, ml.g6e.2xl ou g7e.2xl) para avaliação. Se nenhum for especificado, o SageMaker AI seleciona instâncias compatíveis com base nos requisitos do modelo. Para o objetivo de minimizar custo, o SageMaker AI seleciona automaticamente a instância recomendada. Se houver capacidade reservada por meio de um flexible training plan, ela aparece na lista de fontes.

Passo 4: Executar e monitorar

Ao clicar em Optimize, o job é submetido e a página de detalhes exibe a transição de status de Running para Completed. Perfis predefinidos como Interact podem retornar recomendações rapidamente por já serem comparados a configurações pré-validadas, enquanto benchmarks customizados podem levar mais tempo dependendo do tamanho do modelo, tipos de instância e dataset.

A página de detalhes tem três abas: Overview (recomendações ranqueadas com métricas de desempenho, disponíveis após a conclusão do job), Settings (configuração submetida, incluindo caso de uso, objetivo e seleções de hardware) e Details (metadados do job, timestamps e artefatos de saída).

Passo 5: Revisar recomendações e fazer o deploy

A aba Overview exibe os pacotes de inferência ranqueados. Cada pacote mostra a configuração otimizada, métricas de desempenho — tempo até o primeiro token (TTFT — Time To First Token), latência entre tokens (ITL — Inter-Token Latency), throughput e custo — e um botão Deploy.

Ao clicar em Deploy, uma janela pré-preenche o nome do endpoint e o tipo de instância. É possível fazer o deploy em um novo endpoint ou atualizar um existente. O SageMaker AI então executa três etapas em sequência: registra o modelo otimizado, configura o endpoint e provisiona o endpoint. Após o endpoint atingir o status In Service, ele já pode ser invocado imediatamente.

Gerenciamento dos jobs de otimização

A página de listagem em Jobs → Inference optimization oferece gerenciamento centralizado dos jobs. É possível usar a barra de busca para filtrar por nome, parar um job em execução via menu Actions → Stop, excluir jobs antigos e acessar a página de detalhes de qualquer job.

Como a otimização funciona por baixo dos panos

A experiência no console e a API utilizam a mesma infraestrutura de recomendações e benchmarking. O SageMaker AI primeiro analisa a arquitetura do modelo e os requisitos de memória para reduzir o espaço de configurações e identificar opções viáveis. Em seguida, aplica otimizações alinhadas ao objetivo: speculative decoding para throughput ou kernel tuning para latência, dependendo do objetivo selecionado. O SageMaker AI faz benchmark de cada configuração em infraestrutura real de GPU usando o NVIDIA AIPerf com intervalos de confiança de múltiplas execuções. Por fim, pontua os resultados contra o objetivo de otimização e retorna configurações prontas para produção, ranqueadas do melhor para o pior.

O comportamento varia conforme o objetivo:

• Minimize cost: o SageMaker AI cria um endpoint com o tipo de instância recomendado e executa jobs de benchmark contra ele. O status In Service pode ser acompanhado em Deployments → Endpoints, e os runs de benchmark em Training → Training Jobs.
• Minimize latency: se a arquitetura do modelo e o tipo de instância suportarem, o SageMaker AI usa um deployment com kernel ajustado. Caso contrário, cria um ou mais endpoints padrão, cada um correspondendo a um tipo de instância, e executa jobs de benchmark como training jobs para cada combinação.
• Maximize throughput: se a arquitetura e o tipo de instância suportarem speculative decoding, um training job é executado primeiro para treinar o modelo draft antes dos endpoints serem implantados. O SageMaker AI então executa jobs de benchmark como training jobs para cada combinação.

Vale destacar que o job de otimização deleta automaticamente os endpoints criados durante o processo após sua conclusão.

Boas práticas de uso

A AWS recomenda reexecutar os jobs de otimização em algumas situações: após fine-tuning ou atualização do modelo, quando novos tipos de instância ficarem disponíveis na região AWS utilizada, quando os padrões de tráfego mudarem significativamente e após upgrades de contêiner de serving ou de framework. Também é recomendado executar os jobs em uma cadência regular — por exemplo, a cada algumas semanas — já que a equipe do Amazon SageMaker AI adiciona continuamente novas descobertas ao serviço.

Recursos adicionais

• Blog: Amazon SageMaker AI agora suporta recomendações otimizadas de inferência de IA generativa (lançamento via API)
• Documentação: Otimizar inferência de modelos no Amazon SageMaker AI
• Notebooks de exemplo: Exemplos de recomendações de inferência de IA generativa no GitHub

Fonte

Launching UI for generative AI inference recommendations in Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/launching-ui-for-generative-ai-inference-recommendations-in-amazon-sagemaker-ai/)

Família GPT-5.6 chega ao Amazon Bedrock

A AWS anunciou a disponibilidade geral dos modelos OpenAI GPT-5.6 Sol, Terra e Luna no Amazon Bedrock. A novidade traz para a plataforma a família de modelos mais avançada da OpenAI até o momento, integrada ao motor de inferência de nova geração do Bedrock — projetado com foco em alto desempenho, segurança e confiabilidade.

O GPT-5.6 estabelece um novo patamar de inteligência e eficiência, permitindo resolver problemas mais complexos com maior inteligência por token. Os três modelos da família cobrem diferentes níveis de capacidade e custo, todos acessíveis pela Responses API no Amazon Bedrock.

Os três modelos da família GPT-5.6

Cada modelo da família foi pensado para um perfil de uso diferente:

• Sol — o modelo carro-chefe, voltado para raciocínio avançado. Entrega resultados de ponta nos benchmarks de codificação agêntica (agentic coding), sendo a escolha para tarefas que exigem máxima capacidade.
• Terra — o modelo de desempenho equilibrado. Oferece performance equivalente ao GPT-5.5 pela metade do custo, sendo uma opção estratégica para quem precisa de qualidade sem abrir mão da eficiência financeira.
• Luna — o modelo de inferência rápida e econômica. Traz o menor preço da família, ideal para casos de uso que demandam velocidade e escala com custo controlado.

Casos de uso destacados

Com o GPT-5.6 no Bedrock, as equipes podem construir agentes autônomos de codificação, executar análises de longo prazo em genômica e biologia, e conduzir pesquisas avançadas em cibersegurança. São aplicações que exigem tanto capacidade de raciocínio quanto eficiência operacional — e a família GPT-5.6 foi desenhada justamente para cobrir esse espectro.

Prompt caching e controle de custos

Um recurso importante anunciado junto com a família é o prompt caching com pontos de quebra de cache explícitos. Na prática, isso significa que contextos repetidos ao longo de fluxos de trabalho agênticos são cobrados com 90% de desconto — evitando que o custo se multiplique à medida que os agentes escalam. Para arquiteturas que reutilizam muito contexto, esse recurso pode representar uma economia significativa.

A precificação dos modelos segue as mesmas tarifas praticadas diretamente pela OpenAI, e o consumo é contabilizado nos compromissos de gastos da AWS do cliente.

Disponibilidade por região

A disponibilidade atual dos modelos nas regiões da AWS é a seguinte:

• GPT-5.6 Sol: US East (N. Virginia) e US East (Ohio)
• GPT-5.6 Terra e Luna: US East (N. Virginia), US East (Ohio) e US West (Oregon)

Como começar

Para experimentar os modelos, é possível acessar o Console do Amazon Bedrock ou utilizar a Responses API pelo endpoint bedrock-mantle. Para mais detalhes técnicos, a documentação do Amazon Bedrock cobre os modelos da OpenAI disponíveis na plataforma. Quem preferir uma visão mais aprofundada do lançamento pode conferir o post de lançamento no blog oficial.

Fonte

OpenAI GPT-5.6 Sol, Terra, and Luna now generally available on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/07/openai-gpt-sol-terra/)

A família GPT-5.6 chega ao Amazon Bedrock

A AWS anunciou a disponibilidade geral dos modelos GPT-5.6 Sol, Terra e Luna da OpenAI no Amazon Bedrock. A novidade traz a família de modelos mais avançada da OpenAI até hoje para o motor de inferência de nova geração da plataforma, projetado para alto desempenho, segurança e confiabilidade.

O contexto é relevante: organizações que escalam agentes autônomos e produtos com IA precisam de inteligência de fronteira que funcione de forma confiável ao longo de centenas de etapas — de agentes de código que entregam software em produção a pesquisas de segurança cibernética que exploram novas superfícies de ataque, passando por fluxos de trabalho de genômica que analisam sequências genéticas inteiras de ponta a ponta. Essas cargas de trabalho rodam sobre dados sensíveis, exigem throughput consistente sob demanda imprevisível e operam em ambientes onde residência de dados e segurança não são negociáveis.

Os preços do GPT-5.6 no Bedrock seguem as tarifas de primeira parte da OpenAI, e o uso conta para os compromissos existentes com a AWS.

Um novo sistema de nomenclatura e três camadas de capacidade

O GPT-5.6 inaugura um novo sistema de nomenclatura da OpenAI: o número identifica a geração, enquanto Sol, Terra e Luna identificam camadas de capacidade duráveis que podem evoluir em seu próprio ritmo.

GPT-5.6 Sol — raciocínio avançado

O Sol é o modelo de raciocínio principal e o mais poderoso da OpenAI até o momento. Segundo a própria OpenAI, o Sol estabelece um novo estado da arte no Artificial Analysis Coding Agent Index com 80 pontos — 2,8 acima do próximo melhor modelo — usando menos da metade dos tokens de saída, em menos da metade do tempo e custando cerca de um terço a menos.

No ExploitBench, benchmark de pesquisa em segurança cibernética, o Sol alcança 73,5% contra 47,9% do GPT-5.5 com um orçamento comparável de tokens de saída. No Agents’ Last Exam — avaliação de fluxos de trabalho profissionais de longa duração em 55 áreas —, o Sol atinge 53,6 pontos, superando o próximo melhor modelo em 13,1 pontos. Com esforço de raciocínio médio, ainda lidera por 11,4 pontos a aproximadamente um quarto do custo estimado.

O Sol também introduz o max reasoning effort (esforço máximo de raciocínio), que permite aumentar o poder computacional para trabalhos mais complexos. Os casos de uso indicados incluem agentes de codificação autônoma, pesquisa de vulnerabilidades, fluxos de trabalho de descoberta de medicamentos e tarefas que exigem raciocínio profundo em múltiplas etapas.

GPT-5.6 Terra — equilíbrio para produção

O Terra é o modelo balanceado para o trabalho cotidiano em produção. Ele entrega desempenho superior ao GPT-5.5 com custo menor. É indicado para geração de código, fluxos de trabalho de conteúdo, extração de dados estruturados e tarefas agênticas de propósito geral que precisam de raciocínio sólido sem o preço do modelo principal.

GPT-5.6 Luna — velocidade e economia

O Luna é o modelo rápido e acessível. É indicado para tarefas de inferência em alto volume, como classificação, sumarização, roteamento e aplicações em tempo real onde latência e custo por token são prioritários.

Com as três camadas, é possível calibrar capacidade e custo ao modelo certo para cada carga de trabalho. Os modelos GPT-5.6 concluem tarefas com menos tokens de saída do que seus predecessores, entregando melhor desempenho por dólar gasto.

Motor de inferência construído para escala

O tráfego de agentes tende a ser irregular: uma única requisição de usuário pode disparar centenas de chamadas ao modelo, e a demanda pode mudar rapidamente conforme o uso cresce. O motor de inferência de nova geração do Amazon Bedrock agrupa capacidade para absorver picos de demanda enquanto isola o throughput de cada cliente. Isso reduz a necessidade de escolher entre capacidade compartilhada e desempenho previsível de aplicação.

A inferência dentro da região (In-Region) mantém as requisições dentro da Região AWS especificada, ajudando equipes a cumprir requisitos rígidos de residência de dados.

Cache de prompts com pontos de quebra explícitos

Cargas de trabalho agênticas e de múltiplas etapas repetem boa parte do contexto entre chamadas. Instruções de sistema, definições de ferramentas e arquivos de referência frequentemente permanecem os mesmos enquanto apenas a entrada mais recente muda.

O GPT-5.6 no Amazon Bedrock introduz o cache de prompts com pontos de quebra explícitos para aproveitar essa repetição. Você marca a parte reutilizável de um prompt com um ponto de quebra de cache, e o Bedrock reutiliza o contexto processado em requisições subsequentes que o compartilhem — cada chamada paga apenas pelo trabalho novo. A entrada em cache é cobrada com 90% de desconto e fica disponível para reutilização por pelo menos 30 minutos. Esse período é suficiente para cobrir o burst de chamadas que uma única execução de agente gera, sem multiplicar o custo conforme as cargas de trabalho crescem.

Segurança robusta com proteção em nível de hardware

Modelos mais capazes exigem salvaguardas mais fortes. O GPT-5.6 conta com a pilha de segurança mais robusta da OpenAI até hoje, moldada pelo período de avaliação mais extenso da empresa, combinando red teaming humano com testes automatizados em larga escala. A pilha de segurança inclui recusas em nível de modelo para atividades proibidas, classificadores de uso indevido em tempo real, monitoramento contínuo e aplicação em nível de conta para padrões persistentes.

No Amazon Bedrock, essas proteções se somam à segurança em nível de hardware. O Bedrock utiliza um modelo de segurança ZOA (Zero-Operator Access — acesso zero ao operador), aplicado no chip, de modo que nenhum operador da AWS pode acessar seus prompts ou respostas. Cada chamada ao modelo roda sob as políticas do seu IAM (Identity and Access Management — Gerenciamento de Identidade e Acesso), dentro da sua VPC (Virtual Private Cloud — Nuvem Privada Virtual), e é registrada no AWS CloudTrail. Políticas de perímetro de dados evitam exfiltração entre fronteiras de conta e rede.

Conforme exigido pelo provedor do modelo, dados de tráfego sinalizados por classificadores serão retidos por até 30 dias para detecção automatizada de abuso.

ChatGPT Work e Codex no contexto do GPT-5.6

Junto ao GPT-5.6, a OpenAI lançou o ChatGPT Work, um agente dentro do ChatGPT para tarefas maiores e de múltiplas etapas. O aplicativo desktop atualizado do ChatGPT para Mac e Windows reúne Chat, Work e Codex em uma única experiência, com dois agentes dedicados:

• Work: construído para tarefas maiores e de múltiplas etapas. Pode reunir informações em aplicativos e arquivos, usar a web, criar materiais finalizados como planilhas, slides, documentos e sites, e se manter em projetos complexos por horas. Os usuários podem acompanhar o progresso, mudar de direção e aprovar ações importantes.
• Codex: o poderoso agente de codificação para desenvolvedores e profissionais técnicos. Trabalha com arquivos locais, repositórios, terminais, ferramentas de desenvolvimento e ambientes de desenvolvimento para escrever funcionalidades, corrigir bugs, executar testes e abrir pull requests.

Os usuários podem configurar o aplicativo para usar o GPT-5.6 por meio da Responses API no Amazon Bedrock.

Disponibilidade e como começar

O GPT-5.6 Sol está disponível nas seguintes Regiões AWS: US East (N. Virginia) e US East (Ohio). O GPT-5.6 Terra e Luna estão disponíveis em US East (N. Virginia), US East (Ohio) e US West (Oregon).

Para começar a usar Sol, Terra e Luna, acesse o Console do Amazon Bedrock ou utilize programaticamente a Responses API. Para saber mais, consulte a documentação do Amazon Bedrock ou visite a página do produto Amazon Bedrock.

Fonte

OpenAI GPT-5.6 Sol, Terra, and Luna are now generally available on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/openai-gpt-5-6-sol-terra-and-luna-are-now-generally-available-on-amazon-bedrock/)

O que foi anunciado

A AWS anunciou a disponibilidade do modelo Gemma-4-E2B-it no Amazon SageMaker JumpStart, ampliando ainda mais o portfólio de modelos de fundação acessíveis aos clientes da plataforma. Desenvolvido pelo Google DeepMind, esse modelo chega como uma opção multimodal e ajustada para seguir instruções, com foco em execução local eficiente — o que o torna uma escolha interessante para quem quer construir aplicações de Inteligência Artificial (IA) na infraestrutura da AWS sem abrir mão de desempenho.

O que é o Gemma-4-E2B-it

O Gemma-4-E2B-it é um modelo multimodal, ou seja, capaz de processar diferentes tipos de entrada: texto, imagem e áudio. A saída gerada é sempre em formato de texto. Um diferencial importante é o seu modo de raciocínio nativo, que permite ao modelo “pensar passo a passo” antes de formular uma resposta — uma abordagem que tende a aumentar a qualidade e a precisão das respostas em tarefas mais complexas.

Capacidades do modelo

O Gemma-4-E2B-it cobre uma gama ampla de casos de uso. Entre as funcionalidades destacadas pela AWS, estão:

• Compreensão de imagens: detecção de objetos, interpretação de documentos, entendimento de telas e interfaces de usuário (UI), leitura de gráficos e Reconhecimento Óptico de Caracteres (OCR)
• Compreensão de vídeo
• Chamada de funções nativa para fluxos de trabalho agênticos
• Geração, completude e correção de código
• Suporte multilíngue em dezenas de idiomas

Esse conjunto de capacidades posiciona o modelo como uma opção versátil tanto para aplicações voltadas ao usuário final quanto para automações e pipelines de IA mais sofisticados.

Como colocar em produção no SageMaker JumpStart

Uma das vantagens do SageMaker JumpStart é justamente a facilidade de implantação. Para começar a usar o Gemma-4-E2B-it, basta acessar a seção Models dentro do SageMaker Studio ou utilizar o SageMaker Python SDK para realizar o deploy diretamente na conta AWS. O processo é feito em poucos cliques, sem necessidade de configurações complexas de infraestrutura.

Para mais detalhes sobre como implantar e utilizar modelos de fundação no SageMaker JumpStart, a AWS disponibiliza a documentação oficial do Amazon SageMaker JumpStart.

Por que isso importa

A chegada do Gemma-4-E2B-it ao SageMaker JumpStart é mais um passo na expansão do catálogo de modelos de fundação disponíveis na AWS. Para times brasileiros que trabalham com desenvolvimento de aplicações de IA, isso significa acesso a um modelo multimodal de qualidade — com suporte a múltiplos idiomas, incluindo o português — diretamente integrado ao ecossistema de ferramentas que já utilizam no dia a dia.

Fonte

Gemma-4-E2B-it for is now available in Amazon SageMaker JumpStart (https://aws.amazon.com/about-aws/whats-new/2026/07/gemma-4-e2b-on-sagemaker-jumpstart/)

DocumentDB ganha skill dedicada no Agent Toolkit for AWS

A AWS anunciou que o Amazon DocumentDB (com compatibilidade com MongoDB) passou a integrar o Agent Toolkit for AWS como uma skill especializada de banco de dados. A novidade permite que agentes de codificação com Inteligência Artificial (IA) realizem operações completas em clusters do DocumentDB — desde o provisionamento até a resolução de problemas — seguindo fluxos de trabalho estruturados com boas práticas.

Na prática, isso significa que times de desenvolvimento conseguem executar tarefas complexas no DocumentDB com muito menos esforço manual, sem precisar consultar documentações extensas a cada operação.

O que a skill cobre

A skill do Amazon DocumentDB contempla sete fluxos de trabalho distintos:

• Provisionamento de cluster
• Design de schema
• Avaliação de compatibilidade com MongoDB
• Migração baseada em DMS com Captura de Dados de Mudança (CDC)
• Ajuste de performance
• Revisão Well-Architected com 41 verificações
• Upgrades de versão principal

Essa cobertura abrangente reduz erros operacionais e acelera o trabalho dos desenvolvedores, que passam a contar com orientação automatizada em cada etapa.

Integração com o AWS MCP Server e execução standalone

Quando combinada com o AWS MCP Server, a skill permite que os agentes executem comandos da Interface de Linha de Comando (CLI) da AWS e rodem queries de diagnóstico com controles baseados em Gerenciamento de Identidade e Acesso (IAM), registro de auditoria via CloudTrail e execução em ambiente isolado (sandboxed).

Para equipes que preferem trabalhar localmente, a skill também funciona de forma independente, diretamente via CLI da AWS, sem necessidade de integração adicional.

Disponibilidade e como começar

A skill do Amazon DocumentDB está disponível sem custo adicional como parte do Agent Toolkit for AWS. Para começar a usar, a AWS disponibiliza o código no repositório da skill no GitHub. Quem preferir uma introdução mais guiada pode acessar o Guia de Início Rápido do Agent Toolkit. Para aprofundar o conhecimento sobre o serviço em si, o Guia do Desenvolvedor do Amazon DocumentDB é o ponto de partida recomendado.

Fonte

Amazon DocumentDB (with MongoDB compatibility) now available as a skill in the Agent Toolkit for AWS (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-documentdb-agent-skill)

Por que quantização importa na prática

Manter modelos de linguagem em precisão total — 16 bits por parâmetro (BF16 ou FP16) — é caro. Instâncias grandes de GPU têm custo elevado, os ciclos de iteração ficam lentos e o armazenamento cresce rapidamente. A quantização resolve isso reduzindo a precisão numérica dos pesos do modelo: em vez de 16 bits por parâmetro, você passa a usar 4 ou 8 bits, encolhendo o consumo de memória de forma significativa.

O problema clássico da quantização é a perda de qualidade. É aí que entra a quantização dinâmica, metodologia desenvolvida pela Unsloth Dynamic. Em vez de aplicar a mesma redução de bits em todas as camadas do modelo, a abordagem analisa camada por camada: as mais sensíveis à perda de precisão permanecem em maior resolução (por exemplo, 16 bits), enquanto as menos sensíveis são comprimidas de forma agressiva (4 bits ou menos). O resultado é um modelo muito menor com degradação de qualidade bem controlada.

Para ter uma ideia prática: um modelo com 8 bilhões de parâmetros em BF16 ocupa cerca de 16 GB de memória. Com quantização para 4 bits, esse footprint cai para aproximadamente 5 GB — o que frequentemente significa a diferença entre precisar de uma instância multi-GPU e caber confortavelmente em uma GPU única.

A Unsloth é a ferramenta que viabiliza esse fluxo de ponta a ponta: ajuste fino, quantização, exportação e implantação em um único workflow unificado.

Qual formato de modelo usar

Antes de escolher o serviço AWS, a AWS orienta a escolher o artefato de saída correto — a infraestrutura vem depois. O Unsloth suporta dois tipos principais de exportação voltados para implantação:

• Arquivos GGUF — formato de arquivo único que empacota pesos, tokenizador e metadados juntos. É autocontido e pronto para ser carregado sem arquivos adicionais. Ideal para runtimes leves como llama.cpp, Ollama e Unsloth. No ambiente AWS, mapeia para Amazon EC2 ou container customizado no Amazon SageMaker AI.
• Pesos safetensors mesclados — (16 bits, 8 bits, FP8, 4 bits, NVFP4) para engines de maior throughput como vLLM e SGLang. No AWS, mapeia para containers de Inferência de Modelos Grandes (LMI) do SageMaker AI, Amazon EKS ou Amazon ECS.

A tabela abaixo, presente no artigo original, resume o mapeamento entre artefato, runtime e destino AWS:

• GGUF + llama.cpp/Unsloth → Amazon EC2: validação rápida com acesso direto à instância
• GGUF + container customizado → Amazon SageMaker AI: endpoints gerenciados com autoscaling e runtime leve
• Pesos mesclados 16 bits ou 4 bits + vLLM/SGLang/LMI → Amazon SageMaker AI: alto throughput, batching, autoscaling, GPU em produção
• Qualquer stack containerizado → Amazon EKS ou Amazon ECS: quando a inferência precisa se integrar a um framework de containers já existente

Os quatro padrões de implantação

Padrão 1: GGUF no Amazon EC2 com llama.cpp

O ponto de partida recomendado é o Amazon EC2, pela transparência e controle máximo. Nele é possível comparar diferentes níveis de quantização, testar formatação de prompts, avaliar comportamento em CPU versus GPU e medir o consumo real de memória antes de se comprometer com um endpoint gerenciado.

Uma exportação típica no Unsloth se parece com isso:

model.save_pretrained_gguf("gguf_model", tokenizer, quantization_method="q4_k_xl")

Para iniciar o servidor, o comando mínimo do llama-server é:

llama-server \
  --model /models/my-model.gguf \
  --alias my-model \
  --ctx-size 8192 \
  --host 0.0.0.0 \
  --port 8080

Ou usando o Unsloth diretamente:

unsloth run \
  --model /models/my-model.gguf \
  --alias my-model \
  --ctx-size 8192 \
  --host 0.0.0.0 \
  --port 8080

A partir daí, a aplicação se comunica com o modelo via interface compatível com OpenAI:

from openai import OpenAI
client = OpenAI(
    base_url="http://<ec2-private-ip>:8080/v1",
    api_key="not-required",
)
response = client.chat.completions.create(
    model="my-model",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain AWS Graviton in two sentences."},
    ],
    max_tokens=128,
)
print(response.choices[0].message.content)

Atenção: essa configuração é adequada para testes isolados. Em produção, é necessário restringir o grupo de segurança a blocos de Roteamento entre Domínios sem Classe (CIDR) conhecidos, vincular a uma interface privada e colocar o endpoint atrás de um gateway de API autenticado ou balanceador de carga.

Consulte a documentação GGUF do Unsloth para a lista completa de métodos de quantização e suas características.

Padrão 2: GGUF no Amazon SageMaker AI com container customizado

Quando é necessário um endpoint de produção com autoscaling, monitoramento, integração com Gerenciamento de Identidade e Acesso (IAM) e uma superfície de API estável, os endpoints de inferência do Amazon SageMaker AI são a escolha mais adequada.

Para implantações GGUF, o design mais prático é um container de inferência customizado que empacota o arquivo GGUF junto com o llama.cpp. O container precisa escutar na porta 8080, implementar /ping para verificações de saúde e /invocations para requisições de inferência.

O repositório GitHub de exemplo inclui uma demonstração completa desse padrão. Ele implanta uma comparação lado a lado entre o Qwen3-VL-8B-Instruct quantizado dinamicamente pelo Unsloth (GGUF Q4_K_XL servido com llama.cpp em ml.g5.xlarge, aproximadamente US$ 1,41/hora) e a variante BF16 em precisão total (servida com vLLM em ml.g5.12xlarge, aproximadamente US$ 7,09/hora). Preços referentes a junho de 2026; consulte a página de preços do Amazon SageMaker AI para valores atualizados.

O script de entrada inicia o llama-server em uma porta interna e usa o nginx como proxy reverso para satisfazer a interface do SageMaker AI:

# Start llama-server with the GGUF model and vision projector
/app/llama-server \
  --model /models/Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf \
  --mmproj /models/mmproj-F16.gguf \
  --host 0.0.0.0 \
  --port 8081 \
  --ctx-size 4096

O nginx então mapeia /ping para o health check do llama-server e /invocations para o endpoint de chat completions:

# SageMaker health check endpoint
location /ping {
    proxy_pass http://llama_backend/health;
}
# SageMaker inference endpoint -> llama.cpp chat completions
location /invocations {
    proxy_pass http://llama_backend/v1/chat/completions;
    proxy_read_timeout 120s;
}

A arquitetura típica funciona assim: o arquivo GGUF finalizado fica armazenado no Amazon Simple Storage Service (Amazon S3); ao iniciar, o container do SageMaker AI carrega o modelo de /opt/ml/model e expõe uma camada de API que traduz as requisições do SageMaker AI em chamadas de inferência locais.

Padrão 3: Pesos mesclados no Amazon SageMaker AI com engines otimizadas para GPU

GGUF é excelente quando o tamanho do arquivo e o runtime leve são as prioridades. Mas quando throughput e eficiência de GPU são o foco, os pesos mesclados se tornam mais atrativos.

Pesos mesclados são o modelo salvo como um conjunto unificado de pesos em safetensors — frequentemente o resultado da combinação de um adaptador ajustado (como um adaptador de Adaptação de Baixo Rank, LoRA) com o modelo base. O Unsloth suporta exportações de saída mesclada em 16 bits e 4 bits, mais adequadas para runtimes como vLLM e SGLang, construídos para padrões de serving em GPU de produção: batching, alto throughput de tokens e escalonamento multi-GPU.

Uma exportação representativa:

model.save_pretrained_merged(
    "finetuned_model",
    tokenizer,
    save_method="merged_16bit",
)

O caminho de serving é simplesmente:

vllm serve finetuned_model

No AWS, os containers LMI disponíveis para o Amazon SageMaker AI são especialmente relevantes aqui. Para o endpoint de precisão total no exemplo de referência, o container LMI é configurado inteiramente por variáveis de ambiente no recurso Terraform:

HF_MODEL_ID             = "Qwen/Qwen3-VL-8B-Instruct"
OPTION_DTYPE            = "bf16"
OPTION_ROLLING_BATCH    = "vllm"
OPTION_TENSOR_PARALLEL_DEGREE = "4"
OPTION_MAX_MODEL_LEN    = "4096"

Nenhum container customizado é necessário. O container LMI baixa o modelo do Hugging Face na inicialização e o serve via vLLM com paralelismo tensorial em 4 GPUs A10G. O paralelismo tensorial divide o modelo entre múltiplas GPUs para que cada uma processe uma parte da computação em paralelo.

A regra prática sugerida no artigo: use GGUF e llama.cpp quando quiser o caminho de implantação mais leve. Use pesos mesclados com vLLM, SGLang ou backend LMI quando throughput, batching, concorrência ou topologia de hardware se tornarem as restrições dominantes.

Padrão 4: Amazon EKS ou Amazon ECS quando a inferência precisa se encaixar no ambiente existente

Para equipes que já padronizaram em Kubernetes ou Amazon ECS, faz mais sentido empacotar o runtime do Unsloth nesse ambiente do que introduzir uma superfície de serving separada apenas para modelos. Esse padrão é especialmente útil quando a inferência precisa conviver com outros serviços de aplicação, quando já existe tooling robusto em torno do Amazon EKS ou Amazon ECS, ou quando deployment, rede, observabilidade e segurança já estão padronizados na camada de infraestrutura.

Para equipes que precisam de infraestrutura de cluster gerenciada para treinamento e inferência em larga escala, o Amazon SageMaker HyperPod também vale ser avaliado, embora o artigo original foque em padrões de implantação apenas de inferência.

Práticas operacionais que fazem diferença em produção

Mantenha a formatação de prompts consistente de ponta a ponta

Formatação inconsistente de prompts é uma das formas mais comuns de diagnosticar erroneamente um bom modelo como uma implantação ruim. Quando um modelo exportado se comporta pior fora do Unsloth, o problema geralmente não é o método de quantização — é uma incompatibilidade no template de chat, no tratamento do token de fim de sequência (EOS) ou na estrutura do prompt entre treino e inferência. Consulte a documentação de templates de chat do Unsloth para detalhes sobre configuração de template no momento da exportação.

Avalie o formato completo de implantação, não apenas o nível de quantização

Um benchmark de quantização isolado não é suficiente. O comportamento real depende do tamanho do contexto, concorrência, mix de requisições, comportamento de streaming, caminho de inicialização e o próprio runtime. O Amazon SageMaker AI também oferece recomendações de inferência que podem ajudar a identificar tipos de instância e configurações otimizadas.

Use entrega estável de artefatos

Após finalizar o modelo, promova-o por um caminho de armazenamento previsível. No AWS, isso geralmente significa armazenar o arquivo de modelo escolhido no Amazon S3 e carregá-lo a partir daí, em vez de depender de downloads em tempo de execução de fontes externas durante a inicialização.

Monitore o serviço, não apenas o modelo

Performance em produção não é só sobre qualidade dos tokens — é também sobre tempo de inicialização, latência de cauda, concorrência, comportamento de escalonamento e características de carregamento do modelo. Endpoints gerenciados tornam isso mais visível porque é possível acompanhar métricas de invocação e sinais de escalonamento diretamente pelo Amazon CloudWatch.

Valide o contrato do container com antecedência

Se estiver implantando no Amazon SageMaker AI com um container customizado, valide o container localmente antes de fazer o deploy. Certifique-se de que /ping e /invocations se comportam corretamente e que o runtime sobrevive a tamanhos de prompt realistas. Consulte o guia de containers customizados do Amazon SageMaker para a especificação completa da interface.

Projete segurança e rede desde o início

Serving de modelos frequentemente se torna parte de um ambiente de aplicação maior, o que significa que rede, escopo de papéis IAM, acesso à internet, criptografia com o Serviço de Gerenciamento de Chaves AWS (AWS KMS) e posicionamento na Nuvem Privada Virtual (VPC) importam tanto quanto a performance do runtime. Tome essas decisões desde o início. Habilite o AWS CloudTrail para registro de auditoria em nível de API. Consulte a documentação de segurança de infraestrutura do Amazon SageMaker para orientações sobre configuração de VPC e criptografia.

Próximos passos

Para ver esses padrões em ação, o artigo original recomenda clonar o repositório GitHub de exemplo e executar terraform apply para implantar tanto um endpoint GGUF quantizado quanto um endpoint vLLM de precisão total no Amazon SageMaker AI. O Terraform provisiona toda a infraestrutura e uma instância de Notebook do Amazon SageMaker com o repositório pré-clonado, permitindo executar o notebook de comparação imediatamente.

O notebook envia prompts de imagem idênticos para ambos os endpoints, demonstrando inferência multimodal de visão-linguagem com o Qwen3-VL, e produz comparações lado a lado de qualidade de saída, latência, throughput e custo. Ele também inclui um framework de benchmarking que avalia ambos os modelos com métricas objetivas de qualidade (correspondência exata, BLEU, ROUGE-L), permitindo quantificar a degradação causada pela quantização em vez de depender de julgamento subjetivo.

Para evitar cobranças contínuas ao terminar, basta executar terraform destroy para remover os recursos provisionados.

Para aprofundamento, o artigo original indica:

• Documentação Unsloth Dynamic 2.0 GGUF — métodos de quantização e opções de exportação
• Repositório GitHub de exemplo — templates Terraform, código de container customizado e o notebook de comparação

Fonte

Deploying quantized models on Amazon SageMaker AI with Unsloth (https://aws.amazon.com/blogs/machine-learning/deploying-quantized-models-on-amazon-sagemaker-ai-with-unsloth/)