DeepSeeks Fire-Flyer-Dateisystem

 (github.com/deepseek-ai)
1 Punkte von GN⁺ 2025-03-01 | 1 Kommentare | Auf WhatsApp teilen

Fire-Flyer-Dateisystem

Das Fire-Flyer-Dateisystem (3FS) ist ein leistungsstarkes verteiltes Dateisystem, das zur Lösung der Herausforderungen von KI-Training und Inferenz-Workloads entwickelt wurde. Es nutzt moderne SSDs und RDMA-Netzwerke und bietet eine gemeinsam genutzte Storage-Schicht, die die Entwicklung verteilter Anwendungen vereinfacht.

Leistung und Benutzerfreundlichkeit

  • Entkoppelte Architektur: Bündelt die Netzwerkbandbreite von Tausenden von SSDs und Hunderten von Storage-Knoten, sodass Anwendungen unabhängig von der Lokalität auf Storage-Ressourcen zugreifen können.
  • Starke Konsistenz: Implementiert Chain Replication with Apportioned Queries (CRAQ) und bietet starke Konsistenz, wodurch Anwendungscode einfach und leicht verständlich bleibt.
  • Datei-Interface: Entwickelt einen zustandslosen Metadatenservice auf Basis eines transaktionalen Key-Value-Stores (z. B. FoundationDB). Das Datei-Interface ist weithin bekannt und überall einsetzbar. Es ist nicht nötig, eine neue Storage-API zu erlernen.

Verschiedene Workloads

  • Datenaufbereitung: Organisiert die Ausgaben von Datenanalyse-Pipelines in einer hierarchischen Verzeichnisstruktur und verwaltet große Mengen an Zwischenergebnissen effizient.
  • Data Loader: Ermöglicht wahlfreien Zugriff auf Trainingsbeispiele über Compute-Knoten hinweg, sodass kein Vorabladen oder Shuffling des Datensatzes erforderlich ist.
  • Checkpointing: Unterstützt schnelles paralleles Checkpointing für groß angelegtes Training.
  • KVCache for Inference: Bietet eine kosteneffiziente Alternative zu DRAM-basiertem Caching sowie hohen Durchsatz und eine beträchtlich große Kapazität.

Leistung

1. Spitzendurchsatz

  • In einem groß angelegten Lese-Stresstest des 3FS-Clusters wurde ein aggregierter Lesedurchsatz von etwa 6,6 TiB/s erreicht.

2. GraySort

  • Die Bewertung erfolgte mit dem GraySort-Benchmark, der die Sortierleistung großer Datensätze misst. Das Sortieren von 110,5 TiB Daten in 8.192 Partitionen dauerte 30 Minuten und 14 Sekunden, wobei ein durchschnittlicher Durchsatz von 3,66 TiB/Minute erreicht wurde.

3. KVCache

  • Zur Optimierung des LLM-Inferenzprozesses wird die KVCache-Technologie verwendet. Durch das Caching der Schlüssel- und Wertvektoren früherer Tokens in den Decoder-Layern werden redundante Berechnungen vermieden. Der Spitzendurchsatz erreichte bis zu 40 GiB/s.

Dokumentation

  • Design-Notizen
  • Konfigurationsleitfaden
  • USRBIO-API-Referenz
  • P-Spezifikation

Quellcode ansehen

  • Der Quellcode kann eingesehen werden, indem das 3FS-Repository auf GitHub geklont wird.

Problem melden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-01
Hacker-News-Kommentare

  • Dieses Design wurde ursprünglich hier vorgestellt: Link

    • Dieses Dateisystem wurde über mehrere Jahre entwickelt und eingesetzt
    • Im Vergleich zu traditionellen Dateisystemen ist es stärker auf das Modelltraining ausgerichtet
    • Bei vielen zufälligen Lesezugriffen sind Lesecache und Prefetching nutzlos
    • Zur Leistungssteigerung wurde das Dateisystem ohne diese Funktionen entworfen

  • 3FS wird während des AI-Trainings in Szenarien eingesetzt, in denen Rechenknoten Batch-Lesezugriffe auf Sample-Daten ausführen

    • Es beschleunigt das Modelltraining durch die Interaktion von Hochgeschwindigkeits-Compute und Storage
    • Es handelt sich um groß angelegte Random-Read-Workloads, und gelesene Daten werden in kurzer Zeit nicht erneut verwendet
    • Daher ist ein „Lesecache“ nicht nutzbar, und auch Vorauslesen ist nutzlos
    • 3FS unterscheidet sich in Implementierung und Aufbau deutlich von anderen Dateisystemen

  • 3FS verwendet Linux-basiertes AIO und die io_uring-Schnittstelle, um das Lesen der Samples abzuschließen

    • Der Dateicache ist überhaupt nicht wirksam und verbraucht Systemspeicher, was nachfolgende Aufgaben beeinträchtigt
    • Der Dateicache wird deaktiviert, und Daten werden nur im Direct-I/O-Modus gelesen
    • Buffer-Pointer, Offset und Länge müssen ausgerichtet werden
    • Wenn der Benutzer die Ausrichtung selbst vornimmt, entstehen zusätzliche Speicherkopien, daher wird die Ausrichtung innerhalb des Dateisystems durchgeführt
    • Das optimiert die Leistung und bietet den Benutzern mehr Komfort

  • Ein Unterschied zwischen Deepseek und OpenAI/Anthropic ist unter anderem der zwischen Praktikern und Akademikern

    • Bei OpenAI gibt es Talente von Weltniveau, aber auch Menschen mit wenig technischer Praxiserfahrung

  • Verteilte Dateisysteme gelten als eine der schwierigsten Softwarekategorien überhaupt

    • Man bekommt den Rat, kein Dateisystem von Grund auf neu zu schreiben, nicht einmal auf Basis von FUSE
    • Während ein Silicon-Valley-Unternehmen seine 100. Besprechung abhält, entwickelt ein Team mit weniger als 60 Personen ein hocheffizientes paralleles Dateisystem

  • Zugehörige Forschungsarbeit: Link

    • „Fire-Flyer AI-HPC: kosteneffizientes Software-Hardware-Co-Design für Deep Learning“
    • Durch die rasante Entwicklung von Deep Learning und großen Sprachmodellen sind der Bedarf an Rechenleistung und Bandbreite stark gestiegen
    • Es wird die Fire-Flyer-AI-HPC-Architektur vorgestellt, um Kosten und Energieverbrauch zu senken
    • HFReduce wurde entwickelt, um die Allreduce-Kommunikation zu beschleunigen
    • Es wurden mehrere Maßnahmen umgesetzt, um Staus im Computation-Storage Integrated Network zu vermeiden

  • Ich habe mich gefragt, wie man mit einem FUSE-basierten Design eine solche Leistung erzielen kann

    • FUSE wird zur Verwaltung der Metadaten verwendet, und für hohe Leistung muss eine C++-Client-Bibliothek angebunden werden
    • Es ist nicht für den allgemeinen Einsatz gedacht, und Anwendungen müssen angepasst werden
    • Trotzdem ist es ein cleverer Ansatz, und ich frage mich, ob sich die LD_PRELOAD-Strategie verallgemeinern lässt

  • Auch OpenAI und andere sind tief in ihre Systeme involviert, aber anderswo sieht man diese Art von Sorgfalt nur selten

    • Großartige Arbeit, und ich hoffe, dass Deepseek künftig noch beeindruckendere Dinge macht

  • Sie sind auf jeden Fall produktiv

    • Was werden wir morgen sehen? Etwas wie DeepSeek OS?

  • Es ist derzeit nicht klar, wo und wie populäre bestehende Systeme an ihre Grenzen stoßen

    • Ich frage mich, wie sich das Datenzugriffsmuster von traditionellen Anwendungsfällen unterscheidet

  • Ich frage mich, ob eine Portierung auf einen Orchestrator wie K8s Vorteile hätte

    • Für Training wäre das vielleicht übertrieben, aber KVCache könnte für Inferenz mit mehreren Replikaten nützlich sein

  • Ich frage mich, ob mich jemand überzeugen kann, dass es sich nicht um das NIH-Syndrom handelt

    • Ich frage mich, warum man das statt SeaweedFS, Ceph oder MinIO verwenden sollte