作者 | 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？
- 如何实现生产型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。
尽管Glisten每月要处理各个公司成千上万的产品，但它也只是一家只有两人的初创公司而已。只有他们不需要基础设施团队，这一点才有可能实现。而且，生产型ML的大众化并不仅仅只影响着初创公司。比如说，下面这位工程师，就决定在被隔离期间部署一个对话模型，并录下自己对着对话模型说话的视频，以此来打发时间。视频地址：https://youtu.be/ZnjlV2-qD1c这些只是工程师们正在着手的项目中的几个例子，他们的资源很少，而且通常也缺乏DevOps的专业知识。然而这些项目之所以重要，不仅仅是因为它们本身就很有趣，还因为它们代表了机器学习生态系统中的一个进步。随着机器学习生产化问题的解决，ML科研人员和软件工程师之间的壁垒被打破了。研究方面的突破能更快地体现在产品的特性上。结果就是，我们所有人都会从中受益。https://github.com/cortexlabs/cortexhttps://towardsdatascience.com/production-machine-learning-isnt-hard-anymore-932bd91e138f更多精彩推荐