AI 基础设施中最引人注目的单元是加速器，悄无声息耗掉加速器时间的单元却可以是一个文件：迟到的训练样本、迟迟无法落盘的检查点，或与下一轮运行争抢带宽的恢复作业。

DeepSeek 的 Fire-Flyer File System 通常简称 3FS，它把这个问题推到台前。公开设计将数据集、中间输出、检查点，乃至推理 KV cache 都视为同一共享存储平面上的流量；这个平面由 NVMe SSD 和 RDMA 网络组成。应用看到的是文件，存储位置退居幕后；客户端从文件系统元数据推导分块位置，随后穿过互连网络，直接联系相应的存储服务。[1]

代码仓库于 2025年2月27日公开。截至 2026年7月26日，主分支的维护记录已延续至 5月7日，当天的最新提交修正了复制链配置表（chain table）的单调版本编号。[1] 相较发布首周的新鲜感，这种持续维护更值得关注。它说明 3FS 是一套仍在演进的系统软件，一个微小的顺序不变量也会产生与醒目吞吐量曲线同样深远的影响。

开源范围也由此清晰起来。DeepSeek 已经公开设计与代码，3FS 距任何模型团队在一个周末内即可装好的存储设备仍有很长距离。已公布的快速通道以成排闪存、精细运维的 RDMA 网络、独立的元数据与监控服务，以及客户端一端的应用改造为起点。这份开源成果是一张严肃的基础设施配方，团队从这里走到存储自主性，仍需完成大量工程。

为缩短昂贵等待而设计的文件系统

3FS 诞生于幻方（High-Flyer）的 Fire-Flyer II AI 集群，存储与计算在其中彼此分离，再由高带宽网络连接。幻方目前的网站仍将这套文件系统与训练调度器、优化算子和集合通信层并列展示，其系统论文则描述了一个通过软硬件协同设计建成、包含 10,000 张 A100 的集群。[2][3] 这一出身十分重要：3FS 从一开始便服务于大型加速器集群，目标是缩短昂贵算力等待文件的时间，普通办公文件共享并非它的设计中心。

公开系统包含四个主要部分。集群管理器维护成员关系与数据放置状态；无状态元数据服务执行文件操作，元数据保存在 FoundationDB 中；存储服务管理本地 SSD 上的分块；FUSE 和原生客户端把文件呈现给应用。各项服务通过 InfiniBand 或 RoCE 通信，普通的尽力而为应用网络不在这条路径上。[1]

这种分离带来两项有用属性。第一，持久化的 inode 和目录项状态位于事务型键值数据库中，因此客户端可以把元数据请求发给任一元数据服务。FoundationDB 的默认事务模型会检测冲突，为创建、建立链接、删除链接和重命名等操作提供严格可串行化的基础。[1][5] 阿里云开发者社区的一篇中文源码分析也指出了同一选择：3FS 把跨分片文件系统事务交给 FoundationDB，元数据服务本身保持无状态，可以横向替换。[4]

第二，文件数据被切成等长分块，在复制链之间条带化，再写入多块 SSD。3FS 使用 Chain Replication with Apportioned Queries（按查询分摊的链式复制），简称 CRAQ。写入会依次经过链上的每个目标；副本的版本状态达到安全读取条件后，读取请求可以在它们之间分摊。最初的 CRAQ 研究面向读多写少的负载，因为增加副本能够在保持强一致性的同时扩大读取能力。[1][6] 这种形态格外适合模型训练：庞大的共享数据集会被反复读取，检查点和转换后的数据集仍需要持久、清楚的文件语义。

这里的重点在于，3FS 把文件接口置于一个明确的分布式数据平面之上。CSV 或 Parquet 加载器仍能看到熟悉的路径，底层存储则负责选择复制链、分散分块、均衡读取并恢复副本。

6.6 TiB/s 这个数字连着一整间机房

代码仓库中最醒目的结果，是约 6.6 TiB/s 的聚合读取吞吐量。这个数字周围的测试条件透露了大量信息。DeepSeek 披露的压力测试使用 180个存储节点，每个节点配备 16块 14-TiB NVMe SSD 和 2张 200-Gbps InfiniBand 网卡。超过 500个客户端节点 发起读取，每个客户端节点配备一张 200-Gbps 网卡，测试期间训练流量仍在系统中运行。[1]

这项结果有力说明，该架构可以在集群规模上汇聚闪存与网络带宽。它无法代表一项普适的文件系统速度。公开数字来自大型集群的聚合读取测试；单凭这项结果，无法说明端到端模型吞吐量、检查点完成时间、故障期间的尾延迟、每可用 TB 的成本，或规模较小的以太网部署性能。硬件和流量模式本就是结果的一部分，不能从脚注里剥离。

代码仓库还给出另外两组观察窗口，各自采用不同配置。一次 GraySort 测试使用 25个存储节点 和 50个计算节点，在 30分14秒 内将 110.5 TiB 数据排序为 8,192 个分区，平均每分钟处理 3.66 TiB。KV-cache 示例报告的峰值读取吞吐量最高达 40 GiB/s，相关客户端节点各有一张 400-Gbps 网卡；README 给出的负载细节还不足以把这一观察推广为通用的推理容量主张。[1]

放在一起看，这些测试覆盖了批量读取、数据处理和面向推理的缓存路径。它们没有组成一套可以横向比较的基准，集群、操作、客户端数量和分母都在变化。采购方或运营方若把“6.6 TiB/s”当作采购规格，需要先在自己的存储盘、网卡、网络拓扑、复制因子与故障策略上复现相应访问模式。

历史条件同样划定了范围。Fire-Flyer II 论文所描述的周边系统使用 PCIe A100 GPU 和一体化计算—存储网络。[2] 因此，3FS 能够证明中国实验室在算力成本压力下开发出了有价值的基础设施软件；它无法证明原始技术栈已经摆脱英伟达硬件。其可移植性主张落在存储接口上，已公布的峰值则属于一座具体设施。

熟悉的挂载方式与高速客户端是两种不同产品

3FS 提供 FUSE 客户端，因为挂载文件系统是迁移现有应用的一种有力工具。应用可以继续打开路径、查看目录和读取基于文件的数据集。这是一条友好的通道。

DeepSeek 自己的设计说明也记录了这条通道的终点。在团队的基准测试中，FUSE 约在 每秒 400,000 次 4-KiB 读取时达到饱和，因为请求会经过一个由自旋锁保护的共享多线程队列。Linux 5.x FUSE 无法对同一文件发起并发写入，训练样本中的小型、未对齐随机读取也用不满可用的 SSD 与网络带宽。[1] 这些情况恰好落在 AI 负载的核心位置，数据加载器会直接产生同类访问模式。

高速通道是一套名为 USRBIO 的原生接口。应用仍通过普通文件路径执行元数据操作，随后注册文件描述符，并借助共享内存环提交异步 I/O。大块已注册内存区域让客户端免去又一次数据复制，批处理则降低大量小请求的开销。阿里云的分析同样识别出一条绕过常规 FUSE I/O 路径、供性能敏感访问使用的零拷贝 RDMA 通道。[1][4]

这种分流解释了项目主张中表面上的矛盾。用户沿用原有存储命名空间，峰值性能依然会要求应用侧集成。团队可以先采用挂载方式，再把选定的数据加载器或检查点写入程序迁移到 USRBIO。评估时需要分别测量易用通道与高速通道；集成原生客户端后，POSIX 行为也要逐项核对。

设计说明直接写明了一项语义差异：3FS 跟踪只读文件描述符的方式不同于本地文件系统，因为训练作业会打开海量文件，这些读取者也不依赖延迟删除。并发写入期间，文件长度也只保持最终一致；直到 close 或 fsync 迫使元数据服务查询最后一个分块，长度才会确定。[1] 这些语义差异来自有意作出的系统取舍，评价它们要回到具体负载；上线前的逐项验证因此成为必经环节。

开源代码不抹去部署成本

人工部署指南最能说明 3FS 的实际门槛。示例集群包含一个元数据节点和 5个存储节点。每个存储节点配备 512 GB 内存、16块 14-TB SSD 和 RoCE；合计 80 块 SSD，复制前的十进制原始容量约为 1.12 PB。指南建议为 FoundationDB 和 ClickHouse 配置专用生产节点，要求运营人员使用 ib_write_bw 验证 RDMA，将每个 NVMe 设备格式化为 XFS，提高异步 I/O 上限，在每块 SSD 上创建多个存储目标，并通过放置求解器生成一张三副本复制链配置表。[1]

当前构建还带有一项源自 std::shuffle 的兼容性警告：运营人员必须选择 g++10 或 g++11 的 shuffle 方法，并在现有集群今后的构建中保持一致。近期维护修复了超时处理、截断与扩展的同步，以及复制链配置表版本的排序问题。[1] 存储工程师熟悉这种规律：性能依赖一组横跨源代码、编译器行为、网络配置、盘上状态和发布纪律的不变量。

这正是 3FS 对供应链的意义。中国 AI 技术栈经常沿加速器、编译器、模型的纵向顺序讲述，3FS 补上一条横向约束：每个加速器都要得到数据，每次失败运行都要留下可恢复的状态，每个检查点也要穿过存储网络，同时避免把稀缺算力变成闲置资本。共享存储平面可以在多个模型团队之间分摊这些工作，原则上也能覆盖异构算力集群。

软件本身还不足以让机房成为标准化商品。价值会流向能够把闪存密度、RDMA、数据放置、指标、事务型元数据与负载专用客户端组装成一项可靠服务的运营团队。对超大规模实验室，这种控制力可以成为战略资源；对较小团队，托管对象存储或成熟的商用并行文件系统仍可以是更合适的取舍，即便它们的峰值曲线没那么醒目。

什么证据能证明 3FS 可以走出原始机房

下一项证明应来自不同约束下的独立运行，继续刷新原始集群的数字反居其次。

第一，采用者需要在远小于 180 个节点的集群上，复现数据集随机读取、并行检查点、恢复和元数据测试，同时报告吞吐量以及 p95、p99 延迟。第二，项目需要给出跨编译器设置、FoundationDB 版本、复制链配置表变更和混合客户端版本的升级与回滚证据。第三，KV-cache 路径需要明确的负载定义，还要与 DRAM、本地 NVMe 和专用解耦缓存系统比较；比较应以每个已接受 token 的成本为主，并同时列出每秒字节数。

证伪条件很直接。如果组织可以克隆代码，却仍要依赖私有补丁、原始网络拓扑和格外深厚的内部存储经验才能取得持续稳定的性能，3FS 最终只会是一份有影响力的设计参考，难以成为广泛适用的供应链层。若它的公开测试、打包方式和运维手册能够跨硬件厂商与集群规模迁移，3FS 将拥有更大的位置：为每一次 AI 运行底下那道不显眼的问题提供一套可复用答案——怎样让昂贵算力免于等待文件。

来源

1. DeepSeek，3FS 官方代码仓库——README 性能披露、设计说明、USRBIO 参考资料、六节点部署指南、构建约束，以及截至 2026年5月7日的提交历史。
2. 幻方 AI 团队，“Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning”，arXiv:2408.14158——Fire-Flyer II 的硬件、网络、存储和运营背景。
3. 幻方，“Computing Power on Demand”——关于实验室内部 Fire-Flyer II 与 3FS，以及训练调度器、算子和通信技术栈的第一手说明。
4. 阿里云开发者社区，“DeepSeek 3FS 解读与源码分析（1）”——对元数据、FoundationDB、FUSE 与 RDMA 选择的中文技术解读。
5. FoundationDB，“Developer Guide”——用于理解 3FS 元数据设计的官方事务、冲突检测、重试与严格可串行化行为说明。
6. Jeff Terrace、Michael J. Freedman，“Object Storage on CRAQ: High-Throughput Chain Replication for Read-Mostly Workloads”，普林斯顿大学出版记录——复制协议及读取扩展能力的理论基础。
7. Btrs，“Dell PowerScale F600 nodes in storage cluster”，Wikimedia Commons——2023年11月15日拍摄的三台全闪存存储节点纪实照片，本文以此作为题图。