Pular para o conteúdo principal
Fechar
FinOps

FinOps para IA: Custo por Token e a GPU que Você Não Usa

Gabriel Ferraresi· CEO | Tech8628 de maio de 20265 min
finopsiagpucusto-por-tokencloud

73% dos projetos de IA estouram o orçamento, segundo o State of FinOps 2026 da FinOps Foundation. Alguns 2.4x do planejado. O budget médio enterprise saltou de US$ 1,2 milhão para US$ 7 milhões em dois anos — e a maioria dos CFOs não sabe quanto custa cada token. Na Tech86, vimos empresas queimando US$ 2,3 milhões em custos que ninguém previu porque ninguém instrumentou. Sem custo por token, qualquer otimização é achismo.

O problema de visibilidade

A fatura da Anthropic chega como linha única: US$ 100 mil/mês. Sem detalhamento por cliente, feature ou workflow. Uma query de banking dispara 1 orchestrator, 3 retrievers, 4 tool calls e 7 model invocations. O custo fica enterrado 6 níveis abaixo. O Cost Explorer não enxerga.

O problema não é falta de ferramentas — é falta de granularidade. FinOps tradicional opera no nível da instância. FinOps para IA precisa operar no nível do token. Se você não sabe quanto custa cada token processado por endpoint, não sabe onde está queimando dinheiro. E 98% dos times de FinOps agora gerenciam spend de IA, segundo o State of FinOps 2026 — era 31% em 2024. A demanda explodiu, o guia ainda não existe.

80-90% do gasto é inferência — e a GPU está ociosa

O treinamento domina o hype. A inferência domina a conta. 80-90% do spend de IA é inferência, segundo dados da indústria, não training. E a utilização de GPU média fica entre 15-30%, segundo análises de FinOps. Metade do budget paga hardware ocioso.

O culpado principal: endpoint provisionado para pico. Você configura a infra para aguentar o horário comercial de segunda, e ela fatura hora cheia 24/7. De madrugada, tráfego zero, GPU cobrando. Utilização abaixo de 50% é dinheiro recuperável. É como alugar um caminhão para entregar uma carta e pagar diária integral.

Na Tech86, quando auditamos workloads de IA, o primeiro número que procuramos é utilização de GPU por endpoint e por horário. Se está abaixo de 50%, já sabemos que há margem significativa de economia.

Custo por token: a métrica que separa controle de achismo

Custo por token é simples na teoria: despesas diárias de inferência divididas por tokens processados. Na prática, exige instrumentação na camada de aplicação. Você precisa rastrear tokens por endpoint, por modelo, por cliente, por feature. Sem isso, está voando cego.

Um exemplo concreto: Opus 4.6 custa 21x mais que MiniMax M2.5 para 0.6% de diferença no benchmark. Se você não tem custo por token por endpoint, não sabe qual modelo está consumindo quanto. Não sabe se o Opus está rodando para tasks comuns que o MiniMax resolveria. Não sabe se um cliente que representa 12% do revenue está consumindo 78% do spend de LLM. Essa assimetria é invisível sem a métrica certa.

Custo por token transforma otimização de palpite em decisão de dados. Com ela, você compara modelos no custo real por task, identifica endpoints superdimensionados e quantifica o impacto de cada mudança de arquitetura.

As alavancas que funcionam

Dynamic batching e caching são o ganho mais rápido. Ao agrupar requisições e cachear respostas frequentes, utilização de GPU sobe de 30% para 70%. O custo cai proporcionalmente. Não é teoria — é o que acontece quando a GPU para de processar uma requisição por vez e começa a trabalhar em batch.

Model routing por complexidade é a segunda alavanca. Tasks comuns em modelo barato, reasoning em modelo de ponta. Economia de 5-10x. Já cobrimos isso em detalhe no nosso artigo sobre model selection — aqui o foco é que sem custo por token, você não sabe se o routing está funcionando.

Autoscaling com GPU metrics é a terceira. CPU-based autoscaling não funciona para GPU. Um endpoint pode ter CPU baixa mas GPU saturada. O correto é usar KEDA com NVIDIA GPU Operator para escalar baseado em utilização real de GPU. Scale to zero em períodos de baixa. Sem isso, o endpoint provisionado para pico continua faturando 24/7.

Spend caps e inferência local: quando cloud não é a resposta

Spend caps são o freio que faltava. Google Cloud lançou em 2026: pause automático ao atingir budget. Sem isso, um agentic loop descontrolado gera custos que parecem tráfego legítimo até chegar a fatura. Spend caps por endpoint e por projeto são governança básica — não luxo.

Inferência local é a conta que poucos fazem. Para workloads com volume estável e alto, o ponto de equilíbrio pode chegar em 3 meses, segundo dados do Signal 65 / Futurum Group. Cloud vence quando o volume é esporádico ou imprevisível — o autoscaling compensa o preço por hora. Mas se sua inferência roda 24/7 com carga previsível, infraestrutura local pode ser significativamente mais barata. O cálculo deve incluir hardware, energia, cooling e equipe de operação.

Conclusão

FinOps para IA é prática paralela: instrumentação em nível de token, alocação na camada de aplicação, governança de model routing, budget enforcement na API call. Sem fatura surpresa. Sem agentic runaway que parece tráfego normal. Sem GPU reservada que ninguém usa.

A pergunta para o CFO: quanto custa cada token do seu chatbot? Qual modelo roda para qual query? Qual cliente consome 78% do spend de LLM pagando 12% do revenue? Se a resposta é "não sei" para qualquer uma, você está queimando dinheiro.

Na Tech86, desenhamos FinOps para IA com custo por token, model routing e utilização de GPU como métricas centrais. Se você não sabe quanto custa cada token, está na hora de descobrir.

Interessado nesta solução?

Conheça nossos serviços gerenciados e infraestrutura.

Conheça FinOps para IA

Perguntas Frequentes

Custo por token é a métrica que divide o gasto total de inferência pelo número de tokens processados. Sem ela, você não sabe se está pagando demais por um endpoint, qual modelo consome mais budget, ou onde está o desperdício. É o equivalente a gerenciar custos cloud sem saber o preço por hora da instância.

É comum, mas não é normal. Significa que metade do budget de inferência paga hardware ocioso. O problema é o endpoint provisionado para pico que fatura hora cheia 24/7 — de madrugada com tráfego zero, a GPU continua cobrando. Dynamic batching e autoscaling com métricas de GPU resolvem isso.

Não. CPU-based autoscaling não reflete a utilização real da GPU. Um endpoint pode ter CPU baixa mas GPU saturada — ou o contrário. O correto é usar KEDA com NVIDIA GPU Operator para escalar baseado em métricas de GPU como utilização, memory usage e queue depth.

Para workloads de inferência com volume estável e alto, o ponto de equilíbrio pode chegar em 3 meses, segundo dados do Signal 65 / Futurum Group. Mas depende do workload: se o volume é esporádico, cloud com autoscaling ainda vence. O cálculo deve incluir custo de hardware, energia, cooling e equipe de operação.

Spend caps são limites de gasto configurados por endpoint ou projeto que pausam automaticamente a execução quando o budget é atingido. Google Cloud lançou essa funcionalidade em 2026. Sem spend caps, um agentic loop descontrolado pode gerar custos que parecem tráfego legítimo até chegar a fatura.

Blog — Fale Conosco

Tem alguma pergunta sobre nossos artigos ou serviços? Nossa equipe está pronta para ajudar.

Agendar Reunião

Reserve um horário.

Agendar Agora

E-mail

Envie uma mensagem.

[email protected]

WhatsApp

Conversa rápida.

Endereço

Avenida Paulista, 1636 - São Paulo - SP - 01310-200

Especialista Tech86

Online agora

Olá! Como podemos ajudar a escalar seu negócio hoje?

Tech86 Engineering

Nós valorizamos sua privacidade

Utilizamos cookies e tecnologias similares para otimizar a sua experiência, analisar o tráfego do site e personalizar conteúdo. Ao clicar "Aceitar Todos", você concorda com o uso de todos os cookies. Leia nossa Política de Privacidade.