Le système de fichiers Fire-Flyer de DeepSeek

• Fire-Flyer File System (3FS) est un système de fichiers distribué haute performance conçu pour les charges de travail d’entraînement et d’inférence en IA, qui s’appuie sur des SSD récents et des réseaux RDMA pour fournir une couche de stockage partagée
• Son architecture découplée combine le débit de milliers de SSD et la bande passante réseau de centaines de nœuds de stockage, afin que les applications puissent accéder aux ressources de stockage sans se soucier de leur emplacement
• Le modèle de cohérence fournit une cohérence forte basée sur CRAQ (Chain Replication with Apportioned Queries), et le service de métadonnées adopte une architecture sans état avec, en back-end, un magasin clé-valeur transactionnel comme FoundationDB
• Les principales charges de travail prises en charge sont la préparation des données, le data loader, le checkpointing et le KVCache pour l’inférence ; lors d’un test de stress en lecture sur un cluster à grande échelle, le système a atteint un débit agrégé d’environ 6.6 TiB/s
• Lors de la compilation, l’ancien usage de std::shuffle peut entraîner des problèmes de compatibilité binaire selon la version du compilateur ; il faut donc préciser la méthode g++10 ou g++11 via -DSHUFFLE_METHOD et conserver ce même réglage après le déploiement du cluster

---

Le problème que 3FS cherche à résoudre

• Fire-Flyer File System (3FS) est un système de fichiers distribué haute performance conçu pour répondre aux besoins des charges de travail d’entraînement et d’inférence en IA
• Il exploite des SSD modernes et des réseaux RDMA pour fournir une couche de stockage partagée qui simplifie le développement d’applications distribuées
• Comme il propose une interface de fichier, il n’est pas nécessaire d’apprendre une nouvelle API de stockage distincte

Architecture et cohérence

• L’architecture découplée combine le débit de milliers de SSD et la bande passante réseau de centaines de nœuds de stockage
  • Les applications peuvent accéder aux ressources de stockage sans avoir à connaître leur emplacement
• La cohérence forte est implémentée via Chain Replication with Apportioned Queries (CRAQ)
  • L’objectif est de simplifier le code applicatif et de rendre le système plus facile à raisonner
• Le service de métadonnées est conçu comme sans état et utilise en back-end un magasin clé-valeur transactionnel comme FoundationDB

Charges de travail prises en charge

• Préparation des données

  • Organise la sortie des pipelines d’analyse de données dans une structure de répertoires hiérarchique
  • Gère efficacement de grands volumes de résultats intermédiaires

• Data loader

  • Permet l’accès aléatoire aux échantillons d’entraînement à l’échelle des nœuds de calcul, supprimant le besoin de prélecture du dataset ou de shuffle

• Checkpointing

  • Prend en charge le checkpointing parallèle à haut débit pour l’entraînement à grande échelle

• KVCache pour l’inférence

  • Offre une alternative plus économique au cache basé sur la DRAM, avec une capacité supérieure et un débit plus élevé

Résultats de performance

• Débit de pointe

  • Lors d’un test de stress en lecture sur un grand cluster 3FS, le débit de lecture agrégé a atteint environ 6.6 TiB/s
  • Le cluster de test était composé de 180 nœuds de stockage
    • Chaque nœud de stockage était équipé de 2 NIC InfiniBand 200 Gbps et de 16 SSD NVMe de 14 TiB
    • Environ plus de 500 nœuds clients ont été utilisés
    • Chaque nœud client disposait d’1 NIC InfiniBand 200 Gbps
  • Les résultats ont été mesurés en présence du trafic de fond des tâches d’entraînement
  • Le benchmark 3FS peut utiliser le moteur USRBIO pour fio

• GraySort

  • smallpond a été évalué avec le benchmark GraySort
  • L’implémentation se compose de deux étapes
    • Partitionnement des données basé sur le shuffle à l’aide des bits de préfixe des clés
    • Tri à l’intérieur des partitions
  • Les deux étapes lisent les données depuis 3FS et les écrivent vers 3FS
  • Configuration du cluster de test :
    • 25 nœuds de stockage
    • 2 domaines NUMA par nœud
    • 1 service de stockage par NUMA
    • 2 NIC 400 Gbps par nœud
    • 50 nœuds de calcul
    • Les nœuds de calcul étaient composés de 2 domaines NUMA, 192 cœurs physiques, 2.2 TiB de RAM et 1 NIC 200 Gbps par nœud
  • Le tri de 110.5 TiB de données réparties sur 8,192 partitions a été achevé en 30 minutes et 14 secondes
  • Le débit moyen était de 3.66 TiB/min

• KVCache

  • Le KVCache est une technique utilisée lors de l’inférence LLM pour mettre en cache, dans les couches du décodeur, les vecteurs clé/valeur des tokens précédents afin d’éviter des calculs redondants
  • Le client KVCache utilise 1 NIC 400 Gbps par nœud
  • Le débit de lecture a atteint un pic de 40 GiB/s
  • Les IOPS des opérations d’élimination du GC ont aussi été mesurés sur la même période

Documentation et compilation

• Documentation fournie :
  • Design Notes
  • Setup Guide
  • USRBIO API Reference
  • P Specifications
• Le code source se clone depuis GitHub, puis il faut initialiser les sous-modules et appliquer les patchs
  • git submodule update --init --recursive
  • ./patches/apply.sh
• Des exemples d’installation des dépendances prises en charge sont fournis pour les environnements suivants
  • Ubuntu 20.04
  • Ubuntu 22.04
  • openEuler 2403sp1
  • OpenCloudOS 9
  • TencentOS 4
• Pré-requis supplémentaires pour la compilation :
  • libfuse 3.16.1 ou supérieur
  • FoundationDB 7.1 ou supérieur
  • Rust toolchain au minimum 1.75.0, recommandation 1.85.0 ou plus, ou la dernière version stable
• 3FS se compile avec CMake dans le dossier build
  • Les exemples de compilateurs C/C++ sont clang-14 et clang++-14
  • Le type de build utilisé en exemple est RelWithDebInfo

• Compatibilité de l’algorithme de shuffle

  • En raison de l’ancien usage de std::shuffle, des binaires compilés avec des versions de compilateur différentes, comme g++10 et g++11+, peuvent ne pas être compatibles entre eux
  • Il faut fixer un algorithme de shuffle cohérent à la compilation en précisant -DSHUFFLE_METHOD
  • Un cluster existant doit utiliser la méthode correspondant à la version du compilateur employée lors du déploiement précédent
  • Un nouveau cluster peut choisir g++10 ou g++11, mais doit conserver ce même réglage pour toutes les compilations futures après le déploiement
  • Des images Docker de build sont fournies pour TencentOS-4 et OpenCloudOS-9
  • L’exécution du cluster de test suit le Setup Guide
  • Les problèmes doivent être signalés via GitHub Issues