本文最初发表在 Towards Data Science，经原作者 Caleb Kaiser 授权，InfoQ 中文站翻译并分享。

在许多软件工程学科中，生产用例是相当标准化的。以 Web 开发为例：要在 Web 应用中实现身份验证，你无需发明数据库，编写自己的哈希函数，或者设计一个新的身份验证策略。你可以使用某个定义好的方法，并利用标准工具就能在 Web 应用中实现身份验证。

然而，在机器学习中，这种标准化并不存在。为了构建从模型训练到部署的管道，团队不得不构建自己的解决方案，主要的问题是从头开始开始构建解决方案。

这样一来，这一领域对于许多工程师来说成了不可企及的禁区，推而广之，对那些很多请不起专业专家的公司来说也是如此。

但这一情况正在改变。生产模式正变得越来越常规。这些方法正在标准化，工具也正在日益成熟。到最后，软件可以由非专业的机器学习工程师开发了。

将模型投入生产意味着什么？

如果你看看自己每天都使用的软件，如 Gmail、Uber、Netflix 等，无论你喜欢哪种社交媒体平台，都能在里面看到机器学习的身影，比如：自动完成电子邮件、语音转文本、对象检测、预计到达时间等等。

虽然这些模型背后的数学是机器学习研究人员的领域，但用来将它们转化为产品的架构应该是任何开发人员都熟悉的：

从软件工程的角度来看，经过训练的模型只不过是另一个 API，将模型投入生产意味着将其部署为微服务。

注意：还有其他形式的模型部署（例如，未连接到国际互联网的设备），但它们不是本文要讨论的重点。

想要构建类似 Gmail 的智能撰写（Smart Compose）这样的功能吗？将语言模型部署为 Web 服务，用文本 ping 端点，并在前段显示预测。想要实现像 Facebook 建议的标签功能吗？还是同样的过程，部署一个图像识别模型，并像使用其他 Web 服务一样使用它。

虽然“把你的模型部署成微服务”，这句话听起来很容易，但是要如何做到这一点，却是一个很有挑战性的问题。

部署用于实时推理的模型需要回答几个问题：

如何编写一个从模型生成预测的 API？
将该 API 部署到生产环境的最佳方式是什么？
如何实现生产 Web 服务所需要的所有基础设施特性：自动伸缩、监控、负载平衡、滚动更新等？

根据模型的具体情况（如模型所有的框架、需要多少计算和内存、可以处理的数据种类等等），答案可能会有很大的差异。

这就是为什么大型科技公司有专门的机器学习基础设施团队，也是为什么大多数创业公司无法在生产中使用机器学习的原因。

但现在，这些问题有了标准答案。

要从模型中生成预测，可以使用框架附带的任何服务库（如 TensorFlow/TF serving、PyTorch/TorchServe）。要将你的模型封装在 API 中并进行部署，你就需要使用模型服务平台。

现在，任何软件工程师都可以采用一个模型（无论该模型是由他们的数据科学团队训练的模型，还是经过他们调优的开源模型，或者只是一个普通的预训练模型），并将其转换为生产 Web 服务，而不必成为机器学习或 Kubernetes 方面的专家。

示例：文本生成不仅仅是 Gmail 的智能撰写

如果你在过去的几年里使用过 Gmail，那么你一定很熟悉它的智能撰写功能。当你在写电子邮件时，Gmail 会抛出一些建议回复：

虽然 Google 有一个复杂的机器学习管道，需要大量投资，但如果你想构建一些模仿 Gmail 的智能撰写的功能，不需要 Google 的资源你也能做到这一点。

举个例子：AI Dungeon。这是一款基于机器学习的文字冒险游戏。

从本质上说，AI Dungeon 是 OpenAI 的 GPT-2（一种最先进的语言模型）的微调版本，以 Web 服务的形式部署。用户将他们的提示提交到模型-微服务中，它就会用一个故事来回应。

就上下文而言，GPT-2 非常庞大。经过训练的模型超过了 5GB，完全可以利用 GPU 来服务于一个预测。在不久之前，要想知道如何将其作为微服务进行规模化部署，是一个重大的基础设施项目。你需要：

将其托管在具有足够空间 / GPU 的实例上，已提供预测服务。
配置自动缩放以处理任意数量的并发用户。
实现各种成本优化，让你的云账单处于可控状态。

在这些任务中，有许多子问题需要解决。比如，你是否应该根据内存使用情况或对垒中的请求数量进行自动缩放？你是否能够平稳地处理故障转移，从而能够轻松地使用 Spot 实例来节省成本？

译注：Spot 实例，是一种未使用的 EC2 实例，以低于按需价格提供。由于 Spot 实例允许用户以极低的折扣请求未使用的 EC2 实例，这可能会显著降低你的 Amazon EC2 成本。Spot 实例的每小时价格称为 Spot 价格。每个可用区中的每种实例类型的 Spot 实例的价格是由 Amazon EC2 设置的，并根据 Spot 实例的长期供求趋势逐步调整价格。只要容量可用，并且请求的每小时最高价超过 Spot 价格，Spot 实例就会运行。如果能灵活控制应用程序的运行时间并且应用程序可以中断，Spot实例就是经济实惠之选。例如，Spot 实例非常适合数据分析、批处理作业、后台处理和可选的任务。

正如 AI Dungeon 背后的工程师 Nick Walton 在他的文章《我们如何扩展 AI Dungeon 来支持超过 100 万用户》（How we scaled AI Dungeon 2 to support over 1,000,000 users) 中称，他所要做的就是编写他的预测 API，并允许他的模型服务平台（Cortex）实现基础设施的自动化。

注：如果你不熟悉迁移学习，那么看一看 AI Dungeon 是如何用很少的数据就能获得最先进的结果的故事也是很有趣的。

设计模型具有挑战性，将其生产化的过程很枯燥

多年前，机器学习产品的瓶颈问题如果不解决，就不会有 AI Dungeon。但现在，它只是众多机器学习原生创业公司之一。

例如，Glisten 将多个模型组合在一起，生成了一个 API，可以用于从图像中提取产品信息：

尽管公司用 Glisten 来处理每月数以千计的产品，但 Glisten 只是一家只有两个人的初创公司。这只是因为他们不需要基础设施团队而已，所以公司只有两个人就够了。

随着机器学习的生产化的问题得到解决，机器学习研究人员和软件工程师之间的障碍也被打破。研究方面的突破更快地体现为产品方面的功能，因此，我们所有人都会受益。

作者介绍：

Caleb Kaiser，Cortex Lab 创始团队成员，曾在 AngelList 工作，最初在 Cadillac 供职。

原文链接：

https://towardsdatascience.com/production-machine-learning-isnt-hard-anymore-932bd91e138f

创作场景

生产式机器学习不再是困难