No nosso banco de questões do MLA-C01, cerca de 30 questões tratam de como escalar endpoints e inferência baseada em contêineres, um dos maiores grupos de um único tema. O guia do exame também deixa isso claro: a tarefa 3.2 cita "políticas de escalabilidade automática de endpoints do SageMaker com base na demanda e no horário" e "escolher métricas específicas para a escalabilidade automática (latência do modelo, uso de CPU, invocações por instância)", e a tarefa 3.1 cita "escolher o destino de implantação entre endpoints do SageMaker, Kubernetes, ECS, EKS e Lambda". Saber o nome das políticas não basta; é preciso combinar a política e a métrica certas para cada situação.
Este artigo começa pelo funcionamento da escalabilidade automática e depois trata dos três tipos de política e de como combiná-los, da escolha da métrica, dos períodos de espera e limites de capacidade, dos endpoints que podem chegar a zero, da escolha do tipo de instância e dos destinos de implantação fora do SageMaker (EKS, ECS, Lambda). As diferenças básicas entre as quatro opções de inferência (em tempo real, sem servidor, assíncrona e em lote) foram tratadas antes em Infraestrutura de implantação e estratégias de escalabilidade.
---
Como Funciona a Escalabilidade Automática
O gerente de um restaurante chama mais funcionários quando os clientes lotam a casa e libera o pessoal mais cedo quando o movimento cai. Mas chamar e liberar gente com muita frequência só gera confusão, então depois de cada ajuste ele espera e observa por um tempo. A escalabilidade automática dos endpoints do SageMaker tem a mesma estrutura.
| Componente | Função | |------|------| | Métrica do CloudWatch | Mostra a carga do endpoint como um número (por exemplo, invocações por instância) | | Alarme do CloudWatch | Decide se a métrica ultrapassou o limite | | Application Auto Scaling | Calcula e ajusta o número de instâncias conforme a política | | Destino escalável | O número de instâncias de uma variante de produção, ajustado entre a capacidade mínima e a máxima |
A ordem de configuração é: registrar o destino escalável (com capacidade mínima e máxima), definir a política e aplicá-la. É preciso informar o nome do endpoint e o nome da variante, e as permissões necessárias ficam a cargo da função vinculada ao serviço do Application Auto Scaling.
!Ciclo em que métricas e alarmes do CloudWatch acionam uma política do Application Auto Scaling que ajusta o número de instâncias do endpoint entre o mínimo e o máximo
---
Os Três Tipos de Política e Como Combiná-los
| Política | Como funciona | Quando usar | |------|------|------| | Rastreamento de destino (recomendada) | Mantém a métrica perto de um valor-alvo; os alarmes são criados automaticamente | A maioria dos casos, a mais simples de configurar | | Em etapas | Adiciona um número diferente de instâncias conforme o quanto o alarme foi ultrapassado | Controle fino; obrigatória para escalar a partir de zero | | Programada | Muda a capacidade mínima e máxima em horários definidos, uma vez ou de forma recorrente | Picos previsíveis, como 9h todos os dias |
A AWS recomenda o rastreamento de destino na maioria dos casos. Por exemplo, com um alvo de 70 invocações por instância, ele adiciona instâncias quando o valor passa de 70 e remove quando cai. A escalabilidade programada não pode ser configurada no console; ela só é criada com a AWS CLI ou a API do Application Auto Scaling.
Uma resposta correta frequente no exame é a combinação de políticas. Use a escalabilidade programada para adicionar instâncias antes dos picos previsíveis, como o horário de entrada no trabalho, e deixe o rastreamento de destino acompanhar as variações inesperadas. O rastreamento de destino continua funcionando depois que uma ação programada é executada. Se várias políticas no mesmo destino entrarem em conflito, vence a que oferece mais capacidade.
Dica: "Preparar-se com antecedência para o pico de tráfego de toda segunda-feira de manhã e responder automaticamente às outras mudanças" é escalabilidade programada mais rastreamento de destino. "Escalabilidade automática com o menor esforço operacional" é uma única política de rastreamento de destino.
---
Qual Métrica Deve Guiar a Escalabilidade?
Uma métrica usada no rastreamento de destino precisa cair de forma proporcional quando você adiciona instâncias. Só assim vale a lógica de que "adicionar instâncias traz a métrica de volta ao alvo".
| Métrica | Tipo | Quando usar | |------|------|------| | InvocationsPerInstance | Métrica predefinida, resolução de 1 minuto | O padrão para endpoints em tempo real típicos | | ConcurrentRequestsPerModel e ConcurrentRequestsPerCopy | Métricas predefinidas de alta resolução, a cada 10 segundos | Picos repentinos de tráfego, LLMs que enviam a resposta como fluxo de tokens | | CPUUtilization, GPUUtilization, MemoryUtilization | Métricas personalizadas | Modelos de cálculo pesado em que a CPU ou a GPU chega primeiro ao limite | | ModelLatency | Métrica personalizada | Quando você gerencia diretamente uma meta de tempo de resposta (SLA) | | ApproximateBacklogSizePerInstance | Métrica personalizada | Tamanho da fila de um endpoint assíncrono |
As métricas de alta resolução são emitidas a cada 10 segundos, por isso escalam para fora muito mais rápido quando o tráfego cresce. A redução, porém, acontece na mesma velocidade das métricas padrão. O CPUUtilization pode passar de 100% até o número de vCPUs da instância (até 400% com 4 vCPUs), então tome cuidado ao definir o alvo.
Dica: "A escalabilidade é lenta demais diante de um salto repentino de solicitações simultâneas e surge latência" é a métrica de alta resolução de solicitações simultâneas. "O modelo esgota a GPU e fica lento" é uma métrica personalizada baseada em GPUUtilization.
---
Períodos de Espera, Limites de Capacidade e Testes de Carga
Período de Espera: Evitar que a Capacidade Oscile Demais
O período de espera (cooldown) é um tempo que adia o próximo ajuste depois que um foi feito. Se você não informar, vale o padrão de 300 segundos tanto para escalar para fora quanto para dentro.
Instâncias são adicionadas e removidas com frequência demais: aumente o período de espera As instâncias chegam tarde demais para o tráfego que cresce: reduza o período de espera de escalar para fora Reduzir devagar e ampliar rápido: deixe o período de redução mais longo que o de ampliação (por exemplo, 600 e 300 segundos)
Capacidade Mínima e Máxima
A capacidade mínima de um endpoint em tempo real comum precisa ser pelo menos 1, e quando o tráfego cai a zero o endpoint reduz até esse mínimo. O SageMaker não impõe um limite próprio ao máximo, mas ele não pode passar da cota de instâncias da conta. Para ampliar manualmente com urgência, aumente o mínimo; para reduzir, diminua o máximo.
Defina o Alvo com um Teste de Carga
O método que a AWS recomenda é descobrir com um teste de carga o número máximo de solicitações por segundo (MAX_RPS) que uma instância atende dentro da sua meta de latência e multiplicá-lo por um fator de segurança para definir o alvo.
Alvo de InvocationsPerInstance = MAX_RPS × fator de segurança × 60 Comece com um fator de segurança de 0,5 e ajuste conforme os testes
Dica: "A escalabilidade acontece com tanta frequência que as instâncias são adicionadas e removidas sem parar" se resolve aumentando o período de espera.
---
Endpoints que Podem Chegar a Zero
Manter instâncias ligadas a noite inteira para um modelo que não recebe solicitações é desperdício. Se um endpoint pode chegar a zero depende do tipo dele.
| Tipo | Chegar a zero | Como e o que observar | |------|------|------| | Endpoint em tempo real (comum) | Não | Capacidade mínima de pelo menos 1 | | Tempo real com componentes de inferência | Sim | Defina como 0 o número mínimo de instâncias; voltar a crescer a partir de zero exige uma política em etapas e um alarme, e as solicitações falham durante os minutos de provisionamento | | Endpoint assíncrono | Sim | Capacidade mínima 0, as solicitações esperam na fila; adicionar uma política em etapas HasBacklogWithoutCapacity escala na primeira solicitação | | Endpoint sem servidor | Automático | Vai a zero sozinho quando ocioso; a primeira solicitação causa uma partida a frio |
As partidas a frio da inferência sem servidor são reduzidas com a simultaneidade provisionada. A simultaneidade que você define fica pronta para uso, e esse valor pode ser ajustado com o Application Auto Scaling conforme uma métrica-alvo ou um agendamento. Os endpoints sem servidor aceitam de 1 a 6 GB de memória e simultaneidade máxima de 200 por endpoint, e não aceitam GPU, configuração de VPC, endpoints multimodelo, captura de dados nem Model Monitor.
Dica: "Solicitações raras, dá para esperar alguns minutos e as cargas são grandes" é um endpoint assíncrono que chega a zero. "Solicitações curtas e intermitentes, mas é preciso reduzir a latência da primeira resposta" é sem servidor com simultaneidade provisionada.
---
Escolher o Tipo de Instância: Inference Recommender
A escalabilidade automática decide "quantas", mas antes é preciso decidir "qual". O SageMaker Inference Recommender implanta o modelo em vários tipos de instância, executa testes de carga e dá recomendações que comparam desempenho e custo.
| Tipo de trabalho | O que faz | Duração | |------|------|------| | Padrão (Inference recommendations) | Testes de carga automáticos nas instâncias candidatas recomendadas | Normalmente em até 45 minutos | | Avançado (Endpoint recommendations) | Testes de carga personalizados em que você escolhe instâncias, padrão de tráfego e meta de latência | Cerca de 2 horas em média |
Ele funciona com endpoints em tempo real e sem servidor, e você paga apenas pelas instâncias usadas enquanto o trabalho roda. Para recursos de inferência que rodam fora do SageMaker, como EC2, Lambda e ECS no Fargate, o AWS Compute Optimizer recomenda o dimensionamento com base no histórico re