# 3FS(Fire-Flyer File System) DeepSeekが開発したオープンソースの分散ファイルシステム。AIワークロードが大量のランダム読み取りを発生させるという観察から生まれた。従来型のページキャッシュはこのランダム読み取りパターンに対して有効に機能せず、むしろカウンタープロダクティブ(逆効果)になりうるため、3FSはキャッシュを完全に排除し、すべての読み取り要求をNVMe SSDデバイスへ直接送るダイレクトI/O設計を採用する。この設計は、直接ストレージアクセスを優先する現代のHPCファイルシステムの潮流と合致し、NVIDIAの[[GPUDirect Storage]](GDS)が高性能並列ファイルシステムと連携して直接GPUスループットを実現するアプローチと軌を一にする(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]] §DeepSeek's Fire-Flyer File System)。 ## アーキテクチャ - 4つの主要コンポーネントで構成: クラスタマネージャ(cluster manager)・メタデータサービス(metadata service)・ストレージサービス(storage service)・クライアント(client)。これらはInfiniBandやRoCEのようなRDMA対応ファブリックで相互接続され、CPUの関与とホスト側コピーを最小化する。 - Linuxベースのファイルシステムとして実装され、既存アプリケーションとの互換性を保ちながらRDMA読み取りによる直接GPUアクセス可能なデータ転送を活用する。 - メタデータはスケールアウト性能のために複数ノードにシャーディング・複製される。データパスはOSのページキャッシュを完全にバイパスし、最適なスループットを維持する。 - FUSEでユーザー空間実装されたファイルシステムはGDSパスを提供できない(GDSはカーネルレベルのファイルシステム統合と`O_DIRECT`セマンティクスを要求するため)。3FSはRDMAベースの転送をDeepSeekの推論・学習パイプラインに直接統合することで、GDSと同種の「ホストメモリコピーを排除する」効果を、カーネル統合とは異なる経路で実現する。 - データ一貫性は**CRAQ**(Chain Replication with Apportioned Queries)アルゴリズムで保証する。1つのデータは複数の同一チャンクとしてチェーンを構成し、読み取り要求はチェーン内の任意のチャンクへ送信できる一方、書き込み要求は各チャンクへ順次実行される。あるチャンクが故障した場合、従来手法のように異常期間中の増分データで上書きするのではなく、まずそのチャンクをチェーンの末尾へ移動し、正常復帰した時点で他チャンクの全内容をコピーする。この設計は書き込みに一定の遅延を生む一方、LLM訓練でより重要な読み取り操作にはほぼ影響しない(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.2)。 - クラスタ設定データ・生データ・メタデータの3系統をそれぞれ独立に管理する: クラスタ設定データはキーバリュー形式でFoundationDBに、生データはSSD群へのCRAQで、メタデータはキーバリュー形式で別系統のFoundationDBに格納する(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.2, Fig. 7)。 - LLM訓練の文脈でファイルキャッシュがシステムメモリを大量消費しI/O性能を劣化させることを発見し、非同期データロードを採用してファイルキャッシュを無効化、Direct I/Oのみでデータアクセスすることでメモリ圧迫を大幅に軽減する。さらにバッファポインタ・オフセット・長さのシステムレベルアライメントを行い、ユーザー側アライメント操作による追加メモリコピーを回避する(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.2)。 ## 実測性能 - DeepSeekは大規模クラスタでの3FS集約読み取りスループットとして最大7.3TB/sを公にレポートしている。 - 別のベンチマークでは、68ノードのAI-HPCクラスタ(各ノード10×16TB NVMe SSD、デュアル100Gb/s)で集約読み取りスループット約6.6TB/sを達成し、これはバックグラウンドワークロードへ追加1.4TB/sを同時提供しながらの数値である。 - この6.6TB/sという3FSのスループットは、同等ハードウェア上のCephの約1.1TB/sを大幅に上回る。 ## 位置づけ 3FSは、ストレージ層そのものを再設計することでI/Oボトルネックの最後の部分を取り除けることを示す例であり、DeepSeekが示す「ストレージ設計を含むフルスタックの性能エンジニアリングが大規模AIシステムの性能を最大限引き出すために不可欠である」という主張の裏付けとなっている。ただし独自ファイルシステムの構築は多大な先行投資と継続的な保守を要する高度な技術であり、多くの実務では既存の分散ファイルシステムやオブジェクトストアから始めるのが現実的である(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]] §DeepSeek's Fire-Flyer File System)。 ## 関連 - [[GPUDirect Storage]] — ホストメモリコピー排除という設計思想を共有するが、カーネルレベル統合(GDS)対RDMA直接転送(3FS)という異なる経路を取る - [[GPUストレージIOデータパス]] — 3FSはGDSと並び、GPU向けストレージI/O最適化の代表的アプローチの一つ - [[NIXL]] — KVキャッシュ転送バックエンドの一つとしてHF3FSが位置づけられる(別ソースでの言及) - [[分散ファイルシステムとオブジェクトストア]] — 3FSはこのconceptが扱う分散ストレージシステムの代表例の一つ(JuiceFSと並ぶ) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]] — 本ページの一次ソース - [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] — CRAQによるデータ一貫性保証・3系統ストレージ構成(FoundationDB×2 + SSD群)の詳細を追加した二次ソース ## 出典 - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]](§DeepSeek's Fire-Flyer File System) - [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]](§2.4.2 Data Distribution: CRAQアルゴリズムによるチェーンレプリケーション・ファイルキャッシュ無効化とDirect I/O・Fig. 7 ストレージアーキテクチャ図)