阿里云CPFS全栈自研AI存储：成本降低69%的技术架构与实战调优

1. 从一条发布消息说起：AI存储为什么突然成了焦点

前阵子阿里云发布了新一代全栈自研的高性能存储CPFS，官方给出的数字是AI存储成本降低69%。这个数字一出来，做AI基础设施的圈子基本都炸了。我身边好几个做大模型训练的朋友第一时间就在群里讨论，因为存储成本这件事，真的是每个跑AI任务的人都绕不过去的坎。

先把这个标题拆开看。阿里云是平台方，CPFS是产品名，全称是Cloud Parallel File System，也就是云上并行文件系统。全栈自研意味着从底层硬件到上层协议栈都是自己做的，不是基于开源方案改的。高性能存储是它的定位，AI存储是它的主战场。这几个关键词串起来，讲的就是一件事：阿里云针对AI场景重新做了一套并行文件系统，把成本打下来了。

那为什么AI场景对存储这么敏感？因为大模型训练和推理跟传统互联网业务完全不是一个路数。传统业务读写的是小文件、随机IO多，数据库和对象存储就能扛住。但AI训练不一样，它要的是高吞吐、大文件、顺序读为主、多客户端并发访问同一份数据。你想想，几百张GPU卡同时从存储里拉训练数据，每张卡每秒钟要吃掉几百MB甚至上GB的数据，这个带宽压力是传统存储架构根本顶不住的。

CPFS这类并行文件系统的核心价值就在这里。它把文件切成块分散到多个存储节点上，客户端可以同时从多个节点并行读取，聚合带宽能线性扩展。但问题也来了：性能上去了，成本也跟着上去了。传统的并行文件系统要么依赖昂贵的专用硬件，要么需要复杂的运维团队，中小企业根本玩不起。所以这次69%的降本数字，才是真正让圈内人兴奋的点。

这篇文章我打算从几个角度把这件事讲透：CPFS到底解决了什么问题，它的技术架构是怎么设计的，69%的成本是怎么省出来的，实际使用中怎么配置和调优，以及踩过的坑和排查经验。不管你是刚开始接触AI基础设施的新手，还是已经在跑训练任务的老兵，应该都能从中找到有用的东西。

2. CPFS到底解决什么问题：AI存储的核心需求拆解

2.1 传统存储在AI场景下的三个致命短板

要理解CPFS的价值，得先搞清楚传统存储在AI场景下到底哪里不行。我总结下来主要是三个短板，每一个都足以让训练任务跑不下去。

第一个短板是带宽瓶颈。对象存储比如OSS，单客户端的吞吐通常也就几百MB/s，就算你开多线程并发，聚合带宽也有限。而一个中等规模的训练集群，几十张A100同时拉数据，瞬间就能把带宽打满。结果就是GPU利用率上不去，卡在那儿等数据，钱白白烧着。我见过最夸张的情况，GPU利用率只有30%，剩下70%的时间都在等IO。

第二个短板是元数据性能。AI训练数据集动辄几百万甚至上千万个小文件，每个文件都要做open、stat、close这些元数据操作。传统NAS的元数据服务是单点或者弱分布式的，面对这种海量小文件场景，元数据操作延迟会急剧上升。有时候光是遍历一遍数据集就要几个小时，训练还没开始人已经崩溃了。

第三个短板是POSIX兼容性。很多AI框架和工具链是直接基于POSIX文件接口写的，比如PyTorch的DataLoader、TensorFlow的tf.data，它们默认就是按文件路径读数据。如果你用对象存储，就得改代码适配S3接口，或者加一层FUSE挂载，但FUSE的性能损耗又很大。这个兼容性问题看起来不起眼，实际落地时特别折磨人。

2.2 并行文件系统的核心原理：把带宽堆起来

CPFS这类并行文件系统的思路其实很直接：既然单个存储节点带宽有限，那就把数据分散到多个节点上，客户端同时从多个节点读，带宽自然就叠加起来了。这个道理跟 RAID 0 把多块盘组成一个逻辑卷提升吞吐是一个逻辑，只不过规模从磁盘级别放大到了节点级别。

具体来说，CPFS的架构里有两个关键角色：元数据节点和数据节点。元数据节点负责管理文件的目录结构、权限、位置信息这些元数据；数据节点负责实际存储文件内容。当客户端要读一个文件时，先问元数据节点这个文件的数据分布在哪几个数据节点上，然后直接跟这些数据节点建立连接并行读取。

这个架构的好处是元数据和数据分离，各自可以独立扩展。元数据压力大就加元数据节点，带宽不够就加数据节点。而且数据被切成固定大小的块（chunk）分散存储，单个大文件也能被多个客户端并行读取，这对AI训练里多worker同时读同一份数据的场景特别友好。

2.3 全栈自研意味着什么：从硬件到协议栈的垂直整合

标题里“全栈自研”这四个字值得单独说说。市面上很多并行文件系统是基于开源方案二次开发的，比如Lustre、GPFS这些老牌选手。基于开源方案的好处是成熟稳定，但坏处是你很难做深度优化，因为底层不是你的，改起来束手束脚。

阿里云这次强调全栈自研，意味着从存储介质、网络协议、文件系统协议栈到上层管理平台都是自己做的。这样做最大的优势是可以做端到端的垂直优化。举个例子，网络传输层可以根据AI负载的特点定制RDMA协议参数，文件系统层可以根据训练数据的访问模式预取数据，存储介质层可以根据冷热数据分布做分级。这些优化如果依赖开源方案，每一层都要跟社区扯皮，根本做不深。

另一个优势是成本控制。全栈自研意味着可以用自研的硬件或者定制化的硬件方案，不用被上游供应商卡脖子。存储这东西，硬件成本占大头，能把硬件成本压下来，整体成本自然就降了。69%这个数字，我猜测很大一部分就来自于硬件层面的优化和资源利用率的提升。

3. 69%成本是怎么省出来的：技术细节与实现路径

3.1 存储介质分级：把冷数据放到便宜的地方

降本最直接的手段就是存储介质分级。AI训练的数据其实有明显的冷热分布：正在被训练读取的数据是热数据，需要高性能介质；训练完的历史数据、备份数据是冷数据，放在便宜的大容量介质上就行。传统方案往往一刀切，所有数据都放在高性能存储上，成本自然高。

CPFS的做法应该是做了自动分级。热数据放在NVMe SSD上保证带宽，温数据放在SATA SSD或者高性能HDD上，冷数据沉到大容量HDD甚至对象存储里。关键是这个分级对用户透明，你看到的还是一个统一的文件系统路径，不用关心数据实际在哪一层。数据在层间流动由系统自动调度，根据访问频率动态调整。

这个思路跟CPU的缓存分级是一个道理：L1缓存最快但最小最贵，L3缓存慢一些但大很多也便宜很多。存储分级就是把这种思路放大到整个存储系统。实际用下来，如果数据集有明显的冷热分布，分级能省下的成本非常可观。

3.2 数据压缩与去重：同样的数据只存一份

AI数据集有个特点：重复率很高。同一个数据集可能被多个训练任务使用，数据预处理过程中也会产生大量中间文件。如果每个副本都完整存一份，存储利用率会很低。CPFS应该是在文件系统层面做了压缩和去重。

压缩这块，针对AI数据的特点，可能用了针对性的压缩算法。比如图像数据用有损压缩会影响训练精度，那就用无损压缩；文本数据压缩率通常很高，可以用更激进的算法。去重则是识别相同的数据块，只存一份，多个文件引用同一个数据块。这个技术在备份领域很成熟，但用在并行文件系统上需要解决并发访问和一致性问题。

注意：压缩和去重虽然省空间，但会消耗CPU资源。如果存储节点的CPU本身就很忙，开启压缩反而可能拖慢整体性能。实际配置时需要根据负载情况权衡。

3.3 资源池化与超卖：提升硬件利用率

云存储的成本大头是硬件，硬件利用率上去了，单位成本自然就下来了。传统存储方案为了保证性能，往往按峰值需求配置硬件，但峰值时间可能只占全天的一小部分，大部分时间硬件是闲置的。CPFS作为云服务，可以把多个用户的存储需求池化，通过智能调度提升整体利用率。

这个逻辑跟云服务器的超卖是一样的：物理资源是固定的，但通过调度让多个用户共享，整体利用率能从30%提升到70%甚至更高。当然存储的超卖比计算要谨慎，因为数据不能丢，但通过分级和调度，在保证性能的前提下提升利用率是完全可行的。

3.4 自研协议栈减少中间层开销

传统存储方案里，数据从存储介质到应用要经过很多层：块设备层、文件系统层、网络协议层、客户端缓存层等等。每一层都有开销，累加起来很可观。全栈自研的好处是可以把这些层打通，减少不必要的拷贝和转换。

比如RDMA网络传输，自研协议栈可以直接把数据从存储节点的内存传到客户端的内存，中间不需要CPU参与，也不需要多次拷贝。这个零拷贝的特性对高吞吐场景特别重要，既降低了延迟，又减少了CPU占用，间接降低了成本。

4. 实操配置：CPFS在AI训练场景下怎么用

4.1 创建文件系统与挂载配置

假设你已经在阿里云上有了ECS实例和CPFS文件系统，第一步是挂载。CPFS支持POSIX接口，挂载方式跟普通NFS类似，但需要安装专用的客户端。以下是一个典型的挂载配置流程。

首先安装CPFS客户端。不同操作系统的安装方式略有差异，以常见的Linux发行版为例：

安装完成后，需要配置挂载点。CPFS的挂载命令需要指定文件系统ID和挂载点：

这里的参数值得解释一下。rsize和wsize设置成1MB，是为了匹配AI训练的大块读写模式，减少网络往返次数。hard表示硬挂载，网络中断时会一直重试而不是报错返回，这对训练任务很重要，避免因为短暂网络抖动导致任务失败。timeo和retrans控制重试超时和次数。

提示：挂载参数里的rsize和wsize不是越大越好。如果设置得太大，单个请求的延迟会上升，反而影响小文件操作的性能。建议根据实际负载测试后调整，大文件为主就设大一些，小文件多就设小一些。

4.2 训练数据加载的性能调优

挂载好之后，怎么让训练任务高效地读数据是另一个关键。PyTorch的DataLoader是大家最常用的数据加载工具，但默认配置在CPFS上不一定最优。我实测下来，有几个参数需要重点调整。

num_workers控制数据加载的并行进程数。默认是0，意味着在主进程里加载数据，这会阻塞训练。建议设置成CPU核心数的2到4倍，让数据加载和GPU计算重叠起来。但也不是越大越好，太多worker会导致上下文切换开销增加，反而拖慢速度。

prefetch_factor控制每个worker预取多少批数据。默认是2，在CPFS这种高吞吐存储上可以适当调大，比如设成4或8，让数据提前加载到内存里，减少GPU等待。

pin_memory建议开启，它会把数据加载到锁页内存里，加速CPU到GPU的传输。这个参数对性能影响挺大的，尤其是小批量训练时。

persistent_workers这个参数容易被忽略，但它能避免每个epoch结束时销毁再重建worker进程，对多epoch训练能省下不少时间。

4.3 多节点并发读取的配置要点

大规模训练通常是多节点并行的，几十上百个节点同时从CPFS读数据。这时候要注意几个点。

首先是客户端缓存。CPFS客户端有本地缓存，重复读取的数据可以直接从缓存拿，不走网络。但缓存大小有限，如果数据集比缓存大很多，缓存命中率会很低。可以通过挂载参数调整缓存大小，但要注意别把客户端机器的内存吃光了。

其次是并发连接数。每个客户端跟存储节点建立的连接数是有限的，如果并发读取的线程太多，可能会在连接层面排队。可以通过调整客户端的并发参数来优化，但具体值需要根据存储集群的规格来定。

最后是数据局部性。如果多个节点读的是同一份数据，尽量让它们从相同的数据节点读，减少跨节点流量。CPFS应该会自动做数据分布优化，但用户侧也可以通过合理组织数据目录结构来辅助。

5. 常见问题与排查技巧实录

5.1 挂载失败与连接超时

挂载CPFS时最常见的问题是连接超时。报错信息通常是mount: mount point /mnt/cpfs does not exist或者connection timed out。排查思路按顺序来：

先检查网络连通性，用ping或者telnet测试挂载点的域名和端口是否可达。CPFS默认用的是2049端口，如果这个端口不通，大概率是安全组或者网络ACL没放行。去控制台检查安全组规则，确保入方向允许来自客户端IP的2049端口流量。

如果网络没问题，检查客户端版本是否跟服务端匹配。CPFS客户端和服务端有版本兼容性要求，版本差太多会挂载失败。用cpfs-client --version查看客户端版本，跟控制台上的服务端版本对比。

还有一种情况是挂载点被占用。如果之前挂载过没卸载干净，再次挂载会报错。用mount | grep cpfs查看是否有残留挂载，有的话先umount掉再重新挂。

5.2 训练过程中IO卡顿的排查

训练跑着跑着突然变慢，GPU利用率掉下来，这种问题最让人头疼。排查IO卡顿我一般按这个顺序来。

先看客户端侧的监控。用iostat -x 1看磁盘的%util和await，如果await很高说明IO延迟大。再用nfsstat或者CPFS自带的监控工具看客户端跟存储端的交互情况，重点看重传率和超时次数。

然后看存储侧的监控。阿里云控制台上有CPFS的性能监控面板，能看到带宽、IOPS、延迟这些指标。如果存储侧带宽打满了，说明是存储集群的瓶颈，需要扩容或者优化数据分布。如果存储侧很闲但客户端很忙，那问题可能在客户端或者网络。

网络问题容易被忽略。用iftop或者nload看客户端的网络流量，如果带宽跑满了说明网络是瓶颈。CPFS建议用高速网络，比如25Gbps以上的网卡，千兆网络肯定是不够的。

注意：排查IO问题时，一定要同时看客户端和存储端两边的监控。只看一边很容易误判。我踩过这个坑，客户端显示IO等待很高，我以为是存储慢，结果查了半天发现是客户端网卡带宽打满了。

5.3 小文件性能优化的实战经验

AI数据集里小文件多的时候，性能会明显下降。每个小文件的元数据操作都要走网络，延迟累加起来很可观。我试过几种优化方法，效果最好的是打包成大文件。

具体做法是把大量小文件合并成少数几个大文件，比如用TFRecord或者WebDataset格式。训练时顺序读取大文件，元数据操作从几百万次降到几百次，性能提升非常明显。代价是需要预处理数据，但一次预处理换来长期的高性能，很划算。

如果不想改数据格式，可以试试调整客户端的元数据缓存参数。CPFS客户端有元数据缓存，把常用的目录和文件属性缓存在本地，减少网络查询。但缓存大小有限，数据集太大时效果有限。

另一个技巧是预取目录结构。训练开始前先遍历一遍数据集目录，让元数据缓存预热。可以用find或者ls -R把目录结构刷一遍，虽然看起来笨，但实测能减少训练初期的卡顿。

5.4 成本控制的几个实用技巧

虽然CPFS已经比传统方案便宜很多，但用不好还是会产生不必要的费用。分享几个我总结的省钱技巧。

及时清理中间数据。训练过程中会产生大量checkpoint、日志、临时文件，这些东西如果不清理会一直占存储空间。建议设置生命周期规则，自动清理超过一定时间的临时文件。

合理设置数据分级。不是所有数据都需要高性能存储。训练完的数据集如果还要保留，可以转到低频存储或者归档存储，成本能降一个数量级。CPFS应该支持生命周期管理，配置好规则让系统自动迁移。

监控存储用量。定期看存储用量报表，找出占用空间大但访问频率低的数据，该删的删，该迁的迁。我见过一个团队存储费用居高不下，一查发现是半年前的训练数据一直没清理，白白花了好多钱。

6. 这套方案适合谁用：场景匹配与选型建议

6.1 大模型训练场景的适配分析

CPFS最典型的应用场景就是大模型训练。不管是预训练还是微调，只要涉及多卡多节点并行，存储带宽就是刚需。CPFS的高吞吐和POSIX兼容性，让它能直接对接PyTorch、TensorFlow这些主流框架，不需要改代码。

具体来说，如果你的训练集群规模在几十张卡以上，数据集大小在TB级别，那CPFS基本是必选项。小规模训练用本地SSD或者普通NAS也能凑合，但规模上去之后，存储就会成为瓶颈。我见过太多团队在GPU上花了大钱，结果因为存储拖后腿，GPU利用率只有一半，等于白烧钱。

6.2 推理场景的存储需求差异

推理场景跟训练不太一样。推理对存储的带宽要求没那么高，但对延迟更敏感。用户请求过来，模型要快速加载，如果存储延迟高，推理响应时间就上去了。

CPFS在推理场景也有用武之地，主要是模型文件的存储和分发。大模型动辄几十GB，多个推理节点同时加载模型，用CPFS并行读取比从对象存储拉快很多。而且CPFS的缓存机制能让热点模型常驻缓存，进一步降低加载延迟。

不过如果推理规模不大，用对象存储加本地缓存也能满足需求，不一定非要上CPFS。选型时要根据实际规模和性能要求来定，别为了用而用。

6.3 跟其他存储方案的对比选型

选存储方案时，CPFS不是唯一选择。我把常见的几种方案列出来对比一下，方便大家根据自己情况选。

从表里能看出来，CPFS的定位很明确：大规模AI训练场景下，它在带宽、延迟、兼容性上都是最优解，成本虽然比对象存储高，但比本地SSD便宜很多。如果你的场景是海量小文件归档，对象存储更合适；如果是单机小规模训练，本地SSD就够了。

选型的核心原则是匹配场景。别盲目追求高性能，也别为了省钱牺牲性能。算一笔账：如果存储拖慢训练导致GPU利用率下降，浪费的GPU费用可能远超存储省下的钱。这个账要算清楚。

7. 我个人的使用体会与几个实用建议

用CPFS跑了一段时间训练任务，有几个体会比较深。第一个是挂载参数一定要调，默认参数是通用场景的折中，针对AI负载优化后性能提升很明显。我实测调整rsize和wsize之后，大文件读取带宽提升了将近30%。

第二个是监控要提前做。别等出问题了才去看监控，训练开始前就把客户端和存储端的监控配好，设置好告警阈值。IO问题往往是渐进的，早发现早处理，别等到训练跑了一半才崩。

第三个是数据预处理值得投入。把数据整理成适合并行读取的格式，虽然前期花时间，但长期收益很大。我见过太多团队在数据格式上偷懒，结果训练时各种IO问题，修修补补浪费的时间远超预处理的时间。

最后分享一个小技巧：如果训练任务对存储性能要求特别高，可以考虑把最热的数据集缓存在本地SSD上，CPFS作为二级存储。这样既享受了CPFS的大容量和低成本，又用本地SSD保证了极致性能。这个混合方案在实际使用中效果很好，值得一试。