A IA virou uma linha de gastos “normal” e, ao mesmo tempo, uma das mais difíceis de detalhar para o negócio. No State of FinOps 2026, 98% dos 1.192 respondentes dizem que já gerenciam gastos com IA (eram 31% dois anos antes), em um universo que representa mais de US$ 83 bilhões em gastos anuais com nuvem.
Isso muda a forma de medir e explicar custos. Otimizar instâncias e negociar Savings Plans continuam importantes, mas não é suficiente quando o consumo passa a ser medido em tokens, latência, qualidade e “custo por resposta”.
A seguir, um caminho prático para fazer essa virada de mentalidade.
Por que “custo da GPU” não é a métrica certa (sozinho)
“Quanto estamos gastando em GPU (unidade de processamento gráfico)?” é uma pergunta comum quando o assunto é IA/GenAI (IA generativa). Mas ela raramente responde ao que o negócio precisa saber:
- Quanto custa atender um cliente com IA?
- Qual o custo de cada resposta útil (e não só de cada chamada)?
- Qual é o custo marginal para dobrar o volume?
- O ganho de qualidade vale o aumento de custo?
Em IA/GenAI, grande parte do custo está no uso, não só na infraestrutura. E o uso (principalmente via API (Application Programming Interface, interface de programação de aplicações)) tem armadilhas comuns: o preço por token é um ponto de partida, mas o custo real costuma estar nos detalhes, como a diferença de custo entre tokens de entrada e de saída e o efeito do contexto acumulado (“context window creep”).
Uma regra prática de FinOps (Financial Operations, prática de gestão financeira de nuvem) para IA: troque “custo da GPU” por custo por resposta (e, idealmente, custo por resposta bem-sucedida).
Treinamento vs inferência: duas naturezas de gasto, dois modelos de governança
1) Treinamentos (treinamento/fine-tuning)
- Tendem a ser picos de gastos (projetos, ciclos, experimentos).
- O risco é “queimar GPU” com pipeline ruim, I/O (input/output, entrada e saída) lento, checkpoints caros ou paralelismo ineficiente.
- Um dado que chama atenção (e ajuda a justificar FinOps + MLOps (Machine Learning Operations, operação e governança do ciclo de vida de modelos)): um estudo com 400 jobs reais em plataforma industrial de deep learning encontrou utilização média de GPU de 50% ou menos e mapeou 706 problemas de baixa utilização, quase metade ligada a operações de dados (gargalos fora da GPU).
Tradução para FinOps: comprar mais GPU sem atacar gargalos é, muitas vezes, comprar ociosidade.
2) Inferência (produção)
- Tende a ser gasto recorrente e crescente, diretamente ligado ao produto (usuários, sessões, volume).
- Aqui “custo por resposta” vira o KPI (Key Performance Indicator, indicador-chave de desempenho) mais útil para acompanhar o uso, porque é o que escala com o consumo.
- Há um detalhe importante: em muitos provedores, tokens de saída custam mais, frequentemente 3 a 5 vezes o custo de tokens de entrada. Isso torna respostas longas um multiplicador de custo.
O novo KPI: “custo por resposta” (e como calcular sem auto engano)
Pense em uma resposta de IA como um “pedido” composto por peças:
Custo por resposta ≈
- Tokens de entrada (prompt + contexto + RAG (Retrieval-Augmented Generation, geração com recuperação))
- Tokens de saída (resposta)
- Modalidades (imagem/áudio, se houver)
- Infra/runtime (GPU/CPU, orquestração, filas, cache, rede, observabilidade)
- Retrieval (banco vetorial, re-ranking, armazenamento, egress)
Um alerta de FinOps prático: otimizar preço por token não garante menor custo por resposta, porque o modelo “mais caro” pode responder com menos tentativas, menos ferramentas, menos tokens e menos retrabalho, e sair mais barato no total. Esse é um ponto recorrente no debate de IA/GenAI em FinOps.
“Context window creep”: um custo pouco visível
Como muitos LLMs (Large Language Models, modelos de linguagem de grande porte) são stateless (não mantêm estado), aplicações conversacionais reenviam parte (ou todo) o histórico a cada turno. Isso faz o custo crescer sem ninguém perceber e, em produção, vira um custo que cresce rápido e costuma passar despercebido.
Utilização de GPU: a perda de eficiência que FinOps precisa enxergar
Se você roda treinamento ou serve modelos em GPU própria (ou instâncias com GPU), a utilização vira dinheiro.
- Utilização baixa significa GPU esperando dados, sincronização, checkpoints, rede.
- No estudo citado, cerca de 46% dos problemas estavam ligados a operações de dados. O trabalho aponta que muitos casos se resolvem com pequenas mudanças de código/script.
O que medir (mínimo viável):
- Utilização de SM (Streaming Multiprocessor, bloco de processamento da GPU), não só “GPU %” genérico
- Throughput (tokens/s, requests/s)
- Latência por etapa (prefill vs decode em LLMs)
- Fila/espera por dados (I/O, CPU, rede)
- Memória e pressão de KV cache (KV = key-value, chave-valor) na inferência
Um exemplo do quanto dá para ganhar quando você trata eficiência como produto: um sistema de “GPU pooling” para servir múltiplos modelos em marketplace (Aegaeon) reportou reduzir a necessidade de GPUs de 1.192 para 213 (82% de economia) e aumentar goodput em múltiplos cenários.
Você não precisa replicar essa arquitetura para capturar o insight: eficiência é alavanca financeira, não detalhe técnico.
Guardrails: políticas de uso que viram “controles financeiros” no produto
FinOps para IA dá certo quando vira design de produto + padrões de engenharia. Alguns guardrails que costumam funcionar bem:
1) Guardrails de consumo (custo direto)
- Limite de output tokens por caso de uso (ex.: resumo ≤ 300 tokens; chatbot ≤ 600)
- Teto de contexto (ex.: “últimos 6 turnos” + memória resumida)
- Rate limit por usuário/tenant e por endpoint
- Budget por squad/produto com alertas por anomalia (diário/horário)
2) Guardrails de eficiência (custo indireto)
- Cache (respostas frequentes, embeddings, resultados de RAG)
- Model tiering: modelo “barato” por padrão, “caro” só quando necessário (roteamento por complexidade)
- Batching e filas para workloads assíncronos
- Observabilidade de prompts (versões, templates, regressão de custo)
3) Guardrails de valor (o ponto que destrava valor)
- Métrica de sucesso: custo por resposta aceita / custo por tarefa concluída
- Teste A/B (comparação controlada) de custo x qualidade, não só UX (User Experience, experiência do usuário)
- “Self-funding”: otimizações que liberam orçamento para IA é um padrão reportado no mercado
FinOps + MLOps: o operating model que evita “IA sem dono”
Uma prática comum em times mais estruturados é juntar ciclos:
- MLOps responde: versão do modelo, avaliação, drift (mudança de comportamento), rollback (voltar versão), SLO (Service Level Objective, objetivo de nível de serviço)
- FinOps responde: alocação, orçamento, unit economics (economia por unidade), governança, forecast (previsão)
- Produto responde: valor, conversão, adoção, satisfação, risco
O State of FinOps 2026 enfatiza “shift left”: trazer contexto financeiro pré-deploy (antes de ir para produção). Em IA, isso faz diferença em escala: uma pequena decisão (contexto maior, resposta mais longa, modelo mais caro sempre) pode multiplicar custo por 2 a 10 vezes e virar dívida financeira.
