Observabilidade Completa para Inferência de LLMs no Amazon SageMaker AI: Do Uso de GPU à Qualidade das Respostas

Por que observabilidade de LLMs é diferente do monitoramento tradicional

Colocar modelos de linguagem grande (LLMs) em produção no Amazon SageMaker AI Inference traz um desafio que vai além do monitoramento convencional de software. Aplicações tradicionais retornam saídas determinísticas — você sabe exatamente o que esperar. LLMs, por outro lado, geram respostas livres e variáveis que não se encaixam em alertas do tipo “erro 500” ou “latência acima de X ms”.

A qualidade das respostas pode degradar silenciosamente ao longo do tempo, à medida que a distribuição dos prompts muda ou o contexto de uso evolui. Ao mesmo tempo, a infraestrutura de serving tem suas próprias complexidades: consumo imprevisível de tokens, pressão na memória da GPU e picos de latência tornam o planejamento de capacidade e o controle de custos um alvo em constante movimento.

Diante desse cenário, a AWS publicou uma abordagem de observabilidade abrangente para inferência de LLMs, estruturada em duas dimensões complementares: quantidade (saúde operacional da infraestrutura) e qualidade (desempenho dos próprios modelos). Neste artigo, a CloudTroop explica como essa solução funciona e o que ela oferece para times de ML em produção.

As duas dimensões da observabilidade de LLMs

A AWS organiza a observabilidade de LLMs em dois eixos que, embora distintos, precisam ser monitorados juntos:

• Monitoramento de quantidade: foca na saúde operacional da infraestrutura de inferência — throughput de requisições, utilização de recursos, latência, erros e custos. Ajuda a detectar gargalos, dimensionar corretamente os recursos e controlar gastos.
• Monitoramento de qualidade: avalia o desempenho dos próprios LLMs — precisão das respostas, conformidade, segurança e consistência ao longo do tempo. Detecta drift de modelo, degradação ou comportamentos inesperados nas respostas geradas.

Os dois eixos são interdependentes: um endpoint pode estar operacionalmente saudável enquanto produz respostas ruins ou inseguras. Da mesma forma, um modelo pode entregar respostas de alta qualidade enquanto roda em infraestrutura superdimensionada e cara. A observabilidade de produção só é completa quando as duas dimensões são monitoradas, correlacionadas e otimizadas juntas.

Arquitetura da solução

A solução descrita pela AWS combina três serviços principais, cada um com um papel específico:

• Amazon SageMaker AI Inference Components: camada de hospedagem dos modelos. Um único endpoint SageMaker AI pode hospedar múltiplos componentes de inferência, cada um rodando um LLM diferente (como gpt-oss-20b e Qwen2.5-7B-Instruct). Cada componente mantém isolamento próprio para roteamento de tráfego, políticas de escalabilidade e atribuição de métricas.
• Amazon CloudWatch: repositório centralizado de métricas. Recebe dois fluxos distintos de dados de cada componente de inferência: métricas aprimoradas (enhanced metrics) e métricas customizadas de qualidade.
• Amazon Managed Grafana: camada de visualização, usando o CloudWatch como fonte de dados nativa. Dois dashboards dedicados expõem as métricas de quantidade e qualidade dos LLMs servidos nos endpoints SageMaker AI.

Os dois namespaces no CloudWatch

O CloudWatch organiza os dados em dois namespaces separados, mantendo os sinais operacionais e de qualidade bem distintos:

• /aws/sagemaker/InferenceComponents/<nome-do-modelo> — métricas aprimoradas publicadas automaticamente pelo SageMaker AI quando habilitadas na configuração do endpoint. Incluem dimensões por instância, por contêiner e por GPU, oferecendo visibilidade granular sobre contagens de invocação, latência, taxas de erro e utilização de GPU/CPU por modelo. Para mais detalhes, consulte a documentação oficial de métricas aprimoradas do SageMaker AI e o post de aprofundamento sobre enhanced metrics.
• /aws/sagemaker/inference-quality/<nome-do-modelo> — métricas customizadas de qualidade, como scores compostos de qualidade, scores de segurança e latência de avaliação. São publicadas em um namespace separado configurado pelo usuário, mantendo os sinais de qualidade isolados das métricas operacionais.

Monitoramento de quantidade: visibilidade operacional

O monitoramento de quantidade responde às perguntas operacionais críticas para quem opera endpoints multi-modelo: quantas requisições cada modelo está servindo? As GPUs estão bem dimensionadas ou superprovisionadas? Qual modelo está gerando mais custo?

O dashboard de quantidade no Amazon Managed Grafana — que usa o CloudWatch como fonte de dados nativa — cobre três áreas principais:

1. Invocações e latência dos LLMs

Painéis exibem a latência do modelo como série temporal, o total de invocações comparando os modelos (por exemplo, gpt-oss versus Qwen) e as invocações por cópia de cada modelo. Esses painéis ajudam operadores a entender padrões de throughput de requisições, identificar picos de latência e comparar a distribuição de invocações entre as cópias dos modelos.

2. Utilização de GPU: compute e memória

Painéis dedicados mostram o percentual de uso de GPU Compute e GPU Memory para cada modelo. Essa comparação entre modelos permite que engenheiros de ML e equipes de Engenharia de Confiabilidade de Site (SRE) determinem rapidamente se um problema de desempenho é limitado por compute de GPU ou por memória, e se um modelo está consumindo recursos desproporcionais na infraestrutura compartilhada.

3. Uso do endpoint e custos

Uma visão de cluster exibe GPUs em uso versus GPUs livres e o total de instâncias, ao lado de painéis de custo por hora para cada modelo. Essa visão mostra qual modelo está gerando mais custo, se as GPUs estão superprovisionadas ou saturadas, e se as políticas de auto scaling estão respondendo à demanda.

Para configurar esses dashboards no seu ambiente, a AWS disponibilizou um notebook de exemplo no repositório GitHub, que pode ser estendido para criar dashboards adaptados às necessidades da sua organização.

Monitoramento de qualidade: os LLMs ainda estão performando bem?

Enquanto as métricas de quantidade dizem se a infraestrutura está saudável, as métricas de qualidade respondem se os LLMs ainda estão se comportando como esperado. A degradação de qualidade raramente dispara alertas tradicionais — ela acontece silenciosamente, causada por mudanças na distribuição dos prompts, drift de conceito ou alterações nas condições do mundo real.

O monitoramento de qualidade avalia as saídas dos modelos em dimensões que importam para o negócio:

• Qualidade das respostas: relevância para as perguntas dos usuários, precisão factual, completude e consistência.
• Segurança e conformidade: detecção de conteúdo prejudicial, monitoramento de viés, conformidade com privacidade e regulatórios.
• Qualidade da experiência do usuário: utilidade, clareza, tom adequado e coerência em conversas multi-turno.
• Qualidade específica do domínio: precisão técnica em domínios especializados, qualidade de citações em aplicações de Geração Aumentada por Recuperação (RAG) e correção de código em assistentes de programação.

Os quatro scores de qualidade no dashboard

O dashboard de qualidade no Grafana acompanha quatro scores para cada modelo (como gpt-oss-20b e Qwen2.5-7B-Instruct), cada um exibido como gráfico de linha temporal com thresholds de alerta configuráveis:

• Score Composto de Qualidade: indicador agregado que combina múltiplas dimensões de qualidade. Facilita identificar degradação sustentada versus quedas pontuais que podem estar correlacionadas com tipos específicos de prompt.
• Score de Segurança: monitora detecção de conteúdo prejudicial ou não conforme. Tende a ser o mais estável dos quatro, indicando guardrails de segurança confiáveis.
• Score de Relevância: mede o quanto as respostas do LLM atendem à intenção do usuário, ajudando a identificar categorias de prompts que podem desafiar a compreensão do modelo.
• Score de Tom Profissional: avalia se as respostas mantêm um tom adequado para o contexto de uso.

Esses scores são calculados usando o padrão LLM-as-judge (LLM como avaliador), com rubricas de avaliação configuráveis. Na solução de exemplo da AWS, o modelo Anthropic Claude Sonnet 4.6, servido via Amazon Bedrock, é utilizado como avaliador — uso permitido pelos termos de serviço padrão do Amazon Bedrock para casos de LLM-as-judge. É possível substituir por outro sistema de avaliação, desde que os termos do modelo escolhido permitam avaliar saídas de outros modelos, os requisitos de residência de dados sejam atendidos e o modelo avaliador seja fixado em uma versão específica para manter a comparabilidade dos scores ao longo do tempo.

Alertas automáticos por componente de inferência

Além da visualização, regras de alerta baseadas em thresholds são implantadas automaticamente via Grafana Alerting, dimensionadas por componente de inferência — ou seja, os alertas disparam separadamente para cada modelo. Quando um score de qualidade ultrapassa o threshold configurado, notificações são enviadas via Amazon Simple Notification Service (SNS), permitindo triagem rápida pelas equipes de SRE.

Esses alertas podem ser integrados a ferramentas como Slack, PagerDuty ou OpsGenie, correlacionando logs automaticamente, classificando a severidade do alerta e priorizando incidentes para mitigação.

Para configurar o dashboard de qualidade e entender melhor as métricas disponíveis, a AWS disponibilizou um notebook dedicado no repositório GitHub.

Conclusão

Observabilidade de stacks de inferência de LLMs em produção exige muito mais do que monitorar uptime e taxas de erro. A abordagem publicada pela AWS demonstra que uma estratégia completa precisa endereçar duas dimensões complementares: quantidade, que cobre a saúde operacional da infraestrutura (utilização de GPU, atribuição de custos, comportamento de escalabilidade e throughput de requisições), e qualidade, que cobre o desempenho contínuo dos modelos (relevância das respostas, conformidade de segurança, precisão factual e tom).

Ao combinar as métricas aprimoradas dos endpoints SageMaker AI, o Amazon CloudWatch e o Amazon Managed Grafana, é possível construir uma camada de observabilidade unificada sem instrumentação customizada. As métricas aprimoradas oferecem granularidade por modelo e por GPU em infraestrutura compartilhada. O CloudWatch centraliza tanto os sinais operacionais quanto os de qualidade. O Grafana une tudo em dashboards que atendem diferentes stakeholders: equipes de SRE monitorando saturação de recursos, times de governança acompanhando thresholds de segurança e conformidade, e donos de produto comparando qualidade entre modelos.

Para começar, o repositório de exemplos no GitHub da AWS inclui notebooks para configurar métricas aprimoradas, publicar métricas customizadas de qualidade e alertas, e configurar os dashboards Grafana apresentados neste post.

Fonte

Comprehensive observability for Amazon SageMaker AI LLM inference: From GPU utilization to LLM quality (https://aws.amazon.com/blogs/machine-learning/comprehensive-observability-for-amazon-sagemaker-ai-llm-inference-from-gpu-utilization-to-llm-quality/)