O problema real
Uma equipe treinando um modelo de linguagem moderado (7B de parâmetros) em 4 GPUs A100 deixa a infra rodando por 8 horas durante a noite. Ninguém desliga a máquina. Resultado: R$ 120 por dia caindo na conta AWS (ou ~R$ 3.600 por mês), sendo que apenas 4 horas eram efetivamente usadas para treino. O resto? GPU ociosa.
Em produção, o cenário é pior. Uma empresa com serviço de chat movido por LLM vai descobrir que a fatura subiu 3x em um mês não porque o tráfego triplicou, mas porque tokens de egress saíram para fora da região, checkpoints de modelo ficaram ano inteiro no storage, e o batch de inferência nunca saiu do tamanho 1. FinOps para IA é o exercício de traduzir prioridades técnicas em real: GPU ociosa custa dinheiro. Banda de saída custa dinheiro. Replicação desnecessária de modelo custa dinheiro. Sem observabilidade de custo tag a tag, ninguém sabe onde o dinheiro vai.
O custo de uma GPU e as alavancas que mexem nele
Uma GPU A100 on-demand em sa-east-1 (São Paulo) sai por US$ 3,06 por hora (agosto 2026). Em repouso, durante 8 horas de neglect noturno, você paga US$ 24,48 só pra deixar ela ligada. Multiplique por 30 dias: US$ 735 por mês em desperdício puro.
Três levers mudam radicalmente esse número:
Instâncias spot vs. on-demand vs. reservadas
- On-demand: US$ 3,06/h por A100. Máxima flexibilidade, zero compromisso. Você paga pelo que usa.
- Spot: US$ 0,92/h pela mesma A100. 70% de desconto. Armadilha: AWS pode interromper com 2 minutos de aviso. Vira a opção certa só pra carga interrompível (treino que pode ser retomado, batch processing, experimentos).
- Reserved Instance (1 ano): US$ 1,84/h. Você se compromete. Se pedir 1 instância 24/7 por 365 dias, fica R$ 4.815 (câmbio 5,2). Vs. on-demand: R$ 15.800. Economiza R$ 11k. Mas se a máquina ficar ociosa 30% do tempo, o número fica feio.
Quando cada uma compensa:
| Cenário | Melhor opção |
|---|---|
| Experimentação, POC, prototipagem | Spot (desconto 70%) |
| Carga de treino com checkpointing (pode pausar) | Spot (com retry) |
| Serviço em produção, inferência H24 | Reserved 1 ano + Spot para burst |
| Pico esporádico (Black Friday, lançamento) | On-demand puro (dura 2-3 dias) |
GPU ociosa: o vilão número 1
Uma métrica que ninguém mede: GPU utilization. Você vê no dashboard 1 GB de 40 GB ocupado, pensa "ok, rodando". Mas a GPU tá processando 4% de seus cores. Os outros 96%? Ociosos. Pagando.
Quantização reduz tamanho do modelo de 16 bits para 8 bits ou 4 bits, economizando VRAM e acelerador de cálculo. Um modelo GPT de 7B quantizado em 4 bits cai de 14 GB para 3,5 GB. Economia de VRAM: 74%. Perda de qualidade: ~2% em benchmarks típicos.
# Quantização com bitsandbytes (2 linhas de mudança)
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
quantization_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_compute_dtype=torch.float16,
bnb_4bit_use_double_quant=True,
)
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Llama-2-7b",
quantization_config=quantization_config,
device_map="auto"
)
Resultado: o mesmo modelo roda em 1 GPU de 24 GB (T4, US$ 0,35/h) em vez de 1 GPU A100 de 40 GB (US$ 3,06/h). Economia: 88.5% do custo em compute, com latência +15ms (trade-off aceitável pra muitos casos).
Batching: a alavanca invisível
Inferência serial (request por request) é o setup mais comum. Vem chat, processa 1 prompt isolado. Latência: 200ms. GPU: 3% utilização.
Batching agrupa requests. 32 prompts entram juntos. Latência por request: 220ms (praticamente igual). GPU: 87% utilização. Throughput: 32x maior com a mesma máquina.
Problema: onde fazer batching? Em API serverless não dá (timeout rígido). Em container com worker pool, dá perfeitamente.
# Pseudo-batch para vLLM (servidor de inferência otimizado)
from vllm import LLM
llm = LLM(model="meta-llama/Llama-2-7b-hf", dtype="float16")
# Sem batching: 32 requests = 32 chamadas de modelo
for request in requests:
output = llm.generate(request)
# Com vLLM (batching automático, HTTP):
# 32 requests chegam, o servidor agrupa e processa em 1 batch
# GPU fica 80%+ utilizando, latência quase igual
A diferença de custo? Se você rodar 1M requests/dia em uma A100 pura (sem batching): US$ 1.600. Com batching eficiente na mesma máquina: US$ 200. A mesma infraestrutura, 8x mais barata.
Armazenamento de checkpoint: o silencioso
Você treina um modelo, salva checkpoint a cada epoch. 20 epochs × 14 GB (tamanho do modelo) = 280 GB armazenados. S3 em sa-east-1 custa US$ 0,023 por GB/mês. Seu checkpoint custa US$ 6,44 por mês só pra estar ali.
Pior: o experimento é cancelado. Ninguém deleta. 6 meses depois, continua custando. Multiplique por 10 experimentos: US$ 386 por mês em lixo.
Solução: política de retenção automática. Guarda últimos 3 checkpoints, deleta o resto.
import boto3
import os
from datetime import datetime, timedelta
s3 = boto3.client('s3')
def cleanup_old_checkpoints(bucket, prefix, keep_count=3):
response = s3.list_objects_v2(Bucket=bucket, Prefix=prefix)
if 'Contents' not in response:
return
# Ordena por data
objects = sorted(
response['Contents'],
key=lambda x: x['LastModified'],
reverse=True
)
# Deleta tudo que passar de keep_count
for obj in objects[keep_count:]:
s3.delete_object(Bucket=bucket, Key=obj['Key'])
print(f"Deletado: {obj['Key']}")
# Agenda isso diariamente via CloudWatch Events + Lambda
cleanup_old_checkpoints('my-ml-bucket', 'checkpoints/exp-2026-01/')
Economia: se você fez 100 experimentos e deixa 3 checkpoints cada, deleta 97. Com modelo de 14 GB: 1.358 GB deletados × US$ 0,023 = US$ 31,23 de economia por mês. Só isso.
Custo de API vs. modelo próprio
Chamar GPT-4 via OpenAI custa US$ 0,06 por 1M input tokens, US$ 0,18 por 1M output tokens. Um chatbot médio (25K tokens entrada, 5K tokens saída, por request) em 1M requests/mês fica:
- Entrada: 25B tokens × (US$ 0,06 / 1B) = US$ 1.500
- Saída: 5B tokens × (US$ 0,18 / 1B) = US$ 900
- Total: US$ 2.400 por mês
Rodar Llama 2 7B próprio em batching ótimo numa A100 (US$ 2.208 por mês, on-demand 24/7):
- Amortizado: US$ 73,60 por dia
- 1M requests: precisa de ~3 horas em A100 com batching (latência 150ms, batch 64)
- Custo por dia: US$ 9,20 (3 horas)
- Total: US$ 276 por mês (1M requests)
Ponto de equilíbrio: ~230k requests/mês. Acima disso, modelo próprio ganha. Abaixo, API é mais barato (sem overhead operacional).
Rastreabilidade com tags e alertas
Sem observabilidade, você não sabe onde sai o dinheiro. AWS permite tags em todo recurso. Use:
# Tags obrigatórias em toda GPU, instância, storage
Tags:
- Key: "team"
Value: "ml-platform"
- Key: "project"
Value: "chat-app"
- Key: "environment"
Value: "production"
- Key: "cost-center"
Value: "produto"
Aí você filtra a fatura por team: ml-platform e vê: "o time gastou US$ 5.200 esse mês, 60% em GPU".
Alertas de orçamento salvam vidas:
# AWS CLI: criar alerta se custo ultrapassar US$ 1000/mês
aws budgets create-budget \
--account-id 123456789012 \
--budget file://budget.json \
--notifications-with-subscribers file://notifications.json
Exemplo de budget.json:
{
"BudgetName": "ml-team-monthly",
"BudgetLimit": {
"Amount": "1000",
"Unit": "USD"
},
"TimeUnit": "MONTHLY",
"BudgetType": "COST",
"Tags": {
"team": "ml-platform"
}
}
Quando bater US$ 800, avisa. Quando bater US$ 900, avisa de novo. Quando bate US$ 1000, desliga a fila de treino ou limita concorrência.
Armadilhas comuns
Egress de modelo: você tem modelo em S3 sa-east-1, mas a aplicação roda em sa-east-1b de AZ diferente? Conta egress: US$ 0,02 por GB. Um modelo de 7 GB transferido 1M vezes por mês = US$ 140 em egress puro. Solução: EBS local ou cache.
Checkpoint nunca deletado: comum em experimentos. Um único checkpoint de 40 GB esquecido durante 1 ano custa US$ 11,04. Multiplique por 20 experimentos = US$ 220 em lixo, e ninguém percebe porque é spread entre mil tags.
Batch size errado: 1 request por vez em instância de 8 GPUs. Significa 7 GPUs ociosas. Batch size = 1 tb 256 faz diferença dramática. Teste batch exponencialmente: 1, 2, 4, 8, 16, 32, 64. Acha o sweet spot (latência aceitável + GPU full).
Quando NÃO usar FinOps agressivo
Se seu custo mensal de infraestrutura é abaixo de US$ 500, a complexidade de otimização pode gastar mais tempo que o que você economiza. Reserve economia agressiva pra quando a conta virar problema real (> US$ 2000/mês).
Se o projeto é one-off (hackathon, MVP de 2 semanas), não vale tacar Reserved Instances. Usa spot pura, aceita possível interrução.
Se latência é crítica (< 50ms), não comprime modelo agressivamente só por economia. O trade-off não vale.
Próximos passos
Estude Kubernetes para quem vem do Docker Compose pra orquestrar workloads com FinOps tags por pod.
Mergulhe em Observabilidade em aplicações com LLM pra medir ROI de cada request, não só custo.
Use ferramentas como Kubecost, CloudZero ou Cast.ai pra ter dashboard com gráficos de custo em tempo real, com alertas automáticos. Invista 2 dias de eng pra economizar months de infraestrutura.