Cloud Intelligence™
Como validar a atribuição de custos de IA em um ambiente de produção
Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.
About Gregory Wiedeman
Senior Cloud Architect I
Greg is a Cloud Architecture Strategist at DoiT International and holds an M.S. in Systems Engineering from Regis University. He specializes in cloud architecture, FinOps consulting, and technical advisory services—helping clients optimize infrastructure and make smarter build decisions. When he's not immersed in cloud cost strategies, he enjoys writing about AI governance for non-technical leaders, playing cornhole, or climbing Colorado's many 14ers.
My personal pageÉ simples demonstrar que é possível atribuir custos à IA, mas é difícil confiar nessa atribuição.
Um dashboard pode mostrar tokens, requisições ou uso de GPU; a dificuldade está em descobrir se esses números se referem ao cliente, à funcionalidade do produto, à equipe ou ao agente corretos, e se os totais batem com aqueles em que o financeiro e a engenharia confiam atualmente.
Este artigo apresenta uma abordagem prática para verificar a atribuição de custos de IA em produção. O objetivo não é ter um dashboard totalmente funcional no primeiro dia; a intenção é estabelecer uma cadeia de evidências mensurável que conecte a atividade em runtime ao contexto de negócio.
Comece com uma definição de "correto"
Antes de estabelecer um sistema de atribuição, é preciso decidir que tipo de pergunta os resultados devem responder.
Por exemplo:
- Qual é o custo por cliente para fornecer o serviço?
- Quais funcionalidades do produto fazem os modelos gastarem mais?
- Qual é o custo de execução de cada agente de IA?
- Quais são os workloads compartilhados que geram os custos de infraestrutura?
- Que parcela dos gastos dentro do escopo não pode ser atribuída no momento?
Essas perguntas se referem a diferentes aspectos da atribuição; embora uma abordagem no nível de equipe possa ser suficiente para fins de showback, obter uma visão por cliente exigiria identificadores de tenant, detalhes sobre a funcionalidade e um mapeamento entre identificadores de runtime e nomes de negócio.
Antes de olhar os resultados, é preciso registrar por escrito os critérios de validação. Um bom plano de validação deve especificar:
- Os workloads e provedores no escopo
- As dimensões que precisam estar visíveis
- A fonte da verdade para comparação
- A janela de tempo comparada
- A variância aceitável
- O tratamento dos gastos não atribuídos
O Attribute™ atribui o consumo em runtime a diversas dimensões, como equipe, namespace, workload, modelo, funcionalidade, ambiente, tenant ou cliente. A escolha importante é selecionar as dimensões que correspondem à pergunta de negócio, em vez de coletar todos os rótulos possíveis.
1. Comece com um workload de escopo limitado
Não comece validando todo o ambiente de nuvem. Em vez disso, comece com uma parte pequena e representativa:
- Um serviço de produção
- Um modelo ou gateway
- Uma funcionalidade voltada ao cliente
- Um namespace do Kubernetes
- Uma conta de faturamento ou projeto
Com o escopo restrito, qualquer discrepância pode ser identificada, e a equipe de plataforma também passa a ter um resultado de referência que pode ser estendido no futuro.
Para o primeiro teste, capture a atividade esperada de forma independente. Dados úteis de comparação podem incluir:
- Dados de uso ou faturamento do provedor
- Contadores de requisições e tokens do gateway de LLM
- Logs da aplicação
- Identificadores de tenant ou cliente
- Metadados de workloads do Kubernetes
- Utilização de GPU ou de computação
Não é necessário que todos os sistemas usem a mesma terminologia. O que queremos é entender como os diversos sistemas se relacionam entre si.
2. Garanta que a chave de atribuição permaneça visível em runtime
A falha na atribuição geralmente começa antes do cálculo do custo; quando a telemetria é coletada, a chave de atribuição — ou seja, o identificador necessário para distinguir uma instância de uso de outra — pode estar ausente.
Para cada dimensão-alvo, responda a três perguntas:
- Qual identificador se refere ao cliente, à funcionalidade ou ao tenant?
- Em que ponto do caminho da requisição o identificador aparece?
- O coletor de runtime consegue observá-lo continuamente?
Por exemplo, um identificador de cliente pode estar incluído em uma requisição autenticada, em um header do gateway, em um atributo de conexão de banco de dados ou em um campo específico da aplicação; mas, se o identificador existe apenas na memória da aplicação e nunca atravessa nenhuma fronteira observável, será preciso usar outro método de integração ou instrumentação.
É por isso que a validação deve começar pela capacidade de ver a chave em runtime, e não pelo total exibido em um dashboard; se a chave não puder ser observada de forma confiável, a alocação subsequente continuará incompleta, mesmo com a camada de relatórios cuidadosamente configurada.
Tags não conseguem acompanhar os gastos de IA através de GPUs e gateways compartilhados. Leia AI Features Have a Visibility Problem para entender por que a observabilidade em runtime supera a instrumentação. Baixe o ebook →
3. Defina os limites da coleta
O Attribute™ coleta informações sobre o consumo em runtime no nível do kernel por meio do eBPF (extended Berkeley Packet Filter – uma tecnologia do kernel Linux projetada para observabilidade com baixo overhead) e não exige nenhuma modificação no código da aplicação nem no SDK da aplicação. Ainda assim, a fronteira de coleta continua sendo importante.
Documente:
- Quais clusters, hosts ou contas estão cobertos
- Quais workloads estão incluídos ou excluídos
- Quais sistemas operacionais e versões de kernel são suportados
- Se o tráfego é criptografado antes de chegar à fronteira observável
- Se a infraestrutura compartilhada está dentro do escopo de medição
Antes do início da modelagem de atribuição, o processo de onboarding da DoiT inclui uma revisão da topologia do cluster, uma verificação de compatibilidade do kernel e do sistema operacional, uma análise dos requisitos de segurança e um exame do fluxo de telemetria. Para mais informações sobre o modelo de engajamento, consulte a documentação de visão geral do Attribute.
Uma declaração de cobertura útil se parece com isto:
A validação inclui o namespace de inferência de produção, o gateway auto-hospedado e os nós de GPU associados, de segunda-feira às 00:00 UTC até terça-feira às 00:00 UTC, excluindo tráfego de desenvolvimento, workloads em lote e conexões preexistentes.
Com limites claros definidos, as equipes não tratarão um resultado intencionalmente parcial como falha, nem considerarão que uma área não medida tem custo zero.
4. Crie um mapeamento de identificador para negócio
A telemetria de runtime geralmente começa com identificadores técnicos:
- Nomes de pods
- IDs de contêineres
- Nomes de namespaces
- IDs de modelos
- Chaves de API
- IDs de tenant
- Nomes de serviços
As equipes de finanças e produto precisam de dimensões legíveis:
- Nome do cliente
- Funcionalidade do produto
- Unidade de negócio
- Ambiente
- Faixa de preço
- Equipe responsável
Garanta que o mapeamento seja claro e guarde uma cópia dele; registre quem é o responsável, quando foi atualizado pela última vez e especifique o que acontece quando um identificador não possui um registro de negócio correspondente.
Uma tabela de mapeamento deve incluir pelo menos as seguintes colunas, por exemplo:
| Identificador de runtime | Dimensão de negócio | Responsável | Data de vigência | Status de validação |
|---|---|---|---|---|
tenant-4821 |
Acme / Search Assistant | Product Platform | 01/09/2026 | Confirmado |
tenant-5177 |
ExampleCo / Document Review | AI Applications | 01/09/2026 | Confirmado |
tenant-unknown |
Não mapeado | Platform FinOps | 01/09/2026 | Investigar |
A linha não mapeada é importante. Ocultá-la cria a aparência de atribuição completa e, ao mesmo tempo, elimina as evidências necessárias para melhorar a cobertura.
Quer saber quais clientes custam mais para você? Baixe Cost Per Customer: A FinOps Field Guide to Multi-Tenant Cloud Attribution, com SQL pronto para uso em AWS, Google Cloud e Azure. Baixe o guia →
5. Reúna as três visões da mesma atividade
Uma validação confiável compara pelo menos três perspectivas:
- Atividade em runtime — o que o workload chamou ou consumiu
- Uso do provedor ou do gateway — o que a plataforma reporta em tokens, requisições ou computação
- Custo atribuído — como esse uso é atribuído às dimensões de negócio
Compare a mesma janela de tempo e leve em conta as diferenças de timing: as exportações de faturamento podem atrasar, os contadores do gateway podem interpretar uma requisição de forma diferente e a telemetria de runtime pode registrar retries ou chamadas em cache de um modo diferente da fatura do provedor.
Duas métricas simples são úteis:
Cobertura = gasto atribuído no escopo / gasto total no escopo
Variância = valor absoluto (total da fonte - total atribuído) / total da fonte
É preciso acompanhar as métricas dia a dia, por workload, já que um percentual geral pode mascarar um problema sério envolvendo um cliente ou uma funcionalidade específicos.
Quando houver divergência, classifique-a em vez de alterar imediatamente a regra de atribuição:
- Divergência de escopo
- Divergência de janela de tempo
- Atraso no faturamento do provedor
- Identificador de runtime ausente
- Identificador não mapeado
- Retry ou requisição duplicada
- Trabalho em cache ou assíncrono
- Caminho de tráfego não suportado
O processo de classificação transforma o que seria um exercício de reconciliação em uma série de tarefas de engenharia, e o exemplo a seguir mostra como essa reconciliação é conduzida do início ao fim antes de considerar os testes de casos extremos.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Exemplo ilustrativo de validação
O exemplo abaixo tem caráter meramente ilustrativo e não se baseia no resultado de nenhum cliente real.
Uma empresa de SaaS quer calcular o custo da sua funcionalidade de resumo de documentos do ponto de vista de cada tenant; a funcionalidade faz as requisições por meio de um gateway de LLM compartilhado em execução no Kubernetes.
A equipe estabelece um período de validação de 24 horas, incluindo um namespace de produção, um gateway e dois provedores de modelos, e então compara os contadores de tokens do gateway, o uso do provedor e a saída do Attribute™.
| Etapa de validação | Resultado |
|---|---|
| Total do provedor e do gateway | US$ 10.200 de uso de IA no escopo |
| Gasto atribuído a tenants conhecidos | US$ 9.650 |
| Gasto não mapeado ou não atribuído | US$ 550, ou 5,4% do escopo |
| Conclusão inicial | A atribuição é útil, mas ainda não está completa |
A equipe investiga a discrepância em vez de tratá-la como erro de cálculo. Encontra duas causas:
- O tenant lançado mais recentemente tem identificadores de runtime que não constam no mapeamento de negócio.
- Um workload em lote usa o mesmo gateway, mas está fora do escopo original do namespace.
A equipe adiciona o mapeamento do tenant que faltava, separa o workload em lote e refaz a comparação com as janelas de tempo alinhadas. Desta vez, a equipe obtém 99% de cobertura para o escopo definido da funcionalidade; o restante da variância se deve ao timing do faturamento do provedor.
O importante não é o percentual em si. A equipe agora tem uma explicação consistente para o número, responsabilidade definida sobre qualquer gasto que não tenha sido mapeado e um procedimento de validação que pode usar sempre que novos tenants, modelos ou workloads forem adicionados.
Ainda vê gastos de IA sem alocação? Baixe 5 Reasons AI Costs Don't Add Up e entenda por que tags e SDKs não conseguem fechar essa lacuna. Baixe o ebook →
6. Teste os casos extremos que distorcem o unit economics
Não basta simplesmente fazer uma requisição, porque sistemas de IA em produção podem apresentar comportamentos que afetam o custo aparente de uma funcionalidade ou de um cliente. Teste pelo menos:
- Retries após erros do provedor
- Respostas em streaming
- Prompts ou respostas em cache
- Requisições em lote
- Vários modelos por trás de um único gateway
- Tráfego gerado por humanos e por agentes
- Workloads de GPU compartilhada
- Conexões de longa duração com bancos de dados ou gateways
- Failover entre provedores
Workloads Java merecem atenção especial, já que a visibilidade do eBPF no nível do kernel não é suficiente para o tráfego TLS criptografado dentro da plataforma Java — e é por isso que o Attribute™ desenvolveu um agente Java para esse cenário. Para conhecer os modos de implantação suportados, as limitações e as verificações a serem feitas após a instalação, consulte o Java Instrumentation Guide.
A questão da validação não é apenas se o sensor está em execução; é também se o sensor observa o tráfego relevante para esse workload da forma como esse workload realmente opera.
7. Mantenha a cobertura como mecanismo de controle
A qualidade das atribuições varia conforme o ambiente, pois lacunas podem surgir depois que a implantação inicial foi validada, quando novos tenants, gateways, modelos, namespaces ou funcionalidades são adicionados.
Crie uma revisão recorrente que verifique:
- Identificadores recém-observados sem mapeamento
- Gastos atribuídos a uma dimensão desconhecida ou compartilhada
- Mudanças na cobertura atribuída
- Mudanças inesperadas no custo por requisição ou por funcionalidade
- Workloads que pararam de reportar
- Diferenças entre os totais do provedor e os totais atribuídos
Ao implementar, trate a cobertura como uma métrica operacional, e não como uma conquista pontual.
Um checklist prático de aceitação
Antes de declarar uma implantação de atribuição pronta para produção, confirme:
- As perguntas de negócio e as dimensões relevantes foram registradas.
- O escopo exato e o período estão claramente definidos.
- O identificador-alvo é visível no caminho do tráfego em runtime.
- Os clusters, hosts, contas e workloads estão todos registrados.
- Os identificadores de runtime têm nomes legíveis para o negócio.
- Os gastos não mapeados e não atribuídos estão visíveis.
- A atividade em runtime é conciliada com os dados fornecidos pelo provedor ou gateway.
- Retries, cache, streaming e workloads compartilhados foram testados.
- Os workloads Java com TLS foram devidamente avaliados.
- Há um responsável pela cobertura e pela variância, com um cronograma de revisão.
Conclusão
A atribuição de custos de IA só tem valor na medida em que as pessoas confiam nela o suficiente para tomar decisões com base nela.
Essa confiança nasce de um processo repetível; para isso, é preciso especificar a pergunta, limitar o escopo, verificar se há visibilidade em runtime, vincular os identificadores técnicos ao contexto de negócio, conciliar as diferentes visões, testar os casos extremos em produção e acompanhar a cobertura ao longo do tempo.
O Attribute™ fornece a camada de medição em runtime para IA e para a infraestrutura compartilhada; ainda assim, a qualidade dos resultados continua sendo determinada pelo modelo de atribuição, pela fronteira de coleta e pelo processo de validação associado.
Para equipes que estão migrando de faturas agregadas de IA para custo por cliente, funcionalidade ou agente, a validação não é a etapa final após a implantação. Ela é o sistema operacional do programa de medição.
