本文轉載自公眾號“讀芯術”(ID：AI_Discovery)

2019年初，筆者幾個人嘗試構建端到端ML框架。我們認為，構建ML管道是一種令人沮喪的、脫節的體驗，我們完全可以構建更好的東西。但事情并不像想象中那樣順利。

[[326591]]

我們使用Kaggle數據集為ML管道的不同階段(數據攝取、培訓、部署等)進行了抽象，并公開了存儲庫來源并分享。一個月后，它登上了HN的頭版，改進機器學習的用戶體驗是很多人的關切點。半年后，它在GitHub擁有了幾百個“星星”，但幾乎沒有人使用它。痛定思痛，我們刪除了90%的代碼庫。

經歷這一切之后，我們建立了一個更好的項目：Cortex(模型服務基礎設施)。但對于任何對機器學習和/或ML工具感興趣的人來說，這都是一個警醒你的故事：

“生產機器學習確實需要更好的UX，但是ML生態系統是復雜和多變的，這使得構建一個覆蓋大量用例的工具非常困難。”

為什么需要端到端ML框架

大多數人(Cortex貢獻者)都有devops和web開發的背景，他們習慣于將應用程序的不同層抽象成單一接口的框架。

每個剛剛開始學習機器學習的人，都會感慨工具的脫節。你想建立推薦引擎和聊天機器人，在這一過程中你會發現自己在不同的環境之間來回跳轉——Jupyternotebooks、終端、AWS控制臺等。編寫粘合代碼和TensorFlow樣板的整個文件夾可以被稱為“管道”，這是很必要的。

如果可以用配置文件和命令來代替所有的修改和粘貼：

$ deploy recommendation_engine 

看起來還不錯。接著我們構建一個工具，使用Python來轉換數據，使用YAML來構建管道，使用CLI來控制一切：

當你給它一個Kaggle數據集，使用支持的狹窄堆棧，再加上在api上設置的限制時，它是一個非常棒的工具。但問題來了，如果嘗試在現實世界中使用它，那么它可能無法與堆棧一起工作。

雖然有些問題歸結于設計，但很大一部分問題實際上是構建端到端工具的固有問題——只是在構建之后才發現。

端到端ML框架的問題

簡單地說，機器學習生態系統產品對于端到端框架來說尚未成熟。ML工程師希望使用更好的UX工具，這當然無可厚非。但是試圖構建一個涵蓋多個用例的端到端框架，那你就錯了，尤其是特別是在只有少數貢獻者的情況下。

web框架或許會給我們啟發，想想它們是什么時候開始嶄露頭角的吧。

Rails、Django和Symfony都是在2004年到2005年間發布的，它們都是web新MVC框架的一部分。雖然那時的web開發可能不是“穩定的”，特別是考慮到它走向成熟的過程(這很大程度上要歸功于那些框架)，但是web開發人員所做的工作仍然有高度的相似性。

事實上，Rails最早的格言之一是“你不是美麗而獨特的雪花”，這是指大多數web開發人員都在構建架構上類似的應用程序，這些應用程序可以在相同的配置上運行。

機器學習產品還沒有到那個階段，一切仍在變化之中。數據科學家在他們處理的數據類型、使用的模型體系結構喜歡的語言/框架、應用程序的推斷需求以及幾乎所有能想到的其他方面都有所不同。

更重要的是，該領域本身就變化迅速。我們可以看到，自從Cortex18個月前首次發布以來：

• PyTorch已經從一個很有前途的項目變成了比較流行的ML框架，同時發布了許多專門的培訓庫(比如微軟的Deep Speed)。
• 大量初創公司已經開始使用轉移學習和預培訓模型來微調和部署具有少量數據的模型(例如，現在不是每個人都需要100個節點的Spark集群)。
• Open AI發布了有史以來比較大的模型，15億參數的GPT-2。此后，谷歌、Salesforce、微軟和英偉達都發布了更大的型號。

變化從未停止，這意味著試圖構建一個支持“正確”堆棧的端到端框架從一開始就注定要失敗。

每個人都會要求他們需要的“一個功能”，但是沒有人有相同的要求。我們嘗試了一段時間，但很快發現“用Django換ML”是不可行的，至少不是想象中的那種方式。

關注模型服務基礎設施

端到端是很困難的，因為ML生態系統的大部分就像“蠻荒之地”般尚未成型。然而，有一個領域是穩定和一致的：模型服務。

不管使用什么堆棧，大多數團隊都是通過將模型包裝在API中并部署到云中來將模型投入生產的。但數據科學家不喜歡它，因為用于構建可伸縮web服務的工具——docker、Kubernetes、EC2/GCE、負載均衡器等等——都不在他們的控制范圍之內。

這是一個好機會。模型，即微服務的設計模式在團隊中是一致的，而作為基礎設施一部分的工具，也是非常穩定的。同時，作為軟件工程師，在構建生產web服務方面比ML管道更有經驗。

所以，我們認為應該給模型這個機會。我們應用了相同的設計原則，抽象了聲明式YAML配置和最小的CLI背后的所有低層爭論，并自動化了將經過訓練的模型轉換為可伸縮的生產web服務的過程。

通過專門關注模型服務，我們可以不知道堆棧的其他部分(只要模型有Python綁定，Cortex就可以為它服務)。因為Cortex可以插入任何堆棧，開始對Cortex在底層使用的工具有自己的看法，這反過來又使它更容易構建更高層次的功能。

例如，自從發布了用于模型服務的Cortex之后，增加了對GPU推理、基于請求的自動縮放、滾動更新和預測監控的支持。不需要為十幾個不同的容器運行時和集群協調器實現這些特性。Cortex在引擎蓋下使用了Docker和Kubernetes，而且用戶根本不用操心它們。

到目前為止，這種方法似乎是有效的：

圖源: Star History

將web開發的經驗應用到ML工具中

從哲學上講，web框架對如何看待Cortex有很大的影響。

像Rails和Django這樣的框架非常重視程序員的工作效率和幸福感。要構建web應用程序，你不必擔心配置SQL數據庫、實現請求路由或編寫自己的SMTP方法來發送電子郵件。所有這些都被隱藏到直觀、簡單的接口之后。

Cortex也是同樣的。數據科學家不必學習Kubernetes，而是專注于數據科學。工程師們也不需要浪費幾天時間來研究如何避免5GB版本的把他們的AWS賬單搞到爆炸，他們可以自由地構建軟件。

我們希望，隨著ML生態系統的成熟和穩定，這樣的“哲學”會慢慢擴展到堆棧的其他部分。而現在，模型服務就是一個很好的起點。