1、背景

隨著CV算法在業(yè)務(wù)場景中使用越來越多，給我們帶來了新的挑戰(zhàn)，需要提升Python推理服務(wù)的性能以降低生產(chǎn)環(huán)境成本。為此我們深入去研究Python GPU推理服務(wù)的工作原理，推理模型優(yōu)化的方法。最終通過兩項關(guān)鍵的技術(shù): 1.Python的GPU與CPU進(jìn)程分離，2.使用TensorRT對模型進(jìn)行加速，使得線上大部分模型服務(wù)QPS提升5-10倍左右，大量節(jié)約了線上GPU推理服務(wù)的成本。

針對上面的兩項關(guān)鍵技術(shù)，我們還自研了相關(guān)框架與工具進(jìn)行沉淀。包括基于Python的CPU與GPU進(jìn)程自動隔離的推理服務(wù)框架，以及對推理模型進(jìn)行轉(zhuǎn)TensorRT優(yōu)化的調(diào)試工具。

此外針對不同的推理服務(wù)性能瓶頸，我們還梳理了各種實戰(zhàn)優(yōu)化技巧，比如CPU與GPU分離，TensorRT開啟半精度優(yōu)化，同模型混合部署，GPU數(shù)據(jù)傳輸與推理并行等。

下面從理論，框架與工具，實戰(zhàn)優(yōu)化技巧三個方面介紹下推理服務(wù)性能優(yōu)化的方法。

2、理論篇

2.1 CUDA架構(gòu)

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

CUDA的架構(gòu)中引入了主機(jī)端（host, cpu）和設(shè)備（device, gpu）的概念。CUDA的Kernel函數(shù)既可以運行在主機(jī)端，也可以運行在設(shè)備端。同時主機(jī)端與設(shè)備端之間可以進(jìn)行數(shù)據(jù)拷貝。

CUDA Kernel函數(shù)：是數(shù)據(jù)并行處理函數(shù)（核函數(shù))，在GPU上執(zhí)行時，一個Kernel對應(yīng)一個Grid，基于GPU邏輯架構(gòu)分發(fā)成眾多thread去并行執(zhí)行。

CUDA Stream流：Cuda stream是指一堆異步的cuda操作，他們按照host代碼調(diào)用的順序執(zhí)行在device上。

典型的CUDA代碼執(zhí)行流程：

a.將數(shù)據(jù)從Host端copy到Device端。

b.在Device上執(zhí)行kernel。

c.將結(jié)果從Device段copy到Host端。

以上流程也是模型在GPU推理的過程。在執(zhí)行的過程中還需要綁定CUDA Stream，以流的形式執(zhí)行。

2.2 傳統(tǒng)Python推理服務(wù)瓶頸

2.2.1 傳統(tǒng)Python推理服務(wù)架構(gòu)

由于Python在神經(jīng)網(wǎng)絡(luò)訓(xùn)練與推理領(lǐng)域提供了豐富的庫支持，加上Python語言自身的便利性，所以推理服務(wù)大多用Python實現(xiàn)。CV算法的推理引擎大多采用Python flask框架或Kserve的框架直接實現(xiàn)。這種框架大致調(diào)用流程如下：

以上架構(gòu)是傳統(tǒng)推理服務(wù)的常用架構(gòu)。這種架構(gòu)的優(yōu)勢是代碼寫起來比較通俗易懂。但是在性能上有很大的弊端，所能承載的QPS比較低。我們用了幾個CV模型去壓測，極限QPS也一般不會超過4。

2.2.2 瓶頸分析

由于以上架構(gòu)的CPU邏輯(圖片的前處理，后處理)與GPU邏輯(模型推理)在同一個線程內(nèi)，所以會存在如下性能瓶頸：

• 如果是單線程的模式，CPU邏輯與GPU邏輯相互等待，GPU Kernel函數(shù)調(diào)度不足，導(dǎo)致GPU使用率不高。無法充分提升QPS。這種情況下只能開啟更多進(jìn)程來提升QPS，但是更多進(jìn)程會帶來更多顯存的開銷。
• 如果開啟多線程模式，經(jīng)過實測，這種方式也不能帶來QPS的提升。主要是因為Python的GIL鎖的原因，由于Python GIL鎖的存在，Python的多線程實際上是偽的多線程，并不是真正的并發(fā)執(zhí)行，而是多個線程通過爭搶GIL鎖來執(zhí)行，這種情況下GPU Kernel launch線程不能得到充分的調(diào)度。在Python推理服務(wù)中，開啟多線程反而會導(dǎo)致GPU Kernel launch線程頻繁被CPU的線程打斷。由于GPU kernel lanch調(diào)度不足，這種方式也無法充分利用GPU使用率。

2.2.3 解決方案

針對以上問題，我們的解決方案是把CPU邏輯與GPU邏輯分離在兩個不同的進(jìn)程中。CPU進(jìn)程主要負(fù)責(zé)圖片的前處理與后處理，GPU邏輯則主要負(fù)責(zé)執(zhí)行cuda kernel 函數(shù)，即模型推理。

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

針對線上的某個推理服務(wù)，使用我們的框架進(jìn)行了CPU與GPU進(jìn)程分離，壓測得出的數(shù)據(jù)如下，可見QPS大約提升了7倍左右。

2.3 TensorRT模型加速原理

TensorRT是由英偉達(dá)公司推出的一款用于高性能深度學(xué)習(xí)模型推理的軟件開發(fā)工具包，可以把經(jīng)過優(yōu)化后的深度學(xué)習(xí)模型構(gòu)建成推理引擎部署在實際的生產(chǎn)環(huán)境中。TensorRT提供基于硬件級別的推理引擎性能優(yōu)化。

下圖為業(yè)界最常用的TensorRT優(yōu)化流程，也是當(dāng)前模型優(yōu)化的最佳實踐，即pytorch或tensorflow等模型轉(zhuǎn)成onnx格式，然后onnx格式轉(zhuǎn)成TensorRT進(jìn)行優(yōu)化。

其中TensorRT所做的工作主要在兩個時期，一個是網(wǎng)絡(luò)構(gòu)建期，另外一個是模型運行期。

a.網(wǎng)絡(luò)構(gòu)建期

   i.模型解析與建立，加載onnx網(wǎng)絡(luò)模型。

   ii.計算圖優(yōu)化，包括橫向算子融合，或縱向算子融合等。

   iii.節(jié)點消除，去除無用的節(jié)點。

   iv.多精度支持，支持FP32/FP16/int8等精度。

   v.基于特定硬件的相關(guān)優(yōu)化。

b.模型運行期

  i.序列化，加載RensorRT模型文件。

提供運行時的環(huán)境，包括對象生命周期管理，內(nèi)存顯存管理等。

以下是我們基于 VisualTransformer模型進(jìn)行的TensorRT優(yōu)化前后的性能評測報告：

3、框架與工具篇

這一篇章，主要介紹我們自己推出的框架與工具。其中框架為CPU與GPU分離的Python統(tǒng)一推理框架，工具則為Onnx轉(zhuǎn)TensorRT的半自動化調(diào)試工具。相關(guān)框架與工具我們在線上大量推理服務(wù)推進(jìn)使用中。

其中CPU與GPU分離的Python統(tǒng)一推理框架解決了普通Python推理服務(wù)無法自動隔離CPU與GPU的問題，用戶只需要繼承并實現(xiàn)框架提供的前處理，推理，后處理相關(guān)接口，底層邏輯即可自動把CPU與GPU進(jìn)行進(jìn)程級別隔離。

其中TensorRT半自動化調(diào)試工具，主要定位并解決模型轉(zhuǎn)TensorRT的過程中遇到的各種精度丟失問題。底層基于TensorRT的相關(guān)接口與工具進(jìn)行封裝開發(fā)。簡化TensorRT的優(yōu)化參數(shù)。

3.1 CPU與GPU分離的統(tǒng)一推理框架

新架構(gòu)設(shè)計方案如下：

方案設(shè)計的思路是GPU邏輯與CPU邏輯分離到兩個進(jìn)程，其中CPU進(jìn)程主要負(fù)責(zé)CPU相關(guān)的業(yè)務(wù)邏輯，GPU進(jìn)程主負(fù)責(zé)GPU相關(guān)推理邏輯。同時拉起一個Proxy進(jìn)程做路由轉(zhuǎn)發(fā)。

（1）Proxy進(jìn)程

Proxy進(jìn)程是系統(tǒng)門面，對外提供調(diào)用接口，主要負(fù)責(zé)路由分發(fā)與健康檢查。當(dāng)Proxy進(jìn)程收到請求后，會輪詢調(diào)用CPU進(jìn)程，分發(fā)請求給CPU進(jìn)程。

（2）CPU進(jìn)程

CPU進(jìn)程主要負(fù)責(zé)推理服務(wù)中的CPU相關(guān)邏輯，包括前處理與后處理。前處理一般為圖片解碼，圖片轉(zhuǎn)換。后處理一般為推理結(jié)果判定等邏輯。

CPU進(jìn)程在前處理結(jié)束后，會調(diào)用GPU進(jìn)程進(jìn)行推理，然后繼續(xù)進(jìn)行后處理相關(guān)邏輯。CPU進(jìn)程與GPU進(jìn)程通過共享內(nèi)存或網(wǎng)絡(luò)進(jìn)行通信。共享內(nèi)存可以減少圖片的網(wǎng)絡(luò)傳輸。

（3）GPU進(jìn)程

GPU進(jìn)程主要負(fù)責(zé)運行GPU推理相關(guān)的邏輯，它啟動的時候會加載很多模型到顯存，然后收到CPU進(jìn)程的推理請求后，直接觸發(fā)kernel lanuch調(diào)用模型進(jìn)行推理。

該方案對算法同學(xué)提供了一個Model類接口，算法同學(xué)不需要關(guān)心后面的調(diào)用邏輯，只需要填充其中的前處理，后處理的業(yè)務(wù)邏輯，既可快速上線模型服務(wù)，自動拉起這些進(jìn)程。

該方案把CPU邏輯(圖片解碼，圖片后處理等)與GPU邏輯(模型推理)分離到兩個不同的進(jìn)程中。可以解決Python GIL鎖帶來的GPU Kernel launch調(diào)度問題。

3.2 TensorRT調(diào)試工具

TensorRT雖然不是完全開源的，但是官方給出了一些接口與工具，基于這些接口與工具我們可以對模型優(yōu)化流程進(jìn)行分析與干預(yù)。基于TensorRT官方提供的接口與工具，我們自己研發(fā)了一套工具。用戶可以使用我們的工具把模型轉(zhuǎn)成TensorRT格式，如果在模型轉(zhuǎn)換的過程中出現(xiàn)精度丟失等問題，也可以使用該工具進(jìn)行問題定位與解決。

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

3.2.1 問題定位

問題定位階段主要是為了解決模型轉(zhuǎn)TensorRT開啟FP16模式時出現(xiàn)的精度丟失問題。一般分類模型，對精度的要求不是極致的情況下，盡量開啟FP16，F(xiàn)P16模式下，NVIDIA對于FP16有專門的Tensor Cores可以進(jìn)行矩陣運算，相比FP32來說吞吐量提升一倍以上。

比如在轉(zhuǎn)TensorRT時，開啟FP16出現(xiàn)了精度丟失問題，自研工具在問題定位階段的大致工作流程如下：

主要工作流程為：

（1）設(shè)定模型轉(zhuǎn)換精度要求后，標(biāo)記所有算子為輸出，然后對比所有算子的輸出精度。

（2）找到最早的不符合精度要求的算子，對該算子進(jìn)行如下幾種方式干預(yù)。

• 標(biāo)記該算子為FP32。
• 標(biāo)記其父類算子為FP32。
• 更改該算子的優(yōu)化策略(具體參考TensorRT的tactic)

循環(huán)通過以上兩個步驟，最終找到符合目標(biāo)精度要求的模型參數(shù)。這些參數(shù)比如，需要額外開啟FP32的那些算子等。然后相關(guān)參數(shù)會輸出到配置文件中，如下：

3.2.2 模型轉(zhuǎn)換

模型轉(zhuǎn)換階段則直接使用上面問題定位階段得到的參數(shù)，調(diào)用TensorRT相關(guān)接口與工具進(jìn)行轉(zhuǎn)換。

此外，我們在模型轉(zhuǎn)換階段，針對TensorRT原有參數(shù)與API過于復(fù)雜的問題也做了一些封裝，提供了更為簡潔的接口，比如工具可以自動解析ONNX，判斷模型的輸入與輸出shape，不需要用戶再提供相關(guān)shape信息了。

4、優(yōu)化技巧實戰(zhàn)篇

在實際應(yīng)用中，我們期望用戶能夠?qū)σ粋€推理模型開啟CPU與GPU分離的同時，也開啟TensorRT優(yōu)化。這樣往往可以得到QPS兩次優(yōu)化的疊加效果。比如我們針對線下某個分類模型進(jìn)行優(yōu)化，使用的是CPU與GPU分離，TensorRT優(yōu)化，并開啟FP16半精度，最終得到了10倍的QPS提升。

以下是我們在模型優(yōu)化過程中的一些實戰(zhàn)技巧，梳理一下，分享給大家。

（1）分類模型，CPU與GPU分離，TensorRT優(yōu)化，并開啟FP16，得到10倍QPS提升

某個線上基于Resnet的分類模型，對精度損失可以接受誤差在0.001(誤差定義：median,atol,rtol)范圍內(nèi)。因此我們對該推理服務(wù)進(jìn)行了三項性能優(yōu)化：

a.使用我們提供的GPU與CPU分離的統(tǒng)一框架進(jìn)行改造。

b.對模型轉(zhuǎn)ONNX后，轉(zhuǎn)TensorRT。

c.開啟FP16模式，并使用自研工具定位到中間出現(xiàn)精度損失的算子，把這些算子標(biāo)記為FP32.

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

（2）檢測模型，CPU與GPU分離，TensorRT模型優(yōu)化，QPS提升4-5倍左右。

某個線上基于Yolo的檢查模型，由于對精度要求比較高，所以沒有辦法開啟FP16，我們直接在FP32的模式下進(jìn)行了TensorRT優(yōu)化，并使用統(tǒng)一框架進(jìn)行GPU與CPU分離，最終得到QPS 4-5倍的提升。

（3）同模型重復(fù)部署，充分利用GPU算力資源

在實際的場景中，往往GPU的算力是充足的，而GPU顯存是不夠的。經(jīng)過TensorRT優(yōu)化后，模型運行時需要的顯存大小一般會降低到原來的1/3到1/2。

為了充分利用GPU算力，框架進(jìn)一步優(yōu)化，支持可以把GPU進(jìn)程在一個容器內(nèi)復(fù)制多份，這種架構(gòu)即保證了CPU可以提供充足的請求給GPU，也保證了GPU算力充分利用。優(yōu)化后的架構(gòu)如下圖：

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

5、總結(jié)

采用以上兩個推理模型的加速技巧，即CPU與GPU進(jìn)程隔離，TensorRT模型加速。我們對線上的大量的GPU推理服務(wù)進(jìn)行了優(yōu)化，也節(jié)省了比較多的GPU服務(wù)器成本。

其中CPU與GPU進(jìn)程隔離主要是針對Python推理服務(wù)的優(yōu)化，因為在C++的推理服務(wù)中，不存在Python GIL鎖，也就不存在Python Kernel launch線程的調(diào)度問題。目前業(yè)界開源的Python推理服務(wù)框架中，還沒有提供類似的優(yōu)化功能，所以我們后續(xù)有考慮把Python統(tǒng)一推理服務(wù)框架進(jìn)行開源，希望能為社區(qū)做一點貢獻(xiàn)。

此外TensorRT的模型優(yōu)化，我們參考了大量NIVIDIA的官網(wǎng)文檔，在上層做了封裝，后續(xù)會進(jìn)一步深入研究。