A Amazon Web Services (AWS) apresentou em 25 de setembro de 2026 uma arquitetura que permite treinar modelos de IA de grande porte com as GPUs concentradas em uma região da nuvem e o conjunto de dados em outra, ou até em ambiente on-premises. A proposta combina o Amazon SageMaker HyperPod, serviço gerenciado de treinamento distribuído, com o Cloud Native Qumulo (CNQ) e o Cloud Data Fabric (CDF), da Qumulo.
Em vez de replicar petabytes entre regiões ou conviver com latência a cada leitura, a dupla usa cache preditivo para tornar o acesso remoto transparente ao treinamento.
O problema atacado é conhecido por quem treina modelos de fronteira. A capacidade de GPU disponível nem sempre está na mesma região em que os dados residem.
O acesso entre regiões adiciona latência de rede e custos de transferência.
As equipes ficam diante de duas alternativas ruins: copiar volumes imensos de dados de um lado para o outro ou aceitar throughput menor em cada leitura durante o treino.
Como a arquitetura funciona
A solução se organiza em três pilares. O primeiro é a fonte única de verdade: o dataset fica em uma única região, hospedado em uma instância Cloud Native Qumulo.
O segundo é o acesso entre regiões. Cada cluster HyperPod monta sua instância local de CNQ via Network File System (NFS), e o CNQ remoto (spoke) recupera os dados do hub por meio de VPC peering.
Ou seja, os nós de computação não fazem acesso direto entre regiões.
O terceiro pilar é a camada de posicionamento inteligente de dados. O Cloud Data Fabric expõe o mesmo dataset do hub para múltiplas instâncias spoke, inclusive em links de rede com mais de 100 ms de latência.
O componente central é o NeuralCache. Ele usa um modelo de IA para prever os próximos blocos de 4 KB que um job vai precisar, aprende o padrão de acesso do data loader e serve os dados a partir de NVMe local.
Na região spoke, desenvolvedores submetem jobs por um orquestrador Amazon Elastic Kubernetes Service (Amazon EKS), que os executa nos nós do HyperPod. O caminho de montagem é o mesmo nas duas regiões.
O teste entre ohio e oregon
A validação rodou o mesmo job de treinamento em dois clusters independentes. O cluster hub ficou na região Leste dos EUA (Ohio), us-east-2, co-localizado com os dados.
O cluster spoke ficou na região Oeste (Oregon), us-west-2, lendo remotamente pelo CDF com 60 ms de latência de rede. Depois de um breve aquecimento, o cluster remoto igualou o desempenho do cluster local: ambos sustentaram entre 115 e 117 amostras por segundo.
A convergência acontece nas primeiras 100 a 150 batches. Esse aquecimento é pontual e pouco relevante em escala: representa menos de 1% do tempo total em treinos com mais de 10 mil batches e menos de 0,1% acima de 100 mil batches.
A utilização de GPU fica entre 80% e 90% somente nessa fase inicial e depois se estabiliza entre 98% e 100%. Segundo a AWS e a Qumulo, nenhuma orquestração adicional de dados foi necessária para isso.
No cenário co-localizado, a arquitetura cloud-native do CNQ escala o desempenho de forma independente do tamanho do armazenamento. O resultado é 99% de utilização de GPU, saturação de rede nas instâncias p5.48xlarge e operações de dados abaixo de 3 ms.
Do lado da AWS, o SageMaker HyperPod entrega a infraestrutura gerenciada, com verificações de integridade automáticas, substituição de nós e recuperação de checkpoints.
O que isso muda na prática
Na prática, a combinação elimina a necessidade de copiar dados entre regiões ou reescrever código para treinar em outro local. Para organizações que têm cota de GPU em uma região diferente da exigida por residência de dados, ou que querem manter modelos de fronteira atualizados sem mover petabytes, a arquitetura oferece um caminho sem perda de throughput depois do warmup inicial.
A AWS e a Qumulo enquadram o resultado como uma forma de manter times de machine learning produtivos mesmo quando capacidade de computação e dados nascem separados. É um cenário cada vez mais comum conforme a demanda por GPUs se distribui de maneira desigual entre as regiões de nuvem.
