移动网站营销,桂林网站开发,免费发布广告信息的网站,建设教育培训的网站从去年开始#xff0c;LLM大语言模型领域发展迅速、如 LLaMA、ChatGLM、Baichuan、Qwen 和 yi-model 等基础模型#xff08;Foundation Models#xff09;的数量显著增加。众多企业也开始基于这些基础模型做 post-training 的相关工作#xff0c;以开发特定垂直领域的模型实…从去年开始LLM大语言模型领域发展迅速、如 LLaMA、ChatGLM、Baichuan、Qwen 和 yi-model 等基础模型Foundation Models的数量显著增加。众多企业也开始基于这些基础模型做 post-training 的相关工作以开发特定垂直领域的模型实现应用落地。
AI 模型的参数规模呈指数级增长出现了越来越多的千亿甚至万亿参数的通用大模型。例如最新的 llama3 模型就提供了 405B、70B 和 8B 三个版本模型参数量不断刷新给企业存储的成本与规划带来很大挑战。除了模型规模的增长大模型开发的复杂流程和高效的数据流转也对存储系统提出了更高的要求这直接影响到整个流程的效率。 另外大规模训练和推理对于GPU算力的需求导致算力的供给越来越多的转变为多云、多region 的模式在这种情况下又给用户带来了数据集、模型在多区域间进行分发、同步以及一致性管理的挑战。
在本文中我们将简要介绍我们对大模型存储选型的思考、开发中不同阶段的工作负载需求包括成本、性能和功能等多个维度并探讨如何通过 JuiceFS 帮助用户优化这些环节。
01 大模型存储选型思考
针对数据量大和数据流转复杂的挑战通常采用的解决方案是建立统一的数据管理也就是数据湖。这种方法通过统一命名空间在后端存储不同类型的数据同时前端提供多样化的数据访问方式有效减少了复杂数据管道中数据流转的难度和成本。
尽管理想很完美但现实中如何设计一个统一的技术栈或产品来实现这些目标颇具挑战。从支持前端数据处理框架的角度来看全面兼容 POSIX 协议的文件系统目前看来是最佳方案。
此外文件系统还需支持庞大的文件规模既要能支持数百亿文件的存储又要保证在此规模下的文件访问性能这就需要文件系统具备高效的元数据管理能力和多级缓存等高性能实现。
还包括对其他容器平台存储编排的支持、灵活的横向扩展能力以及多云多数据中心的数据同步支持等这些都是选择数据湖产品时需要考虑的关键因素。
以下表格中列举了市场上一些常见的文件系统产品并进行了多维度的横向比较。希望能为大家选型时提供参考。 JuiceFS 用户在选型过程中常询问的产品包括 CephFS、Lustre 和 Alluxio 我们将重点梳理这 3 个产品的差异。
我们从产品定位角度来比较这几款产品。
在对数据处理框架的支持方面需要更好的 POSIX 协议兼容性。
JuiceFS、CephFS 和 Lustre 都是文件系统因此它们均提供较全面的 POSIX 支持并确保数据在不同环节的强一致性Alluxio 主要定位为数据编排和加速工具只部分支持 POSIX 且不保证数据的强一致性因此适用的使用场景有所差异。
在支持海量小文件方面挑战主要体现在文件元数据的管理能力和性能上。
CephFS 和 Lustre 利用磁盘存储元数据并通过内存缓存进行性能加速文件规模达到一定量级后元数据的管理和使用成本会明显增加Alluxio 提供基于 RocksDB 和基于堆内存的两种元数据存储方案用户可以根据自己的需求选择适合的方案JuiceFS 使用对象存储作为后端该存储方式具有扁平命名空间、高可扩展性和低成本等特点非常适合存储海量文件。社区版的元数据引擎采用开放的插件架构设计用户可以根据文件规模、性能需求、使用习惯等从多种主流的开源数据库中进行选择来作为元数据存储 而企业版的则是自研了基于全内存实现的元数据引擎服务针对文件目录树管理从元数据访问性能、横向扩展能力几个方面进行定制优化。
在多云数据管理方面需要对用户透明的文件系统级别复制能力。
CephFS 和 Lustre本身不具备文件系统级别复制功能需要通过存储底座的复制功能或者第三方工具来实现在数据一致性上难以保障也会增加额外的管理成本。JuiceFS 和Alluxio 都提供了对用户透明的多云、多 region 的数据分发能力。除此以外JuiceFS 还提供了在镜像站点文件系统可写的能力 总结一下 JuiceFS 在数据湖存储中的给用户带来的收益
统一命名空间提供多协议访问完整的 POSIX 协议兼容性百亿级别文件规模的支持数据强一致性高并发共享访问能力不同负载的性能优化。多云、多region的数据分发和访问。
02 JuiceFS 在大模型场景的实践
环节1数据集加载
大模型训练的数据集加载有两个关键点数据集需要被反复多轮遍历即多个 epoch并且在每个 epoch 开始之前数据集需要被随机打乱。这样做是为了确保模型能够充分学习数据中的模式并避免过拟合。接着这些被随机打散的数据集按批次加载到 GPU 显存中进行处理。
由于这些数据处理主要依赖 CPU 资源因此 GPU 在这一阶段往往处于空闲。用户需要提升数据集加载的效率如使用缓存从而减少 GPU 的闲置时间。数据集通常以结构化大文件如 FFRecord、TFRecord、Arrow或海量小文件如未打包的文本、图片、音频等形式。
数据集的随机打散过程需要随机读取数据文件结合数据集文件的格式数据集加载流程对于存储的 I/O 模型是大、小文件随机读。随机读 I/O 需要文件系统具备高 IOPS 和低 I/O 延迟尤其对于海量小文件随机读的 I/O 处理对文件系统元数据引擎的性能提出了更高要求。另外数据集在一次训练过程被反复读取那数据如果都能被缓存在高性能存储介质中实现高缓存命中率就可以最大程度的提升数据读取的性能。
JuiceFS 的设计目标是帮助用户在性能和成本之间找到最佳平衡。它通过利用对象存储作为后端数据持久化手段并结合多级缓存加速架构为数据集加载提供了高 IOPS 和低 IO 延迟同时保持成本效益。下面列出了使用 JuiceFS 进行小 IO 随机读操作的一些性能指标
命中本地缓存时延迟在 0.05 到 0.1 毫秒之间命中分布式缓存企业版特性时延迟在 0.1 到 0.2 毫秒之间直接从对象存储读取时延迟超过 30 到 50毫秒。
使用 libaio 可以获得更高的 IOPS但这需要集成特定框架扩展以支持 libaio 接口。另外JuiceFS 企业版提供自研的全内存实现的元数据引擎可以在管理海量文件规模的情况下保证元数据请求的平均处理时间维持在 100 微秒量级在海量小文件的数据集加载场景中也得到很好的性能。另外通过元数据引擎多分区的架构实现提供了根据文件规模动态线性的扩展能力。
下面附上一组用户的大文件随机读测试数据帮助大家理解 JuiceFS 的性能。测试数据为单个 1.8TB 文件。 环节2训练环节 checkpoint 保存
对训练环节的 checkpoint 文件进行保存是为了在训练中断时可以从最近的 checkpoint 进行训练恢复避免从头开始从而节约时间和计算资源。如果采用同步写 checkpoint那么在保存 checkpoint 的时间窗口内GPU 会全部等待。通常checkpoint 写入都是大文件的顺序写。要尽量缩短这个过程的时间就需要文件系统提供高性能的写吞吐能力。
JuiceFS 通过对接对象存储作为数据持久化层其吞吐上限受限于对象存储的写带宽、专线带宽以及 JuiceFS 客户端所在节点的网卡带宽。JuiceFS 采用分块存储设计通过增加对对象存储的并发可以充分利用对象存储带宽来提升大文件顺序写的吞吐能力。
此外JuiceFS 还提供写缓存功能。若后端对象存储存在性能瓶颈可考虑开启 writeback 写缓存利用 GPU 节点的 NVMe 高速存储介质作为本地缓存首先将 checkpoint 文件写入本地然后再异步上传到对象存储这有助于减少写入延迟。这里需要注意开启 writeback 写缓存可能会在一些场景中导致 checkpoint 文件不一致无法正常加载恢复训练针对这种情况就需要加载上一个窗口的 checkpoint 文件进行恢复从而重跑一些训练 epcoh。
根据用户实际应用的验证在通过 torch.save 向 JuiceFS 文件系统保存 checkpoint 的场景每个 GPU 单卡启动的一个写 checkpoint 进程 可以达到 1.7GB/s 或更高的写吞吐能够满足该场景的性能要求。
环节3训练和推理环节的模型加载
典型的模型加载场景包括 训练恢复加载 Checkpoint 文件场景在训练恢复阶段采用并行训练的节点仅加载其 rank 的分片 checkpoint 文件所有节点需要加载的总文件大小就是所有分片 checkpoint 大小的总和加载 checkpoint 文件的效率决定了 GPU 等待训练恢复的时长直接影响 GPU 的利用率。 推理服务加载模型文件场景: 将训练好的模型部署到推理服务中一般需要在推理节点启动时加载完整的模型文件。当推理节点的数量很多时如运行上千个推理节点同时加载模型每个节点都需要从文件存储上去读取一个完整的模型文件这时会产生非常大的读吞吐如果网络吞吐成为瓶颈模型的加载效率就会很慢。如果文件存储是采用公有云上的对象存储那对象存储的带宽、专线带宽等都很容易成为瓶颈而且每个节点都从对象存储 get 完整的模型文件也会产生大量额外的对象存储带宽和调用成本。
值得注意的是在模型加载环节中模型文件的不同格式对存储 I/O 模型的需求不一样。模型文件可能会采用 torch.save 保存的 .pt、.bin 文件或使用 safetensors 库保存的 .safetensors 文件。其中 safetensors 文件较为特殊加载时会采用 mmap 方式对存储的 I/O 模型为大文件的随机读而其他格式文件的加载则是大文件的顺序读。针对这两类不同格式的模型加载的需求来看一下 JuiceFS 的方案。
JuiceFS 对 safetensors 格式模型文件加载大文件随机读的优化实践包括提前将这些文件预热到缓存中以获得高文件读取 IOPS 和低延迟的性能。最终性能将受限于缓存介质的 IOPS 能力和JuiceFS 客户端的网络环境。此外为减少预读可能导致的读放大问题考虑关闭 prefetch 预取功能。若需进一步优化 safetensors 文件的加载性能可以在模型加载前预读文件到内核的 pagecache 中这一步骤能显著提高 safetensors 文件的加载速度性能相较于从 JuiceFS 缓存中读取可提高一个数量级。
JuiceFS 对其他格式模型文件加载大文件顺序读的优化策略JuiceFS 通过预读功能来提升大文件顺序读的性能。此功能可以预测并提前加载未来可能请求的数据块到内存中通过合理配置预读窗口大小并增加访问对象存储的并发数充分利用对象存储带宽。最终读吞吐性能的上限主要受限于对象存储的带宽或到对象存储专线的带宽。此外预热 checkpoint 或模型文件到缓存中可以进一步提高性能例如 8 卡单机加载 checkpoint 的情况下在网卡带宽足够的情况下热读的吞吐量可达到 10GB/s 以上足以应对用户对该场景的性能要求。另外在推理加载模型文件的场景中通过预热的方式只需要缓存集群从对象存储上 get一次完整的模型文件后面推理节点从缓存中读取最大程度提升了读吞吐能力也节省使用公有云对象存储的带宽和调用成本。
环节4混合云架构数据快速分发的需求
随着大模型的普及GPU 算力成为一种稀缺资源尤其是在国内环境中不像过去 CPU 资源那样容易获取。尤其是需要进行通用模型预训练的用户常常需要处理跨地域和多数据中心算力协作的问题这就要求存储资源能够根据算力的地理位置灵活配置确保数据能随算力分布。
JuiceFS 通过其镜像文件系统功能实现数据从主站到其他镜像站点的自动同步元数据同步在确定的时间窗口内完成同城可以达到毫秒级延迟跨城市在国内约为 10-30 毫秒在指定时间窗口内镜像站点保证数据一致性实际数据复制在后台异步完成。一旦元数据同步完成数据即可在各站点访问如果实际数据尚未完全同步到镜像站点JuiceFS 客户端会自动将请求路由到主站点的对象存储以获取数据虽有性能损失但数据访问不会中断并对用户透明。
在这种混合云架构中为了更好地控制成本建议在一个地点部署对象存储各站点本地部署足以容纳训练集数据的缓存集群以实现近100% 的缓存命中率。数据预先从共用对象存储预热到各站点的缓存集群中这种部署方式是AI场景中用户最广泛采用的。
下图是一个用户的一主三镜像站点的混合云算力集群架构。每个站点都通过缓存组实现了数据访问的加速。 值得一提的是在最新企业版中JuiceFS 新增了镜像集群的可写功能。在多站点训练场景中当各个镜像站点的训练集群分别保存 checkpoint 文件并写入到各自站点的 JuiceFS 文件系统时将自动写到主站点文件系统的元数据和对象存储并进行其他镜像站点的分发这里元数据的复制是同步的保证在镜像集群写数据的版本一致性。这一功能简化并加快后续训练任务的 checkpoint 恢复以及推理服务模型加载的流程更好的保证在镜像集群训练和推理的数据一致性。镜像站点的写入性能此时会受到站点间专线网络状况的影响
03 小结
针对大数据量和复杂数据流转所带来的挑战常见的解决方案包括建立统一的数据管理系统即数据湖。这种策略通过采用统一的命名空间来在后端存储不同类型的数据同时在前端提供多样化的数据访问方式从而有效降低了复杂数据管道中数据流转的难度和成本。
在文件存储系统的选择上用户可以从基础架构、性能、兼容性、以及易用性等多方面考虑以选定最适合的产品。JuiceFS 利用廉价的对象存储作为后端数据持久化手段并结合多级缓存加速架构为用户提供提供高成本效益的存储方案。
此外文章还探讨了在下述关键环节 JuiceFS 实践与优化策略。
数据集加载数据集大文件和海量小文件的随机读需要需要文件系统具备高 IOPS 和低 I/O 延迟以及高性能的元数据访问训练环节 checkpoint 保存checkpoint 大文件的顺序写需要文件系统提供高性能的写吞吐能力训练和推理环节模型加载safetensors 格式 checkpoint/ 模型大文件的随机读需要需要文件系统具备高 IOPS 和低 I/O 延迟其他格式 checkpoint 模型大文件的顺序读需要文件系统提供高性能的读吞吐能力大规模推理节点并发加载模型的带宽瓶颈问题混合云架构数据分发可保证数据一致性的镜像读写功能满足多区域协同训练中的数据集分发、checkpoint 保存多区域推理服务的模型部署。
希望这篇内容能够对你有一些帮助如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。
