将 AI/ML 与对象存储结合使用的架构师指南

这篇文章首次出现在 The New Stack 中。

随着企业的不断进化，机器学习和人工智能已经成为董事会层面的举措。

撇开营销说法不谈，随着 AI/ML 融入到每个软件堆栈和架构中，几年前看起来几乎是神话般的功能现在已成为理所当然的事情。这被称为人工智能优先架构。

在 AI/ML 的世界里，重点是寻找能够准确捕捉数据中错综复杂关系的模型，并使用这些模型通过准确的预测创造商业价值。

AI/ML 的现实是，在实现这一崇高目标之前，需要进行大量数据处理。尽管对 AI/ML 的炒作和关注都集中在使用最新、最酷的建模技术上，但事实一再表明，通过适当的数据管理和找到一种方法来实现复杂关系建模能力的最大收益将数据呈现给模型，以便模型在训练时学习细微差别。

简而言之，它主要是关于数据，而不是模型。

在构建人工智能优先架构时，会出现几个关键要求，尤其是与存储相关的要求。在架构师指南的这一部分中，我们将概述需要考虑的内容以及原因。

可扩展性

设计 AI/ML 架构的首要考虑因素是可扩展性。虽然可扩展性有多个方面，但我们专注于数据基础设施的可扩展性。一些非常有趣的工作是在没有太多可用训练数据的受限环境中完成的，但最好的结果仍然来自在涉及非常大规模训练的用例中所做的工作。

大规模训练不是几百 TB——它通常是几十到几百 PB。从管理和性能角度来看，该卷都超出了传统 SAN/NAS 架构的能力。

一旦你超过了几个 PB，你就会看到对象存储。对象存储具有独特的资格来解决这种规模的问题，因为它可以无限扩展，跨网络扩展并随着您的增长提供线性性能。

此外，对象存储天生适合不同类型的数据——半结构化、非结构化、结构化。随着访问数据的 AI/ML 框架寻求创建功能，越来越多不同类型的数据变得重要，并且在一个地方存储、控制和管理所有这些数据的能力变得非常重要。

此外，随着这些不同类型的数据增长到许多 PB 领域，为不同类型的数据建立和维护不同的存储解决方案变得非常昂贵。将持久性整合到对象存储中可以节省基础架构成本。

RESTful API/S3

由于上述关于可扩展性的要求，几乎每个 AI/ML 平台都支持对象存储。对象存储为所有类型的训练数据提供了一个单一的存储库，并且几乎可以无限扩展。拥有单一存储架构可简化部署并降低运营成本。

S3 API 是对象存储的事实标准，因此也是 AI/ML 数据架构领域的事实标准。事实上，大多数现代 AI/ML 平台都是为 S3 API 构建的，后来通常由社区扩展以支持遗留 SAN/NAS 解决方案。

原因很简单：RESTful API 是设计分布式软件系统和对象持久性的现代方法，S3 恰好符合定义。再加上部署在AWS上并使用 S3 构建的 AI/ML 项目的流行，很明显，S3 API（即对象存储）实际上是大型 AI/ML 项目的必要条件。

您可以使用 POSIX（便携式操作系统接口）进行小规模工作吗？是的，但那是更多的沙箱工作。对于真正的大规模 AI/ML，S3 将是您的数据基础设施的 API。

对象锁定（监管或合规性保留）

在金融服务、医疗保健和政府等受监管的环境中，对象锁定是赌注。话虽如此，并非所有对象存储都支持对象锁定，而且很少有对象存储针对操作部署进行了优化。

核心能力是确保对象在设定的时间段内不能被删除或覆盖。需要适应不同的模式，但总体目标是确保源上不会发生篡改。可以很容易地适应版本控制。

这对于 AI/ML 模型和训练文件尤其重要，因为它们的目标是进行可操作的科学实验。确保训练数据的有效性与验证模型本身一样重要。

对象生命周期管理

现代企业中的模型不是静态的。随着时间的推移和越来越多不同的数据可用，模型需要相应地更新。这不应该是一个手动过程，因为这会使模型一开始就是静态的。

对象存储可以提供全生命周期的管理能力。这包括随着模型老化从热层分层到暖层，以及管理有关数据更新、转换和删除的策略。

与这个领域相关的是对象存储近乎无限的可扩展性。在一个您可以拥有尽可能多的存储空间的世界中，它们都可以存在于一个命名空间中。这从对象生命周期管理的角度提出了无数种可能性——所有这些都通过 RESTful API 实现自动化。

在一个命名空间中拥有不同的数据类型可以显着简化数据管理和验证过程。在规模上，这可以提高运营效率并节省资金。

表现

与规模一样，性能也有多个方面。在转向大规模性能之前，让我们先看看 READ 和 WRITE 性能。

为给定模型发现一组可优化训练能力的超参数具有挑战性。无法先验地确定具有给定训练数据集的给定模型的最佳超参数。

超参数调整与其说是一门科学，不如说是一门艺术，通常归结为通过每个参数的范围对离散点进行智能或非智能搜索，直到发现一个合适的集合（“网格搜索”）。

更复杂的是，在给定一组选定的超参数的情况下，模型在整个训练过程中的收敛速度不是线性的，这意味着在给定训练集上针对给定模型评估给定的一组超参数，必须让每一个都完成训练到收敛，以评估所得模型的适合度和超参数集的可取性。

简而言之：它可以是大量重复的试错训练。对于非常大的数据集，这是对训练文件的大量阅读。

当前“Auto ML”库中的大部分工作对数据科学家或开发人员是隐藏的。仅仅因为它被隐藏并不意味着它没有发生。当我们将训练集群的大小增加到数百或数千个计算节点以并行化“Auto ML”过程时，我们会产生一种情况，即给定的训练文件被读取数百或数千次。

如果该训练文件很大，那么 I/O 数量的增加速度大致等于被评估的模型数量乘以我们决定测试每个超参数的离散点数量乘以超参数数量对于给定的模型。

简而言之，从持久性存储中读取训练文件的性能很重要。您可以随心所欲地优化代码，但模型训练仍将依赖于 READ 性能。缓存当然有帮助。但归根结底，这是一个文件 I/O 挑战。

多快才算快？对于上下文，在 32 个 NVMe 节点上运行的 MinIO以 325 GiB/sec 的速度读取。这应该是 AI/ML 设置的目标。

更复杂的 AI/ML 用例——Lambda Compute Eventing

一旦开发出看起来运行良好的模型，通常需要在投入生产之前对其进行验证。在金融服务组织中，这通常由独立的模型验证团队完成，这不是数据科学开发工作的一部分。他们有意分开，负责验证组织使用的数学/模型的正确性。除了验证模型的正确性之外，模型验证团队通常还负责测试和了解模型在各种未预料到的不利经济条件下的表现，这些条件可能不是模型训练的一部分。

例如，如果我们谈论金融模型并且使用的训练数据是最近的历史数据，这很常见，那么模型验证团队可能会针对不利数据运行模型，例如大萧条或时期的历史数据全球冲突，例如战争、极端市场波动、收益率曲线倒挂或负实际利率。他们还可以用理论数据测试模型以评估稳定性。模型验证团队在评估数学/模型的行为以及组织的整体风险方面发挥作用。这可是不小的功夫。

要使用对象存储来操作 AI/ML，一个真正强大的功能是 Lambda Compute Eventing (LCE)。LCE 有助于自动化这个复杂的模型验证工作流程。通常，为建模过程生命周期中的每个步骤创建单独的桶，LCE 用于通知感兴趣的各方新对象到达每个桶。该事件会触发模型进展阶段的适当处理，以及满足合规性要求或内部检查所需的任何业务级审计。

概括

虽然最近的技术炒作让我们都相信找到下一个伟大的、复杂的建模方法是数据科学的圣杯，但实际上，它是数据的收集和适当的管理，以及适当的 MLOps 以保证安全性和可重复性真正为组织创造价值的建模过程。MinIO 本质上提供了促进在现代企业中创建和使用大规模 AI/ML 所需的功能。