DeepSeek開源的檔案系統，是如何提升大模型效率的？

選自 maknee.github.io

作者：Henry Zhu

機器之心編譯

在 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 使用塊引擎來維護物理儲存