Certificação Google Cloud PMLE: serving, escala e MLOps

Série PMLE - 4 de 5

Publicado a 15 de Abril de 2026

Um modelo que só funciona no momento da demo ainda não resolveu nada. A parte operacional da PMLE mede precisamente isso: consegues servir, escalar, monitorizar e atualizar a solução sem transformar cada mudança numa intervenção artesanal?

Identidade visual da série PMLE - serving, escala e MLOps

Slides desta sessão

Versão resumida em formato de apresentação para revisão rápida dos padrões de serving, escalabilidade e MLOps.

Se o embed falhar, abre a apresentação diretamente no Google Slides.

Abrir apresentação

Nota sobre nomenclatura: A Google Cloud atualizou recentemente a marca de "Vertex AI" para "Gemini Enterprise Agent Platform" (ou simplesmente "Agent Platform"). O exame reflete esta transição. Neste artigo usamos "Vertex AI" por ser ainda a nomenclatura mais reconhecida na documentação e nos materiais de estudo, mas deves estar preparado para ver ambos os nomes no exame.

Neste artigo

Passar do modelo aprovado para inferência real, pipelines automatizados, observabilidade e ciclos de retraining.

Domínios do exame

  • Servir e escalar modelos
  • Automatizar e orquestrar pipelines de ML
  • Monitorizar soluções de IA

Ferramentas-chave

  • Vertex AI Endpoints
  • Batch prediction
  • Vertex AI Pipelines
  • Model Monitoring

Neste post

Batch versus online: a primeira escolha operacional

No exame, uma das distinções mais recorrentes é entre inferência batch e inferência online. A primeira faz sentido quando o problema tolera latência maior, processamento periódico e throughput elevado. A segunda é para decisões interativas ou quase em tempo real. A opção correta depende menos da elegância técnica e mais dos requisitos do caso: SLA, custo, volume, previsibilidade de carga e impacto da latência.

Em perguntas de arquitetura, a resposta errada costuma ser a que escolhe online serving por hábito, quando um job batch resolveria com menos custo e menos risco operacional.

Padrão Quando usar Risco se escolheres mal
Batch prediction Scoring periódico, grandes volumes, requisitos de latência relaxados. Se usares online desnecessariamente, aumentas custo e complexidade.
Online inference Interações em tempo real, decisões imediatas, aplicações síncronas. Se usares batch, falhas o tempo de resposta exigido pelo produto.

Scoring noturno para milhões de registos

O problema pede throughput e custo controlado. Batch prediction tende a ser a escolha natural.

Recomendação interativa numa app

Se a resposta tem de aparecer durante a sessão do utilizador, serving online passa a ser requisito, não luxo.

Feature lenta para serving online

Mesmo que o endpoint esteja pronto, a feature pode falhar o SLA e empurrar a arquitetura para batch ou pré-computação.

Carga imprevisível

Autoscaling, limites de custo e latência deixam de ser detalhe de infra e passam a ser parte da decisão de produto.

Static, dynamic e hybrid: a lente de distribuição

Para além da separação batch vs online, o exame testa outra dimensão: como a distribuição dos pedidos de previsão influencia a arquitetura de serving. A Google Cloud ensina isto através de dois conceitos — peakedness e cardinality — que determinam se deves pré-computar previsões, calculá-las on-demand, ou combinar ambos.

Peakedness

Quão concentrados estão os pedidos em poucos valores. Alta peakedness significa que uma pequena fatia de inputs gera a maioria das queries — o cache funciona bem.

Cardinality

Quantos inputs distintos o modelo pode receber. Baixa cardinality torna viável pré-computar todas as previsões; alta cardinality força cálculo sob demanda.

Padrão de serving Como funciona Trade-off principal
Static (pré-computado) Calcula todas as previsões antecipadamente e armazena-as (ex: BigQuery, lookup table). A API apenas lê valores. Latência baixa e fixa, mas custo de armazenamento elevado e impossível para espaços de input muito grandes.
Dynamic (on-demand) Calcula previsões quando solicitadas, usando o modelo em produção. Flexível e sempre atualizado, mas latência variável e maior uso de CPU/GPU.
Hybrid Cache de previsões frequentes (static) + cálculo on-demand para a cauda longa (dynamic). Equilibra latência e custo, mas exige monitorizar taxa de cache hit e decidir que inputs pré-computar.
Cardinality baixa Cardinality alta
Alta peakedness Static ou hybrid Hybrid
Baixa peakedness Static (se pouco frequente) Dynamic

Conversão de anúncios

Conjunto fixo de anúncios, mesmos anúncios repetidamente → alta peakedness, baixa cardinality → static serving.

Deteção de spam

Infinitas combinações de texto, distribuição uniforme → baixa peakedness, alta cardinality → dynamic serving.

Teclado preditivo

Poucas palavras muito frequentes, vocabulário limitado → alta peakedness, baixa cardinality → static ou hybrid.

Tráfego urbano

Poucas estradas concentram a maioria dos pedidos, mas granularidade temporal pode aumentar cardinality → hybrid, começando conservador.

Heurística para o exame: quando o enunciado descreve um modelo com pedidos concentrados em poucos valores e espaço de input limitado, a resposta que pré-computa e serve de uma tabela tende a ser mais eficiente. Quando a distribuição é dispersa e o espaço é grande, dynamic serving é quase sempre a via correta.

Endpoints, escala e rollout

Em Vertex AI, serving não é apenas “pôr um endpoint no ar”. É decidir como versionar, como fazer rollout, como lidar com tráfego variável, como medir latência e como reduzir risco na introdução de novas versões. A PMLE tende a valorizar respostas que pensam em transição segura, observabilidade e rollback, em vez de assumir que o melhor modelo offline deve ser imediatamente o modelo produtivo.

Também interessa perceber que serving não é neutro do ponto de vista económico. Escalar um endpoint para responder mais depressa pode ser certo do ponto de vista de produto e errado do ponto de vista de custo, se o caso não exigir essa latência. A certificação gosta desse raciocínio com trade-offs explícitos.

Padrão de rollout Quando faz sentido Critério de rollback
Substituição direta Baixo risco, forte confiança, sistema não crítico. Erros técnicos, latência inesperada ou quebra rápida de métricas.
Canary / traffic splitting Queres validar o novo modelo em parte do tráfego antes de promover a totalidade. Queda comparativa em métricas, incidentes ou sinais de regressão.
A/B orientado a negócio O objetivo é testar impacto no produto, não apenas qualidade do modelo offline. Perda de KPI principal, custo excessivo ou experiência pior para utilizador.
Pergunta útil para qualquer cenário: estou a otimizar para throughput, para latência, para custo, para simplicidade operacional, ou para uma mistura dos quatro? Sem isso, escolher serving pattern é adivinhar.

Antes de escalar o endpoint, vale a pena perguntar se o modelo em si já está otimizado. Técnicas de model optimization podem reduzir latência e custo sem mexer na infraestrutura:

Técnica O que faz Quando considerar
Quantization Reduz a precisão numérica dos pesos (ex: FP32 → INT8), diminuindo o tamanho e a latência. Quando precisas de reduzir custo de inferência sem retraining, especialmente em edge ou com GPU limitada.
Distillation Treina um modelo mais pequeno (student) para aproximar o comportamento de um modelo maior (teacher). Quando o modelo original é demasiado pesado para o SLA de serving, mas tens budget para o processo de distillation.
Pruning Remove conexões ou neurónios com pouca contribuição para o resultado. Quando queres reduzir complexidade mantendo a arquitetura base. Funciona bem em redes profundas com redundância.
Para o exame: se o problema é latência ou custo no serving e o modelo já está validado, procura primeiro otimização do modelo antes de escalar infraestrutura. A resposta que otimiza o modelo costuma ser mais eficiente do que a que adiciona máquinas.

Autoscaling, cold starts e dimensionamento de endpoints

Vertex AI Endpoints permitem autoscaling baseado em utilização de CPU ou QPS (queries por segundo), com configuração de réplicas mínimas e máximas. O detalhe crítico para exame está no min_replica_count: definir como 0 permite poupar custo quando não há tráfego, mas introduz latência significativa de cold start no primeiro pedido após o endpoint ter sido desativado. Se o requisito de negócio exige latência baixa constante, o mínimo deve ser 1 ou mais.

Outro ponto operacional que o exame testa: quando o modelo precisa de features históricas em tempo real (ex: média de gastos dos últimos 6 meses), fazer um JOIN no BigQuery durante o pedido é inviável e provocará timeouts. A solução é servir features a partir de um armazenamento de baixa latência, tipicamente o Vertex AI Feature Store com online serving (sincronizado com Cloud Bigtable como backend), ou pré-computar as features necessárias.

Configuração Vantagem Armadilha
min_replica_count = 0 Sem custo quando não há tráfego (ideal para dev/staging). Cold start pode durar dezenas de segundos — inaceitável para produção com SLA apertado.
min_replica_count ≥ 1 Latência estável, sem cold start. Custo fixo mesmo sem tráfego. Precisa de dimensionamento adequado ao padrão de carga.
Autoscaling por CPU/QPS Adapta-se à carga real, balanceia custo e performance. Latência de scale-up pode ser lenta demais para picos bruscos — considerar pré-aquecimento ou carga mínima mais alta.
Armadilha de exame: mesmo que uma conta de serviço tenha permissão de Storage Admin, se a VM do endpoint foi criada com access scopes de leitura apenas, a escrita de artefactos falhará. O acesso final é sempre a interseção entre o papel IAM e o access scope da instância. Esta regra aplica-se a qualquer serviço Google Cloud que use VMs, não apenas a endpoints de ML.

Opções de deploy: cloud, edge e containers

O exame não testa apenas serving em cloud. Três padrões de deployment aparecem regularmente:

Padrão de deploy Quando usar Ferramentas e formatos
Cloud endpoint (Vertex AI) Serving centralizado, autoscaling gerido, integração com Feature Store e Model Monitoring. Pre-built containers (TensorFlow, scikit-learn, XGBoost) ou custom containers para frameworks não suportados nativamente.
Edge / mobile Latência mínima, funcionamento offline, privacidade de dados no dispositivo. TFLite para mobile e IoT, TensorFlow.js para browser, Cloud IoT Edge para gateways.
Batch prediction Scoring periódico de grandes volumes, sem necessidade de endpoint persistente. Vertex AI Batch Prediction jobs, input de BigQuery ou Cloud Storage, output para BigQuery ou GCS.

Sobre custom containers: quando o modelo usa um framework que os pre-built containers da Vertex AI não suportam (ex: PyTorch com dependências específicas, modelos customizados com pré/pós-processamento complexo), precisas de criar uma imagem Docker compatível com a API AIP (AI Platform). A imagem deve expor um endpoint HTTP que aceita pedidos de previsão no formato esperado. O Artifact Registry é o serviço recomendado para armazenar e versionar estas imagens de container.

Para o exame: se o cenário menciona necessidade de inferência em dispositivos sem conectividade, latência sub-milissegundo ou privacidade de dados no dispositivo, a resposta é edge deployment (TFLite ou similar), não cloud endpoint. Se menciona um framework não standard ou dependências complexas, a resposta é custom container, não pre-built.

Vertex AI Pipelines e orquestração

MLOps, no contexto da PMLE, é a disciplina que liga dados, treino, avaliação, aprovação e serving por meio de processos consistentes. Vertex AI Pipelines aparece aqui como ferramenta de orquestração, mas o importante é o padrão mental: cada etapa deve ser definida, dependente das anteriores, reexecutável e auditável.

Quando um modelo precisa de ser retreinado, avaliado e eventualmente promovido, o pipeline não deve depender de uma sequência manual de passos dispersos por notebooks e scripts locais. A automação reduz erro humano, melhora reprodutibilidade e cria rastreabilidade entre artefactos.

Uma distinção que importa para o exame: Vertex AI Pipelines é o serviço gerido (serverless) da Google Cloud para orquestração de ML workflows; Kubeflow Pipelines é o framework open-source que corre em Kubernetes e que serve de base ao Vertex AI Pipelines. Se o cenário menciona necessidade de portabilidade multi-cloud ou controlo total sobre infraestrutura, Kubeflow no GKE pode ser a resposta. Se o cenário pede simplicidade operacional e integração com Vertex AI, o serviço gerido é quase sempre a melhor opção.

Outro ponto que a PMLE começou a valorizar mais: CI/CD para ML. Tal como em software, code changes, data changes e model changes beneficiam de pipelines de integração e entrega contínua. Na Google Cloud, isto costuma envolver:

  • Cloud Build: serviço gerido para automação de builds, testes e deployments. Executa pipelines CI/CD a partir de repositórios Git, constrói imagens Docker, corre testes unitários e de integração, e dispara deployments para Vertex AI.
  • Artifact Registry: repositório centralizado para imagens Docker, pacotes Python e outros artefactos. Substitui o Container Registry (deprecated) e suporta múltiplos formatos. É onde armazenas as imagens de treino, serving e os componentes do pipeline.
  • Vertex AI Pipelines: orquestrador do ciclo de vida completo, desde validação de dados até deployment do modelo.

Para pipelines mais standardizados, o exame pode mencionar TensorFlow Extended (TFX), um framework end-to-end para production ML pipelines. TFX fornece componentes reutilizáveis (ExampleGen, StatisticsGen, SchemaGen, Transform, Trainer, Evaluator, Pusher) que podem correr em Vertex AI Pipelines ou Kubeflow Pipelines. A vantagem é a portabilidade: o mesmo pipeline TFX pode correr on-premise, em qualquer cloud com Kubernetes, ou no Vertex AI gerido.

Níveis de maturidade MLOps

A Google Cloud Architecture Center define três níveis de maturidade que o exame usa como framework de referência para calibrar respostas:

Nível 0 — Manual

Treino em notebooks, deploy manual, sem monitorização automatizada. Adequado apenas para prova de conceito.

Nível 1 — Pipeline automático

Treino automatizado com pipelines, retraining contínuo, monitorização de dados e modelo. O código do pipeline ainda é entregue manualmente.

Nível 2 — CI/CD completo

CI/CD para o próprio pipeline: testes automatizados, build, deploy e monitorização end-to-end. O sistema melhora-se a si próprio.

Para o exame: se o cenário descreve uma equipa que faz deploy manualmente mas quer automatizar retraining, a resposta está na transição de Nível 0 para Nível 1. Se já têm pipeline mas querem que o próprio pipeline seja testado e versionado, a resposta é Nível 2.

Retraining: calendário, evento ou degradação observada?

Nem todo o retraining deve acontecer por relógio. Às vezes, um agendamento periódico faz sentido; noutras, o gatilho deve ser drift, quebra de performance ou mudança de negócio. A resposta certa depende do comportamento do domínio. O exame tende a premiar a escolha que liga mecanismo de atualização a um sinal plausível do problema, em vez de aplicar um calendário fixo sem justificação.

Isto também cruza monitorização. Se não medes drift, skew, estabilidade de features ou performance downstream, não tens base para decidir retraining com critério.

Retraining por calendário

Bom quando a sazonalidade e a renovação do dado são previsíveis.

Retraining por evento

Útil quando há novos lotes relevantes, mudanças operacionais ou integração com upstream data products.

Retraining por degradação

Mais sofisticado e mais alinhado com sistemas onde drift e performance determinam a necessidade real.

Ligação com a taxonomia de drift (Parte 2): concept drift sudden (ex: nova legislação) exige retraining imediato. Concept drift gradual pode tolerar calendário com janela curta. Concept drift recurring (sazonalidade) beneficia de modelos que re-aprendem ciclicamente. Data drift (covariates) sem concept drift pode não exigir retraining, mas sim recalibração.

Monitorização: sinais, não superstição

Monitorizar uma solução AI não é abrir um dashboard e sentir-se melhor. É saber que sinais importam. No currículo atual, isso inclui pelo menos entradas, distribuições, desvios, performance e, no caso de GenAI, avaliação mais contextual. Para modelos clássicos, a lógica continua a ser: observar inputs, outputs e comportamento ao longo do tempo, relacionando-os com qualidade real do sistema.

Um bom estudante da PMLE aprende a distinguir quatro níveis de observação:

  • Saúde técnica do serviço: disponibilidade, latência, erros.
  • Saúde dos dados: schema, skew, drift, missingness.
  • Saúde do modelo: degradação de métricas relevantes.
  • Saúde do produto: se a decisão serve ou não o objetivo de negócio.
Erro recorrente: confundir monitorização com logging. Logs ajudam, mas MLOps exige métricas, limiares, interpretação e ação operacional.
Tipo de sistema Métricas de operação Métricas de qualidade
Classificação Latência, erro, throughput, saturação de endpoint Precision/recall por segmento, calibração, drift por feature
Regressão Disponibilidade, custo por previsão, backlog batch MAE/RMSE, estabilidade por janela temporal, drift de input
Ranking / recomendação Latência, cache hit, custo de features online NDCG/recall@k, cobertura, feedback do utilizador

Métricas de distância e feature attribution

O Vertex AI Model Monitoring usa métricas matemáticas específicas para calcular a distância entre distribuições de treino e produção. Trocar estas métricas é um erro frequente em perguntas técnicas detalhadas.

Tipo de feature Métricas suportadas Quando usar cada uma
Categórica (strings, booleanos) L-infinity (L∞) e Jensen-Shannon (JS) L∞ mede a mudança máxima numa categoria específica — ideal para detetar categorias novas ou desaparecidas. JS quantifica a divergência global entre distribuições — mais sensível a mudanças graduais em várias categorias.
Numérica (floats, integers) Jensen-Shannon (JS) Métrica simétrica que quantifica a similaridade entre duas densidades de probabilidade. Sensível a mudanças de distribuição sem ser instável.

Além das distribuições de features, o Model Monitoring permite monitorizar feature attribution: se a importância de uma feature específica muda significativamente entre treino e produção, isso pode indicar problemas silenciosos na qualidade dos dados. A métrica usada para feature attribution é o SHAP value (SHapley Additive exPlanations), que mede a contribuição de cada feature para a inferência do modelo. Esta camada avançada cruza com Explainable AI e é cada vez mais testada no exame.

O Model Monitoring v2 (atualmente em Preview) acrescenta uma capacidade importante: output inference data drift — monitorizar não apenas a distribuição dos inputs, mas também a distribuição das próprias previsões do modelo ao longo do tempo. Isto permite detetar degradação mesmo quando os inputs parecem estáveis mas o comportamento do modelo mudou.

Para o exame: para deteção de skew, tens de fornecer o dataset de treino original como baseline. Para deteção de drift, o baseline são janelas passadas de dados de produção — não precisas do dataset de treino. Esta distinção de configuração aparece em cenários onde os dados de treino já não estão disponíveis.

Cenários de falha operacional

A PMLE não testa apenas cenários onde tudo corre bem. Testa a tua capacidade de diagnosticar e responder a falhas de sistema. Três padrões de falha são particularmente relevantes:

Poluição de dados em evento

Um servidor de transações falha durante a Black Friday, mas o web server continua ativo. O modelo de recomendação aprende que ninguém que clica compra nada.

  • Modelos não conseguem “desaprender” — é preciso rollback para versão anterior.
  • Exige infraestrutura de versionamento automático e capacidade de reverter rapidamente.

Cold start de modelo de recomendação

Modelo estático funciona bem no lançamento, mas ao longo de meses a taxa de conversão desce porque o modelo não conhece novos utilizadores nem novos produtos.

  • Modelos estáticos em ambientes dinâmicos (e-commerce, moda) têm vida útil limitada.
  • Treino dinâmico com retreino regular é obrigatório, não opcional.

Degradação em ambiente adversarial

Modelo de deteção de fraude funciona bem no início, mas fraudadores adaptam-se e desenvolvem novas estratégias que o modelo não reconhece.

  • Ambientes adversariais (fraude, spam, cybersecurity) exigem retreino muito mais frequente.
  • A degradação da performance é inevitável sem atualização constante do modelo.
Regra para o exame: se o cenário descreve performance que degrada ao longo do tempo sem falha técnica óbvia, a resposta mais provável envolve retreino com dados recentes, não mais infraestrutura. Se descreve dados corrompidos, a resposta é rollback + versionamento, não correção manual.

SLOs, custo e capacidade

Há uma parte da PMLE que parece “mais infra do que ML”, mas isso é precisamente o ponto: um modelo em produção consome CPU, memória, budget e atenção operacional. Por isso, convém pensar em SLOs e capacidade com a mesma seriedade com que pensas na métrica do modelo. Um endpoint que cumpre a métrica mas quebra o orçamento ou falha o p95 de latência pode continuar a ser uma má solução.

Em linguagem de exame, isto aparece quando tens de escolher entre escalar horizontalmente, ajustar mínimos/máximos de réplicas, pré-computar features ou mover um problema de online para batch. A melhor resposta não é “mais máquinas”; é o padrão que alinha custo, latência e previsibilidade de carga.

Tipo de sistema SLOs típicos Decisões de capacidade
Classificação em tempo real Latência p95 < 100ms, disponibilidade 99.9%, throughput 1000 QPS min_replica_count ≥ 2, autoscaling por QPS, otimização de modelo para reduzir latência
Batch scoring noturno Conclusão em janela de 4h, custo por milhão de previsões < X€ Batch prediction jobs, sem endpoints persistentes, otimização de custo via preemptible VMs
Recomendação personalizada Latência p95 < 50ms, cache hit rate > 80% Hybrid serving (static + dynamic), Feature Store para baixa latência, pré-computação de features
Deteção de fraude Latência p99 < 200ms, disponibilidade 99.99% Multi-região deployment, min_replica_count alto, monitorização agressiva de drift
Para o exame: quando o cenário menciona requisitos de latência específicos (ex: "p95 < 100ms"), a resposta correta raramente é "adicionar mais réplicas" sem qualificação. Procura a opção que combina otimização de modelo, configuração de autoscaling adequada e, quando aplicável, pré-computação ou caching.

O que precisas de saber para o exame

  • Diferença entre batch prediction e online inference, com critérios de decisão claros.
  • Raciocinar com peakedness e cardinality para escolher entre static, dynamic e hybrid serving.
  • O papel de endpoints, versionamento, traffic splitting e rollout seguro em produção.
  • Impacto de min_replica_count no custo e na latência; riscos de cold start.
  • Quando otimizar o modelo (quantization, distillation, pruning) antes de escalar infraestrutura.
  • Opções de deploy: cloud endpoints, edge/mobile (TFLite, TensorFlow.js) e custom containers.
  • Como Vertex AI Pipelines ajuda a automatizar treino, avaliação e promoção.
  • O papel de Cloud Build, Artifact Registry e TFX em pipelines CI/CD para ML.
  • Reconhecer os três níveis de maturidade MLOps (manual → pipeline automático → CI/CD completo) e saber que nível o cenário pede.
  • Como pensar retraining: por calendário, por evento ou por sinais de degradação.
  • Que métricas de distância usar na monitorização (L∞ e JS para categóricas, Jensen-Shannon para numéricas).
  • Model Monitoring v2 e output inference drift: monitorizar não apenas inputs, mas também a distribuição das previsões.
  • Feature attribution com SHAP values para detetar mudanças na contribuição das features.
  • Que dimensões de monitorização importam num sistema AI/ML operacional e como elas variam por tipo de modelo.
  • Porque SLOs, latência, capacidade e custo fazem parte da resposta certa.
  • Diagnosticar e responder a cenários de falha: poluição de dados, cold start de modelo e ambientes adversariais.

Praticar na documentação e nos labs oficiais

Na última parte, passamos para o bloco mais novo e mais visível do currículo atual: generative AI, Model Garden, Agent Builder, avaliação de soluções generativas e Responsible AI. Se pensas que GenAI é um mundo à parte, esta série mostra o contrário: foundation models herdam todos os problemas que já estudaste — serving, monitorização, custo, drift, governance — e acrescentam desafios próprios como grounding, hallucination e safety.

Parte anterior Treino, avaliação e operacionalização Parte 4 Serving, escala e MLOps Parte seguinte Generative AI, agentes e Responsible AI