AWS EC2 GPU Pricing 2026: Guia Completo para AI Workloads

Infraestrutura GPU mal dimensionada custou a uma startup brasileira R$ 2,4 milhões em 6 meses. O problema não foi tecnologia — foi a ausência de uma estratégia de precificação clara.

Quick Answer

A AWS EC2 GPU pricing mais competitiva para AI workloads em 2026 é a família P5 (8x NVIDIA H100) a partir de USD 98,32/hora On-Demand, ou até 60% menos com Savings Plans de 1 ano. Para inferência leve, instâncias G5 (NVIDIA A10G) oferecem custo-benefício superior. Escolha P5 para training de modelos grandes, G5 para inferência em produção, e considere Trn1 (AWS Trainium) quando o orçamento é crítico e a precisão não é primordial.

Section 1 — O Problema Central: Por Que a Precificação GPU Define Sucesso ou Fracasso

Escolher a instância GPU errada não é apenas ineficiente — é financeiramente destrutivo. O relatório State of the Cloud 2026 da Flexera revelou que 73% das empresas superaram seu orçamento de cloud em mais de 30% no último ano fiscal, com workloads de IA como principal vilão.

O Custo Escondido da Ignorância

Uma equipe de ML que escolheu P3 (V100) para treinamento de um modelo GPT-like em vez de P5 (H100) gastou 4x mais por epoch. O modelo levou 3 semanas para treinar em vez de 5 dias. O custo total: USD 180.000. Com H100, o mesmo trabalho custaria USD 45.000.

Segundo a Gartner 2026, empresas que implementam governança de custos cloud em workloads de IA economizam em média 42% nos primeiros 12 meses. A diferença entre uma estratégia madura e uma abordagem reativa é frequentemente um fator de 3-5x no custo total de propriedade.

Por Que AWS EC2 GPU é Complexa em 2026

A AWS oferece agora 7 famílias GPU distintas, cada uma otimizada para cenários específicos:

• P5: NVIDIA H100 SXM para training de modelosFoundation
• P4d: NVIDIA A100 40GB para training médio
• P3: NVIDIA V100 para legacy workloads
• G5: NVIDIA A10G para inferência
• G4dn: NVIDIA T4 para inference econômica
• Trn1: AWS Trainium para custom silicon
• DL2q: Qualcomm AI 100 para inference especifica

A escolha correta depende de 3 variáveis: tamanho do modelo, throughput requerido, e janela de treinamento. Misturar famílias ou usar instâncias over-spec'd para workloads simples é o erro mais caro que arquitetos cometem.

Section 2 — Análise Técnica Profunda: Famílias GPU e Precificação 2026

Comparativo de Instâncias GPU EC2 (Oregon/us-west-2 — On-Demand)

Família	GPU	VRAM	vCPUs	RAM	USD/hora	Melhor Para
p5en.48xlarge	8x H100 80GB	640GB HBM3	192	2048GB	235,08	Training LLM > 70B
p5.48xlarge	8x H100 80GB	640GB HBM3	192	2048GB	98,32	Training LLM (sem EFA)
p4d.24xlarge	8x A100 40GB	320GB HBM2e	96	1152GB	38,69	Training médio
g5.48xlarge	8x A10G 24GB	192GB GDDR6	96	384GB	35,69	Inferência produção
g4dn.16xlarge	1x T4 16GB	16GB GDDR6	64	256GB	4,82	Inferência leve
trn1.32xlarge	16x Trainium	512GB	128	512GB	59,86	Training custom silicon
dl2q.48xlarge	8x AI 100	256GB	192	2048GB	62,43	Inference edge

Preços On-Demand em USD para us-west-2 em janeiro 2026. Verifique aws.amazon.com/ec2/instance-types/ para valores atualizados.

Quando Escolher Cada Família

P5 (H100)**

A família P5 representa a opção mais poderosa da AWS para training de modelosFoundation. Cada instância carrega 8 GPUs H100 com NVLink e NVSwitch para comunicação inter-GPU de 900 GB/s. Isso é crítico: modelos como Llama 3 70B ou Mistral Large exigem comunicação intensa entre GPUs durante o gradient synchronization.

Otimização de memória HBM3: cada H100 tem 80GB operando a 3.35 TB/s de bandwidth. Para comparação, A100 40GB oferece 2 TB/s. A diferença significa que H100 pode rodar batches 2-3x maiores, reduzindo tempo total de training proporcionalmente.

P4d (A100 40GB)

Mantenha P4d para workloads que não justificam H100 mas precisam de mais poder que G5. Casos típicos: fine-tuning de modelos 7-13B, treinamento de modelos de visão, ou quando sua equipe ainda não migrou para arquiteturas que tiram proveito de H100.

Cuidado: P4d é 2.5x mais barata por hora, mas se você precisa de 3x mais tempo de training versus P5, a economia evapora.

G5 (A10G 24GB)

A G5 é a instância de inference mais versátil da AWS em 2026. Preço por inferência é 60-70% menor que P4d com performance adequada para modelos até 30B com quantização INT8.

Para uma API servindo Llama 3 8B em produção com 100 req/s, uma única g5.48xlarge (8x A10G) custará aproximadamente USD 9.000/mês versus USD 25.000/mês em p4d.24xlarge.

Trn1 (AWS Trainium)

Trainium oferece 40-60% de economia versus GPU NVIDIA para training, mas exige adaptação de código via Neuron SDK. Abarca o ecossistema PyTorch e JAX, com suporte nativo para modelos Transformers.

Limitação real: comunidade menor, documentação menos robusta, e alguns operadores de deep learning ainda não otimizados. Para equipes com capacidade de engineering, Trn1 pode ser a diferença entre ser competitivo ou não em projetos de pesquisa.

AWS EC2 GPU Pricing Models: On-Demand vs Savings Plans vs Spot

Cada modelo de precificação tem implicações estratégicas diferentes:

On-Demand

Pagamento por hora, sem compromisso. Flexibilidade máxima, preço máximo. Use para: desenvolvimento inicial, benchmarks, workloads imprevisíveis, ou como baseline para comparação.

Savings Plans (1 ou 3 anos)

Compromisso de usohorário consistente em troca de descontode 40-60% sobre On-Demand. A AWS oferece dois tipos:

• Compute Savings Plans: Mais flexíveis — aplicam-se a qualquer família EC2
• Instance Savings Plans: Descontos maiores (até 60%) mas vinculados a famílias específicas

Recomendação: para equipes sérias sobre AI, trave 70% da capacidade esperada em Savings Plans de 1 ano para instâncias P5/G5 e reavalie trimestralmente.

Spot Instances

Descontosde 60-90% mas sem garantia de disponibilidade. A AWS pode reclaimar a instância com 2 minutos de aviso. Para training tolerante a interrupções, Spot é excelente. Para inference em produção, é irresponsável.

# Verificar preço Spot atual para p5.48xlarge em us-east-1
aws ec2 describe-spot-price-history \
  --instance-types p5.48xlarge \
  --product-descriptions "Linux/UNIX" \
  --start-time 2026-01-15T00:00:00Z \
  --region us-east-1 \
  --query 'SpotPriceHistory[*].{InstanceType:InstanceType,Price:SpotPrice,AZ:AvailabilityZone}'

Resultado típico: Spot pricing para P5 em us-east-1 varia entre USD 25-50/hora versus USD 98,32 On-Demand.

Quantização e Otimização de Memória

A VRAM disponível é frequentemente o gargalo, não o compute. Técnicas modernas permitem quadruplicar a capacidade effective:

Técnica	VRAM Efetiva (A100 40GB)	Degradação de Acurácia	Use Quando
FP16 (baseline)	40GB	Nenhuma	Models < 7B
INT8 (GPTQ)	80GB	~1-2%	Models 7-70B
INT4 (AWQ)	160GB	~3-5%	Models > 70B em hardware limitado
QLoRA	40GB	~1-3%	Fine-tuning com budget limitado
Gradient Checkpointing	50% original	~10% slower	Models que não cabem em batch size 1

Em prática: se você está rodando um modelo 70B em P4d (8x A100 = 320GB), usar GPTQ INT8 permite batch sizes 3-4x maiores, potencialmente reduzindo seu custo por token em 70%.

Section 3 — Implementação: Estratégia Prática de Deploy

Step-by-Step: Selecionando a Instância Correta

Step 1: Calcule o footprint de memória do seu modelo

# Estimativa rough: 2 bytes por parâmetro em FP16 + overhead de 20%
model_params_b = 70_000_000_000  # Ex: Llama 3 70B
memory_fp16_gb = (model_params_b * 2) / (1024**3) * 1.2
print(f"Memória necessária (FP16): {memory_fp16_gb:.1f} GB")
# Output: ~130 GB

# Com quantização INT8: ~70 GB
# Com quantização INT4: ~40 GB

Step 2: Determine o número de GPUs necessárias

Para treinamento com gradient accumulation, você precisa de VRAM para:

• Pesos do modelo
• Gradientes (igual aos pesos em FP16)
• Otimizador states (Adam: 2x pesos)
• Ativações (variável, depende do sequence length e batch size)

Regra prática para P5 (H100 80GB): multi-GPU training eficiente para modelos até 400B parâmetros com mixed precision.

Step 3: Calcule o custo mensal projetado

# Script para estimar custo mensal com diferentes pricing models
# Assumptions: 24/7 operation, 1 instance

INSTANCE_TYPE="p5.48xlarge"
ON_DEMAND_HOURLY=98.32
SAVINGS_PLAN_DISCOUNT=0.60  # 60% discount
SP_HOURLY=$(echo "$ON_DEMAND_HOURLY * (1 - $SAVINGS_PLAN_DISCOUNT)" | bc)
HOURS_PER_MONTH=730

ON_DEMAND_MONTHLY=$(echo "$ON_DEMAND_HOURLY * $HOURS_PER_MONTH" | bc)
SP_MONTHLY=$(echo "$SP_HOURLY * $HOURS_PER_MONTH" | bc)

echo "On-Demand mensal: USD $ON_DEMAND_MONTHLY"
echo "Savings Plans mensal: USD $SP_MONTHLY"
echo "Economia anual: USD $(echo "($ON_DEMAND_MONTHLY - $SP_MONTHLY) * 12" | bc)"

Step 4: Valide com benchmarks reais

Não confie apenas em specs. Rode seu workload específico por 1 hora antes de se comprometer:

# Benchmark de throughput de training usando PyTorch profiler
python -m torch.distributed.run \
  --nproc_per_node=8 \
  --master_port=29500 \
  train.py \
  --model_config configs/llama3_70b.yaml \
  --max_iters 100 \
  --profiler_enabled

Configuração Recomendada por Workload

Fine-tuning Llama 3 8B (QLoRA)

Componente	Recomendação
Instância	g5.2xlarge (1x A10G 24GB)
Quantização	NF4 (4-bit)
Batch size	16 (gradient accumulation 4)
Custo/hora	USD 4,46
Tempo estimado (1 epoch)	~45 minutos

Training GPT-4 class (70B+)

Componente	Recomendação
Instância	p5.48xlarge (8x H100)
Precisão	BF16 + gradient checkpointing
Batch size	4 (data parallel)
Custo/hora	USD 98,32 (On-Demand)
Alternativa	trn1.32xlarge (Trainium) para 40% economia

Inference em Produção (100 req/s)

Componente	Recomendação
Instância	g5.48xlarge (8x A10G)
Quantização	INT8 (vLLM ou TensorRT-LLM)
Modelo	Llama 3 70B Q8
Custo/mês	~USD 9.000
Latência P99	< 200ms

Integração com Kubernetes (EKS)

Para teams que rodam Kubernetes, o AWS Neuron Plugin e NVIDIA Device Plugin são essenciais:

# Pod spec para training em P5 com EFA networking
apiVersion: v1
kind: Pod
metadata:
  name: llm-training-pod
spec:
  containers:
  - name: training
    image: pytorch/pytorch:2.2.0-cuda12.1
    resources:
      limits:
        nvidia.com/gpu: "8"
        aws.amazon.com/efa: "1"
        hugepages-2Mi: "16Gi"
      requests:
        memory: "1800Gi"
        cpu: "96"
    env:
    - name: NCCL_IB_DISABLE
      value: "0"
    - name: NCCL_SHM_DISABLE
      value: "1"

Section 4 — Erros Comuns e Armadilhas

Erro 1: Escolher Instância Baseada Apenas em Preço/hora

Por que acontece: Tomadores de decisão focam em custos diretos sem calcular throughput.

O problema: Uma g5.48xlarge (USD 35,69/hora) parece 2.7x mais barata que p4d.24xlarge (USD 38,69/hora). Mas se seu training leva 10x mais tempo em G5 por lack de NVLink entre GPUs, o custo total explode.

Como evitar: Calcule sempre "custo por tarefa completada", não "custo por hora".

def calculate_total_cost(instance_type, hourly_price, hours_needed, iterations):
    # hours_needed é menor para instâncias mais rápidas
    return hourly_price * hours_needed

# Exemplo real
p4d_cost = calculate_total_cost("p4d", 38.69, 100, 1000)  # USD 3.869
p5_cost = calculate_total_cost("p5", 98.32, 15, 1000)     # USD 1.475
# P5 é 2.6x mais barata para mesma tarefa!

Erro 2: Ignorar Custos de Egress e Transferência de Dados

Por que acontece: Engenheiros focam em compute pricing e esquecem networking.

O problema: Treinar modelos grandes requer mover datasets massivos. Uma equipe que treinou um modelo de visão em 500TB de imagens pagou USD 40.000 em egress fees porque não configurou S3 endpoint interno.

Como evitar: Use instâncias com EFA (Elastic Fabric Adapter) para comunicação inter-nó, e garanta que datasets estão em S3 na mesma região. Para transferência entre regiões, considere Snowball Edge.

Erro 3: Não Usar Savings Plans para Workloads Previsíveis

Por que acontece: Equipes querem "flexibilidade" e evitam compromisso.

O problema: Para qualquer workload de AI production, 70-80% do uso é previsível. Deixar esse tráfego em On-Demand é dinheiro queimado.

Como evitar: Comprometa 60-70% da capacidade esperada em Savings Plans de 1 ano. Use os 30-40% restantes para Spots ou On-Demand para picos.

Erro 4: Escolher Família GPU Errada para Inference vs Training

Por que acontece: Confusão sobre otimizações de hardware para diferentes workloads.

O problema: P5 e P4d são over-engineered e over-priced para inference. Uma g5.48xlarge entrega throughput de inference superior para 36% do custo de p4d.24xlarge.

Como evitar: Training = P5/P4d. Inference = G5/G4dn. Nunca misture.

Erro 5: Negligenciar Spot Interruption Handling

Por que acontece: Engineers implementam Spot para economia mas não planejam interrupções.

O problema: Treinar um modelo por 3 dias em Spot e perder tudo na hora 72 ékatastrophisch. Todo o progresso perdido.

Como evitar: Implemente checkpointing a cada 15-30 minutos usando S3 ou FSx:

# Checkpointing com PyTorch Lightning
from pytorch_lightning.callbacks import ModelCheckpoint

checkpoint_callback = ModelCheckpoint(
    dirpath="s3://your-bucket/checkpoints/",
    filename="{epoch:02d}-{step:06d}",
    save_top_k=3,
    every_n_train_steps=1000,
    save_weights_only=False,
    verbose=True
)

Section 5 — Recomendações e Próximos Passos

Recomendação 1: Crie um GPU Selection Framework

Antes de iniciar qualquer projeto de AI, responda:

1. Qual o tamanho do modelo em parâmetros?
2. Qual o dataset size (GB/TB)?
3. É training ou inference?
4. Qual a latência/throughput requerida?
5. Qual o budget mensal tolerável?

Com essas respostas, a seleção de instância torna-se mecânica, não emocional.

Recomendação 2: Implemente Cost Allocation Imediatamente

Se sua empresa tem múltiplas equipes usando GPUs, tag everything. Sem visibility, não há accountability.

# Tags obrigatórias para todas as instâncias GPU
aws ec2 create-tags \
  --resources i-1234567890abcdef0 \
  --tags \
    Key=Project,Value=llama3-finetuning \
    Key=Environment,Value=production \
    Key=Team,Value=ml-platform \
    Key=CostCenter,Value=engineering \
    Key=Owner,Value=joao.silva@empresa.com

Recomendação 3: Adote uma Estratégia de Preços Híbrida

Para a maioria das organizações:

• 60% da capacidade: Savings Plans de 1 ano (famílias P5/G5)
• 30% da capacidade: Spot Instances com checkpointing robusto
• 10% da capacidade: On-Demand para benchmarking e spikes

Recomendação 4: Monitore Constantemente com Cost Explorer

Configure dashboards em AWS Cost Explorer para:

• Custo por família de instância GPU
• Custo por projeto/equipe
• Tendência de uso mensal vs budget
• Cobertura de Savings Plans

Revise semanalmente com o time de FinOps. Gastos GPU sem monitoramento ativo crescem 20-30% por trimestre.

Recomendação 5: Considere Alternatives para Workloads Específicos

AWS EC2 não é sempre a resposta. Para certos cenários:

• SageMaker Canvas: para no-code ML, elimina overhead de infraestrutura
• AWS Bedrock: para inference de modelosFoundation, pay-per-token
• Colaboratory TPU: para prototipagem, gratuito até límites
• On-premise (H100 clusters): para workloads > USD 500k/mês constantes

A escolha certa depende de análise honesta de TCO, não de familiaridade tecnológica.

---

Precificação de instâncias GPU EC2 para AI workloads não precisa ser um pesadelo financeiro. Com a estratégia correta — seleção de família baseada em workload, pricing model adequado ao padrão de uso, e monitoramento contínuo — é possível reduzir custos em 40-60% sem sacrificar performance. O investimento inicial em arquitetura de custos paga-se em meses, não anos.