1.2.2 关键组件

现在，让我们逐步介绍那些对于基本的深度学习系统至关重要的关键组件，如图1.3所示。你可以根据自己的需求添加其他组件，或进一步简化它们。

1.应用程序编程接口（API）

我们的深度学习系统的入口点（图1.3中的方框A）是一个可通过网络访问的API。我们之所以选择使用API，是因为系统不仅要支持供研究人员、数据科学家、数据工程师等使用的图形用户界面，还需要支持应用程序和其他相关系统——例如，合作机构的数据仓库。

虽然在概念上，API是系统的唯一入口点，但我们完全可以将API定义为每个组件提供的所有API的总和，而不需要额外的层来将所有内容聚合在单一服务端点下。在本书中，为简单起见，我们将直接使用每个组件提供的所有API的总和，并跳过聚合。

注意 应该使用集中式还是分布式深度学习系统API？在参考架构（图1.3）中，深度学习系统API表示为单个方框。我们应该将它解释为包含了你的深度学习系统API的完整集合的逻辑容器，无论它是实现在单个服务端点上（例如，代理所有组件的API网关）还是多个服务端点上（直接与每个组件交互）。每种实现方法都有其优点和缺点，你应该与你的团队一起找出最适合你的功能。如果你的用例和团队规模较小，那么直接与每个组件交互可能会更容易。

2.数据集管理器

深度学习基于数据。毫无疑问，数据管理组件是深度学习系统的核心组成部分。每个学习系统都是“垃圾进，垃圾出”的系统，因此确保学习的良好数据质量非常重要。一个好的数据管理组件应该为这个问题提供解决方案。它可以收集、组织、描述和存储数据，从而使得数据可以被探索、标注和用于模型训练。

在图1.3中，我们可以看到数据集管理器（方框B）与其他几个方面至少有4种关系：

● 数据收集器将原始数据推送到数据集管理器，以创建或更新数据集。

● 工作流编排服务（方框F）执行数据处理流水线，从数据集管理器中获取数据来增强训练数据集或转换数据格式，然后将结果推送回来。

● 数据科学家、研究人员和数据工程师使用Jupyter Notebook（方框G）从数据管理器中提取数据，并进行数据探索和检查。

● 模型训练服务（方框C）从数据管理器中拉取训练数据，进行模型训练。

我们将在第2章深入讨论数据集管理。在整本书中，我们将使用术语“数据集”来表示一组收集到的可能相互关联的数据。

3.模型训练器

模型训练器（也称为模型训练服务；方框C）负责提供基础计算资源（如CPU、RAM和GPU），以及运行模型训练代码和生成模型文件的作业管理逻辑。在图1.3中，我们可以看到工作流编排服务（方框F）告诉模型训练器执行模型训练代码。训练器从数据集管理器（方框B）获取输入训练数据，并生成一个模型。然后，它将带有训练指标和元数据的模型上传到元数据和工件存储（方框E）。

对于大型数据集，通常需要消耗大量的计算资源，以生成可以进行准确预测的高质量深度学习模型。采用新的算法和训练库/框架也是一个关键的要求。这些要求在以下几个方面会存在挑战：

● 减少模型训练时间——尽管训练数据的规模不断增长，模型架构的复杂性也在不断增加，但训练系统必须将训练时间维持在合理的范围内。

● 横向可伸缩性——一个有效的生产训练系统应该能够同时支持不同应用和用户的多个训练请求。

● 采用新技术的成本——深度学习社区充满活力，不断更新和改进算法及工具（SDK、框架）。训练系统应该足够灵活，既能够轻松地适应新的创新，又不干扰现有工作负载。

在第3章中，我们将探讨解决上述问题的不同方法。本书不会深入研究训练算法的理论，因为它们不会影响我们如何设计系统。在第4章中，我们将看看如何通过分布式训练来加速这个过程。在第5章中，我们将探讨一些优化训练超参数的不同方法。

4.模型服务

模型可以在各种环境中使用，例如，用于实时预测的在线推理或用于批量预测的离线推理，它们都需要处理大量输入数据。这就是模型服务的用武之地——当系统托管模型并接收输入的预测请求时，便会运行模型预测，并将预测结果返回给用户。对此我们需要回答一些关键问题：

● 你的推理请求是来自网络还是来自需要本地服务的传感器？

● 什么样的延迟是可以接受的？推理请求是按需的还是流式的？

● 有多少个模型正在提供服务？是每个模型独立地服务于一种类型的推理请求，还是一组模型共同提供服务？

● 模型大小有多大？需要预备多少内存容量？

● 需要支持哪些模型架构？它是否需要GPU？你需要多少计算资源来生成推理结果？是否还有其他支持性的服务组件，例如，嵌入、归一化或者聚合等？

● 是否有足够的资源来保持模型在线？或者是否需要使用换页策略（例如，在内存和磁盘之间移动模型）？

根据图1.3，模型服务（方框D）的主要输入和输出分别为推理请求和返回的预测结果。为了产生推理结果，可以从元数据和工件存储（方框E）中检索模型。一些请求及其响应可能会被记录并发送到模型监控和评估服务（在图1.3中未显示，本书中未涉及），该服务会从这些数据中检测异常并发出警报。在第6章和第7章中，我们将深入探讨模型服务架构，探索这些关键方面，并讨论它们的解决方案。

5.元数据和工件存储

想象一下你要独立开发一个简单的深度学习应用。你只需要处理少量的数据集，并且只训练和部署一种类型的模型。你能够跟踪数据集、训练代码、模型、推理代码和推理结果之间的关系。这些关系对于模型的开发和故障排查至关重要，因为你需要追溯某些观察结果的原因。

接下来假设增加了更多的应用程序、更多的人员和更多的模型类型。这些关系的数量将呈指数增长。在一个旨在支持多种类型的用户在多个数据集、代码和模型的各个阶段工作的深度学习系统中，需要一个组件来跟踪这些关系网。深度学习系统中的元数据和工件存储正是用来做这个的。工件包括用于训练模型和生成推理结果的代码，以及任何生成的数据，如已训练的模型、推理结果和度量指标。元数据是描述工件或工件之间关系的数据。一些具体的例子包括：

● 训练代码的作者和版本。

● 已训练模型的输入训练数据集和训练环境。

● 已训练模型的训练度量指标，比如训练日期和时间、持续时间以及训练作业的所有者。

● 特定的模型度量指标，比如模型版本、模型谱系（用于训练的数据和代码）以及性能指标。

● 生成某个推理结果的模型、请求和推理代码。

● 工作流历史记录，跟踪模型训练和数据处理流水线每一步的运行情况。

这些只是基线元数据和工件存储能够帮助跟踪的一些例子。你应该根据你的团队或组织的需求定制该组件。

图1.3中每个生成元数据的其他组件都将流向元数据和工件存储（方框E）。该存储在模型部署服务中也扮演着重要角色，因为它向模型部署服务（方框D）提供模型文件及其元数据。虽然图中没有显示，但我们通常会在用户界面层构建自定义的追踪系统和故障排查工具，这些工具依赖于元数据和工件存储的支持。

在学习第8章时，我们将深入了解基线元数据和工件存储。这个存储通常是深度学习系统用户界面的核心组件。

6.工作流编排

工作流编排（图1.3，方框F）在许多系统中普遍存在，它有助于根据编程条件自动启动计算任务。在机器学习系统的上下文中，工作流编排是深度学习系统中运行的所有自动化背后的驱动力。它允许人们定义工作流或流水线——有向无环图（DAG）——来将各个任务按照执行顺序连接在一起。工作流编排组件协调这些工作流的任务执行。一些典型的例子包括：

● 在构建新的数据集时自动启动模型训练。

● 监视上游数据源，增加新数据，转换其格式，通知外部标注者，并将新数据合并到现有数据集中。

● 如果模型符合某些公认的标准，则将训练后的模型部署到模型服务器。

● 持续监控模型性能指标，并在检测到退化时向开发人员发出警报。

在第9章中，你将学习如何构建或设置一个工作流编排系统。

7.交互式数据科学环境

出于合规性和安全性的原因，客户数据和模型不能从生产环境下载到本地工作站。为了让数据科学家能够交互式地探索数据、排查工作流编排中的问题以及调试模型，我们需要一个位于深度学习系统内部的远程交互式数据科学环境（图1.3，方框G）。

许多公司通常通过使用开源Jupyter Notebook（https://jupyter.org/）或利用云服务提供商的基于JupyterLab的解决方案（例如Amazon SageMaker Studio，https://aws.amazon.com/sagemaker/studio/）来建立可信赖的数据科学环境。

一个典型的交互式数据科学环境应该提供以下功能：

● 数据探索——为数据科学家提供访问客户数据的便捷途径，同时保持数据的安全性和合规性；确保没有数据泄漏，并拒绝任何未经授权的数据访问。

● 模型原型设计——为数据科学家在深度学习系统内快速开发概念验证（POC）模型提供必要的工具。

● 排查问题——使工程师能够调试深度学习系统中发生的任何活动，比如下载模型并分析其行为，或检查所有输入/输出工件（中间数据集或配置）以排查失效的流水线。