面向架构师的 AI/ML 与对象存储使用指南

这篇文章最初发表于 The New Stack。

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

撇开营销宣传不谈，几年前看似神话般的功能现在已成为理所当然，因为 AI/ML 正在融入每个软件堆栈和架构。这被称为 AI 首要架构。

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

AI/ML 的现实情况是，在实现这一崇高目标之前，需要进行大量的“数据清洗”。尽管 AI/ML 的炒作和重点在于使用最新、最酷的建模技术，但事实证明，在对复杂关系建模的能力方面，最大的提升来自适当的数据整理，并找到一种将数据呈现给模型的方法，以便模型在训练期间学习细微差别。

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

在构建 AI 首要架构时，会产生一些关键要求，尤其是在存储方面。在本期《架构师指南》中，我们将概述需要考虑的事项以及原因。

可扩展性

设计 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 精确地符合定义。再加上 AI/ML 项目在 AWS 上部署并使用 S3 构建的情况很普遍，很明显 S3 API（因此是对象存储）实际上是大型 AI/ML 项目的要求。

您能用 POSIX（可移植操作系统接口）完成小规模工作吗？可以，但那更像是沙盒工作。对于规模化的真实 AI/ML，S3 将是您数据基础设施的 API。

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

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

核心功能是确保在设定的时间段内无法删除或覆盖对象。需要适应不同的模式，但总体目标是确保源数据不会被篡改。版本控制可以轻松地进行适应。

这对于 AI/ML 模型和训练文件尤其重要，因为目标是将要投入运营的科学实验。确保训练数据的有效性与验证模型本身一样重要。

对象生命周期管理

在现代企业中，模型并非一成不变。随着时间的推移，更多不同类型的数据变得可用，模型需要相应地更新。这不能是一个手动流程，因为这样一来模型一开始就是静态的。

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

与之相关的是对象存储的近乎无限的可扩展性。在一个可以拥有您想象的任意数量存储空间的世界中，所有这些存储空间都可以存在于单个命名空间中。这从对象生命周期管理的角度为我们提供了无数的可能性——所有这些都通过 RESTful API 自动完成。

将不同的数据类型全部放在单个命名空间中，可以显著简化数据整理和验证过程。在大规模情况下，这提高了运营效率并节省了资金。

性能

与规模一样，性能也有多个方面。在讨论规模化的性能之前，让我们先看一下读写性能。

发现一组能够优化训练能力的给定模型的超参数很困难。无法预先确定给定模型在给定训练数据集上的最佳超参数。

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

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

简而言之：可能需要进行大量的重复性试错训练。对于非常大的数据集来说，这需要读取大量的训练文件。

目前“Auto ML”库中，大部分这项工作对数据科学家或开发者来说是隐藏的。只是因为它隐藏了，并不意味着它没有发生。当为了使“Auto ML”流程并行化，我们将训练集群的大小增加到数百或数千个计算节点时，会创建一个情况，即某个训练文件被读取数百或数千次。

如果该训练文件很大，那么 I/O 数量会以大约等于正在评估的模型数量乘以每个超参数决定测试的离散点数量乘以给定模型的超参数数量的速率增长。

简而言之，从持久存储中读取训练文件的读取性能至关重要。您可以优化代码，但模型训练仍然依赖于读取性能。缓存当然可以帮助，但最终这仍然是一个文件 I/O 挑战。

快到什么程度才算快？为了说明，在 32 个节点上运行的 MinIO NVMe 读取速度为 325 GiB/秒。这应该是 AI/ML 设置的目标。

更复杂的 AI/ML 用例——Lambda 计算事件

一旦开发出看似有效的模型，通常需要在投入生产之前进行验证。在金融服务机构中，这通常由独立的模型验证团队完成，该团队不属于数据科学开发工作的一部分。他们有意地独立，并负责验证机构使用的数学/模型的正确性。除了验证模型的正确性之外，模型验证团队通常还负责测试和理解模型在各种不可预见的经济不利条件下的行为，这些条件可能不属于模型的训练范围。

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

为了使用对象存储来实现 AI/ML，Lambda Compute Eventing (LCE) 是一个非常强大的功能。LCE 促进了自动化这种复杂的模型验证工作流程。通常，会为建模过程生命周期的每个步骤创建单独的存储桶，并使用 LCE 来通知相关方新对象进入每个存储桶。该事件会触发模型进度该阶段的相应处理，以及满足合规性要求或内部检查所需的任何业务级审核。

总结

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