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

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

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

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

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

以下是博客原文： 

什么是 3FS？

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

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

什么是分布式文件系統(tǒng)？

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

使用分布式文件系統(tǒng)與使用本地文件系統(tǒng)并無二致。

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

分布式文件系統(tǒng)的優(yōu)勢

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

分布式文件系統(tǒng)廣泛應用于許多實際應用：

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

深入了解 3FS

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

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

3FS 中涉及的組件。

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

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

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

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

3. Storage – 保存物理磁盤上實際文件數(shù)據(jù)的節(jié)點；

4. Client – 與所有其他節(jié)點通信以查看和修改文件系統(tǒng)：

• 請求 Mgmtd 發(fā)現(xiàn)其他節(jié)點
• 請求 Meta 服務器執(zhí)行文件操作（打開、統(tǒng)計、關(guān)閉、符號鏈接）
• 與存儲節(jié)點傳輸數(shù)據(jù)

現(xiàn)在讓我們更詳細地了解每個組件。

Mgmtd

Mgmtd 注冊

Mgmtd 跟蹤集群中正在運行的節(jié)點。存儲節(jié)點和元節(jié)點在啟動時會注冊，并定期發(fā)送心跳信號以確認它們?nèi)匀惶幱诨顒訝顟B(tài)。這提供了系統(tǒng)的集中視圖，可以立即識別哪些節(jié)點處于宕機狀態(tài)。

管理請求

節(jié)點無需與網(wǎng)絡中其他所有節(jié)點保持連接。相反，它們可以通過查詢管理節(jié)點來發(fā)現(xiàn)節(jié)點。雖然這會增加定位節(jié)點的額外往返次數(shù)，但由于節(jié)點發(fā)現(xiàn)并不靜態(tài)的，因此可以降低復雜性。

Mgmtd 鏈。

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

Meta

Meta 概覽。

元節(jié)點比 mgmtd 稍微復雜一些?？蛻舳送ㄟ^ RPC 調(diào)用與其通信。元服務器在元存儲上執(zhí)行典型的文件系統(tǒng)操作（打開、創(chuàng)建、統(tǒng)計、取消鏈接）。文件元數(shù)據(jù)駐留在 inode 中，存儲大小、權(quán)限、所有者和時間戳等屬性。DirEntry 對象將路徑映射到 inode，單個文件可以有多個 DirEntry（類似于符號鏈接）。inode 和 DirEntry 都存儲在 FoundationDB 中。

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

Storage

存儲概覽。

存儲節(jié)點的主要功能是通過將數(shù)據(jù)分解成塊來管理物理存儲上的數(shù)據(jù)：

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

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

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

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

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

存儲節(jié)點需要知道如何將寫入操作轉(zhuǎn)發(fā)到 CRAQ 鏈中的下一個目標。

目前，只需知道寫入操作需要轉(zhuǎn)發(fā)到其他節(jié)點即可。

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

CRAQ

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

Craq 寫入傳播。

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

Craq 寫入提交。

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

Craq clean read

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

Craq dirty read

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

CRAQ 性能

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

如何在 3FS 中使用 CRAQ

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

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

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

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

不同復制協(xié)議比較表。

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

其他分布式文件系統(tǒng)

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

區(qū)別在于其實際適用性和實際實現(xiàn)：

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

以及決定其可用性的更精細的技術(shù)細節(jié)：

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

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

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

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

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