模型再强，数据送不上来，GPU 也只能干等。

前四天，DeepSeek 的开源项目依次覆盖了注意力计算、专家通信、矩阵乘法和并行训练，全都围绕 "GPU 怎么算得更快 " 展开。

第五天，视角换了：GPU 算得再快，也得有数据喂给它。

这一天，DeepSeek 发布了一款充分利用现代 SSD 带宽性能的并行文件系统，名叫 Fire-Flyer File System，简称 3FS。它专为文件和参数的随机读取而设计。

这篇文章会讲清楚：训练时为什么需要 " 随机读取 "、3FS 抓住了什么关键点、它有哪些突出特点，最后附上相关 GitHub 地址。

在训练模型时，数据通常不是按顺序一条条喂进去的，而是被随机采样。

原因很直接：防止模型学到由于顺序读取数据而产生的伪相关性。

打个比方：如果一本习题册总是 " 先讲代数、再讲几何 "，学生就可能记住 " 前半本是代数 " 这个顺序规律，而不是真正掌握知识。把题目打乱，学到的才是题目本身。

模型也一样。如果数据总是按固定顺序出现，它可能会把顺序当成规律，学到一些并不真实存在的关联。随机采样，就是为了避免这个问题。

随机读取，对存储系统来说是个不小的挑战：每次读的位置都不连续，传统依赖顺序读取、依赖缓存的思路就用不上了。

而 3FS 的思路很干脆：

既然训练数据不需要顺序读取，也不需要缓存，那就不为它们花力气；

把全部精力，集中在模型训练中最关键的部分：数据的随机采样。

同时，它充分利用现代 SSD 的带宽性能，让海量随机读取也能跑得快。

结合官方仓库的 README，3FS 的定位是：面向 AI 训练和推理场景的高性能分布式文件系统。 几个值得记住的特点：

README 还给出了几组测试数据（均为官方公布的测试环境下的结果）：

在一个 180 节点的集群上做大块读取压力测试，聚合读取吞吐达到约 6.6 TiB/s，且同时还有训练任务的后台流量；

使用 smallpond 做 GraySort 排序测试，在 25 节点的存储集群上，用约 30 分钟 14 秒排序了 110.5 TiB 的数据，平均吞吐 3.66 TiB/min；

用于推理的 KVCache，峰值读取吞吐可达约 40 GiB/s。

这些数字取决于具体的硬件和网络环境，不代表你自己的集群一定能达到。

3FS 官方仓库：

https://github.com/deepseek-ai/3FS

smallpond（基于 3FS 的数据处理框架，README 中的 GraySort 测试用的就是它）：https://github.com/deepseek-ai/smallpond

DeepSeek 开源基础设施总览 open-infra-index：https://github.com/deepseek-ai/open-infra-index

先读 README 的特点与性能部分，建立整体印象；

再看仓库里的设计说明文档，理解架构；

最后根据自己的环境，查看部署指南与接口文档。

1. 算力不是唯一的瓶颈，数据通路同样关键。GPU 越来越快，如果数据读取跟不上，算力就会闲置。前一天优化的是 "GPU 之间别等 "，这一天优化的是 " 数据别让 GPU 等 "。

2. 看清真实需求，才能做减法。训练数据不需要顺序读取和缓存，3FS 就不为它们花力气，把资源集中到随机采样上。好的系统设计，往往来自对真实负载的清醒认识。

3. 底层存储，也是 AI 基础设施的一部分。从训练数据加载，到检查点保存，再到推理时的缓存，存储贯穿 AI 工作流的每个环节。把它做好，整个系统都会受益。

回到开源周的第五天：3FS 解决的问题听起来朴素，让数据又快又稳地送到 GPU 面前，却是大规模训练里绕不开的一环。

算得快，是本事；喂得上，才是底气。

下一篇：DeepSeek 开源周 - 第六天：DeepSeek-V3/DeepSeek-R1 推理系统概览，欢迎关注，持续更新。