A Métrica que Falta entre Tokens e Gastos em Nuvem

O problema não é que as equipes de IA careçam de dados de custo. É que o painel de tokens e a fatura da nuvem descrevem sistemas diferentes, pertencentes a equipes distintas, sem uma forma confiável de conectá-los.

Um agente de suporte pode resolver um ticket após cinco chamadas ao modelo, uma etapa de recuperação, duas chamadas a ferramentas e uma tentativa novamente. O negócio registra um caso concluído. A infraestrutura registra uma dispersão de solicitações, pods, memória, tempo de acelerador e serviços compartilhados. Até que esses registros se alinhem, a otimização de custos é parcialmente um palpite.

Por que Métricas de Tokens e Faturas de Nuvem Contam Histórias Diferentes?

Contagens de tokens são úteis. Elas mostram quanto texto um modelo recebeu e devolveu, e ajudam as equipes a comparar prompts, modelos ou escolhas de roteamento. Mas não informam o que aconteceu ao redor da chamada ao modelo, quanto de computação suportou a recuperação e o uso de ferramentas, quantas tentativas falhadas ocorreram primeiro, ou se o resultado final foi realmente útil.

O State of FinOps 2026 mostra quão rapidamente a IA se integrou ao trabalho cotidiano de FinOps: 98% dos entrevistados agora gerenciam gastos com IA, contra 63% em 2025. Mas uma linha orçamentária maior ainda não indica qual fluxo de trabalho consumiu o dinheiro ou por quê.

Dois trabalhos de processamento de documentos podem usar aproximadamente o mesmo número de tokens. Um pode terminar com uma única solicitação ao modelo. O outro pode recuperar contexto de vários repositórios, chamar um serviço externo, recorrer a outro modelo e reprocessar o documento após uma validação falha que o usuário nunca vê. Os totais de tokens parecem semelhantes, enquanto os caminhos de execução não são.

Unite.ai já analisou por que contagens de tokens não representam automaticamente o valor de negócio. O próximo passo é conectar essas contagens às cargas de trabalho que as geraram. Caso contrário, uma equipe pode melhorar o custo por token enquanto piora o custo por tarefa concluída.

Como é uma Cadeia de Custos Completa?

Uma cadeia de custos útil começa com o resultado que o negócio valoriza. Pode ser um caso de suporte resolvido, um documento processado, uma mudança de código aceita ou um fluxo de trabalho de agente concluído. Tudo abaixo dele precisa de uma identidade que possa ser acompanhada ao longo do sistema.

A camada de aplicação fornece a primeira conexão. Um ID de solicitação, ID de rastreamento, nome do fluxo de trabalho ou ID de conversa pode ligar várias operações de modelo e ferramenta a um único trabalho. Sem esse elo, dez eventos relacionados parecem dez cobranças não relacionadas.

As convenções OpenTelemetry para agentes GenAI oferecem um vocabulário emergente para essa camada. Elas cobrem operações, provedores, modelos solicitados, agentes, conversas, uso de tokens, execução de ferramentas, erros e fluxos de trabalho. As convenções ainda estão marcadas como em desenvolvimento, portanto as equipes não devem tratá-las como um padrão universal finalizado. Elas são úteis porque tornam o problema de correlação concreto.

Em seguida vem a infraestrutura. O split cost allocation data for EKS da AWS pode atribuir custos compartilhados de computação e memória a pods do Kubernetes e expor detalhes como cluster, namespace, implantação, nó, nome da carga de trabalho e tipo de carga de trabalho. Para instâncias aceleradas suportadas, os dados também cobrem reservas de GPU, Trainium e Inferentia.

Essa é a outra metade da cadeia. Um rastreamento pode explicar o que a aplicação tentou fazer; a alocação do Kubernetes pode mostrar quais recursos carregaram o trabalho. O guia da Unite.ai sobre deployment e monitoramento de LLMs no Kubernetes fornece o contexto de produção mais amplo, incluindo alocação de recursos, escalonamento e observabilidade.

A conexão não acontecerá por acaso. As equipes precisam de um identificador estável que sobreviva o suficiente para conectar a telemetria da aplicação com rótulos de carga de trabalho, registros de alocação ou outra camada de mapeamento. Dados de clientes não devem ficar em tags do Kubernetes. As equipes devem decidir quais identificadores de baixa cardinalidade podem conectar com segurança uma categoria de fluxo de trabalho, serviço ou recurso ao que consumiu.

Uma vez que esse contexto de aplicação esteja em vigor, as equipes podem começar a monitorar custos do Kubernetes por carga de trabalho e conectar namespace, CPU, memória e uso de GPU ao trabalho realizado. Isso ainda não indica se o fluxo de trabalho gerou valor de negócio, mas fornece algo concreto para a parte de infraestrutura da equação.

Qual Métrica Unitária o Negócio Deve Confiar?

Não existe uma única métrica de custo de IA que todas as equipes devam usar. Custo por token responde a uma pergunta de consumo do modelo. Custo por pod responde a uma pergunta de alocação de infraestrutura. Nenhuma delas informa ao proprietário do produto se a funcionalidade está justificando seu custo.

O melhor denominador costuma ser o menor resultado que o negócio pode definir claramente e que a equipe de produto pode influenciar. Uma operação de suporte pode acompanhar custo por caso resolvido. Um sistema de documentos pode usar custo por arquivo processado com sucesso, enquanto um assistente de codificação poderia analisar custo por mudança aceita em vez de custo por sugestão.

O sucesso altera a matemática.

Um fluxo de trabalho com baixo custo por tentativa pode ser caro se falhar frequentemente, gerar validações repetidas ou enviar muitos casos para revisão humana. Por isso as equipes devem separar custo por tentativa de custo por conclusão e, quando possível, custo por resultado aceito. O último número costuma ser o mais útil, pois inclui o trabalho que o sistema produziu mas que o negócio não pôde usar.

Sistemas de agentes dificultam isso porque seus caminhos podem mudar de uma execução para outra. A análise da Unite.ai sobre a economia de escalonamento de cargas de trabalho de IA agente cobre roteamento, chamadas de ferramentas, tentativas e atribuição em nível de fluxo de trabalho. Esses comportamentos fazem parte da métrica unitária quando consomem recursos, mesmo que o usuário final veja apenas uma resposta.

A métrica ainda não será perfeita. Serviços compartilhados, resultados em cache, jobs em lote e processamento atrasado podem desfocar a atribuição. Uma estimativa útil para a tomada de decisão é melhor que precisão falsa, especialmente quando indica aos engenheiros qual camada merece investigação.

Quem Detém o Número?

A parte mais difícil pode ser organizacional. Equipes de ML entendem chamadas de modelo e avaliação. Equipes de plataforma entendem cargas de trabalho e comportamento de clusters. FinOps entende dados de faturamento e regras de alocação. Equipes de produto sabem qual resultado importa.

Nenhuma equipe possui a cadeia completa.

Isso gera um argumento previsível sobre qual painel está correto. A equipe de ML pode apontar para menor uso de tokens, enquanto a equipe de plataforma vê horas de GPU subindo e a equipe de produto vê menos tarefas concluídas do que antes. Todas as três observações podem ser verdadeiras simultaneamente. A métrica compartilhada precisa explicar a relação entre elas.

Um ponto de partida viável é um fluxo de trabalho de produção com um evento de conclusão claro. Dê-lhe um identificador estável. Leve esse contexto através dos rastros de modelo e ferramenta, mapeie-o para o serviço ou carga de trabalho que roda no Kubernetes e escolha um denominador de negócio. Então reúna as equipes quando o número mudar inesperadamente.

Essa revisão importa mais que um painel polido. Um aumento repentino pode vir de prompts mais longos, um novo caminho de fallback, capacidade de GPU subutilizada, política de autoscaling alterada ou decisão de produto que envia mais trabalho para a funcionalidade de IA. Cada causa pertence a um proprietário diferente.

A automação deve vir depois. Um motor de recomendação só pode agir sobre os rótulos e limites que recebe, e um denominador ruim pode fazer um sistema eficiente parecer desperdiçado ou recompensar um fluxo de trabalho barato que os usuários rejeitam. As equipes precisam de visibilidade compartilhada suficiente para distinguir comportamento do modelo do design da aplicação e da alocação de infraestrutura antes de permitir que um sistema aja sobre o resultado. Caso contrário, uma correção automática de custo pode reduzir capacidade, aumentar latência e deslocar a despesa para um local menos visível.

A Cadeia de Custos Precisa Ser Compartilhada

O controle de custos de IA permanecerá fragmentado enquanto cada equipe otimiza apenas a camada que consegue ver. Tokens, rastreamentos, pods, aceleradores e faturas não são medições concorrentes. São partes da mesma cadeia de custos.

As empresas que as conectam não obterão um número perfeito no primeiro dia. O que importa é se a equipe consegue rastrear uma fatura alta até o fluxo de trabalho que a gerou, entender o que mudou e decidir se o resultado justificou o custo.