在 AI 領域里，大模型通常具有百億甚至數千億參數，訓練和推理過程對計算資源、存儲系統和數據訪問效率提出了極高要求。

2 月 28 日，DeepSeek 開源了一種高性能分布式文件系統 3FS，官方表示其目的是解決人工智能訓練和推理工作負載的挑戰。

作為一種并行文件系統，3FS 可以在 180 節點集群中實現 6.6 TiB/s 的聚合讀取吞吐量，對于提高 DeepSeek V3、R1 大模型的訓練數據預處理、數據集加載、檢查點保存/重新加載、嵌入向量搜索和 KVCache 查找等工作的效率有重要幫助。

人們認為，DeepSeek 通過開源 3FS 與 smallpond 等工具，在 AI 基礎設施領域樹立了新的設計范式。其價值不僅在展現技術實力，更是在驅動核心基礎設施創新。

DeepSeek 提出的文件系統是如何運作的，又能如何提高模型效率？最近，來自伊利諾伊大學厄巴納-香檳分校的在讀博士生 Henry Zhu 對 3FS 進行了解讀。

以下是博客原文： 

什么是 3FS？

3FS（Fire-Flyer File System）是 DeepSeek 在開源發布周期間發布的分布式文件系統，旨在充分利用現代固態硬盤（SSD）和遠程直接內存訪問（RDMA）網絡的全部帶寬，能夠加速和推動 DeepSeek 平臺上所有數據訪問操作。

本文將深入探討什么是分布式文件系統以及 3FS 的運作方式，首先介紹一些背景知識。

什么是分布式文件系統？

分布式文件系統會欺騙應用程序，使其以為它們正在對一個常規的本地文件系統進行通信。這種抽象非常強大：一個實際上分散在 10 臺不同機器上的文件，看起來就像一個簡單的文件路徑，例如 /3fs/stage/notes.txt。

使用分布式文件系統與使用本地文件系統并無二致。

在上圖中，我們通過運行 mkdir 和 cat 命令在本地和分布式文件系統上創建了相同的文件夾和文件，命令完全相同。使用分布式文件系統，所有這些細節都被抽象出來，用戶只需操作文件即可，無需擔心后臺涉及多少臺機器、有多少網絡調用或多少硬盤。

分布式文件系統的優勢

與本地存儲相比，分布式文件系統主要有兩大優勢：它們可以處理海量數據（高達 PB 級），并提供超越單機能力的高吞吐量。它具備容錯能力（即使一臺機器宕機，系統仍能繼續運行）和冗余能力（即使一個節點上的數據損壞，其他節點仍可獲得原始副本）。

分布式文件系統廣泛應用于許多實際應用：

• 并行處理框架（支持 Spark 的 HDFS）；
• 帶有數據加載器和 check point 的機器學習訓練流水線；
• 由 Google Colossus 支持的內部大型代碼/數據存儲庫；
• 旅行等行業應用；
• 照片存儲服務等業務。

深入了解 3FS

那么，DeepSeek 開源的 3FS 是如何工作的呢？

它的核心由四種主要節點類型組成：

3FS 中涉及的組件。

這些組件的作用各不相同：

1. Meta – 管理元數據：文件位置、屬性、路徑等；

2. Mgmtd – 管理服務器控制集群配置：其他節點在哪里、哪些節點處于活動狀態以及復制系數；

• 可以將其視為一個路由器，它知道每個節點的地址，并可以幫助節點相互查找。（類似的類比是 NAT hole 中使用的集中式服務器）

3. Storage – 保存物理磁盤上實際文件數據的節點；

4. Client – 與所有其他節點通信以查看和修改文件系統：

• 請求 Mgmtd 發現其他節點
• 請求 Meta 服務器執行文件操作（打開、統計、關閉、符號鏈接）
• 與存儲節點傳輸數據

現在讓我們更詳細地了解每個組件。

Mgmtd

Mgmtd 注冊

Mgmtd 跟蹤集群中正在運行的節點。存儲節點和元節點在啟動時會注冊，并定期發送心跳信號以確認它們仍然處于活動狀態。這提供了系統的集中視圖，可以立即識別哪些節點處于宕機狀態。

管理請求

節點無需與網絡中其他所有節點保持連接。相反，它們可以通過查詢管理節點來發現節點。雖然這會增加定位節點的額外往返次數，但由于節點發現并不靜態的，因此可以降低復雜性。

Mgmtd 鏈。

此外，Mgmtd 維護分布式算法中不同節點的配置。具體來說，復制鏈（CRAQ 是一種非常簡潔的算法，通過將節點視為鏈來實現強一致性和容錯性。）被建立，其節點作為配置存儲在 mgmtd 中。

Meta

Meta 概覽。

元節點比 mgmtd 稍微復雜一些。客戶端通過 RPC 調用與其通信。元服務器在元存儲上執行典型的文件系統操作（打開、創建、統計、取消鏈接）。文件元數據駐留在 inode 中，存儲大小、權限、所有者和時間戳等屬性。DirEntry 對象將路徑映射到 inode，單個文件可以有多個 DirEntry（類似于符號鏈接）。inode 和 DirEntry 都存儲在 FoundationDB 中。

有人可能想知道 founationdb 的鍵是什么樣的？inode：「INOD」+ inode id，dir entry：「DENT」+ nodeid + path，使用 transaction 進行冪等操作。會話管理器跟蹤打開的文件，并將文件會話存儲在 FoundationDB 中。如果客戶端斷開連接但未關閉文件，會話管理器將啟動文件同步。文件刪除請求排隊到垃圾收集器，垃圾收集器會在刪除目錄條目和 inode 之前從存儲節點中刪除數據。

Storage

存儲概覽。

存儲節點的主要功能是通過將數據分解成塊來管理物理存儲上的數據：

Rust 有一個名為 ChunkStore 的舊版塊管理器，是用 C++ 編寫的。我不太明白為什么是用 Rust，可能是因為它用起來很有趣，而且提供了更安全的保障，可以跟蹤磁盤存儲塊。

• Chunk 代表一塊物理磁盤，并跟蹤其元數據（ID、大小、磁盤偏移量、物理磁盤、校驗和、版本等）。這是所有其他結構用來跟蹤數據塊的最原始數據結構。
• Chunk 引擎不允許用戶直接與 Chunk 交互，因為這會增加引擎使用的復雜性。引擎接口提供了一些操作，為用戶提供了一種嚴格清晰的與引擎交互的方式（查找、分配、提交、元數據等）。
• 默認情況下，所有這些數據都存儲在 LevelDB 中，前綴字節表示操作類型（查詢元數據），并以 Chunk ID 作為鍵。

不同的 Worker 使用塊引擎來維護物理存儲

• AllocateWorker 在塊引擎中分配新的塊
• PunchHoleWorker 回收不再使用的塊
• AioReadWorker 處理對塊的讀取請求，并將讀取請求放入 io_uring 隊列，提交并等待完成

起初，我感到很驚訝。塊引擎并不對實際的物理磁盤執行操作，它實際上只管理元數據。這樣做的原因之一可能是為了讓 ChunkEngine 實現保持精簡，讓它只負責管理元數據。

存儲節點需要知道如何將寫入操作轉發到 CRAQ 鏈中的下一個目標。

目前，只需知道寫入操作需要轉發到其他節點即可。

• 目標由多個塊組成（可以將其視為包含不同塊的邏輯存儲）。
• 一個鏈由多個目標組成（通常跨越多個節點）。
• 存儲節點向 mgmtd 服務器查詢其他節點的鏈，以及該鏈中寫入操作需要轉發到的相應目標（節點）。

CRAQ

CRAQ（Chain Replication with Apportioned Queries）是一種實現強一致性和線性一致性的協議。它是確保數據塊容錯的核心機制。這里將解釋 CRAQ 的工作原理，并展示其在 3FS 中的實現。

Craq 寫入傳播。

寫入操作從頭部開始。在我們的示例中，我們將 name=henry 寫入系統。隨著寫入操作沿鏈向下移動，每個條目都會被標記為「臟」，并附帶一個版本號。臟條目不可安全讀取。一旦寫入操作到達尾部，它就會被提交并標記為「干凈」。

Craq 寫入提交。

隨著提交消息從尾部向頭反向傳播，寫入操作將變得干凈。每個節點提交該條目并將其標記為干凈。

Craq clean read

對于讀取來說，過程很簡單：如果對象是干凈的，則立即將其返回給客戶端。

Craq dirty read

挑戰發生在臟對象上。每個鏈都會跟蹤臟版本和干凈版本。由于尾部始終包含最新提交的數據，因此副本會查詢尾部以獲取最新提交的對象，從而確保強一致性。

CRAQ 性能

CRAQ 的讀寫性能因工作負載而異。寫入吞吐量和延遲受鏈中最慢節點的限制，因為寫入必須按順序處理每個節點。例如，在 Zipfian 工作負載（其中頻繁訪問的數據占主導地位）中，讀取性能會受到影響，因為對象可能很臟，從而迫使查詢到尾部節點。這會造成瓶頸，因為尾部必須處理大多數讀取請求。

如何在 3FS 中使用 CRAQ

存儲采用條帶化，CRAQ 在其上運行。

在本例中，集群由 5 個節點組成，每個節點配備 5 個 SSD。存儲目標復制到 3 個節點，旨在避免數據重疊，從而避免節點故障大幅影響整體吞吐量。

考慮一個極端場景，所有鏈都部署在節點 1、2、3 上。如果節點 1 發生故障，分布式系統將損失總吞吐量的 1/3，而不是上圖所示的 1/5。3FS 設計說明中提供了一個示例，并進行了更深入的解釋。CRAQ 在頂層運行，管理頭、中、尾節點。

3FS 默認采用強一致性讀取。寫入操作從頭到尾，再從頭到尾，吞吐量受最慢節點的限制，延遲由所有鏈節點的總延遲決定。          

不同復制協議比較表。

如上表所示，在常見情況下，與其他協議和系統相比，CRAQ 以高寫入延遲為代價，實現了可擴展的低延遲讀取。

其他分布式文件系統

這時候有人可能會問了：這種架構與其他分布式文件系統有什么不同？從高層次來看，這些組件很常見，幾乎每個分布式系統中都會出現客戶端、元數據、存儲和管理節點的概念。

區別在于其實際適用性和實際實現：

• 它擅長處理哪些工作負載
• 它的調優靈活性
• 部署簡便性
• 吞吐量擴展能力
• 在服務等級目標 (SLO) 內保持延遲
• 可靠性

以及決定其可用性的更精細的技術細節：

• 存在哪些瓶頸
• 如何管理瓶頸
• 它的鎖定方法（或不使用鎖定方法）
• 采用的具體數據結構
• 軟件設計所針對的硬件
• 使用哪種容錯算法或糾刪碼

考慮到這一點，我想深入分析一下這個相對較新的開源分布式文件系統的性能。分布式文件系統的開發具有挑戰性，目前的基準測試相當有限，我們也還沒有將 3FS 與單節點系統和其他分布式文件系統的比較，因此很難評估它的性能。

還有一些問題是值得探討的：

• DeepSeek 的一些說法是否成立，尤其是關于 FUSE 瓶頸的說法？
• 我們能以某種方式復現他們的性能圖嗎？
• 在什么情況下性能會下降？
• 系統的瓶頸是什么（CPU/內存/磁盤/網絡）？
• 這個文件系統在哪些類型的工作負載下表現優異？
• 與其他分布式文件系統相比如何？
• 它如何解決現有系統面臨的問題？
• 我能對系統進行一些改進嗎？

在本系列文章的其余部分中，作者將經歷做出初步假設、測試它們以及從差異中學習的過程，以更深入地了解 3FS 的實際表現。