Design Doc: Observabilidade de LLMs, da GPU à Qualidade de Resposta

Plataformas de inferência LLM introduzem uma classe de problemas de observabilidade que as ferramentas tradicionais de APM não foram projetadas para resolver. Em sistemas convencionais, latência alta e erro de aplicação são suficientes para diagnosticar a maioria dos incidentes. Em LLMs, você pode ter latência aceitável, zero erros HTTP e ainda assim estar entregando respostas semanticamente incorretas, truncadas ou com alucinações crescentes, e nenhum alarme vai disparar.

O cenário que este documento endereça é uma plataforma multi-tenant onde múltiplos clientes consomem endpoints de inferência provisionados no SageMaker AI (modelos proprietários fine-tuned) e no Amazon Bedrock (modelos fundacionais via API gerenciada). Cada tenant tem SLAs distintos, volumes de token distintos e tolerâncias de custo distintas. As lacunas de visibilidade identificadas são:

1. Camada de hardware desconectada da camada de aplicação. Métricas de GPU (utilization, memória HBM, temperatura) existem no CloudWatch via /aws/sagemaker/Endpoints, mas não são correlacionadas automaticamente com latência de inferência ou qualidade de saída. Um pico de GPU utilization a 98% pode significar throughput ótimo ou pode ser o sinal precursor de um OOM que vai derrubar o endpoint.

2. Ausência de rastreamento por prompt. Requests de inferência LLM não são idempotentes nem uniformes: um prompt de 4.000 tokens tem perfil de latência e custo radicalmente diferente de um de 200 tokens. Sem trace ID propagado do cliente até o endpoint, é impossível correlacionar uma reclamação de qualidade de um tenant específico com o request real que a causou.

3. Qualidade de resposta não é uma métrica nativa. Nenhum serviço AWS emite automaticamente uma métrica de qualidade semântica. Eval scores (RAGAS, G-Eval, BERTScore ou avaliadores LLM-as-judge) precisam ser calculados assincronamente e injetados no pipeline de métricas como métricas customizadas. Sem isso, degradação de qualidade só é detectada via ticket de suporte, tarde demais.

4. Custo por tenant é invisível no modelo padrão. Bedrock cobra por token; SageMaker cobra por hora de instância. Em um ambiente multi-tenant, a alocação de custo por cliente requer instrumentação explícita: contagem de tokens de entrada/saída por tenant, mapeamento para SKU de instância e agregação temporal. Sem isso, o produto não consegue precificar corretamente nem identificar tenants que estão consumindo recursos desproporcionais.

A arquitetura de observabilidade é organizada em quatro camadas com responsabilidades distintas e interfaces bem definidas entre elas. O princípio central é separar coleta de armazenamento, armazenamento de avaliação e avaliação de alerta, cada camada pode evoluir independentemente.

Camada 1: Instrumentação e Coleta

Todo request de inferência passa por um Inference Proxy (Lambda ou ECS Fargate), que é o ponto de entrada único para ambos os backends (SageMaker e Bedrock). O proxy tem três responsabilidades de observabilidade:

• Geração de trace ID: cada request recebe um x-trace-id UUID v4 que é propagado como header HTTP para o endpoint downstream e como atributo de segmento no X-Ray. O trace ID é também injetado no payload de log estruturado (JSON) emitido para o CloudWatch Logs.
• Contagem de tokens: antes de despachar o request, o proxy tokeniza o prompt com o tokenizador correspondente ao modelo (via biblioteca tiktoken ou transformers) e registra input_token_count como métrica customizada no CloudWatch com dimensões tenant_id, model_id e endpoint_type. A contagem de tokens de saída é registrada na resposta.
• Captura de latência: o proxy mede time_to_first_token (TTFT) e total_latency com precisão de milissegundos e os emite como métricas CloudWatch com resolução de 1 segundo (high-resolution metrics).

Para endpoints SageMaker, métricas nativas de GPU (GPUUtilization, GPUMemoryUtilization, DiskUtilization) já são emitidas automaticamente para o namespace /aws/sagemaker/Endpoints. Para Bedrock, métricas de invocação (InvocationLatency, InputTokenCount, OutputTokenCount) são emitidas para /aws/bedrock/modelinvocations. Ambas as fontes são consumidas diretamente pelo Grafana via CloudWatch data source.

Camada 2: Pipeline de Avaliação Assíncrona

Qualidade de resposta não pode ser avaliada no caminho crítico sem impactar latência. O design usa amostragem: 100% dos requests têm metadados capturados (prompt hash, tenant, modelo, tokens, latência), mas apenas uma fração configurável (padrão: 5% por tenant, ajustável por SLA) passa pelo pipeline de eval completo.

O proxy publica um evento para um Kinesis Data Stream (llm-eval-stream) contendo: trace_id, tenant_id, model_id, prompt (truncado a 2.000 chars para controle de custo), completion, timestamp e metadados de contexto (ex: RAG chunks se aplicável). Uma função Lambda consumidora (eval-worker) processa esses eventos em micro-batches e executa:

1. LLM-as-judge: invoca um modelo avaliador no Bedrock (Claude 3 Haiku por custo) com um prompt de rubrica estruturado que retorna scores de 1-5 para relevância, coerência, fidelidade factual e ausência de alucinação.
2. Métricas de referência (quando ground truth disponível): BERTScore F1 para similaridade semântica.
3. Emissão de métricas customizadas: os scores são emitidos para CloudWatch no namespace LLMPlatform/EvalScores com dimensões tenant_id, model_id e eval_dimension.

Os resultados completos de eval são armazenados em DynamoDB (tabela eval-results, TTL de 90 dias) para consulta ad-hoc e em S3 (formato Parquet, particionado por date/tenant/model) para análise histórica e treinamento de avaliadores.

Camada 3: Custo por Tenant

Uma função Lambda agendada (cost-aggregator, execução horária) lê as métricas customizadas de token count do CloudWatch via GetMetricData e aplica a tabela de preços vigente (Bedrock: preço por token por modelo; SageMaker: preço por hora de instância dividido pelo número de tenants ativos no período via peso de tokens). O resultado é escrito no DynamoDB (tabela tenant-cost, chave tenant_id#date) e exposto via API Gateway para o sistema de billing.

Camada 4: Alertas e Dashboards

Alarmes CloudWatch cobrem três categorias: (a) infraestrutura: GPU utilization > 90% por 5 minutos, latência p99 > threshold por tenant; (b) qualidade: eval score médio por tenant caindo mais de 15% em relação à baseline rolling de 7 dias; (c) custo: consumo de tokens de um tenant ultrapassando 120% do budget diário configurado. Alarmes de regressão de qualidade usam CloudWatch Anomaly Detection com banda de 2 desvios padrão sobre a série histórica de eval scores.

O Amazon Managed Grafana consome CloudWatch como data source principal e X-Ray para visualização de traces. Dashboards são organizados em três camadas: visão executiva (custo e qualidade por tenant), visão operacional (GPU, latência, throughput por endpoint) e visão de debug (trace individual por trace_id).

Taxa de Amostragem do Pipeline de Eval

A decisão de amostrar 5% dos requests para eval completo é o trade-off mais importante deste design. Eval a 100% com LLM-as-judge é tecnicamente viável mas economicamente inviável: a 2M requests/dia usando Claude 3 Haiku como avaliador (estimativa de 500 tokens por avaliação), o custo adicional seria da ordem de $1.500-2.000/dia apenas em chamadas de eval, sem contar latência adicional se feito em sincrono. A 5%, o custo cai para ~$75-100/dia e a cobertura estatística é suficiente para detectar regressões de qualidade com confiança para volumes acima de 10.000 requests/dia por tenant.

A taxa de amostragem é configurável por tenant via parâmetro no Systems Manager Parameter Store (/llm-platform/{tenant_id}/eval_sample_rate), permitindo aumentar para 100% temporariamente durante investigações de incidente ou para tenants com SLA de qualidade premium.

Granularidade de Métricas vs. Custo de CloudWatch

Métricas de alta resolução (1 segundo) no CloudWatch custam $0.30/métrica/mês, versus $0.10/métrica/mês para resolução padrão de 1 minuto. Para latência TTFT e throughput de tokens, a resolução de 1 segundo é necessária para detectar spikes de latência que se resolvem dentro de um minuto. Para métricas de custo e eval score, resolução de 1 minuto é suficiente. O design usa alta resolução seletivamente apenas para as métricas de latência críticas, reduzindo o custo de métricas em ~60% comparado a instrumentar tudo em alta resolução.

Isolamento de Dados de Prompt por Tenant

Prompts de tenants regulados (financeiro, saúde) não devem ser enviados ao pipeline de eval se isso implicar transmissão para um modelo externo ou armazenamento não criptografado. O design resolve isso com duas medidas: (1) o pipeline de eval usa exclusivamente modelos Bedrock na mesma conta AWS, sem egress de dados; (2) prompts são truncados a 2.000 caracteres antes de entrar no Kinesis stream, e a tabela DynamoDB eval-results usa CMK (Customer Managed Key) via AWS KMS com chave por tenant. Tenants podem optar por desabilitar completamente o armazenamento de prompt via flag de configuração, nesse caso, apenas o hash do prompt é armazenado para correlação.

Detecção de Drift vs. Alarmes de Threshold Fixo

Alarmes de threshold fixo para eval score (ex: "alerta se score < 3.0") são frágeis porque a distribuição de scores varia por domínio de aplicação e por modelo. Um modelo de sumarização pode ter score médio de 3.8; um modelo de geração de código pode ter score médio de 4.2. Um threshold único geraria falsos positivos em um e falsos negativos em outro. A solução é usar CloudWatch Anomaly Detection com modelo de ML treinado na série histórica de eval scores por (tenant_id, model_id). O alarme dispara quando o score cai mais de 2 desvios padrão abaixo da banda esperada para aquele contexto específico, detectando regressão relativa, não absoluta.