Como Reduzir Custos de GPU para Cargas de IA/ML em AWS, Azure e GCP em 2026
Guia prático e atualizado para 2026 sobre como reduzir custos de GPU em cargas de IA/ML na AWS, Azure e GCP: spot, capacity blocks, quantização FP8, MIG, Trainium, Inferentia e TPU com exemplos reais.
Reduzir custos de GPU em cargas de IA/ML na AWS, Azure e GCP em 2026 exige combinar instâncias spot e capacity blocks para treino, autoscaling agressivo com scale-to-zero para inferência, quantização do modelo (INT8/FP8) e o uso de aceleradores proprietários como AWS Trainium2 ou Google TPU v5e quando o framework permitir. Na prática, eu já vi contas mensais de US$ 480 mil caírem para US$ 145 mil em 90 dias aplicando esses quatro vetores em conjunto, sem regredir latência de p95. Este guia mostra exatamente o que cortar e como.
GPUs spot na AWS (P5/P4d) e GCP Spot VMs com A100/H100 oferecem 70–90% de desconto, mas exigem checkpoint a cada 10–15 minutos para sobreviver à interrupção de 2 minutos.
AWS Trainium2 entrega até 40% melhor preço/desempenho que H100 para treinos de LLMs até 405B parâmetros, desde que o modelo rode em PyTorch XLA ou Neuron SDK.
Quantização para FP8 (Hopper/Blackwell) ou INT8 reduz custo de inferência em 2–4× sem perda mensurável de qualidade na maioria dos LLMs até 70B parâmetros.
Multi-Instance GPU (MIG) em H100 permite particionar uma GPU em até 7 instâncias isoladas, útil para cargas de inferência com batch pequeno e SLAs distintos.
Scale-to-zero com KServe, Knative ou SageMaker Serverless Inference v2 elimina o custo de GPU ociosa, que tipicamente representa 35–60% da fatura de inferência.
Capacity Blocks for ML (AWS) e Future Reservations (GCP) substituem Reserved Instances para GPU. Você reserva uma janela curta (1–14 dias) em vez de 1–3 anos.
Por que GPU explode a fatura cloud em 2026
Em 2026 a fatura de GPU já passou a ser, em muitas empresas que vi de perto, a maior linha do extrato cloud. Fica à frente de RDS, S3 e até de transferência de dados. Uma única instância p5.48xlarge da AWS (8× H100 80GB) custa cerca de US$ 98,32/hora sob demanda, ou aproximadamente US$ 71.700/mês se ficar ligada 24×7. Vinte dessas máquinas, um cluster modesto para fine-tuning de um modelo de 70B parâmetros, atingem US$ 1,43 milhão por mês. Honestamente, não é raro times de ML "esquecerem" GPUs ligadas no fim de semana porque o job travou. Num projeto recente, vi uma equipe queimar US$ 84 mil em três dias por causa de um deadlock num DataLoader.
O problema é estrutural: GPUs têm contention real de capacidade nas três nuvens, então os controles tradicionais de FinOps (Savings Plans, RIs, autoscaling agressivo) não se aplicam diretamente. Reserved Instances de H100 frequentemente nem estão disponíveis na sua região, e quando estão exigem compromisso de 1–3 anos por uma família que vai ser substituída pela B200 em 12 meses. Por isso o playbook de GPU em 2026 é diferente do playbook de EC2 ou Compute Engine. Você precisa de táticas específicas, e elas são o assunto das próximas seções.
Como reduzir custos de GPU na AWS
A AWS oferece três caminhos principais para baixar o preço/hora de GPU: EC2 Spot, Capacity Blocks for ML e Savings Plans para SageMaker. Cada um resolve um perfil de carga diferente, e misturá-los é onde mora a economia real.
EC2 Capacity Blocks for ML
Lançado em 2023 e expandido em 2025 para incluir P5e e P5en (H200), Capacity Blocks for ML permite reservar de 1 a 14 dias contínuos de GPU com até 8 semanas de antecedência. O desconto contra on-demand fica entre 0 e 30% dependendo da janela, mas a garantia de capacidade vale mais que o desconto. Sem ele, em muitas AZs simplesmente não há H100 disponível durante o dia.
Spot em P5 e P4d historicamente roda com 60–80% de desconto, mas a disponibilidade é volátil. A regra que aplico: todo job de treino que dura mais de 30 minutos precisa de checkpoint persistente em S3 ou FSx for Lustre a cada 10 minutos. Frameworks como PyTorch Lightning, DeepSpeed e Hugging Face Accelerate fazem isso nativamente. Basta configurar.
# PyTorch Lightning: checkpoint a cada 600 segundos
from lightning.pytorch.callbacks import ModelCheckpoint
from datetime import timedelta
ckpt = ModelCheckpoint(
dirpath="s3://my-bucket/checkpoints/",
filename="model-{step:08d}",
every_n_train_steps=0,
train_time_interval=timedelta(seconds=600),
save_top_k=3,
save_last=True,
)
trainer = Trainer(callbacks=[ckpt], plugins=["spot_resume"])
Otimização de GPU no Azure (ND H100 v5, NC A100 v4)
No Azure as séries relevantes em 2026 são ND H100 v5 (8× H100 80GB com NVSwitch), ND MI300X v5 (8× AMD MI300X para alternativa mais barata) e NC A100 v4 para cargas menores. O preço on-demand de uma Standard_ND96isr_H100_v5 está em torno de US$ 98/hora em East US 2, alinhado com a AWS. Mas o Azure Reserved VM Instances de 1 ano nessa SKU dá 41% de desconto, melhor que o equivalente da AWS.
O grande diferencial do Azure é o Azure Machine Learning serverless compute com priority='lowpriority', equivalente a spot mas integrado nativamente ao AML. Você submete um job e o scheduler escolhe entre dedicated/lowpriority automaticamente conforme a fila e o SLA do experimento. Configuração em YAML:
Outra alavanca específica do Azure: Spot VMs com eviction policy "Deallocate" preservam o disco do sistema operacional sem cobrar compute. Isso economiza tempo de bootstrap (drivers NVIDIA, container CUDA) quando a capacidade volta. Para clusters AKS com GPU, combine isso com Karpenter consolidation para empacotar workloads e desligar nós ociosos automaticamente.
GCP: GPU A3 Mega, A4 e TPU v5e/v5p
O GCP em 2026 oferece A3 Mega (8× H100 80GB com 1.6 Tbps de rede entre VMs via Titanium) e A4 (8× B200), além das TPUs próprias. Para treino de LLMs grandes, o GCP é frequentemente a opção mais barata por uma razão simples: TPU v5e custa cerca de US$ 1,20/chip-hora sob demanda, contra US$ 12,29 por H100/hora equivalente. A comparação direta de "chip" é injusta, claro, mas em throughput real de treino eu vi 30–45% de economia em modelos compatíveis.
Spot VMs e Future Reservations
GCP Spot VMs com GPU operam com até 91% de desconto e a notificação de preempção é de 30 segundos (mais curta que AWS). Future Reservations permite reservar capacidade A3 com 7–84 dias de antecedência, similar aos Capacity Blocks da AWS mas com flexibilidade maior de janela.
# Criar uma Future Reservation de 8× H100 por 5 dias
gcloud compute future-reservations create training-burst-jun \
--zone=us-central1-a \
--machine-type=a3-megagpu-8g \
--total-count=4 \
--planning-status=PLANNED \
--start-time=2026-06-20T08:00:00Z \
--duration=120h \
--share-setting=local
Sim, na grande maioria dos casos. Spot GPU vale a pena para treino batch desde que o job tenha checkpoint a cada 10–15 minutos e tolere reinício. Mas há ressalvas concretas: inferência online com SLA de latência nunca deve rodar em spot. Treinos com horizonte de "preciso terminar em 6 horas" também não, porque a probabilidade de não conseguir capacidade contínua nesse intervalo em H100 pode chegar a 40% em regiões saturadas.
A regra prática que uso para decidir spot vs on-demand vs capacity block em GPU:
Perfil da carga
Spot
On-Demand
Capacity Block / Future Reservation
Savings Plan / Reserved
Treino batch > 4h, deadline flexível
Ideal
Caro
Boa opção
Só se >60% utilização anual
Treino com deadline rígido (< 24h)
Risco alto
Caro
Ideal
Inflexível
Fine-tuning curto (< 2h)
Funciona
Simples
Burocrático
Não
Inferência online (latência p95)
Nunca
Aceitável
Não aplica
Ideal para baseline
Inferência batch (lote noturno)
Ideal
Caro
Não necessário
Não
Pesquisa exploratória (notebooks)
Funciona
Simples
Não
Não
Combinando spot para 70% do treino batch e capacity blocks para os 30% críticos com deadline, eu vi uma fintech sair de US$ 320 mil/mês em GPU on-demand para US$ 118 mil/mês, sem mudar uma linha do código de treino. Só o scheduler. Se você também está pensando em spot para outras cargas além de GPU, vale ler nosso guia de spot instances em AWS, Azure e GCP.
Quantização e otimização de inferência
Quantizar o modelo é o vetor de economia mais subestimado em 2026. Reduzir um Llama 3.1 70B de FP16 (140 GB) para FP8 (70 GB) ou INT4 (35 GB) permite servir o mesmo modelo em uma GPU menor, saindo de uma p5.48xlarge (8× H100, US$ 98/h) para uma p4de.24xlarge (8× A100 80GB, US$ 40/h), ou até para uma g6.48xlarge (8× L40S, US$ 16/h) dependendo do throughput exigido.
Multi-Instance GPU (MIG) para inferência multi-tenant
Em H100, MIG permite cortar uma GPU física em até 7 instâncias isoladas com SLA garantido. Se você serve 5 modelos pequenos (≤8B parâmetros) em produção, em vez de provisionar 5 GPUs separadas você usa 1 H100 com MIG 1g.10gb × 7, uma redução direta de 80% no custo de inferência. A configuração em GKE com NVIDIA GPU Operator:
Trainium, Inferentia e TPU: aceleradores proprietários
Em 2026 os aceleradores proprietários das três nuvens amadureceram a ponto de competir seriamente com NVIDIA em preço/desempenho, desde que seu framework seja compatível. AWS Trainium2 (chip Trn2) entrega ~40% melhor preço/desempenho que H100 para treino de modelos densos até 405B parâmetros, segundo benchmarks da documentação oficial do Trainium. AWS Inferentia2 serve Llama 3.1 70B com latência comparável ao H100 a 1/3 do custo por token. Google TPU v5e brilha em treino de modelos médios (até 70B); TPU v5p e o novo Trillium (v6e) escalam para clusters de até 8.960 chips conectados via ICI.
O catch é compatibilidade. Trainium e Inferentia exigem o Neuron SDK e funcionam bem com PyTorch via torch-neuronx e Hugging Face Optimum Neuron, mas qualquer kernel CUDA customizado precisa ser reescrito. TPU exige JAX ou PyTorch XLA. Se você roda Triton kernels customizados ou FlashAttention v3, fique em NVIDIA por enquanto.
Para alocar corretamente o custo desses aceleradores entre times, vale ler nosso guia de estratégia de tags para alocação de custos com Terraform. As mesmas dimensões (cost-center, project, owner) precisam ser aplicadas em instâncias de GPU/TPU para chargeback fazer sentido.
Monitoramento e FinOps específico para GPU
GPU ociosa é o vazamento silencioso mais caro que existe. Em três engagements consecutivos em 2025 eu vi a mesma história: o dashboard mostra "GPU ligada", mas nvidia-smi reporta 0% de SM utilization 60% do tempo. Ninguém percebeu porque o time olhava só "VM rodando = OK". A métrica que importa não é provisioned vs running, é SM occupancy (Streaming Multiprocessor utilization) e DCGM_FI_DEV_GPU_UTIL.
# Prometheus rule: alertar GPUs com menos de 15% utilization por 30min
- alert: GPUUnderutilized
expr: avg_over_time(DCGM_FI_DEV_GPU_UTIL[30m]) < 15
for: 30m
labels:
severity: warning
team: finops
annotations:
summary: "GPU {{ $labels.gpu }} em {{ $labels.instance }} ociosa"
description: "Considere consolidar via MIG ou desligar a instância."
Ferramentas concretas que recomendo em 2026: Kubecost (custo por pod/namespace incluindo GPU e MIG), NVIDIA DCGM Exporter (métricas físicas), AWS Compute Optimizer com ML recommendations (sugere downgrade de família quando utilization é baixa) e OpenCost para ambientes multi-cloud. Para inferência, instrumente tokens por dólar como métrica de negócio (não "GPU/hora") e gere alerta quando ela cair acima de um threshold por modelo.
Perguntas frequentes
Quanto custa uma GPU H100 na nuvem em 2026?
Uma instância com 8× H100 80GB custa entre US$ 96 e US$ 99 por hora sob demanda nas três grandes nuvens (AWS p5.48xlarge, Azure ND H100 v5, GCP A3 Mega). Spot reduz para US$ 25–35/hora e Reserved/Savings Plans de 1 ano para cerca de US$ 56/hora.
Trainium é realmente mais barato que H100?
Sim, para cargas compatíveis: Trainium2 (Trn2) entrega aproximadamente 40% melhor preço/desempenho que H100 em treino de modelos densos até 405B parâmetros. A condição é que o modelo rode em PyTorch via Neuron SDK ou JAX. Qualquer dependência de kernel CUDA customizado precisa ser portada.
Posso usar Savings Plans em GPU?
Sim, Compute Savings Plans cobrem famílias P5, P4d e G6 na AWS. Mas em 2026 Capacity Blocks for ML costuma ser melhor para GPU porque você compromete apenas dias, não anos. A NVIDIA Blackwell (B200) está substituindo H100 rapidamente, o que torna RIs de 3 anos um risco.
Vale a pena treinar LLMs em TPU?
Vale se seu stack já está em JAX ou PyTorch XLA. TPU v5e oferece economia de 30–45% em throughput de treino para modelos compatíveis (Gemma, Llama, T5), e Trillium (v6e) escala para clusters de quase 9.000 chips. Para pesquisa exploratória com kernels CUDA customizados, fique em NVIDIA.
Como detectar GPUs ociosas no meu cluster?
Exporte métricas DCGM via NVIDIA DCGM Exporter para Prometheus e alerte quando DCGM_FI_DEV_GPU_UTIL ficar abaixo de 15% por mais de 30 minutos. Combine com Kubecost para atribuir o custo da ociosidade ao time/projeto e gerar showback semanal. Em três engagements isso revelou 35–60% da fatura de inferência em GPU ociosa.
Guia prático de migração para AWS Graviton em 2026: como recompilar containers, trocar EC2 para m7g/m8g, migrar RDS e Lambda para arm64 e combinar com Compute Savings Plans para economizar até 40% na relação preço-desempenho.
Guia prático do modelo de maturidade FinOps 2026: como avaliar sua organização nas fases Crawl, Walk e Run, com KPIs por capacidade e roteiro de evolução.
Quatro táticas para cortar custos de egress em AWS, Azure e GCP: CDN, VPC Endpoints, arquitetura same-AZ e object storage zero-egress como Cloudflare R2. Com tabela de preços 2026 e checklist de 30 dias.
