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

A AWS e a Qumulo publicaram uma validação de treino com o compute em `us-west-2` e o dataset em `us-east-2`, separados por 60 ms de RTT — e o cluster remoto empatou com o co-localizado depois de 100–150 batches de warmup. Fui atrás do mecanismo: metadados replicados em segundos, prefetch preditivo sobre leitura sequencial de 4 KB e um caminho de rede com limites bem concretos. O resultado é real, mas vale sob condições específicas — e são elas que este artigo destrincha.

- URL: https://fernando.moretes.com/blog/treino-multi-region-no-hyperpod-como-o-cache-da-qumulo-esconde-60-ms

- Markdown: https://fernando.moretes.com/blog/treino-multi-region-no-hyperpod-como-o-cache-da-qumulo-esconde-60-ms/article.md?lang=pt

- Published: 2026-09-29T10:15:07.016Z

- Category: IA & Agentes

- Tags: sagemaker-hyperpod, multi-region, treinamento-distribuido, storage, networking, finops, qumulo

- Reading time: 6 min

- Source: [Multi-Region training with Amazon SageMaker HyperPod and Qumulo](https://aws.amazon.com/blogs/machine-learning/multi-region-training-with-amazon-sagemaker-hyperpod-and-qumulo/)

---

Depois de 16 anos operando plataformas sobre AWS, aprendi que capacidade de GPU e dado de treino raramente moram na mesma Region — e a pergunta que importa não é 'dá para treinar longe do dado?', é 'quanto custa cada batch enquanto o cache não converge?'. A validação publicada pela AWS com SageMaker HyperPod e Cloud Native Qumulo responde com número: um cluster em `us-west-2` lendo de `us-east-2` a 60 ms de RTT empatou com o cluster co-localizado — 115–116 contra 116–117 samples/s — depois de um warmup de 100 a 150 batches. Este artigo destrincha o mecanismo, os modos de falha e as condições em que esse resultado se sustenta.

## O problema real: GPU onde aparece, dado onde ficou

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 caminho do batch: hit local, miss cruza a Region, prefetch corre na frente

Fluxo de leitura do treino cross-Region validado no post — o compute em `us-west-2`, o dado em `us-east-2`, e o NeuralCache convertendo 60 ms de RTT em sub-5 ms locais.

### 🟧 AWS — us-west-2 (spoke, treino)

- PyTorchJob FSDP 2× ml.p5.48xlarge (16 H100) (compute)
- Data loader 64 workers, prefetch_factor=4 (compute)
- CNQ spoke NeuralCache em NVMe local (storage)

### 📡 Rede — inter-Region

- VPC peering 60 ms RTT · MTU 8500 (network)

### 🟧 AWS — us-east-2 (hub, dados)

- CNQ hub (4× r5.8xlarge) C4 tokenizado, PV 50 Ti (storage)
- HyperPod hub baseline co-localizado (compute)

### Fluxos

- loader -> gpu: batches 24 × 4.096 tokens
- loader -> spoke: NFSv3 — blocos de 4 KB
- spoke -> peer: miss (4–6% após warmup)
- peer -> hub: leitura remota TCP 2049
- hub -> spoke: prefetch preditivo + metadados em segundos
- hubgpu -> hub: baseline: 116–117 samples/s

## Como o mecanismo funciona de verdade

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.

## Os números da validação

- **94–96%** — hit rate do NeuralCache após warmup. Leituras servidas do NVMe local em sub-5 ms — só 4–6% cruzam a Region
- **60 ms** — RTT entre us-east-2 e us-west-2. Pago integralmente nos batches 0–100; invisível após a convergência
- **0,08%** — impacto do cold start num treino de 100 mil batches. Extrapolação do post: 0,81% em 10 mil batches, 0,008% em 1 milhão

## O benchmark sob escrutínio: o que foi medido e o que não foi

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.

> **O que realmente sustenta o resultado:** O empate de throughput não vem de rede mágica — vem do fato de que data loading de treino é um dos padrões de I/O mais previsíveis da computação. O loader varre sequências tokenizadas em ordem, em blocos de 4 KB, com 256 batches de antecedência declarada no próprio código. Qualquer cache preditivo decente acerta esse padrão; o mérito do NeuralCache é acertá-lo através de 60 ms de WAN sem estrangular o pipeline. A implicação é a contrapositiva: workload de acesso aleatório — fine-tuning com shuffling agressivo por época, feature store, leitura esparsa — não herda nada desses números.

## Modos de falha e limites do caminho de rede

**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.

## Anti-padrões

- **Replicar petabytes 'por garantia'**: duplicar o dataset entre Regions antes de medir o cache paga transferência integral, dobra o storage e cria duas verdades para sincronizar por anos — o custo que importa não é o da cópia — é o de manter as cópias honestas.
- **Estender os números a acesso aleatório**: os 94–96% de hit rate foram medidos sobre varredura sequencial de 4 KB; shuffling agressivo por época ou leitura esparsa derruba o prefetch e devolve os 60 ms a cada miss — meça com o seu loader antes de comprometer o cronograma.
- **Ignorar o caminho de escrita**: o benchmark mede leitura; checkpoints de FSDP são rajadas de escrita que o post não valida cross-Region — grave checkpoints em storage local à Region do compute (ou S3 na mesma Region) até medir o contrário.
- **Tratar o hub como dependência invisível**: sem alarme no hit rate e na utilização de GPU, uma degradação do hub em `us-east-2` aparece primeiro como treino lento em `us-west-2` — e o peering seguirá marcado `Active` enquanto isso.

## Pelas lentes do Well-Architected

- **security**: Peering inter-Region cifra o tráfego em trânsito e mantém tudo em IP privado; a superfície a governar é o security group liberando `TCP 2049` só entre os CIDRs das duas VPCs — e a consciência de que NFSv3 com `nolock` não carrega autenticação por si.
- **reliability**: O hub é ponto único para os misses: um spoke sobrevive a degradação parcial servindo hits, mas não a um hub fora do ar. Trate a saúde do hub e do peering como parte do SLO do treino — e lembre que o estado `Active` do peering não atesta tráfego fluindo.

> **Nota do curador:** Eu adotaria essa arquitetura hoje num cenário específico: capacidade de GPU garantida numa Region que não é a do dado, treino longo o suficiente para diluir o warmup, e leitura sequencial dominante. Antes de comprometer cronograma, eu rodaria exatamente o que o post rodou — o mesmo job nas duas pontas, 999 batches, comparando samples/s e utilização de GPU — porque benchmark de fornecedor se reproduz, não se herda. E instrumentaria o hit rate desde o primeiro dia: a lição dura de anos operando storage distribuído é que cache que degrada em silêncio vira incidente com nome de outra coisa — no caso, 'o treino ficou lento' três camadas acima de onde o problema mora.

## Veredito

Use HyperPod com CNQ e Cloud Data Fabric quando: a capacidade de GPU que você conseguiu está numa Region diferente do dataset, o treino tem dezenas de milhares de batches para amortizar o warmup, e o acesso é leitura sequencial de data loader. Fique na co-localização (ou em FSx for Lustre com o dado na mesma Region) quando: o job é curto, o padrão de acesso é aleatório, ou o caminho de escrita cross-Region é parte crítica do pipeline — nada disso foi validado. O resultado central é sólido no seu recorte: 60 ms de RTT viram custo de warmup de 0,08% num treino de produção, e isso muda a pergunta de 'onde está o dado?' para 'onde tem GPU?'. Mas a validação tem 2 nós por cluster e mede só leitura — trate os números como piso a reproduzir, não como teto contratado.

**Rating:** adopt-with-conditions

## Referências

- [Multi-Region training with Amazon SageMaker HyperPod and Qumulo (AWS ML Blog, 25/09/2026)](https://aws.amazon.com/blogs/machine-learning/multi-region-training-with-amazon-sagemaker-hyperpod-and-qumulo/)
- [Amazon SageMaker HyperPod — Developer Guide](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod.html)
- [How VPC peering connections work (MTU inter-Region, limites e lifecycle)](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html)
- [Qumulo NeuralCache — predictive caching engine](https://qumulo.com/product/neural-cache/)
- [Qumulo Cloud Data Fabric — hub/spoke e consistência estrita](https://qumulo.com/product/cloud-data-fabric)