从去年开始,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 且不保证数据的强一致性,因此适用的使用场景有所差异。
在支持海量小文件方面,挑战主要体现在文件元数据的

最低0.47元/天 解锁文章

被折叠的 条评论
为什么被折叠?



