Fire-Flyer File System da DeepSeek

• Fire-Flyer File System (3FS) é um sistema de arquivos distribuído de alto desempenho para cargas de trabalho de treinamento e inferência de IA, que fornece uma camada de armazenamento compartilhado usando SSDs modernos e redes RDMA
• A arquitetura desagregada combina a vazão de milhares de SSDs com a largura de banda de rede de centenas de nós de armazenamento, permitindo que as aplicações acessem recursos de armazenamento sem se preocupar com sua localização
• O modelo de consistência oferece consistência forte baseada em CRAQ (Chain Replication with Apportioned Queries), e o serviço de metadados tem uma estrutura sem estado que usa como backend um armazenamento transacional de chave-valor, como o FoundationDB
• As principais cargas de trabalho são preparação de dados, data loader, checkpointing e KVCache para inferência; em um teste de estresse de leitura em cluster de grande escala, registrou cerca de 6,6 TiB/s de vazão agregada de leitura
• Na build, devido ao uso antigo de std::shuffle, há problemas de compatibilidade binária entre versões de compiladores; é preciso especificar o método g++10 ou g++11 com -DSHUFFLE_METHOD e manter a mesma configuração após a implantação do cluster

---

O problema que o 3FS tenta resolver

• Fire-Flyer File System (3FS) é um sistema de arquivos distribuído de alto desempenho projetado para atender aos requisitos de cargas de trabalho de treinamento e inferência de IA
• Usa SSDs modernos e redes RDMA para fornecer uma camada de armazenamento compartilhado que simplifica o desenvolvimento de aplicações distribuídas
• Como oferece uma interface de arquivos, não é necessário aprender uma nova API de armazenamento separada

Arquitetura e consistência

• A arquitetura desagregada combina a vazão de milhares de SSDs com a largura de banda de rede de centenas de nós de armazenamento
  • As aplicações podem acessar os recursos de armazenamento sem precisar conhecer sua localização
• A consistência forte é implementada com Chain Replication with Apportioned Queries (CRAQ)
  • O objetivo é tornar o código das aplicações mais simples e a estrutura mais fácil de raciocinar
• O serviço de metadados é projetado para ser sem estado e usa como backend um armazenamento transacional de chave-valor, como o FoundationDB

Cargas de trabalho suportadas

• Preparação de dados

  • Organiza a saída de pipelines de análise de dados em uma estrutura hierárquica de diretórios
  • Gerencia com eficiência grandes volumes de artefatos intermediários

• Data loader

  • Permite acesso aleatório a amostras de treinamento em todos os nós de computação, eliminando a necessidade de prefetch ou shuffle do dataset

• Checkpointing

  • Suporta checkpointing paralelo de alta vazão para treinamentos em grande escala

• KVCache para inferência

  • Oferece maior capacidade e alta vazão como uma alternativa mais econômica ao caching baseado em DRAM

Resultados de desempenho

• Vazão de pico

  • Em um teste de estresse de leitura em um cluster 3FS de grande escala, a vazão agregada de leitura chegou a cerca de 6,6 TiB/s
  • O cluster de teste era composto por 180 nós de armazenamento
    • Cada nó de armazenamento era equipado com 2 NICs InfiniBand de 200 Gbps e 16 SSDs NVMe de 14 TiB
    • Foram usados cerca de 500 ou mais nós clientes
    • Cada nó cliente era composto por 1 NIC InfiniBand de 200 Gbps
  • Os resultados foram medidos com tráfego em segundo plano de jobs de treinamento
  • O benchmark do 3FS pode usar o engine USRBIO para fio

• GraySort

  • O smallpond foi avaliado com o benchmark GraySort
  • A implementação é composta por duas etapas
    • Particionamento de dados baseado em shuffle usando os prefix bits da chave
    • Ordenação dentro das partições
  • Em ambas as etapas, os dados são lidos do 3FS e gravados no 3FS
  • Configuração do cluster de teste:
    • 25 nós de armazenamento
    • 2 domínios NUMA por nó
    • 1 serviço de armazenamento por NUMA
    • 2 NICs de 400 Gbps por nó
    • 50 nós de computação
    • Os nós de computação tinham 2 domínios NUMA, 192 núcleos físicos, 2,2 TiB de RAM e 1 NIC de 200 Gbps por nó
  • A tarefa de ordenar 110,5 TiB de dados em 8.192 partições foi concluída em 30 minutos e 14 segundos
  • A vazão média foi de 3,66 TiB/min

• KVCache

  • KVCache é uma técnica que, durante a inferência de LLMs, armazena em cache nos layers do decoder os vetores key/value dos tokens anteriores para evitar computação redundante
  • O cliente KVCache usa 1 NIC de 400 Gbps por nó
  • A vazão de leitura chegou a 40 GiB/s no pico
  • No mesmo período, também foram medidos os IOPS das operações de remoção do GC

Documentação e build

• Documentação fornecida:
  • Design Notes
  • Setup Guide
  • USRBIO API Reference
  • P Specifications
• Depois de clonar o código-fonte do GitHub, inicialize os submódulos e aplique os patches
  • git submodule update --init --recursive
  • ./patches/apply.sh
• Exemplos de instalação de dependências suportadas são fornecidos para os seguintes ambientes
  • Ubuntu 20.04
  • Ubuntu 22.04
  • openEuler 2403sp1
  • OpenCloudOS 9
  • TencentOS 4
• Pré-requisitos adicionais de build:
  • libfuse 3.16.1 ou superior
  • FoundationDB 7.1 ou superior
  • Rust toolchain mínima 1.75.0, recomendada 1.85.0 ou superior, ou a versão estável mais recente
• O 3FS é compilado com CMake na pasta build
  • Exemplos de compiladores C/C++ são clang-14 e clang++-14
  • O tipo de build usa RelWithDebInfo como exemplo

• Compatibilidade do algoritmo de shuffle

  • Devido ao uso antigo de std::shuffle, binários compilados com diferentes versões de compilador, como g++10 e g++11+, podem não ser compatíveis
  • Na build, é preciso especificar -DSHUFFLE_METHOD para fixar um algoritmo de shuffle consistente
  • Clusters existentes devem usar o método compatível com a versão do compilador usada na implantação anterior
  • Novos clusters podem escolher entre g++10 ou g++11, mas devem manter a mesma configuração em todas as builds futuras após a implantação
  • Imagens Docker de build são fornecidas para TencentOS-4 e OpenCloudOS-9
  • A execução do cluster de teste segue o Setup Guide
  • Issues devem ser reportadas no GitHub Issues