MLA-C01 Domínio: Deploy e Orquestração de Workflows de ML (22% do exame)

Deploy e Orquestração de Workflows de ML na MLA-C01

O domínio "Deploy e Orquestração de Workflows de ML" representa 22% do exame MLA-C01, o que equivale a aproximadamente 14 das 65 questões. É o domínio onde a prova testa se você sabe levar um modelo de ML do notebook para produção de forma escalável, automatizada e sustentável. Candidatos com experiência em desenvolvimento de modelos costumam errar mais neste domínio do que no de preparação de dados, porque as escolhas de arquitetura de deploy têm nuances que a prática de laboratório não cobre.

A MLA-C01 tem 65 questões em 130 minutos, com nota de corte 720 de 1000. O nível é Associate, o que significa questões de cenário: a prova não pergunta "o que é SageMaker Pipelines", pergunta "dado este cenário de pipeline com restrição de custo e necessidade de reprocessamento, qual configuração é mais adequada". Ter o conceito certo não é suficiente; você precisa saber quando cada opção vence.

Estratégias de deploy: endpoint, batch e serverless

O primeiro subtopic concentra boa parte das questões do domínio. Existem três modalidades principais de deploy no SageMaker, e a prova cobra quando usar cada uma.

SageMaker Real-Time Endpoints são adequados quando a aplicação precisa de resposta em milissegundos para requisições individuais. O endpoint fica ativo permanentemente, consome instância provisionada o tempo todo e começa a cobrar imediatamente após a criação. A vantagem é latência baixa e previsível. O custo fixo é a desvantagem quando o tráfego é irregular.

SageMaker Batch Transform é usado quando você tem um conjunto de dados pronto e quer gerar predições para ele de uma vez, sem precisar de endpoint ativo. Você aponta para um arquivo no S3, o job roda, grava os resultados de volta no S3 e a instância é terminada. Ideal para scoring em lote, como processar todos os clientes da base para um modelo de churn às 2h da manhã. Não tem custo de instância entre execuções.

SageMaker Serverless Inference é a opção intermediária. O endpoint existe, mas não mantém instância dedicada. Quando uma requisição chega, a AWS provisiona o container, executa a inferência e libera. O cold start pode levar alguns segundos. Adequado para endpoints com tráfego muito baixo ou esporádico, onde manter instância ativa o dia todo não faz sentido economicamente.

SageMaker Asynchronous Inference cobre um quarto caso: payloads grandes (até 1 GB) e requisições de processamento longo, com volumes de tráfego que chegam em picos. A requisição entra em uma fila, é processada assim que há capacidade, e o resultado vai para o S3. O cliente não fica bloqueado esperando. Adequado para modelos de geração de imagem ou processamento de documentos longos, que estourariam o timeout de 60 segundos de um endpoint Real-Time.

A pegadinha clássica deste subtopic: a prova descreve um cenário de "modelo usado apenas à noite para gerar relatório" e oferece Real-Time Endpoint como alternativa. A resposta correta é Batch Transform ou Serverless, dependendo do volume. Real-Time Endpoint seria desperdício de custo neste caso.

Outro ponto cobrado: Multi-Model Endpoints (MME) permitem hospedar múltiplos modelos em um único endpoint, com os modelos carregados dinamicamente em memória conforme a demanda. Reduz custo quando você tem dezenas de modelos similares com tráfego esporádico por modelo. A prova pode descrever um cenário com 50 modelos de clientes diferentes e perguntar qual endpoint usa menos recursos.

Infraestrutura e escalabilidade

Este subtopic testa se você sabe configurar a infraestrutura de execução de ML de forma eficiente e elástica.

Tipos de instância: a prova cobra quando usar instâncias com GPU (ml.p3, ml.p4, ml.g4dn, ml.g5) versus CPU (ml.m5, ml.c5). GPUs são necessárias para treinamento de redes neurais profundas e inferência de modelos de linguagem grandes. Para modelos tradicionais (regressão, XGBoost, árvores) e datasets pequenos, CPU é mais custo-efetivo. ml.g4dn.xlarge é a instância GPU mais barata do portfólio e aparece em cenários de inferência de deep learning com restrição de custo.

Spot Instances para treinamento: o SageMaker suporta Managed Spot Training, que usa capacidade EC2 Spot para reduzir o custo de treinamento em até 90%. A limitação é que o job pode ser interrompido. O SageMaker salva checkpoints no S3 automaticamente e retoma de onde parou quando a capacidade volta. A prova cobra: "equipe quer reduzir custo de treinamento, o job aceita interrupção". Resposta: Managed Spot Training com checkpoints.

Auto Scaling de endpoints: endpoints Real-Time podem escalar automaticamente o número de instâncias com base em métricas do CloudWatch (normalmente InvocationsPerInstance). A configuração usa Application Auto Scaling. A prova pode descrever um cenário de pico de tráfego e perguntar qual configuração garante disponibilidade sem provisionar instância ociosa no restante do dia.

Elastic Inference: add-on legado que anexava capacidade de GPU fracionada a instâncias CPU, para modelos que precisavam de aceleração sem justificar uma instância GPU dedicada. A AWS deixou de oferecê-lo a novos clientes, então em cenários atuais a alternativa de baixo custo para aceleração é uma instância GPU pequena (ml.g4dn) ou Serverless Inference. Pode aparecer em questões mais antigas como conceito.

O que a prova NÃO cobra neste subtopic: configuração detalhada de redes neurais, otimização de CUDA ou gestão de memória GPU. O foco é qual recurso usar em qual cenário de custo/performance.

CI/CD e SageMaker Pipelines

Este é o subtopic mais "engenharia de software" do domínio. A prova testa se você sabe estruturar um pipeline de ML reproduzível e automatizado.

SageMaker Pipelines é o orquestrador nativo de MLOps da AWS. Você define um DAG (grafo acíclico dirigido) com tipos de step nativos: ProcessingStep (preparação de dados e avaliação de métricas, rodando scripts de processamento), TrainingStep (treinamento), TuningStep (tuning de hiperparâmetros), ConditionStep (ramificação por métrica) e ModelStep (criação e registro do modelo no Model Registry). Não existe um step nativo de deploy: a publicação do modelo costuma sair do pipeline para um LambdaStep ou para uma etapa de CodePipeline. O pipeline é versionado, rastreável e pode ser disparado por evento ou agendado.

A integração com o SageMaker Model Registry é fundamental. Modelos treinados são registrados com metadados (métricas, versão, dataset usado), e o deploy é feito a partir de uma versão aprovada do registry. Isso separa o treinamento do deploy e permite rollback: se a versão nova tem problema, você promove a versão anterior no registry.

CI/CD com CodePipeline e CodeBuild: o fluxo típico que a prova descreve é: commit no repositório de código (CodeCommit ou GitHub) dispara CodePipeline, que chama CodeBuild para treinar ou reprocessar, que por sua vez executa SageMaker Pipelines. Aprovação humana (manual approval) pode ser inserida no CodePipeline antes do deploy para produção. A prova pode descrever esse fluxo e perguntar qual serviço deve ser responsável por cada etapa.

Model Registry e aprovação: o fluxo recomendado pela AWS é que modelos passem por estado "PendingManualApproval" antes de ir para produção. Um revisor humano (ou gate automatizado de métricas) move o modelo para "Approved". O SageMaker Pipelines pode ser configurado para só fazer deploy de modelos aprovados. A pegadinha: candidatos confundem "aprovação de modelo" com "aprovação de código". São processos separados e independentes.

Reprodutibilidade: a prova cobra rastreabilidade. O SageMaker ML Lineage Tracking registra automaticamente as relações entre datasets, jobs, modelos e endpoints. Permite responder "qual dataset gerou este modelo em produção" ou "quais modelos foram treinados com este dataset". Para questões de auditoria e compliance, é o serviço correto.

IaC (CloudFormation e CDK)

O último subtopic testa se você sabe provisionar infraestrutura de ML como código, de forma repetível.

AWS CloudFormation permite descrever a infraestrutura em YAML ou JSON e criar/atualizar/deletar recursos em conjunto (stacks). Para ML: você pode definir um endpoint SageMaker, a configuração de endpoint, o modelo, as permissões IAM associadas e as políticas de Auto Scaling em um único template. O benefício é que você pode replicar exatamente o mesmo ambiente entre dev, staging e prod, sem configuração manual.

AWS CDK (Cloud Development Kit) é uma abstração de mais alto nível sobre CloudFormation. Você escreve a infraestrutura em TypeScript, Python, Java ou Go, e o CDK sintetiza o CloudFormation por baixo. Para times de ML com background de engenharia de software, o CDK é mais natural porque usa constructs tipados e compostos. A prova pode apresentar um cenário onde um time quer definir endpoints SageMaker reutilizáveis como componentes de código.

SageMaker Projects é a integração nativa de MLOps que combina CodePipeline, CodeBuild e SageMaker Pipelines em um projeto estruturado. Usa CloudFormation por baixo para provisionar toda a infraestrutura do pipeline. É o ponto de entrada recomendado para times que querem começar com MLOps sem construir o CI/CD do zero. A prova pode descrever um requisito de "pipeline de ML end-to-end sem configurar CI/CD manualmente" e a resposta é SageMaker Projects.

A pegadinha de IaC: candidatos confundem o que vai em CloudFormation (infraestrutura: endpoint, modelo, IAM) com o que vai em SageMaker Pipelines (steps de ML: processamento, treinamento, avaliação). Os dois coexistem. CloudFormation cria o pipeline, o pipeline executa os steps de ML.

Terraform não é serviço AWS, mas a prova pode mencionar como alternativa de IaC válida em cenários híbridos. O que a prova cobra é que o AWS CDK e CloudFormation são as ferramentas nativas, com integração direta com SageMaker sem necessidade de providers de terceiros.

Pegadinhas comuns deste domínio

• Real-Time vs Batch vs Serverless: a resposta correta depende de latência, frequência e volume. Leia o cenário devagar antes de escolher.
• Spot para inferência vs treinamento: Managed Spot Training é amplamente suportado para treinamento. Para inferência, Spot não é recomendado porque interrupções afetam disponibilidade do endpoint. Serverless Inference é a alternativa de baixo custo para endpoints, não Spot.
• Model Registry vs Model Card: Model Registry registra versões e controla o ciclo de deploy. Model Cards documentam intenções, limitações e contexto de uso do modelo. São complementares, não equivalentes.
• SageMaker Pipelines vs Step Functions: ambos podem orquestrar workflows de ML. Step Functions é mais genérico (orquestra qualquer serviço AWS). SageMaker Pipelines é otimizado para ML (integra com Model Registry, Lineage Tracking, Feature Store). A prova prefere SageMaker Pipelines em cenários de MLOps puros.
• CDK vs CloudFormation: CDK sintetiza CloudFormation. Não são alternativos em termos de execução, são níveis de abstração diferentes.

O que estudar para as questões de deploy

A MLA-C01 é uma prova de cenário. Para este domínio, treine a lógica de decisão:

• Latência abaixo de 1 segundo, tráfego constante: Real-Time Endpoint.
• Processamento em lote, sem tempo real: Batch Transform.
• Tráfego baixo e irregular, aceita cold start de segundos: Serverless Inference.
• Requisições longas, volume em picos: Asynchronous Inference.
• Muitos modelos similares com tráfego esporádico por modelo: Multi-Model Endpoint.
• Custo de treinamento alto, job aceita interrupção: Spot Training com checkpoints.
• Pipeline reproduzível end-to-end com CI/CD: SageMaker Projects ou Pipelines + CodePipeline.
• Infraestrutura replicável entre ambientes: CloudFormation ou CDK.

Leia também

• MLA-C01 em português: guia completo
• MLA-C01 Domínio: Preparação de Dados para ML
• MLA-C01 Domínio: Desenvolvimento de Modelo de ML
• MLA-C01 Domínio: Monitoramento, Manutenção e Segurança

Pronto para testar este domínio?

Questões de cenário no estilo real da MLA-C01, com feedback por alternativa, em PT-BR. 7 dias grátis.

Praticar deploy e orquestração de ML