引言：3FS 的设计回顾

在 2025 年，DeepSeek 将其高性能分布式文件系统 3FS 开源，标志着存储技术在 AI 场景下的一次重要突破。回顾之前的文章《DeepSeek 3FS：端到端无缓存的存储新范式》，3FS 以极简架构打破了传统存储系统的路径依赖，通过客户端直连元数据和数据服务、链式复制协议和 FFRecord 格式的协同设计，为 AI 场景提供了高吞吐、低冗余的存储解决方案。其创新性不仅体现在硬件性能的极致释放——如绕过 FUSE 内核的零拷贝 RDMA 传输，更在于对存储范式本质的重新思考：通过放弃通用文件系统的“大而全”设计，转而聚焦 AI 业务的大文件、高带宽特性，3FS 以“用极致专注换取性能突破”的工程哲学，实现了存储效率的跃迁。正如其代码中隐含的“No Cache， No Lock”宣言，这一系统既是对全闪存时代硬件特性的精准响应，也是对深度学习场景中数据流本质的深刻洞察。

场景拆解:AI 存储的三大“战役”与 IO 模型

在实测 3FS 前，需要首先理解 3FS 在 AI 领域的三大场景——大模型训练、长上下文推理、云数仓交互——究竟对存储施加了何种压力。我们基于业务负载特征与 3FS 架构特性，将抽象场景转化为可复现的 IO 测试模型：

1、训练场景：Checkpoint 风暴与数据并发的双重验证

• 压力锚点 1：千卡训练下的 Checkpoint 写入

  模拟千卡训练任务每小时生成超百 GB 级模型快照，触发 3FS 的链式复制极限：通过 fio 构造 1MB 大块对齐写，验证其副本流水线机制能否维持线性带宽增长。

• 压力锚点 2：高纬度数据并行读取

  使用 FFRecord 加载百万级图像样本，以 128 线程并发随机读取 4KB 记录块，实测 RDMA 多路径复用对 QPS 与延迟抖动的影响。

2、推理场景：KV Cache 热加载的带宽冲击

• 压力锚点 1：模型参数突发加载

  模拟推理集群扩容时百 GB 级模型文件热加载，通过 fio 构造 1MB 大块对齐读，验证链式复制协议的读访问优化。

• 压力锚点 2：长上下文 KV Cache 持久化

  构造 128KB token 上下文窗口的 KV Cache 持久化流，测试 FFRecord 按 Attention Head 分块存储策略对随机大块读带宽的放大效应。

3、数仓场景：分析型负载的吞吐密度

• 压力锚点 1：列存文件向量化扫描

     模拟验证 SmallPond 对 128KB 随机读的整流效率。

测试设计逻辑：以上模型均以大块连续、高并发、高随机性为核心特征，与 3FS“端到端无缓存”架构的优化靶点高度契合。若实测数据符合预期，则可量化评估其设计目标（大块连续、高并发优化）的实现程度。

实验场：环境配置说明

我们在内部搭建了测试环境，其中 4 台作为存储节点，4 台作为客户端节点，1 台作为管理节点。节点间完全通过 RoCE 进行 RDMA 通讯。

环境拓扑图如下所示，其中绿色方框表示节点，蓝色方框表示 3FS 的软件。

存储池采用 3 副本（目前 3FS 不支持 EC）默认 ChunkSize 设置为 1MB，默认 stripesize 为 16。

测试工具采用 hf3fs_usrbio 接口方式，其中 hf3fs_usrbio 是 3FS 提供的异步零拷贝 API ，相比于 FUSE 原生 IO 路径能够极大提高小块并发读的性能。

FoundationDB（FDB） 在集群模式下使用 WAL 和多副本机制提供 KV 读写，为了简化 FDB 部署，我们使用了支持高可用的全闪块作为 FDB 存储后端。我们在 FDB 实测性能中反馈基于全闪块的 FDB 性能会比 FDB 集群模式写性能更好，读性能在 3 节点下基本没有差异。因此，本次性能测试的单节点 FDB 并不会拖累 3FS 性能表现。

数据说话：线性带宽增长答卷

在 3FS 的大块读取、大块写入、高并发读取测试中，我们观察到在单客户端的性能测试都打满网络，达到 5109MiB/s～5850MiB/s，特别是在小块 4KB 随机读中，也能接近打满网络带宽上限，IOPS 达到 130万～149万。单节点高并发随机小块读取在更好的计算节点网络条件下，应该可以达到 300 万水平。

在 4 客户端的读取测试中，性能线性增长，达到 23,424MiB/s。

在 1MB 顺序写测试中，3 副本有写放大效应，客户端写入数据和副本复制数据打满了存储节点的网络带宽。

3FS 采用的是链式复制，客户端到存储的网络流量是 1:1，不会造成客户端的网络流量放大，这样尽量减少对跨计算节点 GPU 通信的影响，显著提升了计算节点网卡的有效带宽。

下面是测试过程中对于节点的网络监控，佐证了客户端业务流量和网络流量的匹配，接近 1:1 收敛：

注：客户端节点网络监控：峰值 52Gb/s

注：存储节点网络监控：峰值 51Gb/s

在测试过程中，我们可以发现 3FS 的进程 CPU 开销较低。目前 50Gb 网络环境中，客户端在高 IOPS（4KB 随机读）负载中，客户端服务仅占用 326% CPU（“326% CPU”代表使用约 3.26 个 CPU 核），存储节点上的存储服务仅占用 581%（“581% CPU”代表使用约 5.81 个 CPU 核）。

根据以上测试结果，我们可以看到性能结果受限于计算节点带宽上限，3FS 可以轻松“榨干”SSD 性能，同时保持非常高效的 CPU 利用率，完全可以支撑集群性能的客户端线性扩展能力。从端到端的 IO 统计来看，3FS 几乎没有引入任何 IO 放大，完全可以根据网络和 SSD 的物理基准性能直接对等换算集群性能，证明 3FS “端到端无缓存”架构与 AI 负载的 IO 特征高度契合。

我们也跟相同配置下，全球领先的并行文件系统产品进行对比，能够看到 3FS 在读吞吐带宽性能上基本保持同一个水平，属于测试误差范围。但受限于测试环境的计算节点网络条件，我们后续可以在更高规格的网络条件下进一步测试极限。

在高并发的随机小块读场景里，我们采用每 Core IOPS 去衡量。W 文件产品中，单客户端配置了 2 个 CPU 核，可以提供 33 万的 4KB 随机读 IOPS。在 3FS 单客户端中，消耗了 3.26 个核提供了 130 万的 IOPS。所以能够看到 3FS 平均每个 CPU 核所能够提供的 IOPS 是 W 产品的 2.41 倍。这充分显示了 3FS 提供了业界最顶尖的存储效能！

架构取舍：性能长板的背后

在训练、推理与数仓场景的模拟测试中，3FS 展现出了与其设计目标高度一致的优势，充分验证了其“端到端无缓存”架构在 AI 核心场景的竞争力。然而，正如存储领域的经典规律——性能长板往往源于架构选型的硬币两面，3FS 为追求极致的大文件吞吐，在多个维度做出了主动取舍。

这种取舍并非设计缺陷，而是其“场景驱动”哲学的必然结果：

• 小文件性能的主动弱化：3FS 将文件语义转化为 FoundationDB 的 KV 存储逻辑，天然增加了元数据操作开销。其设计文档明确建议用户通过 FFRecord 或其他开源数据格式合并小文件，这意味着系统并未针对传统文件系统的小文件读写进行深度优化。

• 元数据性能的架构瓶颈：FoundationDB 虽保障了元数据强一致性，但其事务型设计相比 Lustre 等并行文件系统的分布式元数据库（如 MDT），在超高并发文件创建/删除（如百万级/s）场景存在吞吐上限。

• 随机写入的双重约束：受限于链式复制协议的顺序提交特性与当前 3FS ChunkEngine 数据引擎的更新算法设计，3FS 在随机写入场景（如小规模覆盖写）中表现出明显的性能衰减。这种设计选择与其“大块连续写入优先”的目标高度一致，但也在客观上划定了系统的能力边界。

上述特点在架构和代码分析后可以得出，但为准确评估系统边界，我们仍需通过针对性测试来验证。

短板实测：90% 性能衰减的代价刻度

我们根据自身对传统 IT 场景和 HPC 场景的文件系统典型负载，制定以下 IO 模型测试：

• 高并发文件元数据操作：目录创建/查看/删除，文件查看/读取/写入/删除；

• 大文件随机更新写操作：模拟 4KB 随机写。

为了尽可能模拟真实的场景，我们模拟了以下目录树结构供文件系统元数据测试：

在测试目录下创建深度为 8、每层目录创建 64 个子目录的目录树。

然后基于这个目录树执行以下测试用例：

我们把结果跟其他并行文件系统（J 文件产品和 W 文件产品）进行对比，能够明显发现 3FS 在小文件场景性能不足。图中以 3FS 的各个元数据操作 OPS 测试结果为基准值。

在小文件写操作测试（4KB 随机写），因为 4KB 比 FileSize/ChunkSize 小，属于局部更新数据，所以底层存储触发读改写，假如 FileSize 是 16KB，则读写放大是 8 倍。假如 FileSize 比 ChunkSize （1MB）大，那么读写放大是 1280 倍，这导致性能极其差。而且假如小文件的 FileSize 小于 ChunkSize，则会有严重的存储空间浪费。

通过以上测试数据可以看到，3FS 对于小文件场景和随机小块更新写入出现远低于行业一流水平的性能结果，但这个实际上也符合架构分析预期，核心场景的性能优势（如带宽、延迟）完全覆盖 AI 业务需求。这种设计验证了存储系统的关键原则——通过场景约束实现长板最大化，而非追求通用场景的均衡性。

总结：极简主义的胜利与行业启示

DeepSeek 3FS 的诞生，与其说是技术迭代的产物，不如说是 DeepSeek 团队“技术苦行”精神的延续。正如其开源的 DeepSeek-R1 模型以高效推理架构突破千亿参数大语言模型的性能瓶颈，3FS 同样选择了一条“非对称竞争”之路：放弃对传统小文件、随机更新写场景的兼容，转而将 AI 场景的连续大块读写与高并发访问特性推向极致。这种“长板效应”的极致追求，使得 3FS 在模型训练、推理流水线和数仓加载等场景中展现出近乎线性的扩展能力，而其代价则是坦然接受在非目标场景中的性能短板。这种“不完美”恰恰体现了 DeepSeek 团队对系统工程本质的把握——存储系统从来不是抽象的理论模型，而是业务需求与硬件特性的动态平衡。

从开源社区的热烈反响来看，3FS 的价值不仅在于其技术实现，更在于它对存储行业思维惯性的冲击。当多数厂商仍在“存算一体/分离”、“缓存分层”等传统命题中纠缠时，DeepSeek 用代码证明：在特定领域内，极简架构的暴力美学能够击败复杂精巧的设计。

或许正如 20 年前 Hadoop 用 HDFS 定义大数据存储，今天的 3FS 正在为 AI 原生存储树立新标杆。它的存在提醒我们：当技术演进到新的临界点时，敢于放弃冗余比盲目堆砌功能更需要勇气与智慧。而 DeepSeek 团队，再次以开源代码而非空洞宣言，展示了系统团队的硬核实力。

XSKY 正密切关注 3FS 为代表的无客户端缓存方向，结合业界领先的非结构化数据平台和文件对象协议积累，协同上下游合作伙伴，为 AI 存储提供前沿解决方案，欢迎联系 XSKY 客户代表！

【1】https://mp.weixin.qq.com/s/RWCbpIBmHCzGNroFhbm2oA