XSKYCTO深度揭秘：DeepSeek3FS如何定義端到端無快取的儲存新正規化

作者：王豪邁，XSKY星辰天合的聯合創始人兼 CTO，中國計算機協會 CTO Club 成員，西南交通大學系統可信性自動驗證國家地方聯合實驗室兼職副主任，Ceph 基金會董事，Intel 全球軟體創新領導者。

在 2025 年 2 月 28 日，DeepSeek 正式開源了其高效能分散式檔案系統 3FS【1】，作為其開源周的壓軸專案，3FS 一經發布便引發了技術圈的熱烈討論。

3FS 不僅繼承了分散式儲存的經典設計，還透過極簡卻高效的架構，展現了儲存技術的新趨勢。

作為一名儲存從業者，我將以分散式儲存架構的視角，深入剖析 3FS 的設計亮點，揭示其“端到端無快取”理念背後的技術演進。

架構全貌

3FS 採用典型的分散式檔案系統架構，客戶端直接連線元資料和資料服務，整體設計清晰且高效。其核心元件包括：

（1）元資料叢集：元資料服務負責將檔案語義轉化為鍵值（KV）語義，底層選用 FoundationDB 作為 KV 儲存。FoundationDB 以高可用性和資料冗餘著稱，這種設計與 JuiceFS、CephFS 等主流檔案系統類似，確保元資料的可靠性和一致性。

（2）資料叢集：資料高可靠性透過鏈式複製協議實現，這一協議最早在 Azure Block Storage 中得到驗證，以讀最佳化為特色。後來 Meta 的 Delta 儲存系統也應用了該複製協議。目前 3FS 支援多副本儲存，雖然配置檔案中提及糾刪碼（EC），但程式碼中尚未實現，可能是功能尚未完善或未納入開源計劃。但鏈式複製帶來的寫入延遲較高，需要在上層儘可能頻寬以大 IO 為主。

（3）叢集管理採用了 ClickHouse 作為監控資料儲存，透過心跳管理來實現故障檢測。

對於儲存從業者來說，3FS 的架構選型既有值得稱道之處，也存在潛在的技術弱點：

（1）FoundationDB 的選擇：FoundationDB 以事務一致性和高可用性見長，但並非以極致效能著稱。相比 Lustre 或 GPFS 等並行檔案系統，3FS 的元資料效能擴充套件性受限於 FoundationDB 的能力，在高併發場景下可能面臨瓶頸。

（2）元資料延遲隱患：檔案元資料與 KV 儲存形成兩個平面，會產生額外的網路轉發和處理開銷。對於小檔案讀寫密集的場景，這種設計可能顯著增加延遲。

不過，3FS 明確將目標鎖定在 AI 相關場景，專注於大檔案和吞吐頻寬最佳化，因此小檔案效能的短板被有意規避，其設計更像是一場“取捨的藝術”。

端到端無快取：儲存架構設計新正規化

3FS 專案開篇就講到了整個專案是面向 AI 相關場景設計，完全面向大檔案最佳化，放棄對於傳統檔案系統小檔案問題的掣肘。因此元資料併發效能和延遲的劣勢可以稍稍避開，而 3FS 相對於過去並行檔案系統和分散式 NAS 到底有何架構上的差異？答案就是“端到端無快取”。

講述端到端無快取，我們需要首先回到儲存系統早期最重要的架構選擇，分層儲存和快取系統設計上。

在儲存系統發展的早期，DRAM 快取加 HDD 是主流方案，快取設計彌補了硬體效能的巨大差距。隨著 SSD 的引入，DRAM+SSD 的組合成為最佳化熱點資料的利器。然而，全快閃記憶體時代的到來讓複雜的快取機制逐漸成為瓶頸。NVMe SSD 的超高效能，使得 DRAM 快取在某些場景下反而拖慢了系統效率。

“去元資料快取”興起

而到了 2014 年開始，隨著全閃檔案系統的提出和概念產品的落地，業界逐漸意識到複雜的元資料和資料快取機制影響了 SSD 效能的充分發揮。隨著 SSD 介質的迭代和 PCIe 標準的演進，NVMe SSD 的效能進一步提升，在相當多的場景裡，DRAM 快取設計已經成為了系統瓶頸，最早是在儲存系統的資料快取中，如 NetApp Ontap 系統：

•NetApp 在 FAST 2024 上的《Evolution of ONTAP to Low-Latency SSDs》【2】論文，提及如何面對一個老舊的架構，透過 Topspin Read 和 Ack Early 來繞開冗長的 IO 棧.

然後是新一代檔案系統如 VastData、WekaFS、DAOS，都在元資料儲存上徹底放棄了 DRAM 快取：

（1）VastData 的 DASE（Disaggregated Shared-Everything Architecture）架構最早著名的設計就是藉助於 Intel Optane 介質，透過持久化記憶體（PMem）形態去解決 DRAM 的掉電問題，同時將 PMem 作為元資料儲存和寫入緩衝，降低相對於 TLC 介質的讀寫延遲。

（2）WekaFS 則採用檔案系統名稱空間徹底打散的方式，完全藉助於分散式叢集的橫向擴充套件能力，使用上千個 MDS 邏輯分割槽並用大量 NVMe SSD 併發來替代集中式的 DRAM 效能。

（3）DAOS 與 VastData DASE 架構類似，也採用了 Intel Optane 作為元資料引擎儲存介質，但是隨著 Optane 介質下市，DAOS 還在艱難轉型 TLC SSD 方案。

以上都是在 2014-2020 年，整個高效能檔案系統領域呈現的元資料無快取設計趨勢。

3FS 的元資料採用了 FoundationDB 作為底座，在客戶端側放棄了 Posix 要求的元資料一致性要求和傳統並行客戶端的多客戶端一致性，相比上述幾家領先的元資料引擎避開了元資料效能的巨大挑戰，但是這個避讓不是單方面的，而是藉助於 FFRecord。

3FS 的小檔案答案：FFRecord

過去通用儲存系統架構師僅僅站在儲存協議上考慮，最大的挑戰就是無法避免業務場景的小檔案，而 DeepSeek 作為端到端系統工程的卓越代表，透過提供 FFRecord 來極大解決了業務場景裡潛在的小檔案情況。

FFRecord 是由 DeepSeek 開發的一種檔案格式，專門用於高效儲存和訪問二進位制記錄序列，特別適用於深度學習（DL）訓練樣本。具有以下關鍵特性：

（1）隨機訪問：支援直接訪問特定記錄，無需掃描整個檔案。

（2）非同步 I/O（AIO）：基於 Linux AIO，提供非阻塞資料讀取，提升資料載入效率。

（3）高效批次讀取：能夠快速讀取資料批次，適合深度學習中批次處理的需求。

（4）壓縮支援：可選的記錄級壓縮，節省儲存空間，同時保持高效訪問。

在實際的訓練中，FFRecord 可以將訓練樣本按記錄儲存（如影像資料集中的每張圖片為一條記錄），而 3FS 的分散式特性確保這些檔案可以跨多個節點儲存，適合大規模資料集。

FFRecord 支援隨機訪問和批次讀取，而 3FS 的無快取設計確保資料直接從儲存介質傳輸到應用程式，避免了不必要的中介層。這種結合減少了資料訪問延遲。

FFRecord 的非同步讀取功能（基於 Linux AIO）與 3FS 的高吞吐量架構相輔相成。在分散式訓練中，多個節點可以同時發起非同步請求，從 3FS 獲取 FFRecord 資料，從而加速資料載入。訓練框架（如 PyTorch 或 TensorFlow）可以直接讀取 FFRecord 格式的資料，無需額外的格式轉換或快取管理。

透過 FFRecord，3FS 在應用側提供一定的場景解決方案，錯位避開了傳統並行檔案系統的小檔案難題。

從 FUSE 最佳化到“無客戶端快取”

3FS 系統的架構師更早看到了 GPU 和 CPU 對於儲存效能訪問需求的變化，非常早的採用了端到端無快取設計，即“從無資料快取->無元資料快取->無客戶端快取”。

這裡就需要提到 3FS 的客戶端技術選型和設計，3FS 客戶端採用了主流 FUSE 框架，對於 FUSE 每個檔案系統從業者都是愛恨交加，一方面 FUSE 給 Linux Kernel FS 帶來了使用者態實現的可能性，另一方面糟糕的效能實現以及坎坷的演進使得每個 FUSE 使用者都無力吐槽。

但也不得不說，FUSE 在過去 3 年裡，隨著檔案系統在 AI 場景的使用，大量的 FUSE 改進專案和核心最佳化都在進行中，其中包括以下：

（1）XFUSE: 《XFUSE: An Infrastructure for Running Filesystem Services in User Space》【3】在 2021 年的 ATC，阿里雲就提出了 FUSE 存在的若干效能問題，對 FUSE 進行了多方面最佳化，包括路徑直通、批處理請求、多執行緒處理等。論文結果表明，XFUSE 能將使用者態檔案系統請求處理延遲壓縮到 4 微秒級，吞吐達到 8GB/s，同時，XFUSE 保持了對 FUSE API 的相容，方便現有 FUSE 檔案系統遷移。

（2）ByteFUSE：字節跳動檔案系統團隊在 2021 年開始也在逐步最佳化 FUSE 效能，在《ByteFUSE 分散式檔案系統的演進與落地》可以看到其創新性的提出了利用 VirtQueue 來最佳化佇列效能，並且可以統一虛擬機器和容器場景。VirtQueue 作為 QEMU/KVM 成熟的高效能佇列框架，非常適合去解決 FUSE 的佇列問題。

（3）RFuse：《RFUSE: Modernizing Userspace Filesystem Framework through Scalable Kernel-Userspace Communication》【4】這篇 FAST 24 的論文進一步對 FUSE 通道進行效能最佳化，它的核心思路是使用每核獨立的環形緩衝區在核心和使用者態之間傳遞訊息，從而避免傳統 FUSE 中集中佇列和鎖帶來的瓶頸。每個 CPU 核心都有自己的請求通道，使用者態檔案系統可以多執行緒並行處理不同核心的請求，無需在核心模組中進行序列化。更重要的是，RFUSE 設計為與現有 FUSE 檔案系統相容，不需要修改現有使用者態程式碼

（4）Fuse over io_uring：由 DDN Bernd Schubert 在 2023 年提出，在 2024 年經過近 10 個版本的迭代，由於程式碼涉及 CPU 排程和跨模組的影響，被迫砍掉了若干效能最佳化點，在 2025 年合併進了主線。 Fuse over io_uring 【5】特性原理是用 io_uring 取代傳統 FUSE 的 /dev/fuse 通道，這樣使用者態檔案系統可以直接從 io_uring 佇列讀取請求和提交響應，避免了每次請求的系統呼叫和上下文切換。

3FS 採用 FUSE 也同樣需要面對類似的問題，不過並不像上述的 FUSE 改進計劃侷限在 FUSE 核心裡，3FS 是選擇完全繞開 FUSE 的資料讀寫通道，如同 DeepSeek 過去開源的運算元最佳化類似，透過借鑑 io_uring 的零複製和共享記憶體設計，直接在應用側跟檔案客戶端建立了共享記憶體通道，實現從應用側記憶體資料到 RDMA 傳輸的零複製，更是徹底避免了 VFS 系統呼叫的 Context Switch 和記憶體複製。

設計的實現最早可以追溯到 DAOS 的 Dfuse+Libioil 【6】方案，可惜的是，目前沒有看到 DAOS 的這個方案在實際的 AI 開源框架中實踐。

實際上，不僅是 DeepSeek 3FS，幾個前沿的儲存系統都開始在端到端無快取方向上發力：

（1）VastData 在 5.1 版本開始，在其兩層的 DASE 架構上，進一步加強了 QLC SSD 直寫，減少 SCM 層帶來的寫入頻寬瓶頸

（2）HammerSpace 在去年年底，創新性提出了 Tier-0 儲存概念，即在計算節點側直接利用本地 NVMe SSD 作為讀寫，納入到檔案系統的全局裡，並且不改變應用的使用方式。其核心是在利用 Linux Kernel 6.12 的 NFS Bypass 特性，繞開整個 VFS 棧進行讀寫，讓 NVMe SSD 在單檔案併發上發揮接近塊儲存的效能。

XSKY 在去年的英特爾儲存技術峰會《LLM 儲存，架構至關重要》【7】提出觀點，隨著 AI LLM 場景對於儲存頻寬效能的爆發，頻寬效能成為檔案系統儲存效能的絕對優先順序，而無快取設計是其中關鍵。

XSKY 星飛平臺自 2023 年底釋出，堅持“全共享架構”、“端到端 NVMe”和“單層快閃記憶體介質”三大設計原則，在新時代的 NVMe + RDMA 高效能方向上，徹底放棄架構中的快取層，完全使用單層快閃記憶體介質來滿足。跟 3FS 的端到端無快取思路不謀而合。

總而言之，如同過去系統工程領域著名的口號“no caches， no locks”，3FS 的實踐證明，在全快閃記憶體系統裡，透過架構和演算法可以彌補不用快取可能帶來的問題，反而獲得更簡潔高效的系統。

3FS 與開源 KVCache 框架

3FS 不僅僅用於訓練側，其設計特點也非常有助於在推理 LLM 興起後，用於大規模 KVCache 場景。

正如 DeepSeek R1 模型釋出後，《DeepSeek 引領的 AI 正規化轉變與儲存架構的演進》【8】的推理過程資料處理和儲存場景要求，以及 DeepSeek 發表的《Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention》【9】和 Kimi 在 FAST 25 的《Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot》【10】，筆者非常期待 Mooncake 專案和 3FS 專案的整合，3FS 為 Mooncake 提供可靠的 KVCache 共享池，使得開源領域裡出現一個完整的開源 KVCache 方案。

值得一提的是，DeepSeek 所實踐的 Prefill-Decode 分離正在透過 Kimi/Alibaba 工程師的努力進入 vLLM 社群，PD 分離將是大規模分散式推理服務和高效能儲存結合的起點，Mooncake 論文表明共享高效能儲存方案會比 Local Cache 方案快取命中率提升 2.6x，響應時間降低 48%。3FS 可以極大幫助超長上下文 Prefill 階段的 KVCache 載入。

3FS 與雲數倉

這次跟 3FS 共同推出的還有 Smallpond 【11】，一個基於 DuckDB 構建，將 3FS 作為持久化的輕量級資料處理框架。過去分散式 OLAP 資料庫從存算一體轉向存算分離，從 ClickHouse 為代表轉向一眾基於 S3 共享儲存的雲數倉。但是這個轉向最大的挑戰就是如何構建快取層，目前不管是著名的 Snowflake 還是開源的 Databend 雲數倉，都是在計算層構建快取，3FS 是否會給雲數倉新的快取機會，特別是計算、快取、持久化全分離的模式，比如在本地機房構建多個計算叢集，但是共享同一個快取叢集，然後將持久化資料放在遠端。

DuckDB 近日正式提出了外部檔案快取概念【12】，筆者認為是一個改變雲數倉架構演進的嘗試，標準化外部快取能力，不同計算架構和叢集共享同一個快取叢集有可能成為新的分離式趨勢。

這些可能的變化都讓筆者想起了 20 年前 Google 釋出的 GFS 論文，特別是後來又有開源的 Apache HDFS，我們期待 3FS 可以成為 AI 領域的 “HDFS”。

未來展望

透過上述對 3FS 的無快取設計解析，我們可以看到 3FS 在架構上大膽地結合了多種前沿理念，成為當前儲存技術趨勢的一個縮影和引領者：

（1）融合創新：3FS 身上融合了來自分散式資料庫、物件儲存和高效能計算領域的創新：FoundationDB 提供強一致元資料儲存，鏈式複製保障高可靠資料冗餘，無快取架構和 RDMA 加速滿足極致效能需求，使用者態檔案系統最佳化兼顧了靈活性和效率。可以說，3FS 並非孤立發明每一個輪子，而是巧妙地把“業界最佳實踐”整合到一個系統中。例如，從 Delta、Azure 借鑑鏈式複製的可靠性模型，從 WekaFS、Vast Data 全快閃記憶體直寫的簡潔路徑，從 Alibaba、FAST 論文的 FUSE 提速的思路，再加以自身的工程實現，打造出了這樣一個系統。

（2）技術趨勢的驗證者：3FS 的出現也在一定程度上驗證並推動了儲存技術的發展趨勢。過去幾年業內對無快取、使用者態 IO、RDMA、分散式事務元資料等理念多有探討，3FS 將它們付諸實踐並取得成功案例，會讓更多人意識到這些路線的可行性。例如，一些保守的企業儲存廠商可能尚在觀望無快取架構是否可靠，而 3FS 的效能和穩定性如果獲得認可，將促使整個行業更大膽地擁抱這一趨勢。

當然，3FS 作為新晉系統，未來仍有許多挑戰和發展空間。

例如，在更大規模部署下，其 FoundationDB 元資料層的伸縮性、鏈式複製對網路的壓力、無快取設計在某些工作負載下的權衡，都需要透過實踐進一步觀察。同時，核心社群對 FUSE 最佳化也將為 3FS 作為通用檔案客戶端的效能提升帶來機遇，以及 3FS 支援 GPU 直通儲存的可能性，在生態上，3FS 未來是否能夠進入主流 AI 框架的預設引擎將是值得觀察和期待的訊號。

可以預見，儲存系統架構在全快閃記憶體和新型網路時代會加速演進，而 3FS 作為這一潮流中的先鋒，將不斷最佳化並引入新的特性。總的來說，3FS 的評測讓我們看到了未來儲存系統的一種雛形：軟體更“通透”但更智慧，硬體效能得到充分釋放，分散式一致性不再以犧牲效率為代價。對於廣大的儲存技術愛好者而言，這是一個激動人心的方向。我們期待 3FS 在後續版本中繼續打磨，實現更成熟的功能，並與業界同行一起，將現代儲存架構帶入一個新的境界。

XSKY 正密切關注 3FS 為代表的無客戶端快取方向，結合過去的 XEOS 強大的元資料引擎和檔案客戶端積累，協同上下游合作伙伴，為 AI 儲存提供前沿解決方案，歡迎聯絡 XSKY 銷售代表！