Início/Blog/Observabilidade de custos cloud
FinOps

Observabilidade de custos cloud para workloads de IA

Uma fatura de provider informa quanto a organização gastou. Normalmente não informa qual tenant, feature, agente, avaliação, job agendado ou resultado útil causou o gasto. Observabilidade de custos de IA constrói essa cadeia ausente.

Gasto de IA atravessa medidores demais para FinOps baseado apenas em fatura

A FinOps Foundation descreve FinOps for AI como resposta a modelos de custo complexos, ciclos rápidos, gasto imprevisível e necessidade de alinhar consumo a valor. Uma feature de IA pode criar tokens, embeddings, consultas vetoriais, object storage, capacidade GPU, logs, egress, tool calls e avaliações agendadas em vários providers.

Tags cloud são necessárias, mas param na fronteira do recurso. Endpoints de inferência e clusters vetoriais compartilhados atendem muitos tenants e features. A aplicação precisa adicionar dimensões que o billing não vê: request, tarefa, agente, versão do prompt, feature, tenant, ambiente, owner e resultado.

Dashboard de alocação de custos de IA
NegócioCusto por resultado útilResolução, sugestão aceita, workflow concluído ou evento de receita.
ProdutoCusto por feature e tenantQuais superfícies e tiers consomem capacidade compartilhada.
WorkflowCusto por tarefa e agenteModel calls, tools, retries, jobs e profundidade da cadeia.
ModeloMix de inferência e embeddingsModelos, providers, cached input, output, batch, avaliações e qualidade.
PlataformaInfraestrutura compartilhadaGPUs, bancos vetoriais, storage, observabilidade, filas e egress.
GovernançaOwnership e alocaçãoTime, projeto, cost center, ambiente, budget, anomalias e forecast.

Construa linhagem de custo, não outro dashboard de billing

A especificação FOCUS fornece uma linguagem comum para dados de custo e uso. Tags da AWS e regras de alocação Azure adicionam contexto e distribuem custos compartilhados. A Usage API da OpenAI agrupa custos por projeto e line item. Convenções GenAI do OpenTelemetry padronizam telemetria de operações de modelo. Ainda é necessário um join key que conecte uso do provider ao trace da aplicação e resultado de negócio.

Carregue correlation IDs do request até tarefa do agente, chamada de modelo, embedding, consulta vetorial, storage e tool downstream. Depois una registros de uso e alocação de recursos compartilhados a esses IDs. O resultado é um cost trace explicando cobranças diretas e overhead alocado.

OwnershipTime, cost center, produto, ambiente, owner e política de budget.
WorkloadFeature, tenant, tarefa, agente, modelo, versão do prompt e job.
RecursoTokens, GPU, embeddings, vector DB, storage, egress, logs e tools.
ResultadoQualidade, latência, conclusão, aceitação, receita, falha e abandono.

Aloque infraestrutura compartilhada com drivers de uso

Alocação igual é simples e geralmente errada. Pools GPU podem usar GPU-seconds ou tempo de sequência ativa. Bancos vetoriais podem usar vetores armazenados, query units e transferência. Observabilidade pode usar spans ou bytes ingeridos. Avaliações podem usar model calls e tamanho do dataset. O driver deve se parecer com o comportamento que cria custo e ser compreensível pelo time cobrado.

Mantenha a confiança da alocação visível. Chamadas diretamente medidas têm alta confiança. Um cluster compartilhado dividido por uso estimado tem confiança menor. Custo não alocado deve ser métrica acompanhada, não distribuído silenciosamente.

SuperfícieSinal diretoDimensão útilPergunta de otimização
InferênciaTokens input, cache, output, reasoning, calls, modelo e tier.Tenant, feature, tarefa, agente, prompt e resultado.Qual modelo e prompt produzem valor com qualidade aceitável?
EmbeddingsTokens, documentos, frequência e batch jobs.Corpus, produto, tenant, pipeline e owner.Documentos sem mudança ou sem uso estão sendo reprocessados?
Banco vetorialVetores, query units, réplicas, index builds e transferência.Corpus, tenant, feature e ambiente.Quais índices e réplicas produzem retrieval útil?
GPU e servingGPU-seconds, memória, sequências, batch fill e idle.Modelo, classe, tenant share e endpoint.Capacidade compartilhada está justa e bem utilizada?
Storage e egressBytes armazenados, retidos, lidos, escritos e transferidos.Dataset, artefato, tenant, região e retenção.Quais dados estão duplicados, stale ou cruzando regiões?
Jobs e evalsExecuções, calls, linhas, duração, falhas e retries.Versão, experimento, owner e decisão de release.Quais jobs recorrentes não influenciam mais decisões?

O que eu construiria

Eu construiria um pipeline de telemetria de custos que enriquece cada operação de IA com dimensões da aplicação antes de exportar traces e uso. Exports de providers, billing normalizado por FOCUS, APIs de uso, métricas Kubernetes, uso de banco vetorial e storage entrariam em um cost ledger.

O dashboard permitiria ir do gasto mensal até feature, tenant, workflow, model call e resultado. Destacaria gasto não alocado, alocações de baixa confiança, anomalias, capacidade ociosa, jobs stale e features cujo custo cresce mais rápido que seus resultados úteis.

O princípio de design

Observabilidade de custo só está completa quando quem pode mudar o sistema vê o custo que influencia e o valor criado. Aloque recursos a workloads, workloads a comportamento de produto e comportamento a resultados. Tudo que resta como “custo compartilhado de IA” é uma pergunta de engenharia ainda sem resposta.