O sistema de arquivos Fire-Flyer da DeepSeek

Sistema de arquivos Fire-Flyer

O sistema de arquivos Fire-Flyer (3FS) é um sistema de arquivos distribuído de alto desempenho projetado para resolver problemas de workloads de treinamento e inferência em IA. Ele aproveita SSDs modernos e redes RDMA para fornecer uma camada de armazenamento compartilhado que simplifica o desenvolvimento de aplicações distribuídas.

Desempenho e usabilidade

• Arquitetura desagregada: combina a largura de banda de rede de milhares de SSDs e centenas de nós de armazenamento, permitindo que as aplicações acessem recursos de armazenamento sem depender de localidade.
• Consistência forte: implementa Chain Replication with Apportioned Queries (CRAQ) para fornecer consistência forte, tornando o código da aplicação mais simples e fácil de entender.
• Interface de arquivos: desenvolveu um serviço de metadados stateless baseado em um armazenamento transacional de chave-valor (por exemplo, FoundationDB). A interface de arquivos é amplamente conhecida e usada em todo lugar. Não é necessário aprender uma nova API de armazenamento.

Diferentes cargas de trabalho

• Preparação de dados: organiza a saída de pipelines de análise de dados em uma estrutura hierárquica de diretórios e gerencia com eficiência grandes volumes de saídas intermediárias.
• DataLoader: permite acesso aleatório às amostras de treinamento em todos os nós de computação, eliminando a necessidade de pré-carregar ou embaralhar o dataset.
• Checkpointing: oferece suporte a checkpointing paralelo de alta velocidade para treinamento em larga escala.
• KVCache for Inference: fornece uma alternativa econômica ao cache baseado em DRAM, com alta taxa de transferência e capacidade bastante grande.

Desempenho

1. Pico de throughput

• Em um teste de estresse de leitura em larga escala no cluster 3FS, alcançou um throughput agregado final de leitura de cerca de 6.6 TiB/s.

2. GraySort

• Foi avaliado usando o benchmark GraySort, que mede o desempenho de ordenação de grandes datasets. Foram necessários 30 minutos e 14 segundos para ordenar 110.5 TiB de dados em 8.192 partições, alcançando um throughput médio de 3.66 TiB/min.

3. KVCache

• Usa a tecnologia KVCache para otimizar o processo de inferência de LLM. Evita cálculos redundantes ao armazenar em cache os vetores de chave e valor de tokens anteriores das camadas decodificadoras. O throughput de pico chegou a até 40 GiB/s.

Documentação

• Notas de design
• Guia de configuração
• Referência da API USRBIO
• Especificação P

Ver código-fonte

• É possível verificar o código-fonte clonando o repositório 3FS no GitHub.

Relatar problemas

• Para relatar problemas, basta visitar a página de issues no GitHub.

[GN⁺]

Comentários do Hacker News

• Este design foi apresentado originalmente aqui: link

  • Este sistema de arquivos foi desenvolvido e usado por vários anos
  • É mais focado em treinamento de modelos em comparação com sistemas de arquivos tradicionais
  • Quando há muitas leituras aleatórias, cache de leitura e prefetch não são úteis
  • Para melhorar o desempenho, o sistema de arquivos foi projetado sem esses recursos

• O 3FS é usado em cenários de leitura em lote de dados de amostra em nós de computação durante o treinamento de IA

  • Acelera o treinamento de modelos por meio da interação entre computação de alta velocidade e armazenamento
  • É uma carga de trabalho de leitura aleatória em larga escala, e os dados lidos não são reutilizados em pouco tempo
  • Portanto, o "cache de leitura" não pode ser aproveitado, e a pré-leitura também não é útil
  • O 3FS tem uma implementação consideravelmente diferente de outros sistemas de arquivos

• O 3FS usa interfaces AIO baseadas em Linux e io_uring para concluir a leitura de amostras

  • O cache de arquivos não é nada eficaz e consome memória do sistema, afetando trabalhos posteriores
  • Ele desativa o cache de arquivos e lê os dados usando apenas o modo Direct I/O
  • É necessário alinhar ponteiros de buffer, offsets e comprimentos
  • Se o usuário fizer esse alinhamento, haverá cópia extra de memória, então o alinhamento é feito dentro do sistema de arquivos
  • Isso otimiza o desempenho e oferece conveniência ao usuário

• Uma das diferenças entre a Deepseek e OpenAI/Anthropic é a diferença entre profissionais práticos e acadêmicos

  • A OpenAI tem talentos de classe mundial, mas também há pessoas com pouca exposição técnica prática

• Sistemas de arquivos distribuídos são considerados um dos softwares mais difíceis de construir

  • Há o conselho de nunca escrever um sistema de arquivos do zero, nem mesmo sobre FUSE
  • Enquanto uma empresa do Vale do Silício faria sua 100ª reunião, uma equipe com menos de 60 pessoas desenvolveu um sistema de arquivos paralelo de alta eficiência

• Artigo de pesquisa relacionado: link

  • "Fire-Flyer AI-HPC: co-projeto de software e hardware com boa relação custo-benefício para deep learning"
  • Com o rápido avanço do deep learning e dos grandes modelos de linguagem, a demanda por capacidade computacional e largura de banda aumentou drasticamente
  • Apresenta a arquitetura Fire-Flyer AI-HPC para reduzir custos e consumo de energia
  • O HFReduce foi projetado para acelerar a comunicação allreduce
  • Foram implementadas várias medidas para evitar congestionamento na Computation-Storage Integrated Network

• Eu me perguntei como eles conseguem esse desempenho com um design baseado em FUSE

  • O FUSE é usado para gerenciar metadados, e para obter alto desempenho é necessário vincular uma biblioteca cliente em C++
  • Não é de uso geral, e é preciso modificar a aplicação
  • Ainda assim é uma abordagem inteligente, e fico me perguntando se a estratégia de LD_PRELOAD poderia ser generalizada

• OpenAI e outras também estão profundamente envolvidas em sistemas, mas é raro ver esse nível de capricho em outros lugares

  • Excelente trabalho, e espero que a Deepseek faça coisas ainda mais impressionantes no futuro

• Eles certamente são produtivos

  • O que veremos amanhã? Algo como um DeepSeek OS?

• Não está claro onde e como os sistemas populares atuais estão ficando aquém

  • Fico curioso sobre como os padrões de acesso a dados diferem dos casos de uso tradicionais

• Fico me perguntando se haveria vantagem em portar isso para um orquestrador como o K8s

  • Pode ser exagero para treinamento, mas o KVCache pode ser útil para inferência com múltiplas réplicas

• Gostaria de saber se alguém consegue me convencer de que isso não é síndrome de NIH

  • Por que usar isso em vez de SeaweedFS, Ceph ou MinIO?