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模型文件。

提供運行時的環境，包括對象生命周期管理，內存顯存管理等。

以下是我們基于 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算力充分利用。優化后的架構如下圖：

比如線上某個模型，經過TensorRT優化后，顯存由原來的2.4G降低到只需要1.2G。為此我們申請了5G顯存，配置GPU進程為復制4份，共需要4.8G顯存。這樣存充分利用5G顯存，達到原來一個模型的4倍的算力，充分利用GPU的算力資源。

5、總結

采用以上兩個推理模型的加速技巧，即CPU與GPU進程隔離，TensorRT模型加速。我們對線上的大量的GPU推理服務進行了優化，也節省了比較多的GPU服務器成本。

其中CPU與GPU進程隔離主要是針對Python推理服務的優化，因為在C++的推理服務中，不存在Python GIL鎖，也就不存在Python Kernel launch線程的調度問題。目前業界開源的Python推理服務框架中，還沒有提供類似的優化功能，所以我們后續有考慮把Python統一推理服務框架進行開源，希望能為社區做一點貢獻。

此外TensorRT的模型優化，我們參考了大量NIVIDIA的官網文檔，在上層做了封裝，后續會進一步深入研究。