Você vê sua conta de IA. Até consegue explicá-la mais ou menos. Mas não consegue atribuir esse gasto a clientes, times ou usuários. E, por isso, não tem como afirmar se está precificando seus produtos com margens saudáveis. Essa lacuna - entre o que você gasta e o que consegue contabilizar - é o problema que estamos resolvendo com o Attribute™.
Atribuir custos de nuvem nunca foi fácil, ainda mais quando se trata de recursos compartilhados. Passamos quinze anos ajudando mais de 4.000 clientes a destrinchar infraestruturas compartilhadas, aplicar políticas de tagging e montar modelos de chargeback que se sustentam sob qualquer análise. Sempre foi um problema difícil. E a IA complicou ainda mais.
A infraestrutura em que a IA roda foi feita para velocidade e escala, não para atribuição. As abordagens de atribuição que o mercado aceitou na nuvem (tags) não se aplicam aqui. É uma realidade arquitetural - e pedia uma resposta diferente.
A armadilha da instrumentação
A resposta padrão para atribuição de custos sempre foi a instrumentação. Coloque tags nos seus recursos. Envolva suas chamadas de API em um SDK. Imponha padrões de nomenclatura. Construa um pipeline que agregue esses sinais em um dashboard.
Para a infraestrutura de nuvem tradicional, essa abordagem funciona, ainda que não seja perfeita. A infraestrutura compartilhada por trás é relativamente estática. O modelo de propriedade é relativamente claro. Dá para chegar ao "bom o suficiente", desde que se façam algumas concessões.
A infraestrutura de IA derruba todas as premissas em que essa abordagem se apoia.
Um único modelo gerenciado atende vários clientes ao mesmo tempo. Um cluster de GPU compartilhado roda modelos de diversos produtos simultaneamente. Um gateway de LLM concentra requisições de agents, harnesses e humanos em um único fluxo de saída. Sem contar que uma workload agêntica pode gerar sub-agents que disparam custos de infraestrutura sem qualquer relação visível com o item da conta de IA que os originou.
Não existe SDK que se encaixe em uma GPU compartilhada. Não existe tag que sobreviva ao trajeto por um proxy de LLM. E as workloads de IA não avançam num ritmo que a instrumentação consiga acompanhar. Um agent pode gerar mil sub-agents em uma madrugada. Quando você terminar de envolver os novos padrões de chamada em um SDK e publicar a atualização, a conta já chegou.
A lacuna de atribuição no gasto com IA não é um problema de processo que dá para resolver com instrumentação. É uma realidade arquitetural de como a infraestrutura de IA funciona.
"A lacuna de atribuição no gasto com IA não é um problema de processo que dá para resolver com instrumentação. É uma realidade arquitetural de como a infraestrutura de IA funciona."
Foi esse insight que nos levou ao Attribute™. Se a arquitetura das workloads de IA derrota a instrumentação por design, então instrumentação é a resposta errada. É preciso medir a partir de uma camada que enxergue tudo - antes de qualquer abstração, antes de qualquer proxy, antes de qualquer fronteira de propriedade. É preciso medir no kernel do sistema operacional.
Uma abordagem diferente
O Attribute™ implanta um sensor eBPF que roda dentro do sistema operacional. Ele observa o consumo real - cada token, cada requisição de modelo, cada ciclo de GPU - na hora em que acontece, e mapeia cada unidade de volta ao processo, contêiner, pod e requisição responsáveis. Depois, cruza esses dados com o faturamento dos provedores Anthropic, OpenAI, Google Gemini e AWS Bedrock, separando automaticamente cached tokens, reasoning tokens, input tokens e output tokens.
O resultado é uma economia de tokens por cliente, por feature, por agent: gerada continuamente, sem instrumentação, sem tagging, sem mexer em código.
As ferramentas que existem hoje (e há opções decentes) se dividem em dois grupos: 1. as que pedem aos engineers para definir a lógica de alocação em código e 2. as que usam inferência de metadados para propor tags virtuais automaticamente.
Ambas são avanços relevantes em relação ao tagging manual. Mas nenhuma consegue enxergar dentro de uma GPU compartilhada. Nenhuma consegue seguir um token por um gateway de LLM até o cliente ou usuário que o originou. O gargalo não está na ferramenta. Está no método.
Qualquer abordagem que dependa de metadados para reconstruir a atribuição vai esbarrar no mesmo muro, porque os metadados não existem na camada em que o consumo de fato ocorre.
A medição em nível de kernel não é um detalhe técnico. É a única arquitetura capaz de gerar atribuição completa em toda a extensão da infraestrutura de IA moderna.
Por que Tokenomics é o enquadramento certo
Com essa nova abordagem, estamos ativamente ajudando a construir a categoria de Tokenomics - e isso é algo bem específico. Não é gestão de custos de IA: o mercado está cheio dessa conversa, e boa parte dela é só o vocabulário de FinOps de nuvem aplicado a um novo item de fatura.
Tokenomics é a disciplina de entender o quanto cada token realmente vale para o seu negócio: quem o consumiu, o que ele produziu e se o gasto se justificou pelo resultado.
Isso exige atribuição em nível de token. Não em nível de conta. Não em nível de time. Em nível de token. Você precisa saber que uma sessão específica de um cliente consumiu 47.000 tokens em três modelos, que 31.000 deles foram em uma feature que responde por 80% da probabilidade de renovação e que os 16.000 restantes foram em uma feature experimental que ainda não foi para produção. São esses dados que permitem tomar decisões inteligentes sobre onde investir e onde recuar.
Não dá para chegar a esses dados via tagging. Não dá via SDKs. Só dá se você estiver medindo na camada em que o consumo real acontece.
A Linux Foundation anunciou recentemente a intenção de lançar a Tokenomics Foundation, em parceria com a FinOps Foundation, para estabelecer padrões abertos de mercado para a economia de tokens em IA. JR Storment, Diretor Executivo da FinOps Foundation e parceiro próximo da DoiT, foi direto ao ponto: dar nome ao problema não é resolvê-lo.
É exatamente isso. A categoria agora tem nome e um lar institucional. O Attribute™ é a camada de medição que a torna operacional.
Por que a DoiT, e por que agora?
A DoiT já gerenciou mais de US$ 20 bilhões em gastos com nuvem para 4.500 clientes em 27 países. Acompanhamos o surgimento de cada grande categoria de custo de nuvem: otimização de compute, gestão de commitments, alocação de custos de Kubernetes. Os times que montam a base de medição certa desde cedo tomam decisões melhores dali em diante. Os que adiam a atribuição até que as contas já estejam altas passam anos reconstruindo um contexto que poderiam ter tido desde o primeiro dia.
O gasto com IA avança mais rápido do que qualquer categoria anterior. Nossa própria pesquisa - com 500 líderes de finanças - mostrou que 79% das empresas já tiveram estouros de custo com IA e que apenas 15% dizem conseguir calcular o ROI de IA com precisão sem gargalos significativos. A janela para adotar o conjunto de ferramentas certo é agora, e não depois da próxima conta-surpresa.
Há um segundo sinal que vale destacar. À medida que a IA sai da experimentação e entra na infraestrutura de produção, as perguntas mudam. Não é mais "quanto estamos gastando" - é "quanto custa atender cada cliente", "quais features de IA estão comendo nossas margens" e "quais agents estão consumindo gasto sem entregar nada em troca". Seu board está fazendo essas perguntas. Seu CFO também. Dados de gasto em nível de conta produzem respostas em nível de conta. Atribuição em nível de kernel - por cliente, por agent, por feature - produz o tipo de resposta que muda decisões de verdade.
Foi por isso que construímos o Attribute™. E é por isso que estamos trazendo essa solução para a DoiT agora.
Sobre o Attribute™
Quinze minutos para instalar. Sem instrumentação. Economia de tokens até o fim do dia. Se você quer ver como o Attribute™ se comporta no seu próprio ambiente, agende uma demo aqui.