酷应用

生产型机器学习已经没那么困难了？

百家作者：AI100 2020-05-07 12:38:30

作者 | Caleb Kaiser

译者 | 香槟超新星

出品 | CSDN（ID:CSDNnews）

封面图源自视觉中国

在软件工程的诸多领域内，生产用例是相当标准化的。以Web开发为例，要在Web应用中实现身份认证，你不会去创造一个数据库，自己写出散列功能，或者去设计一个新的认证方法。你会从几个明确定义的方法之中选一个，并利用标准的工具手段。

然而，对于机器学习来说，这种标准化还不存在。想要建立一个从模型训练到部署的一体化pipeline，团队不得不自己构建解决方案，基本上都是从零开始。

因此，该领域对于许多工程师来说都是触不可及的，而进一步，对于那些没有能力请专家的公司来说，也是如此。

但是，这种局面正在发生变化。模型的生产化正在变得越来越常规化。方法正在逐步标准化，工具的选择正在逐步成熟，到最后，非专业的ML工程师的也能搭建出软件了。

“将模型投入生产”是什么意思？

只要看一看你每天使用的那些软件，Gmail、Uber、Netflix，或者任何哪个你喜欢的社交媒体平台，你就会看到许多由机器学习驱动的功能：自动完成电子邮件，语音转文字，对象检测，ETA预测等。

虽然这些模型背后的数学是机器学习领域的科研人员要操心的事情，但能将其转化为产品的架构却应该为所有开发者所熟知：

从软件工程的角度来看，一个训练好的模型也只是一个API罢了，将模型投入生产意味着将其部署为一个微服务（microservice）。

注意：其他形式的模型部署（例如，对于没有连接到互联网的设备）也是存在的，但那不是本文的重点。

你想搭建出类似Gmail的Smart Compose这样的东西吗？把一个语言模型部署为web服务，用文本ping终端，然后在你的前端显示预测结果。你想实现一个像Facebook的推荐标签（Suggested Tagging）那样的东西吗？还是同样的流程：部署一个图像识别模型，然后就像使用其他web服务一样了。

但是，虽然用手比划着对别人说“把你的模型部署成微服务就好了”是很容易的，但如何做到却是个很有挑战性的问题。

不久前，想要部署一个实时推理模型，还需要先回答几个问题：

你要如何编写一个能从你的模型中生成预测结果的API？
将该API部署到生产中的最佳方式是什么？
如何实现生产型Web服务所需要的所有基础设施功能？比如自动缩放、监控、负载均衡、滚动更新等等。

根据你模型的特性的不同（它是用什么框架训练出来的，需要多少算力和内存，能处理什么类型的数据等等），答案可能会有很大的差异。

这就是为什么大型科技公司有专门的ML基础设施团队，也是大多数初创公司在生产中用不起ML的原因。

而现在，上面的问题都有了标准答案。

要想从你的模型中生成预测，你就用你的框架所附带的服务库（TensorFlow/TF Serving，PyTorch/TorchServe）。要想把你的模型封装成API并部署，你需要使用一个模型服务平台（请容我无耻的插播一句：我参与Cortex的维护，它是我们的开源模型服务平台，地址：https://github.com/cortexlabs/cortex）。

现在，任何一个软件工程师拿到一个模型以后，无论这个模型是由他们的数据科学团队训练好的，还是他们微调以后的开源模型，又或者只是一个普通的预训练模型，都能够把它变成一个web服务投入生产了，而不需要非得成为机器学习或Kubernetes专家。

举例：文本生成并不是只有Gmail的Smart Compose能做到

如果你在过去几年中用过Gmail，你一定对Smart Compose很熟悉。在你输入邮件内容时，它负责让Gmail给出一些建议的回复。

虽然Google肯定是有一个复杂的需要大量投资的ML pipeline的，但如果你想搭建一些模仿Smart Compose功能的东西，你不需要Google那样的资源就可以做到。

这方面的一个例子：AI Dungeon，一款由ML驱动的choose-your-own-adventure游戏。（地址：https://aidungeon.io/）

从底层来看，AI Dungeon 是 OpenAI 的 GPT-2（一种最先进的语言模型）微调后的版本，被部署为 Web 服务的形式。用户将他们的词汇提交给模型微服务，然后它就会回复一个故事。

介绍一下，GPT-2是非常大的。一个训练好的模型超过5GB，进行一项预测能够完全占用GPU。在不久前，探索如何将其大规模地部署为微服务，是一个重大的基础设施项目。你需要：

将其托管到有足够空间/GPU来为预测服务的实例上。
配置autoscaling来处理任意数量的并发用户。
实施各种成本优化方案，以保持你的云计算总花销在可控范围内。

而这每个任务中都包含许多需要解决的子问题。你autoscale的时候，是应该依据内存利用率，还是依据队列中的请求数量？你是否能顺利地处理故障切换（failover），来让自己可以放心地通过现货实例来节省成本？

在谷歌，这些事情都是有ML基础架构团队负责的，而AI Dungeon则是仅由一位工程师独立打造出来的。

正如Nick Walton（AI Dungeon背后的工程师）在其关于将AI Dungeon扩展到超过100万用户的文章中所解释的那样，他所要做的就只是编写他的预测API，并让他的模型服务平台（Cortex）实现基础架构的自动化。（文章地址：https://medium.com/@aidungeon/how-we-scaled-ai-dungeon-2-to-support-over-1-000-000-users-d207d5623de9）

注：即使对那些不熟悉转移学习的人来说，AI Dungeon用很少的数据获得最先进的结果的故事也非常有趣。

设计模型应该是很有挑战性的。

而将它们投入生产则应该是很枯燥的。

几年前，生产型ML的瓶颈会限制AI Dungeon的产生。而现在，AI Dungeon只是众多ML原生创业公司中的一个。

比如说Glisten，它就将多个模型结合在一起，从而产出一个可以用来从图像中提取产品信息的API。