# EC2 G7 e NVIDIA Blackwell: Arquitetura de Inferência GPU para Produção

As instâncias EC2 G7, aceleradas pelas GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, representam um salto geracional que vai muito além de números de benchmark. Nesta análise, examino os mecanismos reais de comunicação GPU-to-GPU, os padrões de falha em clusters multi-nó e as decisões de arquitetura que separam um deployment de inferência funcional de um sistema financeiro-grade tolerante a falhas.

- URL: https://fernando.moretes.com/blog/ec2-g7-e-nvidia-blackwell-arquitetura-de-inferencia-gpu-para-producao-announcing-a

- Markdown: https://fernando.moretes.com/blog/ec2-g7-e-nvidia-blackwell-arquitetura-de-inferencia-gpu-para-producao-announcing-a/article.md?lang=pt

- Published: 2026-06-18T21:22:10.000Z

- Category: AWS & Cloud

- Tags: ec2-g7, nvidia-blackwell, gpu-inference, efa, gpudirect-rdma, eks, ai-infrastructure, financial-grade

- Reading time: 9 min

- Source: [Announcing Amazon EC2 G7 instances accelerated by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs](https://aws.amazon.com/blogs/aws/announcing-amazon-ec2-g7-instances-accelerated-by-nvidia-rtx-pro-4500-blackwell-server-edition-gpus/)

---

A chegada das instâncias EC2 G7 com GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition não é apenas uma atualização de hardware — é uma mudança na equação de custo-eficiência para inferência de modelos grandes em produção. Com 700 Gbps de throughput EFA (7x em relação à G6), 32 GB de memória GPU por dispositivo, GPUDirect RDMA nativo e suporte a até 8 GPUs por instância, o G7 reposiciona o que é possível em um único nó antes de você precisar escalar horizontalmente. Mas hardware generoso não resolve problemas de arquitetura — e é exatamente aí que a maioria dos deployments falha silenciosamente.

## O que realmente mudou no Blackwell para cargas de inferência

A geração Blackwell não é uma iteração incremental sobre Ada Lovelace. Para inferência, as mudanças estruturalmente relevantes são três: os Tensor Cores de 5ª geração com suporte nativo a FP8, a largura de banda de memória de 2,45x em relação ao G6, e os motores NVENC/NVDEC de 9ª e 6ª geração respectivamente.

O FP8 é o ponto mais subestimado. Em modelos de linguagem grandes com quantização FP8, o throughput de tokens por segundo em um único G7 pode superar configurações multi-GPU de geração anterior — não porque o clock seja maior, mas porque a densidade computacional por watt aumentou de forma não-linear. Na prática, isso significa que um `g7.8xlarge` (1 GPU, 32 GB) pode servir modelos de 13B parâmetros em FP8 com latência P99 abaixo de 80ms para sequências de até 512 tokens, o que antes exigia pelo menos dois dispositivos A10G.

A largura de banda de memória de 2,45x é igualmente crítica para inferência autoregressive, onde o gargalo dominante não é FLOPS mas sim a velocidade com que os pesos são carregados do HBM para os núcleos de computação a cada passo de decodificação. Modelos com alta razão de parâmetros por camada — como arquiteturas MoE esparsas — se beneficiam desproporcionalmente dessa melhoria.

Para workloads de vídeo, os motores de 9ª geração NVENC com suporte a 4:2:2 eliminam o gargalo histórico em pipelines de transcodificação profissional, onde a conversão de espaço de cor era feita em CPU. Isso tem implicações diretas para plataformas de mídia financeira que processam feeds de dados em vídeo em tempo real.

## G7 vs G6: Números que importam para arquitetura

- **7x** — Throughput de rede EFA. 700 Gbps vs 100 Gbps — muda o design de sharding de modelo
- **2.45x** — Largura de banda de memória GPU. Gargalo dominante em inferência autoregressive eliminado
- **4.6x** — Performance de inferência AI. vs G6 — viabiliza modelos 70B+ em configuração single-node

## Pipeline de Inferência Multi-GPU com EC2 G7, EFA e EKS

Fluxo completo desde a requisição de inferência até a resposta, mostrando os caminhos de dados críticos: GPUDirect RDMA para comunicação inter-GPU, EFA para comunicação inter-nó, e o plano de controle EKS para orquestração. As arestas tracejadas representam fluxos assíncronos de telemetria e controle.

### 🌐 Client Layer

- API Gateway REST / WebSocket (edge)
- NLB TLS termination (network)

### 🟧 AWS — EKS Inference Plane

- EKS Control Plane k8s scheduler (compute)
- Triton Inference Server Pod — g7.48xlarge (ai)
- NVIDIA Device Plugin k8s resource: nvidia.com/gpu (compute)

### ⚡ G7 Node — GPU Fabric

- GPU 0 RTX PRO 4500 32GB (ai)
- GPU 1-7 RTX PRO 4500 32GB (ai)
- NVMe SSD 7.6 TB local (storage)
- EFA Adapter 700 Gbps (network)

### 🗄️ AWS — Model & Data Storage

- S3 Model weights store (storage)
- FSx for Lustre GPUDirect RDMA source (storage)

### 📊 Observability

- CloudWatch GPU metrics + DCGM (external)

### Fluxos

- apigw -> nlb: HTTPS
- nlb -> triton: gRPC / HTTP2
- eks-cp -> gpu-plugin: alocação de recurso
- gpu-plugin -> triton: bind GPU device
- triton -> gpu0: CUDA kernel dispatch
- gpu0 -> gpu1: GPUDirect P2P / NVLink
- gpu0 -> nvme: KV cache offload
- efa -> fsx: GPUDirect RDMA
- fsx -> gpu0: zero-copy DMA
- s3-models -> nvme: warm-up load
- triton -> cw: DCGM exporter
- eks-cp -> cw: k8s events

## GPUDirect RDMA com EFA: o mecanismo que muda o design de sharding

O suporte a GPUDirect RDMA com EFA — e especificamente com FSx for Lustre — é o recurso arquiteturalmente mais consequente do G7, e também o mais mal compreendido em deployments que eu reviso.

Sem GPUDirect RDMA, o caminho de dados para carregar pesos de um sistema de arquivos distribuído é: FSx → NIC → memória do sistema (CPU DRAM) → PCIe → memória GPU. Cada salto adiciona latência e consome largura de banda do barramento PCIe, que é um recurso compartilhado. Com GPUDirect RDMA, o caminho é: FSx → EFA NIC → memória GPU diretamente, via DMA, sem envolver a CPU no caminho de dados. Para modelos de 70B parâmetros em FP16 (140 GB), isso reduz o tempo de carregamento inicial de dezenas de segundos para a casa de segundos — o que é a diferença entre cold start aceitável e inaceitável em um SLA de inferência.

A configuração crítica aqui é o placement group. Para que o GPUDirect RDMA com EFA funcione entre nós, as instâncias G7 precisam estar em um **cluster placement group** na mesma AZ. Isso cria uma dependência de disponibilidade que precisa ser explicitada no design: você não pode distribuir um cluster de inferência multi-nó entre AZs sem perder o GPUDirect RDMA. A decisão arquitetural é, portanto, latência vs. resiliência — e para inferência de baixa latência, latência ganha, mas você precisa de um plano de failover explícito para falha de AZ.

O driver NVIDIA R595 exigido para EKS não é retrocompatível com todos os AMIs existentes. Eu vi clusters falharem silenciosamente em inicialização porque o DaemonSet do device plugin subia antes do driver estar completamente carregado, resultando em pods com `0/1 nvidia.com/gpu` disponível sem nenhum erro visível no log do pod.

> **O gargalo real em inferência não é FLOPS — é memória e barramento:** Para inferência autoregressive (geração token a token), o modelo é memory-bandwidth-bound, não compute-bound. A cada passo de decodificação, todos os pesos relevantes precisam ser lidos da HBM. O G7 com 2,45x de largura de banda de memória significa que você pode servir o mesmo modelo com menor latência por token ou maior batch size ao mesmo nível de latência — ambos têm impacto direto no custo por token inferido. A métrica que você deve monitorar não é GPU utilization (%), mas sim `sm__throughput.avg.pct_of_peak_sustained_elapsed` e `dram__throughput` via DCGM, que revelam se você está compute-bound ou memory-bound.

## Arquitetura de inferência financeiro-grade: além do happy path

Em ambientes financeiros, inferência de modelos não é apenas uma questão de throughput — é uma questão de comportamento determinístico sob falha, auditabilidade e isolamento de blast radius. O G7 introduz capacidades que permitem um design mais robusto, mas também introduz novos vetores de falha que precisam ser endereçados explicitamente.

**Isolamento e multi-tenancy**: O G7 suporta Dedicated Instances nos tamanhos `g7.12xlarge`, `g7.24xlarge` e `g7.48xlarge`. Para workloads de inferência em dados regulados (PII, dados financeiros), Dedicated Instances eliminam o risco de side-channel attacks de co-residência. Combine isso com `aws:RequestedRegion` conditions em IAM policies para garantir que workloads regulados só executem nas regiões aprovadas (atualmente US East Ohio e US West Oregon para G7).

**KMS e criptografia de modelos**: Os pesos de modelos proprietários armazenados em S3 devem usar SSE-KMS com chaves gerenciadas pelo cliente (CMK). O carregamento via FSx for Lustre com GPUDirect RDMA não bypassa a criptografia em repouso — a decriptografia acontece no plano do S3/FSx antes do DMA. Mas você precisa garantir que o IAM role do node group EKS tenha `kms:Decrypt` com condição `kms:ViaService: s3.region.amazonaws.com` para evitar escalada de privilégio.

**Circuit breaker para inferência**: O padrão de circuit breaker é frequentemente ignorado em clusters GPU. Se um nó G7 entra em estado de GPU error (ECC uncorrectable), o Triton Inference Server pode continuar aceitando requisições enquanto retorna resultados corrompidos silenciosamente. O sinal correto a monitorar é `DCGM_FI_DEV_ECC_DBE_VOL_TOTAL` via DCGM exporter no CloudWatch — um único evento DBE (Double-Bit Error) deve acionar o drain do nó e sua substituição automática via Node Auto Repair no EKS.

## Anti-padrões que eu vejo repetidamente em deployments GPU

- **Usar GPU utilization (%) como métrica de scaling**: GPU util% é uma métrica de presença, não de saturação. Um modelo esperando I/O mostra 0% de utilização enquanto está completamente bloqueado. Use `dram__throughput` e `sm__throughput` via DCGM para decisões de scaling reais.
- **Não configurar placement groups para clusters multi-nó**: Sem cluster placement group, o EFA não garante a topologia de rede de baixa latência necessária para tensor parallelism. A latência de all-reduce pode aumentar 10x, tornando o sharding de modelo inviável economicamente.
- **Carregar modelos de S3 diretamente no cold start do pod**: Modelos de 70B+ em FP16 têm 140 GB. Carregar de S3 na inicialização do pod cria cold starts de 5-15 minutos. O padrão correto é pré-aquecer o NVMe local (7.6 TB disponível) via init container com S5cmd paralelo, e usar FSx for Lustre como cache persistente entre reinicializações.
- **Ignorar a dependência de AZ do GPUDirect RDMA**: Distribuir um cluster de inferência multi-nó entre AZs para alta disponibilidade quebra o GPUDirect RDMA com EFA. O design correto é ter clusters independentes por AZ com roteamento de failover no load balancer, não um único cluster multi-AZ.
- **Não implementar idempotência em requisições de inferência com retry**: Em clusters GPU sob pressão, timeouts são comuns. Sem idempotency keys no API Gateway e lógica de deduplicação no servidor de inferência, retries duplicam a carga exatamente quando o sistema está mais frágil.
- **Usar Spot Instances para inferência stateful sem checkpoint de KV cache**: Spot G7 é economicamente atrativo (até 70% de desconto), mas interrupções destroem o KV cache em memória. Para inferência conversacional com histórico longo, ou você usa On-Demand/Savings Plans, ou implementa offload de KV cache para NVMe local com serialização rápida.

## Dimensionamento e estratégia de compra: a matemática que importa

A escolha entre tamanhos de instância G7 não é linear e depende fundamentalmente do perfil do modelo e do padrão de tráfego. Deixe-me ser concreto.

Para modelos de até 13B parâmetros em FP8 (memória efetiva ~13 GB), o `g7.2xlarge` (1 GPU, 32 GB) é o ponto de menor custo por token. Para modelos de 30-34B em FP8 (~34 GB), você precisa de pelo menos 2 GPUs — o `g7.12xlarge` é o menor tamanho com 2 GPUs (64 GB total). Para 70B em FP16 (140 GB), você precisa do `g7.48xlarge` (8 GPUs, 256 GB) ou de um cluster multi-nó com tensor parallelism — e aqui o GPUDirect RDMA com EFA de 700 Gbps se torna o diferencial que torna o multi-nó viável sem degradação severa de latência.

Na estratégia de compra, o modelo que recomendo para produção financeira é: **70% Savings Plans de 1 ano (Compute Savings Plans cobrem G7) + 20% On-Demand para burst + 10% Spot para batch inference assíncrono**. Savings Plans de 3 anos têm desconto maior, mas a velocidade de evolução do hardware GPU (G7 já é 4.6x melhor que G6 em inferência) torna o commitment de 3 anos arriscado — você pode estar pagando por hardware obsoleto no segundo ano.

O NVMe local de 7.6 TB no `g7.48xlarge` é um recurso frequentemente subutilizado. Em vez de usar apenas como cache de modelo, considere-o como camada de offload de KV cache para inferência com contextos longos (128K+ tokens), onde o KV cache pode facilmente exceder 10-20 GB por sessão. O acesso NVMe local tem latência de ~100μs vs ~500μs para EBS gp3, o que é relevante para operações de swap de KV cache em tempo real.

## Seleção de tamanho G7 por perfil de modelo
| Critério | Tamanho | GPUs / VRAM | Modelo alvo (FP8) | Caso de uso principal | Estratégia de compra |
| --- | --- | --- | --- | --- | --- |
| g7.2xlarge | 1 / 32 GB | ≤13B | Inferência de baixo custo, VDI | Spot + On-Demand | — |
| g7.12xlarge | 2 / 64 GB | 30-34B | Inferência balanceada, analytics | Savings Plans 1 ano | — |
| g7.48xlarge | 8 / 256 GB | 70B+ / MoE | Inferência financeiro-grade, modelos grandes | 70% SP + 20% OD + 10% Spot | — |

## Observabilidade para clusters GPU: além do CloudWatch básico

A observabilidade de clusters GPU é uma disciplina própria, e o G7 não muda isso — mas amplifica as consequências de fazê-la mal. Com 8 GPUs por nó e até dezenas de nós em um cluster, a superfície de falha é significativa e os sinais de degradação são sutis.

A stack que eu recomendo para produção financeira combina três camadas: **DCGM Exporter** para métricas de hardware GPU (temperatura, clock throttling, ECC errors, SM utilization, memory bandwidth), **OpenTelemetry Collector** para correlacionar traces de requisição com métricas de GPU (você precisa saber qual requisição estava rodando quando o GPU throttlou), e **CloudWatch Container Insights** com métricas customizadas para o plano do Kubernetes.

As métricas críticas que você deve ter em dashboard e alarmes: `DCGM_FI_DEV_GPU_TEMP` com threshold em 83°C (acima disso, o Blackwell começa a throttle de clock), `DCGM_FI_DEV_POWER_USAGE` vs TDP para detectar nós com problemas de cooling, `DCGM_FI_DEV_ECC_DBE_VOL_TOTAL` com alarme em qualquer valor > 0 (DBE é sinal de hardware degradado), e `DCGM_FI_DEV_SM_CLOCK` para detectar throttling.

Para SLOs de inferência, a métrica que importa para o usuário final é **TTFT (Time to First Token)** e **TBT (Time Between Tokens)**, não latência total. Em um sistema financeiro que usa LLMs para análise de documentos em tempo real, o SLO típico é TTFT P99 < 500ms e TBT P99 < 50ms. Esses SLOs precisam ser instrumentados no servidor de inferência (Triton tem suporte nativo via métricas Prometheus) e correlacionados com as métricas DCGM para root cause analysis quando violados.

Um sinal de observabilidade frequentemente ignorado: o **EFA flow control**. Quando o fabric EFA está saturado, o throughput de all-reduce em tensor parallelism degrada silenciosamente. O sinal é `ethtool -S` no adaptador EFA mostrando `rdma_read_resp_err` crescendo — isso precisa ser exportado via CloudWatch Agent com configuração customizada.

## EC2 G7 através das lentes do AWS Well-Architected

- **security**: Use Dedicated Instances para workloads com dados regulados. Aplique SSE-KMS com CMK para pesos de modelos em S3 e FSx. Configure IAM com condição `kms:ViaService` para prevenir escalada de privilégio. Habilite VPC Flow Logs no placement group para auditoria de tráfego inter-nó. Para EKS, use IRSA (IAM Roles for Service Accounts) em vez de instance profiles para isolamento de permissão por pod.
- **reliability**: Implemente clusters independentes por AZ com failover no load balancer — não distribua um único cluster multi-nó entre AZs. Configure Node Auto Repair no EKS com alarme em `DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0` para substituição automática de nós com GPU degradada. Use health checks de inferência (não apenas liveness/readiness do pod) que validem saída do modelo com prompt canário.
- **performance**: Configure cluster placement groups para todos os clusters multi-nó. Use GPUDirect RDMA com FSx for Lustre para carregamento zero-copy de modelos. Pré-aqueça NVMe local com pesos de modelo via init container para eliminar cold start. Escolha o tamanho de instância baseado no perfil de memória do modelo (FP8 vs FP16) e não em vCPU. Monitore TTFT e TBT como SLOs primários, não latência total.
- **cost**: Use 70% Savings Plans (Compute) + 20% On-Demand + 10% Spot para batch assíncrono. Evite Savings Plans de 3 anos dado o ciclo de evolução de hardware GPU. Monitore custo por token inferido (não custo por hora de instância) como métrica financeira primária. Utilize NVMe local para KV cache offload antes de adicionar nós — é capacidade gratuita já paga.

> **Minha nota de curadoria:** O que me impressiona no G7 não é o número de 4.6x de performance — é a combinação de 700 Gbps EFA com GPUDirect RDMA que finalmente torna o tensor parallelism multi-nó economicamente viável sem um fabric proprietário. Na prática, eu começaria qualquer novo deployment de inferência com modelos 70B+ no `g7.48xlarge` single-node antes de considerar multi-nó: 256 GB de VRAM cobre a maioria dos modelos em FP8, e você elimina toda a complexidade de comunicação inter-nó. A lição que aprendi da forma mais difícil: o maior risco em clusters GPU de produção não é performance insuficiente — é degradação silenciosa por ECC errors não monitorados, que corrompe saídas de modelo sem nenhum alarme visível. Configure `DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0` como alarme crítico no dia um, antes de qualquer outra coisa.

## Veredicto: G7 é a nova baseline para inferência de produção em AWS

O EC2 G7 com NVIDIA RTX PRO 4500 Blackwell representa uma mudança de geração genuína, não incremental. O salto de 4.6x em inferência AI combinado com 700 Gbps EFA e GPUDirect RDMA reposiciona o que é possível em um único nó e em clusters multi-nó. Para equipes construindo sistemas de inferência em produção hoje, G7 deve ser a instância de referência — G6 só faz sentido onde G7 ainda não está disponível regionalmente ou onde o custo de Spot G6 justifica a diferença de performance para workloads tolerantes a latência.

A ressalva importante: o hardware generoso não resolve problemas de arquitetura. Os anti-padrões que eu descrevo — placement groups incorretos, ausência de monitoramento de ECC, cold start de modelos de S3, idempotência ignorada — são todos independentes de geração de hardware e vão continuar causando falhas em produção se não forem endereçados explicitamente. O G7 amplifica tanto o teto de performance quanto o custo de erros arquiteturais.

Para ambientes financeiros especificamente: priorize Dedicated Instances para isolamento, configure SSE-KMS com CMK para modelos proprietários, implemente DCGM Exporter desde o dia um, e trate a dependência de AZ do GPUDirect RDMA como uma decisão arquitetural explícita com runbook de failover documentado. O hardware está pronto para produção financeiro-grade — a questão é se sua arquitetura está.

**Rating:** 9/10 — Hardware excepcional; exige arqui

## Referências

- [EC2 G7 Instances — AWS News Blog (Daniel Abib, 2026)](https://aws.amazon.com/blogs/aws/announcing-amazon-ec2-g7-instances-accelerated-by-nvidia-rtx-pro-4500-blackwell-server-edition-gpus/)
- [EC2 G7 Instance Types — AWS Documentation](https://aws.amazon.com/ec2/instance-types/g7/)
- [GPUDirect RDMA with EFA — AWS Documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start-nccl-base.html)
- [NVIDIA DCGM Exporter for Kubernetes](https://github.com/NVIDIA/dcgm-exporter)
- [EKS AMIs with NVIDIA Driver R595 — AWS Documentation](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html)
- [FSx for Lustre with GPUDirect RDMA — AWS Documentation](https://docs.aws.amazon.com/fsx/latest/LustreGuide/gpudirect-rdma.html)
- [AWS Deep Learning AMIs — Getting Started](https://docs.aws.amazon.com/dlami/latest/devguide/what-is-dlami.html)
- [Triton Inference Server — NVIDIA Documentation](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/index.html)