Cost attribution por feature, workflow e tenant: de qual bolso saiu cada token

A fatura do provedor de LLM chega com um número em dólar. As perguntas do negócio chegam em outra unidade: quanto custou cada feature, cada workflow, cada cliente. Cost attribution é a ponte entre os dois. Em cloud, essa ponte é disciplina madura: tagging, showback, chargeback. Com LLM, a diferença central é uma só: atribuição é um schema que se decide antes do primeiro request. Este artigo entrega esse schema, o contrato de atribuição, pronto pra levar pra sua equipe.

O problema clássico

Cost allocation em cloud tem um playbook conhecido: tag em cada recurso, custo agregado por time e produto, rateio pro que é compartilhado. Showback dá visibilidade; chargeback cobra a despesa do centro de custo de cada área. O State of FinOps 2026 mostra essa disciplina engolindo a IA. Numa amostra de 693 respostas, 98% gerenciam gasto de IA, contra 63% em 2025 e 31% em 2024. E o item número um da lista de capacidades desejadas em tooling: monitoramento granular do gasto de IA, em tokens, requests de LLM e utilização de GPU.

A demanda aponta na mesma direção. Não é “quanto gastamos”, é “quem gastou e com o quê”. Isso é cost attribution.

O teto do provedor

A Usage & Cost API da Anthropic agrupa uso por chave de API, workspace, modelo, service tier, janela de contexto e geografia de inferência. O custo em dólar sai agrupado por workspace. A OpenAI agrupa por projeto, chave de API, usuário e modelo. Repare no vocabulário: são dimensões da organização. Feature, workflow e tenant não são dimensões nativas de nenhum dos dois. Dá pra torcer workspace ou projeto pra representar um tenant grande; o cruzamento fino entre as três dimensões fica fora do alcance. O provedor fecha a conta da empresa. A pergunta do negócio se responde na sua infraestrutura, e o resto do artigo é sobre como.

Por que o schema vem antes do primeiro request

Não existe retag. Recurso de cloud vive dias ou meses. O relatório de recursos sem tag aponta o dono, a tag entra e o custo passa a ser atribuído dali em diante. Request de LLM vive milissegundos. A chamada que saiu sem nenhuma chave de correlação vira custo órfão: não há recurso vivo pra taggear depois, e o que resta é rateio estimado. Cost attribution de LLM é decisão tomada no request, não faxina de fim de mês.

O preço varia dentro do mesmo request. O mesmo modelo cobra valores diferentes pros quatro tipos de token que a Anthropic reporta: input não cacheado, input cacheado, criação de cache e output. E trocar o modelo do roteamento muda o custo da feature sem mudar uma linha do código dela. O registro por request precisa guardar o modelo e os contadores por tipo, não só o total em dólar.

Suas dimensões são combinatórias. A tentação óbvia é criar uma chave de API por coisa a medir. Só que a unidade que importa é o cruzamento: a feature de resumo, dentro do workflow de cobrança, servindo o tenant Acme. Chave por combinação explode em manutenção. As dimensões precisam viajar juntas, no mesmo request.

O contrato de atribuição

O coração de cost attribution é um schema de uma página. É o registro que todo request de LLM gera, com as dimensões de negócio e as medidas de custo. Este é o contrato pra discutir com a equipe:

Cinco definições curtas seguram a taxonomia. Tenant é a organização cliente. Cliente final é o usuário dentro do tenant, quando ele existe como entidade própria. Agente é a identidade operacional que faz a chamada. Feature é a capacidade do produto; workflow é o processo que agrupa chamadas. E modelo_resposta guarda o modelo que atendeu o request: com roteamento no gateway, ele pode diferir do modelo pedido no request.

Duas regras de design fazem o contrato funcionar:

Taxonomia fechada. feature e workflow vêm de uma lista versionada no repositório, não de string livre. Tag com typo cria uma dimensão fantasma que nunca mais agrega com as outras. Mudança na lista passa por review, como qualquer schema.

Enforcement na admissão. Request sem tenant ou sem feature é rejeitado no gateway, igual budget estourado. A validação compara a tag recebida com a versão ativa da taxonomia e rejeita valor desconhecido. É a resposta estrutural pro “não existe retag”: o custo órfão morre na porta, não no relatório.

Duas pontes ancoram o contrato em padrão aberto. Na telemetria, as convenções GenAI do OpenTelemetry já nomeiam a metade técnica: gen_ai.response.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens e os contadores de cache. Cuidado com a semântica: no OTel, input_tokens é o total e já inclui os cacheados; os contadores de cache são detalhamento, não parcela a somar de novo. A convenção está em estabilidade “development”, e as dimensões de negócio entram como atributo custom ao lado delas. No financeiro, o FOCUS, spec da FinOps Foundation, normaliza dados de billing entre provedores. Quando o dataset informa consumo em tokens, ele entra nos campos padronizados de quantidade e unidade. O contrato não depende de nenhum dos dois; as pontes servem a quem já usa esses padrões.

O contrato no gateway

Se a equipe já opera um gateway no caminho das chamadas, ele é o lugar natural do contrato. Parte das dimensões pode exigir instrumentação na aplicação, dependendo da edição da ferramenta. No LiteLLM, que calcula o gasto automaticamente pros modelos que conhece, o request fica assim (exemplo adaptado da doc):

curl 'http://0.0.0.0:4000/chat/completions' \
  --header 'Authorization: Bearer sk-acme-agente-cobranca' \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "..."}],
    "user": "cliente-4412",
    "metadata": {
      "tags": ["feature:resumo-fatura", "workflow:cobranca-whatsapp"]
    }
  }'

Cada dimensão do contrato tem um veículo. A chave virtual identifica o agente; o team dono da chave, cadastrado antes no gateway, identifica o tenant. O campo user marca o cliente final, quando ele é uma entidade distinta do tenant. As tags marcam feature e workflow. Modelo, contadores e custo estimado o gateway preenche sozinho na volta.

Um aviso honesto de licenciamento: no LiteLLM, tag por request é recurso Enterprise. Na versão aberta, chave e user cobrem agente, tenant e cliente. Feature e workflow exigem Enterprise, ou log da própria aplicação correlacionado pelo request_id que aparece no spend log. O contrato não muda; muda qual camada preenche cada campo. A consulta vem depois: /spend/logs?summarize=false devolve as transações individuais, e /user/daily/activity devolve o gasto diário quebrado por modelo, provedor e chave.

O que sai do outro lado

Com as dimensões persistidas num lugar só, direto no gateway ou após correlação com o log da aplicação, o relatório que hoje não existe vira um GROUP BY. Exemplo ilustrativo, com números fictícios:

Uma tabela dessas destrava três decisões que a fatura sozinha não sustenta.

Reprecificar: cruzando o custo estimado por tenant com receita e câmbio, a parcela de LLM na margem de cada cliente aparece.

Rotear: a feature barata e volumosa vira candidata a um modelo mais barato, decisão que ainda passa pela avaliação de qualidade.

E orçar: o token budget do artigo anterior ganha teto por dimensão real de negócio, não chute. Budget sem atribuição bloqueia pelo recorte técnico, chave ou team, sem dizer qual feature consumiu o teto. Atribuição sem budget explica o gasto e não impede a chamada seguinte. Os dois usam a mesma infraestrutura: chave por agente, team por tenant, gateway no meio.

Fechando

No mapa do artigo dos quatro eixos, cost attribution não move nenhum knob. Ela mostra onde o gasto está e qual knob vale avaliar, pra qual tenant, com número em vez de intuição.

O primeiro passo não é ferramenta, é reunião. A tabela do contrato cabe numa página, e a taxonomia de features e workflows se decide antes do primeiro request em produção. Depois vem o gateway, o enforcement e o relatório. O total da fatura vai continuar sendo um número só. A diferença é saber de qual bolso saiu cada request.

Fontes

• FinOps Foundation: State of FinOps 2026 Report
• Anthropic: Usage and Cost API
• OpenAI: Usage API reference
• LiteLLM: Spend Tracking
• LiteLLM: Customers / End-Users
• OpenTelemetry: GenAI semantic conventions, registro de atributos
• FinOps Foundation: FOCUS specification