Quando sua conta do Amazon Bedrock dispara e ninguém consegue dizer qual recurso causou isso, você não tem um problema de preço. Você tem um problema de observabilidade. A fatura diz que a conta gastou mais com tokens. Não diz qual agente, qual cliente, ou qual caminho de código foi o responsável pelo gasto, e sem essa atribuição toda conversa sobre custo vira um chute. Você não consegue otimizar o que não consegue medir, e a maioria dos times está medindo o total e nada abaixo dele.

O gasto com tokens tem uma propriedade que torna isso pior que um custo de nuvem comum: é gerado por um sistema não determinístico. Uma mudança de prompt, um loop de retry, um agente tagarela, ou um usuário que encontrou uma forma de fazer o modelo pensar mais, qualquer um desses pode mover a conta, e nenhum deles aparece como um recurso novo na fatura. O gasto se esconde dentro de um único item de linha do Bedrock. O trabalho é decompor esse item de linha antes que ele te surpreenda, não depois.

Atribuição é todo o jogo

A pergunta que importa nunca é "quanto gastamos no Bedrock". É "quanto isso gastou, e vale a pena". Responder isso exige uma dimensão em cada unidade de gasto com tokens. No mínimo, marque cada chamada com:

  • Recurso ou área do produto, para poder perguntar se o resumidor ou o assistente de chat é o motor do custo.
  • Cliente ou tenant, para poder ver se uma conta está sendo subsidiada pelo resto e se seu preço cobre seu custo de atendimento.
  • Agente ou workflow, para que o custo de um pipeline multi-etapa seja visível por etapa em vez de um total opaco.
  • Modelo, para poder identificar quando tráfego caro está indo para um modelo de fronteira que um mais barato teria resolvido.

Sem essas dimensões, a otimização de custo se degrada em medidas genéricas: limitar todo mundo, ou desligar recursos e ver qual reclamação chega. Com elas, você consegue apontar exatamente o caminho que cresceu e decidir se ele mereceu esse crescimento.

Duas camadas de instrumentação

Tags de alocação de custo para a fatura

As tags de alocação de custo da AWS são a camada grossa. Marque os recursos e requisições que geram uso do Bedrock para que os dados de cobrança carreguem suas dimensões, e os relatórios de custo possam agrupar por recurso ou ambiente em vez de mostrar uma figura indiferenciada do Bedrock. Essa é a visão em que finanças e donos de plataforma vivem. É granular por mês e boa para a conversa de "para onde está indo o dinheiro", não para pegar um pico no momento em que acontece.

Métricas do CloudWatch para o quadro em tempo real

A fatura é um indicador atrasado. O indicador antecipado é a vazão de tokens, e isso pertence ao CloudWatch. O Bedrock emite métricas de uso, e você pode publicar suas próprias métricas customizadas dimensionadas por agente, por cliente, ou por recurso diretamente da aplicação:

# emit token counts as custom metrics, dimensioned
put_metric_data(
  namespace = "LLM/Usage",
  metric    = "InputTokens",
  value     = usage.input_tokens,
  dimensions = { "Feature": "summarizer", "Tenant": tenant_id }
)
# same for output_tokens, and cache read/write counts

Agora o gasto é um gráfico no qual você pode configurar alarmes. Uma métrica de tokens por agente que triplica durante a noite dispara um alerta na terça-feira, em vez de uma pergunta de finanças no fim do mês. Leia entrada e saída separadamente, porque a saída tem preço mais alto e uma geração descontrolada aparece ali primeiro.

O que a visibilidade permite fazer

Uma vez que todo token está atribuído, as otimizações deixam de ser genéricas. Você pode rotear as chamadas baratas e mecânicas que uma métrica por agente revela para um modelo menor, e manter o modelo de fronteira para o raciocínio que o justifica. Você pode encontrar o cliente cujo custo de atendimento excede o plano dele e corrigir o preço ou o uso. Você pode capturar o loop de retry que uma mudança de prompt introduziu, porque sua contagem de tokens disparou enquanto sua contagem de requisições não. Cada um desses movimentos exige saber qual fatia da conta cortar, que é exatamente o que a instrumentação te dá e a fatura crua nunca dará.

A conclusão

Uma conta do Bedrock que você não consegue decompor é uma conta que você não consegue gerenciar. Trate o gasto com tokens como telemetria, não apenas como uma linha de fatura: marque com tags de alocação de custo para a visão de cobrança, emita métricas de tokens por agente e por cliente para o CloudWatch para a visão em tempo real, e configure alarme no indicador antecipado para que um pico seja um alerta, não um post-mortem. Os times cujos custos de LLM permanecem sob controle não são os que têm os melhores preços. São os que conseguem ver, a qualquer momento, exatamente qual recurso, cliente e agente está gastando o dinheiro.

Leia isso a seguir

Para o playbook de FinOps e visibilidade de custo de nuvem além dos LLMs, as notas de campo sobre cloud estão em ercan.cloud, e o hub está em ercanermis.com.