Como a Meta reestruturou seu armazenamento para otimizar workloads de IA em larga escala

O BLOB-storage é o sistema de armazenamento de objetos da Meta projetado para escalar em exabytes e servir workloads heterogêneos, desde feeds do Facebook até treinamento de modelos como Llama. Ele não é um banco de dados ou um filesystem tradicional, mas uma camada de abstração sobre o Tectonic, a infraestrutura de bloco regional que usa erasure coding, tiering entre HDD e flash e colocação inteligente de dados quentes/frios. O novo BLOB-storage para IA elimina o proxy de dados e substitui metadados espalhados por um esquema unificado no ZippyDB, permitindo lookup O(1) por chunk. Isso reduz latência crítica: em vez de centenas de milissegundos com múltiplas consultas cruzando regiões, agora o plano de leitura (ReadPlan) é resolvido em ~1, 2 ms, essencial para evitar stalls em GPUs sincronizadas.

A arquitetura atual opera em três níveis de cache: memória RAM dos hosts GPU (L1), SSD local ou próximo (L2) e o BLOB-storage regional em flash (L3). A hidratação sob demanda é acionada por prefetch explícito via SDK, não por heurística cega, mas por sinalização antecipada do dataloader sobre os próximos minutos de uso. Isso difere radicalmente de caches genéricos: aqui, o ciclo de vida dos dados (TTL, LRU, quota-aware eviction) é orquestrado pelo próprio workload de treino, não por políticas estáticas. A limitação real persiste: o sistema ainda depende da integridade do Tectonic como camada base; falhas nessa camada não são mascaradas, só mitigadas por hedged reads e controle dinâmico de concorrência no cliente.

Na cobertura anterior de abril e maio de 2026, a Meta já usava agentes de IA para otimizar performance de infraestrutura, mas como consumidores *externos* do BLOB-storage, não como parte de sua arquitetura. Agora, o BLOB-storage incorpora mecanismos nativos de IA-adjacentes: prefetch profundo com sinalização semântica do dataloader, cache de metadados com hit rate de 80%, e evicção adaptativa guiada por quotas. Antes, os agentes detectavam regressões *após* o fato; agora, o próprio BLOB-storage previne gargalos *em tempo de execução*, integrando lógica de hidratação e controle de tráfego diretamente no SDK. Também houve mudança estrutural: o antigo modelo global-padrão foi substituído por implantação regional por padrão, uma decisão técnica, não apenas operacional, alinhada à física da distribuição geográfica de GPUs.

Para desenvolvedores de ML, isso significa menos tempo esperando ingestão de dados e mais tempo ajustando hiperparâmetros. Um researcher que antes precisava copiar snapshots entre regiões por horas agora inicia treinos locais com dados acessíveis via SDK, mesmo que o blob esteja fisicamente em outro continente. Para engenheiros de infraestrutura, o BLOB-storage mostra que otimização de I/O para IA não é só sobre velocidade bruta: é sobre previsibilidade (pMax latência), eficiência energética (sem proxy = menos kW gastos em storage) e DX real (SDK com API explícita de prefetch, não só 'cache mágico'). E para quem constrói sistemas de larga escala, é um caso concreto de como reengenharia de metadados, não só de hardware, resolve bottlenecks críticos quando a carga muda de web requests para epochs de treino.