使用函數計算三步實現深度學習 AI 推理在線服務

目前深度學習應用廣發， 其中 AI 推理的在線服務是其中一個重要的可落地的應用場景。本文將爲你們介紹使用函數計算部署深度學習 AI 推理的最佳實踐,  其中包括使用 FUN 工具一鍵部署安裝第三方依賴、一鍵部署、本地調試以及壓測評估， 全方位展示函數計算的開發敏捷特性、自動彈性伸縮能力、免運維和完善的監控設施。

1.1 DEMO 概述

經過上傳一個貓或者狗的照片， 識別出這個照片裏面的動物是貓仍是狗

• DEMO 示例效果入口： http://sz.mofangdegisn.cn
• DEMO 示例工程地址： https://github.com/awesome-fc/cat-dog-classify

開通服務

免費開通函數計算， 按量付費，函數計算有很大的免費額度。

免費開通文件存儲服務NAS， 按量付費

1.2 解決方案

如上圖所示， 當多個用戶經過對外提供的 url 訪問推理服務時候，每秒的請求幾百上千都沒有關係， 函數計算平臺會自動伸縮， 提供足夠的執行實例來響應用戶的請求， 同時函數計算提供了完善的監控設施來監控您的函數運行狀況。

1.3. Serverless 方案與傳統自建服務方案對比

1.3.1 卓越的工程效率

	自建服務	函數計算 Serverless
基礎設施	須要用戶採購和管理	無
開發效率	除了必要的業務邏輯開發,須要本身創建相同線上運行環境， 包括相關軟件的安裝、服務配置、安全更新等一系列問題	只須要專一業務邏輯的開發, 配合 FUN 工具一鍵資源編排和部署
學習上手成本	可能使用 K8S 或彈性伸縮( ESS )，須要瞭解更多的產品、名詞和參數的意義	會編寫對應的語言的函數代碼便可

1.3.2 彈性伸縮免運維

	自建服務	函數計算 Serverless
彈性高可用	須要自建負載均衡 (SLB)，彈性伸縮，擴容縮容速度較 FC 慢	FC系統固有毫秒級別彈性伸縮，快速實現底層擴容以應對峯值壓力，免運維
監控報警查詢	ECS 級別的 metrics	提供更細粒度的函數執行狀況，每次訪問函數執行的 latency 和日誌等， 更加完善的報警監控機制

1.3.3 更低的成本

• 函數計算 (FC) 固有自動伸縮和負載均衡功能，用戶不須要購買負載均衡 (SLB) 和彈性伸縮。
• 具備明顯波峯波谷的用戶訪問場景(好比只有部分時間段有請求，其餘時間甚至沒有請求)，選擇按需付費，只需爲實際使用的計算資源付費。

對於明顯波峯波谷或者稀疏調用具備低成本優點， 同時還保持了彈性能力，之後業務規模作大之後並無技術切換成本，同時財務成本增加配合預付費也能保持平滑。

• 部分請求持續平穩的場景下,能夠配合預付費解決按需付費較高單價問題。函數計算成本優化最佳實踐文檔。

假設有一個在線計算服務，因爲是CPU 密集型計算， 所以在這裏咱們將平均 CPU 利用率做爲核心參考指標對成本，以一個月爲週期，10臺 C5 ECS 的總計算力爲例，總的計算量約爲 30% 場景下， 各解決方案 CPU 資源利用率使用狀況示意圖大體以下:

由上圖預估出以下計費模型：

• 函數計算預付費 3CU 一個月: 246.27 元， 計算能力等價於 ECS 計算型 C5
• ECS 計算型 C5 (2vCPU,4GB)+雲盤: 包月219 元，按量: 446.4 元
• 包月10 Mbps 的 SLB: 526.52 元(這裏作了必定的流量假設)， 彈性伸縮免費
• 飽和使用下，函數計算按量付費的一臺機器成本約爲按量付費 C5 ECS 的2 倍

	平均CPU利用率	計算費用	SLB	總計
函數計算組合付費	>=80%	738+X（246.27*3+X）	無	<= 738+X
按峯值預留ECS	<=30%	2190（10*219）	526.52	>=2716.52
彈性伸縮延遲敏感	<=50%	1314（102193/5）	526.52	>= 1840.52
彈性伸縮成本敏感	<=70%	938.57 (102193/7)	526.52	>= 1465.09

注：

1. 這裏假設函數邏輯沒有公網公網下行流量費用， 即便有也是一致的， 這裏成本比較暫不參與

2. 延時敏感，當 CPU 利用率大於等於 50% 就須要開始進行擴容，否則更來不及應對峯值

3. 成本敏感，當 CPU 利用率大約 80% 即開始進行擴容， 能容受必定概率的超時或者5XX

上表中， 其中函數計算組合付費中的 X 爲按需付費的成本價，假設按需付費的計算量佔整個計算量的 10%，假設 CPU 利用率爲100%,  對應上表，那麼須要 3 臺 ECS 的計算能力便可。所以 FC 按量付費的成本 X = 3 ️446.4 ️ 10% ️ 2 =  267.84 （ FC 按量付費是按量 ECS 的2倍），這個時候函數計算組合付費總計  1005.8 元。 在這個模型預估裏面， 只要 FC 按量付費佔整個計算量小於 20%， 即便不考慮 SLB, 單純考慮計算成本， 都是有必定優點的。

1.3.4. 小結

基於函數計算進行 AI 推理等 CPU 密集型的主要優點：

1. 上手簡單， 只專一業務邏輯開發， 極大提升工程開發效率。
   • 自建方案有太多學習和配置成本，如針對不一樣場景，ESS 須要作各類不一樣的參數配置
   • 系統環境的維護升級等
2. 免運維，函數執行級別粒度的監控和告警。
3. 毫秒級彈性擴容，保證彈性高可用，同時能覆蓋延遲敏感和成本敏感類型。
4. 在 CPU 密集型的計算場景下， 經過設置合理的組合計費模式， 在以下場景中具備成本優點：
   • 請求訪問具備明顯波峯波谷， 其餘時間甚至沒有請求
   • 有必定穩定的負載請求， 可是有部分時間段請求量突變劇烈

打包代碼ZIP包和部署函數

FUN 操做簡明視頻教程

開通服務

免費開通函數計算， 按量付費，函數計算有很大的免費額度。

免費開通文件存儲服務NAS， 按量付費

2.1 安裝第三方包到本地並上傳到NAS

2.1.1 安裝最新的Fun

• 安裝版本爲8.x 最新版或者10.x 、12.x nodejs
• 安裝 funcraf

2.1.2 Clone 工程 & Fun 一鍵安裝第三方庫到本地

• git clone https://github.com/awesome-fc/cat-dog-classify.git
• 複製 .env_example 文件爲 .env, 而且修改 .env 中的信息爲本身的信息
• 執行 fun install -v,  fun 會根據 Funfile 中定義的邏輯安裝相關的依賴包

root@66fb3ad27a4c: ls .fun/nas/auto-default/classify
model  python
root@66fb3ad27a4c: du -sm .fun
697     .fun

根據 Funfile 的定義：

• 將第三方庫下載到 .fun/nas/auto-default/classify/python 目錄下
• 本地 model 目錄移到 .fun/nas/auto-default/model 目錄下

安裝完成後，從這裏咱們看出， 函數計算引用的代碼包解壓以後已經達到了 670 M, 遠超過 50M 代碼包限制, 解決方案是 NAS 詳情能夠參考:  掛載NAS訪問，幸運的是 FUN 工具一鍵解決了 nas 的配置和文件上傳問題。

2.1.3. 將下載的依賴的第三方代碼包上傳到 NAS

fun nas init
fun nas info
fun nas sync
fun nas ls nas://classify:/mnt/auto/

依次執行這些命令，就將本地中的 .fun/nas/auto-default 中的第三方代碼包和模型文件傳到 NAS 中, 依次看下這幾個命令的作了什麼事情:

• fun nas init: 初始化 NAS, 基於您的 .env 中的信息獲取(已有知足條件的nas)或建立一個同region可用的nas
• fun nas info: 能夠查看本地 NAS 的目錄位置, 對於此工程是 $(pwd)/.fun/nas/auto-default/classify
• fun nas sync: 將本地 NAS 中的內容（.fun/nas/auto-default/classify）上傳到 NAS 中的 classify 目錄
• fun nas ls nas:///mnt/auto/: 查看咱們是否已經正確將文件上傳到了 NAS

登陸 NAS 控制檯 https://nas.console.aliyun.com 和 VPC 控制檯 https://vpc.console.aliyun.com<br />能夠觀察到在指定的 region 上有 NAS 和 相應的 vpc 建立成功

2.2 本地調試函數

在 template.yml 中， 指定了這個函數是 http 類型的函數， 因此根據 fun 的提示:

Tips for next step
======================
* Invoke Event Function: fun local invoke
* Invoke Http Function: fun local start
* Build Http Function: fun build
* Deploy Resources: fun deploy

執行 fun local start,  本地就會啓動一個 http server 來模擬函數的執行， 而後咱們 client 端可使用 postman， curl 或者瀏覽器， 好比對於本例：

2.3 部署函數到FC平臺

本地調試OK 後，咱們接下來將函數部署到雲平臺：

修改 template.yml LogConfig 中的 Project, 任意取一個不會重複的名字便可，有兩處地方須要更改，而後執行

fun deploy

注意:  template.yml 註釋的部分爲自定義域名的配置, 若是想在 fun deploy 中完成這個部署工做:

• 先去域名解析, 好比在示例中, 將域名 sz.mofangdegisn.cn 解析到 123456.cn-hangzhou.fc.aliyuncs.com, 對應的域名、accountId 和 region 修改爲本身的
• 去掉 template.yml 中的註釋, 修改爲本身的域名
• 執行 fun deploy

這個時候若是沒有自定義域名， 直接經過瀏覽器訪問訪問http trigger 的url， 好比 https://123456.cn-shenzhen.fc.aliyuncs.com/2016-08-15/proxy/classify/cat-dog/ 會被強制下載.

緣由:https://help.aliyun.com/knowledge_detail/56103.html#HTTP-Trigger-compulsory-header

登陸控制檯https://fc.console.aliyun.com，能夠看到service 和 函數已經建立成功， 而且 service 也已經正確配置。

在這裏，咱們發現第一次打開頁面訪問函數的時候，執行環境實例冷啓動時間很是長， 若是是一個在線AI推理服務，對響應時間很是敏感，冷啓動引發的毛刺對於這種類型的服務是不可接受的，接下來，本文講解如何利用函數計算的預留模式來消除冷啓動帶來的負面影響。

使用預留模式消除冷啓動毛刺

函數計算具備動態伸縮的特性， 根據併發請求量，自動彈性擴容出執行環境來執行環境，在這個典型的深度學習示例中，import keras 消耗的時間很長 ， 在咱們設置的 1 G 規格的函數中， 併發訪問的時候耗時10s左右， 有時甚至20s+

start = time.time()
from keras.models import model_from_json
print("import keras time = ", time.time()-start)

3.1 函數計算設置預留

預留操做簡明視頻教程

• 在 FC 控制檯，發佈版本，而且基於該版本建立別名 prod，而且基於別名 prod 設置預留, 操做過程請參考：https://help.aliyun.com/document_detail/138103.html
• 將該函數的 http trigger 和 自定義域名的設置執行 prod 版本
  

一次壓測結果

從上面圖中咱們能夠看出，當函數執行的請求到來時，優先被調度到預留的實例中被執行， 這個時候是沒有冷啓動的，因此請求是沒有毛刺的， 後面隨着測試的壓力不斷增大(峯值TPS 達到 1184), 預留的實例不能知足調用函數的請求， 這個時候函數計算就自動進行按需擴容實例供函數執行，此時的調用就有冷啓動的過程， 從上面咱們能夠看出，函數的最大 latency 時間甚至達到了 32s，若是這個web AP是延時敏感的，這個 latency 是不可接受的。

總結

• 函數計算具備快速自動伸縮擴容能力
• 預留模式很好地解決了冷啓動中的毛刺問題
• 開發簡單易上手，只須要關注具體的代碼邏輯， Fun 工具助您一鍵式部署運用
• 函數計算具備很好監控設施, 您能夠可視化觀察您函數運行狀況， 執行時間、內存等信息

有任何問題歡迎進掃碼進釘釘羣溝通

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」