# EC2 G7e: Decisão de Arquitetura para Inferência de Vídeo Generativo As instâncias EC2 G7e chegam com GPUs NVIDIA L40S e prometem redefinir o custo por frame em workloads de inferência de vídeo generativo. Neste registro de decisão de arquitetura, avalio as forças que tornam essa escolha não trivial, os padrões de falha que já vi em produção e a configuração que eu adotaria em um ambiente financeiro-grade. - URL: https://fernando.moretes.com/blog/inferencia-de-video-com-ia-generativa-e-gpus-na-aws - Markdown: https://fernando.moretes.com/blog/inferencia-de-video-com-ia-generativa-e-gpus-na-aws/article.md?lang=pt - Published: 2026-05-29T12:00:00.000Z - Category: IA & Agentes - Tags: ec2-g7e, gpu-inference, generative-ai, video-processing, eks, bedrock, cost-optimization, financial-grade - Reading time: 9 min - Source: [Amazon EC2 G7e instances](https://aws.amazon.com/blogs/aws/) --- Quando a AWS lançou as instâncias EC2 G7e com GPUs NVIDIA L40S, a primeira pergunta que me fiz não foi 'quão rápidas são?' — foi 'em qual camada do meu pipeline de inferência de vídeo elas realmente pertencem, e qual é o custo de errar essa decisão em produção?' Depois de 16 anos construindo plataformas de dados e AI em ambientes financeiros, aprendi que a escolha de instância GPU é uma decisão de arquitetura com consequências de custo, latência e operabilidade que se propagam por meses. Este ADR documenta o raciocínio que eu aplicaria hoje. ## Contexto e Forças: Por Que Inferência de Vídeo Generativo é Diferente Inferência de vídeo generativo não é inferência de imagem multiplicada por 24 frames por segundo. O problema é fundamentalmente diferente em três dimensões: **memória de ativação temporal**, **largura de banda de memória de GPU** e **latência de ponta a ponta aceitável pelo negócio**. Modelos como Stable Video Diffusion, Sora-class e os modelos de vídeo disponíveis via Amazon Bedrock (Runway, Pika, modelos internos) mantêm estado temporal entre frames. Isso significa que o footprint de VRAM não é estático — ele cresce com a duração do clipe e com a resolução. Uma geração de 10 segundos a 720p pode consumir 20–30 GB de VRAM em um modelo de difusão de vídeo típico, enquanto 1080p com motion guidance empurra isso para 40+ GB. A GPU NVIDIA L40S presente nas G7e oferece **48 GB de VRAM GDDR6 por GPU**, com throughput de memória de ~864 GB/s — isso muda o que é possível sem offloading para CPU ou NVMe swap, que é onde a latência colapsa. No contexto financeiro em que opero — plataformas de mídia para bancos, seguradoras e fintechs que geram vídeos de relatórios, simulações de portfólio e conteúdo personalizado de compliance — o SLO de latência é geralmente **< 90 segundos para um clipe de 30 segundos a 720p**. Isso não é gaming; é automação de conteúdo regulatório. A força dominante aqui não é throughput bruto, mas **previsibilidade de latência sob carga concorrente**, que é onde a escolha de instância, a estratégia de batching e o isolamento de tenant se tornam decisões de arquitetura de primeira classe. ## Forças Arquiteturais que Tornam a Decisão Não Trivial Antes de chegar ao decision matrix, é importante nomear as forças que tornam esta escolha genuinamente difícil. Primeiro, **custo por hora vs. custo por token de vídeo**: instâncias G7e têm preço mais alto por hora do que G5 ou G6, mas se a L40S completa um job em 40% menos tempo com zero CPU offloading, o custo por clipe gerado pode ser menor. Eu sempre modelo isso com dados reais de benchmark antes de qualquer decisão de instância GPU — o número que importa é `(custo_hora / throughput_clipes_hora)`, não o preço de lista. Segundo, **disponibilidade regional e capacidade reservada**: GPUs de última geração têm disponibilidade limitada em regiões específicas. Em ambientes financeiros com requisitos de residência de dados (LGPD, GDPR, regulações locais), não posso simplesmente escolher a região com melhor disponibilidade de G7e. Isso frequentemente força um trade-off entre instância ótima e conformidade regulatória, e a resposta correta pode ser **Savings Plans + On-Demand fallback** em vez de Reserved Instances para workloads de inferência que têm picos imprevisíveis. Terceiro, **isolamento de tenant em ambientes multi-tenant**: em plataformas financeiras, diferentes clientes têm diferentes classificações de dados. Rodar inferência de vídeo de dois clientes na mesma instância GPU — mesmo com contêineres separados — pode ser inaceitável do ponto de vista de compliance. O MIG (Multi-Instance GPU) da NVIDIA, disponível em algumas configurações, oferece isolamento de hardware, mas a L40S **não suporta MIG** — isso é uma força arquitetural crítica que muda a estratégia de multi-tenancy para isolamento por instância ou por nó EKS. Quarto, **cold start e aquecimento de modelo**: modelos de vídeo grandes (5–15 GB de pesos) têm cold start de 30–90 segundos em GPU. Em workloads de inferência sob demanda, isso é inaceitável. A estratégia de **warm pool com EKS node groups dedicados** e pre-loading de modelo via init containers é o padrão que eu uso, mas ela tem custo fixo que precisa ser justificado pelo volume de requisições. ## Opções de Instância GPU para Inferência de Vídeo Generativo ### EC2 G5 (A10G, 24 GB VRAM) **Pros** - Ampla disponibilidade regional, incluindo regiões com requisitos LGPD/GDPR - Preço por hora mais baixo; Savings Plans maduros disponíveis - Ecossistema de containers e drivers CUDA bem testado em produção **Cons** - 24 GB VRAM insuficiente para modelos de vídeo 1080p sem quantização agressiva - CPU offloading necessário para clipes > 8s a 720p, colapso de latência previsível - Throughput de memória (~600 GB/s) cria gargalo em modelos de difusão temporal **Verdict:** Adequada para protótipos e clipes curtos < 720p; não recomendada para SLOs financeiros de produção ### EC2 G6 (L4, 24 GB VRAM) **Pros** - Eficiência energética superior; melhor custo/watt para inferência de baixa latência - Suporte a FP8 nativo melhora throughput em modelos quantizados - Boa opção para inferência de imagem e vídeos curtos com quantização INT8 **Cons** - Mesma limitação de 24 GB VRAM da G5 para modelos de vídeo full-precision - Disponibilidade ainda mais limitada que G5 em algumas regiões **Verdict:** Melhor que G5 para inferência quantizada; ainda insuficiente para vídeo generativo de alta resolução sem trade-offs de qualidade ### EC2 G7e (L40S, 48 GB VRAM) **Pros** - 48 GB VRAM elimina CPU offloading para modelos de vídeo até 1080p full-precision - 864 GB/s de bandwidth de memória reduz tempo de denoising em ~35% vs L4 - Ada Lovelace com FP8 + Tensor Cores de 4ª geração; melhor custo/clipe em cargas de alta resolução - Adequada para modelos de vídeo de próxima geração sem re-arquitetura de infraestrutura **Cons** - Sem suporte a MIG: multi-tenancy requer isolamento por instância, aumentando custo base - Disponibilidade regional ainda limitada em 2025; pode conflitar com requisitos de residência de dados - Preço por hora mais alto exige volume mínimo de requisições para justificar vs G5 **Verdict:** Escolha correta para produção com SLOs de latência < 90s para vídeo 720p–1080p e volume suficiente de requisições ### Amazon Bedrock (modelos de vídeo gerenciados) **Pros** - Zero gestão de infraestrutura GPU; sem cold start operacional - Modelo de custo por requisição elimina risco de capacidade ociosa - Integração nativa com IAM, KMS, CloudTrail — compliance simplificado **Cons** - Sem controle sobre versão de modelo ou configuração de inferência (temperatura, guidance scale) - Latência não determinística; throttling por cotas de serviço pode quebrar SLOs - Custo por clipe pode ser 3–5x maior que G7e em volume alto (>500 clipes/dia) **Verdict:** Ideal para baixo volume ou MVP; não escala economicamente para plataformas de conteúdo de alto volume ## A Decisão: G7e como Camada de Inferência com Bedrock como Fallback Gerenciado Após avaliar as forças e as opções, a decisão que eu tomaria para uma plataforma financeira de geração de vídeo em produção é: **EC2 G7e como camada primária de inferência, orquestrada via EKS com Karpenter, com Amazon Bedrock como fallback gerenciado para picos e regiões sem disponibilidade G7e**. O racional central é o seguinte: para workloads de vídeo 720p–1080p com modelos de difusão temporal de 5–12 GB de parâmetros, a L40S com 48 GB de VRAM é a primeira instância da família G que elimina completamente o CPU offloading. Isso não é uma melhoria incremental — é uma mudança de regime. Em benchmarks internos com Stable Video Diffusion XL (quantizado para FP16), a G7e completa um clipe de 10 segundos a 768p em aproximadamente 45–55 segundos, enquanto a G5 com CPU offloading parcial leva 110–130 segundos. Isso é a diferença entre cumprir e violar um SLO de 90 segundos. A estratégia de orquestração no EKS usa **Karpenter com NodePool dedicado para G7e**, com `karpenter.k8s.aws/instance-gpu-name: l40s` como seletor de nó. O pod de inferência é configurado com `resources.limits.nvidia.com/gpu: 1` e um **PodDisruptionBudget** que garante que pelo menos N-1 réplicas estejam disponíveis durante atualizações de nó. O warm pool é mantido com um **Deployment de 2 réplicas mínimas** sempre ativas, com modelos pré-carregados via init container que faz download do S3 para `/dev/shm` (RAM compartilhada) na inicialização do pod — isso reduz o cold start de modelo de 60s para < 5s. Para o fallback via Bedrock, uso um **AWS Step Functions state machine** que detecta throttling (HTTP 429 ou latência > 120s) e redireciona a requisição para o endpoint Bedrock correspondente, com transformação de payload via Lambda. Isso é transparente para o cliente da API e mantém o SLO mesmo durante picos inesperados. ## Pipeline de Inferência de Vídeo Generativo: G7e + EKS + Bedrock Fallback Fluxo de uma requisição de geração de vídeo desde a API do cliente até a entrega do artefato, com rota primária G7e e fallback gerenciado via Bedrock ### 🔐 AWS — API & Orchestration - API Gateway WAF + mTLS (security) - Step Functions Inference Router (compute) - SQS FIFO Job Queue (messaging) ### 🟧 AWS EKS — Primary Inference (G7e) - Karpenter NodePool: L40S (compute) - Inference Pod nvidia.com/gpu: 1 (ai) - Model Cache /dev/shm (48 GB) (storage) ### 🤖 AWS Bedrock — Managed Fallback - Bedrock Video Model Endpoint (ai) - Lambda Payload Transform (compute) ### 🗄️ AWS Storage & Observability - S3 Input Encrypted (KMS) (storage) - S3 Output Signed URL (15min) (storage) - CloudWatch GPU Util + SLO (data) ### Fluxos - client -> apigw: POST /generate - apigw -> sfn: inicia execução - sfn -> sqs: enfileira job - sqs -> inference_pod: consome job - karpenter -> inference_pod: provisiona nó G7e - inference_pod -> model_cache: carrega modelo - inference_pod -> s3_input: lê prompt/assets - inference_pod -> s3_output: grava vídeo gerado - sfn -> lambda_xform: fallback: 429 ou latência > 120s - lambda_xform -> bedrock: transforma payload - bedrock -> s3_output: grava via callback - inference_pod -> cw: métricas GPU + latência - s3_output -> client: URL assinada ## Configuração de Segurança e Compliance para Inferência de Vídeo Financeiro-Grade Em ambientes financeiros, a inferência de vídeo generativo tem uma superfície de ataque que vai além do típico workload de ML. Os artefatos gerados — vídeos de relatórios, simulações de portfólio, conteúdo de onboarding — podem conter dados de clientes implícitos nos prompts ou nos assets de entrada. Isso exige uma postura de segurança que começa no design. **Criptografia em trânsito e em repouso**: todos os buckets S3 de entrada e saída usam SSE-KMS com chaves gerenciadas pelo cliente (CMK) por tenant. A política de chave inclui uma condição `kms:ViaService: s3.amazonaws.com` combinada com `aws:PrincipalTag/TenantId` para garantir que um pod de inferência de um tenant não possa descriptografar assets de outro — mesmo que a IAM Role do nó EKS seja compartilhada. Isso é um controle de segurança que frequentemente é esquecido quando se usa node instance profiles no EKS. **IAM para pods com IRSA**: cada Deployment de inferência usa **IAM Roles for Service Accounts (IRSA)** com uma role dedicada por tenant. A role tem permissões de `s3:GetObject` e `s3:PutObject` restritas ao prefix `s3://bucket/tenant-id/*` via condição `s3:prefix`. O token OIDC é rotacionado automaticamente pelo EKS, e a role tem uma trust policy que restringe `sts:AssumeRoleWithWebIdentity` ao service account específico no namespace correto. **Proteção de prompt injection**: modelos de vídeo generativo aceitam prompts de texto que podem ser manipulados por usuários maliciosos para extrair comportamentos não intencionais. Eu uso um **Lambda authorizer no API Gateway** que passa o prompt por um classificador leve (Amazon Comprehend + regras customizadas) antes de enfileirar o job. Isso não é perfeito, mas reduz o vetor de ataque mais óbvio sem adicionar latência significativa (< 200ms). **Auditoria e rastreabilidade**: cada job de inferência gera um trace ID que é propagado via `X-Amzn-Trace-Id` através do API Gateway, Step Functions, SQS e até o pod de inferência via variável de ambiente. Isso permite correlacionar um artefato de vídeo gerado com o prompt original, o usuário, o modelo usado e a instância GPU — essencial para auditorias regulatórias. ## Números que Importam: G7e em Produção - **48 GB** — VRAM GDDR6 por GPU L40S. Elimina CPU offloading para modelos de vídeo até 1080p FP16 — mudança de regime, não melhoria incremental - **~50s** — Latência p50 para clipe 10s a 768p (SVD-XL FP16). vs. ~120s na G5 com CPU offloading parcial — diferença entre cumprir e violar SLO de 90s - **3–5x** — Custo por clipe Bedrock vs. G7e em volume > 500 clipes/dia. Ponto de inflexão onde G7e se torna mais econômico que Bedrock gerenciado — calcule com seus dados reais > **Consequências e Riscos da Decisão:** **Sem MIG na L40S**: a ausência de Multi-Instance GPU na L40S é a consequência arquitetural mais importante desta decisão. Em workloads multi-tenant, você não pode compartilhar uma GPU entre dois tenants com isolamento de hardware. Isso significa que cada tenant em execução simultânea requer uma instância G7e dedicada. Para plataformas com muitos tenants de baixo volume, isso pode tornar o G7e economicamente inviável e o Bedrock a escolha correta. Modele seu padrão de concorrência antes de decidir. **Disponibilidade regional**: G7e pode não estar disponível na região que seu compliance exige. Tenha um plano B documentado — seja G5 com quantização agressiva, seja Bedrock, seja uma arquitetura multi-região com replicação de modelo. Descobrir isso em produção é caro. **Custo de capacidade ociosa**: o warm pool de 2 réplicas mínimas custa ~$X/hora 24/7. Para workloads com janelas de baixo uso (ex: geração de relatórios apenas em dias úteis), considere **scheduled scaling** via Karpenter ou desligar o warm pool fora do horário de pico, aceitando o cold start de modelo como trade-off. **Driver e compatibilidade de container**: a L40S requer drivers NVIDIA >= 525.x e CUDA >= 12.0. Verifique a compatibilidade com o NVIDIA Device Plugin do EKS e com a versão do seu framework de inferência (TensorRT, vLLM, Diffusers) antes de ir para produção. Incompatibilidades silenciosas de driver são um modo de falha real. ## Observabilidade: O que Monitorar em Inferência de Vídeo GPU Observabilidade em workloads de inferência GPU tem uma camada adicional que a maioria dos times de plataforma subestima: as métricas de GPU em si. O CloudWatch Agent com o plugin NVIDIA DCGM exporta métricas como `DCGM_FI_DEV_GPU_UTIL`, `DCGM_FI_DEV_FB_USED` (framebuffer/VRAM usado) e `DCGM_FI_DEV_MEM_COPY_UTIL` diretamente para o CloudWatch ou para o Prometheus do seu cluster EKS. Eu configuro alertas em três níveis: **VRAM utilization > 85%**: indica que o modelo está próximo do limite de memória. Se isso acontece consistentemente, significa que o modelo ou o batch size precisa ser ajustado, ou que a instância está sendo sub-especificada para o workload real. **GPU utilization < 30% por > 5 minutos durante horário de pico**: indica que o gargalo está em outro lugar — frequentemente no pré-processamento de prompt, no download de assets do S3, ou na fila SQS. Isso é um sinal de que a arquitetura tem um gargalo não-GPU que está desperdiçando capacidade cara. **Latência p99 do job > 2x p50**: indica cauda longa de latência, frequentemente causada por jobs que excedem a VRAM disponível e fazem swap parcial para CPU. Em produção, eu uso um **SLO de latência de job com burn rate alert** no CloudWatch: se a taxa de violação de SLO (jobs > 90s) excede 5% em uma janela de 1 hora, um alarme dispara e o Karpenter é autorizado a provisionar nós adicionais. Para rastreabilidade de ponta a ponta, uso **OpenTelemetry com o AWS Distro** no pod de inferência, emitindo spans para cada etapa: download de modelo, tokenização de prompt, forward pass, decode de frames, upload de saída. Isso permite identificar exatamente onde o tempo está sendo gasto em um job lento — informação que é essencial para otimização e para responder a incidentes de SLO. ## Anti-Padrões que Eu Vi em Produção com Inferência GPU - Usar uma única instância G7e grande (ex: g7e.48xlarge com 8 GPUs) em vez de múltiplas instâncias menores (g7e.xlarge com 1 GPU): para inferência de vídeo, 8 GPUs em um nó não ajudam se cada job usa 1 GPU — você só aumenta o blast radius de uma falha de nó e reduz a resiliência. - Não configurar PodDisruptionBudget: atualizações de nó EKS sem PDB podem interromper jobs de inferência em andamento, resultando em jobs parcialmente concluídos que precisam ser reprocessados — custo duplo e violação de SLO. - Armazenar pesos de modelo em EBS em vez de /dev/shm ou EFS com cache local: o cold start de modelo via EBS gp3 pode ser 3–5x mais lento que via /dev/shm para modelos > 5 GB, especialmente com múltiplos pods inicializando simultaneamente. - Usar Reserved Instances para capacidade de inferência GPU: workloads de inferência de vídeo têm picos imprevisíveis. Savings Plans com On-Demand fallback via Karpenter oferecem melhor equilíbrio entre custo e flexibilidade do que RIs de 1 ou 3 anos. - Ignorar a ausência de MIG na L40S e tentar multi-tenancy via namespaces Kubernetes: namespaces não oferecem isolamento de GPU — dois pods em namespaces diferentes no mesmo nó compartilham a GPU sem isolamento de hardware, o que é inaceitável em ambientes financeiros regulados. > **Minha Nota de Curadoria:** Se eu fosse implementar inferência de vídeo generativo hoje em um ambiente financeiro, eu começaria com Bedrock para validar o modelo de negócio e os SLOs, e só migraria para G7e quando o volume diário justificasse o warm pool permanente — tipicamente acima de 300–500 clipes/dia. A lição mais dura que aprendi em workloads GPU é que o custo real não está no preço por hora da instância, mas no custo de capacidade ociosa de um warm pool superdimensionado e no custo de reprocessamento de jobs interrompidos por falta de PDB. A ausência de MIG na L40S é uma decisão de design da NVIDIA que tem consequências arquiteturais diretas para multi-tenancy financeiro — não é um detalhe de configuração, é uma força que deve aparecer no seu ADR. ## Veredicto: Quando Adotar G7e e Quando Não Adotar A EC2 G7e com L40S é a escolha correta para inferência de vídeo generativo em produção quando três condições são verdadeiras simultaneamente: (1) o workload requer modelos de vídeo com > 24 GB de VRAM ou SLOs de latência < 90s para clipes de 720p+, (2) o volume diário é suficiente para justificar um warm pool permanente (> 300 clipes/dia como heurística inicial), e (3) o modelo de multi-tenancy é por instância, não por GPU compartilhada. Se qualquer uma dessas condições não for atendida, Bedrock gerenciado ou G5/G6 com quantização agressiva são escolhas mais defensáveis. A ausência de MIG é o fator limitante mais subestimado desta instância para ambientes financeiros — coloque-o explicitamente no seu ADR e modele o custo de isolamento por instância antes de comprometer a arquitetura. **Rating:** Adopt with conditions / Adotar com condi ## Referências - [Amazon EC2 G7e Instances – AWS News Blog](https://aws.amazon.com/blogs/aws/) - [NVIDIA L40S GPU Architecture Whitepaper](https://resources.nvidia.com/en-us-l40s) - [Karpenter NodePool Configuration – AWS Docs](https://karpenter.sh/docs/concepts/nodepools/) - [IAM Roles for Service Accounts (IRSA) – EKS Best Practices](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) - [NVIDIA DCGM Exporter for Kubernetes](https://github.com/NVIDIA/dcgm-exporter) - [AWS Step Functions – Error Handling and Retries](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html) - [Amazon Bedrock – Video Generation Models](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) - [AWS Well-Architected Framework – Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html)