如何将AI/ML与对象存储结合使用

随着企业的不断发展，机器学习和人工智能已成为董事会层面的举措。随着AI/ML融入到每一个软件堆栈和架构中，几年前似乎近乎神话般的功能现在被视为理所当然。这被称为AI优先架构。

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

现实是，在实现这一崇高目标之前，需要大量的数据挖掘。尽管AI/ML的宣传和关注点在于使用最新、最酷的建模技术，但已经反复证明，通过适当的数据整理和找到向模型展示数据的方法，可以实现对复杂关系建模能力的最大提升，从而使模型在训练时了解细微差别。

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

在构建AI优先架构时，会出现几个关键需求，尤其是与存储相关的需求。在本文中，我们将概述需要考虑的内容和原因。

可伸缩性

在设计AI/ML架构时，首要考虑的是可伸缩性。虽然可伸缩性有多个方面，但我们关注的是数据基础设施的可伸缩性。一些非常有趣的工作正在有限的环境中进行，那里没有太多可用的培训数据，但最好的结果仍然来自于在涉及大规模培训的用例中进行的工作。

大规模的训练不是几百T——通常是几十到几百P。从管理和性能角度来看，这个容量超过了传统SAN/NAS架构的能力。

一旦过了几个PBs，你就会看到对象存储。对象存储对于这种规模的问题来说是独一无二的，因为它可以无限扩展，跨网络扩展，并随着增长提供线性性能。

此外，对象存储天生适合不同类型的数据——半结构化、非结构化和结构化。随着访问数据的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实现自动化的。

将不同的数据类型都放在一个命名空间中，大大简化了数据管理和验证过程。在规模上，这提高了运营效率并节省了资金。

性能

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

发现一组给定模型的超参数，以优化训练能力是一项挑战。对于一个给定的模型，事先给定一组训练数据是无法确定最优超参数的。

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

更复杂的是，给定一组选定的超参数，模型在整个训练过程中的收敛速度不是线性的，这意味着当给定的超参数集在给定的训练集上针对给定的模型进行评估时，必须允许每个模型完成收敛训练，以便评估结果模型的适用性和超参数集的可取性。

简单地说：这可能是大量重复的试错训练。对于非常大的数据集，这需要大量读取训练文件。

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

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

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

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

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

一旦开发出一个似乎运行良好的模型，通常需要在投入生产之前对其进行验证。在金融服务组织中，这通常由一个单独的模型验证团队完成，该团队不属于数据科学开发的一部分。他们有意分开，负责验证组织使用的数学/模型的正确性。除了验证模型的正确性外，模型验证团队通常还负责测试和了解模型在各种意外不利经济条件下的行为，这些不利经济条件可能不是模型培训的一部分。

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

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

总结

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

原文链接：

https://thenewstack.io/the-architects-guide-to-using-ai-ml-with-object-storage/