【新智元導讀】DeepSeek最後一天，送上了3FS檔案平行系統，以及資料處理框架Smallpond。五天開源連更，終於畫上了完美的句號。

最後一天，DeepSeek開源了全生命周期資料訪問引擎Fire-Flyer File System（3FS），以及基於3FS的資料處理框架Smallpond。

3FS（螢火蟲檔案系統）是一個充分利用現代SSD和RDMA網路頻寬的平行檔案系統，其特點是：

• 在180節點叢集中實現了6.6 TiB/s的總讀取吞吐量
• 在25節點叢集的GraySort基準測試中達到了3.66 TiB/min 的吞吐量
• 每個客戶端節點的KVCache查詢峰值吞吐量超過40+ GiB/s
• 採用分離式架構，確保了強一致性
• 全面支援V3/R1的訓練資料預處理、資料集載入、檢查點保存/多載、嵌入向量搜尋和KVCache查詢推理

Smallpond是輕量級的資料處理框架，其特點是：

• 基於DuckDB的高性能資料處理
• 可擴展性，能夠處理PB等級資料集
• 無需持續運行的服務，操作簡便

3FS和Smallpond兩大開放原始碼專案，正在為AI資料處理設立新的標準——超快的處理速度和無縫整合。

讓許多人驚嘆不已的是，DeepSeek竟自己編寫了分佈式檔案系統。

它的成功背後強大得理念，便是將小事做到極致。這種精神，體現了車庫駭客的精髓。

3FS檔案系統

The Fire-Flyer File System（3FS）專為應對人工智慧訓練和推理任務挑戰而設計的高性能分佈式檔案系統。

項目連結：https://github.com/deepseek-ai/3FS

它採用現代固態硬碟（SSD）和遠端直接記憶體訪問（RDMA）網路技術，建構了共享儲存層，極大簡化了分佈式應用的開發過程。

核心優勢

• 性能與易用性
• 分佈式架構：該系統整合了數千個SSD的高吞吐量和數百個儲存節點的網路頻寬，使得應用程式能夠無視位置差異，高效訪問儲存資源。
• 強一致性保證：通過採用鏈式複製與分配查詢（CRAQ）技術，確保了資料的一致性，使得應用程式程式碼更加簡潔易懂。
• 標準檔案介面：系統提供了基於事務性鍵值儲存（如FoundationDB）的無狀態中繼資料服務，使用的檔案介面通用且易於上手，無需學習新的儲存API。
• 多樣化工作負載支援
• 資料準備：系統有效地將資料分析管道的輸出組織成分層目錄結構，並高效管理大量的中間資料。
• 資料載入最佳化：通過支援計算節點間對訓練樣本的隨機訪問，無需進行資料預取或洗牌操作，提升了資料處理效率。
• 高效檢查點支援：為大規模訓練任務提供高吞吐量的平行檢查點功能。
• KVCache推理加速：提供了一種成本效益高的DRAM快取替代方案，具有高吞吐量和更大的儲存容量，適用於推理任務。

性能

1. 最大吞吐量

下圖展示了一個大型3FS叢集在執行讀壓力測試時的吞吐量表現。

該叢集包含180個儲存節點，每個節點均組態有2張200Gbps的IB網路卡和16塊14TiB的NVMe固態硬碟。

測試中使用了約500個客戶端節點，每個節點配備1張200Gbps的IB網路卡。

在存在訓練任務背景流量的情況下，叢集的總讀取吞吐量達到了約6.6TiB/s。

2. GraySort

採用GraySort基準測試，評估smallpond在處理大規模資料集時的排序能力。

實現採用了兩階段的處理方法：(1) 首先通過鍵的前綴位進行資料重排來分區資料，(2) 然後在各個分區內部進行排序。這兩個階段的資料讀寫都依賴於3FS。

測試所用的叢集包括25個儲存節點（每個節點有2個NUMA域，每個NUMA域運行1個儲存服務，每個節點配備2×400Gbps網路卡）和50個計算節點（每個節點有2個NUMA域，192個物理核心，2.2 TiB記憶體，每個節點配備1×200 Gbps網路卡）。

在8,192個分區中排序110.5 TiB的資料，整個過程耗時30分鐘14秒，平均吞吐量達到3.66TiB/min。

3. KVCache

KVCache是一種用於提升大型語言模型（LLM）推理效率的技術。

它通過快取解碼器層中先前token的鍵和值向量，避免了重複的計算過程。

頂部圖表展示了所有KVCache客戶端的讀取吞吐量，其中既包括了峰值也包括了平均值，峰值吞吐量可達40GiB/s。

底部圖表則展示了在同一時間段內，垃圾收集（GC）過程中操作次數的變化情況。

設計與實現

3FS系統由四個主要部分組成：叢集管理器、中繼資料服務、儲存服務和客戶端。這些元件通過RDMA網路（InfiniBand或RoCE）相互連接。

中繼資料和儲存服務定期向叢集管理器傳送心跳訊號，以報告其狀態。叢集管理器負責處理叢集成員的變更，並將叢集的組態資訊分發到其他服務和客戶端。

系統中部署了多個叢集管理器，其中一個被選為主管理器。當主管理器發生故障時，另一個管理器會被提升為主管理器。

叢集組態資訊通常儲存在一個可靠的分佈式協調服務中，例如ZooKeeper或etcd。在生產環境中，為了減少依賴性，我們使用與檔案中繼資料相同的鍵值儲存來保存叢集組態。

檔案中繼資料操作（如打開或建立檔案/目錄）被傳送到中繼資料服務，由其實現檔案系統的語義。由於檔案中繼資料是儲存在一個事務性鍵值儲存（例如FoundationDB）中的，因此中繼資料服務是無狀態的，客戶端可以連接到任何中繼資料服務。

每個儲存服務管理一些本地SSD，並提供一個塊儲存介面。

為了確保強一致性，儲存服務實現了鏈式複製與分配查詢（CRAQ）機制。CRAQ的寫入全部讀取任意的方法有助於充分利用SSD和RDMA網路的高吞吐量。在3FS中，一個檔案被分割成相等大小的資料區塊，並在多個SSD上複製。

使用

使用以下命令從GitHub克隆3FS倉庫到本地檔案系統：

git clone https://github.com/deepseek-ai/3fs

克隆完成後，進入3FS目錄，運行以下命令來更新並初始化所有子模組：

cd 3fs

git submodule update --init --recursive

./patches/apply.sh

根據Ubuntu版本安裝所需的依賴項：

# for Ubuntu 20.04.apt install cmake libuv1-dev liblz4-dev liblzma-dev libdouble-conversion-dev libprocps-dev libdwarf-dev libunwind-dev \  libaio-dev libgflags-dev libgoogle-glog-dev libgtest-dev libgmock-dev clang-format-14 clang-14 clang-tidy-14 lld-14 \  libgoogle-perftools-dev google-perftools libssl-dev ccache libclang-rt-14-dev gcc-10 g++-10 libboost1.71-all-dev
# for Ubuntu 22.04.apt install cmake libuv1-dev liblz4-dev liblzma-dev libdouble-conversion-dev libprocps-dev libdwarf-dev libunwind-dev \  libaio-dev libgflags-dev libgoogle-glog-dev libgtest-dev libgmock-dev clang-format-14 clang-14 clang-tidy-14 lld-14 \  libgoogle-perftools-dev google-perftools libssl-dev ccache gcc-12 g++-12 libboost-all-dev

確保安裝了libfuse 3.16.1或更新版本，FoundationDB 7.1或更新版本，以及Rust工具鏈。

在建構目錄中建構3FS：

cmake -S . -B build -DCMAKE_CXX_COMPILER=clang++-14 -DCMAKE_C_COMPILER=clang-14 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_EXPORT_COMPILE_COMMANDS=ONcmake --build build -j 32

Smallpond：基於3FS的資料處理框架

項目連結：https://github.com/deepseek-ai/smallpond

快速入門

目前smallpond支援從3.8到3.12的Python版本。

pip install smallpond

使用下列命令獲取示例資料：

# Download example datawget https://duckdb.org/data/prices.parquet

輕鬆上手：

import smallpondsp = smallpond.init()
#載入資料df = sp.read_parquet("prices.parquet")
#資料處理df = df.repartition(3, hash_by="ticker")df = sp.partial_sql("SELECT ticker, min(price), max(price) FROM {0} GROUP BY ticker", df)
#保存結果df.write_parquet("output/")
#顯示結果print(df.to_pandas())

文件

mallpond同時提供了高級和低級API。

注意：目前，smallpond提供了兩種不同的API，分別用於資料流圖的動態和靜態建構。由於歷史原因，這兩種API使用了不同的調度器後端，並支援不同的組態選項。

1. 高級API：目前使用Ray框架作為後端，支援資料流圖的動態建構和執行。
2. 低級API：使用內建調度器，僅支援靜態資料流圖的一次性執行。然而，它提供了更多的性能最佳化和更豐富的組態選項。正在努力將這兩種API合併，以便在未來，可以使用統一的高級API，並在Ray框架和內建調度器之間自由選擇。

下列連結提供入門教學、API參考、性能評估等更多內容。

連結：https://github.com/deepseek-ai/smallpond/blob/main/docs/source/api.rst

開發

pip install .[dev]
# run unit tests,單元測試pytest -v tests/test*.py
# build documentation，建構文件pip install .[docs]cd docsmake htmlpython -m http.server --directory build/html

性能

採用GraySort基準測試指令碼，在一個由50個計算節點和25個運行3FS的儲存節點組成的叢集上，對smallpond進行了評估。

該基準測試在短短30分鐘14秒內完成了對110.5TiB資料的排序，平均吞吐量達到了3.66 TiB/min。

pip install .[dev]
# run unit testspytest -v tests/test*.py
# build documentationpip install .[docs]cd docsmake htmlpython -m http.server --directory build/html

連更五天，最新彙總

DeepSeek開源周，這麼快就過去了。連更5天，次次都是小驚喜。

接下來，我們彙總了過去四天所有的開放原始碼專案，參見：

第一天：為輝達Hopper GPU打造的高效MLA解碼核心FlashMLA，5天項目GitHub星標唯一過10k的。

第二天：支援MoE訓推的EP通訊庫DeepEP，GitHub斬獲6.4k星。

第三天：支援稠密和MoE模型的FP8 GEMM計算庫DeepGEMM，GitHub已達4.2k星。

第四天：最佳化平行策略——DualPipe、EPLB、V3/R1模型中的計算與通訊重疊機制。

(新智元)