## 一、先算一笔钱：GPU 饿着的时候，租金照付

一个 72 卡的 NVIDIA NVL72 机柜，如果每张 GPU 需要 200 MB/s 的训练数据才不闲着，整个机柜需要 **14 到 20 GB/s 的聚合存储带宽**（书第 5 章）。这还只是纯文本 LLM，换成图像、视频这类多模态，需求还要往上翻。

存储喂不上，GPU 就停下来等。你租的卡、买的电、占的机柜，一分钱不会少。

第二章我们讲通信是把 GPU 算出来的结果互相传，存储则是把原始数据从外面送进来。通信慢了，训练卡；存储慢了，训练直接饿。**而且存储的坑最隐蔽**——大家盯着 GPU 和网络，很少有人去算「数据到底跟不跟得上」。

## 二、数据离 GPU 越近，越快越稳

存储优化的底层逻辑不复杂：**数据离计算越近，越快越稳。**

2026 年主流 AI 数据中心通常把存储分成五层（行业通用分层，参考 disks.us 等 AI 存储架构分析）：

![fig6-storage-tiers.png](https://developer.qcloudimg.com/http-save/yehe-11479707/b92d51dad719ff693004c6d37d98fc4b.png)
- **GPU 本地 NVMe**：离得最近，放小批次、模型分片缓存，延迟最低
- **节点 NVMe / 本地 RAID**：放检查点，快速重启
- **NVMe-oF 共享池**：跨节点训练，靠 RDMA + GDS 喂多节点
- **高容量 SSD**：放不常访问的大数据集
- **对象存储 / 冷存储**：原始数据、归档

普通团队不用五层全上，但核心思想一样：**工作集放在最快的层，冷数据往下沉。** 别让一块 1 TB 的模型权重，每次都跨网络从对象存储里现拉。

## 三、小文件是随机读，是存储的隐形杀手

GPU 喜欢大口吃数据，存储也一样——大块顺序读吞吐比小块随机读高一个数量级。

一个常见坑是：训练图像时存了几百万个独立小文件，结果磁盘上全是随机寻道。正确做法是把小样本合并成几个大文件，比如 Arrow、TFRecord、Parquet，或者 WebDataset 的 tar 包。一次顺序读就能拿到一批样本，每次读的开销被摊薄了（书第 5 章）。

如果确实只能随机读，就用 `io_uring` 这类 Linux 异步 I/O 并行发多个请求，把延迟藏起来。文件系统也有讲究：Linux NVMe 服务器上 XFS 是常见选择，挂载时记得 `noatime`，省掉每次读都更新访问时间的开销。

> 一句话：训练前先把数据整理成"大块连续"，比换任何高端存储设备都便宜。

## 四、2026 年的存储硬件：接口翻倍，容量上天

存储硬件这几年的迭代，比很多人意识到的快。三个变化值得记。

**先说接口。** PCIe Gen5 NVMe 已经是 2026 年的主力，顺序读能到 14 GB/s 上下，是 Gen4 的两倍。代表产品是 Samsung PM9C3a 和 Micron 9650。Gen6 还在路上，按 PCIe 规范它能翻倍到 28 GB/s 左右，2026 年内能见到更多支持平台（来源：Fact.MR 数据中心 SSD 市场报告、厂商规格）。

**容量在涨。** QLC NAND 把单盘容量推到了 60 TB 量级（Micron 6550 ION 已做到 60 TB），100 TB 以上还在路线图上。这意味着「把数据复制到每个节点本地盘」这种笨办法，现在变得越来越可行。

**AI SSD 登场。** 2026 年最值得注意的新物种。以公开报道的忆芯 STAR2000D 为例，它在 SSD 主控里集成了 8 TOPS 算力，直接在盘内做 KV Cache 的量化压缩和检索，还支持 GDS/RDMA 直通。计算开始往存储下沉，不用再把数据搬回 CPU 处理。

## 五、GDS：让数据绕过 CPU 直达 GPU

传统路径下数据要绕道：SSD → CPU 内存 → GPU 显存。中间多一次拷贝，还占 CPU。NVIDIA 的 GPUDirect Storage（GDS）让 GPU 直接从存储 DMA 到自己的显存，跳过 CPU 内存这个中转站。

它和上一章讲的 GPUDirect RDMA 是一对：RDMA 加速网络到 GPU，GDS 加速存储到 GPU，都是去掉"主机内存"这个弹跳缓冲。

![fig6-gds-path.png](https://developer.qcloudimg.com/http-save/yehe-11479707/abf9f62d3b35453fbf8a028169c838ef.png)
收益有多大？VAST Data 的实测是：单块 A100 顺序读提升 20%，Hopper H100 因为网卡带宽更高、CPU 负担更重，提升超过 30%（书第 5 章、VAST Data GDS 报告）。

![fig8-gds-speedup.png](https://developer.qcloudimg.com/http-save/yehe-11479707/b65f89f77c646cfe034ed20b4c8e4cb4.png)
但这张图是示意值。真实收益取决于你的数据路径：GPU 和 NIC 是否在同一条 PCIe switch 下、文件系统是否支持 O_DIRECT、cuFile 是否配置正确。GDS 不是开了就自动生效的魔法开关。

### 踩坑现场：GDS 没开，GPU 利用率有规律掉零

下面是一种基于公开资料整理的典型踩坑模式，不是某一次特定事故，但在很多集群里反复出现：

**症状**：训练吞吐只有预期的六成，CPU 使用率居高不下，`iostat` 显示 NVMe 吞吐正常，但 GPU 利用率曲线每隔几十步就规律地掉到 0。

**排查**：

1. `nvidia-smi topo -m` 看 GPU 和 NIC 的拓扑关系，确认是不是在同一条 PCIe switch 下。
2. 单节点跑 `gdsio` 测 GDS 是否生效；如果 fallback 到普通 POSIX 路径，说明没开成功。
3. 检查 `cufile.json` 配置和文件系统是否支持 O_DIRECT，容器里还要注意权限有没有 `CAP_SYS_ADMIN`。

**修复**：把数据路径打通后，GDS 生效，CPU 不再做 memcpy 中转，GPU 利用率曲线会从"锯齿"变"平稳"。

## 六、Checkpoint：别让它把训练卡死

提完 I/O 别忘了 checkpoint。LLM 训练里检查点写入通常几十 GB 到几 TB，写一次就要让训练停几秒到几十秒。

书第 5 章讲了 cuda-checkpoint 配合 CRIU 做进程级快照，路径和模型检查点正交（来源：书第 5 章）。生产里更常见的做法是用并行文件系统 + GDS/RDMA 写检查点，配合异步/分片策略避免阻塞训练循环。

## 七、DeepSeek 为什么自己造了 3FS

这一章最精彩的部分，是 DeepSeek 的 3FS。

DeepSeek 观察到 AI 工作负载有一个反直觉的特点：**绝大多数读是随机读**。而随机读会让传统读缓存失效，甚至帮倒忙——缓存没命中，还白白浪费管理开销。

于是他们从头写了一个文件系统，叫 Fire-Flyer File System（3FS），2025 年 2 月 27 日开源，核心就一个激进决定：**去掉缓存，直接文件 I/O，每个请求直达 NVMe SSD**（来源：DeepSeek 3FS 官方仓库、cronfeed 深度分析）。

这套系统由四部分组成：集群管理器、无状态元数据服务、存储服务、客户端。元数据放在 FoundationDB 里，用它保证创建、删除、重命名这些操作的强一致性。数据切成等大的块，用 CRAQ（Chain Replication with Apportioned Queries）做复制，读的时候可以在多个副本间分摊。

![fig6-3fs-vs-ceph.png](https://developer.qcloudimg.com/http-save/yehe-11479707/ebc9a4ea6059f320b5df2e29bbed8234.png)
它的吞吐数字要分开看，混在一起会误导：

- **6.6 TiB/s 聚合读**：来自 180 个存储节点 + 500 多个客户端的集群，是端到端总吞吐。
- **3.66 TiB/min GraySort**：来自 25 节点的基准测试，体现单节点效率。
- **40 GiB/s 单节点 KV Cache 查找峰值**：说明 3FS 不只是训练数据盘，而是把检查点、中间输出、甚至推理 KV Cache，都当成同一个存储平面上的流量来管（来源：DeepSeek 官方技术报告、cronfeed 2026 分析）。

作为对比，Ceph 在类似硬件上只有约 1.1 TiB/s（书第 5 章）。

> 泼盆冷水：开源了设计和代码，不等于你周末就能搭起来。它需要成排的全闪存、精心运维的 RDMA 网络、独立的元数据和监控服务。3FS 是一张严肃的基础设施配方，不是开箱即用的存储设备（来源：cronfeed 2026）。

## 八、并行文件系统、对象存储，怎么选

大部分人不会自己造文件系统，而是在现成的里面选（书第 5 章）：

- **NFS**：简单，但单服务器容易成瓶颈，只适合几个节点的小规模。
- **并行文件系统（Lustre、GPFS、WekaFS）**：为高并发高吞吐设计，大文件条带化到多个存储目标上，能把带宽乘起来。现代 AI 训练集群首选。
- **对象存储（S3）**：不是文件系统，但很常见。训练时直接读很慢，通常先在本地 NVMe 暂存，或者在 S3 上套一层缓存（比如 AWS FSx for Lustre）。

### 一个反共识判断

很多人以为集群越大越要上 Lustre/GPFS。我的看法相反：**规模不到百卡，与其折腾分布式文件系统，不如先把数据合并成大文件、加一层本地 NVMe 缓存。** 并行文件系统省的是带宽，吃的是运维。小团队过早引入它，往往是给自己找罪受。

## 九、压缩和盘内计算

数据压缩是另一个省钱的路子。存压缩数据、读的时候即时解压，能省 I/O 带宽，代价是多耗点 CPU 或 GPU。现代 GPU 带片上解压引擎，支持 LZ4、Snappy、Deflate，Blackwell 能在管道里直接解压，不占用 SM（来源：书第 5 章）。

这条线走到极致，就是前面说的 AI SSD：把量化、检索这些原本在 CPU 上做的事，下沉到盘里。核心逻辑都一样——**数据在哪，就在哪算，别搬来搬去。**

## 十、收尾

存储 I/O 的优化，本质是消灭"累积的小低效"：这里 5 ms 延迟，那里 10 MB 缓冲太小。单看都不起眼，规模一大就是真金白银。

回扣到整个系列的主线：goodput 损失的三大元凶——通信、存储、数据管道。通信在第二章讲过了，存储这一半讲完了。下一篇我们钻进最后一层，讲数据怎么被预处理、打包、喂进训练循环。


---

## 参考资料

- Chris Fregly, *AI Systems Performance Engineering*, O'Reilly Media（第 5 章）
- DeepSeek 3FS 官方仓库（github.com/deepseek-ai/3FS，2025-02-27 开源）
- cronfeed：《DeepSeek opened 3FS, but the fast path still begins in the machine room》（2026）
- Fact.MR：《Data Center SSD Market Forecast 2026–2036》（2026）
- Micron 6550 ION / 9650、Samsung PM9C3a 官方规格
- 忆芯科技 CFMS 2026 公开报道（STAR2000D AI SSD）
- VAST Data GDS 性能报告

> 说明：GDS 前后对比图为基于 VAST Data 报告典型区间的示意值，非特定集群实测。文中 2026 年存储硬件数据来自厂商官方规格与市场报告，截至 2026 年 8 月；局部性、顺序读、GDS、3FS、checkpoint 等机制与数字沿用《AI Systems Performance Engineering》第 5 章。


一个 72 卡的 NVIDIA NVL72 机柜，如果每张 GPU 需要 200 MB/s 的训练数据才不闲着，整个机柜需要 14 到 20 GB/s 的聚合存储带宽（书第 5 章）。这还只是纯文本 LLM，换成图像、视频这类多模态，需求还要往上翻。

AI Infra 系列 · 第三章 存储层（上）：GPU 饿着不是算法问题，是账单问题

大模型训练慢，很多人的第一反应是换优化器、调学习率、上更贵的卡。但有一半的慢，根因根本不在 GPU，而在数据能不能按时送进 GPU。这篇讲 AI Infra 的存储层：NVMe、GDS、并行文件系统，以及 DeepSeek 为什么放着现成的文件系统不用，非要自己造一个 3FS。

运维开发工程师

云计算

人工智能

硬件

存储系统常被忽视却是AI训练性能的关键瓶颈。GPU等待数据时租金照付，存储慢直接饿死训练。优化核心是分层存储与数据就近原则，小文件合并成大块顺序读可数量级提升性能。GDS技术让数据绕过CPU直达GPU，大幅提升吞吐；DeepSeek自研3FS以激进的无缓存设计实现40GiB/s单节点性能。训练前整理数据格式比更换昂贵硬件更有效。

存储优化

对象存储

数据管道

数据中心

文件系统

大数据

服务器

DeepSeek

容器

Linux

2026上云采购 | AI焕新·智启新局

tiocr

tione

4核4G3M云服务器 新用户低至38元/年！

chdfs

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

存储系统常被忽视却是AI训练性能的关键瓶颈。GPU等待数据时租金照付，存储慢直接饿死训练。优化核心是分层存储与数据就近原则，小文件合并成大块顺序读可数量级提升性能。GDS技术让数据绕过CPU直达GPU，大幅提升吞吐；DeepSeek自研3FS以激进的无缓存设计实现40GiB/s单节点性能。训练前整理数据格式比更换昂贵硬...

AI Infra 系列 · 第三章 存储层（上）：GPU 饿着不是算法问题，是账单问题-腾讯云开发者社区-腾讯云

AI Infra 系列 · 第三章存储层（上）：GPU 饿着不是算法问题，是账单问题

AI Infra 系列 · 第三章存储层（上）：GPU 饿着不是算法问题，是账单问题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第三章 存储层（上）：GPU 饿着不是算法问题，是账单问题

AI Infra 系列 · 第三章 存储层（上）：GPU 饿着不是算法问题，是账单问题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第三章存储层（上）：GPU 饿着不是算法问题，是账单问题

AI Infra 系列 · 第三章存储层（上）：GPU 饿着不是算法问题，是账单问题