这篇文章的缩写版本于 2024 年 3 月 19 日出现在 The New Stack 上。

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

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

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

现代数据湖

让我们从定义现代数据湖开始，因为它将作为参考体系结构的基础。这种架构不是“再循环”的，而是反映了广泛适用的工程第一原则。现代数据湖是一半数据仓库和一半数据湖，对所有事情都使用对象存储。将对象存储用于 Data Lake 非常有意义，因为对象存储用于非结构化数据，而非结构化数据正是 Data Lake 要存储的内容。但是，将对象存储用于数据仓库可能听起来很奇怪，但以这种方式构建的数据仓库代表了下一代数据仓库。这是由 Netflix、Uber 和 Databricks 编写的开放表格式规范 （OTF） 实现的，这使得在数据仓库中无缝使用对象存储成为可能。

OTF 包括 Apache Iceberg、Apache Hudi 和 Delta Lake。它们分别由 Netflix、Uber 和 Databricks 编写，因为市场上没有可以处理其数据需求的产品。 从本质上讲，它们所做的（以不同的方式）都是定义一个可以构建在对象存储 （MinIO） 之上的数据仓库。对象存储提供了可扩展容量和高性能的组合，这是其他存储解决方案无法做到的。由于这些是现代规范，因此它们具有老式数据仓库所不具备的高级功能，例如分区演变、模式演变和零副本分支。最后，由于数据仓库是使用对象存储构建的，因此您可以将相同的对象存储用于图像、视频文件、音频文件和文档等非结构化数据。非结构化数据通常存储在业界所谓的数据湖中。使用对象存储作为数据湖和数据仓库的基础，可以生成能够保存所有数据的解决方案。结构化存储驻留在基于 OTF 的数据仓库中，非结构化存储驻留在数据湖中。MinIO 的同一实例可用于两者。

在 MinIO，我们将基于 OTF 的数据仓库和数据湖的这种组合称为现代数据湖，我们将其视为所有 AI/ML 工作负载的基础。它是收集、存储、处理和转换数据的地方。使用判别性 AI（监督式、无监督式和强化式学习）的训练模型通常需要一种存储解决方案，该解决方案可以处理可以存在于数据仓库中的结构化数据。另一方面，如果要训练大型语言模型 （LLMs），则必须在 Data Lake 中以原始和处理形式管理非结构化数据或文档。

本文重点介绍适用于 AI/ML 的现代数据湖参考架构中支持不同 AI/ML 工作负载的领域。下面列出了这些功能领域。现代数据湖的直观描述如上所示。突出显示了可以找到这些功能区域的图层。

1 . 判别性人工智能

• 非结构化数据存储

• 半结构化数据存储

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

2 . 生成式 AI

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

• 构建文档管道

• 检索增强生成 （RAG）

• 微调大型语言模型

• 测量LLM精度

3 . 机器学习操作

这篇文章还探讨了 GPU 的当前状态以及它们如何影响您的 AI 数据基础设施。我们还将介绍几个场景，这些场景说明了如何构建基础结构以及如何不构建基础结构。最后，这篇文章提出了一些关于构建自己的 AI 数据基础设施的建议。

4 . GPU 的现状

• 饥饿的 GPU 问题

• 增强对象存储能力

5 . 两个组织的故事

6 . 构建 AI 数据基础设施的计划

判别性人工智能

判别性 AI 模型需要所有类型的数据进行训练。图像分类和语音识别模型将使用图像和音频文件形式的非结构化数据。另一方面，欺诈检测和医疗诊断模型基于结构化数据进行预测。让我们看一下现代数据湖中可用于存储和操作判别性 AI 所需数据的选项。

非结构化数据存储

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

半结构化数据存储

Modern Datalake 中有几个选项可用于存储半结构化文件，如 Parquet 文件、AVRO 文件、JSON 文件，甚至 CSV 文件。最简单的方法是将它们存储在 Data Lake 中，并像加载非结构化对象一样加载它们。如果新式数据湖支持的其他工作负载（商业智能、数据分析和数据科学）不需要这些半结构化文件中的数据，则这是最佳选择。

另一种选择是将这些文件加载到数据仓库中，其他工作负载可以在其中使用它们。将数据加载到数据仓库中时，可以使用零拷贝分支对数据执行试验。

数据仓库中的零拷贝分支

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

生成式 AI

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

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

使用向量数据库创建自定义语料库

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

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

SELECT snippet
FROM MyCorpusTable
WHERE (text like '%artificial intelligence%' OR
	text like '%ai%' OR
	text like '%machine learning%' OR
	text like '%ml%' OR
 	... and on and on ...

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

{
Get {
	MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) 

      {snippet}
    }
} 

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

矢量数据库的核心是存储非结构化数据。因此，他们应使用你的 Data Lake 作为其存储解决方案。

构建文档管道

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

文档管道还应将文档转换为文本。幸运的是，一些开源库可以对许多常见的文档格式执行此操作。此外，文档管道必须先将文档分解为小段，然后才能将其保存到矢量数据库中。这是由于将这些文档用于检索增强生成时对提示大小的限制，这将在后面的章节中讨论。

微调大型语言模型

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

如果您的域包含日常使用中找不到的术语，则微调可能会提高 LLM的响应质量。例如，使用医学研究、环境研究以及与自然科学相关的任何文献的项目可能会从微调中受益。微调采用文档中高度具体的方言，并将它们烘焙到模型的参数参数中。在决定这种方法之前，应了解微调的优缺点。

缺点

• 微调将需要计算资源。

• 可解释性是不可能的。

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

• 幻觉是一个问题。

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

优势

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

• 推理流程没有 RAG 那么复杂。

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

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

检索增强生成 （RAG）

检索增强生成 （RAG） 是一种从所问问题开始的技术 - 使用向量数据库将问题与其他数据结合起来，然后将问题和数据传递给 an LLM 进行内容创建。使用 RAG，不需要任何培训，因为我们通过从我们的优质文档语料库中向它发送相关的文本片段来教育它LLM。

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

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

缺点

• 推理流程更为复杂。

优势

• 从您的自定义语料库LLM中获取直接知识。

• 可解释性是可能的。

• 无需微调。

• 幻觉显着减少，可以通过检查向量数据库查询的结果来控制。

• 可以实现授权。

机器学习操作 （MLOps）

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

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

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

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

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

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

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

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

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

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

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

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

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

GPU 对 AI 数据基础架构的影响

链的强度取决于其最薄弱的环节，而 AI/ML 基础架构的速度取决于最慢的组件。如果使用 GPU 训练机器学习模型，则薄弱环节可能是存储解决方案。结果就是我们所说的“饥饿 GPU 问题”。 当您的网络或存储解决方案无法以足够快的速度向训练逻辑提供训练数据以充分利用 GPU 时，就会出现 GPU 不足问题。症状相当明显。如果您监控 GPU，您会注意到它们永远不会被充分利用。如果您已经检测了训练代码，那么您会注意到总训练时间由 IO 主导。

不幸的是，对于那些正在为这个问题而苦苦挣扎的人来说，有一个坏消息。GPU 的速度越来越快。让我们看看GPU的现状以及它们正在取得的一些进展，以了解这个问题在未来几年只会变得更糟。

GPU 的现状

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

GPU	PERFORMANCE	MEMORY	MEMORY BANDWIDTH
A100	624 TFLOPS	40GB	1,555GB/s
H100	1,979 TFLOPS	80GB	3.35TB/s
H200	1,979 TFLOPS	141GB	4.8TB/s

注意：上表使用的统计信息与 A100 的 PCIe（外围组件互连快速）插槽解决方案以及 H100 和 H200 的 SXM（服务器 PCI Express 模块）插槽解决方案一致。A100 不存在 SXM 统计信息。在性能方面，使用 Floating Point 16 Tensor Core 统计数据进行比较。

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

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

性能 - 万亿次浮点运算 （TFLOP） 是每秒一万亿次 （10^12） 浮点运算。这是一个 1，后面有 12 个零 （1,000,000,000,000）。很难将 TFLOP 等同于以 GB 为单位的 IO 需求，因为在模型训练期间发生的浮点运算涉及简单的张量数学以及针对损失函数的一阶导数（也称为梯度）。但是，可以进行相对比较。从上面的统计数据来看，我们看到 H100 和 H200 的运行速度均为 1,979 TFLOPS，速度提高了三倍——如果其他一切都能跟上，消耗数据的速度可能会快 3 倍。

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

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

增强对象存储，用于模型训练

如果您遇到 GPU 饥饿问题，请考虑使用 100 GB 网络和 NVMe 驱动器。最近使用具有此类配置的 MinIO 的基准测试在 GET 上实现了 325 GiB/s，在 PUT 上实现了 165 GiB/s，仅使用了 32 个现成的 NVMe SSD 节点。

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

两个组织的故事

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

组织 #2 具有“闪亮对象”文化。当最新想法进入行业时，它首先要解决最引人注目的挑战，以展示其技术实力。他们发现这些项目在内部和外部都非常引人注目。如果有什么东西坏了，那么聪明的人总是可以修复它。

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

组织 #2 为他们的电子商务网站构建了一个聊天机器人，可以回答客户关于产品的问题。大型语言模型相当复杂 - 团队不熟悉微调或检索增强生成 - 因此该项目的所有工程师周期都集中在快速通过陡峭的学习曲线上。当模型完成时，它产生了不错的结果 - 没有什么了不起的。遗憾的是，由于没有 MLOps 工具来部署它，因此必须手动将其旁加载到预生产和生产环境中。这引起了DevOps团队的一些摩擦。该模型本身在生产中也存在一些稳定性问题。运行它的集群没有足够的计算来应对生成式 AI 工作负载。有一些严重性为一的呼叫，这导致了对集群的紧急增强，因此在繁忙的流量条件下LLM不会出现故障。项目结束后，回顾性会议确定，如果他们要在人工智能方面取得成功，就需要增强他们的基础设施。

构建 AI/ML 数据基础架构的计划

上面的短篇内容是对两种极端情况的简单叙述。构建 AI 模型（包括判别模型和生成模型）与传统软件开发有很大不同。在排队 AI/ML 工作时，应考虑到这一点。下图是上一节中讲述的故事的视觉描述。这是 AI 数据基础设施优先与模型优先方法的并排比较。正如上面的故事所显示的 - 下面用于基础设施优先方法的每一块砖都不必是一个独立的项目。组织应该在构建基础设施的同时寻找创造性的方法来交付 AI——这可以通过了解 AI 的所有可能性，从简单开始，然后选择越来越复杂的 AI 项目来完成。

结论

这篇文章概述了我们与企业合作构建适用于 AI/ML 的现代数据湖参考架构的经验。它确定了不同人工智能方法的核心组件、关键构建块和权衡。基础元素是在对象存储之上构建的现代数据湖。对象存储必须能够大规模提供性能 - 其中规模为数百 PB，通常为 EB。