怎樣搭建Serverless AI應用

本篇文章給大家分享的是有關怎樣搭建Serverless AI應用，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

向大家介紹一個典型函數計算的應用場景：AI Model Serving（AI 模型服務化）。

函數計算和 AI 推理

第一部分，我們簡單介紹一下什么是函數計算和 AI 推理。函數計算能為 AI 場景做些什么？

Serverless 分為 FaaS 和 BaaS，阿里云函數計算屬于 FaaS，是事件驅動的全托管計算服務。通過函數計算，您無需管理服務器等基礎設施，只需編寫代碼并上傳。函數計算會為您準備好計算資源，以彈性、可靠的方式運行您的代碼，并提供日志查詢、性能監控、報警等功能。

借助于函數計算，您可以快速構建任何類型的應用和服務，無需管理和運維。而且，您只需要為代碼實際運行所消耗的資源付費，代碼未運行則不產生費用。

如上圖所示：是一個完整的機器學習項目的工作流程。

工作流程可以分為三個部分：

• 首先對原始數據進行預處理；

• 然后將處理過的數據進行模型訓練，會選用不同的參數和算法組合進行多次訓練，形成多個備選模型；

• 最后選一個最合適的模型進行部署。

上述的 3 個步驟，前兩個步驟數據處理和模型訓練主要由數據科學工作者來完成。最后一步通常是應用開發者的工作。當一個 AI 模型被部署成正式的應用時，需要解決可用性、可靠性和可擴展性等應用開發領域的問題。

函數計算是事件觸發型計算服務，上游服務如 OSS、MNS 和 API Gateway 會觸發事件，事件會觸發函數運行，處理上游數據源的數據。這個機制可以用來做機器學習數據的預處理。

另一個函數計算適合 ML 的場景是適合做 AI Model Serving。上圖是一個圖片分類的示例，通過 TensorFlow 訓練的模型可以部署成函數。當一張新的圖片做出輸入通過 HTTP 協議發送給函數后，函數會返回對這張圖片的分類判斷。

3 步搭建自動生成五言絕句詩句應用

下面我們進入第二部分：快速部署一個 AI 應用。（更多詳細信息：https://developer.aliyun.com/article/741406）

函數支持靈活的調用，分為 GUI、CLI 和 SDK 三種方式：

• GUI 有 web 版本的控制臺和 IDE，也有本地的插件；

• CLI 我們推薦 Funcraft 工具，Funcraft 是個面向工程的開發工具，提供了模板向導、本地開發調試和部署運行等一些功能，Fcli 側重于對已部署云端的資源進行操作；

• SDK 方面，函數計算覆蓋了常見語言。

上圖右側是“為你寫詩”通過 fun 工具的調用效果。每次調用會返回當次執行的耗時和資源使用情況。返回結果就是由 AI 自動生成的詩句。

上圖是“為你寫詩”應用的工作原理圖。

首先是訓練模型，大概有 7 萬行五言絕句，通過 TensorFlow 的 CharRNN 訓練成模型；然后通過 Funcraft 工具安裝 TensorFlow 的 pip 包，用 python 寫好調用代碼。template.yml 是 ROS 的描述文件，以聲明式的方式來描述函數，然后通過 fun deploy 部署函數。

由于 Model 和 TensorFlow lib 會超過函數計算對于部署包 50M 的限制，Funcraft 工具會自動把這兩部分部署到 NAS 網盤（如果不存在會提示自動創建），然后運行時函數會像訪問本地文件系統一樣訪問 NAS 網盤上的模型和庫文件。

最后用戶通過調用函數返回自動生成的詩句。由于函數實例會按照請求量自動擴展，并且按照調用量進行收費，所以快速上線的 AI 服務是一個真實場景下高可用的服務。

要搭建該服務，首選需要安裝 git 和 funcraft 工具。funcraft 是一個 github 開源項目，大家可以在 https://github.com/alibaba/funcraft 找到各個平臺的安裝文件和指南。

然后只需要執行上圖中的三個步驟就可以快速地將“為你寫詩”應用部署到函數計算平臺。

函數計算在 AI 場景的優勢

最后一部分，我們會通過不同維度與傳統架構對比的方式來總結一下函數計算在 AI 場景的優勢。

首先我們看一下函數計算的工程效率：

• 相比于自建服務（ECS 或者 K8s 集群），函數計算不需要維護基礎設施（主機、網絡、存儲等）；

• 在開發效率上，函數計算通過這些年在 Funcraft 和 VSCode 等工具的建設，解決了應用構建、開發調試和打包部署一系列的痛點，用戶可以平滑的上手，通過模板快速部署和二次開發應用；

• 學習成本上方面，由于函數計算實現了分布式應用的細節，所以只需要專心于實現一個單體應用，更專注于業務。

相比于 ECS 和容器服務，函數計算的彈性更好，支持百毫秒級的彈性，可以更好的應對業務的實時波動。同時也提供了細粒度的、開箱即用的監控報警模塊。

上圖是一些監控圖表，用戶可以通過可視化界面直觀地理解應用的監控狀況。

下面我們來看看一個可用性的對比實驗，假設存在上圖中的三個 AI 場景：

• 第一個是部署在 ECS 上的延時敏感應用；

• 第二個是部署在 ECS 上的成本敏感應用；

• 第三個是 FC 方案，由于 FC 默認提供了 MKL 加速，所以這也是 FC 的一個小優勢。

• 場景一出現了很多超時或者 5xx 錯誤，擴容速度太慢， 理論上需要 4 分鐘及以上才能擴容：觸發報警 3*1min + 購買啟動 ECS(1-5min) > 4 min； 同時縮容速度更慢， 只有觸發報警 15 * 1min，當然您可以調整觸發報警的時間間隔，但是云監控總是分鐘級別的粒度，而且設置的值太小，頻繁的采購和釋放 ECS 并不是一個推薦的操作， 這也是官方推薦擴容是 3 分鐘， 縮容 15 分鐘的原因；

• 場景二在壓力忽然上升的時候仍然由于擴容不及時導致的 5xx， 同時實例數目圖可以看出分鐘級別的擴容和縮容速度的滯后在這種場景下可能會嚴重影響用戶體驗；

• 場景三壓力和壓力的變化明顯大于自建 ECS + SLB + ESS 方案，但沒有錯誤，響應時間基本穩定在 200-300ms， 除了冷啟動有點毛刺以外。 但是毛刺的最大時間也沒有超過 2s：MKL 加速， 單次運算時間短；快速彈性縮容，壓力陡升驟降都能快速伸縮，提高資源的使用效率。

不管是延遲敏感型和成本敏感型， FC 都能很好解決快速響應的問題， 冷啟動的毛刺可以通過預留實例+預付費去解決。

解決函數冷啟動毛刺問題有兩條思路：減少單次啟動時間和預先啟動（預熱）。

首先談談如何縮短函數的啟動時間。函數的啟動時間分為兩部分：一部分是由平臺負責的，包括代碼下載、容器啟動、運行時初始化和代碼初始化；另一部分是由用戶負責的代碼部分，這部分往往由于業務的不同比較難優化。

關于預啟動函數的方式，函數計算 1.0 的時候，會推薦用戶使用 Time Trigger 定時觸發函數讓函數保持住而不被回收。函數計算 2.0 推出了函數的預留模式。通過預留模式，用戶可以讓函數一直保持住而不回收。

下面我們針對預留模式做一組對比試驗。

• 場景一：當函數執行的請求到來時，由于沒有任何預留資源，所有的請求都是按需， 所以每次壓力一增大，就會有很多冷啟動的，請求毛刺很多，毛刺的時間達到 20s+；

• 場景二：當函數執行的請求到來時，由于預留資源充足，所有的請求都被調度到預留的實例中被執行， 這個時候是沒有冷啟動的，所以請求是沒有毛刺的；

• 場景三：當函數執行的請求到來時，優先被調度到預留的實例中被執行， 這個時候是沒有冷啟動的，所以請求是沒有毛刺的， 后面隨著測試的壓力不斷增大(峰值 TPS 達到 1184), 預留的實例不能滿足調用函數的請求， 這個時候函數計算就自動進行按需擴容實例供函數執行，此時的調用就有冷啟動的過程， 從上圖我們可以看出，函數的最大 latency 時間甚至達到了 32s，如果這個 web AP 是延時敏感的，這個 latency 是不可接受的。

上圖中的 4 個小圖描繪了不同場景下的資源利用率和成本的關系。

• 圖 1：按照峰值進行 ECS 實例預留，資源利用率小于 30%；

• 圖 2：延遲敏感，資源利用率小于 50%；

• 圖 3：成本敏感，相應的會犧牲一些相應性，資源利用率小于 70%；

• 圖 4：基于預留模式+預付費，把彈性的部分使用函數的按量模式，資源的利用率可以做到 80% 以上。

上面四個 Case 的成本核算，最終函數計算組合付費模式的成本最低。

以上就是怎樣搭建Serverless AI應用，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。