Blog

O que mudou no Amazon Bedrock

A AWS anunciou uma novidade importante para quem trabalha com processamento em lote (batch inference) no Amazon Bedrock. A partir de agora, o serviço passou a suportar a Converse API como tipo de invocação de modelo. Essa mudança representa um avanço significativo em termos de padronização e flexibilidade.

Anteriormente, quando você criava um job de batch inference, era necessário usar formatos de solicitação específicos para cada modelo, trabalhando através da API InvokeModel. Isso exigia conhecimento particular de cada provedor e tornava a transição entre diferentes modelos mais complexa do que deveria ser.

Benefícios da mudança

Formato unificado e consistente

Com o suporte à Converse API no batch inference, você agora pode utilizar um formato padronizado e independente de modelo. Ao criar um job de batch inference, basta selecionar a Converse como tipo de invocação e estruturar seus dados de entrada usando o formato de solicitação padrão da Converse API. As respostas também seguem o padrão de formato da Converse API.

Simplificação do gerenciamento de prompts

Um dos grandes diferenciais dessa atualização é a possibilidade de usar o mesmo formato de solicitação unificado tanto para inferência em tempo real quanto para processamento em lote. Isso reduz significativamente o esforço necessário para gerenciar prompts e diminui a complexidade ao alternar entre diferentes modelos de IA.

Como começar

A configuração do tipo de invocação Converse está disponível tanto através do console do Amazon Bedrock quanto via API. Esse recurso está disponível em todas as regiões AWS que suportam batch inference no Amazon Bedrock.

Para conhecer os detalhes técnicos e colocar a funcionalidade em prática, consulte a documentação oficial do Amazon Bedrock User Guide, especificamente nos artigos sobre criação de jobs de batch inference e formatação e upload de dados para batch inference.

Impacto prático para desenvolvedores

Essa mudança simplifica o desenvolvimento de aplicações que utilizam modelos de IA. Desenvolvedores e arquitetos brasileiros que trabalham com AWS podem agora manter uma única estrutura de solicitação para seus fluxos de trabalho, independentemente de estar fazendo chamadas em tempo real ou processando grandes volumes de dados em lote. Isso representa economia de tempo de desenvolvimento e redução de erros decorrentes de incompatibilidades de formato.

Fonte

Amazon Bedrock batch inference now supports the Converse API format (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-batch-inference-supports-converse-api-format/)

Um Marco na Governança de IA em Nuvem

Em novembro de 2024, a Amazon Web Services (AWS) marcou presença como a primeira grande provedora de serviços em nuvem a anunciar a certificação acreditada ISO/IEC 42001 para seus serviços de inteligência artificial. Essa conquista cobriu um portfólio estratégico de soluções: Amazon Bedrock, Amazon Q Business, Amazon Textract e Amazon Transcribe.

A Auditoria de Vigilância e Seus Resultados

Um ano após essa certificação inicial, em novembro de 2025, a AWS completou com êxito sua primeira auditoria de vigilância para a norma ISO 42001:2023, que estabelece diretrizes para Sistemas de Gestão de Inteligência Artificial. O resultado notável: nenhum achado foi identificado durante o processo.

Esse resultado positivo evidencia o compromisso contínuo da AWS com práticas responsáveis no desenvolvimento e operação de tecnologias de IA. A auditoria de vigilância funciona como validação independente de que os controles implementados pela empresa estão operando adequadamente e de forma consistente.

O Que Isso Significa para os Clientes

A validação externa conquistada pela AWS oferece segurança adicional aos seus clientes. Organizações que utilizam os serviços de IA da plataforma ganham mais confiança para construir e operar aplicações de inteligência artificial de forma responsável, sabendo que o provedor subjacente foi auditado independentemente por órgãos certificadores.

Essa abordagem demonstra que a empresa leva a sério questões fundamentais como transparência, conformidade regulatória e responsabilidade no uso de IA — temas cada vez mais críticos à medida que essas tecnologias se disseminam pelas organizações.

Acessando as Certificações

Clientes interessados em consultar a lista completa de serviços da AWS certificados sob normas ISO e CSA STAR podem acessar a página de Serviços Certificados ISO e CSA STAR. As certificações também estão disponíveis diretamente no Console de Gerenciamento da AWS, por meio do AWS Artifact — um repositório centralizado para documentos de conformidade e relatórios de segurança.

Fonte

AWS successfully completed its first surveillance audit for ISO 42001:2023 with no findings (https://aws.amazon.com/blogs/security/aws-successfully-completed-its-first-surveillance-audit-for-iso-420012023-with-no-findings/)

Modelos base e a necessidade de personalização

Modelos de fundação entregam desempenho impressionante para tarefas genéricas, mas muitas organizações precisam de modelos que entendam suas especificidades de negócio. Quando você constrói aplicações que exigem expertise em domínios específicos, aplicação de estilos de comunicação particulares, otimização para tarefas especializadas como geração de código ou raciocínio financeiro, ou ainda conformidade com regulamentações do setor, a personalização do modelo se torna essencial para fechar a lacuna entre IA genérica e necessidades específicas.

O desafio está em como personalizar efetivamente. O refinamento supervisionado tradicional funciona, mas requer milhares de exemplos cuidadosamente rotulados mostrando não apenas a resposta final correta, mas também o caminho completo do raciocínio para chegar a ela. Para muitas aplicações reais, especialmente aquelas onde múltiplos caminhos de solução são válidos, criar essas demonstrações passo a passo pode ser dispendioso e demorado.

Uma nova abordagem: aprendizado por avaliação em vez de imitação

O refinamento com aprendizado por reforço (RFT) muda o paradigma: em vez de aprender por imitação, o modelo aprende por avaliação. Em vez de fornecer milhares de exemplos rotulados, você oferece prompts e define o que torna uma resposta final correta através de casos de teste, resultados verificáveis ou critérios de qualidade. O modelo então aprende a otimizar esses critérios através de feedback iterativo, descobrindo seus próprios caminhos para soluções corretas.

O RFT é particularmente eficaz para personalização de modelos em geração de código e raciocínio matemático, verificando outputs automaticamente e eliminando a necessidade de fornecer raciocínio detalhado passo a passo.

A AWS disponibilizou o RFT em seus serviços de IA para atender você em qualquer estágio de sua jornada: comece simples com a experiência totalmente gerenciada do Amazon Bedrock, ganhe mais controle com os SageMaker Training Jobs, dimensione para infraestrutura avançada com o SageMaker HyperPod, ou libere capacidades de ponta com o Nova Forge para conversas multi-turno e ambientes de aprendizado por reforço customizados.

Em dezembro de 2025, a Amazon lançou a família Nova 2 — os primeiros modelos da empresa com capacidades de raciocínio integradas. Diferentemente de modelos tradicionais que geram respostas diretas, modelos de raciocínio como o Nova 2 Lite engajam em decomposição de problemas passo a passo, realizando etapas de pensamento intermediário antes de produzir respostas finais. Quando combinado com RFT, essa capacidade de raciocínio se torna particularmente poderosa: o RFT pode otimizar não apenas qual resposta o modelo produz, mas como ele raciocina através de problemas, ensinando-o a descobrir caminhos de raciocínio mais eficientes enquanto reduz o uso de tokens.

Casos de uso práticos do RFT

O RFT se destaca em cenários onde você pode definir e verificar resultados corretos, mas criar demonstrações detalhadas de solução passo a passo em escala é impraticável:

• Geração de código: você deseja código não apenas correto, mas também eficiente, legível e que trate casos extremos graciosamente — qualidades que você pode verificar programaticamente através de execução de testes e métricas de desempenho.
• Atendimento ao cliente: você precisa avaliar se as respostas são úteis, mantêm a voz da marca e apresentam o tom certo para cada situação. Essas são avaliações que não podem ser reduzidas a regras simples, mas podem ser avaliadas por um juiz de IA treinado em seus padrões de comunicação.
• Outras aplicações: moderação de conteúdo, onde contexto e nuance importam; tarefas de raciocínio multi-etapas como análise financeira ou revisão de documentos legais; e uso de ferramentas, onde você precisa ensinar modelos quando e como chamar APIs ou consultar bancos de dados.
• Problemas que exploram diversas soluções: casos como jogos e estratégia, alocação de recursos e agendamento se beneficiam de abordagens onde o modelo usa diferentes estratégias e aprende com feedback.
• Cenários com dados rotulados limitados: aplicações específicas de domínio com poucos exemplos anotados por especialistas, novos domínios de problema sem padrões de solução estabelecidos, ou tarefas caras de rotular (diagnóstico médico, análise legal).

Como o RFT funciona

O RFT opera através de um processo automatizado de três estágios:

Estágio 1: Geração de respostas — O modelo ator (o modelo que você está personalizando) recebe prompts de seu conjunto de dados de treinamento e gera múltiplas respostas por prompt — tipicamente 4 a 8 variações. Essa diversidade oferece ao sistema um leque de respostas para avaliar e aprender.

Estágio 2: Cálculo de recompensas — Em vez de comparar respostas com exemplos rotulados, o sistema avalia qualidade usando funções de recompensa. Você tem duas opções: aprendizado por reforço via recompensas verificáveis (RLVR), usando verificadores baseados em regras implementados como funções AWS Lambda, perfeito para tarefas objetivas como execução de código ou verificação de problemas matemáticos; ou aprendizado por reforço de feedback de IA (RLAIF), usando juízes baseados em IA que avaliam respostas com base em critérios que você configura, ideal para tarefas subjetivas como avaliar utilidade, criatividade ou aderência à voz da marca.

Estágio 3: Treinamento do modelo ator — O sistema usa os pares prompt-resposta pontuados para treinar seu modelo através de um algoritmo de aprendizado por reforço, como Group Relative Policy Optimization (GRPO), otimizado para modelos de linguagem. O modelo aprende a maximizar a probabilidade de gerar respostas com alta recompensa enquanto minimiza respostas com baixa recompensa. Esse processo iterativo continua até que o modelo atinja seu desempenho desejado.

Benefícios principais do RFT

• Sem necessidade de datasets massivos e rotulados: RFT requer apenas prompts e uma maneira de avaliar qualidade. Se usar Bedrock RFT, você pode até aproveitar logs de invocação da API do Bedrock existentes como dados de RFT, eliminando a necessidade de datasets especialmente criados.
• Otimizado para resultados verificáveis: Diferentemente do refinamento supervisionado que requer demonstrações explícitas de como atingir respostas corretas, RFT é otimizado para tarefas onde você pode definir e verificar resultados corretos, mas múltiplos caminhos de raciocínio válidos podem existir.
• Redução no uso de tokens: Ao otimizar o processo de raciocínio do modelo, RFT pode reduzir o número de tokens necessários para realizar uma tarefa, diminuindo custo e latência em produção.
• Seguro e monitorado: Seus dados proprietários nunca deixam o ambiente seguro da AWS durante o processo de personalização, e você obtém monitoramento em tempo real de métricas de treinamento para acompanhar progresso e garantir qualidade.

Opções de implementação: do simples ao complexo

A AWS oferece múltiplos caminhos de implementação para refinamento com aprendizado por reforço com modelos Nova, variando de experiências totalmente gerenciadas até infraestrutura customizável. Essa abordagem em camadas permite corresponder sua implementação de RFT às suas necessidades específicas, expertise técnica e nível desejado de controle.

Amazon Bedrock

O Amazon Bedrock fornece um ponto de entrada para RFT com experiência totalmente gerenciada que requer expertise mínima em aprendizado de máquina. Através do console ou API do Amazon Bedrock, você pode carregar seus prompts de treinamento, configurar sua função de recompensa como uma função AWS Lambda, e iniciar seu trabalho de refinamento com aprendizado por reforço em poucos cliques. O Bedrock cuida de todo o provisionamento de infraestrutura, orquestração de treinamento e implantação de modelo automaticamente. Essa abordagem funciona bem para casos de uso diretos onde você precisa otimizar critérios específicos sem gerenciar infraestrutura.

Bedrock RFT suporta ambas as abordagens RLVR (recompensas baseadas em regras) e RLAIF (feedback baseado em IA), com ferramentas de monitoramento e avaliação integradas para acompanhar a melhoria de seu modelo. Para começar, veja o repositório Amazon Nova RFT no GitHub.

Amazon SageMaker Training Jobs

Para equipes que precisam de mais controle sobre o processo de treinamento, os Amazon SageMaker Training Jobs oferecem um meio termo flexível com computação gerenciada e capacidade de ajustar múltiplos hiperparâmetros. Você também pode salvar checkpoints intermediários e usá-los para criar fluxos de trabalho de treinamento iterativo, como encadear trabalhos de refinamento supervisionado (SFT) e RFT para refinar progressivamente seu modelo. Você tem flexibilidade para escolher entre abordagens de treinamento LoRA (adaptação de baixa classificação) e full-rank, com controle total sobre hiperparâmetros.

Essa camada é ideal para engenheiros de aprendizado de máquina e cientistas de dados que precisam de personalização além do Amazon Bedrock, mas não requerem infraestrutura dedicada. Para começar, consulte os notebooks SFT e RFT.

Amazon SageMaker HyperPod

O SageMaker HyperPod oferece infraestrutura de nível empresarial para cargas de trabalho RFT em larga escala com clusters baseados em Kubernetes persistentes otimizados para treinamento distribuído. Essa camada constrói sobre todos os recursos disponíveis em SageMaker Training Jobs em escala muito maior, com recursos de computação dedicados e configurações de rede especializadas. Para mais informações, veja avaliação baseada em RFT.

Nova Forge

O Nova Forge fornece capacidades avançadas de treinamento de feedback por reforço projetadas para equipes de pesquisa em IA e praticantes construindo aplicações agentic sofisticadas. Ao se libertar de restrições de interação de turno único e timeouts de Lambda, o Nova Forge habilita fluxos de trabalho complexos multi-turno com ambientes personalizados rodando em sua própria VPC. Essa arquitetura oferece controle completo sobre geração de trajetória, funções de recompensa e interação direta com capacidades de servidores de treinamento e inferência — essencial para aplicações de IA de ponta que os tiers RFT padrão não conseguem suportar.

Abordagem sistemática para RFT

O refinamento com aprendizado por reforço melhora progressivamente modelos pré-treinados através de iterações de aprendizado estruturadas baseadas em recompensa. Antes de iniciar RFT, avalie se seu modelo apresenta desempenho em nível minimamente aceitável. RFT requer que o modelo consiga produzir pelo menos uma solução correta entre várias tentativas durante o treinamento. Se todos os rollouts (gerações) falham consistentemente, o modelo não tem sinal positivo para aprender, tornando RFT ineficaz. Nesses casos, você deve primeiro usar refinamento supervisionado (SFT) para estabelecer capacidades básicas antes de tentar RFT.

Após validar a linha de base, identifique o dataset correto e a função de recompensa. Selecione ou crie um dataset de prompts representando os cenários que seu modelo encontrará em produção. Monitore continuamente as métricas de treinamento e rollouts de modelo ao longo do processo. O RFT é um processo iterativo — use insights de cada execução para refinar sua função de recompensa, expandir seu conjunto de prompts ou ajustar hiperparâmetros.

Caso prático: Otimização do benchmark FinQA com RFT

Neste caso prático, você caminha através de um exemplo usando FinQA, um benchmark de análise financeira, com 1000 amostras do dataset público FinQA. Os dados devem ser preparados no formato compatível com o esquema RFT, seguindo o formato conversacional OpenAI. Cada exemplo de treinamento é um objeto JSON contendo campos obrigatórios como mensagens e reference_answer, além de campos opcionais como id e custom metadata.

A função de recompensa é o componente central que avalia respostas do modelo e fornece sinais de feedback para treinamento. Ela deve ser implementada como uma função AWS Lambda que aceita respostas do modelo e retorna pontuações de recompensa. As melhores práticas incluem começar pequeno com 100-200 exemplos e poucos epochs, fazer baseline com SFT primeiro se as pontuações de recompensa forem consistentemente baixas, e desenhar funções de recompensa eficientes que executem em segundos.

Uma vez que você tem dados preparados, lance RFT usando SageMaker Training Jobs. Os dois inputs chave são o dataset de entrada e o ARN da função Lambda de recompensa. Durante o monitoramento dos trabalhos iniciados, você pode acompanhar o progresso em logs do Amazon CloudWatch para SageMaker Training Jobs observando as métricas específicas de RFT. Métricas importantes incluem distribuição de recompensas do crítico (indicando como a forma das recompensas se parece e se as recompensas estão em trajetória de aumento gradual) e métricas de comportamento exploratório do modelo (ajudando você a entender a natureza exploratória do modelo).

RFT versus refinamento supervisionado: quando usar cada um

O refinamento supervisionado (SFT) funciona melhor para tarefas bem definidas com outputs claros desejados — fornece conhecimento factual direto e é ideal quando você tem pares prompt-resposta de alta qualidade. Sua força está em fornecer estruturas de output consistentes e específicas, mas requer exemplos explicitamente rotulados e pode se debater em tarefas envolvendo soluções ambíguas ou múltiplas válidas.

O RFT é mais adequado para cenários onde uma função de recompensa pode ser definida, mesmo que exista apenas uma solução válida. Seus pontos fortes incluem otimização de tarefas complexas de raciocínio, geração eficiente de dados de treinamento reduzindo a necessidade por muitos exemplos rotulados manualmente, e permitir balanceamento de objetivos concorrentes. Sua limitação principal é que requer que o modelo produza pelo menos uma solução correta entre várias tentativas — se o modelo falha consistentemente em gerar soluções corretas, RFT sozinho não será eficaz.

Conclusão

Com RFT você pode realizar personalização de modelo através de aprendizado baseado em avaliação, requerendo apenas prompts e critérios de qualidade em vez de datasets massivos rotulados. Para implementação totalmente gerenciada, comece com Amazon Bedrock. Se precisar de controle mais flexível, mude para SageMaker Training Jobs. Para cargas de trabalho em escala empresarial, o SageMaker HyperPod fornece a infraestrutura necessária. Alternativamente, explore o Nova Forge para aplicações agentic multi-turno com ambientes de aprendizado por reforço customizados.

Fonte

Reinforcement fine-tuning for Amazon Nova: Teaching AI through feedback (https://aws.amazon.com/blogs/machine-learning/reinforcement-fine-tuning-for-amazon-nova-teaching-ai-through-feedback/)

O Desafio da Inferência em Grande Escala

O deployment de grandes modelos de linguagem (LLMs) enfrenta um desafio crescente de custo e desempenho impulsionado pelo aumento do número de tokens processados. O contagem de tokens, que está diretamente relacionada à quantidade de palavras, tamanho de imagens e outros fatores de entrada, determina tanto os requisitos computacionais quanto os custos operacionais. Contextos mais longos traduzem-se em despesas maiores por requisição de inferência.

Esse desafio intensificou-se conforme os modelos de ponta passaram a suportar até 10 milhões de tokens para acomodar demandas crescentes de contexto provenientes de sistemas de Geração Aumentada por Recuperação (RAG – Retrieval Augmented Generation) e agentes de código que necessitam acessar extensas bases de código e documentação.

Contudo, pesquisas do setor revelam que uma parcela significativa dos tokens processados em cargas de trabalho de inferência é repetitiva. Os mesmos documentos e trechos de texto aparecem frequentemente em múltiplos prompts. Essas “zonas quentes” de dados representam uma oportunidade clara. Ao cachear conteúdo frequentemente reutilizado, as organizações podem alcançar reduções de custos e melhorias de desempenho em suas cargas de trabalho de inferência com contexto longo.

Atualizações do Contêiner LMI

A AWS lançou recentemente atualizações significativas no contêiner de Inferência de Grandes Modelos (LMI – Large Model Inference), entregando melhorias abrangentes de desempenho, suporte expandido para modelos e capacidades simplificadas de deployment para clientes que hospedam LLMs na AWS. Essas liberações focam em reduzir a complexidade operacional enquanto entregam ganhos mensuráveis de desempenho em arquiteturas de modelo populares.

Suporte a LMCache: Transformando Inferência de Contexto Longo

Uma das capacidades mais significativas introduzidas nas versões mais recentes do LMI é o suporte abrangente a LMCache. O LMCache é uma solução de código aberto para cachear chaves-valores (KV caching) que extrai e armazena caches KV gerados por motores LLM modernos, compartilhando esses caches entre motores e consultas para melhorar o desempenho da inferência.

Diferentemente de sistemas tradicionais que apenas cacheiam prefixos, o LMCache reutiliza caches KV de texto repetido — não necessariamente apenas prefixos — dentro de uma instância de motor de atendimento. O sistema funciona no nível de fragmentos, identificando trechos de texto repetidos comumente em documentos ou conversas e armazenando seu cache KV pré-computado.

Essa abordagem permite armazenamento em múltiplas camadas abrangendo memória GPU, memória CPU e backends em disco ou remotos, com cacheing inteligente que mantém um índice interno mapeando sequências de tokens para entradas KV cacheadas. As versões mais recentes do LMI introduzem configuração automática de LMCache, simplificando o deployment e otimização do cache KV. Essa interface de baixo código/sem código (LCNC – Low-Code No-Code) ajuda clientes a habilitarem esse recurso de desempenho avançado sem configurações manuais complexas.

Ao descarregar cache KV da memória GPU para RAM CPU ou armazenamento NVMe, o LMCache permite lidar eficientemente com cenários de contexto longo enquanto entrega melhorias de latência. Ao implementar roteamento aderente baseado em sessão no Amazon SageMaker AI, as organizações maximizam as taxas de acerto do cache, garantindo que requisições da mesma sessão sejam roteadas consistentemente para instâncias com conteúdo relevante cacheado.

Benchmarks de Desempenho do LMCache

Testes abrangentes em vários tamanhos de modelo e comprimentos de contexto revelam melhorias de desempenho que transformam a experiência para cargas de trabalho de inferência com contexto longo. A metodologia de teste adaptou o benchmark LMCache Long Doc QA para funcionar com o contêiner LMI, consistindo em três rodadas: pré-aquecimento para inicialização de início frio, uma rodada de aquecimento para popular armazenamento LMCache, e uma rodada de consulta para medir desempenho ao recuperar do cache.

Os benchmarks foram realizados em instâncias p4de.24xlarge (8× GPUs A100, 1,1 TB RAM, SSD NVMe) usando modelos Qwen com 46 documentos de 10.000 tokens cada (460.000 tokens totais) e 4 requisições concorrentes.

Para cargas de trabalho com contexto repetido, o LMCache alcança Tempo até Primeiro Token (TTFT – Time to First Token) mais rápido ao processar contextos de múltiplos milhões de tokens:

• Offloading de CPU: Entrega melhorias de desempenho com aceleração de 2,18x em latência total de requisição (52,978s → 24,274s) e TTFT 2,65x mais rápido (1,161s → 0,438s).
• Armazenamento NVMe com O_DIRECT habilitado: Aproxima-se do desempenho de CPU (0,741s TTFT) enquanto suporta capacidade de cacheing em escala TB, alcançando aceleração de 1,84x em latência total de requisição e TTFT 1,57x mais rápido.

Esses resultados demonstram redução de 62% em TTFT e redução de 54% em latência de requisição, alinhando-se estritamente com benchmarks publicados de LMCache. Essas reduções de latência traduzem-se diretamente em economia de custos, pois a redução de 54% no tempo de processamento de requisição permite que a mesma infraestrutura processe mais do dobro do volume de requisições, efetivamente reduzindo à metade os custos de computação por requisição.

As características de desempenho variam significativamente por tamanho de modelo devido a diferenças nos requisitos de memória de cache KV por token. Modelos maiores requerem substancialmente mais memória por token (Qwen2.5-1.5B: 28 KB/token, Qwen2.5-7B: 56 KB/token, Qwen2.5-72B: 320 KB/token), significando que esgotam a capacidade de cache KV da GPU em comprimentos de contexto muito mais curtos. O Qwen 2.5-1.5B consegue armazenar cache KV para até 2,6M tokens em memória GPU, enquanto Qwen 2.5-72B atinge seu limite em 480K tokens. Isso significa que o LMCache entrega valor em contextos mais curtos para modelos maiores. Um modelo de 72B pode se beneficiar de offloading de CPU começando em torno de 500K tokens com acelerações de 4-6x, enquanto modelos menores apenas requerem offloading em comprimentos de contexto extremos além de 2,5M tokens.

Configurando LMCache

Métodos de Configuração

Existem dois métodos principais para configurar LMCache conforme definido na documentação do GitHub. O primeiro é uma abordagem de configuração manual, e o segundo é uma configuração automatizada disponível em novas versões do LMI.

Configuração Manual

Para configuração manual, clientes criam sua própria configuração LMCache e a especificam em propriedades, arquivos ou variáveis de ambiente:

option.lmcache_config_file=/path/to/your/lmcache_config.yaml# OROPTION_LMCACHE_CONFIG_FILE=/path/to/your/lmcache_config.yaml

Essa abordagem oferece aos clientes controle sobre configurações de LMCache, permitindo customização de backends de armazenamento de cache, tamanhos de fragmentos e outros parâmetros avançados de acordo com seus requisitos específicos.

Configuração Automática

Para deployments simplificados, clientes podem habilitar configuração automática de LMCache similarmente:

option.lmcache_auto_config=True# OROPTION_LMCACHE_AUTO_CONFIG=True

A auto-configuração gera automaticamente uma configuração LMCache baseada no espaço disponível de CPU/disco na máquina host. Essa opção de deployment apenas suporta deployments com Tensor Parallelism, assume que /tmp está montado em armazenamento NVMe para cacheing baseado em disco, e requer maxWorkers=1. Essas configurações são assumidas com auto-configuração, que é projetada para servir um modelo único por instância de contêiner. Para servir múltiplos modelos ou cópias de modelo, clientes devem usar componentes de inferência do Amazon SageMaker AI, que facilitam isolamento de recursos entre modelos e cópias de modelo.

O recurso de configuração automática simplifica o deployment de cache KV ao eliminar a necessidade de arquivos de configuração YAML manual, permitindo que clientes comecem rapidamente com otimização LMCache.

Recomendações de Deployment

Baseado em resultados abrangentes de benchmarking e experiência de deployment, várias recomendações emergem para deployment optimal de LMI:

• Configure offloading de CPU quando RAM da instância permitir, entregando desempenho optimal para a maioria das cargas de trabalho
• Use NVMe com O_DIRECT habilitado para cargas de trabalho que requerem capacidade de cache além da RAM disponível
• Implemente roteamento aderente baseado em sessão no SageMaker AI para maximizar taxas de acerto do cache e facilitar desempenho consistente
• Considere a arquitetura do modelo ao configurar thresholds de offloading, pois modelos com diferentes configurações de cabeça KV terão configurações optimal diferentes
• Use configuração automática de LMCache para simplificar deployment e reduzir complexidade operacional

Decodificação Especulativa EAGLE

As versões mais recentes do LMI entregam melhorias de desempenho através de suporte para técnicas de decodificação especulativa EAGLE (Extrapolation Algorithm for Greater Language-model Efficiency – Algoritmo de Extrapolação para Maior Eficiência em Modelos de Linguagem). O EAGLE acelera a decodificação de grandes modelos de linguagem ao prever tokens futuros diretamente das camadas ocultas do modelo. Essa abordagem gera tokens rascunho que o modelo primário valida em paralelo, ajudando a reduzir a latência geral de geração enquanto mantém a qualidade da saída.

Configurar decodificação especulativa EAGLE é simples, requerendo apenas a especificação do caminho do modelo rascunho e número de tokens especulativos em sua configuração de deployment. Isso permite que organizações alcançem melhor desempenho para cargas de trabalho de hosting de LLM com benefícios para deployments de produção de alta concorrência e modelos focados em raciocínio.

Suporte Expandido a Modelos e Capacidades Multimodais

As versões mais recentes do LMI entregam suporte abrangente para modelos de código aberto de ponta, incluindo DeepSeek v3.2, Mistral Large 3, Ministral 3 e a série Qwen3-VL. Otimizações de desempenho melhoram tanto throughput quanto Tempo até Primeiro Token (TTFT) para servicing de modelos em larga escala através dessas arquiteturas.

Capacidades multimodais expandidas incluem suporte a FlashAttention ViT, agora servindo como o backend padrão para modelos visão-linguagem. Melhorias de decodificação especulativa EAGLE trazem suporte multi-etapa de gráfico CUDA e suporte multimodal com Qwen3-VL, permitindo inferência mais rápida para cargas de trabalho visão-linguagem. Com essas potencializações, organizações conseguem fazer deployment e escalar modelos foundation (FMs) mais rápido e eficientemente, ajudando a reduzir o tempo para produção enquanto diminuem a complexidade operacional.

Melhorias no Hosting de Adaptadores LoRA

As versões mais recentes do LMI trazem potencializações notáveis para hosting de múltiplos adaptadores LoRA no SageMaker AI. Adaptadores LoRA agora são carregados “preguiçosamente” (lazy loaded) — ao criar um componente de inferência, o componente do adaptador torna-se disponível quase imediatamente, mas o carregamento atual dos pesos do adaptador e registro com o motor de inferência ocorre na primeira invocação. Essa abordagem ajuda a reduzir tempo de deployment enquanto mantém flexibilidade para cenários multi-tenant.

Scripts de pré-processamento de entrada e pós-processamento de saída personalizados agora são suportados tanto para modelos base quanto adaptadores, com cada componente de inferência hosting adaptadores LoRA podendo ter scripts diferentes. Isso permite lógica de formatação específica do adaptador sem modificar código de inferência central, suportando deployments multi-tenant onde diferentes adaptadores aplicam regras de formatação distintas ao mesmo modelo subjacente.

Formatadores de saída personalizados proporcionam um mecanismo flexível para transformar respostas do modelo antes de serem retornadas para clientes, permitindo que organizações padronizem formatos de saída, adicionem metadados customizados ou implementem lógica de formatação específica do adaptador. Esses formatadores podem ser definidos no nível do modelo base para aplicar aos responses por padrão, ou no nível do adaptador para sobrescrever comportamento do modelo base para adaptadores LoRA.

Casos de uso comuns incluem adicionar timestamps de processamento e metadados personalizados, transformar texto gerado com prefixos ou formatação, calcular e injetar métricas customizadas, implementar esquemas de saída específicos do adaptador para diferentes aplicações cliente, e padronizar formatos de resposta entre deployments de modelo heterogêneos.

Próximos Passos

As versões mais recentes do LMI representam passos significativos adiante em capacidades de inferência de grandes modelos. Organizações podem fazer deployment de LLMs de ponta com maior desempenho e flexibilidade através de:

• Suporte abrangente a LMCache nas releases
• Decodificação especulativa EAGLE para inferência acelerada
• Suporte expandido a modelos incluindo capacidades multimodais de ponta
• Hosting melhorado de adaptadores LoRA

As opções configuráveis do contêiner proporcionam flexibilidade para fine-tune de deployments de acordo com necessidades específicas, seja otimizando para latência, throughput ou custo. Com as capacidades abrangentes de sistema do Amazon SageMaker AI, organizações podem focar em entregar soluções alimentadas por IA que ajudem a impulsionar valor para o negócio em vez de gerenciar infraestrutura.

Explore essas capacidades hoje ao fazer deployment de seus modelos de IA generativa na AWS e aproveite as melhorias de desempenho e experiência simplificada de deployment para ajudar a acelerar suas cargas de trabalho em produção.

Fonte

Large model inference container – latest capabilities and performance enhancements (https://aws.amazon.com/blogs/machine-learning/large-model-inference-container-latest-capabilities-and-performance-enhancements/)

O Desafio da Subutilização de GPU com Múltiplos Modelos

Organizações que executam vários modelos de inteligência artificial customizados enfrentam um problema prático: quando modelos individuais não recebem tráfego suficiente para saturar um endpoint dedicado, há desperdício significativo de capacidade de GPU. Modelos recentes da família de Mistura de Especialistas (Mixture of Experts — MoE) amplificam esse desafio.

A AWS, em parceria com a comunidade vLLM, desenvolveu uma abordagem eficiente para servir múltiplos modelos adaptados usando Multi-Low-Rank Adaptation (Multi-LoRA), resolvendo o problema de subutilização. A solução permite que, por exemplo, cinco clientes utilizando apenas 10% de uma GPU dedicada sejam servidos a partir de uma única GPU compartilhada.

Como Funciona a Multi-LoRA para Modelos de Mistura de Especialistas

Entendendo os Modelos MoE

Modelos de Mistura de Especialistas contêm múltiplas redes neurais especializadas chamadas especialistas. Um roteador direciona cada token de entrada para os especialistas mais relevantes, cujas saídas são então agregadas. Essa arquitetura esparsa permite processar modelos maiores com menos recursos computacionais, pois apenas uma fração dos parâmetros totais é ativada por token.

Cada especialista é uma pequena rede de propagação direta que processa o estado oculto de um token em dois estágios. Primeiro, a projeção gate_up expande o estado oculto compacto (por exemplo, 4.096 dimensões) em um espaço intermediário maior (por exemplo, 11.008 dimensões). Essa expansão é necessária porque as características no espaço compacto estão fortemente interligadas — o espaço maior oferece lugar para separar, transformar e seletivamente ativar quais características importam. Em seguida, a projeção down comprime o resultado de volta à dimensão original, mantendo compatibilidade com o resto do modelo.

O Papel da Multi-LoRA

Multi-LoRA é uma abordagem popular para adaptar modelos sem retreinar pesos inteiros. Em vez disso, mantém os pesos originais congelados e injeta pequenos adaptadores treináveis nas camadas do modelo. No tempo de inferência, múltiplos modelos customizados compartilham a mesma GPU, com apenas os adaptadores sendo alternados por requisição.

Para uma projeção com pesos base W de dimensão h_in × h_out, LoRA treina duas matrizes pequenas: A com dimensão h_in × r e B com dimensão r × h_out, onde r é o rank LoRA (tipicamente 16-64). A saída adaptada torna-se y = xW + xAB. Cada adaptador LoRA adiciona duas operações a uma projeção: a operação de redução computa z=xA, reduzindo a entrada de h_in dimensões para r dimensões, e a operação de expansão projeta o resultado de r dimensões de volta para h_out dimensões multiplicando z por B.

Em uma configuração de Multi-LoRA servindo múltiplos adaptadores simultaneamente para diferentes usuários ou tarefas, o sistema deve gerenciar eficientemente essas quatro operações por especialista, por adaptador, por requisição — um gargalo chave de performance para modelos MoE.

Implementação Técnica no vLLM

A AWS utilizava a comunidade vLLM para criar um novo kernel chamado fused_moe_lora que integra operações LoRA ao kernel fused_moe existente. Este novo kernel realiza GEMMs (Multiplicações Gerais de Matrizes) de redução e expansão LoRA para as projeções gate_up e down.

Dois desafios técnicos demandaram soluções especializadas: vLLM não possuía um kernel para realizar LoRA em camadas MoE, pois os kernels Multi-LoRA densos existentes não gerenciam roteamento de especialistas. Além disso, MoE LoRA combina duas fontes de esparsidade — roteamento de especialistas e seleção de adaptadores — exigindo design de kernel especializado.

Com essa implementação inicial, foi possível executar Multi-LoRA com o modelo GPT-OSS 20B em uma GPU H200, alcançando 26 OTPS (Tokens de Saída Por Segundo) e 1.053 ms TTFT (Tempo Até o Primeiro Token) no dataset Sonnet com comprimento de entrada 1.600, comprimento de saída 600 e concorrência de 16.

Otimizações de Performance do vLLM

Otimizações em Nível de Execução

Análises de performance inicial revelaram que TTFT estava 10x pior que o modelo base. Usando ferramentas de profiling, identificou-se que o compilador Triton tratava variáveis dependentes do comprimento de entrada como constantes de tempo de compilação, causando recompilação do kernel fused_moe_lora a partir do zero para cada novo comprimento de contexto em vez de reutilizar uma versão em cache. Isso foi resolvido adicionando uma dica de compilador do_not_specialize, instruindo Triton a compilar o kernel uma vez e reutilizá-lo em todos os comprimentos de contexto.

O profiling também revelou que o kernel fused_moe_lora era lançado com a mesma sobrecarga elevada independentemente de a requisição usar apenas o modelo base, adaptadores somente de atenção ou adaptadores LoRA completos. Adicionou-se lógica de saída antecipada para pular o kernel fused_moe_lora em camadas sem adaptadores LoRA, evitando execução desnecessária.

Os kernels de redução e expansão executavam sequencialmente, criando gaps entre execuções. Implementou-se Programmatic Dependent Launch (PDL) para permitir que o kernel dependente comece a lançar antes do kernel primário terminar. Isso permite que o kernel de expansão pré-carregue pesos em memória compartilhada e cache L2 enquanto o kernel de redução executa.

Adicionou-se também suporte para decodificação especulativa com CudaGraph para LoRA, corrigindo um problema onde o vLLM capturava CudaGraphs diferentes para modelo base e adaptador. CudaGraphs são importantes para eficiência pois capturam sequências de operações GPU, reduzindo sobrecarga de kernel.

Com essas otimizações de execução, OTPS melhorou para 50/100 sem/com decodificação especulativa e TTFT melhorou para 150 ms para GPT-OSS 20B.

Otimizações em Nível de Kernel

Split-K é uma estratégia de decomposição de trabalho que melhora balanceamento de carga para matrizes estreitas. Redução LoRA computa xA onde x tem dimensão 1×h_in e A tem dimensão h_in×r. Cada um dos r elementos de saída requer somar h_in multiplicações. Kernels GEMM padrão atribuem diferentes grupos de threads a diferentes elementos de saída, mas cada grupo calcula sua soma sequencialmente. Com r na dezena e h_in na casa dos milhares, há poucos elementos de saída para paralelizar enquanto cada um requer uma longa soma sequencial. Split-K resolve isso dividindo a soma sobre a dimensão interna K de um GEMM entre múltiplos grupos de threads, que calculam somas parciais em paralelo e combinam resultados.

Cooperative Thread Array (CTA) swizzling reordena o agendamento para que grupos de threads trabalhando em colunas próximas executem simultaneamente, aumentando reutilização de cache L2. Esta técnica foi aplicada à operação de redução LoRA.

Removeu-se mascaramento desnecessário e operações de produto escalar dos kernels LoRA de redução e expansão. Kernels Triton carregam dados em blocos de tamanho fixo, mas dimensões de matrizes podem não se dividir uniformemente nesses tamanhos de bloco. Mascaramento previne acessos ilegais à memória, mas essas verificações condicionais executam em cada operação de carregamento, adicionando sobrecarga. Introduziu-se um parâmetro EVEN_K que verifica se K se divide uniformemente por BLOCK_SIZE_K — quando verdadeiro, carregamentos são válidos e mascaramento pode ser completamente ignorado.

Por fim, fundiu-se a adição dos pesos LoRA aos pesos do modelo base no kernel de expansão LoRA, reduzindo sobrecarga de lançamento de kernel. Essas otimizações de kernel alcançaram 144 OTPS e 135 ms TTFT para GPT-OSS 20B.

Ajuste de Configurações para Amazon SageMaker AI e Amazon Bedrock

Kernels Triton requerem ajuste de parâmetros como tamanhos de bloco (BLOCK_SIZE_M, BLOCK_SIZE_N, BLOCK_SIZE_K) que controlam como a computação de matriz se divide entre grupos de threads. Parâmetros avançados incluem GROUP_SIZE_M, que controla ordem de grupos de threads para localidade de cache, e SPLIT_K, que paraleliza somas sobre a dimensão de matriz interna.

Descobriu-se que os kernels MoE LoRA usando configurações padrão otimizadas para MoE fundido padrão tinham performance ruim para serviço Multi-LoRA. Os padrões não contabilizavam a dimensão de grade adicional correspondente ao índice LoRA e a esparsidade composta de múltiplos adaptadores.

Adicionou-se suporte para usuários carregarem configurações ajustadas customizadas fornecendo um caminho de pasta. Clientes da AWS SageMaker AI e Bedrock agora têm acesso a essas configurações ajustadas, carregadas automaticamente e alcançando 171 OTPS e 124 ms TTFT para GPT-OSS 20B — melhorias subsequentes em relação às 144 OTPS e 135 ms TTFT da versão anterior.

Resultados e Impacto

Através da colaboração com a comunidade vLLM, a AWS implementou e disponibilizou em código aberto Multi-LoRA serving para modelos MoE incluindo GPT-OSS, Qwen3 MoE, DeepSeek, e Llama MoE. As otimizações resultaram em melhorias impressionantes: 454% de aumento em OTPS e 87% de redução em TTFT para GPT-OSS 20B comparando vLLM 0.15.0 versus vLLM 0.11.1rc3.

Algumas otimizações, particularmente ajuste de kernel e CTA swizzling, também melhoraram performance para modelos densos — OTPS do Qwen3 32B melhorou 99%.

Para aproveitar este trabalho em deployments locais, utilize vLLM 0.15.0 ou versões posteriores. Otimizações específicas da AWS, disponíveis no Amazon SageMaker AI e Amazon Bedrock, entregam melhorias adicionais de latência em modelos, por exemplo 19% mais rápido em OTPS e 8% melhor em TTFT versus vLLM 0.15.0 para GPT-OSS 20B.

Como Começar

Para começar com hosting de modelos customizados na AWS, consulte a documentação de Amazon SageMaker AI hosting e Amazon Bedrock.

O repositório vLLM contém as implementações e pode ser explorado para entender melhor as otimizações técnicas por trás dessas melhorias de performance.

Fonte

Efficiently serve dozens of fine-tuned models with vLLM on Amazon SageMaker AI and Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/efficiently-serve-dozens-of-fine-tuned-models-with-vllm-on-amazon-sagemaker-ai-and-amazon-bedrock/)