沒人告訴你的大規模部署AI高效流程！

作者：機器之心編譯 2019-01-07 05:51:34

本文介紹了規模化部署 AI 模型的流程，包括如何部署這些方法、這些方法的缺點以及如何在低級別優化 TensorFlow 模型。

現在有許多關于 AI 的教程。比如如何進行目標檢測、圖像分類、NLP 以及構建聊天機器人等，不勝枚舉。

但當我查找如何正確擴展 AI 的內容時，卻發現少得可憐。更令人驚訝的是，現有的極少數資源在反復強調相同的幾點：

用像 TensorFlow 這樣的可擴展框架構建模型。
將其打包到客戶端(TF.js、TF Lite、TF-slim 等)或部署為基于容器的微服務。

我對第二點更感興趣，因為我已經開發好了一個模型，但令我驚訝的是，沒有任何關于如何實現第二點的細節，而關于每個解決方案缺點的信息則更少。研究了幾天并在 Crane.ai 上擴展 AI 之后，我整理了一些關于如何部署這些方法、這些方法的缺點以及如何在低級別優化 TensorFlow 模型的內容。

[[254822]]

將模型打包到客戶端——這種方法太糟了!

最常用的方法之一是用像 TensorFlow.js、TF Lite 或 TensorFlow Slim 這樣的工具將 AI 打包到你所選擇的客戶端中。我不會詳細介紹這些框架如何運行，但我會重點說明它們的缺點。

計算能力。部署這些模型的問題在于它們需要大量的內存(我指的是移動應用程序或瀏覽器的限制，即 > 1-2GB RAM)。許多手機都沒有這樣的計算能力，而桌面瀏覽器又會延遲 UI 線程，同時也降低了用戶的計算機速度，要打開瀏覽器，還要打開風扇等等。
推斷時間。當你在計算能力未知的設備上運行模型時，推斷時間一般也是未知的;這些設備不是 GPU 驅動的高 RAM、高 CPU 機器，它們只是在普通計算機上運行的手機、瀏覽器和桌面應用程序。較大模型的推斷時間可以輕松超過一分鐘時間，而從用戶體驗的角度來看，這并不可行。

大文件。不幸的是大多數模型都存儲在相當大的文件中(我指的是數十、數百 MB)。因此，加載這些文件速度很慢，需要的內存量比較大，也大幅增加了應用程序包的大小。
不安全。除非你用的是開源模型，否則你要相對保密你的 AI 模型和預訓練檢查點。然而，當你將模型打包進應用程序時，不僅你的推斷代碼容易被反編譯，而且在應用程序包里的預訓練檢查點也很容易被竊取。
難以更新。如果想要更新你的模型，在客戶端中你有兩個選擇。要么通過集中管理器(即 Play Store、App Store 等)發布更新，這會導致頻繁的大型更新(對用戶而言這是很煩人的，而且用戶可以根據設置打斷這個過程，或者壓根就不開啟更新)。或者應用程序本身可以獲取新模型的檢查點和元數據。后者聽起來要好得多，但是這意味著你可能要在用戶連接不穩定的情況下下載 100MB 以上的文件，這可能需要一段時間，所以你的應用程序至少要在后臺開到下載過程完成，而且會產生很高的互聯網輸出成本(這取決于你的云計算)。
缺乏可訓練性。針對新用戶的數據訓練的模型提供了一定程度的個性化，同時提高了準確率，并建立了核心的高信號數據集。不幸的是大部分設備缺乏訓練模型的計算能力，即便它們的計算能力夠了，也無法將訓練效果傳遞到服務器或其他運行該應用程序的設備。

[[254823]]

這些缺點使得在客戶端上部署和維護大型神經網絡幾乎不可能，所以我們從擴展模型的備選項中排除這一項。

部署為云端點

圖源：https://xkcd.com/908/

云是可以大規模部署模型的強大工具。你可以根據需要定制環境、容器化應用程序、立即水平擴展應用程序，同時提供足以和大公司媲美的 SLA 和運行時間。

對大部分 TensorFlow 模型來說，部署流程是相同的：

將圖像固化為 Protobuf 二進制文件
調整推斷代碼，使它可以處理固化的圖
容器化應用程序
在最上面加上 API 層

第一部分相對簡單。「固化」圖要用所有命名節點、權重、架構和檢查點元數據創建一個 protobuf 二進制文件。這一步可以用多種工具實現，最常用的是 TF 自己的工具，它可以固化任何給定輸出節點名字的圖。

更多該技術相關信息以及實現參閱： https://www.tensorflow.org/guide/extend/model_files#freezing。

[[254824]]

調整推斷代碼也不難。在大多數情況下，feed_dict 是不變的，主要區別在于添加了加載模型的代碼，也許還有輸出節點的規范。

容器化也很簡單——只要在 Dockerfile 中設置環境即可。而當我們開始添加 API 層時，事情就會變得混亂。通常用這兩種方法：

部署可以運行推斷腳本的擴展容器。這些容器根據輸入運行腳本，腳本啟動一個會話并執行推斷，再通過管道返回輸出結果。這是很有問題的：對大多數云供應商而言添加一個可以操縱容器和管道進出的 API 層并不容易(例如，AWS 有 API 網關，但它并不像你期望的那么方便)，而且這種方法是你可以采用的效率最低的方法。這里的問題是你在啟動容器、分配硬件、啟動會話以及推斷時損失的寶貴時間。如果你讓 stdin 開著并保持管道輸出，那么你的腳本就會加速但是會失去可擴展性(現在你已經連接到容器的 STDIN，而它無法接受多個請求)。

部署運行 API 層的擴展容器。盡管在架構上相似，但由于以下幾個原因，這種方法效率更高。將 API 層內置在容器中，可以緩解之前提出的大多數問題。雖然這需要更多資源，但它已經用了最少資源而且沒有垂直擴展;它允許每個容器保持運行狀態，而且由于這種情況下 API 是分散的，因此可以將特定的 stdin/stout 連接到主要的請求路由器上。這意味著省去了啟動時間，可以在服務多個請求的同時維持速度并保證水平擴展。可以用負載平衡器集中容器，并用 Kubernetes 保證近乎 100% 的運行時間并管理集群。這種方式簡單且有效。

[[254825]]

部署集群!

通過容器集群分散 API 的主要缺點在于計算成本會相對較快地累積起來。不幸的是這在 AI 中是不可避免的，但有一些方法可以緩解這一問題。

重復使用會話。集群會根據負載成比例地增長和收縮，因此你的目標是最小化執行推斷的時間，使容器可以釋放出來處理另外的請求。實現這一想法的方法是初始化 tf.Session 和 tf.Graph 后就將它們存儲起來并將它們作為全局變量傳遞，以達到重復使用 tf.Session 和 tf.Graph 的目的。對 TF 來說，這一舉措可以減少啟動會話和構建圖的時間，從而大大提高推斷任務的速度。即便是單個容器，這個方法也是有效的，而且這一技術被廣泛用于資源再分配最小化和效率最大化。
緩存輸入，如果可能的話還要緩存輸出。在 AI 中，動態規劃范式在 AI 中是最重要的。通過緩存輸入，你可以節省預處理輸入或從遠程獲得輸入的時間;通過緩存輸出，你可以節省運行推斷的時間。這在 Python 中很容易實現，但你要視自己的情況而定。通常，你的模型會隨著時間的推移變得更好，但這會很大程度上影響你的輸出緩存機制。我自己的系統用的是我所謂的「80-20」規則。當模型準確率低于 80% 時，我不會緩存任何輸出;一旦準確率到了 80%，就開始緩存并設置為在準確率到一定值(而不是某個時間點)的時候停止緩存。這樣，隨著模型變得越來越準確，輸出也會發生變化，但是在「80-20」緩存中，性能和速度之間存在的權衡更少。

[[254826]]

使用任務隊列。一般需要運行或大或小的推斷任務(在我們的例子中是較大和較小、復雜和簡單的圖像)。對 UX 來說，使用堆隊列(heap queue)可能更好，它會優先處理小一些的任務，所以要運行簡單步驟的用戶只要等這一步結束就行了，而不必等另一個用戶的更大推斷任務先完成。(也許你會想我在這里為什么不用水平擴展，你可以這么做但是會增加計算成本)。

在帶有任務隊列的專用 GPU 上訓練模型。訓練是一項長期、困難的任務，它需要大量可用的資源，而且模型在訓練過程中無法使用。如果你要將每個交互返回到模型中進行訓練，請考慮在單獨的服務器或 GPU 上運行。一旦訓練結束，你就可以將模型(在 AWS 中，你可以將模型 repo 集中在 S3 中)部署到容器中了。

結論

[[254827]]

深思熟慮后，我們提出了一個大規模部署 AI 的高效工作流程：