一句话定义：并行文件系统（Parallel File System）是把“文件放在哪里”的元数据服务和“数据本身”的存储服务拆开，并由多台服务器同时对外提供读写带宽的一类集群文件系统，Lustre 和 GPFS（IBM 现在的产品名叫 Storage Scale）是超算和 AI 训练集群里最常见的两种。
它运行的机制
传统 NFS 的思路是“一台服务器把本地磁盘共享出去”。所有客户端的数据都要经过这一台机器，它的网卡、CPU 和后端磁盘就是整个集群的上限。想快一点，只能换成更贵的机器；这叫纵向扩展（scale up）。
并行文件系统走的是另一条路：横向扩展（scale out）。它把角色分开。以 Lustre 为例：元数据服务器（MDS/MDT）只管目录、权限和文件被切成哪几块；数据服务器（OSS/OST）管真正的字节。客户端拿到文件的分布信息后，可以绕过元数据服务器，直接同时向多台数据服务器传输数据。GPFS 的做法略有不同，它让数据分布在集群内的共享磁盘上，元数据也分散到多个节点共同分担，而不是固定交给某几台机器。一个文件会被切成条带（striping），按固定大小轮流写到很多块磁盘上。读的时候，几千个客户端各自向不同的数据服务器发请求，带宽是叠加的，而不是被平分的。
这样类比：NFS 像只有一台收银台的超市，队伍再长也只能一个个结账；并行文件系统是开了几十个收银台，而且商品本来就分放在不同货架上，顾客可以同时去不同货架拿。
训练集群不使用 NFS 的原因
差别集中在三件事上：
1. 带宽上限。几千张 GPU 在同一个全局批次（global batch）里，每个训练步都要读样本、算梯度、做一次 all-reduce 同步。数据供给一旦跟不上，GPU 就会空转等待。这是最贵的等待，因为算力是按小时计费的。
2. 元数据操作。几千个进程同时 open/stat 同一个目录下的几十万个文件，这些请求最终都集中到元数据服务器上。NFS 的元数据路径本来就是单点，这里最先成为瓶颈。
3. 检查点写入。训练大模型要周期性写 checkpoint，一次可能是几百 GB 到 TB 级，而且是成百上千个进程同时写。NFS 面对这种并发写入会排队、超时，训练任务被迫停顿甚至重启。
| NFS | 并行文件系统（Lustre 或 GPFS） | |
|---|---|---|
| 架构 | 单台或少数几台服务器导出 | 元数据与数据分离，多服务器组成集群 |
| 扩展方式 | 纵向扩展，更换更强的机器 | 横向扩展，增加存储节点，带宽随之增长 |
| 带宽瓶颈 | 单机网卡与后端存储 | 聚合带宽，随节点数增长 |
| 大量并发小文件的元数据 | 容易成为瓶颈 | 由专门的元数据集群分担 |
| 典型用途 | 办公共享、小规模开发 | HPC、AI 训练、大规模渲染 |
与对象存储的区别
对象存储（例如 S3 接口）容量大、单价低，适合海量冷数据，但它用的是 HTTP 语义，延迟高，不支持 POSIX 的随机写、追加写和 rename。训练时读数据集、写 checkpoint 都要求“像本地文件一样打开就能用”，所以常见做法是用并行文件系统做热层、用对象存储做冷层和归档层。各产品的具体能力以官方文档为准。
对从业者的实际意义
选型时该看的是聚合带宽、元数据 IOPS、能否随节点数近线性扩展，而不是只看“总容量多大”。使用时也有几个具体注意点：大文件比小文件友好，小文件建议打包成分片格式（如 tar、WebDataset）；条带宽度和条带大小要匹配你的读取模式；checkpoint 尽量采用大块顺序写。对不写代码的人来说，这也解释了一件事：大模型训练成本高，不只因为 GPU 贵，还因为“要让 GPU 不闲着”本身就需要一套专门的存储系统。