O desafio de construir sistemas de pedidos com voz em múltiplos canais

Criar um sistema de pedidos ativado por voz que funcione ao mesmo tempo em aplicativos móveis, sites e interfaces de voz — o que chamamos de abordagem omnichannel — envolve desafios técnicos reais. É preciso processar fluxos de áudio bidirecionais, manter o contexto da conversa ao longo de múltiplos turnos, integrar serviços de backend sem acoplamento rígido e escalar para suportar picos de tráfego.

A AWS publicou um guia técnico detalhado mostrando como construir um sistema completo de pedidos omnichannel usando o Amazon Bedrock AgentCore — uma plataforma agêntica para construir, implantar e operar agentes de IA de forma segura e escalável — combinado com o Amazon Nova 2 Sonic, modelo de voz em tempo real disponível no Amazon Bedrock.

Visão geral da solução

A arquitetura proposta separa o frontend, o agente de IA e os serviços de backend em componentes distintos, permitindo que cada camada seja desenvolvida e escalada de forma independente. A comunicação entre o agente e os serviços de negócio é feita via Protocolo de Contexto de Modelo (MCP), um padrão aberto para conectar aplicações de IA a fontes de dados externas, ferramentas e fluxos de trabalho.

Os principais serviços utilizados na solução são:

• Amazon Cognito — gerencia autenticação de usuários e fornece credenciais temporárias da AWS para acesso seguro à API, compatível com qualquer provedor de identidade OAuth 2.0.
• Amazon Bedrock AgentCore Runtime — hospeda o agente de IA com isolamento em microVM. Cada sessão de usuário roda em uma máquina virtual isolada, garantindo segurança e desempenho mesmo sob alta carga.
• Amazon Bedrock AgentCore Gateway — oferece uma forma segura de construir, implantar, descobrir e conectar ferramentas em escala, permitindo comunicação padronizada entre o agente e a lógica de negócio sem acoplamento rígido.
• Amazon API Gateway — expõe os serviços de backend via endpoints de Transferência de Estado Representacional (REST) com autorização baseada em Gerenciamento de Identidade e Acesso da AWS (IAM).
• AWS Lambda — executa a lógica de negócio para recuperação de cardápio, processamento de pedidos e serviços de localização.
• Amazon DynamoDB — armazena perfis de clientes, pedidos, itens do cardápio e carrinhos de compras com latência de milissegundos de um dígito.
• AWS Location Services — fornece funcionalidades baseadas em localização para recomendações de retirada de pedidos.
• AWS Amplify — hospeda a aplicação frontend.

Diagrama de arquitetura

A solução é organizada em quatro seções principais. A Seção A cobre a infraestrutura de backend, que provisiona armazenamento de dados para clientes, pedidos, cardápios, carrinhos e localizações, além de funções Lambda, uma camada de API e serviços de autenticação. A Seção B implanta o AgentCore Gateway com as permissões de serviço necessárias e configura a integração de API para expor os endpoints de backend como ferramentas acessíveis pelo agente. A Seção C configura o ambiente de execução do AgentCore Runtime com suporte a protocolo WebSocket, usando Amazon ECR para armazenamento de containers e AWS CodeBuild para automação de build. A Seção D implanta a aplicação frontend via AWS Amplify.

Fluxo de requisição do usuário

O fluxo de uma requisição funciona da seguinte forma: o usuário acessa a aplicação web hospedada no AWS Amplify pelo navegador ou dispositivo móvel e se autentica no Amazon Cognito com usuário e senha, recebendo tokens JWT (Token de Acesso e Token de ID). O frontend troca o Token de ID pelo Identity Pool do Cognito para obter credenciais temporárias da AWS. Com essas credenciais, o frontend abre uma conexão WebSocket assinada com SigV4 para o AgentCore Runtime e envia o Token de Acesso como primeira mensagem para verificação de identidade. O agente valida o token chamando a API GetUser do Cognito, extrai o nome, e-mail e ID do cliente verificados, e inicializa o modelo Nova 2 Sonic com um prompt de sistema personalizado. A partir daí, o usuário fala seu pedido, o agente processa a entrada de voz, invoca ferramentas de forma assíncrona via MCP pelo AgentCore Gateway, e o Nova 2 Sonic gera uma resposta de voz contextual que é transmitida de volta ao usuário pela conexão WebSocket.

Gerenciamento de dados serverless e serviços de localização

O backend utiliza cinco tabelas no DynamoDB que suportam o fluxo completo de pedidos:

• Tabela de Clientes — armazena perfis com nome, e-mail, telefone, nível de fidelidade e pontos para recomendações personalizadas.
• Tabela de Pedidos — armazena o histórico de pedidos com dados de localização e usa um Índice Secundário Global para consultas por localização.
• Tabela de Cardápio — armazena itens específicos por localização com preços e disponibilidade variável por restaurante.
• Tabela de Carrinhos — armazena carrinhos de compras temporários com TTL de 24 horas para limpeza automática.
• Tabela de Localizações — armazena dados de restaurantes como coordenadas, horários e taxas para cálculos de pedidos e recomendações.

O AWS Location Services oferece três recursos implantados na solução: um Índice de Lugares (Esri) para geocodificação e busca de endereços, um Calculador de Rotas (Esri) para calcular rotas e tempos de desvio, e um Mapa (estilo VectorEsriNavigation) para visualização interativa. As funções Lambda fornecem três capacidades: busca do local mais próximo por GPS usando a fórmula haversine, busca baseada em rota identificando restaurantes dentro de um tempo de desvio especificado (padrão de 10 minutos), e geocodificação de endereços quando o GPS não está disponível. Isso permite recomendações contextuais como “encontrei um local a 2 minutos da sua rota”.

Processamento de voz com Amazon Bedrock AgentCore

O agente de IA processa interações de voz por meio do Amazon Bedrock AgentCore. Cada sessão de usuário roda em uma microVM isolada, mantendo as sessões seguras e com bom desempenho mesmo sob alta carga. O AgentCore oferece escalabilidade automática, monitoramento integrado e suporte a WebSocket para voz em tempo real. O agente usa o framework Strands para definir prompts de sistema, ferramentas e o fluxo da conversa.

O Amazon Nova 2 Sonic oferece as seguintes capacidades:

• Reconhecimento de fala em diferentes sotaques com tolerância a ruído de fundo
• Adaptação da resposta de voz ao tom e sentimento do usuário
• Streaming bidirecional com baixa latência
• Chamada assíncrona de ferramentas que busca dados em paralelo sem bloquear a conversa
• Tratamento de interrupções para turnos naturais de conversa
• Consciência de contexto ao longo de múltiplos turnos

O fluxo de processamento de voz funciona assim: o áudio é enviado pelo frontend (PCM a 16 kHz) via WebSocket para o AgentCore Runtime. O Nova 2 Sonic transcreve a fala, o agente determina a intenção e seleciona as ferramentas, invoca-as de forma assíncrona via MCP, e o AgentCore Gateway traduz as chamadas MCP em chamadas REST para a API Gateway. As funções Lambda executam a lógica de negócio e retornam os resultados, que o agente incorpora na resposta. O Nova 2 Sonic gera a saída de voz e a transmite de volta ao frontend.

Autenticação e fluxo de conexão WebSocket

A solução usa pools de usuários e pools de identidade do Amazon Cognito para controle de acesso seguro baseado em funções. Os usuários fazem login com usuário e senha no Pool de Usuários do Cognito, recebendo tokens JSON Web Token (JWT) — Token de Acesso e Token de ID. O frontend troca o Token de ID pelo Identity Pool do Cognito para obter credenciais temporárias da AWS (Chave de Acesso, Chave Secreta, Token de Sessão). Essas credenciais assinam a conexão WebSocket com o AgentCore Runtime e as requisições ao API Gateway usando Signature Version 4 (SigV4).

Com as credenciais temporárias, o frontend abre uma conexão WebSocket assinada com SigV4 diretamente para o AgentCore Runtime e envia o Token de Acesso para verificação de identidade. O navegador então transmite áudio PCM a 16 kHz e recebe respostas de voz, transcrições e notificações de invocação de ferramentas pela mesma conexão — sem necessidade de um proxy do lado do servidor.

Interação por voz e pedidos dinâmicos

O diagrama a seguir ilustra como uma consulta de pedido de um cliente é processada por chamada assíncrona de ferramentas. Quando o cliente diz “quero fazer um pedido”, o agente invoca múltiplas ferramentas em paralelo (GetCustomerProfile, GetPreviousOrders, GetMenu) pelo AgentCore Gateway, que as traduz em chamadas REST para o API Gateway. As funções Lambda consultam o DynamoDB e retornam os resultados de volta pelo gateway. O Nova 2 Sonic então gera uma resposta contextual incorporando todos os resultados das ferramentas, criando uma experiência personalizada ao longo da conversa.

Pré-requisitos e implantação

Antes de começar, é necessário ter em mãos:

• Uma conta AWS
• Acesso ao Modelo de Fundação (FM) Amazon Nova 2 Sonic no Amazon Bedrock na mesma região onde a solução será implantada
• Node.js 20.x ou superior (necessário para implantação com AWS CDK)
• Python 3.13 ou superior (necessário para o runtime do agente e scripts de implantação)
• Interface de Linha de Comando da AWS (AWS CLI) 2.x configurada com credenciais
• AWS CDK CLI 2.x: npm install -g aws-cdk
• CDK inicializado na conta/região de destino: npx cdk bootstrap
• Boto3 1.38.0 ou superior. Instale com: python3 -m pip install --upgrade boto3 botocore --break-system-packages
• Pacotes Python adicionais: python3 -m pip install email-validator pyyaml --break-system-packages
• O código do repositório aws-samples no GitHub

Passos de implantação

Clone o repositório GitHub e navegue até o diretório do projeto:

git clone https://github.com/aws-samples/sample-omnichannel-ordering-with-amazon-bedrock-agentcore-and-nova-sonic
cd sample-omnichannel-ordering-with-amazon-bedrock-agentcore-and-nova-sonic

Em seguida, execute o script de implantação. Ambos os parâmetros são obrigatórios — o endereço de e-mail receberá uma senha temporária para o usuário de teste inicial no Cognito:

./deploy-all.sh --user-email <seu-email> --user-name "<Seu Nome>"

O script executa verificações antes da implantação para validar Node.js, Python, AWS CLI, CDK, credenciais, bootstrap do CDK e acesso ao modelo Nova 2 Sonic no Bedrock. Se alguma verificação falhar, o script reporta o que está faltando e oferece instalar automaticamente o que for possível.

Após as verificações, o script executa cinco etapas. As etapas 1 a 3 são totalmente automatizadas. A etapa 4 (Dados Sintéticos) solicita uma localização como cidade, CEP ou endereço para usar como ponto central na busca de restaurantes próximos, um tipo de comida para buscar (ex: pizza, hambúrguer, café, sanduíche, tacos), se deseja reutilizar o mesmo endereço como residência do cliente, e uma confirmação antes de gravar os dados gerados no DynamoDB. A etapa 5 (Configuração de Senha) oferece a opção de alterar a senha temporária do Cognito enviada por e-mail.

Ao final, o script exibe a URL do frontend (ex: https://main.<app-id>.amplifyapp.com) para acessar a aplicação.

Experiência de pedido por voz

Ao abrir a URL do frontend no navegador e fazer login, o usuário aciona o botão de microfone para iniciar uma conversa por voz com o agente de pedidos. O agente cumprimenta o usuário pelo nome, obtém a localização pelo navegador e carrega os pedidos anteriores em segundo plano. É possível falar naturalmente: repetir um pedido anterior, navegar pelo cardápio, encontrar locais de retirada próximos à rota ou montar um pedido novo do zero. O agente responde por voz em tempo real, trata perguntas sobre o cardápio, adiciona itens ao carrinho e confirma o pedido com total e tempo estimado de retirada. Toda a conversa acontece sem usar as mãos, por uma única conexão WebSocket, e o agente chama as ferramentas de backend de forma assíncrona — sem pausas enquanto os dados são buscados.

Limpeza dos recursos

Para remover a solução e seus recursos associados, basta executar:

./cleanup-all.sh

Conclusão

A solução apresentada pela AWS demonstra como construir um sistema de pedidos omnichannel combinando Amazon Cognito para autenticação, Amazon Bedrock AgentCore para hospedagem do agente, API Gateway para comunicação de dados, DynamoDB para armazenamento e Location Services para otimização de rotas. A arquitetura em três camadas separa frontend, agente e backend para desenvolvimento e escalabilidade independentes.

O Amazon Nova 2 Sonic oferece interações de voz com baixa latência, chamada assíncrona de ferramentas e tratamento de interrupções. A chamada paralela de ferramentas reduz os tempos de espera, o reconhecimento de voz funciona em diferentes sotaques, as recomendações personalizadas usam o histórico de pedidos e os locais de retirada otimizados por rota ajudam os clientes a encontrar pontos convenientes. O modelo de precificação por uso e a escalabilidade automatizada controlam os custos conforme o uso cresce. Com a integração via MCP, é possível adaptar a solução adicionando novas funções Lambda sem modificar o código do agente.

O código está disponível no repositório no GitHub.

Recursos adicionais

• Apresentando o Amazon Nova 2 Sonic: novo modelo de fala para IA conversacional
• Primeiros passos com o Amazon Bedrock AgentCore
• Especificação do Model Context Protocol
• Documentação do AWS Location Services
• AgentCore CLI — ferramenta de linha de comando para criar, configurar, implantar e gerenciar agentes no Amazon Bedrock AgentCore

Fonte

Omnichannel ordering with Amazon Bedrock AgentCore and Amazon Nova 2 Sonic (https://aws.amazon.com/blogs/machine-learning/omnichannel-ordering-with-amazon-bedrock-agentcore-and-amazon-nova-2-sonic/)

Novas instâncias G7e chegam ao Amazon SageMaker AI

A AWS anunciou a disponibilidade das instâncias G7e no Amazon SageMaker AI, alimentadas pelas GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition. Essa novidade representa um salto relevante para quem precisa executar inferência de Modelos de Fundação (FMs) de grande porte com eficiência de custo.

As instâncias G7e estão disponíveis nas configurações de 1, 2, 4 e 8 GPUs, com cada GPU oferecendo 96 GB de memória GDDR7. O destaque prático é a possibilidade de hospedar modelos de linguagem de grande porte (LLMs) poderosos — como GPT-OSS-120B, Nemotron-3-Super-120B-A12B (variante NVFP4) e Qwen3.5-35B-A3B — em uma única instância de nó, o ml.g7e.2xlarge, sem necessidade de configurações multi-GPU.

O que muda em relação às gerações anteriores

Para entender o salto que as G7e representam, vale comparar as três gerações da família G da AWS na configuração de 8 GPUs:

• G5 (g5.48xlarge): 8x NVIDIA A10G, 24 GB GDDR6 por GPU, 192 GB de memória total, 600 GB/s de largura de banda por GPU, rede de 100 Gbps e 7,6 TB de armazenamento NVMe local.
• G6e (g6e.48xlarge): 8x NVIDIA L40S, 48 GB GDDR6 por GPU, 384 GB de memória total, 864 GB/s de largura de banda por GPU, rede de 400 Gbps e 7,6 TB de armazenamento NVMe local.
• G7e (g7e.48xlarge): 8x NVIDIA RTX PRO 6000 Blackwell, 96 GB GDDR7 por GPU, 768 GB de memória total, 1.597 GB/s de largura de banda por GPU, rede de 1.600 Gbps com EFA e 15,2 TB de armazenamento NVMe local.

Os principais destaques das G7e em relação à geração anterior incluem:

• O dobro de memória GPU em comparação com as G6e, permitindo o deployment de LLMs em FP16 com até 35 bilhões de parâmetros em um único nó GPU (g7e.2xlarge), 150 bilhões de parâmetros em 4 GPUs (g7e.24xlarge) e 300 bilhões de parâmetros em 8 GPUs (g7e.48xlarge).
• Até 1.600 Gbps de throughput de rede com Elastic Fabric Adapter (EFA) — um aumento de 4x sobre a G6e e 16x sobre a G5.
• Até 768 GB de memória GPU agregada na g7e.48xlarge.
• Desempenho de inferência até 2,3x superior em relação à G6e.

Com 768 GB de memória GPU agregada em uma única instância, a G7e consegue hospedar modelos que antes exigiam configurações multi-nó nas G5 ou G6e, reduzindo a complexidade operacional e a latência entre nós. Somado ao suporte à precisão FP4 com Tensor Cores de quinta geração e ao NVIDIA GPUDirect RDMA sobre EFAv4, as instâncias G7e se posicionam como a escolha principal para deployment de LLMs, IA multimodal e cargas de trabalho de inferência agêntica na AWS.

Casos de uso ideais para as instâncias G7e

A combinação de densidade de memória, largura de banda e capacidade de rede das G7e as torna adequadas para uma ampla gama de cargas de trabalho de IA generativa:

• Chatbots e IA conversacional: baixo Tempo para Primeiro Token (TTFT) e alto throughput mantêm experiências interativas responsivas mesmo sob carga concorrente elevada.
• Fluxos de trabalho agênticos e com chamada de ferramentas: a melhoria de 4x na largura de banda CPU-GPU torna a G7e especialmente eficaz para pipelines de Geração Aumentada por Recuperação (RAG) e fluxos agênticos, onde a injeção rápida de contexto a partir de repositórios de recuperação é crítica.
• Geração de texto, sumarização e inferência de contexto longo: os 96 GB de memória por GPU acomodam caches KV grandes para contextos de documentos extensos, reduzindo truncamentos e permitindo raciocínio mais rico sobre entradas longas.
• Geração de imagens e modelos de visão: onde instâncias anteriores encontravam erros de falta de memória em modelos multimodais maiores, a memória dobrada da G7e resolve essas limitações.
• IA física e computação científica: a computação da geração Blackwell, o suporte a FP4 e as capacidades de computação espacial (DLSS 4.0, RT cores de 4ª geração) estendem a aplicabilidade da G7e para gêmeos digitais, simulação 3D e inferência de modelos de IA física.

Como realizar o deployment

Pré-requisitos

Para experimentar a solução usando o SageMaker AI, são necessários os seguintes itens:

• Uma conta AWS que conterá todos os recursos.
• Uma função de Gerenciamento de Identidade e Acesso da AWS (IAM) para acessar o Amazon SageMaker AI. Para saber mais sobre como o IAM funciona com o SageMaker AI, consulte a documentação de Identidade e Gerenciamento de Acesso para o Amazon SageMaker AI.
• Acesso ao Amazon SageMaker Studio ou a uma instância de notebook do SageMaker, ou a um Ambiente de Desenvolvimento Integrado (IDE) como PyCharm ou Visual Studio Code. O SageMaker Studio é a opção recomendada para deployment e inferência simplificados.
• Cota para pelo menos uma instância ml.g7e.2xlarge para uso de endpoint do Amazon SageMaker AI. É possível solicitar aumento de cota pelo console de Cotas de Serviço.

Deployment

É possível clonar o repositório e utilizar o notebook de exemplo disponível neste repositório no GitHub.

Benchmarks de desempenho

Para quantificar a melhoria geracional, a AWS realizou benchmarks do modelo Qwen3-32B (BF16) nas instâncias G6e e G7e com a mesma carga de trabalho: aproximadamente 1.000 tokens de entrada e 560 tokens de saída por requisição — representativo de tarefas de sumarização ou correção de documentos. Ambas as configurações utilizam o contêiner nativo vLLM com cache de prefixo habilitado.

Linha de base G6e: ml.g6e.12xlarge (4x L40S, US$ 13,12/hora)

Com 4 GPUs L40S e grau de paralelismo tensorial 4, a G6e entrega throughput sólido por requisição: 37,1 tok/s em concorrência simples e 21,5 tok/s em C=32. O custo por milhão de tokens de saída nessa configuração vai de US$ 38,09 (C=1) a US$ 2,06 (C=32).

G7e: ml.g7e.2xlarge (1x RTX PRO 6000 Blackwell, US$ 4,20/hora)

A G7e executa o mesmo modelo de 32 bilhões de parâmetros em uma única GPU com grau de paralelismo tensorial 1. Embora o tok/s por requisição seja menor do que a configuração de 4 GPUs da G6e, a história de custo é dramaticamente diferente: o custo por milhão de tokens de saída vai de US$ 21,32 (C=1) a US$ 0,79 (C=32).

Em produção com concorrência C=32, a G7e alcança US$ 0,79 por milhão de tokens de saída, uma redução de custo de 2,6x em relação aos US$ 2,06 da G6e. Isso é impulsionado por dois fatores: a taxa horária significativamente menor da G7e (US$ 4,20 vs. US$ 13,12) e sua capacidade de manter throughput consistente sob carga.

A arquitetura de GPU única da G7e também escala de forma mais previsível. A latência aumenta 22% de C=1 a C=32 (de 27,2s para 33,2s), em comparação com 62% na G6e (de 16,1s para 26,0s). Com grau de paralelismo tensorial 1, não há overhead de sincronização entre GPUs, operações all-reduce a cada camada transformer, fragmentação de cache KV entre GPUs ou gargalos de comunicação NVLink. Para cargas de trabalho sensíveis à latência em baixa concorrência, o paralelismo de 4 GPUs da G6e ainda entrega respostas individuais mais rápidas. Para deployments em produção otimizando custo por token em escala, a G7e é a escolha clara.

Benchmarks combinados: G7e + decodificação especulativa EAGLE

As melhorias de hardware das G7e são significativas por si só, mas combiná-las com a decodificação especulativa EAGLE (Algoritmo de Extrapolação para Maior Eficiência de Modelos de Linguagem) produz ganhos compostos. O EAGLE acelera a decodificação de LLMs prevendo múltiplos tokens futuros a partir das próprias representações ocultas do modelo e, em seguida, verificando-os em um único passo forward. Isso produz qualidade de saída idêntica enquanto gera múltiplos tokens por etapa. Para um guia detalhado do EAGLE no SageMaker AI, consulte o post Amazon SageMaker AI apresenta decodificação especulativa adaptativa baseada em EAGLE para acelerar a inferência de IA generativa.

Os benchmarks foram realizados com Qwen3-32B em BF16, com o EAGLE3 habilitado usando um especulador treinado pela comunidade (~1,56 GB) com num_speculative_tokens=4.

G7e + EAGLE3 entrega uma melhoria de throughput de 2,4x e redução de custo de 75% sobre a linha de base da geração anterior. Com US$ 0,41 por milhão de tokens de saída, é também 4x mais barato que G6e + EAGLE3 (US$ 1,72), apesar de oferecer throughput superior.

O gráfico acima mostra como a G7e com GPU única (TP=1) mantém ganhos de speedup do EAGLE3 mais consistentes sob carga crescente em comparação com a G6e com 4 GPUs (TP=4). Enquanto a G6e cai de 2,3x para 1,2x de speedup entre C=1 e C=32, a G7e mantém de 2,6x para 1,9x no mesmo intervalo.

Para deployments em produção com modelos ajustados (fine-tuned), o toolkit de otimização EAGLE do SageMaker AI pode treinar cabeças EAGLE personalizadas com dados próprios, melhorando ainda mais a taxa de aceitação especulativa e o throughput além do que especuladores da comunidade proporcionam.

Preços

As instâncias G7e no Amazon SageMaker AI são cobradas com os preços padrão de inferência do SageMaker AI para o tipo de instância e duração de uso selecionados. Não há taxa adicional por token ou por requisição para servir na G7e.

Os jobs de otimização EAGLE são executados em instâncias de treinamento do SageMaker AI e cobrados pela taxa padrão de instância de treinamento pelo tempo de duração do job. Os artefatos do modelo otimizado resultante são armazenados no Amazon Simple Storage Service (Amazon S3) com as taxas de armazenamento padrão. Não há cobrança adicional pela inferência acelerada pelo EAGLE após o deployment do modelo otimizado — paga-se apenas o custo padrão da instância de endpoint.

A tabela a seguir apresenta os preços sob demanda para os principais tamanhos de instâncias G7e, G6e e G5 no Leste dos EUA (Norte da Virgínia) para referência:

• ml.g5.2xlarge: 1 GPU, 24 GB — LLMs pequenos (≤7B FP16); desenvolvimento e testes.
• ml.g5.48xlarge: 8 GPUs, 192 GB — Serving de LLMs grandes multi-GPU na G5.
• ml.g6e.2xlarge: 1 GPU, 48 GB — LLMs de médio porte (≤14B FP16).
• ml.g6e.12xlarge: 2 GPUs, 96 GB — LLMs grandes (≤36B FP16); linha de base da geração anterior.
• ml.g6e.48xlarge: 8 GPUs, 384 GB — LLMs muito grandes (≤90B FP16).
• ml.g7e.2xlarge: 1 GPU, 96 GB — LLMs grandes (≤70B FP8) em uma única GPU.
• ml.g7e.24xlarge: 4 GPUs, 384 GB — LLMs muito grandes; serving de alto throughput.
• ml.g7e.48xlarge: 8 GPUs, 768 GB — Throughput máximo; modelos de maior porte.

Também é possível reduzir os custos de inferência com os Amazon SageMaker Savings Plans, que oferecem descontos de até 64% em troca de um compromisso com um volume de uso consistente. Esses planos são adequados para endpoints de inferência em produção com tráfego previsível.

Limpeza de recursos

Para evitar cobranças desnecessárias após concluir os testes, é recomendado excluir os endpoints do SageMaker criados durante o processo. Isso pode ser feito pelo console do SageMaker AI ou com o SDK Python, conforme descrito no Guia do Desenvolvedor do Amazon SageMaker AI. Se um job de otimização EAGLE foi executado, também é recomendado excluir os artefatos de saída do Amazon S3 para evitar cobranças de armazenamento contínuas.

Conclusão

As instâncias G7e no Amazon SageMaker AI representam o próximo salto significativo em inferência de IA generativa com eficiência de custo. A arquitetura de GPU Blackwell entrega 2x de memória por GPU, 1,85x de largura de banda de memória e até 2,3x de desempenho de inferência sobre a G6e. Isso permite que cargas de trabalho que antes exigiam múltiplas GPUs sejam executadas eficientemente em uma única GPU, elevando o teto de throughput para cada configuração.

Combinados com a decodificação especulativa EAGLE do SageMaker AI, os ganhos se compõem ainda mais. A aceleração do EAGLE, limitada pela largura de banda de memória, se beneficia diretamente da maior largura de banda da G7e, enquanto a maior capacidade de memória da G7e permite que as cabeças de rascunho do EAGLE coexistam com modelos maiores sem pressão de memória. Juntas, as melhorias de hardware e software entregam ganhos de throughput que se traduzem diretamente em menor custo por token de saída em escala.

Fonte

Accelerate Generative AI Inference on Amazon SageMaker AI with G7e Instances (https://aws.amazon.com/blogs/machine-learning/accelerate-generative-ai-inference-on-amazon-sagemaker-ai-with-g7e-instances/)

Uma solução inteligente para renderização em nuvem

A AWS anunciou um novo assistente baseado em inteligência artificial para o Deadline Cloud, seu serviço gerenciado que simplifica a gestão de renderização para gráficos 2D/3D, efeitos visuais e conteúdo digital. Essa ferramenta foi desenvolvida para resolver um problema real enfrentado por produtoras de filmes, séries, comerciais, estúdios de games e empresas de design industrial: as falhas que interrompem pipelines de produção.

O desafio das falhas em renderização

Problemas que geram desperdício

Trabalhos de renderização podem falhar por diversos motivos: ativos digitais faltando, erros de software, configurações incompatíveis ou limitações de recursos. Quando isso acontece, não só a produção é interrompida como recursos computacionais são desperdiçados. Historicamente, diagnosticar essas falhas era um processo manual e demorado — especialistas técnicos precisavam analisar centenas de linhas de registros para identificar a causa raiz do problema.

Uma barreira para estúdios menores

Esse cenário criava uma barreira especialmente difícil para estúdios pequenos e médios que não possuem equipes técnicas dedicadas ou não conseguem escalar esse tipo de diagnóstico facilmente.

Como o assistente funciona

O novo assistente do Deadline Cloud investiga trabalhos que falharam, analisa registros e métricas, detecta problemas comuns e recomenda ações corretivas. A base de conhecimento do assistente foi treinada com informações sobre o Deadline Cloud, problemas típicos de render farms e aplicações populares de criação de conteúdo digital, incluindo Autodesk Maya, 3ds Max, VRED, Blender, SideFX Houdini, Maxon Cinema 4D, Foundry Nuke e Adobe After Effects.

Um diferencial importante: o assistente executa dentro da conta da AWS do usuário, utilizando o Amazon Bedrock, mantendo todos os dados e análises sob controle total da organização.

Disponibilidade

O assistente do Deadline Cloud está disponível a partir de agora em todas as regiões da AWS onde o Deadline Cloud é suportado. Para conhecer a ferramenta na prática, é possível assistir a uma demonstração em vídeo ou consultar a documentação do AWS Deadline Cloud para mais detalhes.

Fonte

AWS Deadline Cloud announces AI-powered troubleshooting assistant for render jobs (https://aws.amazon.com/about-aws/whats-new/2026/04/deadline-cloud-ai-troubleshooting/)

Por que a busca semântica em vídeos importa

A demanda por experiências centradas em vídeo está transformando a forma como as organizações entregam conteúdo. Usuários esperam encontrar rapidamente momentos específicos dentro de arquivos de vídeo, e as indústrias de mídia estão enfrentando desafios reais para atender essa expectativa.

Transmissoras de esportes precisam identificar o exato instante em que um jogador marca um gol para disponibilizar o destaque aos fãs instantaneamente. Estúdios de cinema buscam cada cena que apresenta um ator específico ao longo de milhares de horas de arquivo para criar trailers personalizados. Agências de notícias recuperam vídeos por estado emocional, localização ou tipo de evento para publicar reportagens antes dos concorrentes. O denominador comum é claro: entregar conteúdo de vídeo aos usuários rapidamente, capturar o momento certo e monetizar a experiência.

O desafio fundamental reside na complexidade inerente ao vídeo. Diferentemente de texto ou imagens isoladas, um arquivo de vídeo combina múltiplos sinais não estruturados simultaneamente: a cena visual que se desenrola, o áudio ambiente, efeitos sonoros, diálogos, informações temporais e metadados estruturados descrevendo o ativo.

Uma busca por “perseguição de carro com sirenes” envolve tanto um evento visual quanto um evento de áudio. Uma busca por um atleta específico pelo nome pode retornar alguém que aparece de forma proeminente na tela, mas nunca é mencionado na fala. Converter vídeo em texto inevitavelmente perde informações críticas: contexto temporal desaparece e erros de transcrição emergem de problemas de qualidade visual e áudio.

A abordagem inovadora: Embeddings Multimodais do Amazon Nova

A AWS apresentou os Embeddings Multimodais do Amazon Nova, um modelo de embedding unificado que processa nativamente texto, documentos, imagens, vídeo e áudio em um espaço vetorial semântico compartilhado. O modelo oferece precisão de recuperação líder da indústria com eficiência de custo notável.

Diferentemente de abordagens tradicionais que mapeiam todos os sinais de vídeo em texto antes da busca, esse modelo multimodal processa todos os sinais simultaneamente sem perder detalhes essenciais. A solução construída sobre o Amazon Bedrock demonstra como integrar embeddings multimodais com uma arquitetura híbrida inteligente que funde sinais semânticos e lexicais em todos os tipos de mídia do vídeo.

Arquitetura da solução

A solução foi desenvolvida em duas fases distintas: um pipeline de ingestão que converte vídeo em embeddings pesquisáveis, e um pipeline de busca que roteia consultas de usuários inteligentemente entre essas representações.

Pipeline de ingestão

O fluxo de ingestão segue seis etapas principais. Primeiro, vídeos enviados via navegador são armazenados no Amazon DynamoDB para rastreamento de status enquanto um pipeline do AWS Step Functions é iniciado através de um orquestrador em AWS Lambda.

Na etapa de segmentação, o AWS Fargate utiliza detecção de cenas com FFmpeg para dividir o vídeo em segmentos semanticamente coerentes. Três branches paralelos então processam cada segmento: embeddings visuais e de áudio são gerados e armazenados, Amazon Transcribe converte fala em texto, e Amazon Rekognition identifica celebridades.

O Amazon Nova 2 Lite sintetiza legendas em nível de segmento e rótulos de gênero. Uma função Lambda monta todos os metadados e recupera os embeddings do Amazon S3 Vectors. Os documentos completos de segmento, com metadados e vetores, são então indexados em massa no Amazon OpenSearch Service.

Pipeline de consulta

Usuários autenticam através do Amazon Cognito e acessam a interface pela Amazon CloudFront. O Amazon API Gateway roteia requisições para uma função Lambda de busca, que executa duas operações paralelas.

A análise de intenção utiliza Amazon Bedrock com Anthropic Claude Haiku para atribuir pesos de relevância entre os canais visual, áudio, transcrição e metadados. Simultaneamente, os Embeddings Multimodais do Amazon Nova processam a consulta três vezes para correspondência de similaridade visual, áudio e transcrição.

Decisões de design críticas

Segmentação semântica para continuidade de contexto

Antes de gerar qualquer embedding, o vídeo deve ser dividido em unidades pesquisáveis, e as fronteiras traçadas impactam diretamente a precisão da busca. Cada segmento se torna a unidade atômica de recuperação.

Segmentos muito curtos perdem o contexto circundante que confere significado a um momento. Segmentos muito longos fundem múltiplos tópicos ou cenas, diluindo a relevância. Blocos de comprimento fixo são diretos de produzir, mas ignoram a estrutura natural do conteúdo—uma transição de cena no meio de um segmento divide uma ideia visual entre dois chunks.

A solução usa detecção de cenas do FFmpeg para identificar onde o conteúdo visual realmente muda. O framework FFmpeg é amplamente utilizado para processamento de vídeo, conversão de formatos e análise. A função de detecção retorna timestamps marcando limites naturais de cena. O algoritmo de segmentação então alinha cada corte ao limite de cena mais próximo dentro de uma janela aceitável, buscando aproximadamente dez segundos com mínimo de cinco e máximo de quinze segundos.

O resultado são segmentos que soam naturais—oito a doze segundos cada—alinhados a transições visuais reais em vez de divisões arbitrárias. Essa abordagem simples baseada em cenas garante que limites de segmento correspondam a transições visuais naturais.

Embeddings separados para sinais visuais, de áudio e transcrição

Com segmentos definidos, a escolha do modelo de embedding é onde a maior lacuna de qualidade emerge. A abordagem dominante atualmente fundamenta todos os sinais de vídeo em texto antes de gerar embeddings. Enquanto isso funciona para conteúdo repleto de diálogos, converter vídeo em texto inevitavelmente perde informações críticas.

Os Embeddings Multimodais do Amazon Nova mudam isso fundamentalmente porque é um modelo nativo de vídeo que pode gerar embeddings em dois modos. O modo combinado funde sinais visual e de áudio em uma representação unificada, capturando os sinais mais importantes juntos. Essa abordagem beneficia custo de armazenamento e latência de recuperação ao exigir apenas um embedding por segmento.

Alternativamente, o modo AUDIO_VIDEO_SEPARATE gera embeddings visuais e de áudio distintos. Essa abordagem oferece máxima representação em embeddings específicos da modalidade e oferece melhor controle sobre quando buscar conteúdo visual versus conteúdo de áudio. A implementação adicionou até um terceiro embedding de fala derivado do Amazon Transcribe.

Os três embeddings cobrem o espaço completo de sinais de um segmento de vídeo. O embedding visual captura o que a câmera vê: objetos, cenas, ações, cores e composição espacial. O embedding de áudio captura o que o microfone ouve: música, efeitos sonoros, ruído ambiente e textura acústica. O embedding de transcrição captura o que as pessoas dizem, representando o significado semântico da fala e narração.

Busca híbrida combinando metadados e embeddings

Mesmo com três embeddings independentes cobrindo conteúdo visual, áudio e falado, existe uma classe de consultas que o sistema não pode responder bem. Embeddings são projetados para capturar similaridade semântica. Eles excelem em encontrar um “momento de multidão tensa” ou um “pôr do sol sobre a água” porque são conceitos com significado visual e áudio rico.

Mas quando um usuário busca por um nome específico, número de modelo de produto, geolocalização ou data particular, embeddings provavelmente falharão. Essas são entidades discretas com poucos sinais semânticos próprios. Aqui entra a busca híbrida. Em vez de confiar apenas em embeddings, o sistema executa dois caminhos de recuperação paralelos: um caminho semântico que corresponde aos embeddings visuais, de áudio e transcrição para capturar similaridade conceitual, e um caminho lexical que realiza correspondência exata de palavra-chave e entidade contra metadados estruturados.

A quantidade de metadados necessária depende do tipo de conteúdo, organização e caso de uso. Para a implementação, foram selecionadas categorias representando tipos comuns em mídia e entretenimento: título de vídeo e datetime (metadados técnicos), legendas de segmento, gênero e reconhecimento de celebridades (metadados contextuais). As legendas são geradas a partir do vídeo e transcrição de cada segmento. O gênero é previsto a partir da transcrição completa de vídeo. Identificação de celebridades é tratada pelo Amazon Rekognition.

Roteamento de consulta consciente de intenção

Com três embeddings e metadados, há quatro dimensões pesquisáveis. Mas como saber qual usar para uma consulta fornecida? A intenção é tudo. Para resolver isso, foi construído um roteador de análise de intenção que usa o modelo Haiku para analisar cada consulta e atribuir peso a cada canal de modalidade: visual, áudio, transcrição e metadados.

O modelo Haiku recebe uma consulta e retorna um objeto JSON com pesos que somam um, junto com um breve rastreamento explicando a atribuição. Os pesos controlam diretamente quais sub-consultas executam. Qualquer modalidade abaixo do limiar de cinco por cento é completamente ignorada, eliminando chamadas de API de embedding desnecessárias e reduzindo latência sem sacrificar precisão.

Os canais restantes executam em paralelo, cada um buscando seu próprio índice independentemente. Resultados de todos os canais ativos são então pontuados usando uma média aritmética ponderada. As pontuações BM25 (uma medida de relevância lexical baseada em frequência de termo e comprimento de documento) e pontuações de similaridade de cosseno (uma medida geométrica de quão proximamente dois vetores de embedding apontam na mesma direção) existem em escalas muito diferentes. Para resolver isso, cada pontuação de sub-consulta é primeiro normalizada para um intervalo de zero a um, depois combinada usando os pesos de intenção do roteador.

Estratégia de armazenamento para vetores e metadados

A decisão final de design é onde e como armazenar tudo isso. Cada segmento de vídeo produz até três embeddings e um conjunto de campos de metadados, e como eles são armazenados determina tanto o desempenho de busca quanto o custo em escala.

A solução divide isso entre dois serviços com papéis complementares: Amazon S3 Vectors para armazenamento de vetores e Amazon OpenSearch Service para busca híbrida. O S3 Vectors armazena três índices de vetores por projeto, um para cada tipo de embedding: visual, áudio e transcrição. O OpenSearch contém um índice por projeto, onde cada documento representa um único segmento de vídeo contendo campos de texto para busca BM25 e campos de vetor para busca de k-vizinhos mais próximos.

O S3 Vectors foi escolhido pelos benefícios de custo-performance. O Amazon S3 Vectors reduz o custo de armazenamento e consulta de vetores em até noventa por cento comparado a soluções especializadas alternativas. Se latência de busca não é crítica para o caso de uso, S3 Vectors é uma escolha padrão forte. Se a menor latência possível é necessária, recomenda-se usar vetores em memória com o mecanismo Hierarchical Navigable Small World (HNSW) do OpenSearch.

Vale ressaltar que alguns casos de uso requerem busca dentro de segmentos de vídeo mais longos e semanticamente densos, como uma entrevista completa, uma cena documentária de vários minutos ou uma demonstração de produto estendida. A maioria dos modelos de embedding multimodal, incluindo os Embeddings Multimodais do Amazon Nova, tem duração máxima de entrada de trinta segundos. O suporte de vetor aninhado no OpenSearch resolve isso permitindo que um único documento contenha múltiplos embeddings de sub-segmentos.

Resultados de desempenho

Para validar as decisões de design, a abordagem híbrida otimizada foi comparada com a linha de base do modo AUDIO_VIDEO_COMBINED dos Embeddings Multimodais do Amazon Nova. A comparação usou dez vídeos long-form internos (cinco a vinte minutos) avaliados em vinte consultas abrangendo buscas focadas em visual, áudio, transcrição e metadados.

A linha de base usa um único vetor unificado por segmento de dez segundos com um índice e uma consulta de k-vizinhos mais próximos. A abordagem otimizada gera embeddings visual, áudio e transcrição separados, enriquece segmentos com metadados estruturados e aplica roteamento consciente de intenção que pondera dinamicamente canais de modalidade.

Os resultados mostram melhorias substanciais em todas as métricas de recuperação. A busca híbrida atingiu Recall@5 e Recall@10 acima de noventa por cento versus cinquenta e um e sessenta e quatro por cento para a linha de base—um ganho de cerca de quarenta pontos percentuais em precisão de cobertura. Mean Reciprocal Rank saltou de quarenta e oito para noventa por cento, e NDCG@10 subiu de cinquenta e quatro para oitenta e oito por cento. Esses ganhos de trinta a quarenta pontos percentuais validam as decisões arquiteturais centrais: segmentação semântica preserva continuidade de conteúdo, embeddings separados oferecem controle preciso de busca, enriquecimento de metadados captura entidades factuais, e roteamento consciente de intenção garante que os sinais certos direcionem cada consulta.

Implementação prática

Uma implementação de referência completa está disponível no GitHub, permitindo seguir o passo a passo e ver como cada decisão contribui para busca precisa e escalável entre todos os tipos de sinais.

Para evitar incurrer em futuras cobranças, os recursos usados na solução podem ser deletados removendo a stack do AWS CloudFormation. Comandos detalhados estão disponíveis no repositório GitHub.

Próximos passos e otimizações

Mais otimizações podem ser realizadas para afinar ainda mais a precisão de busca, incluindo personalização de modelo para a camada de roteamento de intenção. Recomenda-se ler a Parte 2 para aprofundar essas técnicas.

Para uma implementação pronta para produção desta técnica de busca semântica de vídeo e gerenciamento de metadados em escala, consulte a Orientação para um Media Lake na AWS.

Considerações finais

A solução de busca semântica em vídeo construída sobre os Embeddings Multimodais do Amazon Nova demonstra como transformar um conjunto fragmentado de sinais em uma experiência de busca unificada e precisa que compreende vídeo. Ao manter contexto temporal, processar embeddings separados para cada modalidade, enriquecer com metadados estruturados e aplicar roteamento inteligente baseado em intenção, as organizações podem escalar de forma eficiente entre arquivos de vídeo massivos mantendo precisão de recuperação.

Essa abordagem abre possibilidades para transmissoras de esportes, estúdios de cinema, agências de notícias e qualquer organização que necessite encontrar rapidamente momentos específicos dentro de conteúdo de vídeo—capturando o momento, entregando aos usuários e monetizando a experiência.

Fonte

Power video semantic search with Amazon Nova Multimodal Embeddings (https://aws.amazon.com/blogs/machine-learning/power-video-semantic-search-with-amazon-nova-multimodal-embeddings/)

Balanceando Precisão, Custo e Latência em Buscas de Vídeo

Otimizar modelos para busca semântica de vídeos apresenta um dilema clássico em machine learning: modelos menores e rápidos carecem de inteligência de roteamento, enquanto modelos maiores e mais precisos adicionam latência significativa. A AWS, por meio de seu portfólio de serviços de inteligência artificial, oferece agora uma solução que permite alcançar os três objetivos simultaneamente.

Em um artigo anterior da série, foi apresentado como construir um sistema de busca semântica multimodal em vídeos utilizando roteamento inteligente de intenções com o modelo Anthropic Claude Haiku no Amazon Bedrock. Embora o modelo Haiku entreguasse forte precisão para interpretar intenções de busca, aumentava o tempo total de processamento para 2 a 4 segundos, representando aproximadamente 75% da latência geral.

O cenário fica ainda mais desafiador quando a lógica de roteamento se torna mais complexa. Metadados empresariais costumam ir muito além dos cinco atributos simples (título, legenda, pessoas, gênero e timestamp), incluindo ângulos de câmera, sentimentos, janelas de direitos e licenças, além de taxonomias específicas de domínio. Prompts mais sofisticados exigem modelos maiores, que aumentam custos e latência de forma desproporcional.

A Solução: Destilação de Modelos

Em vez de escolher entre um modelo rápido mas superficial ou um modelo preciso mas custoso, a destilação de modelos — uma técnica de personalização disponível no Amazon Bedrock — permite treinar um modelo pequeno para realizar tarefas complexas com latência e custo significativamente reduzidos.

O processo envolve transferir inteligência de um modelo professor (Amazon Nova Premier, o mais capaz da família) para um modelo aluno (Amazon Nova Micro, otimizado para alta vazão). Essa abordagem reduz custos de inferência em mais de 95% e latência em 50%, mantendo a qualidade de roteamento exigida por sistemas de produção.

Arquitetura da Solução Passo a Passo

1. Preparação de Dados de Treinamento

Uma das principais vantagens da destilação sobre outras técnicas como ajuste fino supervisionado (SFT) é que não requer um conjunto de dados completamente rotulado. No SFT, cada exemplo precisa de respostas geradas por humanos. Na destilação, você precisa apenas de prompts — o Amazon Bedrock invoca automaticamente o modelo professor para gerar respostas de alta qualidade.

A plataforma aplica técnicas de síntese e aumento de dados para produzir um conjunto de treinamento diverso contendo até 15 mil pares prompt-resposta. Para este exemplo, foram preparados 10 mil exemplos sintéticos com o Nova Premier, distribuídos uniformemente entre consultas de sinais visuais, áudio, transcrição e metadados, cobrindo o intervalo completo de entradas esperadas.

Cada registro segue o esquema bedrock-conversation-2024, onde a função usuário (prompt de entrada) é obrigatória e a função assistente (resposta desejada) é opcional. Um exemplo prático:

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{
    "text": "Return JSON with visual, audio, transcription, metadata weights (sum=1.0) and reasoning for the given video search query."
  }],
  "messages": [
    {
      "role": "user",
      "content": [{
        "text": "Olivia talking about growing up in poverty"
      }]
    },
    {
      "role": "assistant",
      "content": [{
        "text": "{\"visual\": 0.2, \"audio\": 0.1, \"transcription\": 0.6, \"metadata\": 0.1, \"reasoning\": \"The query focuses on spoken content ('talking about'), making transcription most important. Visual and audio elements are secondary since they support the context, while metadata is minimal.\"}"
      }]
    }
  ]
}

Para adaptar a distribuição a domínios específicos, está disponível um script de geração de dados que permite criar mais exemplos sintéticos usando o Nova Premier.

2. Executando o Trabalho de Destilação

Com os dados de treinamento no Amazon Simple Storage Service (Amazon S3), o próximo passo é submeter o trabalho de destilação. O processo utiliza os prompts para gerar respostas do modelo professor, então usa esses pares para ajustar o modelo aluno. O Amazon Bedrock gerencia toda a orquestração e infraestrutura automaticamente — não há cluster para provisionar, hiperparâmetros para ajustar ou pipelines complexos para configurar.

Você especifica o modelo professor, o modelo aluno, o caminho S3 dos dados e uma função de Controle de Acesso à Identidade (IAM – Identity and Access Management). O resto é gerenciado pela plataforma. Veja um exemplo de código:

import boto3
from datetime import datetime

bedrock_client = boto3.client(service_name="bedrock")

teacher_model = "us.amazon.nova-premier-v1:0"
student_model = "amazon.nova-micro-v1:0:128k"
job_name = f"video-search-distillation-{datetime.now().strftime('%Y-%m-%d-%H-%M-%S')}"
model_name = "nova-micro-video-router-v1"

response = bedrock_client.create_model_customization_job(
    jobName=job_name,
    customModelName=model_name,
    roleArn=distillation_role_arn,
    baseModelIdentifier=student_model,
    customizationType="DISTILLATION",
    trainingDataConfig={"s3Uri": training_s3_uri},
    outputDataConfig={"s3Uri": output_s3_uri},
    customizationConfig={
        "distillationConfig": {
            "teacherModelConfig": {
                "teacherModelIdentifier": teacher_model,
                "maxResponseLengthForInference": 1000
            }
        }
    }
)

job_arn = response['jobArn']

O trabalho executa de forma assíncrona. Para 10 mil exemplos com o Nova Micro, esperase conclusão em poucas horas.

3. Implantando o Modelo Destilado

Após a conclusão, o modelo personalizado fica disponível e pronto para implantação. O Amazon Bedrock oferece duas opções: Throughput Provisionado para cargas de trabalho previsíveis e de alto volume, ou Inferência sob Demanda para acesso flexível com pagamento por uso. Para equipes começando, a inferência sob demanda é a recomendada — sem endpoints para provisionar, sem compromissos horários e sem requisitos de uso mínimo.

Uma vez com status “InService”, o modelo pode ser invocado usando as APIs padrão InvokeModel ou Converse. Você paga apenas pelos tokens consumidos, aos custos do Nova Micro: $0,000035 por 1 mil tokens de entrada e $0,000140 por 1 mil tokens de saída.

import boto3
import json

bedrock_runtime = boto3.client(service_name="bedrock-runtime")

custom_model_arn = bedrock_client.get_model_customization_job(
    jobIdentifier=job_arn
)['outputModelArn']

response = bedrock_runtime.converse(
    modelId=custom_model_arn,
    messages=[
        {
            "role": "user",
            "content": [{"text": query}]
        }
    ]
)

routing_weights = json.loads(
    response['output']['message']['content'][0]['text']
)
print(routing_weights)
# {"visual": 0.7, "audio": 0.1, "transcription": 0.1, "metadata": 0.1}

Avaliação e Resultados

Qualidade de Roteamento

Antes de comparar com o roteador original, é importante validar que a destilação melhorou a capacidade do modelo base. O modelo Nova Micro destilado demonstrou formato JSON consistente com pesos numéricos que somam 1,0, enquanto a versão base produzia respostas em texto livre, JSON incompleto e valores de peso não-numéricos.

Para uma consulta sobre “CEO discutindo resultados trimestrais”, o modelo destilado retornou pesos apropriados com raciocínio específico, enquanto a versão base lutava com inconsistências de formato e lógica genérica.

Comparação com o Baseline Original

Ambos os modelos foram avaliados contra um conjunto de 100 exemplos de teste usando a Avaliação de Modelos do Amazon Bedrock. Foi definida uma rubrica personalizada de “Qualidade Geral” que instrui o Claude Sonnet a avaliar cada predição em duas dimensões: precisão dos pesos comparados à verdade esperada e qualidade do raciocínio.

O modelo Nova Micro destilado alcançou pontuação 4,0 em 5, praticamente idêntica ao Claude 4.5 Haiku mas com latência aproximadamente 50% menor (833ms versus 1.741ms). A vantagem de custo é ainda mais dramática: redução de mais de 95% tanto em tokens de entrada quanto de saída, sem compromissos antecipados.

Resumo comparativo de métricas:

• Pontuação LLM-as-judge: Nova Micro destilado (4,0/5) versus Claude 4.5 Haiku (4,0/5)
• Latência média: Nova Micro destilado (833ms) versus Claude 4.5 Haiku (1.741ms)
• Custo por 1k tokens entrada: Nova Micro destilado ($0,000035) versus Claude 4.5 Haiku ($0,80–$1,00)
• Custo por 1k tokens saída: Nova Micro destilado ($0,000140) versus Claude 4.5 Haiku ($4,00–$5,00)
• Consistência de formato: Nova Micro destilado (JSON consistente) versus Claude 4.5 Haiku (inconsistente)

Implementação Completa e Recursos

Para explorar a implementação completa, incluindo notebook, script de geração de dados de treinamento e utilitários de avaliação, visite o repositório GitHub. Lá você encontrará todos os componentes necessários para replicar a solução em seu ambiente.

Para não gerar cobranças contínuas, execute a seção de limpeza do notebook para remover recursos provisionados, incluindo endpoints de modelo implantados e dados armazenados no Amazon S3.

Conclusão

Este artigo encerra uma série de dois posts. A destilação de modelos oferece um caminho prático para alcançar eficiência de custo em produção sem sacrificar precisão de busca. Ao transferir comportamento de roteamento do Nova Premier para o Nova Micro usando destilação, reduz-se custo de inferência em mais de 95% e latência de pré-processamento pela metade, preservando a qualidade de roteamento necessária.

Para equipes operando busca de vídeo multimodal em larga escala, a destilação de modelos é um caminho consolidado para produção, balanceando inteligência de roteamento com velocidade e custo ao mesmo tempo. Para mergulhar na implementação, consulte o repositório GitHub e experimente a solução.

Fonte

Optimize video semantic search intent with Amazon Nova Model Distillation on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/optimize-video-semantic-search-intent-with-amazon-nova-model-distillation-on-amazon-bedrock/)