# Teardown: Resilient Network Graphs e a Próxima Geração de Rede para IA Uma análise arquitetural aprofundada das redes de data center baseadas em grafos resilientes que a AWS está construindo para suportar workloads de IA em escala — cobrindo topologia, controle de congestionamento, eficiência energética e os trade-offs que definem a próxima geração de infraestrutura cloud. - URL: https://fernando.moretes.com/studies/teardown-resilient-network-graphs-ai-data-center - Markdown: https://fernando.moretes.com/studies/teardown-resilient-network-graphs-ai-data-center/study.md?lang=pt - Type: Teardown - Company: AWS data center networking - Domain: Infraestrutura / IA - Date: 2026-06-09 - Tags: networking, AI infrastructure, data center, graph topology, distributed training, sustainability, AWS, congestion control - Reading time: 11 min --- Treinar um modelo de linguagem de fronteira não é um problema de computação — é um problema de rede. Quando dezenas de milhares de aceleradores precisam trocar gradientes em microssegundos, a topologia do switch, o algoritmo de roteamento e a política de controle de congestionamento determinam se o job termina em dias ou em semanas. A AWS está redesenhando a rede de seus data centers do zero para esse regime. Este teardown reconstrói a arquitetura, examina as decisões de design e avalia o que funciona, o que é arriscado e o que eu faria diferente. ## Ficha Técnica - **Empresa / Sistema:** Amazon Web Services — Rede de Data Center para IA - **Domínio:** Infraestrutura de rede / Workloads de IA - **Escala declarada:** Dezenas de milhares de aceleradores por cluster; redes de 400 Gbps a 3,2 Tbps por porta (estimativa de roadmap) - **Stack principal:** Topologia fat-tree / Clos multi-estágio, ECMP adaptativo, RDMA sobre Ethernet convergente (RoCEv2), switches de silício customizado (Nitro, Trainium, Inferentia), roteamento baseado em grafos - **Sustentabilidade:** Meta de 100% de energia renovável (atingida em 2023 globalmente); PUE médio de ~1,2 nos novos data centers - **Referência pública principal:** AWS Architecture Center, Amazon Sustainability Report 2023 - **Tipo de análise:** Teardown arquitetural — reconstrução a partir de fontes públicas ## O Problema: Por Que a Rede de Data Center Convencional Quebra com IA Durante a maior parte da história do cloud computing, a rede de data center foi projetada para tráfego *east-west* de microsserviços: muitas conexões curtas, tolerância razoável a latência variável, e padrões de tráfego relativamente imprevisíveis que se beneficiam de ECMP estático. O modelo funciona bem para OLTP, streaming de vídeo e APIs REST. Ele falha categoricamente para treinamento distribuído de modelos de IA. O motivo é estrutural. Em um job de treinamento com All-Reduce coletivo — o padrão dominante em frameworks como PyTorch com NCCL — todos os workers precisam sincronizar gradientes em cada passo de otimização. Isso gera um padrão de tráfego *incast*: centenas ou milhares de fluxos convergem simultaneamente para os mesmos switches de agregação. Buffers transbordam. Pacotes são descartados. O NCCL entra em retransmissão. O job que deveria terminar em 12 horas termina em 18 — ou não termina. A questão de congestionamento é agravada por três fatores específicos de IA: (1) **tamanho dos tensores** — um único All-Reduce em um modelo de 70B parâmetros pode mover centenas de gigabytes por passo; (2) **sincronicidade** — diferente de tráfego web, os workers disparam ao mesmo tempo porque o SGD é síncrono por design; (3) **sensibilidade a jitter** — a latência de cauda mata a eficiência porque o passo só avança quando o *último* worker termina. Um único link congestionado pode degradar a utilização de GPU de 90% para 40%. Além do congestionamento, há o problema de **topologia de falha**. Em uma rede Clos clássica com ECMP estático, a falha de um spine switch pode criar assimetria de carga que o plano de dados não detecta rapidamente. Para workloads de longa duração (jobs de dias), isso significa degradação silenciosa — o job continua, mas lento, sem alarme óbvio. Detectar e re-rotear em segundos, não em minutos, é requisito de produção. Por fim, há a dimensão de **custo energético**. Um cluster de 16.000 GPUs H100 consome na ordem de 50-80 MW apenas em compute. A rede de interconexão adiciona 10-20% sobre isso. Switches de alto radix com buffers profundos e SerDes de alta velocidade são vorazes em energia. A escolha de topologia, velocidade de porta e política de buffer tem impacto direto no PUE e na conta de energia — e, portanto, na meta de sustentabilidade da Amazon. ## Arquitetura Reconstruída: Rede de Data Center para Workloads de IA Reconstrução baseada em fontes públicas da AWS. Representa um cluster de treinamento de IA com topologia Clos multi-estágio, plano de controle baseado em grafos, e integração com o stack de sustentabilidade. ### 🖥️ Compute Layer - GPU/Trainium Worker Rack 0 (compute) - GPU/Trainium Worker Rack 1 (compute) - GPU/Trainium Worker Rack N (compute) ### 🔀 Edge / ToR Layer - ToR Switch Rack 0 (400G) (network) - ToR Switch Rack 1 (400G) (network) - ToR Switch Rack N (400G) (network) ### 🌐 Aggregation Layer - Aggregation Switch A0 (network) - Aggregation Switch A1 (network) ### 🏗️ Spine / Core Layer - Spine Switch S0 (Custom ASIC) (network) - Spine Switch S1 (Custom ASIC) (network) - Spine Switch S2 (Custom ASIC) (network) ### 🧠 Control Plane - Graph-Based Control Plane (ai) - In-Band Telemetry (INT) (data) - Adaptive Congestion Controller (DCQCN) (network) ### ♻️ Sustainability Stack - PUE Monitor & Power Capping (external) - Renewable Energy Matching (100%) (external) ### 🔗 Storage / Checkpoint - S3 / EFS Checkpoint Store (storage) ### Fluxos - gpu0 -> tor0: RoCEv2 400G - gpu1 -> tor1: RoCEv2 400G - gpu2 -> tor2: RoCEv2 400G - tor0 -> agg0: uplink - tor1 -> agg0: uplink - tor2 -> agg1: uplink - agg0 -> spine0 - agg0 -> spine1 - agg1 -> spine1 - agg1 -> spine2 - telemetry -> graphctrl: métricas de fluxo - graphctrl -> congctrl: política de roteamento - congctrl -> tor0 - congctrl -> tor1 - congctrl -> tor2 - graphctrl -> spine0: re-roteamento - pue -> graphctrl - gpu0 -> s3ckpt: checkpoint - gpu1 -> s3ckpt ## Como Funciona: Topologia, Grafos e Controle de Congestionamento A arquitetura central é uma **rede Clos multi-estágio** — especificamente uma variante fat-tree de três camadas: ToR (Top-of-Rack), Agregação e Spine. Isso não é novidade; a Clos é o padrão da indústria desde os anos 2000. O que diferencia a abordagem da AWS para IA é o que acontece *acima* do plano de dados. **Plano de controle baseado em grafos.** A rede é modelada como um grafo dirigido ponderado onde os nós são switches e os vértices são links com atributos de capacidade, utilização atual e estado de saúde. Um controlador centralizado (análogo a um SDN controller, mas com semântica de grafo) mantém essa representação em memória e executa algoritmos de caminho mínimo com restrições de capacidade — essencialmente uma variante de Dijkstra ou Bellman-Ford com múltiplos objetivos: minimizar latência de cauda, maximizar throughput de bisseção e evitar links degradados. Quando a telemetria in-band (INT) reporta que um link está acima de 70% de utilização, o controlador recalcula rotas alternativas e as injeta no plano de dados via P4 ou OpenConfig, sem intervenção humana. O tempo de convergência alvo é sub-segundo — crítico para jobs de treinamento que não podem pausar. **RoCEv2 e DCQCN.** O transporte de dados entre GPUs usa RDMA sobre Ethernet convergente (RoCEv2), que elimina o overhead de cópia de memória do kernel e reduz latência para dezenas de microssegundos. O problema clássico do RoCEv2 é que ele é *lossless por design* — usa PFC (Priority Flow Control) para pausar transmissores upstream quando buffers enchem. PFC mal configurado gera *deadlock de PFC*, onde pausas se propagam pela rede e paralisam tráfego não relacionado. A AWS mitiga isso com **DCQCN** (Data Center Quantized Congestion Notification), um algoritmo de controle de congestionamento baseado em ECN que reduz a taxa de injeção do transmissor *antes* de o buffer estourar, mantendo a rede em regime não-lossy sem depender de PFC como mecanismo primário. **Telemetria in-band (INT).** Cada pacote carrega metadados de latência e utilização de fila coletados por cada switch no caminho. O controlador agrega esses dados em tempo real para construir um mapa de calor da rede. Isso é fundamentalmente diferente de polling SNMP periódico — a granularidade temporal é por-fluxo, não por-interface, e a latência de observabilidade é de milissegundos, não de minutos. Para um job de treinamento com All-Reduce a cada 100ms, isso faz diferença operacional real. **Checkpointing e resiliência de job.** A rede sozinha não garante resiliência de job. A AWS integra checkpointing periódico para S3/EFS diretamente nos frameworks de treinamento (via SageMaker ou Trainium SDK). Se um nó falha ou um link degrada a ponto de o job ser abortado, o treinamento reinicia do último checkpoint, não do zero. A frequência de checkpoint é um trade-off: checkpoints mais frequentes reduzem o trabalho perdido mas aumentam o tráfego de rede e o custo de I/O — especialmente relevante para modelos de 100B+ parâmetros onde um checkpoint pode ter centenas de GB. ## Matriz de Decisões Arquiteturais ### Topologia Clos Fat-Tree vs. Torus 3D (estilo HPC) **Pros** - Bisseção de banda uniforme — qualquer nó pode falar com qualquer outro à velocidade de linha - Tolerância a falhas por múltiplos caminhos paralelos (ECMP) - Escala horizontal sem redesign de topologia **Cons** - Custo de cabeamento e switches cresce com O(n log n) — mais caro que torus para clusters muito grandes - Latência de hop count maior que torus direto para comunicação nearest-neighbor **Verdict:** Correto para cloud multi-tenant. Torus faz sentido apenas em clusters dedicados de HPC puro. ### DCQCN (ECN-based) vs. PFC puro **Pros** - Evita deadlock de PFC — o maior risco operacional em redes RoCEv2 - Controle de congestionamento proativo, não reativo - Compatível com tráfego TCP convencional no mesmo fabric **Cons** - Requer suporte a ECN em todos os switches do caminho — lock-in de hardware - Tuning de parâmetros (Kmin, Kmax, g) é sensível ao perfil de tráfego específico **Verdict:** Decisão correta. PFC puro é uma bomba-relógio em produção com incast de IA. ### Silício customizado (Nitro, Trainium) vs. merchant silicon (Broadcom Tomahawk) **Pros** - Controle total do roadmap de features — pode otimizar para padrão de tráfego de IA específico - Integração profunda entre NIC, switch e acelerador (offload de coletivos) - Vantagem competitiva sustentável — concorrentes não têm acesso ao mesmo silício **Cons** - CapEx de P&D de silício é bilionário — barreira de entrada proibitiva para qualquer um exceto hyperscalers - Ciclo de iteração de hardware de 2-3 anos vs. software que pode ser atualizado em semanas **Verdict:** Faz sentido para a AWS. Para qualquer outra empresa, merchant silicon com software diferenciado é o caminho. ### Controlador SDN centralizado vs. roteamento distribuído puro **Pros** - Visão global da rede — pode otimizar rotas com informação completa de estado - Convergência mais rápida em falhas complexas (múltiplos links simultâneos) **Cons** - O controlador centralizado é um ponto único de falha lógico — requer HA cuidadoso - Latência de controle (RTT para o controlador) pode ser problemática para re-roteamento sub-segundo em clusters muito grandes **Verdict:** Híbrido é o estado da arte: distribuído para reações rápidas locais, centralizado para otimização global. ## Sustentabilidade como Restrição Arquitetural, Não Como Marketing A Amazon atingiu 100% de energia renovável em 2023 — antes da meta original de 2025. Isso é relevante para este teardown não como nota de rodapé de ESG, mas porque **sustentabilidade está se tornando uma restrição de design de primeira classe** na arquitetura de rede de IA. O argumento é direto: um cluster de treinamento de IA de 10.000 aceleradores consome na ordem de 30-60 MW. A rede de interconexão representa 10-20% desse consumo — ou seja, 3-12 MW apenas em switches e transceivers. A escolha entre SerDes de 112G PAM4 vs. 56G NRZ para links de 400G tem impacto direto no consumo por bit. A escolha de buffers profundos (necessários para absorver incast) vs. buffers rasos (mais eficientes energeticamente) é um trade-off explícito entre eficiência de rede e consumo de energia. A AWS está endereçando isso em três frentes. Primeiro, **PUE de ~1,2** nos novos data centers — alcançado via resfriamento líquido direto nos racks de GPU e otimização de airflow. Para contexto: um PUE de 1,2 significa que 83% da energia vai para compute; um PUE de 1,5 (típico de data centers legados) significa apenas 67%. A diferença em um cluster de 50 MW é 8 MW — o suficiente para alimentar uma cidade pequena. Segundo, **power capping dinâmico** integrado ao controlador de rede. Quando a demanda de energia do data center se aproxima de um limite, o controlador pode reduzir frequências de clock de switches não-críticos ou consolidar tráfego em menos links físicos (desligando os demais). Isso é análogo ao que processadores fazem com DVFS, mas aplicado à rede. Terceiro, **co-localização com fontes renováveis**. A AWS está construindo data centers próximos a fazendas solares e eólicas para minimizar perdas de transmissão e garantir matching temporal de energia renovável — não apenas créditos anuais (RECs), mas matching horário real. Isso influencia a escolha de localização de regiões e, indiretamente, a latência de rede entre regiões. O ponto que quero deixar claro: para arquitetos de sistemas que projetam workloads de IA, a eficiência energética da rede não é problema do time de infraestrutura da AWS — é um parâmetro que afeta o custo por token treinado e, portanto, a viabilidade econômica do produto. Escolher instâncias com rede de maior eficiência (Trainium2 vs. P4d, por exemplo) é uma decisão arquitetural com impacto financeiro mensurável. ## Leitura pelo AWS Well-Architected Framework - **security**: **Forte, mas com superfície ampliada.** RoCEv2 opera em L2/L3 com bypass de kernel — o modelo de segurança tradicional baseado em firewalls de host não se aplica diretamente. A AWS isola clusters de treinamento em VPCs dedicadas com placement groups e security groups granulares. O Nitro System garante que o hypervisor não tem acesso aos dados de treinamento. O risco residual é lateral movement dentro do mesmo cluster — mitigado por segmentação de rede por job. - **reliability**: **O ponto mais forte da arquitetura.** Múltiplos caminhos paralelos (ECMP com 64+ caminhos em fat-tree), re-roteamento sub-segundo via controlador de grafos, e checkpointing automático de jobs criam resiliência em camadas. A falha de um único switch spine não deve degradar throughput em mais de 1/N (onde N é o número de spines). O risco principal é a falha correlacionada — um bug de firmware que afeta todos os switches do mesmo modelo simultaneamente. A AWS mitiga isso com atualizações de firmware em rolling e canary deployments na rede. - **performance**: **Otimizado para o caso de uso, com trade-offs explícitos.** RoCEv2 + DCQCN entrega latência de dezenas de microssegundos e throughput próximo à velocidade de linha em condições normais. O gargalo em clusters grandes é o All-Reduce coletivo — especificamente a fase de scatter-reduce que satura os uplinks de ToR. A AWS endereça isso com offload de coletivos no hardware Trainium (EFA com NCCL customizado), movendo parte da computação de All-Reduce para o NIC e reduzindo o tráfego na rede. - **sustainability**: **Diferencial real e mensurável.** PUE de ~1,2, 100% de energia renovável (matching real, não apenas RECs), e power capping dinâmico integrado ao controlador de rede colocam a AWS entre as infraestruturas de data center mais eficientes do mundo. O impacto para o cliente é direto: treinar um modelo na AWS tem pegada de carbono materialmente menor do que on-premises em data center legado. Isso está se tornando um critério de procurement em empresas com metas de net-zero. > **O Que Eu Faria Diferente:** **1. Apostaria mais cedo em topologias de grafos não-Clos para clusters de IA dedicados.** A fat-tree Clos é ótima para multi-tenancy e tráfego geral, mas para clusters de treinamento dedicados (onde você sabe exatamente quais jobs rodam onde), topologias como Dragonfly+ ou Slim Fly oferecem menor diâmetro de rede e menor custo de cabeamento para o mesmo bisection bandwidth. A AWS provavelmente está explorando isso internamente (há sinais em papers de pesquisa), mas a comunicação pública ainda é dominada pela narrativa Clos. Se eu estivesse projetando um cluster de 50.000+ aceleradores dedicados a treinamento, avaliaria seriamente Dragonfly+ com roteamento adaptativo baseado em grafos. **2. Investiria pesado em observabilidade correlacionada antes de escalar.** O problema mais difícil que vejo em produção não é congestionamento — é debugging. Quando um job de treinamento está 30% mais lento que o esperado, a causa pode ser: (a) congestionamento em um link específico, (b) um worker com GPU degradada, (c) imbalance no particionamento do modelo, (d) throttling de checkpoint por I/O. Sem correlação automática de métricas de rede + GPU + sistema, você passa horas em hipóteses. Eu construiria um pipeline de observabilidade unificado (OpenTelemetry com contexto de job propagado até o nível de pacote de rede) antes de escalar para além de 1.000 nós. **3. Trataria o controlador SDN como serviço de missão crítica desde o dia 1.** Vejo times que deployam controladores SDN com a mesma disciplina de um serviço interno de baixa criticidade. Para uma rede de IA em produção, o controlador é tão crítico quanto o banco de dados de pagamentos. Isso significa: HA ativo-ativo com failover testado regularmente, chaos engineering na rede (injeção de falhas de link em produção em horários controlados), e runbooks detalhados para cada modo de falha do controlador. A maioria dos times não faz isso até depois do primeiro incidente grave. **4. Separaria fisicamente o tráfego de checkpoint do tráfego de All-Reduce.** Usar a mesma rede de alta velocidade para All-Reduce (latência crítica) e checkpoint (throughput crítico, latência tolerante) cria contenção em momentos de checkpoint. Eu projetaria uma rede de storage separada (25G ou 100G) dedicada a checkpointing, liberando a rede de 400G+ exclusivamente para tráfego de gradientes. O custo adicional de cabeamento é marginal comparado ao impacto de um checkpoint que degrada o throughput de treinamento por 10-15 segundos a cada hora. ## Impacto para Arquitetos de Sistemas: O Que Isso Significa na Prática Este teardown não é apenas sobre o que a AWS faz internamente. As decisões arquiteturais da infraestrutura de rede da AWS se propagam diretamente para as escolhas que arquitetos de sistemas fazem ao projetar workloads de IA na cloud. **Escolha de instância não é só sobre FLOP/$.** A topologia de rede da instância importa tanto quanto o número de aceleradores. Uma instância P4de com EFA em um placement group de cluster tem comportamento de rede fundamentalmente diferente de uma instância G5 em uma AZ genérica. Para jobs de treinamento distribuído acima de 8 GPUs, a escolha de instância e placement group deve ser guiada por análise de padrão de comunicação do modelo — não apenas por custo de compute. **Particionamento de modelo tem implicações de rede.** Tensor parallelism (TP) gera tráfego all-to-all de alta frequência entre GPUs do mesmo nó — ideal para NVLink, não para Ethernet. Pipeline parallelism (PP) gera tráfego ponto-a-ponto entre estágios — tolerante a latência maior. Data parallelism (DP) gera All-Reduce periódico — o caso para o qual a rede descrita neste teardown é otimizada. Um arquiteto que entende a topologia de rede pode escolher a estratégia de paralelismo que minimiza o gargalo de comunicação para seu modelo específico. **Monitoramento de rede é parte do SLA de treinamento.** Em sistemas financeiros, eu nunca aceitaria um SLA de disponibilidade sem monitoramento de latência de rede. O mesmo princípio se aplica a clusters de IA: o SLA de conclusão de job deve incluir métricas de rede (utilização de link, taxa de retransmissão RDMA, latência de All-Reduce). CloudWatch com métricas de EFA e VPC Flow Logs são o mínimo; INT via ferramentas como AWS Network Manager é o estado da arte. **Custo de rede é visível e otimizável.** O tráfego entre AZs tem custo explícito na AWS. Um job de treinamento mal particionado que gera tráfego cross-AZ pode ter custo de rede que supera o custo de compute. Isso é um bug de arquitetura, não um problema de infraestrutura. A solução é placement group de cluster (garante co-localização na mesma AZ e, idealmente, no mesmo rack) e análise de tráfego antes de escalar. ## Veredicto A arquitetura de rede de data center da AWS para IA é tecnicamente sólida e representa o estado da arte em infraestrutura de cloud pública. A combinação de topologia Clos fat-tree com plano de controle baseado em grafos, RoCEv2 com DCQCN, telemetria in-band por-fluxo e silício customizado integrado é coerente, bem fundamentada em pesquisa acadêmica e endereça os problemas reais de congestionamento, resiliência e eficiência energética que definem o custo de treinamento de IA em escala. Os pontos fortes são claros: resiliência por design (múltiplos caminhos, re-roteamento sub-segundo, checkpointing automático), eficiência energética mensurável (PUE ~1,2, 100% renovável), e integração profunda entre rede e acelerador (EFA, offload de coletivos no Trainium). Esses não são diferenciais de marketing — são vantagens arquiteturais com impacto direto no custo por token treinado. As lacunas que identifico são principalmente de observabilidade e operação: o tooling para correlacionar métricas de rede com métricas de job de treinamento ainda está amadurecendo, e a complexidade operacional de tuning de DCQCN e configuração de RoCEv2 é subestimada pela maioria dos times que adotam essas tecnologias. O controlador SDN centralizado, se não tratado com a disciplina de um sistema de missão crítica, é um risco real. Para arquitetos de sistemas que projetam workloads de IA: a infraestrutura de rede da AWS é suficientemente boa para a maioria dos casos de uso. O diferencial competitivo não está em escolher o cloud provider com a melhor rede — está em entender a topologia profundamente o suficiente para fazer escolhas de particionamento de modelo, placement e monitoramento que extraiam o máximo dessa infraestrutura. Esse entendimento é raro e é onde o valor arquitetural real reside. ## Referências - [AWS Architecture Center](https://aws.amazon.com/architecture/) - [Amazon Sustainability — 2023 Report](https://sustainability.aboutamazon.com/) - [AWS Elastic Fabric Adapter (EFA) — Documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) - [AWS Trainium and Inferentia — Architecture Overview](https://aws.amazon.com/machine-learning/trainium/) - [AWS re:Invent 2023 — AI/ML Infrastructure Networking](https://reinvent.awsevents.com/) - [DCQCN: Congestion Control for Large-Scale RDMA Deployments (Microsoft Research / Zhu et al., SIGCOMM 2015)](https://dl.acm.org/doi/10.1145/2785956.2787484) - [Jupiter Evolving: Transforming Google's Datacenter Network (SIGCOMM 2022)](https://dl.acm.org/doi/10.1145/3544216.3544265) - [AWS Nitro System — Security and Architecture](https://aws.amazon.com/ec2/nitro/) ## Fontes do caso - [AWS Architecture Center](https://aws.amazon.com/architecture/) - [Amazon Sustainability](https://sustainability.aboutamazon.com/)