谷歌投資「演算法商店」創始人：打造AI操作系統（PPT)

1 新智元編譯

筆記本電腦上的操作系統同時運行幾十個或者幾百個進程。它會給每一個進程分配所需要的資源（RAM、CPU 和 IO）。它會將它們隔離在自己的虛擬空間中，將它們鎖定到一組預定義的許可權，允許它們進行通信，並允許用戶安全地監視和控制它們。

操作系統會抽象出硬體層（寫入快閃記憶體驅動器與寫入硬碟驅動器相同），並且不關心用於編寫這些應用程序的編程語言或技術堆棧——它只是順利地統一地運行它們。

隨著機器學習逐漸滲透到企業，許多公司很快就會發現自己在生產越來越多的模型，並且更快地剪輯。隨著時間的推移，部署效率，資源規模，監測和審計將開始變得更加困難和昂貴。來自公司不同部門的數據科學家將各自擁有自己的一套首選技術（R，Python，Julia，Tensorflow，Caffe，deeplearning4j，H2O等），數據中心戰略將從一個雲轉向混合。以一種類似雲的方法運行、擴展、監管多樣模型，負責地說，與操作系統很像，這就是我們想說的 。

在 Algorithmia.com 上，我們運行3,500多種演算法（每種都有多個版本，最多可以獲得40k +獨特的REST API端點）。任何API端點都可以從一天一次到每秒1,000次以上的突發，具有完全無限制的體驗。這些演算法以我們今天支持的八種編程語言中的任何一種編寫，可以基於CPU或GPU，可以在任何雲端運行，可以讀取和寫入任何數據源（S3，Dropbox等），並以標準硬體 ?15ms。

我們將 Algorithmia.com 視為我們的AI操作系統版本，這篇文章將分享我們的一些想法。

目錄

? 訓練 VS 推理

? 無伺服器 FTW

? Kernel 和 Shell

? Kernel #1 彈性伸縮

? Kernel #2 Runtime Abstraction

? Kernel #3 Cloud Abstraction

? 總結

訓練VS推理

機器學習和深度學習由兩個獨特的階段構成：訓練和推理。前者關於搭建模型，後者是關於在產品中運行這些模型。

訓練模型是一個非常依賴框架的迭代過程。一些機器學習工程師在GPU上使用Tensorflow，其他人在CPU上使用scikit-learn 。這類似於構建應用程序，其中應用程序開發人員有一個精心整合的開發工具鏈和庫，不斷編譯和測試他們的代碼。培訓需要很長的計算周期（數小時到數天），通常是固定的負載輸入（意味著你不需要從一台機器擴展到X機器以響應觸發器），並且理想地是一個有狀態的過程，數據科學家將需要反覆保存訓練進度，如神經網路檢查點。

另一方面推理是將該模型規模擴展到多個用戶。當同時運行多個模型時，每個模型都以不同的框架和語言編寫，它類似於操作系統。操作系統將負責調度工作，共享資源和監視這些工作。 「工作」是一個推理事務，與訓練的情況不同，需要一個短暫的計算周期（類似於SQL查詢），彈性負載（機器需要與推理需求成比例地增加/減少），而且它是無狀態的，其中先前事務的結果不會影響下一個事務的結果。

我們將重點放在推理方面。

無伺服器 FTW

我們將為我們的操作系統使用無伺服器計算，所以讓我們花一點時間來解釋為什麼無伺服器架構對於AI推理是有意義的。

正如我們在上一節中所解釋的，機器學習推理需要一個短的計算突發。這意味著作為REST API服務的伺服器將處於空閑狀態。例如，當接收到請求時，要對圖像進行分類，它會在短時間內突然出現CPU / GPU利用率，返回結果，然後恢復為空閑狀態。此過程與資料庫伺服器相似，該伺服器在接收到SQL查詢之前是空閑的。

由於這個要求，AI推理是非常適合無伺服器計算的。無伺服器架構具有明顯的擴展優勢和經濟優勢。例如，假設您已經構建了一個名為「SeeFood」的應用程序，它可以將圖像分為是熱狗和不是熱狗。您的APP會被虛擬化，現在位列圖表上方。以下是您的日常應用使用情況：

「SeeFood」每日應用程序的使用情況。午餐時間非常受歡迎。

Y軸為「每秒呼叫」。 X軸是每天的時刻。

在這個虛擬的情況下，如果我們使用傳統（固定規模）架構，那麼我們每天要養40台機器。這是以下綠色突出顯示的區域。使用標準的雲定價，這可能需要我們約$ 648 * 40 =每月25,920美元。

傳統架構 - 最大設計

40台機器24小時， $ 648 * 40 = $ 25,920每月

如果我們使用自動擴展架構（我們每小時添加或刪除機器），那麼我們每天平均需要支付19台機器。這是以下綠色突出顯示的區域。總共$ 648 * 19 = $ 12,312每月。

自動擴展架構 - 本地最大設計

19台機器24小時。 $ 648 * 40 = $ 12,312每月

最後，如果我們使用無伺服器架構，那麼我們將在理論上支付我們使用的金額，而不是為空閑時間付費。這是下面圖表中的藍色區域。這個虛構場景中的成本是難以計算的 - 它平均降低到21個/秒，或者相當於6台機器。這是$ 648 * 6 = $ 3,888每月。

無伺服器架構 - 最小設計

平均 21次調用/秒，或相當於6台機器。 $ 648 * 6 =每月$ 3,888

在這個（虛構的）情況下，我們的雲計算成本從$ 26k到$ 4k。除了更簡單的開發（功能封裝為原子服務），降低延遲（與邊緣計算一起使用）以及滾動部署功能等其他優點之外，這也是使用無伺服器計算的重要原因。

從零開始建立一個無伺服器架構並不是一件特別困難的事情，特別是近期的進步。像Kubernetes和Docker這樣的項目將大大簡化功能即服務體系結構的分布、擴展和恢復需求。

Kernels and Shells

和由 Kernel、Shell 和 Service 構成的操作系統類似，我們的操作系統也包括這些組件。

Shell 是用戶與之互動的部分，如網站或API端點。Service 是我們操作系統的可插拔組件，如認證和報告。最後一層，Kernel 是真正定義我們操作系統的部分。下面將重點關注。

我們的 Kernel 由三個主要組件組成：彈性伸縮（elastic scaling），runtime abstraction 和cloud abstraction。我們來詳細探討這些組件。

Kernel ＃1 智能彈性伸縮

如果我們知道演算法#A總是會調用演算法#B，我們如何利用這些知識？這就是應需 scaling up 的智能部分。

可組合性是機器學習和數據科學世界中非常普遍的模式。數據處理流程通常由預處理、處理和後處理階段組成。在這種情況下，處理流程是流程上不同功能的組合。在 ensemble 中也發現了這種組合性，數據科學家運行不同的模型，然後綜合最終得分。

舉個例子：「SeeFood」拍攝了一張水果或蔬菜的照片，然後給出水果或蔬菜的名稱。相比於為所有食物和蔬菜建立一個單一的分類器，通常將其分解為三個分類器，像這樣：

在這種情況下，我們知道頂端的模型（「水果或蔬菜分類器」）將始終調用「水果分類器」或「蔬菜分類器」。如何利用這一點？一種方法是對所有資源進行測量，跟蹤每個模型消耗的CPU水平、內存水平和IO水平。我們的 orchestrator 可以設計為在堆棧這些任務時使用此信息，從而減少網路或增加伺服器利用率（為單個伺服器適配更多的模型）。

Kernel＃2 Runtime Abstraction

我們的 Kernel 的第二個組件是 runtime abstraction。在機器學習和數據科學工作流中，通常我們用某個堆棧（比如說R，GPU 上的 TensorFlow）構建一個分類器，並且在不同的堆棧上（也許是Python，CPU 上的scikit-learn）運行預處理或相鄰模型。

我們的操作系統必須抽象出這些細節，並實現功能和模型之間的無縫互操作性。為此，我們使用RESTAPI ，並使用JSON或等效的通用數據表徵來交換數據。如果數據太大，我們將URI傳遞給數據源，而不是JSONblob。

Kernel＃3 Cloud Abstraction

如今我們不期望程序員是devops。我們甚至不期望數據科學家理解不同雲供應商的所有複雜細節。處理不同的數據源是這種抽象的一個很好的例子。

想像一下，數據科學家創建了一個分類圖像模型。該模型的消費者可能有三種不同的角色：（a）後端製作工程師可能正在使用S3；（b）數據科學家可能使用Hadoop；（3）不同組織中的BI用戶可能正在使用Dropbox。要求該模型的作者為每一個源構建一個數據連接器（並保留它，以備未來新數據源之需）會分散他們工作的注意力。而我們的操作系統可以提供讀寫不同數據源的 DataAdapter API。

以上代碼分別顯示了不帶 abstraction 和帶有 abstraction的數據讀取

在第一個塊中，沒有存儲抽象需要我們為每個數據源（在這種情況下為S3）編寫一個連接器，並在我們的模型中進行硬編碼。在第二個塊中，我們使用DataAdapter API，它接收到數據源的URI，並自動注入正確的數據連接器。那些URI可以指向S3，Azure Blob，HDFS，Dropbox 或其他任何東西。

總結

到目前為止，我們的操作系統是自動伸縮、可組合、自動優化且與雲無關的。監控您的數百或數千種模型也是至關重要的任務。不過它還在做另外一件事：可見性。

可見性是發現以下各方創建的模型和功能的能力：

• 操作系統的第一方用戶（您的同事）

• 第三方供應商（學術界、開源、獨立開發商）

操作系統不是產品，而是平台。從打孔卡片到機器語言到彙編語言，操作系統慢慢地爬上了抽象的梯子。抽象，是關於如何將事物看成是模塊化組件，鼓勵重用，並使得高級工作流更易於訪問。這就是為什麼最新一波的操作系統（如 iOS 和 Android）都附帶了內置的 AppStore。

出於同樣的原因，我們的操作系統必須重視可見性和可重用性。這就是為什麼我們創建了CODEX，我們 AI 的首選操作系統，以及 Algorithmia.com，演算法和模型的應用程序商店。我們幫助公司提高其演算法的可見性，同時讓這些公司（和獨立開發人員）通過 Algorithmia.com 訪問最佳的第三方演算法。

編譯來源：https://blog.algorithmia.com/wp-content/uploads/2017/07/geekwire-os-for-ai.pdf

PPT 下載：https://blog.algorithmia.com/wp-content/uploads/2017/07/geekwire-os-for-ai.pdf

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！