# GPU Fracionada no ECS: Decisão de Arquitetura para Inferência de IA

O Amazon ECS agora suporta agendamento de GPU fracionada em instâncias EC2 G6f, permitindo partições de até 1/8 de uma GPU NVIDIA L4 com 3 GB de memória. Para plataformas de inferência de IA em escala financeira, isso muda fundamentalmente o cálculo de custo e densidade de workload. Este ADR documenta o contexto, as opções consideradas, a decisão e as consequências operacionais reais.

- URL: https://fernando.moretes.com/blog/gpu-fracionada-no-ecs-decisao-de-arquitetura-para-inferencia-de-ia-amazon-ecs-n

- Markdown: https://fernando.moretes.com/blog/gpu-fracionada-no-ecs-decisao-de-arquitetura-para-inferencia-de-ia-amazon-ecs-n/article.md?lang=pt

- Published: 2026-08-07T09:03:54.483Z

- Category: IA & Agentes

- Tags: ECS, GPU, AI Inference, G6f, Cost Optimization, ECS Managed Instances, CloudWatch, Financial Grade

- Reading time: 10 min

- Source: [Amazon ECS now supports fractional GPU scheduling with Amazon EC2 G6f instances](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ecs-fractional-gpu/)

---

Em agosto de 2026, o Amazon ECS passou a suportar agendamento de GPU fracionada em instâncias EC2 G6f — o primeiro sinal concreto de que a AWS está tratando GPU como um recurso de primeira classe no plano de scheduling do ECS, não apenas como um dispositivo passthrough. Para arquitetos de plataformas de inferência de IA em ambientes financeiros, onde custo por inferência e isolamento de workload são restrições reais, esta mudança exige uma decisão de arquitetura explícita: quando adotar, como configurar e quais são as consequências operacionais que ninguém documenta no lançamento.

## Contexto e Forças: Por Que Isso Importa Agora

Antes desta feature, o ECS tratava GPU como um recurso binário: ou você alocava uma GPU inteira para um container, ou não alocava nenhuma. Na prática, isso significava que um modelo de classificação de risco de crédito com 1,2 bilhão de parâmetros — que cabe confortavelmente em 4 GB de VRAM — consumia uma GPU L4 inteira de 24 GB, desperdiçando 83% da capacidade de memória aceleradora. Para plataformas de inferência que servem dezenas de modelos diferentes com padrões de tráfego assimétricos, esse desperdício se traduzia diretamente em custo de instância desnecessário e em latência de cold-start porque o auto-scaling precisava provisionar instâncias inteiras para picos de tráfego em modelos pequenos.

As instâncias G6f foram anunciadas em GA em julho de 2025 com suporte nativo a particionamento de GPU via NVIDIA MIG-like partitioning sobre as L4 Tensor Core GPUs. A integração com o plano de scheduling do ECS, no entanto, só chegou em agosto de 2026 — um gap de 13 meses que forçou equipes a usarem soluções alternativas como device plugins customizados no EKS ou alocação manual de GPUs via variáveis de ambiente. Agora, com `GPU=0.125`, `GPU=0.25` e `GPU=0.5` como valores válidos na definição de task do ECS, o scheduler consegue bin-packing real: até 8 tasks em uma única instância G6f, cada uma com 3 GB de VRAM isolada.

O contexto financeiro adiciona camadas de complexidade. Reguladores como o Banco Central do Brasil e a SEC exigem rastreabilidade de decisões de modelos de ML usados em crédito, detecção de fraude e precificação de derivativos. Isso significa que múltiplos modelos precisam coexistir com isolamento de memória auditável — exatamente o que o particionamento de GPU oferece, desde que a configuração seja feita corretamente e monitorada de forma contínua.

## Forças em Tensão: O Que Torna Esta Decisão Não-Trivial

A decisão de adotar GPU fracionada no ECS não é simplesmente 'ative e economize'. Há forças arquiteturais genuinamente em tensão que precisam ser resolvidas antes de qualquer mudança em produção.

**Densidade vs. Isolamento de Blast Radius**: Quando você coloca 8 tasks em uma única instância G6f, uma falha de driver de GPU ou um kernel CUDA travado pode afetar todas as 8 partições simultaneamente. O ECS Managed Instances inclui health monitoring automático que detecta falhas de hardware de GPU e substitui instâncias não saudáveis, mas o tempo de detecção e substituição — tipicamente 2-5 minutos — é inaceitável para workloads de detecção de fraude em tempo real com SLOs de latência P99 abaixo de 200ms.

**Custo por Inferência vs. Custo de Capacidade Reservada**: Uma instância G6f com 8 partições de 1/8 GPU pode servir 8 modelos pequenos simultaneamente, mas se o tráfego for sazonal e apenas 2-3 partições estiverem ativas na maior parte do tempo, o custo de instância ociosa supera o benefício do bin-packing. O cálculo correto exige dados reais de utilização de GPU por modelo, não estimativas.

**Gerenciamento de Memória VRAM vs. Overhead de Runtime**: Com 3 GB de VRAM por partição de 1/8, modelos que usam quantização INT8 ou FP16 agressiva cabem facilmente. Mas frameworks como TensorRT e PyTorch Serve têm overheads de runtime que consomem 200-400 MB de VRAM antes mesmo de carregar pesos do modelo. Em partições de 3 GB, esse overhead representa 7-13% da capacidade total — um fator que precisa entrar no sizing.

**ECS Managed Instances vs. ECS on EC2 Self-Managed**: A escolha entre os dois modos de operação tem implicações diretas em controle operacional, customização de AMI e custo de gerenciamento. Para ambientes financeiros com requisitos de hardening de SO e conformidade com CIS Benchmarks, a AMI gerenciada pelo ECS Managed Instances pode não atender sem configuração adicional.

## Opções Consideradas para Plataforma de Inferência GPU

### ECS + GPU Fracionada (G6f, GPU=0.125/0.25/0.5)

**Pros**
- Bin-packing nativo no scheduler ECS — até 8 tasks por instância G6f
- ECS Managed Instances com health monitoring automático de GPU e métricas via CloudWatch Container Insights
- Sem overhead de plano de controle Kubernetes — menor complexidade operacional para equipes sem expertise em EKS
- Integração nativa com IAM task roles, Secrets Manager e VPC networking sem configuração adicional

**Cons**
- Apenas 3 valores de fração suportados (0.125, 0.25, 0.5) — sem granularidade intermediária
- Blast radius por instância: falha de hardware afeta todas as partições da mesma G6f
- Disponível apenas em regiões onde G6f está disponível — cobertura regional ainda limitada

**Verdict:** Recomendado para modelos pequenos com VRAM ≤ 10 GB e padrões de tráfego que justifiquem bin-packing

### EKS + NVIDIA Device Plugin + MIG (GPU Fracionada via Kubernetes)

**Pros**
- Controle total sobre particionamento MIG — granularidade de 1g.3gb, 2g.10gb, 4g.20gb no A100/H100
- Suporte a GPU Time-Slicing e MPS para workloads que não suportam MIG nativo
- Ecossistema maduro: DCGM Exporter, Prometheus, Grafana para observabilidade de GPU

**Cons**
- Overhead operacional significativo: configuração de MIG, DaemonSets, node labeling, taint/toleration management
- Custo de plano de controle EKS + complexidade de upgrades de cluster com node pools GPU
- Time-Slicing não oferece isolamento real de memória — modelos podem interferir entre si

**Verdict:** Preferível quando a equipe já opera EKS e precisa de granularidade MIG além de 1/8, ou suporte a A100/H100

### Amazon Bedrock Inference Endpoints (Serverless/Provisioned)

**Pros**
- Zero gerenciamento de infraestrutura GPU — totalmente serverless para modelos suportados
- Isolamento de tenant nativo, conformidade com SOC2/ISO27001 gerenciada pela AWS

**Cons**
- Sem suporte a modelos customizados ou fine-tuned fora do catálogo Bedrock
- Custo por token significativamente maior que inferência self-hosted em escala alta
- Latência de cold-start no modo serverless incompatível com SLOs de detecção de fraude em tempo real

**Verdict:** Adequado para experimentação e modelos de baixo volume; não para inferência proprietária em escala financeira

### EC2 G6f Self-Managed (sem ECS/EKS, alocação manual)

**Pros**
- Controle máximo sobre configuração de driver, CUDA toolkit version e otimizações de kernel

**Cons**
- Sem scheduling automático, bin-packing ou health monitoring — todo o gerenciamento é manual
- Custo operacional elevado; não escala para dezenas de modelos em produção

**Verdict:** Apenas para pesquisa ou prova de conceito isolada

## A Decisão: ECS + GPU Fracionada com ECS Managed Instances para Modelos Pequenos

Para uma plataforma de inferência de IA em ambiente financeiro que serve modelos de scoring de crédito, classificação de documentos e detecção de anomalias — todos com VRAM máxima de 8 GB e throughput de 50-500 req/s por modelo — a decisão é adotar ECS com GPU fracionada em instâncias G6f usando ECS Managed Instances, com as seguintes configurações específicas.

Cada task definition de inferência declara `GPU=0.25` como padrão (6 GB de VRAM, 4 tasks por instância), reservando headroom para o overhead de runtime do TensorRT (≈350 MB) e para picos de batch size. Modelos com menos de 2 GB de pesos quantizados em INT8 podem usar `GPU=0.125`, mas apenas em services com `minimumHealthyPercent=100` e `maximumPercent=200` para garantir que uma substituição de instância não reduza a capacidade disponível abaixo do mínimo de SLO.

A capacity provider é configurada com Auto Scaling Group (ASG) dedicado para instâncias G6f, com `targetCapacityPercent=70` — mantendo 30% de headroom para absorver spikes sem latência de provisioning. O `managedTerminationProtection=ENABLED` no capacity provider garante que instâncias com tasks ativas não sejam terminadas durante scale-in, evitando interrupções em inferências em andamento.

Para o IAM, cada task role tem permissões mínimas via condition keys: `aws:RequestedRegion` fixado na região de operação, `aws:SourceVpc` restrito à VPC de inferência, e acesso ao S3 para leitura de artefatos de modelo limitado por prefixo via `s3:prefix` condition. KMS CMK dedicada por ambiente (dev/staging/prod) para criptografia de artefatos de modelo em repouso, com key policy que permite apenas o task role do ECS e o pipeline de CI/CD de deploy de modelos.

A decisão de usar ECS Managed Instances em vez de ECS on EC2 self-managed é motivada pelo health monitoring automático de GPU — especificamente a detecção de falhas de hardware que substitui instâncias sem intervenção manual. Em um ambiente financeiro com SLA de 99,9% para inferência, essa automação é mais valiosa do que o controle adicional de AMI que o modo self-managed oferece.

## Arquitetura de Inferência com GPU Fracionada no ECS

Fluxo de uma requisição de inferência financeira desde o API Gateway até a task ECS com partição GPU isolada, mostrando scheduling, observabilidade e isolamento de segurança.

### 🌐 Edge / Ingress

- API Gateway REST + WAF (edge)
- NLB Internal (network)

### 🧠 ECS Inference Cluster (G6f)

- ECS Service Capacity Provider (compute)
- Task A GPU=0.25 (6 GB VRAM) (ai)
- Task B GPU=0.125 (3 GB VRAM) (ai)
- EC2 G6f NVIDIA L4 24GB (Managed Instance) (compute)

### 📦 Model Artifacts

- S3 Bucket Model Artifacts (KMS CMK) (storage)
- ECR Inference Image (Immutable Tag) (storage)

### 🔒 Security & IAM

- IAM Task Role VPC + Region Conditions (security)
- KMS CMK Per-Env Key (security)

### 📊 Observability

- CloudWatch Container Insights GPU Metrics (data)
- CloudWatch Alarm GPU Util < 20% → Scale-in (data)

### Fluxos

- client -> apigw: HTTPS + JWT
- apigw -> nlb: WAF filtrado
- nlb -> ecs_svc: roteamento interno
- ecs_svc -> task_a: schedule GPU=0.25
- ecs_svc -> task_b: schedule GPU=0.125
- task_a -> g6f: partição L4 isolada
- task_b -> g6f: partição L4 isolada
- task_a -> s3_models: leitura artefato (KMS)
- task_a -> ecr: pull imagem
- task_role -> task_a: assume role
- kms -> s3_models: decrypt artefato
- g6f -> cw_insights: GPU util / mem metrics
- cw_insights -> cw_alarm: threshold trigger

## Configuração Específica: Task Definition, Capacity Provider e Observabilidade

A configuração correta de uma task definition para GPU fracionada requer atenção a detalhes que não estão evidentes na documentação de lançamento. O campo `resourceRequirements` na definição de container aceita `type: GPU` com `value` como string representando a fração: `"0.125"`, `"0.25"` ou `"0.5"`. Importante: o valor é uma string, não um número float — um erro comum que resulta em falha silenciosa de validação e task placement em instâncias sem GPU.

Para o capacity provider com G6f, a configuração do ASG deve incluir `instanceWarmupPeriod` de pelo menos 180 segundos para acomodar o tempo de inicialização do driver NVIDIA e do container runtime. Com `managedScaling` habilitado, o `targetCapacityPercent=70` no capacity provider garante que o ECS mantenha instâncias suficientes para absorver um spike de 43% acima da capacidade atual sem latência de provisioning. Para workloads de detecção de fraude com SLO de P99 < 200ms, qualquer latência de cold-start de instância é inaceitável — o headroom de 30% é o custo de seguro para esse SLO.

A observabilidade de GPU via CloudWatch Container Insights com ECS Managed Instances expõe métricas como `GPUUtilization`, `GPUMemoryUsed` e `GPUMemoryTotal` por task e por instância. A configuração de alarmes deve incluir: (1) `GPUMemoryUsed / GPUMemoryTotal > 90%` por 5 minutos como sinal de pressão de memória que precede OOM kills; (2) `GPUUtilization < 15%` por 15 minutos como sinal de scale-in seguro; (3) `TaskCount < desiredCount` por 2 minutos como alarme de degradação de serviço que aciona PagerDuty.

Para rastreabilidade regulatória, cada requisição de inferência deve incluir no response header o `X-Model-Version` e o `X-Inference-TaskArn` — o Task ARN do ECS permite correlacionar a decisão do modelo com a instância e partição GPU exata que a executou, o que é necessário para auditorias de modelos de crédito sob as diretrizes do Banco Central.

> **Consequências e Riscos Operacionais:** **Blast radius por instância é real e subestimado.** Com 4-8 tasks em uma única G6f, uma falha de driver NVIDIA — que não é rara após atualizações de kernel — derruba todas as partições simultaneamente. O health monitoring do ECS Managed Instances detecta a falha e substitui a instância, mas o tempo de substituição (provisionamento + warmup + pull de imagem + inicialização do modelo) pode ser de 4-8 minutos. Para workloads financeiros críticos, isso significa que o design de redundância deve garantir que nenhuma instância G6f única sirva mais de 40% da capacidade total de um modelo — o que implica no mínimo 3 instâncias G6f ativas por modelo crítico, mesmo que a utilização não justifique.

**VRAM overflow é silencioso sem alertas configurados.** Se um modelo excede a VRAM da partição (3 GB para GPU=0.125), o comportamento padrão do driver não é falha limpa — pode ser swap para memória do host com degradação severa de latência (10-100x) antes de eventual OOM kill. Configure `GPUMemoryUsed > 85%` como alarme de WARNING e `> 95%` como CRITICAL com ação automática de substituição de task.

**Custo de Savings Plans não cobre G6f automaticamente.** Instâncias G6f são cobertas por Compute Savings Plans, mas não por EC2 Instance Savings Plans específicos para outras famílias. Verifique a cobertura existente antes de migrar workloads para evitar surpresas de custo no final do mês.

**Conformidade de dados em partições compartilhadas.** Mesmo com isolamento de memória VRAM entre partições, dados em trânsito na PCIe bus são compartilhados. Para modelos que processam dados de PII de clientes financeiros, avalie se o isolamento de partição atende aos requisitos da LGPD e do PCI-DSS antes de colocar múltiplos tenants na mesma instância G6f.

## Análise de Custo: Quando o Bin-Packing Realmente Compensa

A promessa de redução de custo do GPU fracionado é real, mas condicional. O cálculo precisa ser feito com dados reais de utilização, não com a premissa otimista de que todas as partições estarão ocupadas o tempo todo.

Considere um cenário concreto: uma plataforma financeira com 12 modelos de inferência pequenos, cada um com pico de 100 req/s e VRAM de 4 GB. No modelo anterior (GPU inteira por task), você precisaria de 12 instâncias G6 (uma GPU por modelo), com custo aproximado de $X por hora. Com GPU fracionada usando `GPU=0.25` (4 tasks por instância G6f), você precisa de no mínimo 3 instâncias G6f para os 12 modelos — uma redução teórica de 75% no número de instâncias.

Mas o cálculo real inclui: (1) headroom de 30% para absorver spikes sem cold-start → 3 instâncias viram 4; (2) redundância mínima de 3 instâncias por modelo crítico para blast radius → os modelos críticos precisam de instâncias dedicadas; (3) `instanceWarmupPeriod` de 180s significa que o ASG não pode escalar rápido o suficiente para picos abruptos sem pre-warming.

Na prática, para 12 modelos com distribuição mista (4 críticos + 8 experimentais), a configuração ótima é: 4 instâncias G6f dedicadas para modelos críticos (um modelo por instância, usando `GPU=0.25` para deixar headroom para versões A/B simultâneas) + 2 instâncias G6f compartilhadas para os 8 modelos experimentais. Isso resulta em 6 instâncias G6f versus 12 instâncias G6 anteriores — redução de 50%, não 75%, mas ainda significativa. O benefício real é que os modelos experimentais saem de instâncias dedicadas para compartilhadas, liberando capacidade para os críticos sem aumento de custo.

Para calcular o break-even, a métrica correta é `custo por 1000 inferências por modelo`, não `custo de instância`. Com bin-packing, o denominador aumenta proporcionalmente ao número de tasks por instância, mas o numerador (custo de instância) permanece fixo — o que melhora o custo por inferência apenas quando a utilização agregada das partições é alta o suficiente para justificar o custo de instância compartilhado.

## Avaliação Well-Architected: GPU Fracionada no ECS

- **security**: IAM task roles com condition keys de VPC e região; KMS CMK por ambiente para artefatos de modelo; sem acesso a metadados de instância EC2 via `disableNetworking` ou IMDSv2 obrigatório; SecurityGroup dedicado para o cluster ECS GPU com egress restrito ao S3 endpoint e ECR endpoint via VPC Endpoints.
- **reliability**: Mínimo de 3 instâncias G6f ativas por modelo crítico para tolerar falha de uma instância sem degradação de SLO; `minimumHealthyPercent=100` em services críticos; health monitoring automático do ECS Managed Instances para substituição de instâncias com falha de GPU; circuit breaker de deployment habilitado para evitar rollout de imagens com falha de inicialização de modelo.
- **performance**: TensorRT para otimização de inferência com precisão FP16/INT8; `GPU=0.25` como padrão para headroom de VRAM; `instanceWarmupPeriod=180s` no ASG; pre-warming de instâncias via scheduled scaling para picos previsíveis (ex: abertura do mercado financeiro às 9h); monitoramento de latência P50/P95/P99 por modelo via CloudWatch Embedded Metrics Format.
- **sustainability**: Bin-packing de GPU fracionada reduz o número de instâncias ativas, diminuindo consumo de energia por inferência; modelos quantizados em INT8 reduzem FLOPS por inferência sem degradação significativa de acurácia para scoring de crédito; desligamento automático de instâncias ociosas via scale-to-zero para ambientes de desenvolvimento e staging.

## Anti-Padrões a Evitar com GPU Fracionada no ECS

- Usar `GPU=0.125` para modelos de produção críticos sem redundância de instância — 3 GB de VRAM é suficiente para modelos pequenos, mas o blast radius de uma falha de instância é inaceitável sem múltiplas réplicas em instâncias diferentes.
- Misturar modelos de diferentes tenants (clientes financeiros) na mesma instância G6f sem avaliação de conformidade de dados — o isolamento de VRAM não garante isolamento de dados em todos os vetores de ataque.
- Configurar `targetCapacityPercent=100` no capacity provider para maximizar utilização — isso elimina o headroom necessário para absorver spikes e resulta em latência de cold-start de instância em picos de tráfego.
- Usar ECS on EC2 self-managed sem implementar health monitoring de GPU equivalente ao ECS Managed Instances — falhas de hardware de GPU sem detecção automática resultam em tasks travadas servindo erros silenciosos.
- Assumir que o valor `GPU` na task definition é um float — é uma string; `GPU=0.25` funciona, `GPU=0.250` pode falhar dependendo da versão do agente ECS.
- Ignorar o overhead de runtime do framework de inferência no sizing de VRAM — TensorRT, PyTorch Serve e Triton consomem 200-500 MB de VRAM antes de carregar qualquer peso de modelo.

> **Nota do Arquiteto:** Na minha experiência com plataformas de inferência em ambientes financeiros, o erro mais caro não é escolher a fração errada de GPU — é subestimar o blast radius de falhas de hardware em instâncias com alta densidade de tasks. Eu sempre começo com `GPU=0.25` e nunca coloco mais de 40% da capacidade de um modelo crítico em uma única instância G6f, independente do custo de headroom. O segundo erro mais comum que vejo é pular a validação de VRAM no pipeline de CI/CD: um modelo que passou de 2,8 GB para 3,1 GB de VRAM após um fine-tune silencioso vai causar degradação de latência em produção antes de qualquer alarme disparar. Automatize essa validação como gate de deploy. Por fim, o ECS Managed Instances é a escolha certa para 90% dos casos — o controle adicional do modo self-managed raramente justifica o custo operacional em equipes que não têm um especialista em NVIDIA driver management dedicado.

## Veredicto: Adote com Disciplina de Sizing e Redundância

GPU fracionada no ECS com instâncias G6f é uma feature genuinamente útil para plataformas de inferência de IA que operam múltiplos modelos pequenos — especialmente em ambientes financeiros onde custo por inferência e rastreabilidade regulatória são restrições reais. A integração nativa com o scheduler do ECS elimina a complexidade operacional de device plugins customizados que equipes precisavam manter no EKS, e o ECS Managed Instances com health monitoring automático de GPU reduz o risco operacional de falhas de hardware não detectadas.

A recomendação é adotar `GPU=0.25` como padrão para modelos de produção (headroom de VRAM), `GPU=0.125` apenas para modelos experimentais ou de baixo volume com redundância explícita, e `GPU=0.5` para modelos que precisam de 10-12 GB de VRAM após overhead de runtime. Configure `targetCapacityPercent=70` no capacity provider, implemente alarmes de `GPUMemoryUsed > 85%` e `GPUUtilization < 15%`, e nunca concentre mais de 40% da capacidade de um modelo crítico em uma única instância G6f.

O que esta feature não resolve: modelos que precisam de mais de 12 GB de VRAM (use GPU=0.5 ou instâncias G6/G5 com GPU inteira), workloads que exigem isolamento de tenant de nível hardware entre partições, e ambientes onde a cobertura regional de G6f ainda não está disponível. Para esses casos, EKS com MIG configurado manualmente ou instâncias dedicadas por modelo continuam sendo as escolhas corretas.

**Rating:** Recommended with Conditions

## Referências

- [Amazon ECS Fractional GPU Scheduling — AWS What's New (Aug 2026)](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ecs-fractional-gpu/)
- [Amazon EC2 G6f Instances GA with Fractional GPUs — AWS What's New (Jul 2025)](https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-ec2-g6f-instances-fractional-gpus/)
- [Amazon ECS Fractional GPU Documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html)
- [ECS Managed Instances — AWS Documentation](https://aws.amazon.com/ecs/managed-instances/)
- [CloudWatch Container Insights Enhanced Observability for ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-enhanced-observability-metrics-ECS.html)
- [Amazon EC2 G6 Instance Page](https://aws.amazon.com/ec2/instance-types/g6/)
- [AWS Well-Architected Framework — Performance Efficiency Pillar](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html)
- [NVIDIA L4 Tensor Core GPU Product Brief](https://www.nvidia.com/en-us/data-center/l4/)