本文转载自公众号《读芯》（ID：AI_Discovery）2019年初，笔者几人尝试构建一个端到端的-到端机器学习框架。我们相信构建ML管道是一种令人沮丧、脱节的体验，我们都可以构建更好的东西。但事情并没有想象中那么顺利。我们使用Kaggle数据集以及公开来源和共享的存储库抽象了ML管道的不同阶段（数据摄取、训练、部署等）。一个月后，它登上了HN的首页，通过机器学习改善用户体验成为许多人关注的问题。半年后，它在GitHub上有数百个“star”，但几乎没有人在使用它。痛定思痛后，我们删除了90%的代码库。毕竟，我们构建了一个更好的项目：Cortex（模型服务基础设施）。但对于任何对机器学习和/或ML工具感兴趣的人来说，这里有一个警示故事：“生产机器学习确实需要更好的用户体验，但ML生态系统是复杂和流动的，这使得构建一个涵盖大范围的工具变得非常困难用例的数量。”为什么需要一个端到端的ML框架大多数人（Cortex贡献者）都有devops和web开发的背景，他们习惯于将应用程序的不同层抽象到一个单一的界面框架中。每个刚开始学习机器学习的人都会感叹工具的脱节。你想构建推荐引擎和聊天机器人，并在这个过程中发现自己在不同的环境之间来回跳转——Jupyternotebooks、终端、AWS控制台等。编写胶水代码和TensorFlow样板的整个文件夹都可以称为“管道”，这是必要的。如果只使用配置文件和命令而不是所有的修改和粘贴：$deployrecommendation_engine看起来不错。然后我们构建一个工具，使用Python转换数据，使用YAML构建管道，使用CLI控制一切：当你给它一个Kaggle数据集时，使用narrowstackofsupport，加上api上设置的限制，这真是一个很棒的工具。但是问题来了，如果你尝试在现实世界中使用它，那么它可能无法与堆栈一起使用。虽然一些问题归结为设计问题，但很大一部分问题实际上是构建端到端工具所固有的——只有在构建之后才会被发现。端到端ML框架的问题简而言之，机器学习生态系统产品对于端到端框架而言还不成熟。ML工程师想要更好的UX工具，这当然是可以理解的。但是试图构建一个涵盖多个用例的端到端框架，你做错了，尤其是只有少数贡献者。Web框架可能会启发我们，想想它们是什么时候开始出现的。Rails、Django和Symfony都在2004年到2005年间作为新的WebMVC框架的一部分发布。虽然当时Web开发可能还不够“稳定”，尤其是考虑到它的成熟程度（在很大程度上要归功于那些框架），但Web开发人员所做的工作仍然存在高度相似性。事实上，最早的Rails格言之一是“你不是美丽而独特的雪花”，它指的是大多数Web开发人员构建的应用程序在架构上相似，可以在相同的配置上运行。机器学习产品还没有到那个阶段，一切都还在变化中。数据科学家在他们处理的数据类型、他们使用的模型架构、他们喜欢的语言/框架、他们的应用程序的推理需求以及几乎所有其他可以想象的方面都有所不同。更重要的是，该领域本身正在迅速变化。我们可以看到，自Cortex首次发布18个月以来：PyTorch从一个有前途的项目变成了一个更受欢迎的ML框架，同时发布了许多专门的训练库（例如微软的DeepSpeed）。许多初创公司已经开始使用迁移学习和预训练模型来微调和部署具有少量数据的模型（例如，如今并不是每个人都需要100节点的Spark集群）。OpenAI发布了有史以来最大的模型GPT-2，拥有15亿个参数。从那时起，谷歌、Salesforce、微软和英伟达都发布了更大的型号。变化永远不会停止，这意味着试图构建一个支持“正确”堆栈的端到端框架从一开始就注定要失败。每个人都要求他们需要的“一项功能”，但没有人有相同的要求。我们尝试了一段时间，但很快意识到“djangoforML”不是一个选项，至少不是我们认为的那样。专注于端到端的基础架构服务模型很困难，因为大部分ML生态系统仍处于野外状态。但是，有一个领域是稳定且一致的：模型服务。无论使用何种堆栈，大多数团队都是通过将模型包装在API中并部署到云端来将模型投入生产。但数据科学家不喜欢它，因为用于构建可扩展Web服务的工具——docker、Kubernetes、EC2/GCE、负载均衡器等——不在他们的控制范围内。这是一个很好的机会。该模型，即微服务的设计模式，在整个团队中是一致的，作为基础设施一部分的工具也非常稳定。此外，作为一名软件工程师，在构建生产Web服务方面比ML管道更有经验。所以，我们认为应该给模型这个机会。我们应用相同的设计原则，抽象出声明式YAML配置和最小CLI背后的所有低级争论，并自动化将训练模型转变为可扩展生产Web服务的过程。通过专注于模型服务，我们可以忽略堆栈的其余部分（只要模型具有Python绑定，Cortex就可以为它提供服务）。因为Cortex可以插入任何堆栈，它开始对Cortex在底层使用的工具有自己的看法，这反过来又使构建更高级别的功能变得更加容易。例如，自从用于模型服务的Cortex发布以来，增加了对GPU推理、基于请求的自动缩放、滚动更新和预测监控的支持。无需为十几个不同的容器运行时和集群协调器实现这些功能。Cortex在底层使用Docker和Kubernetes，用户完全不必担心它们。到目前为止，这种方法似乎有效：来源：StarHistory将从Web开发中吸取的经验教训应用到ML工具从哲学上讲，Web框架对如何看待Cortex有很大影响。像Rails和Django这样的框架非常重视程序员的生产力和幸福感。要构建Web应用程序，您不必担心配置SQL数据库、实施请求路由或编写自己的SMTP方法来发送电子邮件。所有这一切都隐藏在一个直观、简单的界面之后。皮质是一样的。数据科学家不必学习Kubernetes，而是专注于数据科学。工程师们也不需要浪费几天的时间来弄清楚如何避免5GB版本的AWS账单超支，他们可以自由地构建软件。我们希望随着ML生态系统的成熟和稳定，这种“哲学”将慢慢传播到堆栈的其他部分。目前，模型服务是一个很好的起点。
