O desafio de monitorar inferência de IA generativa em escala
Operar endpoints de Grandes Modelos de Linguagem (LLMs) em produção é uma tarefa complexa. Quando a latência P99 de um endpoint dispara, a equipe precisa descobrir em minutos se o problema é pressão na memória da GPU, saturação do cache KV, tráfego desbalanceado entre Zonas de Disponibilidade (AZs) ou uma política de auto scaling que ainda não foi ativada. Engenheiros de plataforma de Aprendizado de Máquina (ML), times de Operações de ML (MLOps) e Engenheiros de Confiabilidade de Site (SREs) precisam manter endpoints saudáveis, responsivos e com custo eficiente — muitas vezes gerenciando dezenas de modelos em centenas de instâncias de GPU.
Para endereçar esse cenário, a AWS anunciou uma expansão significativa nas capacidades de observabilidade do Amazon SageMaker AI: mais de 100 novas métricas detalhadas de inferência, além de um dashboard nativo integrado ao Amazon CloudWatch chamado SageMaker Insights.
Arquiteturas de endpoint suportadas
O SageMaker AI oferece hospedagem gerenciada de inferência em tempo real. Ao implantar um modelo em um endpoint do SageMaker, o serviço cuida do provisionamento e do escalonamento das instâncias. Existem duas arquiteturas principais relevantes para cargas de trabalho de IA generativa com observabilidade detalhada:
- Endpoints de modelo único (SME — Single-Model Endpoint): cada endpoint hospeda um modelo em instâncias dedicadas. São simples de configurar, mas cada modelo exige sua própria frota de GPUs.
- Endpoints com componentes de inferência (IC — Inference Component): múltiplos modelos compartilham o mesmo conjunto de instâncias por meio de componentes de inferência. Cada componente define um modelo, seus requisitos de recursos (CPU, GPU, memória) e sua política de escalonamento. Essa é a arquitetura recomendada para produção, pois suporta hospedagem multi-modelo em infraestrutura GPU compartilhada, escalonamento independente por modelo e alta disponibilidade (HA) com distribuição de cópias entre AZs.
Para mais detalhes sobre inferência no SageMaker, consulte a documentação Implante modelos para inferência em tempo real.
O que são as novas métricas detalhadas
Anteriormente, os endpoints do SageMaker emitiam métricas agregadas como contagens de invocação, latência do modelo e latência de overhead. Úteis para uma visão geral, mas insuficientes para diagnóstico profundo em frotas de GPU com múltiplos modelos.
Agora, o SageMaker AI emite mais de 100 métricas detalhadas de inferência cobrindo: saúde da GPU, latência no nível de token, pressão no cache KV, distribuição de tráfego entre AZs, posicionamento de componentes de inferência e diagnósticos de cold start. Essas métricas utilizam o formato nativo OpenTelemetry e fluem para o CloudWatch, onde ficam disponíveis no dashboard SageMaker Insights — sem necessidade de configurar Grafana ou Prometheus manualmente. Para entender o suporte a OpenTelemetry e PromQL no CloudWatch, veja o post Introduzindo suporte a OpenTelemetry PromQL no Amazon CloudWatch.
O dashboard SageMaker Insights fica localizado no console do CloudWatch em Infrastructure Monitoring → SageMaker Insights e organiza as visualizações em três abas: Performance, Capacity e Reliability.
Pré-requisitos
Para utilizar as métricas detalhadas, são necessários: uma conta AWS com pelo menos um endpoint de inferência em tempo real do SageMaker; permissões de Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management) para sagemaker:CreateEndpointConfig, sagemaker:UpdateEndpoint e cloudwatch:GetMetricData; e o framework de container vLLM ou SGLang (necessário para métricas no nível de token, como Tempo para o Primeiro Token (TTFT — Time to First Token) e Latência Entre Tokens (ITL — Inter-Token Latency)). Instâncias de GPU recebem métricas de utilização por acelerador, além das métricas de CPU e memória disponíveis em todos os tipos de instância. Para o guia completo de configuração, consulte Primeiros passos com observabilidade detalhada.
Ativando métricas detalhadas nos endpoints
Novos endpoints: ativação automática
Para qualquer nova configuração de endpoint criada, as métricas detalhadas já vêm ativadas por padrão. O parâmetro EnableDetailedObservability na configuração do endpoint assume o valor true automaticamente. Nenhum código adicional é necessário:
import boto3
sm = boto3.client("sagemaker")
# Create endpoint config — observability turned on by default
response = sm.create_endpoint_config(
EndpointConfigName="my-llm-config",
ProductionVariants=[{
"VariantName": "primary",
"InstanceType": "ml.g6.4xlarge",
"InitialInstanceCount": 2,
"ManagedInstanceScaling": {
"Status": "ENABLED",
"MinInstanceCount": 2,
"MaxInstanceCount": 8
}
}],
ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerExecutionRole"
)Também é possível definir explicitamente a frequência de publicação usando MetricsPublishFrequencyInSeconds no MetricsConfig. O padrão é 60 segundos, mas para cargas de trabalho que precisam de monitoramento quase em tempo real, esse valor pode ser reduzido.
# Create endpoint
sm.create_endpoint(
EndpointName="my-llm-endpoint",
EndpointConfigName="my-llm-config"
)Dentro de 2 minutos após o endpoint atingir o estado InService, as métricas no formato OpenTelemetry começam a fluir para o CloudWatch.
Endpoints existentes: opt-in explícito
Endpoints já existentes exigem uma ativação explícita. É necessário criar uma nova configuração de endpoint com a flag MetricsConfig e então atualizar o endpoint:
# Step 1: Create new config with detailed observability turned on
sm.create_endpoint_config(
EndpointConfigName="my-existing-config-v2",
ProductionVariants=[{
"VariantName": "primary",
"ModelName": "my-existing-model",
"InstanceType": "ml.g6.4xlarge",
"InitialInstanceCount": 2
}],
MetricsConfig={"EnableDetailedObservability": True},
ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerExecutionRole"
)
# Step 2: Update endpoint
sm.update_endpoint(
EndpointName="my-existing-endpoint",
EndpointConfigName="my-existing-config-v2"
)O console do SageMaker também disponibiliza um assistente guiado de três etapas para ativar a observabilidade detalhada: aprender sobre as métricas, ativar o enriquecimento OpenTelemetry (OTel) e selecionar quais endpoints incluir.
Enriquecimento OTel para métricas clássicas do CloudWatch
As métricas nativas OpenTelemetry fluem automaticamente para o CloudWatch após a ativação. Porém, as métricas clássicas já existentes (como Invocations, ModelLatency e OverheadLatency) precisam de enriquecimento OTel para aparecer no dashboard SageMaker Insights e serem consultáveis via PromQL. Essa configuração é feita uma única vez, no nível de conta e região, acessando o console do CloudWatch em Settings e ativando o enriquecimento de métricas OTel e as tags de recursos para telemetria.
Navegando pelo dashboard SageMaker Insights
O dashboard pode ser acessado tanto pelo console do SageMaker quanto pelo console do CloudWatch. Dentro do SageMaker, há três pontos de entrada com filtros pré-aplicados:
- Página de listagem de endpoints → “Open SageMaker Insights”: visão geral de toda a frota.
- Página de detalhes do endpoint → “View in SageMaker Insights”: filtrado para aquele endpoint específico.
- Aba de IC → link “Metrics” por IC: filtrado para o endpoint e o componente de inferência específico.
Aba Performance: saúde da frota e depuração de latência
A aba Performance é onde a maior parte das equipes passa o tempo. Ela responde perguntas como “Está tudo funcionando bem?” e “Se não, qual componente é o problema?”
A visualização em hexágonos coloridos mostra cada recurso da frota: verde indica estado OK, branco indica sem alarmes, e vermelho indica alarme ativo. Ao passar o cursor sobre um hexágono, são exibidos tipo de instância, TTFT, Tokens por Segundo (TPS) de saída, requisições concorrentes, utilização do cache KV e status de alarme no CloudWatch.
O painel Token streaming plota o TTFT e o ITL ao longo do tempo com alternância entre P50 e P99. O TTFT mede quanto tempo o usuário espera antes de ver o primeiro caractere da resposta; o ITL mede o tempo entre tokens consecutivos, impactando diretamente a fluidez do streaming.
Quando um pico de TTFT é identificado, o painel Latency breakdown ajuda a atribuir a causa: ele separa a latência total em Latência do Modelo (tempo de processamento pelo modelo) e Latência de Overhead (tempo de roteamento e agendamento pela plataforma). Se ambas estiverem normais mas o TTFT ainda estiver elevado, o motor de inferência pode estar enfileirando requisições internamente — por exemplo, aguardando slots no cache KV. O painel Engine and request pressure confirma esse diagnóstico.
O painel Traffic distribution mostra o fluxo de requisições por instância ou por componente de inferência com filtro por AZ. Se uma AZ apresenta zero tráfego enquanto as outras estão sobrecarregadas, isso indica um problema de roteamento ou posicionamento.
O painel Token throughput mede tokens processados por segundo, divididos por entrada/saída, percentis ou por instância. Se uma instância ml.g6.4xlarge entrega 150 tokens por segundo quando o benchmark do modelo indica 500, isso sinaliza restrição de recurso, problema de configuração ou pressão no cache KV.
Aba Capacity: planejamento e gestão de recursos
A aba Capacity responde perguntas como “Tenho recursos suficientes?”, “Onde há folga?” e “Consigo adicionar outro modelo?” A mesma visualização em hexágonos reaparece aqui, agora exibindo percentuais de utilização de GPU, memória de GPU, CPU, memória de CPU e disco no hover.
O painel Fleet utilization over time mostra tendências de consumo de recursos. Memória de GPU crescendo continuamente ao longo de dias indica que os limites de capacidade estão sendo atingidos; uma queda repentina indica que um modelo travou ou foi descarregado. Picos de disco recorrentes correlacionam com downloads de modelo durante cold starts.
Aba Reliability: alta disponibilidade e resiliência
A aba Reliability responde perguntas como “Se uma AZ cair, minha frota de inferência sobrevive?”, “Os eventos de scaling estão funcionando?” e “Por que os cold starts estão lentos?”
O gráfico de barras de Availability Zone distribution mostra a contagem de instâncias e cópias de IC por AZ. Distribuição uniforme entre 3 ou mais AZs representa baixo risco; concentração em 1-2 AZs representa risco médio; ausência de instâncias em qualquer AZ representa alto risco — uma falha de AZ pode tirar o endpoint do ar.
O painel Cold start anatomy exibe cada evento de provisionamento de IC como uma barra horizontal empilhada com quatro fases: download do modelo (azul), carga na GPU (roxo), inicialização do container (laranja) e overhead da plataforma (cinza). Esse painel indica qual fase otimizar para reduzir tempos de resposta ao escalonamento.
O painel ICE diagnostics rastreia erros de capacidade insuficiente (ICE — Insufficient Capacity Errors), que ocorrem quando o SageMaker não consegue provisionar as instâncias solicitadas. A tabela mostra quando a falha ocorreu, qual endpoint foi afetado, qual tipo de instância estava indisponível e qual AZ não tinha capacidade. Se todos os eventos ICE forem para um único tipo de instância em todas as AZs, isso indica esgotamento regional completo para aquele tipo — sinal para migrar para outros tipos de instância como fallback.
Conectando sua ferramenta de observabilidade existente
Para times que já utilizam Grafana ou outras ferramentas compatíveis com PromQL, é possível consultar as métricas do SageMaker Insights diretamente, sem precisar acessar o console do CloudWatch.
O processo envolve quatro etapas:
- Passo 1: Obter a URL do endpoint PromQL no console do SageMaker (Endpoints → selecione o endpoint → Connect to your observability tool).
- Passo 2: Configurar a fonte de dados no Grafana (Amazon Managed Grafana 2.4+ ou Grafana auto-hospedado com plugin Amazon Managed Service for Prometheus v3.0.0+), usando a URL obtida e autenticação SigV4 com uma role IAM que tenha permissões
cloudwatch:GetMetricDataecloudwatch:ListMetrics. - Passo 3: Importar o template de dashboard pré-construído disponível na mesma página “Connect to your observability tool” do console do SageMaker.
- Passo 4: Escrever queries PromQL customizadas conforme necessário. Exemplos:
# KV cache
vllm:kv_cache_usage_perc{"aws.sagemaker.endpoint.name"="ep-prsn-ic","aws.sagemaker.inference_component.name"="ic-qwen3-4b"}
# Active requests
vllm:num_requests_running{"aws.sagemaker.endpoint.name"="ep-prsn-ic","aws.sagemaker.inference_component.name"="ic-qwen3-4b"}
# TTFT P99
histogram_quantile(0.99, rate(vllm:time_to_first_token_seconds{"aws.sagemaker.endpoint.name"="ep-prsn-ic","aws.sagemaker.inference_component.name"="ic-qwen3-4b"}[5m]))Para mais detalhes, consulte a documentação Conecte seu workspace Grafana pelo endpoint PromQL.
Preços
O SageMaker não cobra separadamente pela emissão das métricas detalhadas de observabilidade. As métricas são publicadas no Amazon CloudWatch no formato OpenTelemetry, e a precificação padrão de ingestão OpenTelemetry do CloudWatch se aplica: US$ 0,50 por GB ingerido. Se o enriquecimento de métricas vended OTel for ativado (necessário para visualizar métricas clássicas como Invocations e ModelLatency no dashboard Insights), as métricas enriquecidas também são cobradas a US$ 0,50 por GB. Para exemplos detalhados de precificação e uma calculadora de custos, consulte a seção OpenTelemetry Metrics na página de preços do Amazon CloudWatch.
Limpeza dos recursos
Para evitar cobranças contínuas após testes, exclua os recursos na seguinte ordem:
# Delete inference components first (if IC endpoint)
aws sagemaker delete-inference-component --inference-component-name my-ic
# Delete endpoints
aws sagemaker delete-endpoint --endpoint-name my-endpoint
# Wait for deletion, then delete configs
aws sagemaker delete-endpoint-config --endpoint-config-name my-configInstâncias de GPU são cobradas por segundo enquanto os endpoints estão no estado InService. Exclua-os imediatamente após os testes.
Próximos passos
Com as novas métricas detalhadas e o dashboard SageMaker Insights, times de MLOps e engenharia de plataforma ganham visibilidade profunda sobre frotas de inferência de IA generativa — desde saúde da GPU até diagnósticos de cold start e distribuição de tráfego entre AZs. Para começar:
- Ative a observabilidade detalhada nos seus endpoints e verifique se os dados estão fluindo para o CloudWatch.
- Navegue pelo dashboard SageMaker Insights e explore as abas Performance, Capacity e Reliability.
- Conecte seu workspace Grafana pelo endpoint PromQL e importe o template de dashboard pré-construído.
Fonte
Monitor and debug generative AI inference with SageMaker detailed metrics and Insights dashboard on CloudWatch (https://aws.amazon.com/blogs/machine-learning/monitor-and-debug-generative-ai-inference-with-sagemaker-detailed-metrics-and-insights-dashboard-on-cloudwatch/)
Leave a Reply