Início/Blog/Observabilidade de custos cloud FinOpsObservabilidade 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.
Publicado em 8 de junho de 202612 min de leituraFinOps para IA
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 IANegó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ície | Sinal direto | Dimensão útil | Pergunta de otimização |
|---|
| Inferência | Tokens 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? |
| Embeddings | Tokens, documentos, frequência e batch jobs. | Corpus, produto, tenant, pipeline e owner. | Documentos sem mudança ou sem uso estão sendo reprocessados? |
| Banco vetorial | Vetores, query units, réplicas, index builds e transferência. | Corpus, tenant, feature e ambiente. | Quais índices e réplicas produzem retrieval útil? |
| GPU e serving | GPU-seconds, memória, sequências, batch fill e idle. | Modelo, classe, tenant share e endpoint. | Capacidade compartilhada está justa e bem utilizada? |
| Storage e egress | Bytes 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 evals | Execuçõ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.