为什么 AI 建立在对象存储之上？

tl;dr

这篇文章将探讨四个技术原因，解释为什么人工智能工作负载依赖于高性能对象存储。

1. 无限制的非结构化数据

在当前的机器学习范式中，性能和能力随着计算能力的增长而提升，这实际上是数据集大小和模型大小的替代指标 (《神经语言模型的缩放规律》，Kaplan 等人)。在过去几年中，这给机器学习和数据基础设施的构建方式带来了翻天覆地的变化——主要体现在：存储和计算的分离，充满 *非结构化* 数据的大规模云原生数据湖的构建，以及可以 *非常* 快速地进行矩阵乘法的专用硬件。

当训练数据集，甚至单个数据集分片，所需的存储空间超过系统内存和/或本地存储的容量时，将存储与计算分离的重要性就变得十分明显。在对 MinIO 对象存储上的数据进行训练时，您的训练数据大小没有限制。由于 MinIO 专注于简单性和 I/O 吞吐量，网络成为训练速度和 GPU 利用率的唯一限制因素。

除了提供任何对象存储中最好的性能之外，MinIO 还与所有现代机器学习框架兼容。MinIO 对象存储也完全兼容 S3 API，因此您可以使用熟悉的 DataSet 工具（例如 TorchData S3 Datapipe）针对您的本地或设备上的对象存储执行 ML 工作负载。如果您的使用应用程序需要类似文件系统的功能，您甚至可以将 MinIO 与对象存储文件接口（例如 Mountpoint S3 或 S3FS）一起使用。在未来的博文中，我们将使用 MinIO Python SDK 在某些常见的 PyTorch 和 FairSeq 接口（分别如 Dataset 和 Task）的自定义实现中使用，以实现“无限制”训练数据和高 GPU 利用率的模型训练。

除了现代 ML 堆栈的性能和兼容性之外，对象存储的设计选择，即 (1) 平面命名空间，(2) 将整个对象（及其元数据）封装为最低逻辑实体，以及 (3) 简单 HTTP 动词 API，是对象存储成为大规模非结构化数据湖的事实标准的原因。回顾机器学习的近况，我们会发现训练数据（从某种意义上说，模型架构本身）变得不那么结构化，更加通用。过去，模型主要是在表格数据上进行训练。如今，范围要广泛得多，从纯文本段落到数小时的视频。随着模型架构和 ML 应用程序的不断发展，对象存储的无状态、无模式以及因此可扩展的特性变得越来越重要。

2. 模型和数据集的丰富元数据

由于 MinIO 对象存储的设计选择，每个对象都可以包含丰富的、无模式的元数据，而不会牺牲性能或需要使用专用的元数据服务器。在您想为对象添加何种元数据方面，唯一的限制是您的想象力。但是，以下是一些对于 ML 相关对象特别有用的想法：

对于模型检查点：损失函数值、训练时间、用于训练的数据集。

对于数据集：配对索引文件的名称（如果适用）、数据集类别（训练、验证、测试）、有关数据集格式的信息。

当这种高度描述性的元数据与高效索引和查询元数据的能力（即使跨数十亿个对象）结合使用时，其效力尤为显著，而这正是 MinIO 企业级目录 提供的功能。例如，您可以查询标记为“已测试”的模型检查点或在特定数据集上进行过训练的检查点。

3. 模型和数据集可获取、可审计和可版本化

随着机器学习模型及其数据集变得越来越重要的资产，以容错、可审计和可版本化的方式存储和管理这些资产也变得同样重要。

数据集和在它们上进行训练的模型是宝贵的资产，是时间、工程投入和资金的辛勤结晶。因此，应以一种不阻碍应用程序访问的方式对其进行保护。MinIO 的内联操作（如位腐烂检查和擦除编码），以及多站点、主动-主动复制等功能确保了这些对象的规模化弹性。

特别是对于生成式 AI，了解用于训练特定模型（正在提供服务）的哪个数据集的哪个版本非常有用，这在调试幻觉和其他模型行为异常时非常有用。如果模型检查点已正确版本化，则更容易快速回滚到以前提供服务的检查点版本。使用 MinIO 对象存储，您可以直接获得这些对象优势。

4. 自有服务基础设施

MinIO 对象存储从根本上来说是一个您或您的组织控制的对象存储。无论是用于原型设计、安全、法规还是 经济目的，控制都是共同点。因此，如果已训练的模型检查点驻留在对象存储中，则可以更好地控制用于推理或消费的模型服务任务。

在之前的一篇博文中，我们探讨了将模型文件存储在对象存储中的优势，以及如何使用 PyTorch 的 TorchServe 推理框架直接提供服务。但是，这是一种完全与模型和框架无关的策略。

但这为什么重要呢？第三方模型存储库上的网络延迟或中断会导致模型推理服务速度变慢，甚至完全不可用。此外，在推理服务器正在扩展并需要定期拉取模型检查点的生产环境中，这个问题会加剧。在最安全或最关键的情况下，最好避免通过互联网使用第三方依赖，因为您可以在没有互联网的情况下进行操作。使用 MinIO 作为私有或混合云对象存储，可以完全避免这些问题。

结语

这四个原因绝不是详尽无遗的。开发人员和组织出于各种原因使用 MinIO 对象存储进行 AI 工作负载，从开发的简便性到其超轻量级占用空间。

在本文开头，我们介绍了采用高性能对象存储进行 AI 的驱动力。无论缩放规律是否成立，可以肯定的是，组织及其 AI 工作负载将始终受益于最佳的 I/O 吞吐量能力。此外，我们可以相当有把握地说，开发人员永远不会要求使用 *更难* 的 API，也不会要求使用 *无法* “正常工作” 的软件。在任何这些假设成立的未来，高性能对象存储都是必经之路。

对于本文的任何架构师和工程决策者，这里提到的许多最佳实践都可以实现自动化，以确保以一种使您的 AI/ML 工作流程更简单、更可扩展的方式利用对象存储。这可以通过使用任何现代 MLOps 工具集来实现。AI/ML 专家 Keith Pijanowski 探索了其中许多工具——搜索我们的博客网站，了解有关 Kubeflow、MLflow 和 MLRun 的更多信息，以及有关 MLOps 工具的更多信息。但是，如果您的组织无法使用这些 MLOps 工具，并且需要快速上手，那么本文介绍的技术是使用 MinIO 开始管理 AI/ML 工作流程的最佳方式。

对于开发人员（或任何有好奇心的人 🙂），在未来的博文中，我们将逐步演练如何调整 ML 框架以利用对象存储，从而实现“无限制”训练数据和正确的 GPU 利用率。

感谢阅读，希望本文对您有所帮助！如果您有任何问题，请加入我们的 Slack 频道 或发送邮件至 hello@min.io。