Amazon MLS-C01: Implantação, Inferência e Serving (Implementação e Operações de ML) — Guia de estudos

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

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

Padrões de implantação e opções de serviço

As escolhas de serviço de modelos equilibram latência, custo, throughput e complexidade operacional. Endpoints em tempo real do SageMaker (provisionados ou serverless) fornecem latências de menos de 100 ms a segundos, adequadas para APIs interativas; escolha famílias de instâncias como ml.c5/m5 para modelos de CPU, ml.g4dn ou ml.p3 para modelos de GPU, ou ml.inf1 para inferência de baixo custo e alto throughput com Inferentia. A inferência assíncrona e o Batch Transform são adequados para casos de uso com grandes lotes (batch) ou latência variável: o Batch Transform é ideal para grandes trabalhos offline (divida objetos grandes do S3 em fragmentos e use instâncias ml.m5/c5 ou de GPU conforme necessário), enquanto o SageMaker Asynchronous Inference suporta payloads maiores com enfileiramento para processamento em lote quase em tempo real. Endpoints multimodelo hospedam vários modelos por trás de um único contêiner, reduzindo o overhead de armazenamento ao carregar modelos sob demanda; eles funcionam melhor quando os modelos são pequenos, têm custos de cold start modestos e os padrões de acesso são esparsos. Escolha o SageMaker Serverless Inference para cargas de trabalho imprevisíveis e de baixo throughput para evitar o gerenciamento de instâncias; tenha cuidado com os cold starts e o tempo de execução limitado. Os principais critérios de decisão incluem SLOs de latência, custo por invocação, padrão de concorrência, tamanho do modelo e tolerância a cold starts. Uma armadilha comum é usar endpoints em tempo real para cargas de trabalho em lote de volume extremamente alto — isso é caro; em vez disso, use o Batch Transform, a Inferência Assíncrona ou invoque endpoints por meio de lotes e workers concorrentes.

Escalabilidade, modelagem de tráfego e otimização de custos

O escalonamento automático, o desvio de tráfego e o controle de custos devem ser projetados em conjunto com a topologia de implantação. Use o Application Auto Scaling para escalar variantes de endpoint do SageMaker com políticas de target-tracking baseadas em métricas de invocação ou métricas personalizadas do CloudWatch; defina capacidades mínimas/máximas e cooldowns sensatos para evitar oscilações excessivas (thrashing). Para implantações blue/green e lançamentos canary, use endpoints multivariante ou atualizações de EndpointConfig com porcentagens de divisão de tráfego e aumentos graduais; integre com o AWS CodeDeploy para automatizar o desvio de tráfego. As otimizações de custo incluem poda (pruning) de modelo, quantização (FP16 ou int8), compilação com o SageMaker Neo ou AWS Neuron para Inf1 e a transferência de cargas de trabalho não sensíveis à latência para o Batch Transform ou inferência serverless. Instâncias Spot reduzem os custos de treinamento, mas não são aplicáveis a endpoints em tempo real; em vez disso, dimensione corretamente os tipos de instância (cpu vs. gpu vs. inferentia) e consolide modelos com endpoints multimodelo quando apropriado. Fique atento a armadilhas como o superprovisionamento ao usar target-tracking sem entender o throughput por instância, ou presumir que endpoints multimodelo eliminam os limites de memória — o carregamento do modelo ainda requer memória e pode aumentar a latência. Além disso, comprima os artefatos do modelo (ONNX, TF SavedModel com gz) e use estratégias de lazy-loading para reduzir o armazenamento e os tempos de cold start.

Edge, inferência de baixa latência e posicionamento do pré/pós-processamento

Para ambientes de latência ultrabaixa ou desconectados, implante modelos no AWS IoT Greengrass (v2) ou use o SageMaker Edge Manager para empacotar e monitorar modelos em dispositivos de edge; compile com o SageMaker Neo ou componentes do AWS IoT Greengrass e use quantização para atender às restrições de memória/CPU. Posicione o pré-processamento e a extração de features onde eles minimizem a latência e o custo de ponta a ponta: filtros simples podem ser executados no firmware do dispositivo ou em uma Lambda do Greengrass, enquanto o processamento em lote (batching) e transformações pesadas devem ficar em um gateway de edge ou na nuvem. Para janelas de eventos de streaming (por exemplo, janelas deslizantes de 10 minutos), faça a ingestão com o Amazon Kinesis Data Streams ou Amazon MSK, use o Kinesis Data Analytics ou Flink/Apache Spark para janelamento e agregação, e encaminhe as features sumarizadas para um endpoint do SageMaker ou um modelo leve no edge — isso reduz a saída de dados da rede (egress) e a frequência de invocação do modelo. Cuidado com armadilhas como ignorar o versionamento de modelos em dispositivos de edge ou não provisionar armazenamento suficiente no dispositivo para os artefatos do modelo. Para microsserviços do lado do servidor, colocalize o pré-processamento (API Gateway + Lambda ou ALB + Fargate) para evitar o overhead de chamadas a frio e reduzir o tamanho dos payloads enviados ao modelo.

Monitoramento, auditoria, governança e manipulação de dados

ML operacional exige monitoramento contínuo da saúde do modelo e governança de dados. Use o SageMaker Model Monitor para criar um baseline dos dados de treinamento com um DataQualityJob e configure o monitoramento contínuo para detectar data drift, regressões na qualidade do modelo, valores ausentes e restrições personalizadas; habilite o DataCaptureConfig nos endpoints para capturar entradas/saídas para o S3 e acionar jobs do Model Monitor. Para linhagem e auditoria em nível de feature, use o Amazon SageMaker Feature Store (stores online e offline) combinado com o AWS Glue Data Catalog e o CloudTrail para rastrear o acesso e as transformações de datasets; jobs do Amazon Macie e do Glue/SageMaker Processing podem descobrir e redigir PII antes do treinamento. As armadilhas de criptografia incluem o SSE-KMS: quando objetos do S3 são criptografados com uma CMK gerenciada pelo cliente, garanta que a execution role do SageMaker tenha as permissões kms:Decrypt e kms:GenerateDataKey e que a política da CMK conceda acesso; garanta também que as políticas do bucket S3 e os VPC endpoints não bloqueiem o acesso. Para objetos S3 grandes diários (ex: 100 GB), evite a ingestão em um único arquivo — particione em muitos objetos menores, armazene em Parquet e comprima, e use o Athena/Glue para detecção de schema. Armadilhas comuns incluem agendamentos de monitoramento insuficientes, não gerar um baseline adequado para o Model Monitor e esquecer de conceder acesso ao KMS para todos os service principals (SageMaker, Glue, Lambda) que precisam de permissão para descriptografar.

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

Cenário: A Streamlytic Media opera uma plataforma de análise de podcasts na AWS. Eles usam o Kinesis Data Streams para ingerir eventos de usuários, armazenam features agregadas no S3 e hospedam modelos no SageMaker para predição de engajamento em tempo real. Os dados contêm PII ocasionalmente e são criptografados com uma chave gerenciada pelo cliente SSE-KMS.

Desafio: Fornecer predições de baixa latência em uma janela de eventos contínua de 10 minutos, redigir PII antes do treinamento do modelo, garantir que o SageMaker possa ler dados criptografados do S3 e implementar monitoramento contínuo para desvio de features (feature drift).

Abordagem Recomendada:

Crie um Kinesis Data Stream para ingerir eventos, execute o Kinesis Data Analytics (Flink) para manter janelas contínuas de 10 minutos e emita features agregadas para o S3 em formato Parquet com partições por hora.
Detecte e redija PII usando o Amazon Macie para descoberta e um job do SageMaker Processing (ou um job do AWS Glue) para aplicar redação/tokenização determinística; armazene os resultados em um offline store do Feature Store para treinamento.
Conceda à execution role do SageMaker as permissões kms:Decrypt e kms:GenerateDataKey na CMK, adicione a role à política de chave da CMK e garanta que a política do bucket S3 ou o VPC endpoint permita o acesso para o SageMaker.
Implante o modelo como um endpoint em tempo real do SageMaker em instâncias ml.inf1, habilite o DataCaptureConfig, crie um baseline do Model Monitor a partir dos dados de treinamento e configure o monitoramento contínuo com alertas para o CloudWatch.

Justificativa: A agregação via streaming com Kinesis + Flink minimiza o volume de eventos e a latência; a redação no momento do processamento preserva a privacidade e a conformidade; permissões explícitas do KMS evitam falhas de acesso; endpoints baseados em Inferentia e o Model Monitor equilibram o baixo custo de inferência com a observabilidade operacional.

← Treinamento · Todos os domínios · Segurança →

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