在 2025 年 2 月 28 日，DeepSeek 正式開源了其高性能分布式文件系統 3FS【1】，作為其開源周的壓軸項目，3FS 一經發布便引發了技術圈的熱烈討論。它不僅繼承了分布式存儲的經典設計，還通過極簡卻高效的架構，展現了存儲技術的新趨勢。

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

架構全貌

3FS 采用典型的分布式文件系統架構，客戶端直接連接元數據和數據服務，整體設計清晰且高效。其核心組件包括：

• 元數據集群：元數據服務負責將文件語義轉化為鍵值（KV）語義，底層選用 FoundationDB 作為 KV 存儲。FoundationDB 以高可用性和數據冗余著稱，這種設計與 JuiceFS、CephFS 等主流文件系統類似，確保元數據的可靠性和一致性。
• 數據集群：數據高可靠性通過鏈式復制協議實現，這一協議最早在 Azure Block Storage 中得到驗證，以讀優化為特色。后來 Meta 的 Delta 存儲系統也應用了該復制協議。目前 3FS 支持多副本存儲，雖然配置文件中提及糾刪碼（EC），但代碼中尚未實現，可能是功能尚未完善或未納入開源計劃。但鏈式復制帶來的寫入延遲較高，需要在上層盡可能帶寬以大 IO 為主。

• 集群管理采用了 ClickHouse 作為監控數據存儲，通過心跳管理來實現故障檢測。

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

• FoundationDB 的選擇：FoundationDB 以事務一致性和高可用性見長，但并非以極致性能著稱。相比 Lustre 或 GPFS 等并行文件系統，3FS 的元數據性能擴展性受限于 FoundationDB 的能力，在高并發場景下可能面臨瓶頸。

• 元數據延遲隱患：文件元數據與 KV 存儲形成兩個平面，會產生額外的網絡轉發和處理開銷。對于小文件讀寫密集的場景，這種設計可能顯著增加延遲。

不過，3FS 明確將目標鎖定在 AI 相關場景，專注于大文件和吞吐帶寬優化，因此小文件性能的短板被有意規避，其設計更像是一場“取舍的藝術”。

端到端無緩存：存儲架構設計新范式

3FS 項目開篇就講到了整個項目是面向 AI 相關場景設計，完全面向大文件優化，放棄對于傳統文件系統小文件問題的掣肘。因此元數據并發性能和延遲的劣勢可以稍稍避開，而 3FS 相對于過去并行文件系統和分布式 NAS 到底有何架構上的差異？答案就是“端到端無緩存”。

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

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

1、“去元數據緩存”興起

而到了 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 緩存：

• VastData 的 DASE（Disaggregated Shared-Everything Architecture）架構最早著名的設計就是借助于 Intel Optane 介質，通過持久化內存（PMem）形態去解決 DRAM 的掉電問題，同時將 PMem 作為元數據存儲和寫入緩沖，降低相對于 TLC 介質的讀寫延遲。
• WekaFS 則采用文件系統命名空間徹底打散的方式，完全借助于分布式集群的橫向擴展能力，使用上千個 MDS 邏輯分區并用大量 NVMe SSD 并發來替代集中式的 DRAM 性能。

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

以上都是在 2014年-2020 年，整個高性能文件系統領域呈現的元數據無緩存設計趨勢。

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

2、3FS 的小文件答案：FFRecord

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

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

• 隨機訪問：支持直接訪問特定記錄，無需掃描整個文件。
• 異步 I/O（AIO）：基于 Linux AIO，提供非阻塞數據讀取，提升數據加載效率。
• 高效批量讀取：能夠快速讀取數據批次，適合深度學習中批量處理的需求。

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

在實際的訓練中，FFRecord 可以將訓練樣本按記錄存儲（如圖像數據集中的每張圖片為一條記錄），而 3FS 的分布式特性確保這些文件可以跨多個節點存儲，適合大規模數據集。FFRecord 支持隨機訪問和批量讀取，而 3FS 的無緩存設計確保數據直接從存儲介質傳輸到應用程序，避免了不必要的中介層。這種結合減少了數據訪問延遲。FFRecord 的異步讀取功能（基于 Linux AIO）與 3FS 的高吞吐量架構相輔相成。在分布式訓練中，多個節點可以同時發起異步請求，從 3FS 獲取 FFRecord 數據，從而加速數據加載。訓練框架（如 PyTorch 或 TensorFlow）可以直接讀取 FFRecord 格式的數據，無需額外的格式轉換或緩存管理。通過 FFRecord，3FS 在應用側提供一定的場景解決方案，錯位避開了傳統并行文件系統的小文件難題。

3、從 FUSE 優化到“無客戶端緩存”

3FS 系統的架構師更早看到了 GPU 和 CPU 對于存儲性能訪問需求的變化，非常早的采用了端到端無緩存設計，即“從無數據緩存->無元數據緩存->無客戶端緩存”。

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

但也不得不說，FUSE 在過去 3 年里，隨著文件系統在 AI 場景的使用，大量的 FUSE 改進項目和內核優化都在進行中，其中包括以下：

• XFUSE: 《XFUSE: An Infrastructure for Running Filesystem Services in User Space 》【3】在 2021 的 ATC，阿里云就提出了 FUSE 存在的若干性能問題，對 FUSE 進行了多方面優化，包括路徑直通、批處理請求、多線程處理等。論文結果表明，XFUSE 能將用戶態文件系統請求處理延遲壓縮到 4 微秒級，吞吐達到 8GB/s，同時，XFUSE 保持了對 FUSE API 的兼容，方便現有 FUSE 文件系統遷移。
• ByteFUSE：字節跳動文件系統團隊在 2021 年開始也在逐步優化 FUSE 性能，在《》可以看到其創新性的提出了利用 VirtQueue 來優化隊列性能，并且可以統一虛擬機和容器場景。VirtQueue 作為 QEMU/KVM 成熟的高性能隊列框架，非常適合去解決 FUSE 的隊列問題。
• RFuse：《RFUSE: Modernizing Userspace Filesystem Framework through Scalable Kernel-Userspace Communication》【4】這篇 FAST 24 的論文進一步對 FUSE 通道進行性能優化，它的核心思路是使用每核獨立的環形緩沖區在內核和用戶態之間傳遞消息，從而避免傳統 FUSE 中集中隊列和鎖帶來的瓶頸。每個 CPU 核心都有自己的請求通道，用戶態文件系統可以多線程并行處理不同核心的請求，無需在內核模塊中進行序列化。更重要的是，RFUSE 設計為與現有 FUSE 文件系統兼容，不需要修改現有用戶態代碼。

• 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，幾個前沿的存儲系統都開始在端到端無緩存方向上發力：

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

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

XSKY 在去年的英特爾存儲技術峰會《LLM 存儲，架構至關重要》提出觀點，隨著 AI LLM 場景對于存儲帶寬性能的爆發，帶寬性能成為文件系統存儲性能的絕對優先級，而無緩存設計是其中關鍵。XSKY 星飛平臺自 2023 年底發布，堅持“全共享架構”、“端到端 NVMe”和“單層閃存介質”三大設計原則，在新時代的 NVMe + RDMA 高性能方向上，徹底放棄架構中的緩存層，完全使用單層閃存介質來滿足。跟 3FS 的端到端無緩存思路不謀而合。總而言之，如同過去系統工程領域著名的口號“no caches， no locks”，3FS 的實踐證明，在全閃存系統里，通過架構和算法可以彌補不用緩存可能帶來的問題，反而獲得更簡潔高效的系統。

3FS 與開源 KVCache 框架

3FS 不僅僅用于訓練側，其設計特點也非常有助于在推理 LLM 興起后，用于大規模 KVCache 場景。正如 DeepSeek R1 模型發布后，《》的推理過程數據處理和存儲場景要求，以及 DeepSeek 發表的《Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention》【7】和 Kimi 在 FAST 25 的《Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot》【8】，筆者非常期待 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【9】，一個基于 DuckDB 構建，將 3FS 作為持久化的輕量級數據處理框架。過去分布式 OLAP 數據庫從存算一體轉向存算分離，從 ClickHouse 為代表轉向一眾基于 S3 共享存儲的云數倉。但是這個轉向最大的挑戰就是如何構建緩存層，目前不管是著名的 Snowflake 還是開源的 Databend 云數倉，都是在計算層構建緩存，3FS 是否會給云數倉新的緩存機會，特別是計算、緩存、持久化全分離的模式，比如在本地機房構建多個計算集群，但是共享同一個緩存集群，然后將持久化數據放在遠端。

DuckDB 近日正式提出了外部文件緩存概念【10】，筆者認為是一個改變云數倉架構演進的嘗試，標準化外部緩存能力，不同計算架構和集群共享同一個緩存集群有可能成為新的分離式趨勢。

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

未來展望

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

• 融合創新：3FS 身上融合了來自分布式數據庫、對象存儲和高性能計算領域的創新：FoundationDB 提供強一致元數據存儲，鏈式復制保障高可靠數據冗余，無緩存架構和 RDMA 加速滿足極致性能需求，用戶態文件系統優化兼顧了靈活性和效率。可以說，3FS 并非孤立發明每一個輪子，而是巧妙地把“業界最佳實踐”集成到一個系統中。例如，從 Delta、Azure 借鑒鏈式復制的可靠性模型，從 WekaFS、Vast Data 全閃存直寫的簡潔路徑，從 Alibaba、FAST 論文的 FUSE 提速的思路，再加以自身的工程實現，打造出了這樣一個系統。

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

當然，3FS 作為新晉系統，未來仍有許多挑戰和發展空間。例如，在更大規模部署下，其 FoundationDB 元數據層的伸縮性、鏈式復制對網絡的壓力、無緩存設計在某些工作負載下的權衡，都需要通過實踐進一步觀察。同時，內核社區對 FUSE 優化也將為 3FS 作為通用文件客戶端的性能提升帶來機遇，以及 3FS 支持 GPU 直通存儲的可能性，在生態上，3FS 未來是否能夠進入主流 AI 框架的默認引擎將是值得觀察和期待的信號。

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

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

注：

【1】DeepSeek  3FShttps://github.com/deepseek-ai/3FS【2】《Evolution of ONTAP to Low-Latency SSDs》https://www.usenix.org/system/files/fast24-curtis-maury.pdf【3】《XFUSE: An Infrastructure for Running Filesystem Services in User Space》https://www.usenix.org/system/files/atc21-huai.pdf【4】《RFUSE: Modernizing Userspace Filesystem Framework through Scalable Kernel-Userspace Communication》 https://www.usenix.org/system/files/fast24-cho.pdf【5】Fuse over io-uring https://www.phoronix.com/news/Linux-6.14-FUSE【6】 Dfuse+Libioilhttps://www.intel.com/content/www/us/en/developer/articles/training/introduction-to-dfs.html【7】《Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention》https://arxiv.org/abs/2502.11089【8】 Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbothttps://www.usenix.org/system/files/fast25-qin.pdf【9】 Smallpondhttps://github.com/deepseek-ai/smallpond【10】DuckDB 外部文件緩存https://github.com/duckdb/duckdb/pull/16463