Pular para o conteúdo
CloudIntermediário

FinOps para IA: como controlar o custo de LLMs e GPUs

Entenda de onde vem o custo de IA, de tokens a GPU ociosa, e aplique as alavancas que mais reduzem a conta: roteamento de modelos, cache, batch, tags e orçamento.

Por Equipe IAUAI Estudos · 29 de julho de 2026 · 9 min de leitura

Nesta página

Ao final deste artigo você vai saber decompor a conta de uma aplicação de IA, identificar as alavancas que mais pesam, comparar API paga por uso com modelo próprio usando uma conta que você mesmo refaz com seus números, e montar a rotina mínima de tags, alertas e revisão que impede a surpresa no fim do mês.

Uma observação sobre preços: eles mudam com frequência e variam por região e contrato. Os valores de exemplo deste texto são inventados para ilustrar o raciocínio. Antes de decidir qualquer coisa, consulte as páginas oficiais de preço do seu provedor.

O problema real

Duas situações aparecem o tempo todo. A primeira é a GPU esquecida: um time sobe instâncias com GPU para um experimento, usa algumas horas e deixa ligadas a noite e o fim de semana. A segunda é a fatura de API que cresce sem que o tráfego tenha crescido, porque o prompt ficou maior, a resposta ficou mais longa ou alguém trocou o modelo por um mais caro.

Nos dois casos, o problema não é técnico, é de visibilidade. FinOps é a prática de ligar decisões de engenharia a custo, com dados, de forma contínua.

Para onde vai o dinheiro

Um sistema de IA costuma gastar em cinco lugares.

  • Tokens de modelos via API, cobrados por milhão de tokens de entrada e de saída, normalmente com preços diferentes para cada.
  • GPU para inferência ou treino própria, cobrada por hora de máquina ligada, esteja trabalhando ou não.
  • Armazenamento de dados, índices vetoriais, checkpoints e logs.
  • Transferência de dados, principalmente a que sai da nuvem ou cruza regiões.
  • Serviços auxiliares: bancos, filas, observabilidade.

Antes de otimizar, descubra qual desses domina a sua conta. Muita gente passa semanas afinando a GPU quando 80% do gasto são tokens.

Alavancas de custo com API

Escolher o modelo certo para cada tarefa

Os fornecedores oferecem modelos de tamanhos diferentes, e a diferença de preço entre um modelo pequeno e um de ponta costuma ser de uma ordem de grandeza. Classificação, extração e roteamento muitas vezes funcionam bem num modelo pequeno. Reserve o modelo de ponta para raciocínio difícil. Um roteador simples decide por tipo de tarefa e, quando preciso, tenta primeiro o modelo barato e escala para o caro se a verificação falhar.

A decisão certa vem de avaliações com evals no seu caso de uso: meça a qualidade de cada modelo e só então escolha.

Reduzir tokens de entrada

O custo cresce com o tamanho do prompt, e prompts crescem em silêncio. Revise instruções repetitivas, limite o histórico enviado, recupere só os trechos relevantes num RAG, em vez de colar documentos inteiros, e corte exemplos que não melhoram o resultado.

Prompt caching

Vários provedores oferecem cache de prompt: a parte inicial estável do prompt (instruções, documentos de referência) é processada uma vez, e as chamadas seguintes pagam bem menos por esse trecho e respondem mais rápido. Para aproveitar, coloque o conteúdo estável no começo e o variável no fim, e confira na documentação do seu provedor as regras de tamanho mínimo e de duração do cache.

Processamento em lote

Tarefas sem urgência, como classificar uma base inteira de documentos de madrugada, podem usar as APIs de batch oferecidas por vários provedores, que costumam cobrar menos em troca de um prazo maior de resposta. Confira o desconto e o prazo vigentes na documentação.

Controlar tokens de saída

A saída costuma ser mais cara por token do que a entrada. Defina max_tokens, peça respostas concisas quando for o caso e use formatos estruturados curtos. Uma instrução "responda em até três frases" pode cortar bastante o custo de uma funcionalidade.

Cache de respostas

Perguntas repetidas podem ser respondidas por um cache tradicional, com chave derivada da pergunta normalizada. Veja Cache com Redis na prática. Use com cuidado onde a resposta depende de dados que mudam ou de contexto do usuário.

Alavancas de custo com GPU própria

Pagar só pelo que usa

GPU ociosa é o desperdício mais comum. Tipos de compra existentes nas nuvens principais, com as trocas de sempre:

Modalidade Vantagem Risco
Sob demanda Flexibilidade total Preço cheio
Spot ou preemptível Desconto grande Pode ser interrompida com pouco aviso
Reserva ou plano de economia Desconto por compromisso de 1 a 3 anos Paga mesmo sem usar

Spot combina com treino que salva checkpoints e com processamento em lote que aceita repetir. Reserva combina com a carga de base que roda 24 horas por dia. Picos curtos ficam melhor sob demanda. Descontos e condições exatos mudam, então confira com o provedor.

Automatize o desligamento: agendamentos, autoscaling que chega a zero quando não há trabalho e alertas para instâncias de GPU com utilização baixa por horas.

Medir a utilização de verdade

A memória ocupada não diz se a GPU está trabalhando. Meça a utilização dos núcleos e o uso de memória, por exemplo com o nvidia-smi ou o exportador DCGM. Se a GPU passa a maior parte do tempo abaixo de uma fração pequena, você está pagando por capacidade que não usa, e o problema costuma ser falta de batching ou um gargalo no carregamento de dados.

Batching e servidores de inferência

Atender uma requisição por vez desperdiça a GPU. Servidores como vLLM ou o Text Generation Inference agrupam requisições simultâneas de forma contínua e aumentam muito a vazão por GPU.

from vllm import LLM, SamplingParams

llm = LLM(model="caminho-ou-nome-do-modelo")
params = SamplingParams(max_tokens=256, temperature=0.2)

prompts = ["Resuma: ...", "Classifique: ...", "Extraia: ..."]
saidas = llm.generate(prompts, params)   # a lista inteira é agrupada
for s in saidas:
    print(s.outputs[0].text)

Em produção, o mais comum é subir o servidor compatível com a API da OpenAI (vllm serve nome-do-modelo) e deixar que ele agrupe as requisições que chegam. O ganho real depende do modelo, do tamanho dos prompts e da sua meta de latência, então meça no seu caso.

Quantização

Reduzir a precisão dos pesos de 16 bits para 8 ou 4 bits diminui a memória e permite usar GPUs menores, geralmente com perda pequena de qualidade, que varia por modelo e tarefa. Teste no seu conjunto de avaliação antes de adotar.

import torch
from transformers import AutoModelForCausalLM, BitsAndBytesConfig

config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
)
modelo = AutoModelForCausalLM.from_pretrained(
    "nome-do-modelo-aberto",
    quantization_config=config,
    device_map="auto",
)

API ou modelo próprio

A comparação honesta usa a mesma carga nos dois lados. Faça a conta com uma planilha e seus números.

Custo da API por mês: requisições × (tokens de entrada × preço de entrada + tokens de saída × preço de saída).

Custo próprio por mês: horas de GPU ligadas × preço por hora, mais armazenamento, rede, observabilidade e o tempo da equipe para operar e atualizar. Se a GPU roda 24 horas e só trabalha 20% do tempo, o custo efetivo por requisição é cinco vezes maior que o teórico.

Modelo próprio tende a compensar com volume alto e constante, requisitos de privacidade que impedem enviar dados a terceiros, ou necessidade de ajuste fino. API tende a compensar com volume baixo ou irregular, e quando o time não quer operar infraestrutura de GPU. O ponto de equilíbrio muda com cada reajuste de preço de um dos lados, então revise a conta a cada trimestre.

Rastreabilidade: tags, orçamento e alertas

Sem atribuição, ninguém é dono do custo. Marque todo recurso com tags de time, projeto, ambiente e centro de custo, e ative essas tags como tags de alocação de custo no console de cobrança da sua nuvem. Para chamadas de API, registre feature e cliente em cada evento, como descrito em Observabilidade de LLM.

Configure orçamentos com alertas progressivos (por exemplo em 50%, 80% e 100% do previsto) e um alerta de previsão. Na AWS, o serviço é o AWS Budgets, e há equivalentes no Azure e no Google Cloud. Alertas avisam, e quem decide o que fazer é gente. Para chaves de API, vale também definir limites de gasto no painel do provedor, para que uma chave vazada ou um laço descontrolado não gere uma fatura enorme.

Armadilhas comuns

  • Transferência entre regiões e saída para a internet, que costumam ser esquecidas no cálculo. Mantenha modelo, dados e aplicação na mesma região.
  • Checkpoints, datasets e logs de experimentos abandonados. Defina política de retenção, como regras de ciclo de vida no armazenamento de objetos.
  • Ambientes de homologação com GPU ligada o tempo todo.
  • Laços de agente sem limite de passos ou de tokens. Defina tetos por requisição e por usuário.
  • Otimizar antes de medir. Comece pela maior linha da fatura.

Quando não otimizar agressivamente

Se o gasto mensal é pequeno, o tempo gasto otimizando pode custar mais que a economia. Em protótipos e experimentos curtos, o importante é aprender rápido, com um teto de gasto configurado. Também não degrade o modelo ou comprima demais quando a qualidade ou a latência são o produto.

Próximos passos

Faça o exercício em uma hora: exporte a fatura do último mês, agrupe por serviço, escolha os dois maiores itens e liste uma ação para cada. Depois ligue as tags e um orçamento com alerta.

Para organizar cargas de trabalho com limites por equipe, veja Kubernetes para quem vem do Compose.

Quer aplicar isso na sua empresa? Marque uma conversa de 45 minutos em https://iauaicloud.com.br/consultoria

Aprenda jogando

Corrida de GPU

Aumente o batch para ganhar velocidade — sem estourar a VRAM e travar tudo.

Jogar Corrida de GPU

Teste seu conhecimento

Teste o que você aprendeu sobre FinOps para IA

Pergunta 1 de 5

Antes de otimizar o custo de uma aplicação de IA, qual deve ser o primeiro passo?

Um conteúdo prático por quinzena

Deixe o seu e-mail para receber um conteúdo prático de IA e cloud a cada quinzena. Sem spam, e você pede a exclusão quando quiser.

Continue lendo