1背景

隨著CV演算法在業務場景中使用越來越多，給我們帶來了新的挑戰，需要提升Python推理服務的效能以降低生產環境成本。為此我們深入去研究Python GPU推理服務的工作原理，推理模型優化的方法。最終通過兩項關鍵的技術: 1.Python的GPU與CPU程序分離，2.使用TensorRT對模型進行加速，使得線上大部分模型服務QPS提升5-10倍左右，大量節約了線上GPU推理服務的成本。

針對上面的兩項關鍵技術，我們還自研了相關框架與工具進行沉澱。包括基於Python的CPU與GPU程序自動隔離的推理服務框架，以及對推理模型進行轉TensorRT優化的除錯工具。

此外針對不同的推理服務效能瓶頸，我們還梳理了各種實戰優化技巧，比如CPU與GPU分離，TensorRT開啟半精度優化，同模型混合部署，GPU資料傳輸與推理並行等。

下面從理論，框架與工具，實戰優化技巧三個方面介紹下推理服務效能優化的方法。

2理論篇

2.1 CUDA架構

CUDA 是 NVIDIA 發明的一種平行計算平臺和程式設計模型。它通過利用圖形處理器 (GPU) 的處理能力，可大幅提升計算效能。

CUDA的架構中引入了主機端（host, cpu）和裝置（device, gpu）的概念。CUDA的Kernel函式既可以執行在主機端，也可以執行在裝置端。同時主機端與裝置端之間可以進行資料拷貝。

CUDA Kernel函式：是資料並行處理函式（核函式)，在GPU上執行時，一個Kernel對應一個Grid，基於GPU邏輯架構分發成眾多thread去並行執行。
CUDA Stream流：Cuda stream是指一堆非同步的cuda操作，他們按照host程式碼呼叫的順序執行在device上。

典型的CUDA程式碼執行流程：
a.將資料從Host端copy到Device端。
b.在Device上執行kernel。
c.將結果從Device段copy到Host端。

以上流程也是模型在GPU推理的過程。在執行的過程中還需要繫結CUDA Stream，以流的形式執行。

2.2 傳統Python推理服務瓶頸

2.2.1 傳統Python推理服務架構

由於Python在神經網路訓練與推理領域提供了豐富的庫支援，加上Python語言自身的便利性，所以推理服務大多用Python實現。CV演算法的推理引擎大多采用Python flask框架或Kserve的框架直接實現。這種框架大致呼叫流程如下：

以上架構是傳統推理服務的常用架構。這種架構的優勢是程式碼寫起來比較通俗易懂。但是在效能上有很大的弊端，所能承載的QPS比較低。我們用了幾個CV模型去壓測，極限QPS也一般不會超過4。

2.2.2 瓶頸分析

由於以上架構的CPU邏輯(圖片的前處理，後處理)與GPU邏輯(模型推理)在同一個執行緒內，所以會存在如下效能瓶頸：

• 如果是單執行緒的模式，CPU邏輯與GPU邏輯相互等待，GPU Kernel函式排程不足，導致GPU使用率不高。無法充分提升QPS。這種情況下只能開啟更多程序來提升QPS，但是更多程序會帶來更多視訊記憶體的開銷。

• 如果開啟多執行緒模式，經過實測，這種方式也不能帶來QPS的提升。主要是因為Python的GIL鎖的原因，由於Python GIL鎖的存在，Python的多執行緒實際上是偽的多執行緒，並不是真正的併發執行，而是多個執行緒通過爭搶GIL鎖來執行，這種情況下GPU Kernel launch執行緒不能得到充分的排程。在Python推理服務中，開啟多執行緒反而會導致GPU Kernel launch執行緒頻繁被CPU的執行緒打斷。由於GPU kernel lanch排程不足，這種方式也無法充分利用GPU使用率。

2.2.3 解決方案

針對以上問題，我們的解決方案是把CPU邏輯與GPU邏輯分離在兩個不同的程序中。CPU程序主要負責圖片的前處理與後處理，GPU邏輯則主要負責執行cuda kernel 函式，即模型推理。

另外由於我們線上有大量推理服務在執行，所以我們基於Python開發了一個CPU與GPU分離的統一框架。針對原有Flask或Kserve的服務，稍作修改即可使用我們的服務。具體請參考下面的CPU與GPU分離的統一推理框架相關介紹。

針對線上的某個推理服務，使用我們的框架進行了CPU與GPU程序分離，壓測得出的資料如下，可見QPS大約提升了7倍左右。

2.3 TensorRT模型加速原理

TensorRT是由英偉達公司推出的一款用於高效能深度學習模型推理的軟體開發工具包，可以把經過優化後的深度學習模型構建成推理引擎部署在實際的生產環境中。TensorRT提供基於硬體級別的推理引擎效能優化。
下圖為業界最常用的TensorRT優化流程，也是當前模型優化的最佳實踐，即pytorch或tensorflow等模型轉成onnx格式，然後onnx格式轉成TensorRT進行優化。

其中TensorRT所做的工作主要在兩個時期，一個是網路構建期，另外一個是模型執行期。

a.網路構建期
i.模型解析與建立，載入onnx網路模型。
ii.計算圖優化，包括橫向運算元融合，或縱向運算元融合等。
iii.節點消除，去除無用的節點。
iv.多精度支援，支援FP32/FP16/int8等精度。
v.基於特定硬體的相關優化。

b.模型執行期
i.序列化，載入RensorRT模型檔案。
ii.提供執行時的環境，包括物件生命週期管理，記憶體視訊記憶體管理等。

以下是我們基於 VisualTransformer模型進行的TensorRT優化前後的效能評測報告：

3框架與工具篇

這一篇章，主要介紹我們自己推出的框架與工具。其中框架為CPU與GPU分離的Python統一推理框架，工具則為Onnx轉TensorRT的半自動化除錯工具。相關框架與工具我們在線上大量推理服務推進使用中。

其中CPU與GPU分離的Python統一推理框架解決了普通Python推理服務無法自動隔離CPU與GPU的問題，使用者只需要繼承並實現框架提供的前處理，推理，後處理相關介面，底層邏輯即可自動把CPU與GPU進行程序級別隔離。

其中TensorRT半自動化除錯工具，主要定位並解決模型轉TensorRT的過程中遇到的各種精度丟失問題。底層基於TensorRT的相關介面與工具進行封裝開發。簡化TensorRT的優化引數。

3.1 CPU與GPU分離的統一推理框架

新架構設計方案如下：

方案設計的思路是GPU邏輯與CPU邏輯分離到兩個程序，其中CPU程序主要負責CPU相關的業務邏輯，GPU程序主負責GPU相關推理邏輯。同時拉起一個Proxy程序做路由轉發。

（1）Proxy程序
Proxy程序是系統門面，對外提供呼叫介面，主要負責路由分發與健康檢查。當Proxy程序收到請求後，會輪詢呼叫CPU程序，分發請求給CPU程序。

（2）CPU程序
CPU程序主要負責推理服務中的CPU相關邏輯，包括前處理與後處理。前處理一般為圖片解碼，圖片轉換。後處理一般為推理結果判定等邏輯。
CPU程序在前處理結束後，會呼叫GPU程序進行推理，然後繼續進行後處理相關邏輯。CPU程序與GPU程序通過共享記憶體或網路進行通訊。共享記憶體可以減少圖片的網路傳輸。

（3）GPU程序
GPU程序主要負責執行GPU推理相關的邏輯，它啟動的時候會載入很多模型到視訊記憶體，然後收到CPU程序的推理請求後，直接觸發kernel lanuch呼叫模型進行推理。

該方案對演算法同學提供了一個Model類介面，演算法同學不需要關心後面的呼叫邏輯，只需要填充其中的前處理，後處理的業務邏輯，既可快速上線模型服務，自動拉起這些程序。

該方案把CPU邏輯(圖片解碼，圖片後處理等)與GPU邏輯(模型推理)分離到兩個不同的程序中。可以解決Python GIL鎖帶來的GPU Kernel launch排程問題。

3.2 TensorRT除錯工具

TensorRT雖然不是完全開源的，但是官方給出了一些介面與工具，基於這些介面與工具我們可以對模型優化流程進行分析與干預。基於TensorRT官方提供的介面與工具，我們自己研發了一套工具。使用者可以使用我們的工具把模型轉成TensorRT格式，如果在模型轉換的過程中出現精度丟失等問題，也可以使用該工具進行問題定位與解決。

自研工具主要在兩個階段為使用者提供幫助，一個階段是問題定位，另一個階段是模型轉換。具體描述如下：

3.2.1 問題定位

問題定位階段主要是為了解決模型轉TensorRT開啟FP16模式時出現的精度丟失問題。一般分類模型，對精度的要求不是極致的情況下，儘量開啟FP16，FP16模式下，NVIDIA對於FP16有專門的Tensor Cores可以進行矩陣運算，相比FP32來說吞吐量提升一倍以上。
比如在轉TensorRT時，開啟FP16出現了精度丟失問題，自研工具在問題定位階段的大致工作流程如下：

主要工作流程為：
（1）設定模型轉換精度要求後，標記所有運算元為輸出，然後對比所有運算元的輸出精度。
（2）找到最早的不符合精度要求的運算元，對該運算元進行如下幾種方式干預。

• 標記該運算元為FP32。
• 標記其父類運算元為FP32。
• 更改該運算元的優化策略(具體參考TensorRT的tactic)

迴圈通過以上兩個步驟，最終找到符合目標精度要求的模型引數。這些引數比如，需要額外開啟FP32的那些運算元等。然後相關引數會輸出到配置檔案中，如下：

3.2.2 模型轉換

模型轉換階段則直接使用上面問題定位階段得到的引數，呼叫TensorRT相關介面與工具進行轉換。
此外，我們在模型轉換階段，針對TensorRT原有引數與API過於複雜的問題也做了一些封裝，提供了更為簡潔的介面，比如工具可以自動解析ONNX，判斷模型的輸入與輸出shape，不需要使用者再提供相關shape資訊了。

4優化技巧實戰篇

在實際應用中，我們期望使用者能夠對一個推理模型開啟CPU與GPU分離的同時，也開啟TensorRT優化。這樣往往可以得到QPS兩次優化的疊加效果。比如我們針對線下某個分類模型進行優化，使用的是CPU與GPU分離，TensorRT優化，並開啟FP16半精度，最終得到了10倍的QPS提升。

以下是我們在模型優化過程中的一些實戰技巧，梳理一下，分享給大家。

（1）分類模型，CPU與GPU分離，TensorRT優化，並開啟FP16，得到10倍QPS提升
某個線上基於Resnet的分類模型，對精度損失可以接受誤差在0.001(誤差定義：median,atol,rtol)範圍內。因此我們對該推理服務進行了三項效能優化：
a.使用我們提供的GPU與CPU分離的統一框架進行改造。
b.對模型轉ONNX後，轉TensorRT。
c.開啟FP16模式，並使用自研工具定位到中間出現精度損失的運算元，把這些運算元標記為FP32.

經過以上優化，最終得到了10倍QPS的提升(與原來Pytorch直接推理比較)，成本上得到比較大的縮減。

（2）檢測模型，CPU與GPU分離，TensorRT模型優化，QPS提升4-5倍左右。
某個線上基於Yolo的檢查模型，由於對精度要求比較高，所以沒有辦法開啟FP16，我們直接在FP32的模式下進行了TensorRT優化，並使用統一框架進行GPU與CPU分離，最終得到QPS 4-5倍的提升。

（3）同模型重複部署，充分利用GPU算力資源
在實際的場景中，往往GPU的算力是充足的，而GPU視訊記憶體是不夠的。經過TensorRT優化後，模型執行時需要的視訊記憶體大小一般會降低到原來的1/3到1/2。

為了充分利用GPU算力，框架進一步優化，支援可以把GPU程序在一個容器內複製多份，這種架構即保證了CPU可以提供充足的請求給GPU，也保證了GPU算力充分利用。優化後的架構如下圖：

5總結

採用以上兩個推理模型的加速技巧，即CPU與GPU程序隔離，TensorRT模型加速。我們對線上的大量的GPU推理服務進行了優化，也節省了比較多的GPU伺服器成本。
其中CPU與GPU程序隔離主要是針對Python推理服務的優化，因為在C++的推理服務中，不存在Python GIL鎖，也就不存在Python Kernel launch執行緒的排程問題。目前業界開源的Python推理服務框架中，還沒有提供類似的優化功能，所以我們後續有考慮把Python統一推理服務框架進行開源，希望能為社群做一點貢獻。
此外TensorRT的模型優化，我們參考了大量NIVIDIA的官網文件，在上層做了封裝，後續會進一步深入研究。