面向 AI 的存储架构师指南

这篇文章最初出现在 The New Stack 上。
开发人员倾向于使用软件定义、开源、云原生和简单的技术。这基本上就是对象存储的定义。
引言
为机器学习 (ML) 项目的所有阶段选择最佳存储至关重要。研究工程师需要创建多个数据集版本并试验不同的模型架构。当模型被提升到生产环境时,它必须在对新数据进行预测时高效运行。— 在生产环境中运行的经过良好训练的模型是将 AI 添加到应用程序中的关键,因此这是最终目标。
作为 AI/ML 架构师,这已经是我过去几年的生活了。我想分享我对模型训练和服务项目的必要条件以及可用选项的了解。可以将其视为一项调查。我将涵盖从传统文件系统变体到为大型语言模型 (LLM) 和其他生成式 AI 系统的大规模性能要求而设计的现代云原生对象存储的一切。
一旦我们了解了必要条件和存储选项,我将回顾每个选项,看看它如何与我们的必要条件相符。
在我们深入研究必要条件之前,回顾一下当今软件行业的现状将是有益的。正如你将看到的,机器学习和人工智能的演进正在推动必要条件。
当前的 ML 和 AI 状态
能够以接近人类精度的对话方式进行交流的大型语言模型 (LLM) 正在主导媒体。这些模型需要大量数据来训练。还有许多关于生成式 AI 的其他令人兴奋的进步,例如,文本到图像和声音生成。这些也需要大量数据。
不只是关于 LLM。还存在其他类型的模型可以解决基本的业务流程问题。回归、分类和多标签是非生成式模型类型,但可以为企业增加实际价值。越来越多的组织正在寻求使用这些类型的模型来解决各种问题。
另一个现象是,越来越多的企业正在成为 SaaS 供应商,他们使用客户的私有数据提供模型训练服务。考虑一下工程师使用来自互联网和数千本书籍的数据训练的 LLM,以回答问题,就像 ChatGPT 一样。这个 LLM 将是一个通才,能够回答各种主题的基本问题。但是,如果用户问一个需要医疗保健、金融服务或专业服务等特定行业的高级知识的问题,它可能无法提供有帮助、详细和完整的答案。可以通过额外的数据微调已训练的模型。因此,经过通才训练的 LLM 可以用特定行业的额外数据进行进一步训练。然后,该模型将能够更好地回答有关该行业的问题。微调在使用 LLM 时尤其有用,因为它们的初始训练成本可能高达数百万美元,而微调成本则便宜得多。
无论你构建的是哪种模型,一旦它进入生产环境,它就必须像你作为应用程序一部分部署的任何其他服务一样,可用、可扩展且具有弹性。如果你是一家提供 SaaS 解决方案的企业,你将有额外的安全要求。你需要防止直接访问任何代表你的竞争优势的模型,并且你需要保护客户的数据。
让我们更详细地看一下这些必要条件。
机器学习存储必要条件
下面列出的存储必要条件是来自技术决策者的角度,评估任何技术可行性。具体来说,用于软件解决方案的技术必须可扩展、可用、安全、高效、具有弹性和简单。让我们看看每个必要条件对机器学习项目意味着什么。
可扩展性:存储解决方案中的可扩展性是指它能够在不进行重大更改的情况下处理越来越多的存储量。换句话说,可扩展的存储可以随着容量和吞吐量需求的增加而继续以最佳方式运行。考虑一家组织从单个项目开始其 ML/AI 之旅。这个项目本身可能没有很大的存储需求。但是,很快其他团队将创建自己的计划。这些新团队可能只有很小的存储需求。但是,总体而言,这些团队可能会对中央存储解决方案施加相当大的存储需求。可扩展的存储解决方案应该扩展其资源(横向扩展或纵向扩展)以处理新团队加入后所需的额外容量和吞吐量。
可用性— 可用性是指运行系统执行任务的能力。运维人员通常会衡量整个系统在时间上的可用性。例如,该系统在当月 99.999% 的时间内处于可用状态。可用性也可以指单个请求在资源可以开始处理它之前经历的等待时间。过长的等待时间会导致系统不可用。
无论定义如何,可用性对于模型训练和存储都是必不可少的。模型训练不应因存储解决方案的可用性不足而出现延迟。生产环境中的模型应该在当月 99.999% 的时间内处于可用状态。对数据或模型本身的请求(可能很大)应该经历较短的等待时间。
安全— 在所有读写操作之前,存储系统应该知道你是谁以及你能做什么。换句话说,存储访问需要进行身份验证和授权。数据也应该在静止状态下安全,并提供加密选项。上一节中提到的假设 SaaS 供应商必须密切关注安全性,因为他们为客户提供多租户。锁定数据、版本数据和指定保留策略也是安全需求的一部分。
性能— 高效的存储解决方案针对高吞吐量和低延迟进行了优化。性能在模型训练期间至关重要,因为更高的性能意味着实验完成得更快。ML 工程师可以执行的实验次数与最终模型的准确性成正比。如果使用神经网络,将需要进行许多实验才能确定最佳架构。此外,超参数调整需要进行更进一步的实验。使用 GPU 的组织必须注意防止存储成为瓶颈。如果存储解决方案无法以等于或大于 GPU 处理速度的速度提供数据,则系统将浪费宝贵的 GPU 周期。
弹性— 具有弹性的存储解决方案不应具有单点故障。具有弹性的系统试图防止故障,但在发生故障时,它可以优雅地恢复。此类解决方案应该能够参与故障转移和保持演练,其中整个数据中心丢失被模拟以测试整个应用程序的弹性。
在生产环境中运行的模型需要弹性。但是,弹性也可以为模型训练增加价值。假设一个 ML 团队使用使用集群的分布式训练技术。在这种情况下,为该集群提供服务的存储以及集群本身应该具有容错性,以防止团队因故障而损失数小时或数天。
简单— 工程师将“简单”和“美观”这两个词同义使用。这是有原因的。当软件设计简单时,它就经过了深思熟虑。简单的设计适用于许多不同的场景,并且可以解决许多问题。用于 ML 的存储系统应该很简单,尤其是在新 ML 项目的概念验证 (PoC) 阶段,此时研究人员需要专注于特征工程、模型架构和超参数调整,同时试图提高模型的性能,使其足够准确,从而为企业增加价值。
存储环境
有几种用于机器学习和服务的存储选项。今天,这些选项分为以下几类:本地文件存储、网络附加存储 (NAS)、存储区域网络 (SAN)、分布式文件系统 (DFS) 和对象存储。在本节中,我将讨论每一个选项,并将它们与我们的必要条件进行比较。目标是找到一个在所有必要条件中表现最好的选项。
本地文件存储:研究人员工作站上的文件系统和专用于模型服务的服务器上的文件系统是用于 ML 存储的本地文件系统的示例。本地存储的底层设备通常是固态硬盘 (SSD),但它也可能是更先进的非易失性内存表达驱动器 (NVMe)。在这两种情况下,计算和存储都在同一个系统上。
这是最简单的选项。它也是PoC阶段的常见选择,在这个阶段,一个小型研发团队试图从模型中获得足够的性能来证明进一步支出的合理性。虽然很常见,但这种方法也有一些缺点。
本地文件系统存储容量有限,不适合大型数据集。由于没有复制或自动扩展,本地文件系统无法以可用、可靠和可扩展的方式运行。它们的安全性与它们所在的系统一样。模型投入生产后,本地文件系统以外的选择更适合模型服务。
网络附加存储 (NAS): NAS 是一种连接到网络的 TCP/IP 设备,它像计算机一样拥有一个 IP 地址。存储的基础技术是磁盘的 RAID 阵列,文件通过 TCP 传输到客户端。这些设备通常以设备的形式提供。管理数据和 RAID 阵列所需的计算资源被封装到一个单一设备中。
NAS 设备可以得到保护,并且底层存储的 RAID 配置提供了一些可用性和可靠性。NAS 使用数据传输协议,如服务器消息块 (SMB) 和网络文件系统 (NFS),来封装 TCP 用于数据传输。
当文件数量众多时,NAS 设备会遇到扩展问题。这是由于其底层存储结构的层次结构和路径规划造成的,其最大容量为数百万个文件。这是所有基于文件解决方案的问题。NAS 的最大存储量约为数十 TB。
存储区域网络 (SAN): SAN 将服务器和 RAID 存储组合在一个高速互连中。使用 SAN,您可以将存储流量放到使用光纤通道协议 (FCP) 的专用光纤通道上。对文件操作的请求可能会通过 TCP 抵达 SAN,但所有数据传输都通过专门用于高效传输数据的网络进行。如果没有专用光纤网络,SAN 可以使用互联网小型计算机系统接口 (iSCSI),它使用 TCP 进行存储流量。
与 NAS 设备相比,SAN 的设置更加复杂,因为它是一个网络,而不是一个设备。您需要一个单独的专用网络才能从 SAN 中获得最佳性能。因此,SAN 费用高昂,需要大量的管理工作。
虽然 SAN 与 NAS 相比可能看起来很吸引人(性能提升以及类似的安全、可用性和可靠性水平),但它仍然是一种基于文件的方案,存在前面描述的所有问题。性能的提高并不能弥补额外的复杂性和成本。总存储量最大可达数百 PB。
分布式文件系统: 分布式文件系统 (DFS) 是一种跨越多台计算机或服务器的文件系统,它允许以分布式方式存储和访问数据。与单个集中式系统不同,分布式文件系统将数据分布在多个服务器或容器中,允许用户访问和修改文件,就好像它们位于单个集中式文件系统中一样。
一些流行的分布式文件系统示例包括 Hadoop 分布式文件系统 (HDFS)、Google 文件系统 (GFS)、Amazon Elastic File System (EFS) 和 Azure Files。
文件可以像上面的基于文件解决方案一样得到保护,因为操作系统呈现给它的界面看起来像一个传统的文件系统。分布式文件系统在集群中运行,该集群提供可靠性。与 SAN 相比,在集群中运行可能会导致更高的吞吐量;但是,它们在文件数量众多时仍然会遇到扩展问题(像所有基于文件的解决方案一样)。
对象存储: 对象存储已经存在了一段时间,但在 2006 年亚马逊将其作为第一个 AWS 服务推出 Simple Storage Service (S3) 后发生了革命性变化。现代对象存储是云原生,其他云很快也将自己的产品推向市场。微软提供了 Azure Blob 存储,谷歌提供了 Google Cloud Storage 服务。S3 API 是开发人员与存储和云交互的事实上的标准,并且有多家公司为公共云、私有云、边缘和托管环境提供与 S3 兼容的存储。无论对象存储位于何处,它都是通过 RESTful 接口访问的。
与其他存储选项相比,对象存储最显著的区别在于数据存储在扁平结构中。桶用于创建对象的逻辑分组。以 S3 为例,用户首先会创建一个或多个桶,然后将他们的对象(文件)放在这些桶中的一个中。一个桶不能包含其他桶,一个文件只能存在于一个桶中。这可能看起来很限制,但对象有元数据,通过使用元数据,您可以模拟文件系统中目录和子目录提供的相同级别的组织。
对象存储解决方案在作为分布式集群运行时也能获得最佳性能。这为它们提供了可靠性和可用性。
对象存储在扩展方面与众不同。由于底层存储的扁平地址空间(每个对象只在一个桶中,并且桶中没有桶),对象存储可以在潜在的数十亿个对象中快速找到一个对象。此外,对象存储提供了接近无限的扩展能力,达到 PB 级甚至更高。这使得它们非常适合存储数据集和管理大型模型。
下面是一个存储评分卡,显示了针对要求的解决方案。
AI 最佳存储选项
最终,存储选项的选择将取决于需求、现实和必要性的混合,但是,对于生产环境,有充分的理由支持对象存储。
原因如下:
- 可扩展的性能 — 现代对象存储速度很快,即使在数百 PB 和并发请求的情况下也能保持快速。使用其他选项无法实现这一点。
- 非结构化数据 — 许多机器学习数据集是非结构化的 — 音频、视频和图像。即使可以存储在数据库中的表格型 ML 数据集也更容易在对象存储中管理。例如,工程师通常将构成训练集的数千行或数百万行视为一个单一实体,可以通过单个简单请求进行存储和检索。验证集和测试集也是如此。
- RESTful API — RESTful API 已成为服务之间通信的事实上的标准。因此,存在用于身份验证、授权、安全传输和通知的成熟消息传递模式。
- 加密 — 如果您的数据集包含个人身份信息,则您的数据必须在静止状态下进行加密。
- 云原生(Kubernetes 和容器) — 能够在其服务中运行 Kubernetes 管理的容器的解决方案可以在所有主要公共云中移植。许多企业都有内部 Kubernetes 集群,可以运行 Kubernetes 原生对象存储部署。
- 不可变性 — 实验的可重复性非常重要,如果底层数据移动或被覆盖,则实验就无法重复。此外,保护训练集和模型免遭删除(意外或有意)将是 AI 存储 系统的核心能力,当世界各地的政府开始监管 AI 时,这一点尤为重要。
- 擦除编码与 RAID 的数据弹性和可用性比较 — 擦除编码使用简单驱动器来提供弹性存储所需的冗余。另一方面,RAID 阵列(由控制器和多个驱动器组成)是另一种必须部署和管理的设备类型。擦除编码在对象级别上工作,而 RAID 在块级别上工作。如果单个对象损坏,擦除编码可以修复该对象并使系统快速恢复到完全运行状态(例如在几分钟内)。RAID 需要重建整个卷才能读取或写入任何数据,重建可能需要几个小时或几天,具体取决于驱动器的尺寸。
- 所需的文件数量 — 用于训练模型的许多大型数据集都是从数百万个小文件创建的。想象一家拥有数千个 IoT 设备的组织,每个设备每秒进行一次测量。如果每次测量都是一个文件,那么随着时间的推移,文件的总数将超过文件系统所能处理的范围。
- 跨环境可移植性 — 软件定义的对象存储可以使用本地文件、NAS、SAN 和在 Kubernetes 集群中运行的带有 NVMe 驱动器的容器作为其底层存储。因此,它可以在不同的环境中移植,并通过 S3 API 在任何地方访问底层存储。
MinIO 用于 ML 训练和推理
由于其性能、可扩展性、可扩展性能和简单性,MinIO 已成为 AI/ML 堆栈中的一个基础组件。MinIO 理想情况下配置在使用 NVMe 驱动器的容器集群中;但是,您可以根据需求使用几乎任何存储配置。
实现软件定义、云原生方法的一个优势是代码变得可移植。训练代码和模型服务代码不需要随着 ML 项目从概念验证成熟到获得资金,再到模型在生产环境中为集群提供预测而发生更改。
虽然可移植性和灵活性很重要,但如果它们以牺牲性能为代价,则毫无意义。MinIO 的性能特征是众所周知的,所有性能特征都以 基准测试 的形式公布。
后续步骤
开始新项目的科研人员应该在他们的工作站上安装 MinIO。以下指南将帮助您入门。
如果您负责构成开发、测试和生产环境的集群,那么请考虑添加 MinIO。
边学边做
开发人员和数据科学家越来越多地控制他们自己的存储环境。IT 严格控制存储访问的时代已经过去了。开发人员自然会倾向于软件定义、开源、云原生和简单的技术。这本质上将对象存储定义为解决方案。
如果您正在使用自己喜欢的 ML 工具设置新的工作站,请考虑通过安装本地解决方案将对象存储添加到您的工具集中。此外,如果您的组织拥有用于实验、开发、测试和生产的正式环境,那么请将对象存储添加到您的实验环境中。这是将新技术引入组织中所有开发人员的绝佳方法。您还可以使用在这个环境中运行的真实应用程序进行实验。如果您的实验成功,则可以将您的应用程序提升到开发、测试和生产环境中。
如果您对 AI 数据存储 有任何问题,请发送邮件到 hello@min.io 或加入我们的 通用 Slack 频道 进行讨论。