DeepSeekのFire-Flyer File System

• Fire-Flyer File System(3FS) は、AIの学習および推論ワークロード向けに設計された高性能な分散ファイルシステムで、最新のSSDとRDMAネットワークを活用して共有ストレージ層を提供する
• 分離型アーキテクチャにより、数千台のSSDのスループットと数百台のストレージノードのネットワーク帯域幅を統合し、アプリケーションが配置を意識せずにストレージ資源へアクセスできるようにする
• 一貫性モデルは CRAQ(Chain Replication with Apportioned Queries) ベースの強整合性を提供し、メタデータサービスは FoundationDB のようなトランザクション型キー・バリューストアをバックエンドに利用するステートレス構成となっている
• 主なワークロードはデータ準備、データローダー、チェックポイント、推論向け KVCache であり、大規模クラスタの読み取りストレステストでは約 6.6 TiB/s の集約読み取りスループットを記録した
• ビルド時には過去の std::shuffle の使用に起因して、コンパイラのバージョンごとにバイナリ互換性の問題があるため、-DSHUFFLE_METHOD で g++10 または g++11 方式を明示し、クラスタ展開後も同じ設定を維持する必要がある

---

3FSが解決しようとする課題

• Fire-Flyer File System(3FS) は、AIの学習および推論ワークロードの要求に対応するために設計された高性能な分散ファイルシステムである
• 最新の SSD と RDMAネットワーク を活用し、分散アプリケーション開発を簡素化する共有ストレージ層を提供する
• ファイルインターフェースを提供するため、新しいストレージAPIを別途学ぶ必要がない

アーキテクチャと一貫性

• 分離型アーキテクチャ は、数千台のSSDのスループットと数百台のストレージノードのネットワーク帯域幅を統合する
  • アプリケーションは、ストレージ資源の配置を意識せずにアクセスできる
• 強整合性 は Chain Replication with Apportioned Queries(CRAQ) により実装される
  • アプリケーションコードを単純化し、推論しやすい構造を目指している
• メタデータサービスはステートレスに設計され、FoundationDB のような トランザクション型キー・バリューストア をバックエンドとして利用する

対応ワークロード

• データ準備

  • データ分析パイプラインの出力を階層型ディレクトリ構造として構成する
  • 大量の中間生成物を効率的に管理する

• データローダー

  • コンピュートノード全体から学習サンプルへランダムアクセスできるようにし、データセットのプリフェッチやシャッフルの必要をなくす

• チェックポイント

  • 大規模学習向けの高スループット並列チェックポイントをサポートする

• 推論向けKVCache

  • DRAMベースのキャッシュに対する費用対効果の高い代替手段として、より大きな容量と高いスループットを提供する

性能結果

• ピークスループット

  • 大規模な3FSクラスタの読み取りストレステストで、集約読み取りスループットは約 6.6 TiB/s に到達した
  • テストクラスタは 180 台のストレージノードで構成される
    • 各ストレージノードは 2×200Gbps の InfiniBand NIC と 16 台の 14TiB NVMe SSD を搭載する
    • 約 500 台以上のクライアントノードが使用された
    • 各クライアントノードは 1×200Gbps の InfiniBand NIC で構成される
  • 結果は、学習ジョブのバックグラウンドトラフィックが存在する状態で測定された
  • 3FS のベンチマークには fio 向けの USRBIO エンジンを利用できる

• GraySort

  • smallpond を GraySort ベンチマークとして評価した
  • 実装は 2 段階で構成される
    • キーの prefix bit を利用したシャッフルベースのデータパーティショニング
    • パーティション内ソート
  • 両段階とも 3FS からデータを読み込み、3FS にデータを書き込む
  • テストクラスタ構成:
    • 25 台のストレージノード
    • ノードごとに 2 つの NUMA ドメイン
    • NUMA ごとに 1 つのストレージサービス
    • ノードごとに 2×400Gbps NIC
    • 50 台のコンピュートノード
    • コンピュートノードは 2 つの NUMA ドメイン、192 個の物理コア、2.2TiB の RAM、ノードごとに 1×200Gbps NIC で構成される
  • 110.5TiB のデータを 8,192 個のパーティションにまたがってソートする処理は 30分14秒 で完了した
  • 平均スループットは 3.66 TiB/min である

• KVCache

  • KVCache は、LLM の推論過程で過去トークンの key/value ベクトルをデコーダ層にキャッシュし、重複計算を避ける手法である
  • KVCache クライアントはノードごとに 1×400Gbps NIC を使用する
  • 読み取りスループットはピーク時で 40 GiB/s に達した
  • 同期間に GC の削除処理 IOPS も測定された

ドキュメントとビルド

• 提供ドキュメント:
  • Design Notes
  • Setup Guide
  • USRBIO API Reference
  • P Specifications
• ソースコードは GitHub からクローンした後、サブモジュールを初期化してパッチを適用する
  • git submodule update --init --recursive
  • ./patches/apply.sh
• 対応依存関係のインストール例は次の環境を対象に提供されている
  • Ubuntu 20.04
  • Ubuntu 22.04
  • openEuler 2403sp1
  • OpenCloudOS 9
  • TencentOS 4
• 追加のビルド前提条件:
  • libfuse 3.16.1 以上
  • FoundationDB 7.1 以上
  • Rust toolchain 最低 1.75.0、推奨 1.85.0 以上または最新の安定版
• 3FS は build フォルダで CMake によりビルドする
  • C/C++ コンパイラの例は clang-14、clang++-14 である
  • ビルドタイプには RelWithDebInfo の例を使用する

• シャッフルアルゴリズム互換性

  • 過去に std::shuffle を使用していたため、g++10 と g++11+ など異なるコンパイラバージョンでビルドしたバイナリ同士は互換性がない可能性がある
  • ビルド時に -DSHUFFLE_METHOD を明示し、一貫したシャッフルアルゴリズムを固定する必要がある
  • 既存クラスタでは、以前の展開に使用したコンパイラバージョンに対応する方式を使う必要がある
  • 新規クラスタでは g++10 または g++11 のいずれかを選べるが、展開後の今後すべてのビルドで同じ設定を維持しなければならない
  • Docker ビルドイメージは TencentOS-4 と OpenCloudOS-9 向けに提供される
  • テストクラスタの実行は Setup Guide に従う
  • 問題は GitHub Issues に報告する