当前位置：首页 > 编程日记 > 正文

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

编程日记 2024-12-01 20:20:00

作者 | 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。

图源：Glisten.ai

尽管Glisten每月要处理各个公司成千上万的产品，但它也只是一家只有两人的初创公司而已。只有他们不需要基础设施团队，这一点才有可能实现。

而且，生产型ML的大众化并不仅仅只影响着初创公司。比如说，下面这位工程师，就决定在被隔离期间部署一个对话模型，并录下自己对着对话模型说话的视频，以此来打发时间。

视频地址：https://youtu.be/ZnjlV2-qD1c

这些只是工程师们正在着手的项目中的几个例子，他们的资源很少，而且通常也缺乏DevOps的专业知识。然而这些项目之所以重要，不仅仅是因为它们本身就很有趣，还因为它们代表了机器学习生态系统中的一个进步。

随着机器学习生产化问题的解决，ML科研人员和软件工程师之间的壁垒被打破了。研究方面的突破能更快地体现在产品的特性上。结果就是，我们所有人都会从中受益。

GitHub链接：

https://github.com/cortexlabs/cortex

原文链接：

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

本文为CSDN翻译文章，转载请注明出处。

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

我们想研发一个机器学习框架，6 个月后失败了

相关文章：

poj1330Nearest Common Ancestors 1470 Closest Common Ancestors（LCA算法）

干货 | 时间序列预测类问题下的建模方案探索实践

Redis安装与源码调试

system pause in C#

C#设置当前程序通过IE代理服务器上网

计算机科学精彩帖子收集

挑战王者荣耀“绝悟” AI，我输了！

java 注解类说明

《ArcGIS Runtime SDK for Android开发笔记》——（13）、图层扩展方式加载Google地图...

调试JDK源码-一步一步看HashMap怎么Hash和扩容

开源一年，阿里轻量级AI推理引擎MNN 1.0.0正式发布

人生在成败中进步

【原】YUI压缩与CSS media queries下的bug

Spring源码分析【4】-Spring扫描basePackages注解

c语言c++语言中静态变量，函数详解

深度解析MegEngine亚线性显存优化技术

2016-04-28

Spring源码分析【8】-MyBatis注解方法不能重载

不知道这 7 大 OpenCV 函数怎么向计算机视觉专家进阶？

MySQL5.5复制新特性

GitLab 8.7发布

Java飞行记录器 JRockit Flight Recorder JFR诊断JVM的历史性能和操作

vi/vim: 使用taglist插件

学会这些Python美图技巧，就等女朋友夸我了

Linux下的softlink和hardlink（转）

ubuntu安装之后的最初几天一路杂记

百万级访问量网站的技术准备工作[转帖]

智能驾驶L2的黄金时代，打磨地图是关键

css中的垂直居中方法

U盘挂载，gedit,vi,文本模式中文乱码等等问题