乐观的人会想，未来机器学习能够完成驾驶汽车、接听电话、预约、回复电子邮件这些人类才能完成的任务。但现实往往很骨感。现代机器学习能有效解决的问题范围仍然非常狭窄，比如在 Netflix 上推荐下一个节目或计算 ETA。
然而，当 OpenAI 发布 GPT-2 后，机器和人类之间的差距就开始缩小了。
通过简单地指示模型的大小，OpenAI 建立了一个通用语言模型，通过后者可以更流畅地处理人类的任务（虽然有时不完美）：
图片来源：OpenAI
GPT-2 的出现并非偶然，它发布不久，Salesforce 就发布了 16 亿参数语言模型 CTRL。NVIDIA 构建了 Megatron，一个 80 亿参数的 transformer 模型。最近，Google 又发布了拥有 26 亿参数的最先进的会话模型 Meena。
即使在计算机视觉领域，要实现更好的性能往往也需要更大的模型。2018 年夏天，就在 GPT-2 首次发布的前几个月，Google 发布了 NASNet，这是一个创纪录的图像分类模型，它拥有 8890 万个参数，比其他任何能够识别图像中物体的主流图像分类模型都要大：
资料来源：Sik-Ho Tsang
趋势很明显。为了实现机器学习驱动未来的美好愿景，这些「超级模型」将越来越大。但现在的问题是：
它们太大了，没有办法在生产中使用。
超级模型面临哪些挑战？
模型不断膨胀，将它们部署到生产中变得越来越棘手。以 GPT-2 为例：
GPT-2 大于 5 GB。在本地将模型嵌入到应用程序中不是移动设备中软件的选择。
GPT-2 需要计算。为了服务于单个预测，GPT-2 可以以 100% 的利用率占用 CPU 几分钟。即使使用 GPU，一个预测仍然需要几秒钟。而与之相比，一个 web 应用程序可以用一个 CPU 服务数百个并发用户。
GPT-2 对内存需求很大。除了相当大的磁盘空间和计算需求之外，GPT-2 还需要大量内存才能保证顺利运行。
换句话说，GPT-2 规模大、资源密集、速度慢。将其投入生产是一个挑战，而扩大规模则更加困难。
这些问题并非 GPT-2 独有，它们对所有超级模型来说都是通用的，而且只会随着模型变大而变得更糟。幸运的是，机器学习生态系统中的一些项目正在消除这一障碍。
我们如何解决超级模型问题
虽然完全解决问题还为时过早，但解决超级模型问题的总体方向有三点：
1. 把模型变小
如果模型变得太大，最直接的方法就是压缩它们。
一种方法是通过知识蒸馏。在一个很高的层次上，这可以说是一个小模型（学生）可以通过学习来模仿大模型（家长）的表现。
换言之，训练 GPT-2 需要输入 40 GB 的文本，这相当于一个大约 27118520 页的文本文件。然而，训练一个精简的 GPT-2 模型，只需要你给它输入 GPT-2 的输出。
著名的 Transformers NLP 库幕后的公司 HuggingFace 就是这样创建了 DistilGPT2。虽然 DistilGPT2 在某些质量基准上的得分比完整的 GPT-2 模型低一些，但它比完整的 GPT-2 模型小 33%，速度快两倍。
速度提高两倍是了不起的大事。对于自动驾驶汽车来说，安全停车和撞车是两码事。对于一个会话代理来说，这是自然对话和与恼人的机器人通话之间的区别。
实际上，你可以将 DistilGPT2 和 GPT-2 的性能和 HuggingFace 与 Transformers editor 的交互编写进行比较：
资料来源：Write With Transformers
2. 将模型部署到云端
然而，即使经过蒸馏，模型仍然相当大。对超过 25 GB（NVIDIA 的 Megatron 是 GPT-2 的 5.6 倍）的模型来说，减小 33% 仍然很庞大。
在这样的规模下，我们用来消费 ML 生成内容的设备——我们的手机、电视，甚至我们的电脑——都不能托管这些模型，它们根本不适合。
一种解决方案是将模型作为微服务部署到云中，我们的设备可以根据需要进行查询。这被称为实时推理，是在生产中部署大型模型的标准方法。
然而，在云中部署有自己的问题，特别是规模问题。
举个例子，让我们看看 AI Dungeon，这是一个流行的文本冒险游戏，建立在 GPT-2 上：
由于 GPT-2 的规模和计算要求，AI Dungeon 只能为来自单一部署模型的两个用户提供服务。随着流量的增加，AI Dungeon 需要自动升级。
扩展 GPT-2 部署是很棘手的。它要求你：
确保每个部署都是相同的。例如，使用 Docker 对模型进行容器化，使用 Kubernetes 对容器进行编排。
自动扩展部署。例如，通过配置云供应商的自动缩放器，根据流量自动上下旋转实例。
优化资源。这意味着在不牺牲性能的情况下找到成本最低的实例类型和资源分配方式。
如果做得不对，你就会收到一笔巨大的云账单——部署 200 个 g4dn.2xlarge 实例每小时花费 150.40 美元，或者你会发现自己的预测服务 API 经常崩溃。
换句话说，要为你的大型模型服务，你目前需要对 devops 有相当多的了解，而且大多数数据科学家并不能完成基础设施工程师的工作。
幸运的是，有些项目正在努力消除这个瓶颈。
像 Cortex 这样的开源项目——AI Dungeon 基础设施背后的项目，作为自动化部署大型模型所需的 devops 工作工具，已经获得了广泛的关注：
来源：Cortex GitHub
3. 加速模型服务硬件
最后一类让服务大模型变得更容易的方法与模型本身没有任何关系。相反，它与改进硬件有关。
大模型在不同的硬件上性能更好。事实上，正如我之前所说的，为什么 GPU 对模型服务很重要？这是因为只有在 GPU 上才能以足够低的延迟来为 GPT-2 服务，比如 autocorrect：
一般人每分钟打 40 个字，一般的英语单词大约有 5 个字符，因此，一个普通人每分钟输入 200 个字符，或者每秒输入 3.33 个字符。再往前走一步，这意味着平均每个人输入每个字符之间时间大约有 300 毫秒。
如果你在 CPU 上运行，每次请求占用 925 毫秒，那么你的 Gmail 智能合成速度就会慢下来。当你处理一个用户的字符时，他们大约会领先 3 个字符——如果输入是快速打字机，甚至领先更多。
然而，在 GPU 的帮助下，你的处理速度远远领先于他们。在每个请求占用 199 毫秒时，你将能够用大约 100 毫秒的空闲时间预测其余的消息，这在他们的浏览器仍需要呈现你的预测时非常有用。
然而，随着模型越来越大，我们需要更多的处理能力。
解决这个问题的方法包括构建全新的硬件。例如，Google 已经发布了 TPU，这是专门为 TensorFlow 接口而设计的 asic。Google 最新的 TPU 最近打破了模型服务基准的可伸缩性和性能记录。美国亚马逊云（AWS）最近也发布了自己的专业推理芯片。
其他工作包括加速和优化现有硬件。例如，NVIDIA 发布了 TensorRT，这是一个用于优化推理服务中 NVIDIA GPU 利用率的 SDK。NVIDIA 已经记录了在 GPU 上使用 TensorRT 的性能，它比仅使用 CPU 的推理提高了 40 倍。
机器学习将变得司空见惯
在很多方面，机器学习仍然像美国西部一样蛮荒。
像 GPT-2 这样的超级模型刚刚开始出现，除了大公司，机器学习正越来越广泛地为工程师们所接受，模型架构的新突破似乎一直就在眼前。
然而，我们已经看到机器学习几乎出现在每个垂直领域，从媒体到金融到零售。不出意外，在不久的将来，几乎没有一款产品会不涉及机器学习。
随着机器学习成为软件的标准部分，在生产中部署大型模型的挑战也将变得司空见惯。
via：
阅读(345) | 评论(0) | 转发(0) |
