Amazon MLA-C01: Implantação e Inferência de Modelos — Guia de estudos

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

Faz parte do AWS Machine Learning Engineer Associate MLA-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Endpoints em tempo real, sem servidor (serverless), assíncronos e em lote — conceito principal

A inferência em tempo real no Amazon SageMaker é um modelo de serviço stateful e de baixa latência no qual você cria um Model, um EndpointConfig e um Endpoint que aloca recursos computacionais provisionados (tipos de instância ml.*) e permanece disponível para atender a requisições por meio da API InvokeEndpoint. O CreateEndpointConfig aceita ProductionVariants, e cada ProductionVariant define ModelName, InitialInstanceCount, InstanceType e InitialVariantWeight; você pode alterar o tráfego e a capacidade com UpdateEndpointWeightsAndCapacities ou UpdateEndpoint. Para necessidades de baixa latência previsível, os endpoints provisionados em tempo real são a opção principal e suportam pipelines de inferência de múltiplos contêineres para encadear contêineres de pré-processamento, modelo e pós-processamento.

A Serverless Inference elimina o gerenciamento de instâncias e é configurada no nível do endpoint com um ServerlessConfig que especifica MemorySizeInMB e MaxConcurrency para cada ProductionVariant; o SageMaker gerencia o provisionamento de contêineres e escala a zero quando ocioso, tornando-o ideal para cargas de trabalho com picos e de baixa vazão. A Asynchronous Inference é otimizada para requisições que levam muito tempo para serem executadas ou onde o cliente não exige uma resposta síncrona. Um endpoint assíncrono é criado com AsyncInferenceConfig no CreateEndpointConfig (OutputConfig com S3OutputPath, ClientConfig opcional e MaxConcurrentInvocationsPerInstance) e os clientes chamam InvokeEndpointAsync, fornecendo um URI de entrada do S3; os resultados são gravados no local de saída do S3 configurado. O Batch Transform é um tipo de job separado (CreateTransformJob) para grandes cargas de trabalho de inferência offline; a API exige TransformInput (S3DataSource com S3Uri e S3DataType), TransformOutput (S3OutputPath, Accept, AssembleWith) e TransformResources (InstanceType, InstanceCount). O Batch Transform é ideal quando a vazão é importante, mas a latência não, e ele suporta grande paralelismo entre conjuntos de dados.

Endpoints de múltiplos modelos, pipelines de inferência, shadowing e testes A/B — serviços e configurações principais

Ao hospedar muitos modelos com baixo QPS (consultas por segundo) por modelo, os SageMaker Multi-Model Endpoints (MME) permitem que um único contêiner hospede de dezenas a milhares de artefatos de modelo armazenados no S3 e os carregue sob demanda. Você constrói um contêiner de servidor de modelo que implementa o padrão de servidor de múltiplos modelos do SageMaker ou usa uma imagem de framework compatível, faz o upload dos arquivos tarball do modelo para o S3 e cria um recurso Model que referencia o contêiner. No momento da invocação, você passa o nome do modelo de destino por meio do parâmetro TargetModel da API InvokeEndpoint (ou do cabeçalho X-Amzn-SageMaker-Target-Model) para que o servidor carregue esse modelo do S3 para a memória. Os MMEs economizam memória e custo operacional para grandes frotas de modelos, mas adicionam latência de carregamento a frio (cold-load) para modelos que ainda não estão residentes no ambiente de execução.

Os pipelines de inferência são implementados como modelos de múltiplos contêineres, onde o recurso Model lista os Containers em ordem; o endpoint roteia as cargas (payloads) através do primeiro contêiner (pré-processamento), depois o contêiner do modelo e, em seguida, o contêiner de pós-processamento. Defina cada contêiner com seu próprio ModelDataUrl e variáveis de ambiente no CreateModel. Para testes no estilo canário ou blue/green, use múltiplos ProductionVariants em um EndpointConfig e controle a divisão do tráfego com InitialVariantWeight e, posteriormente, por meio de UpdateEndpointWeightsAndCapacities. Uma implantação sombra (shadow deployment) pode ser alcançada enviando uma cópia de cada requisição na camada de aplicação para um endpoint sombra (sem peso de tráfego no endpoint de produção) ou criando um ProductionVariant com um peso baixo para que a infraestrutura do endpoint receba algum tráfego espelhado; a duplicação de requisições na camada de aplicação oferece isolamento total do experimento e observabilidade independente.

Para monitoramento contínuo e sob demanda, configure o DataCaptureConfig ao criar um endpoint para persistir as cargas (payloads) de requisição e resposta no S3. Os campos de interesse do DataCaptureConfig incluem EnableCapture (true), InitialSamplingPercentage, DestinationS3Uri e CaptureOptions (REQUEST, RESPONSE). Os dados capturados se tornam a base para as verificações pós-implantação do SageMaker Model Monitor e do SageMaker Clarify; você pode criar linhas de base (baselines) com o CreateMonitoringSchedule do Model Monitor e executar jobs de Processamento ad-hoc que usam o contêiner integrado de monitoramento de modelo para calcular restrições (constraints) e métricas de desvio (drift).

Padrões de design e trade-offs

Opte por endpoints provisionados em tempo real quando precisar de latência de um dígito a dois dígitos baixos de milissegundos e puder arcar com a capacidade sempre ativa. Se o custo por minuto em inatividade for a restrição dominante e o tráfego for intermitente, os endpoints serverless reduzem as operações: configure

undefined

para cada variante e deixe o SageMaker escalar automaticamente. Para workloads com inferências de longa duração ou padrões de troca de payloads pesados, os endpoints assíncronos desacoplam o ciclo de vida do cliente da computação; eles exigem o S3 para entradas/saídas e são mais apropriados quando os clientes podem fazer polling ou receber notificações do S3 para a conclusão.

Endpoints de múltiplos modelos (multi-model endpoints) reduzem a duplicação de memória e a complexidade do gerenciamento de objetos no S3, mas adicionam latência de cold-start por modelo e exigem um servidor de modelo capaz de carregar sob demanda do S3 e gerenciar o ciclo de vida adequadamente (eviction/LRU). Se a latência por modelo for crítica, hospede os modelos “quentes” (hot models) em ProductionVariants dedicados e descarregue os modelos de baixo tráfego para um MME. Pipelines de inferência centralizam a lógica de pré-processamento e pós-processamento mais perto do modelo, reduzindo o código do lado do cliente e garantindo uma transformação consistente entre treinamento e inferência, mas aumentam a complexidade de inicialização do endpoint e exigem um design robusto de contrato de contêiner (codecs de entrada/saída e tipos de conteúdo).

O teste A/B usando os pesos do ProductionVariant é direto para a divisão de tráfego e coleta de métricas offline, mas quando você deseja espelhar o tráfego (shadow traffic) sem afetar as métricas de produção, prefira o espelhamento no nível da aplicação. Para rollouts progressivos e automação de rollback, integre o

undefined

em um fluxo de trabalho do CodePipeline ou Step Functions que inclua avaliação automática de métricas usando métricas do CloudWatch, alertas do Model Monitor e uma ação de aprovação manual que controla a promoção final.

Armadilhas comuns e critérios de decisão

Um erro operacional comum é assumir que o Model Monitor detectará problemas de disponibilidade de rótulos; o Model Monitor pode detectar desvio na distribuição de features e violações de qualidade de dados a partir das requisições capturadas, mas para medir a degradação de métricas baseadas em rótulos (F1, recall), você deve entregar os rótulos de ground-truth de volta ao S3 em um formato que os jobs de monitoramento possam consumir e agendar um job de monitoramento que calcule a predição vs. a verdade. Outra armadilha é falhar em dimensionar o ServerlessConfig.MemorySizeInMB adequadamente; memória subprovisionada causa throttling ou falhas no contêiner, enquanto o superprovisionamento aumenta o custo. Para endpoints de múltiplos modelos, negligenciar a configuração apropriada do layout e do ciclo de vida dos objetos S3 (prefixos, manifestos de modelo) torna os carregamentos a frio (cold loads) mais lentos e complica as políticas de evicção.

Ao lidar com desbalanceamento de classes para detecção de fraude, prefira a ponderação nativa do algoritmo em vez de pipelines de amostragem pesados para uma sobrecarga operacional mínima; por exemplo, o XGBoost (contêiner SageMaker XGBoost) suporta o hiperparâmetro ‘scale_pos_weight’, que você calcula como exemplos_negativos/exemplos_positivos e passa através do mapa de hiperparâmetros na chamada CreateTrainingJob. Para o controle manual de implantação, use o SageMaker Model Registry: crie um ModelPackageGroup, chame CreateModelPackage para registrar um pacote de modelo e defina o status do pacote de modelo como PendingManualApproval; uma ação de aprovação manual externa do CodePipeline ou uma confirmação manual via Step Functions + SNS pode então chamar UpdateModelPackage para definir ApprovalStatus = "Approved" antes que CreateModel ou CreateEndpoint sejam executados.

Problema Prático: Cenário de Caso de Uso

A FraudDetectCo está construindo um sistema de detecção de fraudes online que deve consolidar logs de transação no S3 e tabelas de perfil de cliente em um MySQL on-premise, treinar um modelo XGBoost, implantá-lo com latência próxima de tempo real, impor um portão de aprovação manual para liberações em produção e detectar tanto anomalias no conjunto de dados quanto desvio do modelo sob demanda.

Agregação e pré-processamento de dados: use o AWS Database Migration Service (DMS) ou o conector JDBC do AWS Glue para replicar continuamente as tabelas MySQL on-premise para o S3 (parquet) ou para um data lake habilitado para Amazon RDS/Athena; catalogue com o AWS Glue e registre as features no offline store do Amazon SageMaker Feature Store para fornecer uma busca de features consistente para treinamento e serviço online. Isso centraliza a linhagem de features e impõe políticas de segurança do S3 e governança do Lake Formation para isolamento.
Treinamento e tratamento de desbalanceamento de classes: execute SageMaker Training jobs usando o contêiner integrado do SageMaker XGBoost. Calcule a proporção de rótulos de treinamento e defina o hiperparâmetro “scale_pos_weight” do XGBoost no mapa HyperParameters do CreateTrainingJob para lidar com o desbalanceamento de classes com o mínimo de pré-processamento. Use o modo Pipe para o canal de treinamento (DataSource com S3DataSource e S3DataType definidos como S3Prefix, e habilite "RecordWrapperType":"None" se estiver usando o modo Pipe) para reduzir o tempo de inicialização e a latência de download de dados em jobs consecutivos.
Registro de modelo e aprovação manual: registre os modelos treinados no SageMaker Model Registry chamando CreateModelPackage dentro de um ModelPackageGroup. Defina o ApprovalStatus inicial como PendingManualApproval, integre um AWS CodePipeline que inclua uma ação de Aprovação Manual da AWS e, após a confirmação manual, chame UpdateModelPackage com ApprovalStatus="Approved" antes de promover o ModelPackage para produção via CreateModel e CreateEndpointConfig.
Implantação e topologia de inferência: implante o modelo em um endpoint de tempo real provisionado para pontuação de baixa latência. Se centenas de modelos precisarem ser hospedados posteriormente, avalie um Multi-Model Endpoint e use o parâmetro TargetModel do InvokeEndpoint para direcionar modelos específicos armazenados no S3. Configure o DataCaptureConfig (EnableCapture=true, InitialSamplingPercentage=100, DestinationS3Uri=s3:///captures, CaptureOptions=['REQUEST','RESPONSE']) para coletar os payloads de requisição/resposta para análise sob demanda.
Monitoramento e detecção de anomalias: agende baselines do SageMaker Model Monitor com CreateMonitoringSchedule para qualidade de dados e desvio de features. Para detecção e visualização de anomalias no nível do conjunto de dados, alimente os dados capturados do S3 no Amazon Lookout for Metrics para detectar anomalias automaticamente e no Amazon QuickSight para dashboards. Para avaliação de viés e desvio sob demanda, execute jobs de processamento do SageMaker Clarify contra os dados capturados ou inicie um job de processamento ad-hoc do Model Monitor (via CreateProcessingJob) que aplica as restrições da baseline armazenada e produz o relatório de comparação.

Justificativa: esta abordagem centraliza as features para treinamento reprodutível e serviço de baixa latência, usa o scale_pos_weight do XGBoost para desbalanceamento de classes com complexidade mínima de pipeline, impõe uma aprovação manual no Model Registry integrado com o CodePipeline, reduz a latência de inicialização do treinamento usando o modo Pipe para streaming de dados de treinamento e fornece tanto detecção automatizada de anomalias (Lookout for Metrics) quanto verificações sob demanda de justiça/desvio (Clarify + Model Monitor) usando dados de inferência capturados.

← Avaliação e Seleção de Modelos · Todos os domínios · MLOps e Gerenciamento do Ciclo de Vida do Modelo →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →