本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)

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

[[326591]]

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

經(jīng)歷這一切之后，我們建立了一個(gè)更好的項(xiàng)目：Cortex(模型服務(wù)基礎(chǔ)設(shè)施)。但對(duì)于任何對(duì)機(jī)器學(xué)習(xí)和/或ML工具感興趣的人來說，這都是一個(gè)警醒你的故事：

“生產(chǎn)機(jī)器學(xué)習(xí)確實(shí)需要更好的UX，但是ML生態(tài)系統(tǒng)是復(fù)雜和多變的，這使得構(gòu)建一個(gè)覆蓋大量用例的工具非常困難。”

為什么需要端到端ML框架

大多數(shù)人(Cortex貢獻(xiàn)者)都有devops和web開發(fā)的背景，他們習(xí)慣于將應(yīng)用程序的不同層抽象成單一接口的框架。

每個(gè)剛剛開始學(xué)習(xí)機(jī)器學(xué)習(xí)的人，都會(huì)感慨工具的脫節(jié)。你想建立推薦引擎和聊天機(jī)器人，在這一過程中你會(huì)發(fā)現(xiàn)自己在不同的環(huán)境之間來回跳轉(zhuǎn)——Jupyternotebooks、終端、AWS控制臺(tái)等。編寫粘合代碼和TensorFlow樣板的整個(gè)文件夾可以被稱為“管道”，這是很必要的。

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

$ deploy recommendation_engine 

看起來還不錯(cuò)。接著我們構(gòu)建一個(gè)工具，使用Python來轉(zhuǎn)換數(shù)據(jù)，使用YAML來構(gòu)建管道，使用CLI來控制一切：

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

雖然有些問題歸結(jié)于設(shè)計(jì)，但很大一部分問題實(shí)際上是構(gòu)建端到端工具的固有問題——只是在構(gòu)建之后才發(fā)現(xiàn)。

端到端ML框架的問題

簡單地說，機(jī)器學(xué)習(xí)生態(tài)系統(tǒng)產(chǎn)品對(duì)于端到端框架來說尚未成熟。ML工程師希望使用更好的UX工具，這當(dāng)然無可厚非。但是試圖構(gòu)建一個(gè)涵蓋多個(gè)用例的端到端框架，那你就錯(cuò)了，尤其是特別是在只有少數(shù)貢獻(xiàn)者的情況下。

web框架或許會(huì)給我們啟發(fā)，想想它們是什么時(shí)候開始嶄露頭角的吧。

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

事實(shí)上，Rails最早的格言之一是“你不是美麗而獨(dú)特的雪花”，這是指大多數(shù)web開發(fā)人員都在構(gòu)建架構(gòu)上類似的應(yīng)用程序，這些應(yīng)用程序可以在相同的配置上運(yùn)行。

機(jī)器學(xué)習(xí)產(chǎn)品還沒有到那個(gè)階段，一切仍在變化之中。數(shù)據(jù)科學(xué)家在他們處理的數(shù)據(jù)類型、使用的模型體系結(jié)構(gòu)喜歡的語言/框架、應(yīng)用程序的推斷需求以及幾乎所有能想到的其他方面都有所不同。

更重要的是，該領(lǐng)域本身就變化迅速。我們可以看到，自從Cortex18個(gè)月前首次發(fā)布以來：

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

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

每個(gè)人都會(huì)要求他們需要的“一個(gè)功能”，但是沒有人有相同的要求。我們嘗試了一段時(shí)間，但很快發(fā)現(xiàn)“用Django換ML”是不可行的，至少不是想象中的那種方式。

關(guān)注模型服務(wù)基礎(chǔ)設(shè)施

端到端是很困難的，因?yàn)镸L生態(tài)系統(tǒng)的大部分就像“蠻荒之地”般尚未成型。然而，有一個(gè)領(lǐng)域是穩(wěn)定和一致的：模型服務(wù)。

不管使用什么堆棧，大多數(shù)團(tuán)隊(duì)都是通過將模型包裝在API中并部署到云中來將模型投入生產(chǎn)的。但數(shù)據(jù)科學(xué)家不喜歡它，因?yàn)橛糜跇?gòu)建可伸縮web服務(wù)的工具——docker、Kubernetes、EC2/GCE、負(fù)載均衡器等等——都不在他們的控制范圍之內(nèi)。

這是一個(gè)好機(jī)會(huì)。模型，即微服務(wù)的設(shè)計(jì)模式在團(tuán)隊(duì)中是一致的，而作為基礎(chǔ)設(shè)施一部分的工具，也是非常穩(wěn)定的。同時(shí)，作為軟件工程師，在構(gòu)建生產(chǎn)web服務(wù)方面比ML管道更有經(jīng)驗(yàn)。

所以，我們認(rèn)為應(yīng)該給模型這個(gè)機(jī)會(huì)。我們應(yīng)用了相同的設(shè)計(jì)原則，抽象了聲明式Y(jié)AML配置和最小的CLI背后的所有低層爭(zhēng)論，并自動(dòng)化了將經(jīng)過訓(xùn)練的模型轉(zhuǎn)換為可伸縮的生產(chǎn)web服務(wù)的過程。

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

例如，自從發(fā)布了用于模型服務(wù)的Cortex之后，增加了對(duì)GPU推理、基于請(qǐng)求的自動(dòng)縮放、滾動(dòng)更新和預(yù)測(cè)監(jiān)控的支持。不需要為十幾個(gè)不同的容器運(yùn)行時(shí)和集群協(xié)調(diào)器實(shí)現(xiàn)這些特性。Cortex在引擎蓋下使用了Docker和Kubernetes，而且用戶根本不用操心它們。

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

圖源: Star History

將web開發(fā)的經(jīng)驗(yàn)應(yīng)用到ML工具中

從哲學(xué)上講，web框架對(duì)如何看待Cortex有很大的影響。

像Rails和Django這樣的框架非常重視程序員的工作效率和幸福感。要構(gòu)建web應(yīng)用程序，你不必?fù)?dān)心配置SQL數(shù)據(jù)庫、實(shí)現(xiàn)請(qǐng)求路由或編寫自己的SMTP方法來發(fā)送電子郵件。所有這些都被隱藏到直觀、簡單的接口之后。

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

我們希望，隨著ML生態(tài)系統(tǒng)的成熟和穩(wěn)定，這樣的“哲學(xué)”會(huì)慢慢擴(kuò)展到堆棧的其他部分。而現(xiàn)在，模型服務(wù)就是一個(gè)很好的起點(diǎn)。