AI 训练数据为什么经常采用对象存储，和传统文件系统相比有哪些不同

AI训练的数据规模正在改变传统存储系统的设计思路。从几TB的图片数据，到数百TB甚至PB级的视频、文本、语音、遥感数据集，再到训练过程中不断产生的checkpoint、评估结果和中间数据，存储系统面对的已经不只是“把文件保存下来”这么简单的问题。更大的数据规模、更高的并发读取量，以及大量训练节点同时访问同一批数据，使得企业越来越多地把对象存储作为AI数据平台的底层存储。

但这并不意味着对象存储正在取代传统文件系统。恰恰相反，现代AI基础设施中经常同时存在对象存储、并行文件系统、本地NVMe SSD和缓存层。对象存储更像是大规模数据的长期底座，而高速文件系统和本地SSD负责解决训练作业对低延迟、高吞吐和随机访问的需求。真正成熟的AI存储架构，通常不是在“对象存储”和“文件系统”之间二选一，而是根据数据生命周期和访问模式把几种技术组合起来。

对象存储和文件系统首先不是同一种数据模型

传统文件系统以文件和目录为核心。用户通过路径访问文件，例如：

/data/dataset/train/images/000001.jpg
/data/dataset/train/images/000002.jpg

操作系统通过目录、inode、权限、时间戳等元数据管理这些文件，应用程序则通过POSIX接口进行 open()、read()、write()、close() 等操作。

这种模型非常适合操作系统和应用程序，因为程序可以把存储设备看成一个统一的文件树。

对象存储采用的是另一套模型。一个对象通常由对象数据、元数据以及对象键组成，应用通过API访问它，例如：

bucket/dataset/train/000001.jpg

这里的重点并不是“对象存储没有目录”，而是所谓的目录通常并不是传统文件系统意义上的目录树。很多对象存储系统使用对象键的前缀模拟目录结构，底层依然按照对象键进行管理。

这种设计非常适合海量数据。

例如一个训练数据集可能包含几亿个对象。对象存储系统可以把这些数据分散到大量存储节点和磁盘上，由系统负责数据布局、冗余、故障恢复和容量扩展。应用程序并不需要知道某一个对象到底位于哪台服务器、哪块磁盘。

AI训练为什么喜欢对象存储

AI训练有一个非常明显的特点：计算规模增长得比传统应用快得多。

一台服务器可能只有几张GPU，但一个大型训练任务可能同时使用几十台、几百台甚至更多服务器。每台服务器又可能拥有多张GPU。

假设一个训练集包含100TB数据，训练集放在中央存储系统中，同时有100台训练服务器读取，那么存储系统面对的并不是一次100TB的读取，而可能是大量节点持续产生的并发读请求。

这时候存储系统需要解决的核心问题已经从“磁盘容量够不够”变成了：

总吞吐量
并发连接数
网络带宽
IOPS
请求延迟
元数据压力
缓存命中率
数据预取效率
GPU等待时间

对象存储最大的优势之一就是非常容易横向扩展容量和吞吐能力。增加存储节点、磁盘和网络资源以后，系统可以继续扩大整体规模。

对于数据湖、训练数据仓库、原始视频、图片、日志、遥感数据以及训练checkpoint等数据，这种扩展能力非常有价值。

但“文件数量多”并不等于文件系统一定撑不住

原文把“文件句柄数量限制”和“元数据操作拖慢”作为传统文件系统面对AI数据的普遍瓶颈，这个说法过于绝对。

现代并行文件系统同样可以针对大规模AI工作负载进行设计，例如Lustre、IBM Storage Scale等系统，本身就是为了大规模并行计算和高吞吐场景设计的。

问题真正出现在访问模式。

如果训练集由大量几KB甚至几十KB的小文件组成，即使底层存储拥有非常高的顺序吞吐能力，训练程序仍然可能因为大量 open()、stat()、目录查询和小块读取而产生严重的元数据和IOPS压力。

例如一个数据集包含：

1亿个小图片

与一个经过打包处理的：

数千个大型数据分片

即使两者总容量完全一样，对存储系统造成的压力也可能完全不同。

因此AI训练中经常会把大量小文件转换成更适合批量读取的数据格式，例如WebDataset、TFRecord、Parquet，或者其他专门的数据分片格式。

这时候真正得到改善的并不是“对象存储魔法般地解决了小文件问题”，而是数据布局本身发生了变化。

对象存储真正强大的地方是容量、扩展性和数据生命周期

对象存储非常适合作为AI数据的“数据湖底座”。

例如企业可能保存：

原始视频
原始图片
清洗后的数据
训练集
验证集
测试集
模型checkpoint
日志
评估结果
历史版本

其中很多数据并不会每天访问。

如果把这些数据全部放在高性能NVMe文件系统中，成本会非常高。

对象存储可以根据数据访问频率采用不同存储层级，例如热数据、低频访问数据和归档数据，并结合生命周期策略自动转换存储层级。

因此对象存储的优势并不只是“速度快”。

很多时候，它真正解决的是：

PB级容量
低单位容量成本
长期保存
数据版本
生命周期管理
跨区域复制
权限控制
对象锁定
审计
备份

这些能力对于AI数据平台的重要性，甚至比单纯的IOPS更加突出。

对象存储并不天然等于高性能训练存储

这是AI基础设施设计中非常容易出现的误区。

对象存储通常通过HTTP、HTTPS或厂商提供的SDK访问，而不是传统POSIX文件接口。

假设训练程序不断执行：

open
read
seek
read
close

这种大量小粒度随机访问，并不一定适合直接打到远端对象存储。

网络往返延迟、对象API请求数量、TLS、SDK处理、连接管理以及小对象读取都会产生额外开销。

因此真正的AI训练系统通常不会简单地让每张GPU每次需要数据时都直接向远端对象存储发请求。

更常见的架构是：

对象存储
↓
数据预取
↓
训练节点本地NVMe
↓
缓存
↓
CPU内存
↓
GPU显存

对象存储负责保存规模庞大的数据资产，而训练节点通过预取和缓存，把即将使用的数据提前搬到本地高速存储。

这样才能让GPU尽量保持满载。

AI训练真正关心的不是磁盘峰值速度，而是GPU有没有等数据

假设一台GPU服务器使用的SSD标称读取速度为7GB/s，但训练过程中GPU经常等待DataLoader，那么单纯把SSD换成更快的型号可能并不能解决问题。

需要观察完整的数据通路：

对象存储
网络
数据下载
解压
解码
CPU预处理
内存
本地NVMe
DataLoader
GPU

任何一个环节出现瓶颈，GPU都可能出现空闲。

例如图像训练中，如果JPEG解码占用了大量CPU时间，那么把对象存储从一个系统换成另一个系统可能几乎没有效果。

如果网络吞吐只有20Gbps，那么即使后面的NVMe能够达到7GB/s，也无法改变前端数据供应能力。

如果数据已经全部缓存到本地NVMe，那么对象存储性能甚至可能暂时不再是训练作业的主要瓶颈。

所以AI存储优化真正应该观察的是GPU utilization、step time、DataLoader等待时间、读取延迟、吞吐、缓存命中率以及数据预取队列，而不是只看“SSD读取速度多少GB/s”。

对象存储和并行文件系统经常是搭档

大型AI集群中，一个非常常见的设计思路是：

对象存储负责保存完整数据集和长期数据资产。

并行文件系统负责向大量计算节点提供高吞吐、低延迟的共享文件访问。

本地NVMe负责训练数据缓存、临时文件、shuffle、中间结果和checkpoint staging。

GPU显存则保存当前计算阶段真正需要的数据。

这样形成不同层级的存储架构。

对象存储可以拥有PB甚至更大的容量，但并不需要承担所有随机IO；本地NVMe拥有极低延迟，但容量有限；并行文件系统提供共享高吞吐能力，但成本和运维复杂度通常高于普通对象存储。

这就是为什么现代AI数据中心经常不是“对象存储替代文件系统”，而是让不同存储系统各自承担最适合自己的工作。

不要把NVMe-oF、RDMA和对象存储混为一谈

原文把NVMe over Fabrics作为对象存储性能提升的重要手段，这个表述容易让读者产生错误理解。

NVMe-oF是一套通过网络访问远端NVMe存储资源的技术体系，重点是让远端NVMe设备提供接近本地块存储的访问能力。

它与对象存储不是同一个存储模型。

同样，RDMA主要解决的是低延迟、高吞吐网络通信问题，InfiniBand和RoCE是常见实现路线之一。大型AI集群可以使用高速网络把计算节点、存储节点和GPU节点连接起来，但不能简单说“用了NVMe-oF，对象存储就会自动变快”。

实际性能取决于整个架构，包括网络拓扑、协议栈、对象存储软件、客户端、缓存、数据布局以及底层磁盘。

对象存储也不能简单理解成“最终一致性”

这一点也需要根据具体产品和部署架构判断。

现代主流云对象存储服务已经提供了相当成熟的一致性语义，不能笼统地告诉读者“对象存储通常是最终一致性”。

不同产品、不同API以及不同操作的语义可能不同。

因此AI系统不能建立在一个模糊的“对象存储最终会同步”假设上，而应该明确数据发布流程、版本、对象命名、manifest以及任务之间的依赖关系。

例如一个训练任务开始之前，可以先生成数据集manifest：

dataset-v2026-09

然后固定本次训练使用的对象版本。

这样训练过程中即使后台产生了新的数据版本，也不会导致当前任务读取到一半发生数据集变化。

对于机器学习，这种数据版本管理往往比简单讨论“强一致还是最终一致”更加实际。

真正需要警惕的是小文件和数据布局

对象存储解决不了所有AI数据问题。

如果训练数据是几亿个极小对象，直接通过远端API逐个读取，依然可能产生巨大的请求开销。

工程上经常需要进行数据打包、分片、压缩、索引和预取。

例如把：

1亿个小文件

组织成：

数千个大型shard

训练程序可以顺序读取一个shard中的多个样本，再在本地完成解码和随机化。

这样不仅可以降低请求数量，也更容易利用网络吞吐和SSD顺序读取能力。

所以AI存储优化经常不是“换一个更贵的存储设备”，而是从数据格式、sharding、DataLoader、缓存和预取策略一起优化。

对象存储最大的价值是让计算和数据解耦

传统服务器往往把应用、文件系统和数据紧密绑定在一起。

AI数据平台则越来越强调计算和存储分离。

数据集长期存在对象存储中，需要训练的时候，可以临时启动大量GPU服务器，把数据缓存到本地，再进行训练。训练结束以后，GPU服务器可以释放，而数据仍然留在对象存储中。

这对于云计算尤其重要。

如果训练任务每个月只运行几次，没有必要为了保存几百TB数据长期维持一套昂贵的高性能文件系统。

对象存储提供了一个相对低成本的长期数据底座，而计算资源可以根据训练任务动态扩缩容。

这也是AI基础设施从传统“服务器加硬盘”模式逐渐转向数据湖、弹性计算和分层缓存架构的重要原因。

因此，AI训练大量采用对象存储，并不是因为传统文件系统已经过时，也不是因为对象存储在所有情况下都更快。两者解决的问题不同。

对象存储更适合海量数据的长期保存、横向扩展、生命周期管理和计算存储分离；并行文件系统更适合大量计算节点同时访问共享数据；本地NVMe则负责低延迟缓存和高速临时IO。对于真正的大型AI训练集群，最合理的方案往往是把三者甚至更多层级组合起来。

最终决定训练性能的，也从来不是某一种存储介质的宣传页峰值，而是从数据集到GPU显存的整条数据供应链。只要GPU因为数据加载、网络传输、解码或者缓存未命中而等待，哪怕底层存储标称速度达到数十GB/s，昂贵的GPU算力依然可能没有得到充分利用。对于AI基础设施工程师来说，存储设计的核心问题因此已经从“数据放在哪里”转向“如何以稳定、可预测、经济的方式持续把数据喂给GPU”。