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

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.

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.

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.

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.

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.