Observabilidade de LLMs em Produção: Do GPU à Qualidade da Resposta

A maioria dos times que implanta LLMs no SageMaker começa com o mesmo conjunto de métricas que usaria para qualquer endpoint de ML: Invocations, ModelLatency, OverheadLatency e Invocation4XXErrors. Isso é necessário, mas completamente insuficiente para inferência de linguagem.

A primeira camada de cegueira é a infraestrutura de GPU. Um endpoint ml.g5.12xlarge com 4xA10G pode estar com GPUUtilization em 40% enquanto o GPUMemoryUtilization está em 95% — o modelo está thrashing na VRAM, causando latência de P99 de 8s enquanto o P50 parece saudável em 1.2s. Sem separar essas duas métricas por instância e por modelo carregado, você vai escalar horizontalmente quando o problema é vertical (batch size, quantização, tensor parallelism).

A segunda camada é a semântica de tokens. ModelLatency mede do request ao response, mas não distingue Time to First Token (TTFT) de Inter-Token Latency (ITL). Para um usuário interagindo com um chat financeiro, TTFT de 3s é inaceitável mesmo que o throughput total seja alto. O LMI (Large Model Inference) container do SageMaker expõe TimeToFirstByte via CloudWatch, mas só se você configurar OPTION_OUTPUT_FORMATTER=jsonlines e instrumentar o cliente para registrar o timestamp do primeiro chunk.

A terceira camada — e a mais negligenciada — é a qualidade semântica. O modelo pode estar respondendo rápido, com GPU eficiente, e ainda assim produzindo respostas com hallucinations, recusas excessivas ou drift de tom que viola políticas de compliance. Isso só é detectável com avaliação assíncrona pós-geração.

O container LMI do SageMaker (baseado em DJL Serving) expõe métricas de token via o endpoint /metrics do servidor interno, mas elas não chegam automaticamente ao CloudWatch. A abordagem que funciona em produção é um sidecar OTEL Collector rodando no mesmo task definition (para SageMaker Multi-Container) ou como um Lambda invocado assincronamente pelo próprio endpoint via destino de invocação.

As métricas críticas a capturar são:

• ttft_ms (Time to First Token): P50/P95/P99 por modelo e por request_type
• itl_ms (Inter-Token Latency): distribuição — alta variância aqui indica contenção de GPU
• tokens_per_second: throughput real de geração, não confundir com invocações por segundo
• prompt_tokens e completion_tokens: essenciais para custo e para detectar prompt injection que infla o contexto
• cache_hit_rate: se você usa KV-cache com prefix caching (disponível no TGI e vLLM backends do LMI)

Para publicar essas métricas no CloudWatch com dimensões corretas, use put_metric_data com namespace LLMInference/SageMaker e dimensões ModelName, EndpointName e InstanceType. O custo de métricas customizadas no CloudWatch é $0.30/métrica/mês — com 6 métricas × 3 dimensões × 2 endpoints, estamos falando de ~$10/mês, completamente justificável.

Um detalhe crítico: configure SAGEMAKER_CONTAINER_LOG_LEVEL=20 (INFO) no endpoint e ative DataCaptureConfig com SamplingPercentage=100 para ambientes de staging e SamplingPercentage=10 para produção com alto volume. Capturar 100% em produção com modelos grandes pode gerar custos de S3 e Firehose significativos.

O padrão de usar um LLM para avaliar outro LLM (LLM-as-judge) é poderoso, mas tem falhas específicas que eu já vi causar falsos positivos de qualidade em produção financeira.

O primeiro problema é o viés de posição: modelos como Claude tendem a avaliar melhor respostas mais longas, independentemente da precisão. Para mitigar, use rubricas estruturadas com scoring por dimensão (factualidade: 1-5, completude: 1-5, tom: 1-5) em vez de um score único. Inclua exemplos few-shot no prompt do juiz com casos de respostas curtas e corretas que devem pontuar alto.

O segundo problema é o custo de avaliação em escala. Avaliar 100% das inferências com Claude 3 Sonnet é proibitivo — para um endpoint processando 10.000 requests/dia com resposta média de 300 tokens, o custo seria ~$180/dia só em avaliação. A estratégia correta é amostragem estratificada: 100% de amostras com score de confiança baixo (detectado por entropia do logit, se disponível), 10% aleatório do restante, e 100% de qualquer request que acionou um guardrail.

O terceiro problema é drift do juiz: o modelo juiz também pode mudar com atualizações de versão do Bedrock. Use model versioning explícito (anthropic.claude-3-haiku-20240307-v1:0) e nunca claude-3-haiku sem versão em produção. Mantenha um golden dataset de 200 pares prompt/resposta com scores humanos para recalibrar o juiz mensalmente — isso é equivalente ao teste de regressão de um sistema de ML clássico.

Para ambientes com requisitos de soberania de dados (LGPD, regulação bancária brasileira), o pipeline de avaliação deve garantir que dados de clientes não saiam do boundary de VPC. Use Bedrock via VPC endpoint (com.amazonaws.region.bedrock-runtime) e nunca roteie logs de inferência por redes públicas.

O pipeline de observabilidade de LLM é, paradoxalmente, uma superfície de ataque. Os logs de DataCapture contêm prompts e respostas completas — em contexto financeiro, isso pode incluir dados de clientes, números de conta, análises de portfólio. Tratar esse pipeline com menos rigor do que o endpoint em si é um erro grave.

As camadas de controle que implemento obrigatoriamente:

Criptografia em trânsito e em repouso: O bucket S3 de DataCapture deve ter SSE-KMS com chave CMK separada do endpoint. A política da chave deve permitir decrypt apenas para a role do Lambda avaliador e para a role de auditoria — não para a role do endpoint em si (princípio de separação de duties).

Mascaramento de PII antes da avaliação: O Lambda avaliador deve passar o texto por Amazon Comprehend detect_pii_entities antes de enviar para o Bedrock judge. Substitua entidades PII por placeholders ([ACCOUNT_NUMBER], [CPF]) no payload de avaliação. Isso garante que dados sensíveis não entrem no contexto do modelo avaliador.

IAM com condições de contexto: A role do Lambda avaliador deve ter bedrock:InvokeModel com condição aws:SourceVpc restrita ao VPC do pipeline. Adicione aws:RequestedRegion para garantir que invocações só ocorram na região primária — relevante para compliance com BACEN e LGPD que exigem processamento em território nacional.

Auditoria de acesso aos logs: Configure CloudTrail com S3 data events no bucket de DataCapture. Qualquer acesso ao bucket deve gerar evento auditável. Em ambientes com SOC 2 ou ISO 27001, isso é requisito de controle, não opcional.

Um detalhe que frequentemente é esquecido: o endpoint SageMaker em si deve ter KmsKeyId configurado no ProductionVariant para criptografar o volume EBS da instância. Sem isso, os pesos do modelo e o KV-cache ficam em disco não criptografado.

Definir um SLO de qualidade para LLM é conceitualmente simples — 'quality score > 0.75 em 95% das respostas' — mas operacionalizar isso em CloudWatch com burn rate alerts exige uma arquitetura de dados específica.

O problema é que quality scores são produzidos assincronamente (pelo Lambda avaliador, segundos ou minutos após a resposta original), enquanto SLOs de latência são síncronos. Para unificar no mesmo framework de SLO, você precisa de uma janela de avaliação diferida: o SLO de qualidade opera sobre uma janela de 1 hora com delay de 5 minutos (tempo de avaliação), não em tempo real.

A implementação prática usa DynamoDB Streams: quando o Lambda avaliador escreve o score no DynamoDB, o stream aciona outro Lambda que publica a métrica QualityScore no CloudWatch com timestamp retroativo (usando put_metric_data com Timestamp explícito, não o tempo atual). Isso permite que o CloudWatch SLO calcule o burn rate corretamente sobre a janela histórica.

Um aspecto crítico para ambientes financeiros: o SLO de qualidade deve ter thresholds diferenciados por tipo de request. Uma pergunta sobre saldo de conta tem threshold de factualidade diferente de uma pergunta sobre estratégia de investimento. Use a dimensão request_type no CloudWatch para criar SLOs separados por categoria — isso é mais trabalhoso para configurar mas evita que respostas de baixo risco diluam o sinal de qualidade em requests de alto risco.

Por fim, documente o SLO de qualidade como um ADR (Architecture Decision Record) com a justificativa do threshold escolhido, o modelo juiz utilizado, o golden dataset de calibração e o processo de revisão trimestral. Em auditorias de compliance, a capacidade de demonstrar que você tem um processo formal de avaliação de qualidade de IA é tão importante quanto os números em si.