A falácia do 'Storage Infinito' na nuvem: Por que a IA exige repatriação e CXL em 2026

O marketing da nuvem nos vendeu um sonho sedutor na última década: armazenamento infinito, durabilidade de onze noves e a promessa de que você nunca mais precisaria trocar um disco falho em um data center gelado às 3 da manhã. Para a maioria das cargas de trabalho, o Amazon S3 e seus equivalentes no Azure e Google Cloud são maravilhosos. Mas estamos em 2026, a era da Inteligência Artificial generativa em escala industrial, e a física decidiu cobrar a conta.

O conceito de "Storage Infinito" na nuvem pública tornou-se uma armadilha financeira e técnica para o treinamento de modelos de IA. A nuvem é excelente para armazenar petabytes de logs que ninguém lê, mas quando você precisa alimentar um cluster de GPUs H100 ou Blackwell com terabytes de dados por segundo, o modelo de "object storage via HTTP" colapsa. Não é apenas uma questão de largura de banda; é uma questão de latência, protocolo e, dolorosamente, de custo de egress.

Resumo em 30 segundos

• O custo oculto: Em cargas de trabalho de IA, as taxas de transferência de dados (egress) e chamadas de API podem superar o custo do aluguel das próprias GPUs.
• O gargalo do protocolo: O S3 foi feito para durabilidade e escala web, não para a latência de microssegundos exigida pelo treinamento de modelos modernos.
• A solução CXL: O Compute Express Link (CXL) 3.1 transforma o armazenamento em "memória lenta", permitindo que GPUs acessem dados sem a sobrecarga da CPU, algo impossível na arquitetura de nuvem tradicional atual.

Quando a fatura de egress supera o custo das H100

Vamos falar sobre o elefante na sala de reuniões do CFO: a fatura da AWS. Se você está treinando um LLM (Large Language Model) ou um modelo de visão computacional, seu dataset não é estático. Ele é um organismo vivo que precisa ser ciclado, transformado e alimentado nas GPUs repetidamente.

Na nuvem, armazenar os dados no S3 é barato (relativamente). O problema começa quando você tenta usar esses dados. Cada vez que seus nós de treinamento puxam dados de uma zona de disponibilidade diferente ou, Deus nos livre, de uma região diferente para garantir disponibilidade de GPU, o taxímetro do tráfego de rede dispara.

Em 2026, com clusters de treinamento exigindo checkpoints constantes de centenas de gigabytes a cada poucos minutos para mitigar falhas, o tráfego de rede "leste-oeste" (dentro do data center) e o tráfego de saída para sistemas de análise tornam-se astronômicos. Eu vi arquiteturas onde o custo de data transfer e operações de I/O (as temidas requisições GET/PUT) ultrapassou o custo de computação das instâncias p5.

⚠️ Perigo: Não subestime as taxas de "NAT Gateway" e "VPC Peering". Se seus dados de treinamento estão em um bucket S3 e suas instâncias de computação estão em uma sub-rede privada passando por um NAT Gateway gerenciado, você está pagando uma taxa extra por gigabyte apenas para mover dados dentro da mesma infraestrutura do provedor. É como pagar pedágio para ir da cozinha para a sala de estar.

A latência oculta no handshake do S3 e o gargalo do PCIe

O "Storage Infinito" da nuvem é, fundamentalmente, armazenamento de objetos acessado via API REST. Isso significa que, para ler um arquivo, seu sistema precisa abrir uma conexão HTTP, realizar um handshake TLS, enviar um cabeçalho, esperar o processamento do load balancer, esperar o backend do S3 localizar o objeto e começar a transmitir.

Para um humano carregando uma foto de gato, 50 milissegundos é instantâneo. Para uma GPU capaz de realizar quatrilhões de operações por segundo, 50 milissegundos é uma eternidade de ociosidade.

O problema se agrava com a serialização. O armazenamento em nuvem tradicional obriga os dados a passarem pela CPU do servidor (o host), serem serializados em pacotes de rede, viajarem pela fibra, serem desserializados pela CPU da instância de computação e, finalmente, copiados para a memória da GPU. Isso é o que chamamos de "CPU Bounce".

Fig. 1: A eliminação do 'CPU Bounce' na arquitetura CXL 3.1 reduz a latência em ordens de grandeza.

A latência de cauda (tail latency) no S3 é notória. Enquanto a média pode ser aceitável, os 1% das requisições mais lentas (o p99) podem travar todo o processo de treinamento síncrono, onde todas as GPUs devem esperar pela mais lenta antes de avançar para o próximo lote.

Por que o caching em FSx for Lustre é apenas um band-aid caro

A resposta padrão do seu arquiteto de soluções da nuvem para o problema de latência do S3 é: "Use o Amazon FSx for Lustre". E, tecnicamente, funciona. O Lustre é um sistema de arquivos paralelo fantástico.

Financeiramente, no entanto, é um desastre esperando para acontecer. O FSx for Lustre atua como uma camada de cache de alto desempenho na frente do S3. Você provisiona uma capacidade de armazenamento SSD rápida e cara. O problema é o dimensionamento.

Se o seu dataset de treinamento é de 500 TB, mas você só quer pagar por 50 TB de cache no FSx, você enfrentará o "cache thrashing". O sistema passará mais tempo despejando dados antigos e puxando dados novos do S3 (com latência alta) do que realmente alimentando as GPUs. Se você decidir colocar todos os 500 TB no FSx para garantir desempenho máximo, parabéns: você agora está pagando pelo armazenamento duas vezes (uma no S3 pela durabilidade, uma no FSx pela velocidade), a um preço por GB que faria um agiota corar.

💡 Dica Pro: Soluções de armazenamento efêmero local (NVMe Instance Store) nas instâncias de GPU são "gratuitas" (inclusas no preço), mas voláteis. Arquiteturas inteligentes em 2026 usam essas unidades como cache distribuído, usando ferramentas como o DAOS ou sistemas de arquivos definidos por software, evitando a "taxa de serviço gerenciado" do FSx.

Desagregando memória com CXL 3.1 em arquitetura híbrida

Aqui entra a verdadeira revolução de 2026, e o motivo pelo qual a repatriação de cargas de trabalho de IA está acelerando. O CXL (Compute Express Link) não é apenas um acrônimo novo para decorar; é a mudança fundamental na forma como conectamos armazenamento e computação.

O CXL 3.1 permite a coerência de cache e o compartilhamento de memória entre dispositivos. Em termos simples, ele permite que o armazenamento (agora na forma de SSDs habilitados para CXL ou módulos de memória expandida) seja endereçado diretamente pela CPU e, crucialmente, pelas GPUs, como se fosse memória RAM, não como um "disco" que exige drivers de sistema de arquivos e interrupções de CPU.

O fim da distinção entre RAM e Disco

Em um ambiente on-premise ou de colocation moderno, você pode construir um rack onde um pool de memória CXL é compartilhado entre vários servidores de GPU.

1. Sem cópia de rede: Os dados não precisam ser encapsulados em TCP/IP.

2. Sem intervenção da CPU: A GPU pode buscar dados diretamente do pool de memória via CXL (Direct Memory Access).

3. Latência de nanossegundos: Estamos falando de latências próximas às da DRAM, não de milissegundos de rede.

Isso é impossível na nuvem pública atual devido à arquitetura multi-tenant e à virtualização pesada. A nuvem vende vCPUs e vDisks; o CXL exige acesso físico ao barramento PCIe e à topologia de memória que os provedores de nuvem ainda lutam para expor de forma segura e econômica.

Reduzindo o idle time da GPU de 40% para zero com acesso direto

O custo mais alto em qualquer projeto de IA não é o armazenamento, é a ociosidade da GPU. Se você aluga um cluster de H100s e elas passam 40% do tempo esperando dados chegarem do S3 (o que chamamos de I/O Wait), você está queimando dinheiro.

Ao repatriar essa infraestrutura e utilizar arrays de armazenamento baseados em PCIe Gen 6 e CXL, eliminamos o gargalo de I/O.

Fig. 2: Arrays de armazenamento PCIe Gen 6 permitem densidade e velocidade que o EBS da nuvem não consegue entregar economicamente.

Neste cenário, o armazenamento deixa de ser um "lugar onde guardamos coisas" e passa a ser uma extensão ativa da memória da GPU. O conceito de "carregar dados" desaparece; os dados simplesmente estão lá, acessíveis via endereçamento de memória.

Isso permite:

• Checkpointing instantâneo: Salvar o estado do modelo em segundos, não minutos.

• Dataloading determinístico: Garantia de que a GPU terá o próximo lote de dados no exato momento em que terminar o cálculo anterior.

O argumento da repatriação: economia e física

Não sou um purista que diz "nunca use a nuvem". A nuvem é fantástica para elasticidade imprevisível. Mas o treinamento de IA é o oposto de imprevisível: é uma carga de trabalho constante, pesada e sustentada de 100% de utilização por semanas ou meses.

Alugar hardware na nuvem por longos períodos é como morar em um hotel de luxo: conveniente, mas financeiramente ruinoso a longo prazo. Construir um cluster dedicado (ou alugar bare metal em provedores especializados em IA que oferecem topologia CXL) reduz o custo total de propriedade (TCO) drasticamente.

Além disso, você elimina a "taxa de egress". Em seu próprio rack, mover 1 Petabyte do storage para a GPU custa zero dólares em taxas de transferência. Você paga apenas pela eletricidade e pela depreciação do cabo de fibra óptica.

O futuro é híbrido, mas o núcleo é físico

A falácia do "Storage Infinito" na nuvem é acreditar que a conveniência da API S3 supera as leis da física e da economia em escala. Para startups testando modelos pequenos, a nuvem continua sendo o caminho. Mas para empresas treinando modelos de fundação ou realizando fine-tuning pesado em 2026, a gravidade dos dados dita que o armazenamento deve estar fisicamente adjacente à computação, conectado por barramentos de cobre e silício (CXL/PCIe), não por protocolos HTTP e gateways de faturamento.

Se sua estratégia de IA para os próximos anos depende exclusivamente de buckets S3 e volumes EBS, prepare-se para explicar ao seu conselho por que sua margem de lucro está sendo devorada pela AWS, enquanto seus concorrentes com infraestrutura própria treinam modelos mais rápido e pela metade do preço. A nuvem é um ótimo lugar para visitar, mas você não vai querer manter seus dados de treinamento morando lá.

Referências & Leitura Complementar

• Compute Express Link (CXL) Consortium: CXL 3.1 Specification. Disponível em: computeexpresslink.org. Detalha os protocolos de coerência de memória e compartilhamento de recursos.

• SNIA (Storage Networking Industry Association): Computational Storage Architecture and Programming Model. Define padrões para processamento de dados próximo ao armazenamento.

• PCI-SIG: PCI Express 6.0 Specification. A base física para a largura de banda necessária para alimentar arquiteturas CXL modernas.

• JEDEC: DDR5 & HBM3 Standards. Essencial para entender o ecossistema de memória que o CXL visa expandir.

Perguntas Frequentes

1. O que é CXL e por que ele é importante para storage? O CXL (Compute Express Link) é um padrão de interconexão aberto que permite comunicação de alta velocidade e baixa latência entre a CPU e dispositivos (como aceleradores e memória). Para storage, ele permite que SSDs se comportem como memória RAM, reduzindo drasticamente a latência.

2. A repatriação de dados não aumenta a complexidade operacional? Sim, exige uma equipe de engenharia de infraestrutura competente. No entanto, em escalas de IA, a economia de milhões de dólares em taxas de nuvem paga facilmente os salários dessa equipe. Além disso, provedores de Bare Metal as a Service estão simplificando essa camada.

3. O S3 Express One Zone resolve o problema de latência? Ele melhora, mas não resolve. O S3 Express One Zone reduz a latência em comparação ao S3 Standard, mas ainda é um armazenamento de objetos acessado via rede, sujeito a overhead de protocolo e custos de API significativamente mais altos que o armazenamento local via PCIe/CXL.

4. O que é "Egress" e por que é tão caro? Egress é a taxa cobrada pelos provedores de nuvem quando seus dados saem da rede deles (para a internet ou para outro provedor). É uma margem de lucro altíssima para as nuvens e serve como uma barreira de saída (lock-in) para seus dados.