全文共2420字，預計學習時長9分鐘
圖源：unsplash
2019年初，筆者幾個人嘗試構建端到端ML框架。我們認爲，構建ML管道是一種令人沮喪的、脫節的體驗，我們完全可以構建更好的東西。但事情並不像想象中那樣順利。
我們使用Kaggle數據集爲ML管道的不同階段（數據攝取、培訓、部署等）進行了抽象，並公開了存儲庫來源並分享。一個月後，它登上了HN的頭版，改進機器學習的用戶體驗是很多人的關切點。半年後，它在GitHub擁有了幾百個“星星”，但幾乎沒有人使用它。痛定思痛，我們刪除了90%的代碼庫。
經歷這一切之後，我們建立了一個更好的項目：Cortex（模型服務基礎設施）。但對於任何對機器學習和/或ML工具感興趣的人來說，這都是一個警醒你的故事：
“生產機器學習確實需要更好的UX，但是ML生態系統是複雜和多變的，這使得構建一個覆蓋大量用例的工具非常困難。”
爲什麼需要端到端ML框架
大多數人（Cortex貢獻者)都有devops和web開發的背景，他們習慣於將應用程序的不同層抽象成單一接口的框架。
每個剛剛開始學習機器學習的人，都會感慨工具的脫節。你想建立推薦引擎和聊天機器人，在這一過程中你會發現自己在不同的環境之間來回跳轉——Jupyternotebooks、終端、AWS控制檯等。編寫粘合代碼和TensorFlow樣板的整個文件夾可以被稱爲“管道”，這是很必要的。
圖源：unsplash
如果可以用配置文件和命令來代替所有的修改和粘貼：
$ deploy recommendation_engine
看起來還不錯。接着我們構建一個工具，使用Python來轉換數據，使用YAML來構建管道，使用CLI來控制一切：
當你給它一個Kaggle數據集，使用支持的狹窄堆棧，再加上在api上設置的限制時，它是一個非常棒的工具。但問題來了，如果嘗試在現實世界中使用它，那麼它可能無法與堆棧一起工作。
雖然有些問題歸結於設計，但很大一部分問題實際上是構建端到端工具的固有問題——只是在構建之後才發現。
端到端ML框架的問題
簡單地說，機器學習生態系統產品對於端到端框架來說尚未成熟。ML工程師希望使用更好的UX工具，這當然無可厚非。但是試圖構建一個涵蓋多個用例的端到端框架，那你就錯了，尤其是特別是在只有少數貢獻者的情況下。
web框架或許會給我們啓發，想想它們是什麼時候開始嶄露頭角的吧。
Rails、Django和Symfony都是在2004年到2005年間發佈的，它們都是web新MVC框架的一部分。雖然那時的web開發可能不是“穩定的”，特別是考慮到它走向成熟的過程（這很大程度上要歸功於那些框架)，但是web開發人員所做的工作仍然有高度的相似性。
圖源：unsplash
事實上，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賬單搞到爆炸，他們可以自由地構建軟件。
圖源：unsplash
我們希望，隨着ML生態系統的成熟和穩定，這樣的“哲學”會慢慢擴展到堆棧的其他部分。而現在，模型服務就是一個很好的起點。
我們一起分享AI學習與發展的乾貨
歡迎關注全平臺AI垂類自媒體 “讀芯術”
（添加小編微信：dxsxbb，加入讀者圈，一起討論最新鮮的人工智能科技哦～）