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

流媒体应用程序或 API

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

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

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

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

3. 预处理数据。

4. 运行模型。

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

6. 返回一个结果。

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

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

然而，对于像 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检索问题数据，将其传递给模型，并返回模型输出。

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

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

批量预测

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

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

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

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

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

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

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

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

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

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

在设备上

笔记本电脑和手机中的处理器通常未针对运行 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。一个大模型或许多单独的模型