面對線上推理服務使用的GPU資源不斷增加、GPU利用率普遍較低的挑戰，美團視覺研發團隊決定透過模型結構拆分和微服務化進行最佳化，他們提出一種通用高效的部署架構，來解決這種常見的效能瓶頸問題。以“影像檢測+分類”服務為例，最佳化後的服務壓測效能指標GPU利用率由40%提升至100%，QPS也提升超過3倍。本文將會重點介紹推理服務部署架構最佳化的工程實踐，希望對大家能有所幫助或啟發。
0. 導讀
美團視覺面向本地生活服務，在眾多場景上落地應用了文字識別、影像質量評價、影片理解等視覺AI技術。此前，線上推理服務使用的GPU資源不斷增加，但服務GPU利用率普遍較低，浪費大量計算資源，增加了視覺AI應用成本，這是美團也是很多企業亟需解決的問題。
美團視覺智慧部透過實驗分析發現，造成視覺推理服務GPU利用率低下的一個重要原因是模型結構問題：模型中預處理或者後處理部分CPU運算速度慢，導致推理主幹網路無法充分發揮GPU運算效能。基於此，視覺研發團隊透過模型結構拆分和微服務化，提出一種通用高效的部署架構，解決這種常見的效能瓶頸問題。
目前，該解決方案已經在多個核心服務上成功應用。以“影像檢測+分類”服務為例，最佳化後的服務壓測效能指標GPU利用率由40%提升至100%，QPS提升超過3倍。本文將會重點介紹推理服務部署架構最佳化的工程實踐，希望對從事相關工作的同學們有所幫助或啟發。
1. 背景
隨著越來越多的AI應用進入生產應用階段，推理服務所需要的GPU資源也在迅速增加。調研資料表明，國內AI相關行業推理服務的資源使用量佔比已經超過55%，且比例未來還會持續升高。但很多公司面臨的實際問題是，線上推理服務GPU利用率普遍較低，還具備很大的提升空間。
而造成服務GPU利用率低的重要原因之一是：推理服務本身存在效能瓶頸，在極限壓力情況下也無法充分利用GPU資源。在這種背景下，“最佳化推理服務效能、提高GPU資源使用效率、降低資源使用成本”具有非常重要的意義。本文主要介紹如何透過架構部署最佳化，在保證準確率、推理時延等指標的前提下，提升推理服務的效能和GPU利用率。
2. 視覺模型服務的特點與挑戰
近年來，深度學習方法在計算機視覺任務上取得顯著進展，已經成為主流方法。視覺模型在結構上具有一些特殊性，如果使用現有推理框架部署，服務在效能和GPU利用率方面可能無法滿足要求。
2.1 模型最佳化工具與部署框架
深度學習模型部署前通常會使用最佳化工具進行最佳化，常見的最佳化工具包括TensorRT、TF-TRT、TVM和OpenVINO等。這些工具透過運算元融合、動態視訊記憶體分配和精度校準等方法提高模型執行速度。模型部署是生產應用的最後一環，它將深度學習模型推理過程封裝成服務，內部實現模型載入、模型版本管理、批處理以及服務介面封裝等功能，對外提供RPC/HTTP介面。業界主流的部署框架有以下幾種：
- TensorFlow Serving：TensorFlow Serving（簡稱TF-Serving）是Google釋出用於機器學習模型部署的高效能開源框架，內部整合了TF-TRT最佳化工具，但是對非TensorFlow格式的模型支援不夠友好。
- Torch Serve：TorchServe是AWS和Facebook聯合推出的Pytorch模型部署推理框架，具有部署簡單、高效能、輕量化等優點。
- Triton：Triton是Nvidia釋出的高效能推理服務框架，支援TensorFlow、TensorRT、PyTorch和ONNX等多種框架模型，適用於多模型聯合推理場景。
在實際部署中，無論選擇哪種框架，需要同時考慮模型格式、最佳化工具、框架功能特點等多種因素。
2.2 視覺模型特點
與傳統方法不同， 深度學習是一種端到端的方法，不需要單獨設計特徵提取、分類器等模組，用單個模型取代傳統方法多模組任務。深度學習模型在分類、檢測、分割、識別等視覺任務上呈現出巨大優勢，做到了傳統方法無法達到的精度。常用的視覺分類模型（如ResNet、GoogleNet等）和檢測模型（如YOLO、R-FCN等）具有如下特點：
- 網路層數多（適合用GPU運算）：以ResNet-50為例，網路包含49個卷積層和1個全連線層，引數量高達2千5百萬，計算量達到38億FLOPs（浮點運算數）。模型推理包含大量矩陣計算，適合用GPU並行加速。
- 輸入影像尺寸固定（需要預處理）：同樣以ResNet-50為例，網路的輸入是影像浮點型別矩陣，尺寸大小固定為224x224。因此二進位制編碼圖片在送入網路前，需要做解碼、縮放、裁切等預處理操作。
2.3 視覺推理服務面臨的問題與挑戰
由於視覺模型存在的上述特點，導致模型在部署和最佳化上存在2個問題：
- 模型最佳化不徹底：TensorRT、TF-TRT等工具主要針對主幹網路最佳化，但忽略了預處理部分，因此整個模型最佳化並不充分或者無法最佳化。例如分類模型中ResNet-50所有網路層都可以被最佳化，但預處理中的影像解碼（通常是CPU運算）操作"tf.image.decode"會被TF-TRT忽略跳過。
- 多模型部署困難：視覺服務經常存在組合串接多個模型實現功能的情況。例如在文字識別服務中，先透過檢測模型定位文字位置，然後裁切文字所在位置的區域性圖片，最後送入識別模型得到文字識別結果。服務中多個模型可能採用不同訓練框架，TF-Serving或Troch Serve推理框架只支援單一模型格式，無法滿足部署需求。Triton支援多種模型格式，模型之間的組合邏輯可以透過自定義模組（Backend）和整合排程（Ensemble）方式搭建，但實現起來較為複雜，並且整體效能可能存在問題。
這兩點常見的模型部署問題，導致視覺推理服務存在效能瓶頸、GPU利用率低，即便Triton這種高效能部署框架也難以解決。
通用部署框架重點關注的是“通訊方式、批處理、多例項”等服務託管方面的效能問題，但如果模型本身中間某個部分（如影像預處理或後處理）存在瓶頸，最佳化工具也無法最佳化，就會出現“木桶效應”，導致整個推理過程效能變差。因此，如何最佳化推理服務中的模型效能瓶頸，仍然是一件重要且具有挑戰性的工作。
3. GPU服務最佳化實踐
分類和檢測是兩種最基礎的視覺模型，常應用在影像稽核、影像標籤分類和人臉檢測等場景。下面以兩個典型服務為案例，單個分類模型和“分類+檢測”多模型組合的使用情況，來介紹具體效能的最佳化過程。
3.1 影像分類模型服務最佳化
美團每天有千萬量級的圖片需要稽核過濾有風險內容，人工稽核成本太高，需要藉助影像分類技術實現機器自動稽核。常用的分類模型結構如圖1，其中預處理部分主要包括“解碼、縮放、裁切”等操作，主幹網路是ResNet-50。預處理部分接收影像二進位制流，生成主幹網路需要的矩陣資料Nx3x224x224（分別代表圖片數量、通道數、影像高度和影像寬度 ），主幹網路預測輸出圖片分類結果。
模型經過TF-TRT最佳化後的實際結構如下圖2所示，主幹網路ResNet被最佳化為一個Engine，但預處理部分的運算元不支援最佳化，所以整個預處理部分仍然保持原始狀態。
3.1.1 效能瓶頸
模型經過TF-TRT最佳化後使用TF-Serving框架部署，服務壓測GPU利用率只有42%，QPS與Nvidia官方公佈的資料差距較大。排除TF-TRT和Tensorflow框架等可能影響的因素，最終聚焦在預處理部分。Nvidia進行效能測試的模型沒有預處理，直接輸入Nx3x224x224矩陣資料。但這裡的線上服務包含了預處理部分，壓測指標CPU利用率偏高。檢視模型中各個運算元的執行裝置，發現模型預處理大部分是CPU運算，主幹網路是GPU運算（具體細節參見圖1）。
如下圖3所示，透過NVIDIA Nsight System（nsys）工具檢視模型執行時的CPU/GPU執行情況，可以發現GPU執行有明顯間隔，需要等待CPU資料準備完成並複製到GPU上，才能執行主幹網路推理運算，CPU處理速度慢導致GPU處於飢餓狀態。結合服務壓測的CPU/GPU利用率資料可以看出：預處理部分CPU消耗高、處理速度慢，是推理服務的效能瓶頸。
3.1.2 最佳化方法
如下圖4所示，針對預處理CPU消耗過高影響推理服務效能的問題，提出幾種最佳化方法：
- 增加CPU：增加機器CPU數量是最簡單的做法，但是受限於伺服器硬體配置，1個GPU通常只配置8個CPU。所以增加CPU的方法只能用於效能測試資料對比，無法實際應用部署。
- 前置預處理：大尺寸圖片的解碼、縮放操作CPU消耗較高，相較而言小尺寸圖片的處理速度會快很多。因此考慮對輸入圖片提前進行預處理，將預處理後的小圖再送入服務。經過驗證Tensorflow中縮放、裁切操作具有疊加不變性，即多次操作和單次操作對最終結果沒有影響。預處理後的小影像經過編碼後，再送入原始分類服務。需要注意的是影像編碼必須選擇無損編碼（如PNG），否則會導致解碼資料不一致，引起預測誤差。前置預處理方式的優點是不需要修改原始模型服務，可操作性高、預測結果沒有誤差。缺點是需要重複預處理，導致整體流程時延增加、CPU資源浪費。
- 分離預處理：另外一種思路是將模型預處理部分和主幹網路拆分，預處理部分單獨部署到CPU機器上，主幹網路部署到GPU機器上。這種做法讓CPU預處理服務可以水平無限擴容，滿足GPU處理資料供給，充分利用GPU效能。更重要的是將CPU和GPU運算進行解耦，減少了CPU-GPU資料交換等待時間，理論上比增加CPU數量效率更高。唯一需要考慮的是服務間的通訊效率和時間，裁切後影像大小為224x224x3，採用無符號整型型別資料大小是143KB，傳輸時間和頻寬在1萬QPS以下沒有問題。
3.1.3 最佳化結果
如下圖5所示，我們利用NVIDIA Nsight System，對比上述幾種方法最佳化後的模型執行情況。增加CPU和前置預處理的方法都可以縮短CPU預處理時間，減少GPU資料等待時間，提升GPU利用率。但相較而言，分離預處理的方法最佳化更加徹底，CPU到GPU的資料複製時間最短，GPU利用最為充分。
各種方法最佳化後的線上服務壓測效能結果見下圖6（其中前置預處理和分離預處理中的CPU預處理服務額外使用16個CPU），機器配置的CPU型號是Intel(R) Xeon(R) Gold 5218 CPU@2.30GHz、GPU型號是Tesla T4。從壓測結果可以看出：
- 服務CPU增加到32核，QPS和GPU利用率（透過
nvidia-smi命令獲取的GPU-Util指標）提升超過1倍，GPU利用率提升至88%； - 前置預處理方法最佳化後服務QPS提升超過1倍，略優於增加CPU的方法，但從GPU利用率角度看仍有較大最佳化空間；
- 分離預處理方法最佳化後QPS提升2.7倍，GPU利用率達到98%接近滿載狀態。
增加CPU並不能完全解決服務效能瓶頸問題，雖然GPU利用率達到88%，但是CPU-GPU資料傳輸時間佔比較大，QPS提升有限。前置預處理方法也沒有完全解決預處理效能瓶頸問題，最佳化並不徹底。相較而言，分離預處理方法充分發揮了GPU運算效能，在QPS和GPU利用率指標上都取得了更好的最佳化效果。
3.2 影像“檢測+分類”模型服務最佳化
在一些複雜任務場景下（如人臉檢測識別、影像文字識別等），通常是檢測、分割、分類等多個模型組合實現功能。本節介紹的模型便是由“檢測+分類”串接而成，模型結構如下圖7所示，主要包括以下幾個部分：
- 預處理：主要包括影像解碼、縮放、填充等操作，輸出Nx3x512x512影像矩陣，大部分運算元執行在CPU裝置上。
- 檢測模型：檢測網路結構是YOLOv6，運算元執行裝置為GPU。
- 檢測後處理：使用NMS（非極大值抑制）演算法去除重複或誤檢目標框，得到有效檢測框，然後裁切目標區域子圖並縮放，輸出Nx3x224x224影像矩陣，檢測後處理大部分運算元執行在CPU裝置上。
- 分類模型：分類網路結構是ResNet-50，運算元執行裝置為GPU。
其中檢測和分類兩個子模型是單獨訓練的，推理時合併成單個模型，部署框架採用TF-Serving，最佳化工具採用TF-TRT。
3.2.1 效能瓶頸
模型中預處理和檢測後處理大部分是CPU運算，檢測和分類模型主幹網路是GPU運算，單次推理過程中需要進行多次CPU-GPU之間資料交換。同樣地，CPU運算速度慢會導致GPU利用率低，推理服務存在效能瓶頸。
實際線上服務壓測GPU利用率68%，QPS也存在較大最佳化空間。服務配置為1GPU+8CPU（機器CPU型號是Intel(R) Xeon(R) Gold 5218 CPU@2.30GHz，GPU型號是Tesla T4）。
3.2.2 最佳化方法
仍然採用模型拆分的思路，將CPU和GPU運算部分單獨部署微服務。如下圖8所示，我們將原始模型拆分為4個部分，預處理和檢測後處理部署成CPU微服務（可根據流量大小動態擴容），檢測模型和分類模型部署成GPU微服務（同一張GPU卡上）。為了保持呼叫方式簡單，上層採用排程服務串接各個微服務，提供統一呼叫介面，對上游遮蔽呼叫差異。拆分後的檢測模型和分類模型經過TensorRT最佳化後採用Triton部署。
3.2.3 最佳化結果
如下圖9所示，除了原始服務和微服務拆分，另外還對比了增加CPU和Triton Ensemble兩種方式的效能測試結果。Triton Ensmeble方式將所有子模型（包括預處理和後處理）部署在一個機器上，實現多模型流水線排程。對比可以看出：
- 原始服務CPU增加到32核，GPU利用率提升到90%，但QPS提升只有36%；
- Triton Ensemble方式與原始TF-Serving服務相比效能差距不大；
- 模型拆分微服務方式最佳化後QPS提升3.6倍，GPU利用率達到100%滿載狀態。
增加CPU的方法對服務GPU利用率提升較大、QPS提升不明顯，原因在於CPU預處理和後處理時間縮短，但CPU-GPU資料傳輸時間在整個推理過程中仍然佔比較大，GPU運算時間較少。
將模型拆分使用Triton Ensmeble方式部署實現多模型排程流水線，效率並不比模型拆分前高。因為多模型流水線是在同一臺機器上，CPU和GPU相互影響的問題並沒有解決，GPU處理效率受CPU制約。模型拆分微服務部署方式在服務層面實現了呼叫流水線，CPU預處理和後處理微服務可以根據流量動態增加資源，滿足GPU模型微服務吞吐需求，實現了GPU/CPU處理解耦，避免了CPU處理成為瓶頸。
總而言之，拆分微服務的方式充分發揮了GPU運算效能，在QPS和GPU利用率指標上都取得了更好的效果。
4. 通用高效的推理服務部署架構
除了上述兩個具有代表性的推理服務最佳化案例，視覺其它很多服務也採用了這種最佳化方式。這種最佳化方式具有一個核心思想：在CPU運算是瓶頸的推理服務中，將模型的CPU和GPU運算部分拆分，單獨部署成CPU/GPU微服務。
根據這種思想，我們提出一種通用高效的推理服務部署架構。如下圖10所示，底層使用通用的部署框架（TF-Serving/Triton等），將模型中CPU運算部分如預處理、後處理拆分單獨部署成CPU微服務，主幹網路模型部署成GPU服務，上層排程服務串聯模型微服務實現整體功能邏輯。
這裡需要解釋一個重要問題，為什麼這種部署架構是高效的？
首先在宏觀層面，模型拆分部署成微服務，透過排程服務實現了子模型流水線處理。拆分的子模型CPU微服務可以根據流量和處理能力動態擴容，避免模型預處理或後處理CPU運算能力不足成為效能瓶頸，滿足了GPU模型微服務的吞吐需求。
其次在微觀層面，如果模型包含多個CPU/GPU運算部分，那麼GPU運算之間會存在間隔。如下圖11所示，單次推理過程中兩次GPU運算之間需要等待CPU後處理部分完成，CPU預處理也會影響GPU運算。模型拆分後，預處理和後處理部分獨立部署成CPU服務，GPU服務中推理過程僅包含兩個子模型運算部分，並且子模型間運算相互獨立無資料關聯，CPU-GPU資料傳輸部分可以與GPU運算過程並行，理論上GPU可以達到100%執行效率。
另外，在時延方面，拆分微服務的部署方式增加了RPC通訊和資料複製時間開銷，但從實踐來看這部分時間佔比很小，對端到端的延遲沒有顯著影響。例如對於上面3.1節中的分類模型，最佳化前服務的平均耗時是42ms，最佳化後微服務形式（RPC通訊協議為Thrift）的服務整體平均耗時是45ms。對於大部分視覺服務應用場景而言，這種級別的延遲增加通常並不敏感。
5. 總結與展望
本文以兩個典型的視覺推理服務為案例，介紹了針對模型存在效能瓶頸、GPU利用率不高的問題進行的最佳化實踐，最佳化後服務推理效能提升3倍左右，GPU利用率接近100%。根據最佳化實踐，本文提出了一種通用高效的推理服務部署架構，這種架構並不侷限於視覺模型服務，其它領域的GPU服務也可參考應用。
當然，這種最佳化方案也存在一些不足，比如最佳化過程中模型如何拆分比較依賴人工經驗或者實驗測試，沒有實現最佳化流程的自動化與標準化。後續我們計劃建設模型效能分析工具，自動診斷模型瓶頸問題，支援自動拆分最佳化全流程。
6. 作者
| 張旭、趙錚、岸青、林園、志良、楚怡等，來自基礎研發平臺視覺智慧部。
| 曉鵬、駃飛、松山、書豪、王新等，來自基礎研發平臺資料科學與平臺部。
閱讀美團技術團隊更多技術文章合集
前端 | 演算法 | 後端 | 資料 | 安全 | 運維 | iOS | Android | 測試
| 在公眾號選單欄對話方塊回覆【2022年貨】、【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可檢視美團技術團隊歷年技術文章合集。
| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請傳送郵件至tech@meituan.com申請授權。