稿定科技:多云架构下的 AI 存储挑战与 JuiceFS 实践
稿定科技(gaoding.com)是一家专注于为企业和个人提供视觉内容创新方案的科技公司,致力于打造全新的设计方式,帮助更多用户轻松掌控设计,创造价值。
随着 AI 技术的加速发展,数据存储和管理成为支撑公司创新与发展的关键基础设施。最初,"稿定"的 AI 训练数据主要依赖公有云厂商提供的对象存储和 NAS 服务。但随着业务快速发展,单一云厂商的 GPU 资源已无法满足需求,"稿定"逐步转向多云架构,以获取更灵活的计算资源。但这也带来了新的技术难题:如何在多个云环境中统一管理训练数据,实现高效、低成本的跨云读写访问。
JuiceFS 正是在这一背景下被引入,其出色的多云兼容性、灵活的挂载机制与完善的工具支持,帮助"稿定"快速打通了不同云环境间的数据访问通路。目前,JuiceFS 管理了其训练数据和模型库,极大简化了模型数据在多云环境下的管理流程,高效的缓存机制显著加快了训练过程中的数据加载,同时加速了模型推理阶段的挂载响应,为业务带来了实质性的性能与效率提升。
01 训练场景的存储挑战:数据规模、性能与多云难题
随着人工智能业务的迅速发展,稿定运维体系面临诸多新挑战,其中存储无疑是最为关键的环节之一。AI 模型训练通常包含五个主要步骤,而每个环节几乎都离不开数据存储的支持。
- 数据处理: 根据需求从各种渠道收集并存储原始数据。
- 数据清洗与加工: 对收集到的数据进行清洗、裁剪和预处理。
- 模型训练: 基于处理好的数据和算法模型进行训练。
- 模型产出与验证: 训练完成后生成模型,并对其进行基本的性能和质量验证。
- 推理服务: 模型验证无误后,部署上线提供推理服务。
在这一过程中,模型训练环节面临的存储挑战最大,呈现出下三大特点:
数据规模庞大: 相较于常规工作中常见的几十 GB 甚至一两 TB 的数据,AI 训练数据往往体量巨大,小则几十 GB,大则可达几十 TB 甚至上百 TB。
数据读取性能要求极高: 模型训练离不开昂贵的 GPU 资源。如果数据读取性能不佳,导致 GPU 使用率低下,将造成巨大的资源浪费。
热数据管理需求: 模型训练通常会对同一批数据进行多次迭代使用。这意味着当前使用的数据很可能在不久的将来会被再次访问,因此希望能够将这些数据缓存起来,以提高后续读取速度。
若采用常规存储方案作为训练数据存储,将面临诸多问题:对于本地磁盘,采购和维护大容量磁盘成本较高,且单块磁盘容量有限,需多个磁盘支持大规模数据存储。此外,数据与计算紧密绑定,任务必须调度到数据所在的服务器,缺乏调度灵活性。
对象存储的最大优势是低廉的存储成本,并且公有云厂商提供的 CSI(容器存储接口)使得挂载更加便捷。然而,尽管成本低,读写性能较差,无法满足大规模数据训练对高性能存储的需求。
公有云 NAS 是许多训练数据存储的常见解决方案,但存在几个问题:操作效率较低,尤其在数据删除和拷贝时速度较慢;权限管理功能不够细粒化,权限控制存在不足;数据统计困难,难以准确计算目录下的数据量。虽然像阿里云 CPFS 等高级 NAS 服务能够提升性能,但其成本明显增加。
除了上述存储方案的局限性,我们还面临更大的挑战:单一公有云厂商已无法提供足够的 GPU 资源。由于全球芯片供应紧张,获取高性能 GPU 越发困难,这迫使我们考虑采用多云策略。然而,多云环境带来了新的存储难题:如何在不同云厂商之间共享训练数据?每家云厂商的 NAS 服务差异较大,若要自行解决数据共享和同步问题,将是一个复杂且耗时的工程。
因此,我们不得不重新审视和规划所需的存储架构,以期能够满足在多云环境下进行 AI 训练的严苛需求。
02 为什么选择 JuiceFS?
经过一系列选型,我们最终选择了 JuiceFS 作为存储解决方案,主要基于以下考量:
-
多云架构支持: JuiceFS 能够无缝对接大多数公有云平台。通过其数据跨区域复制或镜像文件系统功能,我们能便捷地实现多云或多区域之间的数据共享,解决了跨区域数据管理和同步的复杂性。
-
卓越的数据读取能力: 借助 JuiceFS 独特的分布式多级缓存机制,它能够提供极其出色的数据读取性能,这对于对 IOPS 和吞吐量要求极高的 AI 训练场景至关重要。
-
核心数据管理能力:
- 权限控制: 尽管 JuiceFS 的权限控制是基于 Token 级别的,但已完全能够满足我们的日常业务需求。
- 回收站功能: 提供了回收站机制,当数据被误删除时,能够快速进行恢复,有效保障了数据安全。
-
完善的工具链: JuiceFS 提供了一套相对完整的工具链,极大便利了我们的运维与管理
- CSI 支持: 对我们而言,CSI 至关重要,它使得 JuiceFS 在 Kubernetes 环境下的部署和使用变得非常简便。
- 监控体系: JuiceFS 提供了丰富的监控信息,使我们能够方便快捷地排查问题。
- 命令行工具:JuiceFS 的命令行工具功能强大且易于使用,特别是其中的克隆功能。数据处理前,通常需要进行备份,而传统的拷贝方式速度较慢。相比之下,JuiceFS 的克隆功能能够在秒级完成大数据量(如 1TB 或 2TB)的处理,显著提高了工作效率。
以下是我们在选型过程中对 JuiceFS 和某 NAS 方案进行的性能比较测试,主要模拟日常 AI 训练中常见的图片数据。我们使用了随机生成的 1 万个文件,大小从 200KB 到 3MB 不等,总计 10K 数据。
测试结果显示:
- 有数据缓存的情况下,JuiceFS 的读取性能遥遥领先。
- 没有缓存的情况下,其性能可能会略低于 NAS。
但在实际 AI 训练任务中,所用的数据通常是预知的,我们可以在训练任务开始前进行数据预热,从而确保数据已建立缓存。在这种情况下,JuiceFS 的读取性能优势将得以充分发挥。在多点并行写入场景下,JuiceFS 的性能也优于 NAS。
03 多云模型数据存储实践
多云需求是我们架构中的关键问题之一,因此在此我们对其进行详细介绍。最初,我们的模型数据存储方案主要包括两种方式:
第一种是将模型上传至对象存储。在打包镜像时:一是将模型直接打包进镜像。由于部分模型体积较大,可能达到十几 GB,这会导致镜像体积增加至 20 多GB,进而造成镜像拉取缓慢,甚至超时。二是在服务容器启动时通过链接获取模型。如果服务有多个实例,下载时间将大幅增加,可能导致效率低下。我们曾有一个服务采用此方式,十几个实例的滚动更新需超过一个小时。无论采用哪种方式,都会在K8s集群中存储多份模型数据,造成存储资源的浪费。
第二种方案是将模型存储到 NAS,服务容器挂载 NAS 使用。此方案存在两个问题:其一,由于业务部署在国内外多个区域及不同云厂商,需要手动管理多个区域的模型数据同步;其二, NAS 的模型加载性能一般,容易导致业务请求超时。实际测试表明,每次加载模型所需时间大致相同。
引入 JuiceFS 后,我们使用其镜像文件系统功能来建设多地域模型存储架构。如下图所示,该架构中,左侧是源文件系统,右侧对应多个镜像文件系统。我们只需将模型导入到源文件系统,其他区域的镜像文件系统便会自动同步这些模型数据。即使模型数据尚未完全同步过来,业务访问时也会自动回源读取。整个数据管理流程大为简化,且缓存后的模型数据加载速度提高,JuiceFS 的加载性能约为传统 NAS 的三倍。
通过引入 JuiceFS,我们有效简化了跨云数据共享的复杂性,减轻了多云环境中的存储压力。此外,JuiceFS 提升了数据读取性能,显著提高了 GPU 利用率,从而优化了整体训练过程。通过优化存储架构并充分利用闲置资源,我们降低了存储成本和人工管理成本,提升了运维效率。希望我们的实践经验能为社区用户在多云存储架构优化方面提供一些参考。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
AI 智能体记忆机制详解
编者按: 为什么我们总是感觉在与 AI 助手重复着同样的对话?为什么明明告诉过它的重要信息,五分钟后它就完全遗忘了? 我们今天为大家带来的文章,作者的观点是:记忆能力是 AI 从工具进阶为真正智能伙伴的关键桥梁,只有具备完善的记忆系统,AI 才能提供个性化体验、拥有持续学习和处理复杂任务的能力。 本文深度解析了记忆增强型 AI 系统的核心技术架构,介绍了"观察→记忆→行动→反思→更新"这一认知闭环解决方案。作者还系统阐述了从实时内存状态到向量数据库的多层次存储机制,并详细解析了工作记忆、情景记忆和语义记忆这三种记忆类型。 作者 | Bhavishya Pandit 编译 | 岳扬 是否总感觉你在和 AI 助手重复着同样的对话?你告诉它一些重要的事情,五分钟后,它就忘了。很长一段时间以来,这就是和大多数 AI 进行对话的现实情况。它们非常聪明,却只有金鱼般的记忆。 但这种情况正在改变。如今,AI 小伙伴能记住我们上周的对话,回想起我们的喜好,并从与我们长期的交流互动中学习。这是目前人工智能的前沿领域之一,也是我想在今天这篇文章中深入探讨的主题:AI 记忆能力的精妙之处。让我们来分析一下,...
- 下一篇
我为什么又开始手写Agent框架了?从CrewAI和LangGraph的局限谈起
一、 引言:被"框架"困住的我们 嗨,大家好,我是技术老金。 最近,我发现自己陷入了一个有趣的困境。 当我想快速搭建一个多智能体(Multi-Agent)应用时,我首先想到了CrewAI。它就像一个精装修的公寓,角色、任务、流程都替你定义好了,拎包入住,很快就能跑起来。但只要我想稍微改动一下"房型",比如让两个Agent先碰个头,或者根据某个工具的执行结果,动态决定下一步谁来接手,我就会发现自己被困在了这精美的"枷锁"里,动弹不得。 于是,我转向了LangGraph。它就像一个堆满了顶级建材(节点、边、状态)的"毛坯房",给了我无限的自由。我可以随心所-欲地设计任何我想要的流程,循环、分支、判断,无所不能。但很快,新的问题来了:我发现我不仅要设计流程,还要亲自设计状态管理、消息传递、工具调用、错误处理......我需要从零开始,为这个毛坯房设计一整套"水电煤"系统。 我们似乎被困在了两难的境地:要么选择一个僵化的"应用级"框架,要么选择一个过于灵活的"引擎级"工具。 有没有一条中间道路? 在反复挣扎和实践后,我得出了一个结论:有。那就是在LangGraph这种强大的"引擎"之上,构建一...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS关闭SELinux安全模块
- Linux系统CentOS6、CentOS7手动修改IP地址
- 2048小游戏-低调大师作品
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池