Treino multi-Region no HyperPod: como o cache da Qumulo esconde 60 ms

Quem já caçou capacidade de ml.p5.48xlarge sabe que ela não espera decisão de comitê. O HyperPod está disponível em 18 Regions, mas a fila de H100 não é uniforme — a capacidade aparece onde aparece, e o dataset de pré-treino, com dezenas ou centenas de terabytes, ficou na Region onde o pipeline de dados o construiu.

Até aqui, as duas saídas conhecidas eram ruins de formas diferentes. Replicar o dataset: copiar petabytes entre Regions paga transferência por GB, dobra o custo de armazenamento e — o custo que ninguém orça — cria duas verdades para manter sincronizadas por toda a vida do projeto. Ler remoto sem cache: cada leitura NFS atravessa 60 ms de RTT, o data loader não alimenta a GPU no ritmo, e você paga hora de H100 para vê-la esperar I/O.

A proposta validada no post é a terceira via: o dataset fica em us-east-2 num hub Cloud Native Qumulo, e um spoke em us-west-2 expõe o mesmo filesystem ao cluster de treino via NFS, com o Cloud Data Fabric replicando metadados em segundos e o NeuralCache — o motor de prefetch preditivo — trazendo os blocos antes de o job pedir. Sem cópia prévia, sem mudança de código: o PyTorchJob monta um PV ReadWriteMany de 50 Ti como se o dado fosse local.

O Cloud Data Fabric não replica o dado — replica o metadado do filesystem para o spoke em segundos, com consistência estrita entre as pontas. A leitura é servida pela fonte válida mais próxima: hit no NVMe local do spoke, miss vai ao hub pelo peering. O protocolo de transporte entre portais usa controle de congestionamento por pacing, não por perda — a Qumulo declara throughput próximo de line-rate em caminhos de até 900 ms de RTT, o que torna os 60 ms entre Ohio e Oregon um caso confortável.

O NeuralCache é a peça que muda a equação: ele observa as leituras sequenciais de blocos de 4 KB que o data loader emite e aprende o padrão de acesso — treino de LLM é um dos workloads mais previsíveis que existem, o loader varre o dataset tokenizado em ordem com prefetch_factor=4 e 256 batches em voo. Com o padrão aprendido, o cache busca os blocos antes do pedido e atinge 94–96% de hit rate, servindo do NVMe local em menos de 5 ms.

A convergência tem fases medidas: nos batches 0–100, cada leitura paga os 60 ms e a utilização de GPU cai para 80–90%; entre os batches 100 e 150, a latência despenca para 5–10 ms; dali em diante o spoke opera igual ao hub, com GPU acima de 98%. O warmup não é configurável — é aprendizado, e o preço dele aparece uma vez por padrão de acesso.

O desenho experimental é honesto no que se propõe: o mesmo job — LLaMA v3 de 1,02 bilhão de parâmetros sobre o C4 tokenizado em janelas de 4.096 tokens, 48,4 milhões de sequências, batch 24 por GPU, PyTorch 2.1 com FSDP — rodou de forma independente nos dois clusters, cada um com 2× ml.p5.48xlarge orquestrados por EKS via Kubeflow PyTorchJob. Hub: 116–117 samples/s e 18,5 minutos para 999 batches. Spoke com cache quente: 115–116 samples/s, mesmos 18,5 minutos, GPU acima de 99% desde o primeiro batch. Empate técnico, medido — não prometido.

Dito isso, o que o benchmark não cobre importa tanto quanto o que cobre. São 2 nós por cluster — 16 GPUs lendo 1,0–1,3 GBps; nada garante que 32 nós disputando o mesmo hub de 4× r5.8xlarge mantenham a curva, e o CNQ escala performance de forma independente do armazenamento justamente porque vai precisar. O workload é leitura sequencial pura — o caso ideal para um prefetch preditivo. E o caminho de escrita ficou de fora: checkpoints de FSDP são rajadas de escrita pesadas, e o post não mede o que acontece quando elas atravessam o fabric. A extrapolação de 0,08% de impacto em 100 mil batches assume um único warmup — verdadeiro enquanto o padrão de acesso não mudar no meio do treino.

A rede tem letras miúdas: peering inter-Region opera com MTU de 8.500 bytes — não os 9.001 do intra-Region — e não é transitivo: cada par hub-spoke exige uma conexão própria, então três spokes viram três peerings e três pares de route tables com CIDRs que não podem se sobrepor. O NFS atravessa em TCP 2049, liberado por security group entre as VPCs, e o tráfego inter-Region do peering é cifrado em trânsito pela própria AWS — sem VPN para operar.

Hub fora do ar é o modo de falha estrutural: o spoke serve hits do cache local, mas os 4–6% de misses dependem do hub — indisponibilidade em us-east-2 degrada o treino remoto em minutos, não em horas. O peering permanece Active mesmo quando um evento regional impede o tráfego; a detecção é sua, não da AWS.

Custo é dominado pelo miss: transferência inter-Region é cobrada por GB nos dois sentidos do peering, e a conta boa é exatamente o hit rate — a 94–96%, você paga a travessia do dataset aproximadamente uma vez (warmup) mais a fração residual, contra pagar a cópia integral e a duplicação de storage na replicação clássica. A Qumulo declara redução de mais de 30% em tráfego WAN e egress com o prefetch agregando leituras.

Observabilidade mínima: hit rate do cache, utilização de GPU e samples/s contam a mesma história por ângulos diferentes — GPU caindo de 98% para 85% sem mudança de código é o cache perdendo o padrão.