AI 存储架构师指南

Source: Keith Pijanowski, The Architect's Guide to Storage for AI, Jun 1st, 2023

为机器学习 （ML） 项目的所有阶段选择最佳存储至关重要。研究工程师需要创建多个版本的数据集，并试验不同的模型架构。当模型提升到生产环境时，它在对新数据进行预测时必须高效运行。在生产中运行的训练有素的模型是将AI添加到应用程序中的原因，因此这是最终目标。

作为一名AI/ML架构师，这一直是我过去几年的生活。我想分享我所学到的关于训练和服务模型的项目要求以及可用选项的知识。将此视为一项调查。我将介绍从传统文件系统变体到现代云原生对象存储的所有内容，这些对象存储专为满足与大型语言模型 （LLM） 和其它生成式 AI 系统相关的大规模性能要求而设计。

我将回顾每个方案，看看它如何与我们的要求相提并论。

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

机器学习和人工智能的现状

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

这不仅仅是关于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 是连接到具有 IP 地址的网络的 TCP/IP 设备，与计算机非常相似。存储的基础技术是驱动器的 RAID 阵列，文件通过 TCP 传送到客户端。这些设备通常作为设备交付。管理数据和 RAID 阵列所需的计算打包到单个设备中。

NAS 设备可以得到保护，底层存储的 RAID 配置提供了一定的可用性和可靠性。NAS 使用SMB和NFS等数据传输协议来封装 TCP 以进行数据传输。

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

SAN：SAN 在高速互连上结合了服务器和 RAID 存储。借助 SAN，您可以使用光纤通道协议 （FCP） 将存储流量放在专用光纤通道上。文件操作请求可能通过 TCP 到达 SAN，但所有数据传输都通过专用于高效交付数据的网络进行。如果专用光纤网络不可用，SAN 可以使用 Internet 小型计算机系统接口 （iSCSI），该接口使用 TCP 进行存储流量。

SAN 的设置比 NAS 设备更复杂，因为它是网络而不是设备。您需要一个单独的专用网络才能从 SAN 获得最佳性能。因此，SAN 成本高昂，需要花费大量精力来管理。

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

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

分布式文件系统的一些流行示例包括Hadoop分布式文件系统（HDFS），Google文件系统（GFS），Amazon Elastic File System（EFS）和Azure Files。

文件可以得到保护，就像上面基于文件的解决方案一样，因为操作系统的界面看起来像传统的文件系统。分布式文件系统在提供可靠性的集群中运行。与 SAN 相比，在群集中运行可能会带来更好的吞吐量;但是，当存在大量文件时，它们仍然会遇到缩放问题（就像所有基于文件的解决方案一样）。

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

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

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

对象存储在规模方面与众不同。由于底层存储的平面地址空间（每个对象仅在一个存储桶中，存储桶内没有存储桶），对象存储可以在潜在的数十亿个对象中快速找到对象。此外，对象存储提供近乎无限的 PB 级甚至更高的扩展。这使得它们非常适合存储数据集和管理大型模型。

下面是一个存储记分卡，显示了针对要求的解决方案。

AI 的最佳存储选项

最终，存储选项的选择将取决于需求、现实和必要性的混合。但是，对于生产环境，对象存储有一个强有力的理由。

原因如下：

• 大规模性能：现代对象存储速度很快，即使面对数百 PB 和并发请求也能保持快速。您无法通过其它选项实现这一目标。
• 非结构化数据：许多机器学习数据集是非结构化的，包括音频、视频和图像。即使是可以存储在数据库中的表格 ML 数据集，也可以在对象存储中更轻松地进行管理。例如，工程师通常会将构成训练集的数千或数百万行视为单个实体，可以通过单个简单请求进行存储和检索。验证集和测试集也是如此。
• RESTful API：RESTful API 已成为服务之间通信的事实标准。因此，存在用于身份验证、授权、动态安全和通知的经过验证的消息传递模式。
• 加密：如果数据集包含个人身份信息，则必须在静态时对数据进行加密。
• 云原生（Kubernetes 和容器）：可以在由 Kubernetes 管理的容器中运行其服务的解决方案可以在所有主要的公共云中移植。许多企业都有内部 Kubernetes 集群，可以运行 Kubernetes 原生对象存储部署。
• 不可变：实验必须可重复，如果基础数据移动或被覆盖，实验就不可重复。此外，当世界各国政府开始监管人工智能时，保护训练集和模型不被意外或故意删除，将成为人工智能存储系统的核心功能。
• 纠删码与 RAID 在数据弹性和可用性方面的对比：纠删码使用简单的驱动器来提供弹性存储所需的冗余。另一方面，RAID 阵列（由控制器和多个驱动器组成）是必须部署和管理的另一种设备类型。纠删码适用于对象级别，而 RAID 适用于块级别。如果单个对象损坏，纠删码可以修复该对象并快速将系统返回到完全运行状态（如几分钟）。RAID 需要先重建整个卷，然后才能读取或写入任何数据，重建可能需要数小时或数天，具体取决于驱动器的大小。
• 根据需要创建任意数量的文件：用于训练模型的许多大型数据集都是从数百万个小文件创建的。想象一下，一个拥有数千台物联网设备的组织，每台设备每秒进行一次测量。如果每个度量都是一个文件，那么随着时间的推移，文件总数将超过文件系统可以处理的范围。
• 跨环境可移植：软件定义的对象存储可以使用本地文件、NAS、SAN 和在 Kubernetes 集群中与 NVMe 驱动器一起运行的容器作为其底层存储。因此，它可以跨不同环境移植，并通过 S3 API 随时随地提供对底层存储的访问。