第三部分 构建分布式机器学习工作流 如果您已经学习到了这里，那么恭喜您！ 您已经学习了许多可以在现实机器学习系统中使用的常见模式，并且了解了在决定将哪些模式应用到系统时，需要权衡的因素。
在本书的最后一部分，我们将构建一个端到端的机器学习系统来应用之前学到的知识。 我们将通过这个项目获得实践经验，来实现许多之前学到的模式。 我们将学习如何解决大规模的问题，并将笔记本电脑上开发的内容应用于大型分布式集群。
在第七章中，我们将介绍项目背景和系统组件。 然后，我们将逐一探讨这些组件带来的挑战，并分享我们面对这些挑战所应用的模式。 第八章涵盖了 4 项技术（TensorFlow、Kubernetes、Kubeflow 和 Argo Workflows）的基本概念，并为我们提供了每种技术的实践机会，为最终项目的实施做准备。
在本书的最后一章中，我们将使用第七章中设计的架构来实现端到端的机器学习系统。 同时，使用在第八章中学到的技术来构建分布式机器学习工作流的不同组件。
项目概述及系统架构
本章涵盖 系统总体设计 优化多轮迭代数据集的数据摄取组件 决定使用哪种分布式模型训练策略以最大限度地减少开销 添加模型服务器副本以实现高性能模型服务 加速端到端机器学习系统工作流
在前面的章节中，我们学习了如何选择和应用正确的模式来构建和部署分布式机器学习系统，以获得管理和自动化机器学习任务的实践经验。 第二章介绍了一些可以融入到数据摄取中的实用模式，这通常是分布式机器学习系统的第一个步骤，负责监控传入数据并执行必要的预处理步骤，为模型训练做准备。
在第三章中，我们探讨了分布式训练组件面临的一些挑战，并且介绍了一些可以整合到组件中的实用模式。 分布式训练组件是分布式机器学习系统中最关键的部分，这也是该系统和一般分布式系统的区别所在。 在第四章中，我们讨论了分布式模型服务系统所面临的挑战，并介绍了一些常用的模式。 您可以使用复制服务来实现水平扩展，并使用分片服务模式来处理大型模型服务请求。 您还学习了如何评估模型服务系统，并评估事件驱动设计在现实场景中是否能带来收益。
在第五章中，我们讨论了机器学习工作流，它是机器学习系统中最重要的组件之一，因为它连接了机器学习系统中的所有组件。 最后，在第六章中，我们讨论了一些运维模式，当工程团队在系统投入生产之前、与数据科学家或机器学习团队协作时，这些模式可以极大地加速端到端工作流并减少维护和沟通工作。
在本书的剩余章节中，我们将构建一个端到端的机器学习系统来应用我们之前学到的知识。 您将获得我们之前讨论过的许多模式的实践经验，还将学习到如何解决大规模的问题，并将笔记本电脑上开发的内容应用于大型分布式集群。 在本章中，我们将介绍项目背景和系统组件，然后讨论与组件相关的挑战，以及可以应用哪些的模式来解决它们
请注意，虽然我们不会在本章中深入探讨实现细节，但在剩余的章节中，我们将使用几种流行的框架和前沿技术，特别是 TensorFlow、Kubernetes、Kubeflow、Docker 和 Argo Workflows 来构建分布式机器学习工作流组件。
7.1 项目概况 在这个项目中，我们将构建一个图像分类系统，该系统从数据源下载原始图像，执行必要的数据清洗步骤，在分布式 Kubernetes 集群中构建机器学习模型，然后将训练好的模型部署到模型服务系统中供用户使用。 我们还希望建立一个高效且可复用的端到端工作流。 接下来，我将介绍项目背景、系统架构和组件。
7.1.1 项目背景 我们将构建一个端到端的机器学习系统来应用我们之前学到的知识。 首先，我们构建一个用于下载 Fashion-MNIST 数据集的数据摄取组件，以及一个用于训练和优化图像分类模型的模型训练组件。 一旦最终模型训练完成，我们将构建一个高性能的模型服务系统，开始使用训练好的模型进行预测。
正如之前提到的，我们将使用多种框架和技术来构建分布式机器学习工作流组件。 例如，我们将使用 TensorFlow 和 Python 在 Fashion-MNIST 数据集上构建分类模型并进行预测。 然后使用 Kubeflow 在 Kubernetes 集群上运行分布式机器学习模型训练。 最后，使用 Argo Workflows 构建一个机器学习流水线，其中包含了分布式机器学习系统的许多重要组件。 这些技术的基础知识将在下一章中介绍，在第九章中深入了解项目的实施细节之前，您将得到这些技术的实践经验。 在下一节中，我们将深入探究项目所涉及的组件。
7.1.2 系统组件 图 7-1 是我们将要构建的系统的架构图。 首先，我们构建数据摄取组件，负责使用第二章中讨论的一些模式摄取数据并将数据集存储在缓存中。 接下来，我们将构建三个不同的模型训练步骤，结合第三章中讨论的集合通信模式训练不同的模型。 完成模型训练步骤后，我们将构建模型选择步骤，挑选出最佳模型。 选定的最佳模型将用于接下来的两个模型服务步骤。 在模型服务步骤结束时，我们汇总预测结果并呈现给用户。 最后，我们希望确保所有这些步骤都是可重复运行的工作流的一部分，可以在任何环境中随时执行。
我们将根据图 7-1 中的架构图构建系统，并深入研究各个组件的细节。 我们还将讨论可用于解决构建这些组件时遇到的挑战的模式。
图 7-1 我们将要构建的端到端机器学习系统的架构图
The machine learning workflow is triggered. 机器学习工作流被触发。
Three model training steps train different models. 3 个模型训练步骤分别训练不同的模型。
This step picks the top model that will be used in the following model serving steps. 此步骤挑选出最佳的模型，用于接下来的模型服务步骤。
The results from the two model serving steps are then aggregated via a result aggregation step to present to users. 然后，通过结果聚合步骤将两个模型服务步骤的结果聚合，呈现给用户。
7.2 数据摄取 在这个项目中，我们将使用 2.2 节中介绍的 Fashion-MNIST 数据集来构建数据摄取组件，如图 7-2 所示。 该数据集由 60,000 个训练样本和 10,000 个测试样本组成。每个样本都是一张 28 × 28 灰度图像，代表与 10 个类别中的一个标签相关联的 Zalando 商品图像。 回想一下，Fashion-MNIST 数据集旨在作为原始 MNIST 数据集的直接替代品，用于对机器学习算法进行基准测试。 它有着相同的图像大小和相同的图像分割结构。
图 7-2 端到端机器学习系统中的数据摄取组件（深色框）
The machine learning workflow is triggered. 机器学习工作流被触发。
回顾一下，图 7-3 是 Fashion-MNIST 中所有 10 个类别（T 恤/上衣、裤子、套头衫、连衣裙、外套、凉鞋、衬衫、运动鞋、包和靴子）的图像集，其中每个类别在图像集中占三行。
图 7-4 展示了训练集中的前几个示例图像及其对应的文本标签。
下载的 Fashion-MNIST 数据集在压缩后仅占用 30 MB 的磁盘空间。 可以轻松地将整个数据集一次性加载到内存中。
7.2.1 问题 尽管 Fashion-MNIST 数据量不大，但在将数据集输入模型之前，我们可能需要执行额外的计算，这对于需要额外数据转换和清洗的任务来说是很常见的。 我们可能想要调整图像大小、标准化图像或将图像转换为灰度。 我们还可能想要执行复杂的数学运算，例如卷积运算，这可能需要大量的额外内存空间分配。 将整个数据集加载到内存后，我们的可用计算资源可能充足，也可能不足，具体取决于分布式集群的大小。
图 7-3 Fashion-MNIST 数据集中所有 10 个类别（T 恤/上衣、裤子、套头衫、连衣裙、外套、凉鞋、衬衫、运动鞋、包和靴子）的图像集合
Every three rows represent example images that represent a class. For example, the top three rows are images of T-shirts. 每 3 行代表代表一个类别的示例图像。例如，前 3 行是 T 恤的图像。
图 7-4 训练集中的前几个示例图像及其对应的文本标签
此外，我们的机器学习模型需要在数据集上进行多轮训练。 假设在整个训练数据集上迭代训练一轮需要 3 小时。 如果我们要进行两轮迭代训练，模型训练所需的时间就会加倍，如图 7-5 所示。
图 7-5 t0、t1 等时刻多轮迭代进行模型训练的示意图，每轮迭代花费 3 小时
在实际的机器学习系统中，通常需要大量的迭代训练。如果按顺序训练，那么每个迭代的效率会很低。 在下一节中，我们将讨论如何解决这种效率低的问题。
7.2.2 解决方案 让我们看看所面临的第一个挑战：机器学习算法中的数学运算可能需要大量额外的内存空间分配，而计算资源可能充足也可能不足。 鉴于我们没有太多的空闲内存，我们不应该直接将整个 Fashion-MNIST 数据集加载到内存中。 假设我们希望在数据集上执行的数学运算也可以在整个数据集的子集上执行。 那么，我们可以使用第二章中介绍的批处理模式，它将整个数据集中的多个数据记录分组为多个批次，然后依次在每个批次上训练机器学习模型。
为了应用批处理模式，我们首先将数据集划分为多个小的子集或 mini-batch，加载每个单独的 mini-batch 的示例图像，对每个批次执行大量的数学运算，然后在每个模型中仅使用一个 mini-batch 的图像训练迭代。 例如，我们可以对仅由 20 张图像组成的第一个 mini-batch 执行卷积或其他繁重的数学运算，然后将转换后的图像发送到机器学习模型进行训练。 接下来，我们对剩余的 mini-batch 重复相同的过程，同时执行模型训练。
由于我们已将数据集划分为许多小的子集（mini-batch），因此在对整个数据集执行各种繁重的数学运算（这在 Fashion-MNIST 上实现准确的分类模型是必须的）时，我们可以避免内存不足导致的潜在问题。 然后，我们可以通过减小 mini-batch 的大小来处理更大的数据集。 在批处理模式的帮助下，我们在获取数据集进行模型训练时不再担心潜在的内存不足问题。 我们不必立即将整个数据集加载到内存中，而是可以依次逐批地使用数据集。 例如，如果我们有一个包含 1,000 条记录的数据集，我们可以先从 1,000 条记录中取出 500 条形成一个批次，然后使用该批次的数据来训练模型。 随后，我们可以对剩余的数据重复这个批处理和模型训练过程。 图 7-6 展示了此过程，其中原始数据集被分为两批并按依次处理。 第一个批次在时间 t0 用于训练模型，第二个批次在时间 t1 被使用。
图 7-6 数据集分为两批并依次处理。第一个批次在时间 t0 用于训练模型，第二个批次在时间 t1 被使用。
The two batches of the dataset are consumed sequentially for model training. 这两批数据集依次用于模型训练。
现在，让我们解决 7.2.1 节中提到的第二个挑战：如果我们需要训练一个涉及在原始数据集上进行多轮迭代的机器学习模型，我们不希望浪费过多的时间。 回想一下，在第二章中，我们讨论了可以解决此类问题的缓存模式。 借助缓存模式，我们可以大大加快模型训练过程中对数据集的重复访问速度，该过程涉及在多轮迭代中对同一数据集进行训练。
对于第一轮迭代，我们无法做特别的处理，因为这是模型第一次读取整个训练数据集。 我们可以将训练样本的缓存存储在内存中，这样在第二次及后续的迭代轮次中重新访问该数据时速度会快得多。
假设我们用于模型训练的笔记本电脑具有足够的计算资源，例如：内存和磁盘空间充足。 在机器学习模型消费了整个数据集中的每个训练样本后，我们可以选择不立即回收样本数据，而是将消费过的训练样本保留在内存中。 例如，在图 7-7 中，在完成第一轮迭代的模型拟合后，我们可以缓存第一轮迭代训练中所使用的两个批次的样本。
然后，我们可以通过直接将缓存提供给模型来开始第二轮迭代训练，而无需在后续的迭代中重复读取数据源。 接下来，我们将讨论如何在项目中构建模型训练组件。
图 7-7 使用缓存对 t0、t1 等时刻多轮迭代进行模型训练的示意图，无需重复读取数据源
7.2.3 练习 1 我们将缓存存储在哪里？ 2 当 Fashion-MNIST 数据集变大时，我们可以使用批处理模式吗？
7.3 模型训练 在上一节中，我们讨论了数据摄取组件，以及如何使用缓存和批处理模式来处理大型数据集并提高系统效率。 接下来，我们讨论一下模型训练组件。 图 7-8 是模型训练组件的整体架构图。
在图中，3 个不同的模型训练步骤之后是模型选择步骤。 这些模型训练步骤可以训练出 3 个不同的模型，它们之间相互对比以获得更好的统计性能。 然后，模型选择步骤会挑选出最佳的模型，该模型将在后续的端到端机器学习工作流组件中被使用。
在下一节中，我们将更深入地研究图 7-8 中的模型训练组件，并讨论实现该组件时可能遇到的问题。
图 7-8 端到端机器学习系统中的模型训练组件（深色框）
Three model training steps train different models. 3 个模型训练步骤训练不同的模型。
This step picks the top two models that will be used in the following two separate model serving steps. 此步骤挑选出将在以下两个单独的模型服务步骤中使用的前两个性能最佳的模型。
7.3.1 问题 第三章中介绍了参数服务器和集合通信模式。 当模型太大而无法被容纳在一台机器中时，可以考虑使用参数服务器模式，例如：用于在 800 万个 YouTube 视频中进行实体标记的模型（第 3.2 节）。 当通信开销很大时，集合通信模式有助于加快中等模型的训练过程。 我们应该为模型训练组件选择哪种模式呢？
7.3.2 解决方案 借助参数服务器，我们可以有效解决不适合在单台机器中进行大型机器学习模型训练的问题。 即使模型太大而无法容纳在单台机器中，我们仍然可以使用参数服务器高效地训练模型。 例如，图 7-9 是使用多台参数服务器进行模型训练的架构图。 每个工作节点获取数据集的一个子集，执行每个神经网络层所需的计算，并发送计算好的梯度以更新存储在某个参数服务器中的一个模型分区。
由于所有工作节点都以异步方式执行计算，因此每个工作节点中用于计算梯度的模型分区可能不是最新的。 例如，两个工作节点在向同一个参数服务器发送梯度时可能会相互阻塞，这使得我们及时收集计算出的梯度变得困难，因此需要一种策略来解决阻塞问题。 在包含参数服务器的分布式训练系统中，多个工作节点可能同时发送梯度，因此我们首先要解决多节点通信阻塞的问题。
图 7-9 包含多个参数服务器的机器学习训练组件
另一个挑战是如何确定工作节点数量和参数服务器数量之间的最佳比例。 例如，当许多工作节点同时向同一个参数服务器发送梯度时，问题会变得更加严重，最终，不同工作节点或参数服务器之间的通信阻塞成为了瓶颈。
现在，让我们回到最初的应用，也就是 Fashion-MNIST 分类模型。 我们构建的模型并不像大型推荐系统模型那么大，如果我们为机器提供足够的计算资源，它可以很轻易地部署在单台机器中。 因为它压缩后只有 30 MB。 因此，集合通信模型非常适合我们所构建的系统。
现在，如果没有参数服务器，每个工作节点都会存储整套模型的副本，如图 7-10 所示。 我之前提到过，每个工作节点都会消费一部分数据，并计算出该节点的模型参数更新所需的梯度（参考第三章）。 我们希望在所有工作节点完成梯度计算后立即聚合所有梯度，并确保每个工作节点的整套模型参数都根据聚合的梯度进行更新。 换句话说，每个工作节点都应该存储一份完全相同的模型副本。
回到图 7-8 中的架构图，每个模型训练步骤都使用集合通信模式，利用底层网络基础设施执行 allreduce 操作，以在多个工作节点之间传递梯度。 集合通信模式还允许我们在分布式环境中训练多个中等大小的机器学习模型。 一旦模型训练完成，我们就可以使用一个单独的步骤来选择用于模型服务的最佳模型。 这个步骤非常直观，我将把具体的实现细节推迟到第九章中讲解。 在下一节中，我们将讨论模型服务组件。
图 7-10 只包含工作节点的分布式模型训练组件，其中每个工作节点存储整个模型的副本并使用数据分区来计算梯度
Each of these workers contains a copy of the entire set of model parameters and consumes partitions of data to calculate the gradients. 每个工作节点都包含整个模型参数的副本，并使用数据分区来计算梯度。
7.3.3 练习 1 为什么参数服务器模式不适合我们的模型？ 2 使用集合通信模式时，每个工作节点是否存储模型的不同部分？
7.4 模型服务 我们已经探讨了数据摄取和模型训练组件。接下来探讨一下模型服务组件，这对于系统最终的用户体验至关重要。 图 7-11 展示了模型服务组件架构图。
接下来，让我们看一下构建该组件时可能会遇到的潜在问题及其解决方案。
7.4.1 问题 模型服务系统需要获取用户上传的原始图像，并将请求发送到模型服务器，以使用训练好的模型进行推理。 这些模型服务请求正在排队并等待模型服务器处理。
如果模型服务系统是单节点服务器，则它只能以先到先得的原则处理有限数量的模型服务请求。 随着请求量的增加，用户必须等待很长时间才能收到模型服务的结果，因此用户体验会受到影响。 也就是说，所有请求都在等待模型服务系统的处理，但计算资源受限于这单个节点。我们应该如何构建更高效的模型服务系统呢？
图 7-11 端到端机器学习系统中的模型服务组件（深色框）
The results from the two model serving steps are then aggregated via a result aggregation step to present to users. 然后，通过结果聚合步骤将两个模型服务步骤的结果聚合，呈现给用户。
7.4.2 解决方案 上一节为第四章中讨论的复制服务模式提供了一个完美的用例。 我们的模型服务系统接收用户上传的图像并向模型服务器发送请求。 此外，与简单的单台服务器设计不同，系统具有多个模型服务器副本来异步处理模型服务请求。 每个模型服务器副本接收一个请求，从模型训练组件中检索之前训练好的分类模型，并对 Fashion-MNIST 数据集中不存在的图像进行分类。
借助复制服务模式，我们可以通过向单服务器模型服务系统添加服务器副本来轻松扩展模型服务器。 新的架构如图 7-12 所示。 模型服务器副本可以同时处理多个请求，因为每个副本可以独立地处理各自的模型服务请求。
在我们引入模型服务器副本后，用户的多个模型服务请求会同时发送到模型服务器副本上。 我们还需要明确模型服务请求和模型服务器副本之间的映射关系，这决定了哪些请求由哪个模型服务器副本处理。
为了在副本之间分配模型服务请求，我们需要添加一个额外的负载均衡层。 例如，负载均衡器接收多个模型服务请求。 然后，它将请求均匀地分配给模型服务器副本，再由模型服务器副本负责处理各个请求，包括模型检索和对请求数据进行推理。 图 7-13 阐述了这个过程。
图 7-12 副本模型服务的系统架构
Users upload images and then submit requests to the model serving system for classification. 用户上传图像，然后向模型服务系统提交图像分类请求。
图 7-13 显示负载均衡器如何在模型服务器副本之间均匀分配请求的示意图
Multiple model serving requests from users 来自用户的多个模型服务请求。
The load balancer distributes the requests evenly among the model server replicas. 负载均衡器在模型服务器副本之间均匀分配请求。
负载均衡器使用不同的算法来决定哪个请求发送到哪个特定的模型服务器副本。 负载均衡的示例算法包括轮询算法（round robin）、最少连接算法（least-connection）和哈希算法（hashing）。
从图 7-11 原始架构图中可以看到，模型服务有两个单独的步骤，每个步骤使用不同的模型。 每个模型服务步骤都包含一个具有多副本的模型服务，用于处理不同模型的模型服务流量。
7.4.3 练习 1 如果模型服务系统中没有负载均衡器会怎么样？
7.5 端到端工作流 我们已经了解了各个组件，让我们看看如何用可扩展且高效的方式构建一个包含所有组件的端到端工作流。 我们还将在工作流中加入第五章介绍的一些模式。图 7-14 是我们正在构建的端到端工作流的架构图。
图 7-14 我们将要构建的端到端机器学习系统的架构图
The machine learning workflow is triggered. 工作流被触发。
Three model training steps train different models. 3 个模型训练步骤训练不同的模型。
This step picks the top model that will be used in the following model serving steps. 这一步选择将在接下来的模型服务步骤中使用的最佳模型。
The results from the two model serving steps are then aggregated via a result aggregation step to present to users. 然后，通过结果聚合步骤将两个模型服务步骤的结果聚合，呈现给用户。
我们不关注单个组件，而是着眼于整个机器学习系统，该系统将所有组件以端到端工作流的方式连接在一起。
7.5.1 存在的问题 首先，Fashion-MNIST 数据集是静态的，不会随时间变化。然而，为了设计一个更贴近现实的系统，我们假设 Fashion-MNIST 数据集会定期手动更新。 每当数据集更新时，我们可能希望重新运行整个机器学习工作流，以训练包含最新数据的机器学习模型。 换句话说，每次数据集发生变化时，我们都需要执行数据摄取步骤。 同时，当数据集没有更新时，我们希望尝试新的机器学习模型。 因此，我们仍然需要重新执行整个工作流，包括数据摄取步骤。 然而，数据摄取步骤通常非常耗时，尤其是大型数据集。 有没有办法让这个工作流更加高效呢？
其次，我们希望构建一个可以训练不同的模型的机器学习工作流，然后选择表现最佳的两个模型应用于模型服务，以生成预测。 由于现有机器学习工作流中每个模型训练步骤的完成时间存在差异，后续每个步骤（例如：模型选择和模型服务）的开始取决于前面步骤的完成情况。 然而，工作流中顺序执行步骤非常耗时，并且会阻塞其余步骤。 例如，假设一个模型训练步骤的完成时间比其他步骤要长得多。 只有在这个长时间运行的模型训练步骤完成后，后续的模型选择步骤才能开始执行。 结果，整个工作流被这个步骤延迟了。 有没有办法加速这个工作流，使其不受单个步骤持续时间的影响？
7.5.2 解决方案 对于第一个问题，我们可以使用第五章中的步骤记忆化模式。 回想一下，步骤记忆化可以帮助系统决定是否执行或跳过某个步骤。 借助步骤记忆化，工作流可以识别出冗余的步骤，这些步骤可以跳过而无需重新执行，从而大大加快端到端工作流的执行速度。。
例如，图 7-15 包含一个简单的工作流，只有在我们知道数据集已经更新时才执行数据摄取步骤。 也就是说，如果新数据没有更新，不会重新摄取已经收集的数据。
有许多策略可以用来确定数据集是否已经更新。 通过预定义的策略，我们可以重构机器学习工作流，并控制是否要包含一个需要重新执行的数据摄取步骤，如图 7-16 所示。
缓存是一种确定数据集是否已经更新的方法。 假设 Fashion-MNIST 数据集定期更新（例如：每月更新一次），我们可以创建一个基于时间的缓存，用于存储摄取的数据集的位置（假设数据集位于远程数据库）及其最后更新的时间戳。
图 7-15 数据集未更新时跳过数据摄取步骤的示意图
The dataset has not been updated yet. 数据集尚未更新。
New model type or hyperparameters? 是否为新的模型类型或超参数？
如图 7-16 所示，工作流中的数据摄取步骤将根据最后更新的时间戳来确定是否在特定窗口内动态构建和执行。 例如，如果时间窗口设置为两周，如果摄取的数据在过去两周内更新过，我们仍然认为该数据是最新的。 数据摄取步骤将被跳过，并且接下来的模型训练步骤将使用缓存中已摄取的数据集。 时间窗口可用于控制缓存的有效期，在有效期内我们都认为数据集足够新，可以直接用于模型训练而不需要重新摄取数据。
图 7-16 工作流被触发。我们通过访问缓存来检查数据在过去两周内是否有更新。 如果数据是最新的，我们可以跳过不必要的数据摄取步骤，直接执行模型训练步骤。
The workflow is triggered. 工作流被触发。
Writes new cache or reads existing cache that contains timestamp information 写入新的缓存或读取包含时间戳信息的当前缓存
The data has been updated within the last two weeks. 数据在过去两周内已经更新。
The data has not been updated within the last two weeks. 数据在过去两周内没有更新。
现在，我们来看看第二个问题：步骤的顺序执行会阻塞工作流中的后续步骤，降低了效率。 而第五章中介绍的同步和异步模式有助于解决这个问题。
当一个短时间运行的模型训练步骤完成时（例如：图 7-17 中的模型训练步骤 2），我们成功地获得了一个训练好的机器学习模型。 我们可以直接在模型服务系统中使用这个已经训练好的模型，而无需等待其余的模型训练步骤完成。 因此，一旦我们通过工作流训练好了一个模型，用户就能够通过模型服务请求得到图像分类的结果。 第二个模型训练步骤（图 7-17 中的模型训练步骤 3）完成后，两个训练好的模型将被传递到模型服务中。 现在，用户就能够得到 2 个模型的聚合结果了。
图 7-17 第二个模型训练步骤完成后，我们可以将两个训练好的模型直接传递给模型服务。2 个模型聚合的推理结果将呈现给用户。
After a second model training step finishes, we can pass the two trained models directly to be used for model serving, and the aggregated inference results will be presented to users instead of the results from only the one model that we obtained initially. 第二个模型训练步骤完成后，我们可以将两个训练好的模型直接传递给模型服务，并将 2 个模型聚合的推理结果将呈现给用户。
Both short-running model training steps have finished. 两个短时间运行的模型训练步骤均已完成。
因此，我们可以继续使用训练好的模型进行模型选择和模型服务。同时，长时间运行的模型训练步骤也在运行。 它们可以不依赖于彼此的完成情况异步执行。 工作流可以在上一个步骤完成之前执行下一个步骤。 这样长时间运行的模型训练步骤将不再阻塞整个工作流。 相反，它可以继续使用模型服务系统中通过短时间运行的模型训练步骤所训练的模型，然后立即开始处理用户的模型服务请求。
7.5.3 练习 1 哪个组件可以从步骤记忆化中获得最大收益？ 2 如果触发了工作流中某个步骤的再次运行，如何判断该步骤是否可以跳过？
7.6 习题答案 第 7.2 节 1 在内存中 2 是的
第 7.3 节 1 工作节点和参数服务器之间存在通信阻塞问题。 2 不，每个工作节点都存储完全相同的模型副本。 第 7.4 节 1 我们将无法在多个副本之间平衡并分配模型服务请求。 第 7.5 节 1 数据摄取组件 2 使用步骤缓存中的元数据判断
总结 数据摄取组件使用缓存模式来加速处理多轮迭代的数据集。 模型训练组件使用集合通信模式来避免工作节点和参数服务器之间潜在的通信开销。 我们可以使用模型服务器副本，每个副本独立处理模型服务请求，因此它能够同时处理多个请求。 我们可以将所有组件连接到一个工作流中，并使用缓存来有效地跳过耗时的组件，例如：数据摄取组件。