照片由 Jakob Owens 在 Unsplash 拍摄

作为一名机器学习工程师，我经常看到社交媒体上关于部署机器学习模型的重要性的讨论。我完全同意——模型部署是MLOps（模型运行操作）的一个关键部分。随着机器学习的应用增加，对可扩展和高效部署方法的需求也在增长，但具体实施细节往往仍不清楚。

那么，是不是意味着无论在什么情况下，模型部署都是一样的？实际上恰恰相反：我已经做了大约十年的机器学习模型部署了，每个项目的部署情况可能都不同。有许多方法可以部署机器学习模型，掌握了一种方法并不一定意味着你能精通其他方法。

剩下的问题就是：如何部署一个ML模型，还有我们应该怎样选择合适的方法？

人工智能模型可以以多种方式部署，但通常主要分为两大类。

• 云端部署
• 边缘部署

这听起来可能很简单，但有一个陷阱。对于这两类，实际上存在很多子类别。以下是我们将在本文中探讨的一些部署方案的非详尽图示。

本文探讨的部署子类别示意图。作者提供。

在讨论如何选择合适的方法之前，我们先来看看每一类：它是什么，优点是什么，缺点是什么，以及典型的技术栈。我还会分享一些个人的部署实例。让我们深入聊聊吧！

从我所见，当涉及到机器学习模型部署时，最受欢迎的选择似乎是云部署。这通常是人们需要掌握的内容来部署模型。但云部署通常指的是根据具体情境，可能是以下几种中的某一种。

• API 部署,
• 无服务器计算,
• 批量处理,

甚至在那些子分类中，还可以进一步细分，但本文不过多涉及。我们来看看它们的意思、各自的利弊，以及通常使用的技术栈。

API 代表应用程序编程接口。在云上部署模型的一种非常流行的方式就是通过API。一些最受欢迎的机器学习模型是通过API部署的，比如，可以通过 Google Maps 和 OpenAI 的 ChatGPT 的 API 来查询信息。

如果你还不熟悉API，要知道它通常是通过简单的查询来调用的。在你的终端里输入以下命令来获取前20个宝可梦的名字：例如：
在你的终端里输入如下命令：

// 假设这里填具体的命令

在你的终端里输入如下命令来获取前20个宝可梦的名字：例如：

// 命令示例

curl -X GET https://pokeapi.co/api/v2/pokemon # 获取 Pokémon API 数据

在底层实现中，调用 API 可能更复杂。API 部署通常包括一个标准的技术栈，通常包括负载均衡器、自动伸缩器以及与数据库的交互操作：

这是在云基础设施中部署 API 的一个典型例子。图片来源作者。

注意：由于API的具体需求和基础设施不同，此处的示例为了便于理解进行了简化。

API部署之所以受欢迎，有以下几个原因

• 很容易实现并集成到各种技术堆栈中
• 在云中利用水平扩展可以有效地扩展系统；此外，云提供商提供的托管服务可能减少了手动干预的需求
• 它支持集中管理模型版本和日志记录，从而实现高效的跟踪和复现

虽然API非常受欢迎，但也有一些不足之处。

• 可能因网络延迟或地理位置较远而产生延迟问题，当然，还需要一个良好的网络连接
• 在高流量情况下，成本可能会迅速上升（假设自动扩展功能已启用）
• 维护成本可能会变得很高，无论是管理服务费用还是基础设施团队的费用

总之，许多初创公司和技术公司广泛使用API部署，由于其灵活性，并且能够快速上市。但是，对于高流量情况，成本可能会迅速增加，维护成本也可能很高。

关于技术栈方面：有很多方法可以开发API，但在机器学习领域最常见的是的框架FastAPI和Flask。可以很方便地部署到主要的云服务商如AWS、GCP、Azure等，最好是使用Docker镜像。编排可以通过托管服务或Kubernetes来实现，这取决于团队的选择、规模以及技能水平。

作为云API部署的一个例子，我曾经为客户面向的网页应用部署了一个基于机器学习的解决方案，用于自动定价电动汽车充电站。想了解更多详情，可以在这里查看详细信息。

即使这篇帖子不包含代码，它也能给你一个用API部署应用的好想法。

API部署因其简单性而非常流行，可以轻松集成到任何项目中。但有些项目可能需要更大的灵活性和更低的维护成本：在这种情况下，无服务器架构可能就是解决方案。

另一种流行但可能不那么常用的选择是无服务器部署。无服务器计算意味着你运行你的模型（或任何代码）无需拥有或配置任何服务器资源。

无服务器部署具有几大优点，而且设置起来非常容易。

• 无需管理或维护服务器
• 不需要担心流量增加时的扩展问题
• 只需为实际使用的服务付费：无流量则几乎无成本，因此没有任何额外费用

不过，它也有一些限制存在。

• 对于大量查询，通常与管理 API 相比成本效益较低
• 冷启动延迟可能成为问题，因为需要启动服务器，从而导致延迟
• 内存使用通常设计有限：你不能总是运行大型模型
• 执行时间也有上限：通常不能运行超过几分钟的任务（例如 AWS Lambda 的最长执行时间是 15 分钟）

简而言之，我认为说无服务器部署在启动一个新的东西、不预计会有太多流量而且不想在基础设施管理上花太多心思时，是一个不错的选择。

无服务器计算由所有主要的云提供商以不同的名称提供，例如 AWS Lambda、Azure Functions 和 Google Cloud Functions 这些最受欢迎的服务。

我自己从来没有部署过无服务器解决方案，我主要专注于深度学习，通常会受到上述无服务器限制的困扰，但是有很多关于如何正确部署无服务器解决方案的教程，例如AWS的这篇文档。

虽然无服务器部署提供了一个灵活且按需的解决方案，但某些应用程序可能需要更为计划化的处理方式，例如批处理任务。

另一种在云上部署的方式是通过计划的批处理任务。虽然无服务器和API主要用于实时预测，在某些情况下，批处理预测更为合适。

无论是数据库的更新，仪表盘的刷新，还是缓存预测……只要不需要实时预测的场景，批处理通常是最佳选择。

• 处理大批量数据比实时处理更节省资源和减少开销，更好地体现“resource-efficient”的含义。
• 可以将处理安排在非高峰时段，从而减少总体费用，进而降低成本。

它带来了相关的弊端，当然。

• 批处理会导致资源使用量骤增，可能导致系统过载，如果不妥善规划。
• 批处理中的错误处理至关重要，因为您需要一次性妥善处理整个批次。

对于任何不需要实时结果的任务，可以考虑批处理：通常更加节省成本。但是，对于任何需要实时反馈的应用程序，这种方法就不适用了。

在许多公司中被广泛使用，主要用于ETL（提取、转换、加载）管道中，这些管道可能包含或不包含ML。其中一些最受欢迎的工具是：

• Apache Airflow 用于工作流管理与任务调度
• Apache Spark 用于快速处理大规模数据

作为批量处理的一个实例，我曾参与过YouTube视频收入预测项目。基于视频初期的收入数据这些数据，我们会根据这些数据预测未来5年的收入，采用多目标回归和曲线拟合的方法。

表示原始数据、多目标回归和拟合曲线的图表。作者提供。

在这个项目中，我们每个月都需要重新预测所有数据，以确保我们的初始预测与最新的预测一致。为此，我们使用了Airflow进行管理，这样每个月它都会自动触发一次新预测，基于最新的数据，并将这些预测结果存储到我们的数据库里。想了解更多关于这个项目的信息，可以看看这篇文章。

探索了各种云部署策略和工具之后，很明显这种方法提供了相当大的灵活性和可扩展性。然而，并不是所有的机器学习应用都适合采用云部署，特别是在需要实时处理、涉及隐私问题或受到财务资源限制的情况下。

云部署的优缺点列表。作者提供。

边缘部署开始受到关注，成为了一个可行选项。我们现在来深入探讨边缘部署，以了解它可能成为最佳选择的情况。

边缘计算部署

从我个人的经验来看，边缘部署很少被视为主要的部署方式。几年前，甚至我认为边缘部署并不是一个吸引人的部署选项。现在有了更多的视角和经验后，我认为任何时候它都应该是优先考虑的部署选项。

就像云部署一样，边缘计算部署也涉及到各种情况：

• 本地应用，网页应用，边缘计算和特定装置

尽管它们都具有一些相似的特性，例如资源有限和水平扩展的局限，每个部署选择都有自己的特点。让我们来瞧一瞧。

现在越来越多的智能手机应用程序集成了人工智能，这一趋势在未来可能会继续增长。一些大型科技公司，如OpenAI或Google，选择了通过API方式部署其大型语言模型（LLM），而苹果正在通过类似OpenELM这样的较小LLM来研究在iOS应用中的部署方案。确实，这么做有以下几个好处：

• 基础设施成本几乎为零，无需维护云，所有操作都在设备上运行
• 更好的隐私，无需将任何数据发送到API，所有操作都可以在本地完成

• 您的模型可以直接集成到应用程序中，无需维护多个代码版本

  此外，苹果已经建立了一个出色的生态系统，用于在iOS中部署模型：您可以使用Core ML在M1、M2等苹果芯片上高效运行机器学习模型，并利用神经引擎进行非常快速的推理操作。据我所知，Android在这方面稍微落后一些，但也拥有一个很棒的生态系统。

虽然这样做在许多情况下确实非常有益，但仍有其限制：

• 手机资源限制了模型的大小和性能，并且这些资源还与其他应用程序共享。
• 重型模型可能会很快耗尽电池，这可能会给用户造成一种误导，觉得设备的性能不如预期。
• 设备碎片化，加上iOS和Android应用的差异，使得覆盖整个市场变得困难。
• 与云端更新相比，分散的模型更新可能会更具挑战性。

虽然原生应用部署存在一些缺点，但它是运行在应用中的机器学习解决方案的一个强有力选择。但在开发阶段可能会感觉更复杂，但一旦部署，与云部署相比，它会更加经济实惠。

说到技术栈时，主要有两种方式：iOS和Android。它们各自都有自己的技术栈，但它们共享一些相同特性：

• 应用开发：iOS 开发使用 Swift，Android 开发使用 Kotlin
• 模型格式：iOS 使用 Core ML（核心机器学习模型格式），Android 使用 TensorFlow Lite（轻量级机器学习模型格式）

• 硬件加速器：iOS 使用 Apple Neural Engine 作为硬件加速器，Android 使用 Neural Network API 作为硬件加速器

  这只是对技术栈的一个简化。本非详尽的概述仅旨在涵盖要点部分，如果您感兴趣，可以从此开始深入了解

作为一个这样的部署的个人例子，我曾经为Android开发了一款阅读书籍的应用程序，在该应用中，他们希望用户通过摇动手机来翻页。例如，向左摇动手机翻到前一页，向右摇动手机翻到下一页，还可以用其他特定的动作执行特定的命令。为此，我使用手机加速度计的数据训练了一个模型，用于识别运动，模型较小。然后，将此模型作为TensorFlow Lite模型直接部署到应用中。

原生应用有很多优势，但只能运行在一种设备上，比如在笔记本电脑上就不能用。而一个 web 应用程序就能解决这些问题。

Web应用程序部署意味着在客户端运行模型。基本上，它意味着在该浏览器使用的设备上运行模型的推理，不论是平板、手机还是笔记本（等等）。这种部署方式确实很方便。

• 您的部署可以在任何能运行网络浏览器的设备上运行
• 推理成本几乎为零：没有服务器，没有维护的基础设施……只需要客户的设备

• 只需一个代码库就可支持所有设备：无需同时兼顾 iOS 和 Android 应用的维护

  注意：在服务器端运行模型等同于上述云部署选项中的一个。

虽然网页部署带来了不少好处，但也有一些明显的局限。

• 合理利用资源，尤其是利用TensorFlow.js进行GPU推理可能颇具挑战性。
• 您的网页应用需要兼容各种设备和浏览器，比如是否有GPU、是否使用Safari或Chrome、是否有Apple M1芯片等，这可能会带来高昂的维护成本。
• 您可能还需要为较慢或较旧的设备准备备用方案，例如当设备因为速度太慢而无法运行您的模型时。

与原生应用不同，模型没有官方大小限制。较小的模型下载更快，从而使整体体验更流畅，因此优先考虑会更好。而且，非常大的模型可能根本无法运行。

总的来说，尽管网页部署非常强大，但也存在重大限制，需要谨慎使用。此外，它还可能是一种我未提及的部署方式：微信小程序。

技术栈通常与Web开发中的技术栈相同：HTML、CSS、JavaScript（以及你想要使用的任何框架），当然还包括TensorFlow Lite用于模型部署。如果你对在浏览器中部署机器学习感兴趣，可以参考这篇博客，我在该博客中从头开始在浏览器中运行一个实时面部识别模型。

一个从Python训练流程到JavaScript演示的BlazeFace模型训练指南

这篇文章从使用PyTorch训练模型讲到最终上线的网络应用，可能对这种特定部署方式有一定的参考价值。

在某些情况下，原生和网页应用并不是可行的选择：我们可能没有网络连接，或者其他条件限制。这时候边缘服务器和特定设备就发挥作用了。

除了本地和网页应用之外，边缘部署还包含其他形式。

• 边缘服务器部署：在某些情况下，本地服务器会运行模型，例如在一些工厂生产线、摄像头等环境中。主要因为隐私要求，这种解决方案有时是唯一的办法。
• 特定设备部署：如下，无论是传感器、微控制器、智能手表、耳塞、自动驾驶车辆等设备，都可能运行模型。

在边缘服务器上的部署可以非常接近基于API的云部署，技术栈也可能非常接近。

注意：也可以在边缘计算服务器上运行批量处理任务，或者使用单一的脚本来完成所有处理。此外，也可以使用单一的脚本来完成所有任务。

但特定设备上的部署可能涉及使用FPGA或低级编程语言。这是一整套完全不同的技能，可能会根据设备的不同而有所不同。有时也被称为TinyML，这是一项非常有趣且正在迅速发展的领域。

在这两种情况中，它们面临着与其他边缘部署方法相同的挑战：

• 资源有限，横向扩展通常不可行
• 电池可能也是一个限制因素，同样，模型大小和内存占用也可能有限制

即便有这些限制和挑战，在某些情境下，仍是唯一的可行方案，或最经济实惠的选择。

我曾经为一家公司部署过边缘服务器，该公司希望自动验证快餐店收银台上的订单是否准确。一个安装在上方的摄像头会观察收银台，通过计算机视觉和物体识别技术来比对实际物品与订单，如果发现不符，会立即发出警报。出于某种原因，该公司希望在快餐店内部署边缘服务器来执行这项任务。

以下是如下主要部署类型的概述及其各自的优缺点：

云部署的利弊列表。图片由作者提供。

考虑到这一点，怎么实际选择合适的部署方式呢？ 并没有一个明确的答案，但在下一节中，我们将尝试给出一些规则，让大家更容易选择。

在得出结论前，我们来做一个决策树来帮你找到适合你的解决方案。

选择合适的部署方式需要理解特定的需求和限制，通常通过与利益相关者的讨论。记住每个案例都是独特的，有时可能是个特例。但下面的图中，我试着总结了最常见的几种情况，希望能帮到你。

部署决策图。注意，每个用例都是具体的。

这些图虽然很简，但仍可以简化成几个问题来引导你，帮助你找到正确的方向：

• 需要实时吗？如果不是的话，先考虑批处理；如果是的话，考虑边缘部署
• 解决方案是在手机上运行还是在网页上运行？尽可能地探索这些部署方式
• 处理复杂且繁重吗？如果是的话，考虑云部署

这虽然有点简单化，但在很多情况下还是很有帮助的。另外要留意的是，不过，为了简洁起见，省略了一些问题，不过，在某些情况下，这些问题其实非常重要：您有隐私方面的限制吗？您有连接方面的限制吗？您的团队有哪些技能呢？

其他问题可能会根据应用场景而出现；随着您对生态系统经验和理解的积累，这些问题会自然而然地浮现。但愿这能帮助您更轻松地部署机器学习模型。

虽然云部署常常是机器学习模型的默认选择，边缘部署可以提供显著的优势：成本效益高和更好的隐私控制。尽管存在处理能力、内存和能源等方面的限制，我认为边缘部署对于很多情况来说是个不错的选择。最终，最适合的部署策略应该符合您的业务目标、资源限制和具体需求。

如果你看到这里，我很想听听你对项目部署方法的看法。