Os quatro modos de inferência e a árvore de três perguntas
- ⬜🎚️ Ajuste de hiperparâmetros e avaliação honesta(AWS ML Engineer Associate (MLA-C01))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
A decisão de maior densidade de questão da prova inteira
O SageMaker oferece quatro modos de servir um modelo, e a diferença entre eles não é de capacidade — é de perfil de tráfego e de o que você paga quando ninguém está usando. Errar o modo é o defeito de custo mais comum em ML na AWS, e é o assunto que mais rende questão por página estudada.
| Modo | Paga por | Perfil de tráfego | Limite que decide |
|---|---|---|---|
| Tempo real | Instância viva, por hora | Contínuo, resposta em milissegundos | Paga mesmo ocioso — inviável para uso esporádico |
| Sem servidor | Invocação e duração | Intermitente, com pausas longas | Partida a frio; teto de memória e de carga |
| Assíncrono | Instância, com escala a zero | Carga grande, resposta demorada por requisição | Fila interna; resposta não é imediata |
| Lote | Só o processamento do trabalho | Volume fechado, sem urgência | Não serve pedido individual sob demanda |
A árvore de decisão em três perguntas
Primeira: o pedido é individual e sob demanda, ou é um conjunto fechado? Conjunto fechado é LOTE, e acaba aqui. Segunda: a resposta precisa ser imediata? Se não, e a carga é grande ou o processamento é longo, é ASSÍNCRONO. Terceira: o tráfego é contínuo? Contínuo é TEMPO REAL; intermitente com pausas longas é SEM SERVIDOR.
As armadilhas de cada modo
- Tempo real: manter endpoint de pé para um modelo chamado dez vezes por dia. É o desperdício clássico, e a prova o apresenta sempre com o mesmo enunciado — "o endpoint fica ocioso a maior parte do tempo".
- Sem servidor: partida a frio. A primeira invocação depois de um período ocioso carrega o modelo e demora; se o requisito exige latência baixa e previsível SEMPRE, esse modo cai fora, por mais que o perfil de tráfego combine.
- Assíncrono: confundir com sem servidor. Ele escala a zero também, mas existe para carga grande e processamento longo, com fila — não para reduzir custo de tráfego pequeno.
- Lote: tentar usá-lo para atender usuário. Ele não expõe endpoint; se alguém está esperando a resposta na tela, não é lote.
Vários modelos no mesmo endpoint é uma quinta opção, e ela cai
Quando há dezenas de modelos pequenos e semelhantes — um por cliente, por exemplo — mantê-los em endpoints separados multiplica o custo ocioso por dezenas. Um endpoint com vários modelos os carrega sob demanda na mesma infraestrutura. A contrapartida é latência maior no primeiro pedido de um modelo que não está carregado, que é a mesma família de problema da partida a frio.
from sagemaker.serverless import ServerlessInferenceConfig
from sagemaker.async_inference import AsyncInferenceConfig
# 1. Tempo real — tráfego contínuo. Paga instância viva 24 h.
modelo.deploy(initial_instance_count=1, instance_type="ml.m5.large")
# 2. Sem servidor — rajada com pausas longas. Paga invocação; custo zero parado.
# A contrapartida é a partida a frio, que elimina este modo quando o requisito
# exige latência baixa e PREVISÍVEL sempre.
modelo.deploy(serverless_inference_config=ServerlessInferenceConfig(
memory_size_in_mb=4096, max_concurrency=10))
# 3. Assíncrono — carga grande, processamento longo POR REQUISIÇÃO. Fila interna.
modelo.deploy(initial_instance_count=1, instance_type="ml.m5.xlarge",
async_inference_config=AsyncInferenceConfig(
output_path="s3://lago/saidas-async/"))
# Escala a zero sem perder a fila:
predictor.update_endpoint(min_capacity=0, max_capacity=4)
# 4. Lote — volume fechado, sem urgência. Sobe, processa, morre.
transformer = modelo.transformer(instance_count=4, instance_type="ml.m5.xlarge",
output_path="s3://lago/previsoes/")
transformer.transform("s3://lago/curado/diario/", content_type="text/csv")Um modelo de recomendação é chamado em rajadas curtas, algumas vezes por dia, com longos períodos sem nenhuma chamada. A restrição declarada é custo. Qual modo?
Estratégias de implantação sem derrubar ninguém
| Estratégia | Como funciona | Custo | Quando |
|---|---|---|---|
| Tudo de uma vez | Substitui a versão de imediato | Menor | Ambiente sem tráfego crítico |
| Canário | Fração pequena do tráfego vai para o novo | Duas versões por um período | Padrão quando há risco e métrica para observar |
| Linear | Aumenta a fração em degraus | Duas versões por mais tempo | Quando o efeito só aparece com volume |
| Azul e verde | Duas frotas completas, troca instantânea | Dobro durante a janela | Reversão precisa ser imediata |
O que a prova cobra aqui não é a definição, é o par estratégia-e-alarme: implantação gradual sem alarme configurado não é gradual coisa nenhuma, porque nada dispara a reversão. Quando o cenário menciona reversão automática, a resposta precisa incluir o alarme que a aciona.
Uma equipe mantém 60 modelos pequenos, um por cliente, cada um em seu endpoint em tempo real. A conta está alta e a maioria dos endpoints fica ociosa. Qual mudança resolve?
Um requisito diz que a latência precisa ser baixa e PREVISÍVEL em toda chamada, mesmo após períodos ociosos. Qual modo é eliminado por esse requisito?
Próximo passo
Com o modelo servindo no modo certo, o passo seguinte é tornar tudo o que veio antes repetível: o fluxo do dado bruto ao endpoint, versionado e disparável sem ninguém abrir um caderno.
Perguntas frequentes
❓ Quais são os modos de inferência do SageMaker e quando usar cada um?
❓ Qual a diferença entre inferência sem servidor e assíncrona no SageMaker?
❓ Como reduzir custo quando há muitos modelos pequenos em endpoints separados?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…