沒人告訴你的大規(guī)模部署AI高效流程！
現(xiàn)在有許多關于 AI 的教程。比如如何進行目標檢測、圖像分類、NLP 以及構建聊天機器人等，不勝枚舉。
但當我查找如何正確擴展 AI 的內(nèi)容時，卻發(fā)現(xiàn)少得可憐。更令人驚訝的是，現(xiàn)有的極少數(shù)資源在反復強調(diào)相同的幾點：
- 用像 TensorFlow 這樣的可擴展框架構建模型。
- 將其打包到客戶端(TF.js、TF Lite、TF-slim 等)或部署為基于容器的微服務。
我對第二點更感興趣，因為我已經(jīng)開發(fā)好了一個模型，但令我驚訝的是，沒有任何關于如何實現(xiàn)第二點的細節(jié)，而關于每個解決方案缺點的信息則更少。研究了幾天并在 Crane.ai 上擴展 AI 之后，我整理了一些關于如何部署這些方法、這些方法的缺點以及如何在低級別優(yōu)化 TensorFlow 模型的內(nèi)容。
將模型打包到客戶端——這種方法太糟了!
最常用的方法之一是用像 TensorFlow.js、TF Lite 或 TensorFlow Slim 這樣的工具將 AI 打包到你所選擇的客戶端中。我不會詳細介紹這些框架如何運行，但我會重點說明它們的缺點。
- 計算能力。部署這些模型的問題在于它們需要大量的內(nèi)存(我指的是移動應用程序或瀏覽器的限制，即 > 1-2GB RAM)。許多手機都沒有這樣的計算能力，而桌面瀏覽器又會延遲 UI 線程，同時也降低了用戶的計算機速度，要打開瀏覽器，還要打開風扇等等。
- 推斷時間。當你在計算能力未知的設備上運行模型時，推斷時間一般也是未知的;這些設備不是 GPU 驅(qū)動的高 RAM、高 CPU 機器，它們只是在普通計算機上運行的手機、瀏覽器和桌面應用程序。較大模型的推斷時間可以輕松超過一分鐘時間，而從用戶體驗的角度來看，這并不可行。
- 大文件。不幸的是大多數(shù)模型都存儲在相當大的文件中(我指的是數(shù)十、數(shù)百 MB)。因此，加載這些文件速度很慢，需要的內(nèi)存量比較大，也大幅增加了應用程序包的大小。
- 不安全。除非你用的是開源模型，否則你要相對保密你的 AI 模型和預訓練檢查點。然而，當你將模型打包進應用程序時，不僅你的推斷代碼容易被反編譯，而且在應用程序包里的預訓練檢查點也很容易被竊取。
- 難以更新。如果想要更新你的模型，在客戶端中你有兩個選擇。要么通過集中管理器(即 Play Store、App Store 等)發(fā)布更新，這會導致頻繁的大型更新(對用戶而言這是很煩人的，而且用戶可以根據(jù)設置打斷這個過程，或者壓根就不開啟更新)。或者應用程序本身可以獲取新模型的檢查點和元數(shù)據(jù)。后者聽起來要好得多，但是這意味著你可能要在用戶連接不穩(wěn)定的情況下下載 100MB 以上的文件，這可能需要一段時間，所以你的應用程序至少要在后臺開到下載過程完成，而且會產(chǎn)生很高的互聯(lián)網(wǎng)輸出成本(這取決于你的云計算)。
- 缺乏可訓練性。針對新用戶的數(shù)據(jù)訓練的模型提供了一定程度的個性化，同時提高了準確率，并建立了核心的高信號數(shù)據(jù)集。不幸的是大部分設備缺乏訓練模型的計算能力，即便它們的計算能力夠了，也無法將訓練效果傳遞到服務器或其他運行該應用程序的設備。
這些缺點使得在客戶端上部署和維護大型神經(jīng)網(wǎng)絡幾乎不可能，所以我們從擴展模型的備選項中排除這一項。
部署為云端點
圖源：https://xkcd.com/908/
云是可以大規(guī)模部署模型的強大工具。你可以根據(jù)需要定制環(huán)境、容器化應用程序、立即水平擴展應用程序，同時提供足以和大公司媲美的 SLA 和運行時間。
對大部分 TensorFlow 模型來說，部署流程是相同的：
- 將圖像固化為 Protobuf 二進制文件
- 調(diào)整推斷代碼，使它可以處理固化的圖
- 容器化應用程序
- 在最上面加上 API 層
第一部分相對簡單。「固化」圖要用所有命名節(jié)點、權重、架構和檢查點元數(shù)據(jù)創(chuàng)建一個 protobuf 二進制文件。這一步可以用多種工具實現(xiàn)，最常用的是 TF 自己的工具，它可以固化任何給定輸出節(jié)點名字的圖。
更多該技術相關信息以及實現(xiàn)參閱： https://www.tensorflow.org/guide/extend/model_files#freezing。
調(diào)整推斷代碼也不難。在大多數(shù)情況下，feed_dict 是不變的，主要區(qū)別在于添加了加載模型的代碼，也許還有輸出節(jié)點的規(guī)范。
容器化也很簡單——只要在 Dockerfile 中設置環(huán)境即可。而當我們開始添加 API 層時，事情就會變得混亂。通常用這兩種方法：
部署可以運行推斷腳本的擴展容器。這些容器根據(jù)輸入運行腳本，腳本啟動一個會話并執(zhí)行推斷，再通過管道返回輸出結果。這是很有問題的：對大多數(shù)云供應商而言添加一個可以操縱容器和管道進出的 API 層并不容易(例如，AWS 有 API 網(wǎng)關，但它并不像你期望的那么方便)，而且這種方法是你可以采用的效率最低的方法。這里的問題是你在啟動容器、分配硬件、啟動會話以及推斷時損失的寶貴時間。如果你讓 stdin 開著并保持管道輸出，那么你的腳本就會加速但是會失去可擴展性(現(xiàn)在你已經(jīng)連接到容器的 STDIN，而它無法接受多個請求)。
部署運行 API 層的擴展容器。盡管在架構上相似，但由于以下幾個原因，這種方法效率更高。將 API 層內(nèi)置在容器中，可以緩解之前提出的大多數(shù)問題。雖然這需要更多資源，但它已經(jīng)用了最少資源而且沒有垂直擴展;它允許每個容器保持運行狀態(tài)，而且由于這種情況下 API 是分散的，因此可以將特定的 stdin/stout 連接到主要的請求路由器上。這意味著省去了啟動時間，可以在服務多個請求的同時維持速度并保證水平擴展。可以用負載平衡器集中容器，并用 Kubernetes 保證近乎 100% 的運行時間并管理集群。這種方式簡單且有效。
部署集群!
通過容器集群分散 API 的主要缺點在于計算成本會相對較快地累積起來。不幸的是這在 AI 中是不可避免的，但有一些方法可以緩解這一問題。
- 重復使用會話。集群會根據(jù)負載成比例地增長和收縮，因此你的目標是最小化執(zhí)行推斷的時間，使容器可以釋放出來處理另外的請求。實現(xiàn)這一想法的方法是初始化 tf.Session 和 tf.Graph 后就將它們存儲起來并將它們作為全局變量傳遞，以達到重復使用 tf.Session 和 tf.Graph 的目的。對 TF 來說，這一舉措可以減少啟動會話和構建圖的時間，從而大大提高推斷任務的速度。即便是單個容器，這個方法也是有效的，而且這一技術被廣泛用于資源再分配最小化和效率最大化。
- 緩存輸入，如果可能的話還要緩存輸出。在 AI 中，動態(tài)規(guī)劃范式在 AI 中是最重要的。通過緩存輸入，你可以節(jié)省預處理輸入或從遠程獲得輸入的時間;通過緩存輸出，你可以節(jié)省運行推斷的時間。這在 Python 中很容易實現(xiàn)，但你要視自己的情況而定。通常，你的模型會隨著時間的推移變得更好，但這會很大程度上影響你的輸出緩存機制。我自己的系統(tǒng)用的是我所謂的「80-20」規(guī)則。當模型準確率低于 80% 時，我不會緩存任何輸出;一旦準確率到了 80%，就開始緩存并設置為在準確率到一定值(而不是某個時間點)的時候停止緩存。這樣，隨著模型變得越來越準確，輸出也會發(fā)生變化，但是在「80-20」緩存中，性能和速度之間存在的權衡更少。
使用任務隊列。一般需要運行或大或小的推斷任務(在我們的例子中是較大和較小、復雜和簡單的圖像)。對 UX 來說，使用堆隊列(heap queue)可能更好，它會優(yōu)先處理小一些的任務，所以要運行簡單步驟的用戶只要等這一步結束就行了，而不必等另一個用戶的更大推斷任務先完成。(也許你會想我在這里為什么不用水平擴展，你可以這么做但是會增加計算成本)。
在帶有任務隊列的專用 GPU 上訓練模型。訓練是一項長期、困難的任務，它需要大量可用的資源，而且模型在訓練過程中無法使用。如果你要將每個交互返回到模型中進行訓練，請考慮在單獨的服務器或 GPU 上運行。一旦訓練結束，你就可以將模型(在 AWS 中，你可以將模型 repo 集中在 S3 中)部署到容器中了。
結論
深思熟慮后，我們提出了一個大規(guī)模部署 AI 的高效工作流程：
- 固化圖并將推斷封裝在 API 下
- 重復使用會話和圖，緩存輸入和輸出
- 用 Docker 容器化應用程序(包括 API 層)
- 將大規(guī)模應用程序與 Kubernetes 一起部署在你選擇的云上
- 將訓練從推斷中分離出來
- 建立任務隊列，將較小的任務確立為優(yōu)先級
使用這些技術，你就可以在成本最小、速度和效率最大的情況下大規(guī)模部署 AI。
原文鏈接：https://towardsdatascience.com/scaling-ai-2be294368504
【本文是51CTO專欄機構“機器之心”的原創(chuàng)譯文，微信公眾號“機器之心( id: almosthuman2014)”】
