1. 非结构化数据不受限制

在当前的机器学习范式中，性能和能力随计算而扩展，这实际上是数据集大小和模型大小的代理（神经语言模型的缩放定律，Kaplan 等人）。在过去几年中，这为机器学习和数据基础设施的构建方式带来了彻底的变化——即：存储和计算的分离、充满非结构化数据的海量云原生数据湖的构建，以及可以非常快速地进行矩阵乘法的专用硬件。

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

除了提供所有对象存储中最佳的性能外，MinIO 还与所有现代机器学习框架兼容。MinIO 对象存储还 100% 兼容 S3 API，因此您可以使用熟悉的数据集实用程序（如 TorchData）针对本地或设备对象存储执行 ML 工作负载S3 数据管道如果您的使用应用程序需要类似文件系统的功能，您甚至可以将 MinIO 与对象存储文件接口一起使用，例如挂载点 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 SME Keith Pijanowski 探索了许多这些工具 - 在我们的博客网站上搜索 Kubeflow、MLflow 和 MLRun 以获取有关 MLOps 工具的更多信息。但是，如果这些 MLOps 工具不适合您组织，并且您需要快速开始，那么本文中展示的技术是开始使用 MinIO 管理 AI/ML 工作流的最佳方式。

对于开发人员（或任何好奇的人🙂），在未来的博客文章中，我们将进行端到端的演练，以调整 ML 框架来利用对象存储，目标是“无限制”训练数据和适当利用 GPU。

感谢您的阅读，希望对您有所帮助！一如既往，如果您有任何问题，请加入我们的Slack 频道或者给我们留言你好@min.io 。