架构师指南：构建 AI／ML 数据湖参考架构

在企业人工智能中，有两种主要类型的模型：判别型和生成型。判别型模型用于对数据进行分类或预测，而生成型模型用于创建新数据。尽管生成型人工智能最近占据了新闻头条，但组织仍在追求这两种类型的人工智能。对于希望提高运营效率并寻求额外收入来源的组织来说，判别型人工智能仍然是一项重要举措。这些不同类型的人工智能有很多共同点，但同时也存在显著的差异，在构建人工智能数据基础设施时必须考虑到这些差异。

组织不应只构建专用于 AI 和 AI 的基础设施，而将商业智能、数据分析和数据科学等工作负载留给自己处理。可以构建一个完整的数据基础设施来支持组织的所有需求 - 商业智能、数据分析、数据科学、判别性 AI 和生成性 AI。

在另一篇文章中，我们介绍了一种现代数据湖的参考架构，该架构能够满足商业智能、数据分析、数据科学和 AI/ML 的需求。让我们回顾一下现代数据湖参考架构，并重点介绍其支持 AI/ML 工作负载的功能。

首先，我们来定义一个现代数据湖，因为它将作为我们参考架构的基础。这种架构不是“回收的”，而是反映了广泛适用的工程第一原则。现代数据湖一半是数据仓库，一半是数据湖，并且使用对象存储来存储所有内容。将对象存储用于数据湖非常合理，因为对象存储用于非结构化数据，而这正是数据湖的用途。但是，将对象存储用于数据仓库可能听起来很奇怪 - 但以这种方式构建的数据仓库代表了下一代数据仓库。这得益于 Netflix、Uber 和 Databricks 编写的开放表格式规范 (OTF)，这使得在数据仓库中使用对象存储变得无缝。

OTF 分别是 Apache Iceberg、Apache Hudi 和 Delta Lake。它们分别由 Netflix、Uber 和 Databricks 编写 - 因为市场上没有可以满足它们数据需求的产品。本质上，它们所做的（以不同的方式）都是定义一个可以构建在对象存储（MinIO）之上的数据仓库。对象存储提供了其他存储解决方案无法提供的可扩展容量和高性能的组合。由于这些是现代规范，它们具有老式数据仓库所没有的高级功能 - 例如分区演变、模式演变和零拷贝分支。最后，由于数据仓库是使用对象存储构建的，因此您可以将同一个对象存储用于非结构化数据，如图像、视频文件、音频文件和文档。

非结构化数据通常存储在业界所谓的数据湖中。使用对象存储作为数据湖和数据仓库的基础，可以得到一个能够容纳所有数据的解决方案。结构化存储位于基于 OTF 的数据仓库中，非结构化存储位于数据湖中。MinIO 的同一个实例可以用于两者。

这篇文章重点介绍支持不同 AI/ML 工作负载的现代数据湖参考架构的 AI/ML 领域。这些功能领域如下所示。上图显示了现代数据湖的视觉描述。这些功能领域所在的层已突出显示。

• 判别性人工智能

  • 非结构化数据存储

  • 半结构化数据存储

  • 数据仓库中的零拷贝分支

     

• 生成式人工智能

  • 使用矢量数据库构建自定义语料库

  • 构建文档管道

  • 检索增强生成 (RAG)

  • 微调大型语言模型

  • 测量法学硕士 (LLM) 准确度

     

• 机器学习操作

本文还介绍了 GPU 的现状以及它们如何影响您的 AI 数据基础设施。我们还将介绍几个场景，说明如何构建基础设施以及如何不构建基础设施。最后，本文提出了一些构建您自己的 AI 数据基础设施的建议。

• GPU 的现状

  • GPU 饥饿问题

  • 增强对象存储

     

• 两个组织的故事

• 构建人工智能数据基础设施的计划

判别式 AI 模型需要各种类型的数据进行训练。图像分类和语音识别模型将使用图像和音频文件形式的非结构化数据。另一方面，欺诈检测和医疗诊断模型则根据结构化数据进行预测。让我们看看 Modern Datalake 中可用于存储和处理判别式 AI 所需数据的选项。

非结构化数据将驻留在数据湖中，可用于训练和测试模型。可以装入内存的训练集可以在训练之前加载（在 epoch 循环开始之前）。但是，如果您的训练集很大并且无法装入内存，则您必须在训练之前加载对象列表，并在处理 epoch 循环中的每个批次时检索实际对象。如果您不使用高速网络和高速磁盘驱动器构建数据湖，这可能会给您的数据湖带来压力。如果您使用无法装入内存的数据训练模型，请考虑使用 100 GB 网络和 NVMe 驱动器构建数据湖。

Modern Datalake 中提供了一些用于存储半结构化文件的选项，例如 Parquet 文件、AVRO 文件、JSON 文件甚至 CSV 文件。最简单的方法是将它们存储在数据湖中，并以与加载非结构化对象相同的方式加载它们。如果 Modern Datalake 支持的其他工作负载（商业智能、数据分析和数据科学）不需要这些半结构化文件中的数据，那么这是最佳选择。

另一个选择是将这些文件加载到数据仓库中，其他工作负载可以使用它们。当数据加载到数据仓库后，您可以使用使用零拷贝分支进行实验您的数据。

特征工程是一种改进用于训练模型的数据集的技术。基于 OTF 的数据仓库拥有一个非常巧妙的功能，那就是零拷贝分支。这允许数据以与代码在 Git 存储库中分支相同的方式进行分支。顾名思义，此功能不会复制数据 - 相反，它利用用于实现数据仓库的开放表格式的元数据层来创建数据唯一副本的外观。数据科学家可以对分支进行实验 - 如果他们的实验成功，那么他们可以将他们的分支合并回主分支，供其他数据科学家使用。如果实验不成功，则可以删除该分支。

所有模型，无论是使用 Scikit-Learn 构建的小型模型、使用 PyTorch 或 TensorFlow 构建的自定义神经网络，还是基于 Transformer 架构的大型语言模型，都需要数字作为输入并产生数字作为输出。如果您对生成式人工智能感兴趣，这个简单的事实会对您的 AI/ML 基础架构提出一些额外的要求，其中单词必须转换为数字（或向量，我们将会看到）。如果您想使用包含公司专有知识的私人文档来增强 LLM 生成的答案，那么生成式人工智能解决方案会变得更加复杂。这种增强可以采用检索增强生成或 LLM 微调的形式。

本节将讨论所有这些技术（将单词转换为数字、RAG 和微调）及其对 AI 基础设施的影响。让我们首先讨论如何构建自定义语料库以及它应该位于何处。

如果您对生成式人工智能非常认真，那么您的自定义语料库应该定义您的组织。它应该包含其他人没有的知识的文档，并且只包含真实准确的信息。此外，您的自定义语料库应该使用矢量数据库构建。矢量数据库索引、存储和提供对您的文档的访问，以及它们的矢量嵌入，这是您的文档的数字表示。（这解决了上面描述的数字问题。）

矢量数据库便于进行语义搜索。如何做到这一点需要大量的数学背景知识，而且很复杂。但是，语义搜索在概念上很容易理解。假设您想查找所有讨论与“人工智能”相关的文档。要在传统数据库中执行此操作，您需要搜索“人工智能”的所有可能的缩写、同义词和相关术语。您的查询将如下所示：

手动相似性搜索不仅费力且容易出错，而且搜索本身也非常缓慢。矢量数据库可以接受类似下面的请求，并以更快、更高的准确度运行查询。如果您希望使用检索增强生成，那么快速准确地运行语义查询的能力非常重要。

自定义语料库的另一个重要考虑因素是安全性。访问文档时应遵守对原始文档的访问限制。（如果实习生可以访问尚未向华尔街发布的首席财务官财务结果，那就太不幸了。）在矢量数据库中，您应该设置授权以匹配原始内容的访问级别。这可以通过将您的矢量数据库与您组织的身份和访问管理解决方案集成来实现。

矢量数据库本质上存储非结构化数据。因此，它们应该使用您的数据湖作为其存储解决方案。

不幸的是，大多数组织都没有一个包含干净准确文档的存储库。相反，文档以多种格式分布在整个组织的各个团队门户中。因此，构建自定义语料库的第一步是构建一个管道，该管道仅接受已批准用于生成式人工智能的文档并将其放置在矢量数据库中。对于大型全球组织来说，这可能是生成式人工智能解决方案最困难的任务。团队通常会在其门户中以草稿格式保存文档。也可能有一些文档是关于可能发生的事情的随机思考。这些文档不应成为自定义语料库的一部分，因为它们不能准确地代表业务。不幸的是，过滤这些文档将是一项手动工作。

当我们对大型语言模型进行微调时，我们会使用自定义语料库中的信息对其进行更多训练。这可能是获得特定领域 LLM 的好方法。虽然此选项确实需要计算来针对自定义语料库进行微调，但它并不像从头开始训练模型那样耗时，并且可以在适度的时间内完成。

如果您的领域包含日常使用中不常见的术语，微调可能会提高 LLM 响应的质量。例如，使用医学研究、环境研究和任何与自然科学相关的文档的项目可能会受益于微调。微调会采用文档中发现的高度特定的术语，并将其融入模型的参数中。在决定采用这种方法之前，应该了解微调的优点和缺点。

缺点

• 微调将需要计算资源。

• 无法解释。

• 随着语料库的发展，您将需要定期使用新数据进行重新微调。

• 幻觉令人担忧。

• 文档级别的安全性是不可能的。

   

优点

• LLM 通过微调获取您自定义语料库中的知识。

• 推理流程比 RAG 简单。

   

虽然微调是向 LLM 教授业务语言的好方法，但它会稀释数据，因为大多数 LLM 包含数十亿个参数，而您的数据将分布在所有这些参数中。微调的最大缺点是无法进行文档级授权。一旦文档用于微调，其信息就会成为模型的一部分。无法根据用户的授权级别来限制此信息。

让我们看一下在推理时结合自定义数据和参数数据的技术。

检索增强生成 (RAG) 是一种从提出的问题开始的技术 - 使用矢量数据库将问题与附加数据相结合，然后将问题和数据传递给 LLM 进行内容创建。使用 RAG，无需培训，因为我们通过从我们的优质文档语料库中发送相关文本片段来教育 LLM。

它使用问答任务像这样工作：用户在应用程序的用户界面中提出问题。您的应用程序将接受问题 - 特别是其中的单词 - 并使用矢量数据库在优质文档语料库中搜索与上下文相关的文本片段。这些片段和原始问题将发送给 LLM。这个整个包 - 问题加上片段（上下文）称为提示。LLM 将使用此信息来生成您的答案。这似乎是一件愚蠢的事情 - 如果您已经知道答案（片段），为什么还要费心使用 LLM？请记住，这是实时发生的，目标是生成文本 - 您可以复制并粘贴到您的研究中。您需要 LLM 来创建包含来自您的自定义语料库的信息的文本。

这比微调更复杂。但是，由于在推理时从向量数据库中选择了文档（或文档片段），因此可以实现用户授权。文档中的信息永远不会成为模型参数的一部分。下面列出了 RAG 的优点和缺点。

缺点

• 推理流程更加复杂。

   

优点

• LLM 直接从您的自定义语料库中获取知识。
• 可解释性是可能的。
• 无需微调。
• 幻觉显著减少，并可以通过检查矢量数据库查询的结果进行控制。
• 可以实施授权。

为了更好地理解 MLOps 的重要性，将模型创建与传统应用程序开发进行比较会有所帮助。传统的应用程序开发（例如实施向应用程序添加新功能的新微服务）从审查规范开始。任何新的数据结构或对现有数据结构的任何更改都首先进行设计。一旦开始编码，数据的设计就不应该改变。然后实施服务，编码是此过程中的主要活动。单元测试和端到端测试也经过编码。这些测试证明代码没有错误并正确实现了规范。在部署整个应用程序之前，它们可以由 CI/CD 管道自动运行。

创建模型和训练模型是不同的。第一步是了解原始数据和所需的预测。ML 工程师确实需要编写一些代码来实现他们的神经网络或设置算法，但编码并不是主要活动。反复实验才是主要活动。在实验过程中，数据的设计、模型的设计和使用的参数都会发生变化。每次实验后，都会创建指标来显示模型在训练时的表现。还会针对验证集和测试集生成模型性能指标。这些指标用于证明模型的质量。一旦模型准备好纳入应用程序，就需要对其进行打包和部署。

MLOps 是机器学习操作的缩写，是一套旨在解决这些差异的实践和工具。实验跟踪和协作是与 MLOP 最相关的功能，但当今行业中更现代的 MLOP 工具可以做更多的事情。例如，它们可以为您的实验提供运行时环境，并且可以在模型准备好集成到应用程序中后对其进行打包和部署。以下是当今 MLOps 工具中的一组功能。此列表还包括其他需要考虑的事情，例如支持和数据集成。

1. 获得主要参与者的支持- MLOps 技术和功能不断发展。您需要一个由主要参与者支持的工具，以确保该工具不断发展和改进。

    

2. 现代数据湖集成- 实验会产生大量结构化和非结构化数据。理想情况下，这些数据可以存储在数据仓库和数据湖中。然而，许多 MLOps 工具在现代数据湖诞生之前的开放表格式出现之前就已经存在，因此大多数工具都会为其结构化数据提供单独的解决方案。

    

3. 实验跟踪- 跟踪每个实验的数据集、模型、超参数和指标。实验跟踪还应促进可重复性。

    

4. 促进协作- 允许团队成员查看所有 ML 工程师运行的所有实验的结果。

    

5. 模型打包——打包模型，以便可以从其他编程环境访问。

    

6. 模型服务- 将模型部署到组织的正式环境中。如果您已经找到将模型整合到现有 CI/CD 管道中的方法，则不需要此操作。

    

7. 模型注册表——维护所有模型的所有版本。

    

8. 无服务器功能——一些工具提供的功能允许以某种方式注释代码，以便可以将函数或模型部署为容器化服务，以便在集群中运行实验。

    

9. 数据管道功能- 一些 MLOps 工具旨在提供完整的端到端功能，并具有允许您构建管道以检索和存储原始数据的功能。如果您已经有数据管道，则不需要此功能。

    

10. 训练管道功能- 将无服务器函数编排到有向无环图中的能力。还允许调度和运行训练管道。

链条的强度取决于其最薄弱的环节 - 而您的 AI/ML 基础设施的速度仅取决于最慢的组件。如果您使用 GPU 训练机器学习模型，那么您的薄弱环节可能是您的存储解决方案。结果就是我们所说的“饥饿 GPU 问题”。当您的网络或存储解决方案无法足够快地将训练数据提供给您的训练逻辑以充分利用您的 GPU 时，就会发生饥饿 GPU 问题。症状相当明显。如果您监控您的 GPU，您会注意到它们从未接近得到充分利用。如果您已经对训练代码进行了检测，那么您会注意到总训练时间主要由 IO 决定。

不幸的是，对于那些正在努力解决这个问题的人来说，有一个坏消息。GPU 的速度越来越快。让我们看看 GPU 的现状和它们所取得的一些进展，以了解这个问题在未来几年将如何变得更糟。

GPU 的速度越来越快。不仅原始性能越来越好，内存和带宽也在增加。让我们来看看 Nvidia 最新 GPU 的这三个特点A100 ， 这H100和H200 。

注意：上表使用与 A100 的 PCIe（外围组件互连 Express）插槽解决方案以及 H100 和 H200 的 SXM（服务器 PCI Express 模块）插槽解决方案一致的统计数据。A100 没有 SXM 统计数据。在性能方面，使用浮点 16 张量核心统计数据进行比较。

值得一提的是，上述统计数据有几个比较观察结果。首先，H100 和 H200 具有相同的性能（1,979 TFLOPS），比 A100 高 3.17 倍。H100 的内存是 A100 的两倍，内存带宽也增加了类似的量 - 这是有道理的，否则，GPU 会耗尽内存。H200 可以处理高达 141GB 的内存，其内存带宽也相对于其他 GPU 按比例增加。

让我们更详细地看看这些统计数据，并讨论它对机器学习的意义。

性能- 1 万亿次浮点运算 (TFLOP) 是每秒进行 1 万亿次 (10^12) 浮点运算。即 1 后面跟 12 个零 (1,000,000,000,000)。很难将 TFLOP 等同于千兆字节的 IO 需求，因为模型训练期间发生的浮点运算涉及简单的张量数学以及对损失函数 (又称梯度) 的一阶导数。但是，可以进行相对比较。查看上面的统计数据，我们发现 H100 和 H200 的性能均为 1,979 TFLOPS，速度是 H100 的三倍 - 如果其他一切都能跟上，则数据消耗速度可能会快三倍。

GPU 内存- 也称为视频 RAM 或图形 RAM。GPU 内存与系统的主内存 (RAM) 分开，专门用于处理显卡执行的密集图形处理任务。GPU 内存决定训练模型时的批处理大小。过去，当训练逻辑从 CPU 转移到 GPU 时，批处理大小会减小。但是，随着 GPU 内存在容量方面赶上 CPU 内存，用于 GPU 训练的批处理大小将会增加。当性能和内存容量同时增加时，请求量会更大，每 GB 的训练数据处理速度会更快。

内存带宽- 将 GPU 内存带宽视为连接内存和计算核心的“高速公路”。它决定了单位时间内可以传输多少数据。就像更宽的高速公路允许更多汽车在给定时间内通过一样，更高的内存带宽允许更多数据在内存和 GPU 之间移动。如您所见，这些 GPU 的设计人员在每个新版本中都按内存比例增加了内存带宽；因此，芯片的内部数据总线不会成为瓶颈。

如果您遇到了 Starving GPU 问题，请考虑使用 100 GB 网络和 NVMe 驱动器。最近的基准使用这种配置的 MinIO 仅用 32 个现成的 NVMe SSD 节点就实现了 GET 速度为 325 GiB/s 和 PUT 速度为 165 GiB/s。

随着计算世界的发展和DRAM 价格暴跌我们发现服务器配置通常配备 500GB 或更多的 DRAM。当您处理更大规模的部署时，即使是那些具有超密集 NVMe 驱动器的部署，服务器数量乘以这些服务器上的 DRAM 也会迅速增加 - 通常每个实例会达到数 TB。该 DRAM 池可以配置为分布式共享内存池，非常适合需要大量 IOPS 和吞吐量性能的工作负载。因此，我们构建了 MinIO Cache，使我们的企业和企业精简版客户能够配置其基础架构以利用此共享内存池，进一步提高核心 AI 工作负载（如 GPU 训练）的性能，同时保持完全持久性。

作为最后的思想实验，让我们讲一个故事，讲述两个在 AI/ML 旅程中采取截然不同方法的组织。组织 #1 具有“迭代改进”的文化。他们认为，所有大型计划都可以分解为更小、更易于管理的项目。然后以这样的方式安排这些较小的项目，即每个项目都基于前一个项目的成果来解决越来越复杂的问题。他们还喜欢以这样的方式组织这些小项目，即每个项目都能为企业带来价值。他们发现，纯粹是为了改善基础设施或现代化软件而没有任何新功能的项目在控制预算的高管中并不受欢迎。因此，他们了解到，要求使用花哨的存储设备和计算集群来进行生成式 AI 概念验证并不是协调基础设施改进和新软件功能的最佳方式。相反，他们将从可以随着增长而扩展的基础设施产品开始，并且他们将从简单的 AI 模型开始，这样他们就可以将 MLOP 工具落实到位，并弄清楚如何与现有的 DevOps 团队和 CI/CD 管道合作。

组织 #2 拥有“闪亮物体”文化。当最新创意进入行业时，它首先要解决最引人注目的挑战，以展示其技术实力。他们发现这些项目在内部和外部都备受瞩目。如果出现问题，那么聪明的人总能修复它。

组织 #1 在为其主要电子商务网站开发推荐模型的同时，通过构建部分 AI 数据基础设施构建了其第一个项目。推荐模型的训练相对简单。它是一个使用文件共享中已存在的数据集的判别模型。然而，在该项目结束时，该团队还构建了一个小型（但可扩展）的现代数据湖，实施了 MLOP 工具，并制定了一些用于训练和部署模型的最佳实践。尽管该模型并不复杂，但它仍然为他们的网站增加了许多效率。他们利用这些积极的结果为他们的下一个项目筹集资金，这将是一个生成式 AI 解决方案。

组织 #2 为他们的电子商务网站构建了一个聊天机器人，用于回答客户关于产品的问题。大型语言模型相当复杂 - 团队不熟悉微调或检索增强生成 - 因此该项目的所有工程师周期都专注于快速克服陡峭的学习曲线。模型完成后，它产生了还行的结果 - 没有什么特别的。不幸的是，它必须手动侧载到预生产和生产环境中，因为没有 MLOps 工具来部署它。这给 DevOps 团队带来了一点摩擦。该模型本身在生产中也存在一些稳定性问题。它运行的集群没有足够的计算能力来处理生成 AI 工作负载。有几个严重程度为 1 的呼叫，导致集群紧急增强，以便 LLM 不会在流量大的情况下失败。项目结束后，回顾会议确定，如果他们想在 AI 方面取得成功，他们需要增强基础设施。