DeepSeeks Fire-Flyer File System

• Fire-Flyer File System (3FS) ist ein leistungsstarkes verteiltes Dateisystem für KI-Trainings- und Inferenz-Workloads, das moderne SSDs und RDMA-Netzwerke nutzt, um eine gemeinsame Storage-Schicht bereitzustellen
• Die disaggregierte Architektur kombiniert den Durchsatz von Tausenden SSDs mit der Netzwerkbandbreite von Hunderten Storage-Nodes, sodass Anwendungen ohne Kenntnis des Speicherorts auf Storage-Ressourcen zugreifen können
• Das Konsistenzmodell bietet starke Konsistenz auf Basis von CRAQ (Chain Replication with Apportioned Queries); der Metadatenservice ist zustandslos aufgebaut und nutzt einen transaktionalen Key-Value-Store wie FoundationDB als Backend
• Zu den wichtigsten Workloads gehören Datenvorbereitung, Dataloader, Checkpointing und KVCache für Inferenz; in einem Lese-Stresstest eines großen Clusters wurde ein aggregierter Lesedurchsatz von etwa 6,6 TiB/s erzielt
• Wegen der früheren Verwendung von std::shuffle kann es beim Build zu Problemen mit der binären Kompatibilität zwischen Compiler-Versionen kommen; daher muss mit -DSHUFFLE_METHOD explizit die Variante g++10 oder g++11 angegeben und nach der Cluster-Bereitstellung dieselbe Einstellung beibehalten werden

---

Welches Problem 3FS lösen will

• Fire-Flyer File System (3FS) ist ein leistungsstarkes verteiltes Dateisystem, das für die Anforderungen von KI-Trainings- und Inferenz-Workloads entwickelt wurde
• Es nutzt moderne SSDs und RDMA-Netzwerke, um eine gemeinsame Storage-Schicht bereitzustellen, die die Entwicklung verteilter Anwendungen vereinfacht
• Da es eine Dateischnittstelle bereitstellt, muss keine neue separate Storage-API erlernt werden

Architektur und Konsistenz

• Die disaggregierte Architektur kombiniert den Durchsatz von Tausenden SSDs mit der Netzwerkbandbreite von Hunderten Storage-Nodes
  • Anwendungen können auf Storage-Ressourcen zugreifen, ohne deren Standort kennen zu müssen
• Starke Konsistenz wird über Chain Replication with Apportioned Queries (CRAQ) umgesetzt
  • Ziel ist eine Struktur, die Anwendungscode vereinfacht und leichter nachvollziehbar macht
• Der Metadatenservice ist zustandslos konzipiert und nutzt einen transaktionalen Key-Value-Store wie FoundationDB als Backend

Unterstützte Workloads

• Datenvorbereitung

  • Die Ausgaben von Datenanalyse-Pipelines werden in einer hierarchischen Verzeichnisstruktur organisiert
  • Große Mengen an Zwischenartefakten werden effizient verwaltet

• Dataloader

  • Ermöglicht zufälligen Zugriff auf Trainings-Samples über Compute-Nodes hinweg und macht Dataset-Prefetching oder Shuffling überflüssig

• Checkpointing

  • Unterstützt paralleles Checkpointing mit hohem Durchsatz für groß angelegtes Training

• KVCache für Inferenz

  • Bietet als kosteneffiziente Alternative zu DRAM-basiertem Caching größere Kapazität und hohen Durchsatz

Performance-Ergebnisse

• Spitzendurchsatz

  • In einem Lese-Stresstest eines großen 3FS-Clusters erreichte der aggregierte Lesedurchsatz etwa 6,6 TiB/s
  • Der Testcluster bestand aus 180 Storage-Nodes
    • Jeder Storage-Node war mit 2×200-Gbps-InfiniBand-NICs und 16 NVMe-SSDs mit 14 TiB ausgestattet
    • Es wurden rund 500 oder mehr Client-Nodes verwendet
    • Jeder Client-Node war mit 1×200-Gbps-InfiniBand-NIC ausgestattet
  • Die Ergebnisse wurden bei vorhandenem Hintergrundtraffic durch Trainingsjobs gemessen
  • Für 3FS-Benchmarks kann die USRBIO-Engine für fio verwendet werden

• GraySort

  • smallpond wurde mit dem GraySort-Benchmark evaluiert
  • Die Implementierung besteht aus zwei Phasen
    • Shuffle-basierte Datenpartitionierung anhand der Prefix-Bits des Keys
    • Sortierung innerhalb der Partitionen
  • In beiden Phasen werden Daten aus 3FS gelesen und nach 3FS geschrieben
  • Konfiguration des Testclusters:
    • 25 Storage-Nodes
    • 2 NUMA-Domänen pro Node
    • 1 Storage-Service pro NUMA-Domäne
    • 2×400-Gbps-NICs pro Node
    • 50 Compute-Nodes
    • Die Compute-Nodes bestanden aus 2 NUMA-Domänen, 192 physischen Kernen, 2,2 TiB RAM und 1×200-Gbps-NIC pro Node
  • Eine Sortieraufgabe über 110,5 TiB Daten auf 8.192 Partitionen wurde in 30 Minuten 14 Sekunden abgeschlossen
  • Der durchschnittliche Durchsatz betrug 3,66 TiB/min

• KVCache

  • KVCache ist eine Technik, die während der LLM-Inferenz die Key/Value-Vektoren früherer Tokens in Decoder-Layern zwischenspeichert, um redundante Berechnungen zu vermeiden
  • KVCache-Clients verwenden 1×400-Gbps-NIC pro Node
  • Der Lesedurchsatz erreichte in der Spitze 40 GiB/s
  • Im selben Zeitraum wurden auch die IOPS der Löschvorgänge der GC gemessen

Dokumentation und Build

• Bereitgestellte Dokumente:
  • Design Notes
  • Setup Guide
  • USRBIO API Reference
  • P Specifications
• Der Quellcode wird von GitHub geklont; anschließend werden Submodule initialisiert und Patches angewendet
  • git submodule update --init --recursive
  • ./patches/apply.sh
• Beispiele zur Installation unterstützter Abhängigkeiten werden für folgende Umgebungen bereitgestellt
  • Ubuntu 20.04
  • Ubuntu 22.04
  • openEuler 2403sp1
  • OpenCloudOS 9
  • TencentOS 4
• Weitere Build-Voraussetzungen:
  • libfuse 3.16.1 oder höher
  • FoundationDB 7.1 oder höher
  • Rust-Toolchain mindestens 1.75.0, empfohlen 1.85.0 oder höher beziehungsweise die aktuelle stabile Version
• 3FS wird im Ordner build mit CMake gebaut
  • Beispiele für C/C++-Compiler sind clang-14 und clang++-14
  • Als Build-Typ wird im Beispiel RelWithDebInfo verwendet

• Kompatibilität des Shuffle-Algorithmus

  • Wegen der früheren Verwendung von std::shuffle können Binärdateien, die mit unterschiedlichen Compiler-Versionen wie g++10 und g++11+ gebaut wurden, inkompatibel sein
  • Beim Build muss -DSHUFFLE_METHOD angegeben werden, um einen konsistenten Shuffle-Algorithmus festzulegen
  • Bestehende Cluster müssen die Variante verwenden, die zur Compiler-Version der früheren Bereitstellung passt
  • Neue Cluster können zwischen g++10 und g++11 wählen, müssen nach der Bereitstellung aber bei allen künftigen Builds dieselbe Einstellung beibehalten
  • Docker-Build-Images werden für TencentOS-4 und OpenCloudOS-9 bereitgestellt
  • Zum Ausführen eines Testclusters folgt man dem Setup Guide
  • Issues werden über GitHub Issues gemeldet