本文最初發佈於 Towards Data Science 博客，經原作者 Priansh Shah 授權由 InfoQ 中文站翻譯並分享。
AI 前線導讀：現在，創建深度學習模型越發容易，對數據科學家和開發者來說，在測試環境中打造複雜模型已不再是難事。但是要大規模部署人工智能模型就變得非常困難了，而且這個問題也不會隨着公司規模擴大而消失，更可怕的是，相關資料還很匱乏。Priansh Shah 跟我們分享了他在雲端上大規模部署人工智能的心得。
現在，關於人工智能的教程多如牛毛：比如，如何進行目標檢測、圖像分類、自然語言處理、構建聊天機器人等等，這份清單還不止這些。
但當我查找有關如何正確進行大規模部署人工智能的資料時，我發現相關內容屈指可數。更令人驚訝的是，眼下這些少得可憐的資源似乎都重申了同樣的這幾點：
- 使用 TensorFlow 之類的可擴展框架構建模型。
- 要麼將其打包到客戶端中（如 TF.js Lite、TF-slim 等），要麼將其部署爲帶有容器的微服務。
我對上述第二點更感興趣，因爲我已經開發了一個模型，但讓我很驚訝的是，在網上，關於如何實現這點的細節，相關資料寥若晨星。至於每種解決方案有何缺點的信息更是寥寥可數。經過幾天的研究並在 Crane.ai 上進行人工智能規模化之後，我整理了更多的信息，如有關部署、它們的缺點以及如何在低級別上優化 TensorFlow 模型。
將其打包到客戶端？太槽糕了！
其中一項最常用的技術就是使用 TensorFlow、TF Lite 或 TensorFlow Slim 等工具將人工智能打包到你所選擇的客戶端中。限於篇幅，我並不會贅述這些框架是如何運行的，而是重點闡述它們的缺點。
-
計算能力。這些模型的部署問題是它們需要海量內存（我指的是受移動 App 或瀏覽器的限制，即 > 1~2GB 內存）。很多手機並不具備這種能力，桌面瀏覽器會延遲 UI 線程，同時也會拖慢電腦、使發熱更嚴重，以致於啓動了 CPU 風扇等等。
-
推理時間。在計算能力未知的設備上運行模型時，推理時間通常也是未知的；而且這些還不是配置 GPU、大內存、高配 CPU 的機器，而是智能手機、瀏覽器以及普通電腦上運行的桌面應用程序。使用更大的模型僅需一分鐘即可輕鬆地進行推理，但從用戶體驗的角度來看，卻是一個大大的 “NO”。
-
大文件。不幸的是，大多數模型都存儲在相當大的文件中（我們說的是動輒幾十 MB、幾百 MB 那種）。因此，這會拖慢速度，而且加載起來會佔用大量內存，並且會大大增加了應用程序包的大小。
-
不安全。除非你使用的是開源模型，否則，你應該將你的人工智能和預訓練的檢查點進行相對保密。然而不幸的是，當你將模型與應用程序打包在一起時，不僅你的推理代碼容易遭到反編譯，而且預訓練的檢查點也會被打包其中，很容易被竊取。
-
難以更新。如果想更新模型，那麼客戶端有兩項選擇。要麼用戶通過像 Google Play、Apple 的 App Store 那樣的應用商店發佈的更新進行升級，但這方式會帶來頻繁的大更新（這對於用戶來說非常麻煩，而且這一更新可能會被終止或者永遠不更新，具體要取決於用戶的設置）；或者應用程序自身進行檢查更新和獲取元數據。後者聽上去更好一些，但這意味着，你必須通過用戶可能不穩定的連接下載一個 100MB 以上的文件；這需要耗費一段時間，因此你的應用程序至少要在後臺運行才能完成這一更新過程，而且你還需要支付相當大的網絡輸出成本（這取決於你採用的雲端）。
-
缺乏可訓練性。針對新用戶數據的訓練模型提供了一定程度的個性化，同時提高了其準確性，並構建了核心的、高信號的數據集。不幸的是，大多數設備缺乏訓練模型的計算能力，就算它們有這種能力，也不可能將訓練的效果傳送到運行這一應用的服務器或其他設備。
由於這些缺點的存在，在客戶端上部署和維護大型神經網絡幾乎是一個不可能實現的任務。因此，我們剔除了這一選項。
將其部署爲雲端點
雲端是大規模部署模型的強大工具。你可以根據需求調整完全定製的環境，將你的應用進行容器化，並立即橫向擴展，同時提供可與大公司相媲美的 SLA 和正常運行時間。
對大多數 TensorFlow 模型來說，部署週期是相同的：
- 將圖固化爲 Protobuf 二進制
- 調整推理代碼以使用固化圖
- 將應用程序容器化
- 在上面添加 API 層
第一部分相對簡單。“固化”（Freezing）圖涉及到創建一個 Protobuf 二進制文件，其中包含檢查點所涉及的所有命名節點、權重、體系結構和元數據。這些都可以用各種工具來實現，最爲流行的工具就是 TF 自己的工具，可以在給定輸出節點名的情況下，固化任何圖。要深入瞭解這項技術，以及如何完成這一部分的更多信息，可參閱《A Tool Developer’s Guide to TensorFlow Model Files》中的 “Freezing” 一節：
https://www.tensorflow.org/guide/extend/model_files#freezing
調整推理代碼也不難；多數情況下，你的feed_dict將保持不變，主要區別在於，添加的加載模型的代碼，也許還有輸出節點的規範。
容器化也非常簡單：只需在 Dockerfile 中設置環境即可（可使用 TF docker 鏡像作爲基礎）。但當我們開始添加 API 層時，事情就開始變得一團糟。通常有兩種方法可以做到這一點：
-
部署運行推理腳本的可擴展容器。這些容器針對輸入運行腳本，腳本啓動會話並運行推理，通過管道將輸出內容反饋給你作爲結果。這是非常有問題的；對大多數雲服務提供商來說，添加一個操作容器和管道的 API 層並不是一件很容易的簡單事（例如，雖說 AWS 有 API 網關，但它也遠沒有你所期望的那麼方便），這種方法效率最低。這裏的問題在於容器啓動、硬件分配、會話啓動和推理方面損失了寶貴的時間。如果打開
stdin並保持管道輸出，就會加快腳本的速度，但這樣一來，就失去了可擴展性（因爲你現在已連接到該容器的 STDIN，它就將無法接受多個請求）。 -
部署運行 API 層的可擴展容器。儘管在架構上類似，但出於幾種原因，這種方法效率更高；通過將 API 層放到容器中，可以緩解先前提到的大部分問題。雖然這樣一來，需要更多的資源，但它是最小的，並不意味着垂直擴展。它允許每個容器保持運行，而且這種情況下 API 是分散的，因此將特定的
stdin/stdout連接到主請求路由也沒有問題。這意味着你可以節約啓動時間，並且可以在服務多個請求時，能夠輕鬆保持速度和橫向擴展。你可以使用負載均衡器將容器集中化，並使用 Kubernetes 來保證幾乎 100% 的正常運行時間並管理 Fleet。這種方法簡單而有效！
通過容器 Fleet 來分散 API 的主要缺點是，這些成本加起來會很快變得昂貴。不幸的是，這對人工智能來說是不可避免的，儘管有一些方法可以緩解這種情況。
-
重用會話。你的 Fleet 會根據負載成比例地擴展與縮小，因此你的目標是將運行推理所需時間最小化，以便容器可以騰出時間來處理另一個請求。一種方法是重用
tf.Session和tf.Graph，一旦初始化後就存儲它們並將其作爲全局變量進行傳遞。這就會減少 TF 啓動會話和構建圖所需的時間，從而大大加快推理任務的速度。這一方法即使在單個容器上也有效，並且被廣泛用作最小化資源重新分配和最大化效率的技術。 -
緩存輸入，如果可能，也緩存輸出。在人工智能中，動態編程範式最爲重要；通過緩存輸入，可以節約預處理或從遠程獲取所需的時間，而通過緩存輸出，可以節約運行推理所需的時間。這些都可以在 Python 中輕鬆完成， 但你應該問問自己它是否適合你的用例 。通常情況下，模型會隨着時間的推移而變好，這將極大地影響你的輸出緩存機制。在我自己的系統中，我喜歡使用所謂的 “80-20” 規則。當模型的準確率低於 80% 時，我不會緩存任何輸出。一旦達到 80%，我就開始緩存，並在某個準確度將緩存設置爲過期（而不是在某個時間點設置爲過期）。這樣，隨着模型變得更爲準確，輸出也將會發生變化，但在這個 “80-20” 規則減輕的緩存中，性能和速度之間的權衡較少。
-
使用任務隊列。通常來說，需要運行的推理任務有大一些的，也有小一些的（在我們的例子中，既有大一些的，也有小一些的，還有複雜的和簡單的圖）。就用戶體驗來說，這裏使用堆隊列並優先處理較小的任務可能會更好，這樣運行一個簡單步驟的用戶只需等待該步驟即可，而無需等待先完成另一個用戶的更大推理。（你肯定會想，爲什麼這裏就不能使用橫向擴展呢？不是不可以，而是這樣一來會增加成本）
-
在具有任務隊列的專用 GPU 上訓練模型。訓練模型是一項長期而艱鉅的任務，它需要大量的資源使用，並且模型在其持續期間內無法使用。如果你要將每個交互反饋到模型中進行訓練，請考慮在單獨的服務器上運行，也許還要使用 GPU。一旦訓練完成之後，你可以將模型（在 AWS 中，可以將模型存儲庫集中在 S3 中）部署到容器中去。
結語
經過深思熟慮，我們提出了一個大規模部署人工智能的有效工作流程：
- 固化圖，並在 API 之下封包推理
- 重用會話和圖，並緩存輸入和輸出
- 使用 Docker（包括 API 層）將應用程序進行容器化
- 使用 Kubernetes 在你所選擇的雲端上大規模部署應用程序
- 從推理中分離訓練
- 開發任務隊列確定處理較小的任務的優先級
使用這些技術，你應該能夠以最小的成本和開銷進行部署，同時最大限度地提高速度和效率！
原文鏈接： https://towardsdatascience.com/scaling-ai-2be294368504