【构建ML驱动的应用程序】第 9 章 ：选择部署选项

   🔎大家好，我是Sonhhxg_柒，希望你看完之后，能对你有所帮助，不足请指正！共同学习交流🔎

📝个人主页－Sonhhxg_柒的博客_CSDN博客 📃

🎁欢迎各位→点赞👍 + 收藏⭐️ + 留言📝​

📣系列专栏 - 机器学习【ML】 自然语言处理【NLP】  深度学习【DL】

​

 🖍foreword

✔说明⇢本人讲解主要包括Python、机器学习（ML）、深度学习（DL）、自然语言处理（NLP）等内容。

如果你对这个系列感兴趣的话，可以关注订阅哟👋

文章目录

服务器端部署

流媒体应用程序或 API

批量预测

客户端部署

在设备上

浏览器端

联邦学习：一种混合方法

结论

---

这前面的章节涵盖了从产品创意到 ML 实现的过程，以及迭代此应用程序直到您准备好部署它的方法。

本章介绍了不同的部署选项以及它们之间的权衡。不同的部署方法适用于不同的需求集。在考虑选择哪一个时，您需要考虑多种因素，例如延迟、硬件和网络要求，以及隐私、成本和复杂性问题。

部署模型的目的是让用户与其交互。我们将介绍实现此目标的常用方法，以及在部署模型时决定方法之间的技巧。

我们将从部署模型和启动 Web 服务器以提供预测服务时最简单的入门方法开始。

服务器端部署

服务器端部署包括设置一个 Web 服务器，该服务器可以接受来自客户端的请求，通过推理管道运行它们，并返回结果。该解决方案适合 Web 开发范例，因为它将模型视为应用程序中的另一个端点。用户有他们发送到此端点的请求，并且他们期望结果。

服务器端模型有两种常见的工作负载，流式和批处理。流式工作流程接受请求并立即处理它们。批处理工作流运行频率较低，一次处理大量请求。让我们从查看流式工作流开始。

流媒体应用程序或 API

这流式方法将模型视为用户可以向其发送请求的端点。在这种情况下，用户可以是依赖于模型预测的应用程序或内部服务的最终用户。例如，一个预测网站流量的模型可以被内部服务使用，该服务负责调整服务器数量以匹配预测的用户数量。

在流式应用程序中，请求的代码路径经过一组步骤，这些步骤与我们在“从简单管道开始”中介绍的推理管道相同。提醒一下，这些步骤是：

1. 验证请求。验证传递的参数值，并可选择检查用户是否具有运行此模型的正确权限。

2. 收集额外的数据。查询其他数据源以获取我们可能需要的任何其他所需数据，例如与用户相关的信息。

3. 预处理数据。

4. 运行模型。

5. 对结果进行后处理。验证结果是否在可接受的范围内。添加上下文以使其易于用户理解，例如解释模型的置信度。

6. 返回一个结果。

您可以在图 9-1中看到这个步骤序列。

图 9-1。流式 API 工作流

端点方法可以快速实施，但需要基础设施根据当前用户数量线性扩展，因为每个用户都会导致一个单独的推理调用。如果流量增加超过服务器处理请求的能力，它们将开始延迟甚至失败。因此，使这种管道适应流量模式需要能够轻松启动和关闭新服务器，这将需要一定程度的自动化。

然而，对于像 ML Editor 这样的简单演示，一次只能由少数用户访问，流式传输方法通常是一个不错的选择。为了部署 ML Editor，我们使用了一个轻量级的 Python Web 应用程序，例如Flask，它可以很容易地设置一个 API 来使用几行代码来为模型提供服务。

您可以在本书的GitHub 存储库中找到原型的部署代码 ，但我将在此处提供一个高级概述。Flask 应用程序由两部分组成，一个 API 接收请求并将它们发送到使用 Flask 处理的模型，以及一个用 HTML 构建的简单网站，供用户输入文本并显示结果。定义这样的 API 不需要太多代码。在这里，您可以看到两个函数处理大量工作以服务于 ML Editor 的 v3：

from flask import Flask, render_template, request

@app.route("/v3", methods=["POST", "GET"])
def v3():
    return handle_text_request(request, "v3.html")

def handle_text_request(request, template_name):
    if request.method == "POST":
        question = request.form.get("question")
        suggestions = get_recommendations_from_input(question)
        payload = {"input": question, "suggestions": suggestions}
        return render_template("results.html", ml_result=payload)
    else:
        return render_template(template_name)

v3 函数定义了一个路由，允许它确定在用户访问/v3页面时要显示的 HTML。它使用函数handle_text_request来决定显示什么。当用户首次访问该页面时，请求类型为GET，因此该函数会显示一个 HTML 模板。这个 HTML 页面的屏幕截图如图 9-2所示。如果用户单击“获取推荐”按钮，则请求类型为POST，因此handle_text_request检索问题数据，将其传递给模型，并返回模型输出。

图 9-2。使用模型的简单网页

当存在强延迟限制时，需要流式应用程序。如果模型所需的信息仅在预测时可用，并且立即需要模型的预测，则您将需要一种流式处理方法。例如，在叫车应用程序中预测特定行程价格的模型需要有关用户位置和司机当前可用性的信息才能进行预测，而这些信息仅在请求时可用。这样的模型还需要立即输出预测，因为它必须显示给用户，让他们决定是否使用该服务。

在其他一些情况下，计算预测所需的信息可以提前获得。在这些情况下，一次性处理大量请求比在请求到达时处理更容易。这称为批量预测，我们将在接下来介绍它。

批量预测

这批处理方法将推理管道视为可以同时在多个示例上运行的作业。批处理作业在许多示例上运行模型并存储预测，以便在需要时使用它们。当您可以在需要模型预测之前访问模型所需的功能时，批处理作业是合适的。

例如，假设您想要构建一个模型，为您团队中的每个销售人员提供最有价值的潜在客户联系公司列表。这是一个常见的 ML 问题称为领先得分。要训​​练这样的模型，您可以使用历史电子邮件对话和市场趋势等功能。在销售人员决定联系哪个潜在客户之前，即需要进行预测时，就可以使用这些功能。这意味着您可以在每晚的批处理作业中计算潜在客户列表，并在早上需要时准备好结果显示。

同样，使用 ML 对最重要的消息通知进行优先级排序并在早上阅读的应用程序没有很强的延迟要求。此应用程序的适当工作流程是在早上批量处理所有未读电子邮件，并保存优先列表以供用户需要时使用。

批处理方法需要与流处理方法一样多的推理运行，但它可以更有效地利用资源。因为预测是在预定的时间完成的，并且预测的数量在批处理开始时已知，所以更容易分配和并行化资源。此外，批处理方法在推理时可以更快，因为结果已经预先计算并且只需要检索。这提供了与缓存类似的收益。

图 9-3显示了此工作流程的两个方面。在批处理时，我们计算所有数据点的预测并存储我们产生的结果。在推理时，我们检索预先计算的结果。

图 9-3。批处理工作流程示例

也可以使用混合方法。在尽可能多的情况下进行预计算，在推理时要么检索预计算结果，要么在它们不可用或过时时就地计算它们。这种方法尽可能快地产生结果，因为任何可以提前计算的东西都会。它伴随着必须同时维护批处理管道和流处理管道的成本，这显着增加了系统的复杂性。

我们已经介绍了在服务器上部署应用程序的两种常见方式，流式和批处理。这两种方法都需要托管服务器为客户运行推理，如果产品变得流行，这很快就会变得昂贵。此外，此类服务器代表您的应用程序的中央故障点。如果预测需求突然增加，您的服务器可能无法满足所有请求。

或者，您可以直接在发出请求的客户端的设备上处理请求。让模型在用户的设备上运行可以降低推理成本，并允许您保持恒定的服务水平，而不管您的应用程序是否受欢迎，因为客户端正在提供必要的计算资源。这称为客户端部署。

客户端部署

这在客户端部署模型的目标是在客户端运行所有计算，消除了服务器运行模型的需要。计算机、平板电脑、现代智能手机和一些连接设备（如智能扬声器或门铃）具有足够的计算能力来自行运行模型。

本节仅涵盖部署在设备上进行推理的训练模型，而不是在设备上训练模型。模型仍然以相同的方式进行训练，然后被发送到设备进行推理。该模型可以通过包含在应用程序中进入设备，也可以从网络浏览器加载。有关在应用程序中打包模型的示例工作流，请参见图 9-4 。

图 9-4。在设备上运行推理的模型（我们仍然可以在服务器上训练）

袖珍设备提供的计算能力比强大的服务器更有限，因此这种方法限制了可以使用的模型的复杂性，但是让模型在设备上运行可以提供多种优势。

首先，这减少了构建可以为每个用户运行推理的基础设施的需要。此外，在设备上运行模型减少了需要在设备和服务器之间传输的数据量。这减少了网络延迟，甚至可以允许应用程序在没有访问网络的情况下运行。

最后，如果推理所需的数据包含敏感信息，则在设备上运行模型可以消除将此数据传输到远程服务器的需要。服务器上没有敏感数据可以降低未经授权的第三方访问此数据的风险（请参阅“数据问题”了解为什么这可能是一个严重的风险）。

图 9-5比较了服务器端模型和客户端模型向用户提供预测的工作流程。在顶部，您可以看到服务器端工作流的最长延迟通常是将数据传输到服务器所花费的时间。在底部，您可以看到虽然客户端模型几乎没有延迟，但由于硬件限制，它们处理示例的速度通常比服务器慢。

图 9-5。在服务器上或本地运行

就像服务器端部署一样，有多种方法可以在客户端部署应用程序。在接下来的部分中，我们将介绍两种方法，本地部署模型和通过浏览器运行它们。这些方法适用于智能手机和平板电脑，它们可以访问应用程序商店和 Web 浏览器，但不适用于其他连接的设备，例如微控制器，我们将不在此处介绍。

在设备上

笔记本电脑和手机中的处理器通常未针对运行 ML 模型进行优化，因此执行推理管道的速度会较慢。为了使客户端模型能够快速运行且不会消耗太多电量，它应该尽可能小。

可以通过使用更简单的模型、减少模型的参数数量或计算精度来减小模型大小。例如，在神经网络中，权重经常被修剪（移除那些值接近于零的权重）和量化（降低权重的精度）。您可能还想减少模型使用的特征数量以进一步提高效率。近年来，Tensorflow Lite等库已开始提供有用的工具来减小模型的大小并帮助它们更轻松地部署在移动设备上。

由于这些要求，大多数模型在移植到设备上时都会遭受轻微的性能损失。不能容忍模型性能下降的产品，例如依赖于过于复杂而无法在智能手机等设备上运行的尖端模型的产品，应该部署在服务器上。一般来说，如果在设备上运行推理所需的时间大于将数据传输到服务器进行处理所需的时间，则应考虑在云端运行模型。

对于其他应用程序，例如智能手机上的预测键盘，可以提供建议以帮助更快地打字，拥有不需要访问互联网的本地模型的价值超过了准确性损失。同样，一款旨在帮助徒步旅行者通过拍摄植物照片来识别植物的智能手机应用程序应该可以离线运行，以便在徒步旅行时使用。这样的应用程序需要在设备上部署模型，即使这意味着牺牲预测准确性。

翻译应用程序是另一个受益于本地功能的机器学习产品示例。这样的应用程序很可能在用户可能无法访问网络的国外使用。拥有一个可以在本地运行的翻译模型成为一项要求，即使它不如只能在服务器上运行的更复杂的模型那么精确。

除了网络问题，在云中运行模型还增加了隐私风险。将用户数据发送到云端并暂时存储它会增加攻击者访问它的几率。考虑一个像在照片上叠加滤镜一样良性的应用程序。许多用户可能不愿意将他们的照片传输到服务器进行处理并无限期存储。在日益注重隐私的世界中，能够向用户保证他们的照片永远不会离开设备是一个重要的差异化因素。正如我们在“数据问题”中看到的那样，避免将敏感数据置于风险之中的最佳方法是确保它永远不会离开设备或存储在您的服务器上。

另一方面，量化剪枝和简化模型是一个耗时的过程。只有在延迟、基础设施和隐私方面的好处足以投入工程工作时，设备上的部署才值得。对于 ML Editor，我们将限制自己使用基于 Web 的流式 API。

最后，专门优化模型以使其在特定类型的设备上运行可能非常耗时，因为优化过程可能因设备而异。存在更多在本地运行模型的选项，包括利用设备之间的共性来减少所需工程工作的选项。该领域中一个令人兴奋的领域是浏览器中的机器学习。

浏览器端

大多数智能设备都可以访问浏览器。这些浏览器通常经过优化以支持快速图形计算。这导致人们对使用浏览器让客户端执行 ML 任务的库越来越感兴趣。

这些框架中最流行的是Tensorflow.js，它可以在浏览器中使用 JavaScript 训练和运行推理，用于大多数可微分模型，甚至是使用不同语言（如 Python）训练的模型。

这允许用户通过浏览器与模型交互，而无需安装任何额外的应用程序。此外，由于模型使用 JavaScript 在浏览器中运行，因此计算是在用户的设备上完成的。您的基础架构只需要为包含模型权重的网页提供服务。最后，Tensorflow.js 支持 WebGL，这允许它利用客户端设备上可用的 GPU 来加快计算速度。

使用 JavaScript 框架可以更轻松地在客户端部署模型，而无需像以前的方法那样进行大量特定于设备的工作。这种方法确实带来了增加带宽成本的缺点，因为客户每次打开页面时都需要下载模型，而不是在安装应用程序时下载一次。

只要您使用的模型是几兆字节或更小并且可以快速下载，使用 JavaScript 在客户端上运行它们可能是降低服务器成本的有用方法。如果服务器成本曾经成为 ML Editor 的一个问题，那么使用 Tensorflow.js 等框架部署模型将是我推荐探索的首要方法之一。

到目前为止，我们考虑的客户端纯粹是部署已经训练过的模型，但我们也可以决定在客户端上训练模型。在下一部分中，我们将探讨这何时有用。

联邦学习：一种混合方法

我们主要涵盖了部署我们已经训练过的模型的不同方法（最好遵循前面章节中的指南），而我们现在正在选择如何部署。我们已经研究了在所有用户面前获得独特模型的不同解决方案，但是如果我们希望每个用户都拥有不同的模型怎么办？

图 9-6显示了顶部的系统与底部的系统之间的区别，顶部的系统为所有用户提供了一个通用的训练模型，而底部的每个用户都有一个稍微不同的模型版本。

图 9-6。一个大模型或许多单独的模型

对于内容推荐、提供写作建议或医疗保健等许多应用程序，模型最重要的信息来源是它拥有的有关用户的数据。我们可以通过为模型生成用户特定的特征来利用这一事实，或者我们可以决定每个用户都应该有自己的模型。这些模型都可以共享相同的架构，但每个用户的模型将有不同的参数值来反映他们的个人数据。

这个想法是联邦学习的核心，这是深度学习的一个领域，最近随着OpenMined等项目受到越来越多的关注。在联邦学习中，每个客户端都有自己的模型。每个模型都从其用户的数据中学习，并向服务器发送汇总的（并且可能是匿名的）更新。服务器利用所有更新来改进其模型并将此新模型提炼回各个客户端。

每个用户都会收到一个根据他们的需求进行个性化设置的模型，同时仍然受益于其他用户的汇总信息。联邦学习改善了用户的隐私，因为他们的数据永远不会传输到服务器，服务器只接收聚合的模型更新。这与通过收集有关每个用户的数据并将所有数据存储在服务器上的传统方式训练模型形成对比。

联邦学习是 ML 的一个令人兴奋的方向，但它确实增加了一层额外的复杂性。确保每个单独的模型都表现良好并且传输回服务器的数据经过适当的匿名处理比训练单个模型更复杂。

联邦学习已经被有资源部署它的团队用于实际应用。例如，正如 A. Hard 等人在这篇文章“移动键盘预测的联合学习”中所述，Google 的 GBoard 使用联合学习为智能手机用户提供下一个词的预测。由于用户之间的写作风格各不相同，因此构建一个对所有用户都表现良好的独特模型被证明具有挑战性。用户级别的训练模型允许 GBoard 了解用户特定的模式并提供更好的预测。

我们介绍了在服务器、设备甚至两者上部署模型的多种方法。您应该根据应用程序的要求考虑每种方法及其权衡。与本书的其他章节一样，我鼓励您从一种简单的方法开始，只有在您确认有必要时才转向更复杂的方法。

结论

有多种方法可以为 ML 驱动的应用程序提供服务。您可以设置流式 API 以允许模型在示例到达时对其进行处理。您可以使用批处理工作流，该工作流将定期一次处理多个数据点。或者，您可以选择在客户端部署您的模型，方法是将它们打包在应用程序中或通过 Web 浏览器提供它们。这样做会降低您的推理成本和基础设施需求，但会使您的部署过程更加复杂。

正确的方法取决于您的应用程序的需求，例如延迟要求、硬件、网络和隐私问题以及推理成本。对于像 ML 编辑器这样的简单原型，从一个端点或一个简单的批处理工作流开始，然后从那里进行迭代。

然而，部署模型不仅仅是将其暴露给用户。在第 10 章中，我们将介绍围绕模型构建安全措施以减少错误的方法、使部署过程更有效的工程工具，以及验证模型是否按应有的方式执行的方法。