架构师的AI存储指南！

为机器学习项目选择最佳存储是至关重要的。工程师需要创建多个版本的数据集，并用不同的模型架构进行实验。当模型被推广到生产环境时，必须在对新数据进行预测时高效运行。

作为一名AI/ML架构师，这一直是笔者过去几年的生活。本文将分析对训练和服务模型的项目需求以及可用选项的了解，涵盖从传统的文件系统到现代云原生对象存储的所有内容，这些对象存储是为与大型语言模型(LLM)和其他生成式AI系统相关的大规模性能需求而设计的。

在我们深入研究需求之前，回顾一下当今软件行业中正在发生的事情将是有益的。正如你将看到的，机器学习(ML)和人工智能(AI)的发展正在推动需求。

ML和AI的现状

能够以接近人类的精确度进行聊天的大型语言模型(LLM)正在主导媒体。这些模型需要大量的数据来训练。关于生成AI还有许多其他令人兴奋的进展，例如，文本到图像和声音生成。这些也需要大量的数据。

除了LLM，还有其他模型可以解决基本的业务问题。回归、分类和多标签是不可生成的模型类型，但可以为企业增加真正的价值。越来越多的组织正在寻找这些模型来解决各种各样的问题。

另一个现象是，越来越多的企业正在成为使用客户私有数据提供模型训练服务的SaaS供应商。比如一个LLM接受了来自互联网数据和几千本书的训练来回答问题，就像ChatGPT一样。这个LLM将是一个能够回答各种主题的基本问题的通才。

但是，如果用户提出的问题需要医疗保健、金融服务或专业服务等特定行业的高级知识，那么它可能无法提供有用、详细和完整的答案。可以用额外的数据对训练好的模型进行微调。

因此，作为通才接受训练的LLM可以进一步接受行业特定数据的训练。然后，该模型将为有关特定行业的问题提供更好的答案。对LLM进行微调尤其有益，因为它们的初始训练可能花费数百万美元，而微调成本要便宜得多。

无论构建的模型是什么，一旦投入生产，它必须是可用、可伸缩的，就像作为应用程序的一部分部署的其他服务一样。如果是一家提供SaaS解决方案的企业，将有额外的安全需求。需要防止直接访问任何代表竞争优势的模型，并且需要保护客户的数据。

下面让我们更详细地看看这些需求。

ML存储要求

软件解决方案中使用的技术必须是可扩展的、可用的、安全的、高性能的和简单的。让我们看看每个需求对ML项目意味着什么。

可扩展性

存储解决方案中的可扩展性是指其处理不断增加的存储量而不需要进行重大更改的能力。换句话说，随着容量和吞吐量需求的增加，可扩展存储可以继续以最佳方式运行。

可用性

可用性是指操作系统执行任务的能力的属性。操作人员经常在一段时间内测试整个系统的可用性。例如，系统在一个月的99.999%的时间是可用的。可用性还可以指资源开始处理单个请求之前的等待时间。过多的等待时间会导致系统不可用。

可用性对于模型训练和存储都是必不可少的。模型训练不应该由于存储解决方案中缺乏可用性而出现延迟。生产中的模型应该在每月99.999%的时间内可用。对数据或模型本身的请求(可能很大)应该经历较短的等待时间。

安全性

在进行所有读写操作之前，存储系统应该知道您是谁以及您能做什么。换句话说，存储访问需要经过身份验证和授权。数据在静态状态下也应该是安全的，并提供加密选项。上一节中提到的假想SaaS供应商在向客户提供多租户时必须密切关注安全性。锁定数据、版本数据和指定保留策略的能力也是安全需求的一部分。

高性能

高性能存储解决方案针对高吞吐量和低延迟进行了优化。在模型训练过程中，性能是至关重要的，因为更高的性能意味着更快地完成实验。ML工程师可以执行的实验数量与最终模型的准确性成正比。如果使用神经网络，则需要进行多次实验来确定最优结构。使用GPU必须注意防止存储成为瓶颈。如果存储解决方案不能以等于或大于GPU的处理速率传输数据，系统将浪费宝贵的GPU周期。

弹性

弹性存储解决方案不应该有单点故障。弹性系统试图防止故障，但当故障发生时，它可以优雅地恢复。这样的解决方案应该能够参与故障转移，模拟整个数据中心的损失，以测试整个应用程序的弹性。

在生产环境中运行的模型需要弹性。然而，弹性也可以为模型训练增加价值。假设ML团队使用集群的分布式训练技术。在这种情况下，服务于该集群的存储以及集群本身应该具有容错性，从而防止团队因故障而损失数小时或数天。

简单性

工程师把“简单”和“美”等同起来使用。当一个软件设计很简单时，它是经过深思熟虑的。简单的设计适合许多不同的场景并解决许多问题。ML的存储系统应该是简单的，特别是在一个新的ML项目的概念验证(PoC)阶段，研究人员需要专注于特征工程、模型架构和超参数调优，同时试图提高模型的性能，使其足够准确，从而为业务增加价值。

存储策略

有几种存储选项用于机器学习和服务。目前，这些选项可分为以下几类:本地文件存储、网络附加存储(NAS)、存储区域网络(SAN)、分布式文件系统(DFS)和对象存储。本节将一一讨论，并将它们与需求进行比较。目标是找到一个能够在所有需求中达到最佳标准的选项。

本地文件存储

研究人员工作站的文件系统和专用于模型服务的服务器上的文件系统是用于ML存储的本地文件系统的示例。用于本地存储的底层设备通常是SSD，但也可以是更高级的NVMe。在这两种情况下，计算和存储都在同一个系统上。

这是最简单的选择。在PoC阶段，这也是一个常见的选择，在这个阶段，一个小的研发团队试图从一个模型中获得足够的性能来证明进一步的费用是合理的。虽然这种方法很常见，但也有缺点。

本地文件系统的存储容量有限，不适合较大的数据集。由于没有复制或自动扩展功能，本地文件系统无法以可用、可靠和可扩展的方式运行。它们和所在的系统一样安全。一旦模型投入生产，就会有比本地文件系统更好的模型服务选择。

网络附加存储(NAS)

NAS是一种连接到具有IP地址的网络的TCP/IP设备。存储的底层技术是驱动器的RAID阵列，文件通过TCP传递给客户端。这些设备通常作为设备交付，管理数据所需的计算和RAID阵列被打包到单个设备中。

NAS设备是安全的，底层存储的RAID配置提供了一定的可用性和可靠性。NAS使用服务器消息块(SMB)和网络文件系统(NFS)等数据传输协议封装TCP进行数据传输。

当存在大量文件时，NAS设备会遇到扩展性问题。这是由于它们的底层存储结构的层次结构和路径，最多可容纳数百万个文件。这是所有基于文件的解决方案都存在的问题。NAS的最大存储空间大约是几十TB。

存储区域网络(SAN) 

SAN将服务器和RAID存储以高速互连方式组合在一起。SAN可以使用光纤通道协议(FCP)将存储流量放在专用光纤通道上。对文件操作的请求可以通过TCP到达SAN，但是所有的数据传输都是通过专门用于有效传输数据的网络进行的。在没有专用光纤网络的情况下，SAN可以使用iSCSI (Internet Small Computer System Interface)协议，该协议使用TCP协议传输存储流量。

SAN的设置比NAS设备更复杂，因为它是一个网络而不是一个设备。需要一个单独的专用网络来获得SAN的最佳性能。因此，SAN的成本很高，需要付出很大的努力来管理。

虽然与NAS相比，SAN看起来很有吸引力(性能提高，安全性、可用性和可靠性级别相似)，但它仍然是一种基于文件的方法，存在前面描述的所有问题。性能的提高并不能弥补额外的复杂性和成本。总存储空间最大可达数百PB。

分布式文件系统(DFS)

DFS是一种跨多台计算机或服务器的文件系统，能够以分布式的方式存储和访问数据。与单个集中式系统不同，分布式文件系统将数据分布在多个服务器或容器上，允许用户访问和修改文件，就像在单个集中式文件系统上一样。

一些流行的分布式文件系统包括Hadoop分布式文件系统(HDFS)，谷歌文件系统(GFS)，亚马逊弹性文件系统(EFS)和Azure文件。

文件可以得到保护，就像上面基于文件的解决方案一样，因为操作系统提供了一个看起来像传统文件系统的界面。分布式文件系统运行在集群中，提供了可靠性。与SAN相比，在集群中运行可能会产生更好的吞吐量；然而，当存在大量文件时(就像所有基于文件的解决方案一样)，它们仍然会遇到扩展性问题。

对象存储

对象存储已经存在很长一段时间了，但是当Amazon在2006年通过简单存储服务(S3)将其作为第一个AWS服务时，它发生了革命性的变化。现代对象存储是云原生的，其他云很快将它们的产品推向市场。微软提供Azure Blob存储，谷歌也有自己的谷歌云存储服务。S3 API是开发人员与存储和云交互的标准，有许多公司为公共云、私有云、边缘和共存环境提供兼容S3的存储。无论对象存储位于何处，都可以通过RESTful接口访问它。

与其他存储选项相比，对象存储最显著的区别是数据存储在平面结构中。Bucket用于创建对象的逻辑分组。以S3为例，用户首先创建一个或多个Bucket，然后将他们的对象(文件)放在其中一个Bucket中。一个Bucket不能包含其他Bucket，一个文件只能存在于一个Bucket中。这似乎有些限制，但是对象具有元数据，并且使用元数据，可以模拟文件系统中目录和子目录提供的相同级别的组织。

对象存储解决方案在作为分布式集群运行时也表现最佳。这为它们提供了可靠性和可用性。

对象存储在规模方面与众不同。由于底层存储的平面地址空间(每个对象只在一个Bucket中，而不是Bucket中的Bucket)，对象存储可以在潜在的数十亿个对象中快速找到对象。此外，对象存储提供近乎无限的规模，可以达到PB甚至更大。这使得它们非常适合存储数据集和管理大型模型。

下面是一个存储对比图：

AI存储的最佳选择

AI存储选项的选择将受到需求、现实和必要性的综合影响。对于生产环境来说，对象存储是一个很好的选择。

原因如下：

• 大规模性能：现代对象存储速度很快，即使面对数百PB的并发请求也能保持快速。用其他选择无法实现这一点。

• 非结构化数据：许多ML数据集是非结构化的(音频、视频和图像)。即使是可以存储在数据库中的表格式ML数据集，在对象存储中也更容易管理。例如，工程师通常将组成训练集的数千或数百万行视为单个实体，可以通过单个简单请求进行存储和检索。验证集和测试集也是如此。

• RESTful API： RESTful API已经成为服务间通信的事实标准。因此，存在用于身份验证、授权、动态安全性和通知的经过验证的消息传递模式。

• 加密：如果数据集包含个人身份信息，数据必须在休息时加密。

• 云原生：可以在Kubernetes管理的容器中运行其服务的解决方案可以在所有主要的公共云上移植。许多企业都有内部的Kubernetes集群，可以运行Kubernetes-native对象存储部署。

• 不变性：实验的可重复性非常重要，如果底层数据移动或被覆盖，实验就无法重复。此外，当世界各国政府开始监管AI时，保护训练集和模型不被意外或故意删除，将成为AI存储系统的核心能力。

• Erasure编码与RAID的数据弹性和可用性：Erasure编码使用简单的驱动器来提供弹性存储所需的冗余。另一方面，RAID阵列(由一个控制器和多个驱动器组成)是另一种必须部署和管理的设备类型。Erasure编码工作在对象级别，而RAID工作在块级别。如果单个对象被损坏，擦除编码可以修复该对象，并迅速(如几分钟)将系统恢复到完全可操作的状态。RAID需要在读取或写入任何数据之前重建整个volume，重建可能需要数小时或数天，具体取决于驱动器的大小。

• 尽可能多的文件：许多用于训练模型的大型数据集是由数百万个小文件创建的。想象一个拥有数千个物联网设备的组织，每个设备每秒进行一次测量。如果每个度量都是一个文件，那么随着时间的推移，文件的总数将超过文件系统可以处理的数量。

• 跨环境的可移植性：软件定义的对象存储可以使用本地文件、NAS、SAN和在Kubernetes集群中与NVMe驱动器一起运行的容器作为其底层存储。因此，它可以在不同的环境中移植，并通过S3 API提供对底层存储的访问。

用于ML训练和推理的MinIO

MinIO因其性能、规模、大规模性能和简单性而成为AI/ML堆栈中的基础组件。MinIO理想配置在使用NVMe的容器集群中，但是可以根据需求选择使用几乎任何存储配置。

实现软件定义的云原生方法的一个优点是代码变得可移植。虽然可移植性和灵活性很重要，但如果以牺牲性能为代价，它们就毫无意义。MinIO的性能特性是众所周知的，并且都作为基准发布。

边做边学

开发人员和数据科学家越来越多地控制自己的存储环境。IT严密保护存储访问的日子已经一去不复返了。开发人员自然会被软件定义、开源、云原生和简单的技术所吸引。

如果您正在使用最喜欢的ML工具设置一个新的工作站，请考虑通过安装本地解决方案将对象存储添加到工具包中。此外，如果您的组织有用于实验、开发、测试和生产的正式环境，那么可以在实验环境中添加对象存储。这是向组织中的所有开发人员介绍新技术的好方法。您还可以使用在此环境中运行的实际应用程序来运行实验。如果你的实验成功了，那就把你的应用推广到开发、测试和生产阶段。