「机器学习」我们想研发一个机器学习框架，6 个月后失败了( 二 ) |设计|Kaggle|技术|

有一件事很值得去做（而在项目的早期被我们忽略了），那就是思考一下曾经给我们启发的web框架，并记住他们第一次崭露头角的时候。
Rails、Django和Symfony ，作为web应用的新MVC框架浪潮的一部分，它们都是在2004年到2005年间发布的。当时的web开发还不能称为“稳定” ，尤其是考虑到自那以后它们是如何变得成熟的（在很大程度上要感谢那些框架），但是web开发人员所做的工作和现在相比仍然有高度的相似性。
事实上， Rails最早的口号之一是“你不是一片美丽而独特的雪花” ，正是基于这样的一个事实：大多数web开发人员正在构建架构上类似的应用程序，这些应用程序可以在相同的配置上运行。
生产型机器学习系统还未发展到那个阶段。一切仍在变化之中。数据科学家处理的数据类型、使用的模型体系结构、喜欢的语言/框架、应用程序的推断要求，以及几乎所有你能想象到的一切东西，都在不断变化中。
而且，这个领域本身变化也很快。自18个月前Cortex首次发布以来：

PyTorch已经从一个仅仅前景看好的项目发展成为最流行的机器学习框架，在此期间许多专门的机器学习训练库（如微软的DeepSpeed）已经发布出来。
OpenAI发布了有史以来最大的模型，可以运行带有15亿个参数的GPT-2 。此后，谷歌、Salesforce、微软和Nvidia都发布了更大的机型（有些是同一数量级的）。
大量初创企业已经开始使用迁移学习（Transfer Learning）和预训练模型来优化和部署具有少量数据的模型（比如说，并非每个人现在都需要一个100节点的Spark群集）。

所有这些都在不断变化中，所以试图构建一个支持“合适”技术堆栈的端到端框架从一开始就注定了失败。
每个人都会要求他们需要的“一个特性” ，而没有人有相同的要求。我们试图构建一些通用的特性，但很快就发现这是不可行的，至少不是我们想象的那样。

本文插图
专注于模型服务基础设施构建一个端到端的机器学习框架是很困难的，因为大部分的机器学习生态系统仍然是“蛮荒的西部” 。然而，其中的“模型服务”已经具有了稳定性和一致性。
不管他们使用什么堆栈，大多数团队都是通过先将模型封装在API中，然后部署到云端（尽管他们不喜欢这样做）来将其投入生产，。
数据科学家不喜欢它，因为用于构建弹性web服务的工具，如 Docker、Kubernetes、EC2/GCE、负载均衡器等等，都不在他们的触手可及之处。 DevOps工程师对模型推断的独特之处感到恼火。
但是对我们来说，这是一个机会。 “模型作为微服务（model-as-a-microservice）”的设计模式对所有团队来说是一致的，而它提供的工具，因为它是基础设施（而不是机器学习生态系统）的一部分，所以非常稳定。更有利的是，作为软件工程师，我们在构建生产型web服务方面比在构建机器学习管道方面更有经验。
所以，我们想在模型服务上尝试一下。我们应用了相同的设计原则，抽象了声明性YAML配置和最小CLI背后的所有低层次的不同，并自动化了将一个经过训练的模型转换为一个可伸缩的生产型web服务的过程：

本文插图
通过专注于模型服务，我们可以对堆栈的其余部不加理会（只要模型有Python绑定， Cortex就可以为其服务）。因为Cortex可以插入任何堆栈，所以我们对Cortex在底层使用的工具有了话语权，这又使得构建更高级别的特性变得更加容易。
例如，自从发布用于模型服务的Cortex以来，我们增加了对GPU推断、基于请求的自动缩放、滚动更新和预测监视的支持。我们不需要为十几个不同的容器运行时和集群编排器实现这些功能。 Cortex在底层使用Docker和Kubernetes ，用户从来不需要接触它们中的任何一下。