Fire-Flyer File System（3FS）：DeepSeek 开源的大规模 AI 训练存储底座

当大模型遇到存储瓶颈：3FS 的诞生背景

2024 年，当 DeepSeek 训练千亿参数大模型时，遇到一个业界普遍存在的难题：数据 IO 效率低下。传统分布式文件系统在面对每天需要读取数 PB 训练数据的场景时，元数据查询成为瓶颈，SSD 吞吐量和网络带宽无法充分发挥。存储速度跟不上 GPU 计算速度，昂贵的 H100 集群大量时间在等待数据——每等待一分钟，都是金钱的浪费。

DeepSeek 工程团队意识到，必须为 AI 训练场景重新设计一套存储系统。Fire-Flyer File System（简称 3FS）由此诞生，目标是：让存储不再是大模型训练的短板。

架构设计：RDMA + CRAQ 解决 AI 存储难题

3FS 的核心架构围绕高性能 AI 负载设计，采用 RDMA 网络和 Chain Replication with Apportioned Queries（CRAQ）一致性协议，实现了"强一致性"与"高吞吐"的兼顾。

系统由四个核心组件构成：

• Cluster Manager（集群管理器）：管理成员关系和集群配置，支持多副本选举机制保障高可用。
• Metadata Service（元数据服务）：无状态服务，后端依赖 FoundationDB 等事务性 KV 存储，元数据操作（文件打开、创建等）由其处理。
• Storage Service（存储服务）：管理本地 NVMe SSD，提供块存储接口，实现 CRAQ 链式复制保证强一致性。
• Client（客户端）：提供 FUSE 客户端（低门槛通用挂载）和 Native 客户端（高性能集成）两种接入方式。

在 180 存储节点、500+ 客户端节点的实测中，3FS 实现了约 6.6 TiB/s 的聚合读取吞吐量——这足以在 1 秒内传输一部蓝光电影约 2800 次。

三大 AI 核心场景：数据准备、Dataloader 与 Checkpoint

3FS 并非通用存储系统，而是专为 AI 训练/推理场景量身定制的分布式文件系统。README 明确列出了三个核心应用场景：

场景一：数据准备（Data Preparation）

AI 训练的第一步是数据清洗与预处理。传统方案将中间结果存回对象存储，流程繁琐。3FS 支持将数据分析管道的输出直接组织为层级目录结构，高效管理大量中间产物，简化了数据工程流程。

场景二：Dataloader 随机读取优化

传统训练需要在计算节点预取（prefetch）或打乱（shuffle）数据集，造成 IO 瓶颈和内存浪费。3FS 的随机访问能力让每个计算节点可以直接从共享存储中随机读取训练样本，无需预取，数据加载更灵活、更高效。

场景三：大规模 Checkpoint 保存

千亿参数模型的 Checkpoint 动不动就是 TB 级别。3FS 的高吞吐并行写入使得训练中断后快速恢复成为可能——再也不用担心几个小时的训练结果因故障付之东流。

性能验证：GraySort 与 KVCache 实测数据

3FS 在真实工作负载下进行了严格的性能验证：

GraySort 大规模排序测试：使用 smallpond（基于 3FS 的数据处理框架），在 25 存储节点 + 50 计算节点的集群上，对 110.5 TiB 数据进行分布式排序，完成时间仅 30 分 14 秒，平均吞吐量达到 3.66 TiB/min。

KVCache 推理加速：大模型推理中，同一 prompt 的 KVCache 可被多次复用。3FS 的 KVCache 方案相比纯 DRAM 缓存，成本更低、容量更大，读取吞吐量峰值可达 40 GiB/s，有效加速 LLM 推理过程。

技术栈：纯 C++ + CMake 构建，配套 Python SDK

3FS 主体使用 C++ 开发，充分利用 C++ 的零拷贝、内存池等底层优化能力，充分压榨硬件性能。源码结构如下：

目录	说明
src/	核心 C++ 源码（1043 项），含 client、storage、meta、analytics 等模块
hf3fs/	Python SDK 封装，通过 pybind11 封装底层 C++ 库
hf3fs_fuse/	FUSE 客户端源码
benchmarks/	fio 和存储基准测试工具
deploy/	部署脚本与配置，含 Python 数据放置工具
tests/	完整测试套件（242 项）
specs/	协议规格文档

Python SDK（hf3fs 包）提供类文件接口，通过 hf3fs_py_usrbio 底层库接入，API 风格与标准文件操作接近，降低了集成门槛。部署层面，3FS 依赖 FoundationDB（元数据存储）和 ClickHouse（监控指标），通过 CMake + Clang/GCC 工具链编译。

开发者体验：文档质量高，入门门槛也高

3FS 的文档质量令人印象深刻——README 中包含完整的设计说明、性能测试结果和编译指南，docs/design_notes.md 深入阐述了 CRAQ 一致性、文件接口语义等技术细节，deploy/README.md 提供了 6 节点集群的完整部署步骤。

但客观来说，3FS 的部署门槛相当高：

• 需要至少 6 节点服务器集群
• 每个存储节点必须配备 14TB+ NVMe SSD
• 必须配置 RDMA 网络（InfiniBand 或 RoCE）
• 需手动安装配置 FoundationDB 和 ClickHouse
• 从源码编译依赖大量系统库（cmake、libuv、liblz4 等十余个包）

对于个人开发者或小型团队，3FS 几乎无法在本地环境复现，这也是它目前 star 数虽高但 star/stars 比率（活跃度）偏低的原因之一——大部分关注者来自研究和大规模部署场景，而非个人使用。

局限性与挑战

3FS 目前面临几个值得关注的局限：

1. 生产部署复杂度高：即使有 Dockerfile，构建开发环境也需要手动安装大量依赖，官方没有提供 docker-compose 一键部署方案。
2. RDMA 网络强依赖：没有 RDMA 网络，3FS 的高吞吐优势几乎无法体现，适用场景被严格限定在 HPC/AI 集群环境。
3. FoundationDB 耦合：元数据强依赖 FoundationDB，引入额外的运维复杂度。
4. Release 节奏较慢：当前仓库无正式 Release tag，主要通过 commit hash 追踪版本。

行业意义：开源基础设施的又一次突破

3FS 的开源，体现了 DeepSeek 在基础设施层面的工程实力。继 DeepSeek-V2 的 MoE 架构创新、FlashDecoding++ 的推理优化之后，3FS 补全了 DeepSeek 在"存储"这一关键环节的自研能力。

对于整个 AI 基础设施领域，3FS 的意义在于：

• 证明了开源社区在分布式存储领域同样可以做出世界级工程
• 为中小企业和科研机构提供了低成本获得高性能存储的可能（尽管仍需 RDMA 环境）
• 推动了 AI 训练存储标准的演进——3FS 的设计理念（强一致性 + 文件接口 + CRAQ）可能影响未来更多分布式文件系统设计

如果你在建设 AI 训练平台或进行大规模数据处理研究，3FS 值得关注。即使当前无法直接使用，其设计文档和性能数据对理解现代 AI 存储系统也极具参考价值。