戰(zhàn)：CUDA/cuDNN/TensorRT版本匹配與C++推理)
簡介本資源是面向Windows平臺AI推理開發(fā)者的Paddle Inference 3.0.0預(yù)編譯開發(fā)包專為需快速集成高性能深度學(xué)習(xí)推理能力的C工程而優(yōu)化適用于模型部署、邊緣計(jì)算及工業(yè)級服務(wù)開發(fā)等場景。壓縮包共623個(gè)文件涵蓋569個(gè)頭文件h/hpp用于接口調(diào)用與類型定義13個(gè)靜態(tài)庫lib和2個(gè)導(dǎo)出文件exp支撐鏈接構(gòu)建5個(gè)核心DLL如paddle_inference.dll、mklml.dll、mkldnn.dll提供運(yùn)行時(shí)推理引擎與數(shù)學(xué)加速能力另有proto與pb文件支持模型序列化解析整體體積達(dá)528.04MB。內(nèi)容預(yù)覽顯示其深度整合Intel MKL含lapacke.h等數(shù)學(xué)接口、CUDA 11.8、cuDNN 8.6.0及TensorRT 8.5.1.7具備AVX指令集優(yōu)化與VS2019兼容性。目前已有132人下載學(xué)習(xí)開箱即用省去復(fù)雜環(huán)境編譯與依賴適配過程顯著降低Windows下PaddlePaddle C推理部署門檻。 拿到這個(gè)文件名的時(shí)候我第一反應(yīng)是這是一臺Windows機(jī)器的Paddle Inference推理環(huán)境全家桶。x86-64-cuda11.8-cudnn8.6.0-trt8.5.1.7-mkl-avx-vs2019-paddle-inference-3.0.0.zip光看名字就能拆出七八個(gè)關(guān)鍵信息。如果你是做深度學(xué)習(xí)模型部署的或者剛接手一個(gè)C推理項(xiàng)目看到這種預(yù)編譯包時(shí)最怕的不是別的就是版本對不上、DLL缺一堆、跑起來直接崩。這篇文章就圍繞這個(gè)包把我實(shí)際部署Paddle Inference時(shí)踩過的坑、驗(yàn)證過的步驟、調(diào)過的參數(shù)全部梳理一遍從環(huán)境匹配講到推理代碼再到TensorRT加速和常見報(bào)錯(cuò)排查爭取讓你拿到包之后能一口氣跑通。先說這個(gè)包具體能干什么。Paddle Inference是PaddlePaddle的官方高性能推理引擎跟訓(xùn)練框架解耦專門為上線部署優(yōu)化。這個(gè)zip是預(yù)編譯好的Windows x64版本編譯時(shí)用的是CUDA 11.8、cuDNN 8.6.0、TensorRT 8.5.1.7同時(shí)開啟了MKL數(shù)學(xué)庫和AVX指令集構(gòu)建環(huán)境對應(yīng)VS2019。什么意思呢就是說只要你的機(jī)器滿足這些依賴版本解壓這個(gè)包配置好環(huán)境變量和CMake工程就能直接做GPU加速的模型推理完全不需要自己從源碼編譯Paddle省下幾個(gè)小時(shí)甚至一整天的編譯時(shí)間。適合誰看剛?cè)胄凶瞿Ｐ筒渴鸬墓こ處?、需要在Windows上集成Paddle推理到C項(xiàng)目的同學(xué)以及被各種CUDA/cuDNN版本折磨過的老哥。1. 內(nèi)容整體設(shè)計(jì)與拆解思路1.1 文件名里的版本矩陣代表什么先把這個(gè)文件名當(dāng)密碼一樣逐段拆開看。x86-64平臺架構(gòu)表示64位x86指令集幾乎所有現(xiàn)代Intel和AMD處理器都適用。如果你的機(jī)器是ARM架構(gòu)比如部分Windows平板、Surface Pro X這個(gè)包就用不了。cuda11.8NVIDIA CUDA Toolkit的版本號。推理庫編譯時(shí)鏈接的是CUDA 11.8的運(yùn)行時(shí)庫意味著你的機(jī)器上必須安裝CUDA 11.8或者更新但兼容的版本向下兼容方面一般驅(qū)動(dòng)版本不能低于525.60.13具體看NVIDIA官方文檔。這里有個(gè)常見誤區(qū)CUDA有兩個(gè)概念一個(gè)是顯卡驅(qū)動(dòng)自帶的運(yùn)行時(shí)兼容層一個(gè)是獨(dú)立的Toolkit后面會(huì)細(xì)說。cudnn8.6.0NVIDIA cuDNN深度學(xué)習(xí)原語庫版本。CUDA負(fù)責(zé)通用并行計(jì)算cuDNN專門對卷積、池化、歸一化等神經(jīng)網(wǎng)絡(luò)核心算子做了深度優(yōu)化兩者配合才能發(fā)揮GPU的性能。trt8.5.1.7TensorRT版本。這是NVIDIA的高性能推理優(yōu)化器能把訓(xùn)練好的模型做層融合、精度校準(zhǔn)、動(dòng)態(tài)shape優(yōu)化再生成推理引擎。Paddle Inference啟用TensorRT之后某些模型的推理延遲可以再降30%到50%。mklIntel Math Kernel Library數(shù)學(xué)核心庫。CPU上跑算子的時(shí)候會(huì)用MKL加速矩陣乘法、卷積等計(jì)算。Paddle Inference在CPU模式下如果沒有MKL性能會(huì)差挺多這個(gè)包默認(rèn)帶上了。avxAdvanced Vector ExtensionsCPU指令集。AVX允許CPU單條指令處理多個(gè)浮點(diǎn)數(shù)據(jù)Paddle為這個(gè)指令集專門優(yōu)化過算子跑CPU推理時(shí)速度提升明顯。注意如果你的老舊CPU不支持AVX這個(gè)包會(huì)直接報(bào)非法指令錯(cuò)誤。vs2019構(gòu)建工具鏈版本Visual Studio 2019。這個(gè)主要影響你編譯C程序時(shí)MSVC運(yùn)行時(shí)版本如果你用VS2015或VS2017去鏈接這個(gè)庫大概率會(huì)遇到運(yùn)行時(shí)庫沖突或者符號解析失敗。paddle-inference-3.0.0Paddle Inference主版本號。3.0.0是相對較新的版本API設(shè)計(jì)和舊版有差異最明顯的是頭文件引用方式變了后面代碼部分會(huì)展示。zip打包格式Windows下直接用解壓工具解壓即可。一句話總結(jié)這個(gè)包是Paddle Inference團(tuán)隊(duì)在特定軟硬件環(huán)境下編譯出來的產(chǎn)物想用好它你的開發(fā)機(jī)環(huán)境要跟這個(gè)版本矩陣對齊。1.2 CUDA、cuDNN、TensorRT三者的“鐵三角”關(guān)系很多人分不清CUDA、cuDNN、TensorRT的關(guān)系我打個(gè)比方。CUDA Toolkit相當(dāng)于GPU的“操作系統(tǒng)API”你寫CUDA代碼、編譯GPU程序、管理顯存都靠它。顯卡驅(qū)動(dòng)是“硬件驅(qū)動(dòng)層”CUDA Toolkit是“用戶態(tài)開發(fā)庫”兩者有對應(yīng)關(guān)系驅(qū)動(dòng)包含一個(gè)兼容層只要驅(qū)動(dòng)版本夠新就能運(yùn)行較舊版本的CUDA Toolkit編譯出來的程序。cuDNN是構(gòu)建在CUDA之上的“深度神經(jīng)網(wǎng)絡(luò)加速庫”它把卷積、LSTM等常用算子優(yōu)化到極致訓(xùn)練和推理框架都會(huì)調(diào)用它。Paddle推理庫編譯時(shí)指定cuDNN 8.6.0運(yùn)行時(shí)就會(huì)去找對應(yīng)版本的cudnn64_8.dll。TensorRT則更上層它是個(gè)“推理引擎優(yōu)化器”。它不關(guān)心你怎么訓(xùn)練模型只負(fù)責(zé)把訓(xùn)練好的模型轉(zhuǎn)換成推理引擎通過層融合、kernel自動(dòng)調(diào)優(yōu)、FP16/INT8量化等手段壓縮推理耗時(shí)。Paddle Inference跑GPU推理時(shí)要啟用TensorRT就必須在運(yùn)行時(shí)加載TensorRT的動(dòng)態(tài)庫nvinfer.dll等版本跟編譯時(shí)保持一致或兼容否則會(huì)報(bào)算子不匹配或版本不兼容的錯(cuò)。這三者的匹配邏輯是驅(qū)動(dòng) CUDA Toolkit cuDNN版本可接受范圍 TensorRT版本可接受范圍。實(shí)際部署中最讓人頭疼的就是dll版本沖突老版本和新版本往往只差一兩個(gè)小版本號但行為卻截然不同。1.3 為什么需要預(yù)編譯的Paddle Inference包可能有人會(huì)問直接pip install paddlepaddle-gpu不就行了對于Python調(diào)用確實(shí)簡單但C部署場景完全不同。首先C推理需要的是靜態(tài)庫和頭文件pip包里雖然有但接口不穩(wěn)定、沒有頭文件、不方便鏈接。其次Paddle Inference源碼編譯在Windows下極其痛苦要裝Python、CMake、VS2019、CUDA、cuDNN、TensorRT還要處理各種依賴沖突編譯一次少說兩小時(shí)。預(yù)編譯包相當(dāng)于把這些都辦好你的任務(wù)只是“解壓 配置 鏈接”。從工程視角看預(yù)編譯包還能保證推理行為的一致性你自己編譯的庫可能因?yàn)榫幾g選項(xiàng)不同算出的結(jié)果有細(xì)微差異但官方預(yù)編譯的版本是統(tǒng)一優(yōu)化過的批量部署時(shí)更可控。2. 環(huán)境配置從零準(zhǔn)備CUDA 11.8、cuDNN和TensorRT2.1 Windows下安裝CUDA 11.8的完整步驟很多人在Windows裝CUDA時(shí)翻車主要原因是把“顯卡驅(qū)動(dòng)”和“CUDA Toolkit”混為一談。實(shí)際上如果你只是要跑現(xiàn)成的Paddle推理包NVIDIA驅(qū)動(dòng)里已經(jīng)包含了最低限度的CUDA運(yùn)行時(shí)兼容庫但頭文件、nvcc編譯器、開發(fā)庫必須額外裝Toolkit。第一步檢查顯卡驅(qū)動(dòng)。打開NVIDIA控制面板左下角“系統(tǒng)信息”里能看到驅(qū)動(dòng)版本。CUDA 11.8要求驅(qū)動(dòng)版本至少525.60.13如果驅(qū)動(dòng)太老后面加載cuda runtime的時(shí)候會(huì)報(bào)找不到入口點(diǎn)或版本不兼容。驅(qū)動(dòng)更新就直接去NVIDIA官網(wǎng)下載Game Ready或Studio驅(qū)動(dòng)都可以開發(fā)機(jī)建議用Studio驅(qū)動(dòng)穩(wěn)定性更好。第二步下載CUDA Toolkit 11.8。到NVIDIA官網(wǎng)的CUDA Toolkit Archive頁面選擇11.8版本W(wǎng)indows x86_64的exe安裝包大概2.8GB。安裝時(shí)選擇“自定義”把CUDA下的“Visual Studio Integration”選上其他組件默認(rèn)。注意安裝路徑不要有中文和空格我習(xí)慣用默認(rèn)的C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8。第三步驗(yàn)證安裝。打開命令行cmd或PowerShell輸入nvcc -V如果正常輸出版本信息說明Toolkit安裝成功。這里我遇到過一個(gè)問題裝完CUDA后命令行輸入nvcc提示不是內(nèi)部或外部命令原因是沒有把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bin加到系統(tǒng)環(huán)境變量PATH里。重新配置環(huán)境變量后重開命令行即可。還有一個(gè)非常常見的坑CUDA安裝的時(shí)候提示需要VS的某類組件如果你機(jī)器上裝的是VS2022而不是VS2019也沒關(guān)系CUDA 11.8對VS2022也有一定支持只是官方在VS2019下驗(yàn)證得最充分。Paddle這個(gè)包標(biāo)注VS2019不代表VS2022不能用只是建議盡量接近構(gòu)建環(huán)境減少鏈接時(shí)的小問題。2.2 cuDNN 8.6.0下載與部署cuDNN的安裝比CUDA簡單本質(zhì)上就是往CUDA目錄里放幾個(gè)文件。到NVIDIA cuDNN Archive頁面選擇Download cuDNN v8.6.0 for CUDA 11.xWindows版本下載得到一個(gè)zip壓縮包。解壓后里面有3個(gè)文件夾bin、include、lib。操作邏輯很直接把bin里的cudnn64_8.dll復(fù)制到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bininclude里的cudnn.h復(fù)制到對應(yīng)的include目錄lib里的cudnn.lib復(fù)制到lib\x64目錄。復(fù)制的時(shí)候記得管理員權(quán)限。驗(yàn)證方式有兩個(gè)。第一查看C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bin下是否存在cudnn64_8.dll第二在命令行執(zhí)行nvidia-smi如果驅(qū)動(dòng)正常再執(zhí)行一個(gè)小的CUDA樣本程序比如bandwidthTest.exe能通過就說明CUDA環(huán)境沒問題cuDNN因?yàn)槭莿?dòng)態(tài)庫只有真正跑深度學(xué)習(xí)推理時(shí)才會(huì)被調(diào)用。關(guān)于cuDNN我多說一句版本號中數(shù)字的兼容性比你想象中嚴(yán)格。比如cuDNN 8.6.0生成的動(dòng)態(tài)庫名為cudnn64_8.dll其中“64_8”表示64位平臺、支持CUDA 11.x的API。如果你換成cudnn 8.9.x文件名可能會(huì)變成cudnn64_9.dll此時(shí)Paddle Inference編譯時(shí)鏈接的還是cudnn64_8這個(gè)導(dǎo)入庫運(yùn)行時(shí)就會(huì)報(bào)找不到dll。所以不要隨便升級cuDNN。2.3 TensorRT 8.5.1.7的安裝與環(huán)境配置TensorRT的安裝也是解壓式。到NVIDIA TensorRT Archive頁面下載TensorRT 8.5.1.7 for Windows x86_64 and CUDA 11.0, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7, 11.8的zip包解壓到一個(gè)你方便找到的路徑比如D:\TensorRT-8.5.1.7。TensorRT包里面包括bin目錄trtexec等工具、include目錄頭文件、lib目錄dll和導(dǎo)入庫、還有python包目錄。我們的核心任務(wù)是把lib目錄加入PATH或者把dll復(fù)制到安全位置。Paddle Inference運(yùn)行時(shí)加載TensorRT是動(dòng)態(tài)加載的它會(huì)在默認(rèn)路徑和PATH中查找nvinfer.dll、nvonnxparser.dll等文件。所以最簡單的方法是把D:\TensorRT-8.5.1.7\lib加到系統(tǒng)環(huán)境變量PATH里并確保在PATH中的位置比較靠前。如果你在開發(fā)機(jī)上不想污染全局環(huán)境也可以在做CMake工程時(shí)通過cmake變量把TensorRT路徑傳進(jìn)去運(yùn)行exe前在腳本里加一下PATH。TensorRT還有個(gè)小坑它在運(yùn)行時(shí)需要額外的CUDA驅(qū)動(dòng)支持如果你用了精簡版驅(qū)動(dòng)或者老驅(qū)動(dòng)初始化TensorRT時(shí)會(huì)卡在加載cudart64_11.dll。所以再次確認(rèn)驅(qū)動(dòng)版本別低于525.60.13。2.4 驗(yàn)證整套環(huán)境是否匹配在開始寫代碼之前先用最簡單的方式驗(yàn)證一下環(huán)境。打開命令行依次執(zhí)行nvcc -V確認(rèn)CUDA 11.8。where cudnn64_8.dll如果能找到路徑說明cuDNN在PATH里。where nvinfer.dll確認(rèn)TensorRT核心庫可見。另外可以用TensorRT自帶的trtexec工具做一次快速自檢比如加載一個(gè)ONNX模型轉(zhuǎn)成engine能跑通說明TensorRT初始化正常D:\TensorRT-8.5.1.7\bin\trtexec.exe --onnxyour_model.onnx --saveEnginetest.engine如果這個(gè)命令報(bào)錯(cuò)先別查Paddle大概率是TensorRT環(huán)境本身的問題早點(diǎn)發(fā)現(xiàn)早點(diǎn)排查。整個(gè)環(huán)境配置下來我的經(jīng)驗(yàn)是能不改系統(tǒng)PATH就盡量不改所有的依賴庫通過拷貝dll到指定目錄的方式管理項(xiàng)目可控性更高。但既然做開發(fā)PATH方式最省事二選一即可。3. Paddle Inference 3.0.0的工程集成與推理實(shí)現(xiàn)3.1 解壓并理解預(yù)編譯包的目錄結(jié)構(gòu)把下載的zip解壓后你會(huì)看到類似這樣的目錄結(jié)構(gòu)paddle_inference/ ├── paddle/ │ ├── include/ │ │ ├── paddle_analysis_config.h │ │ ├── paddle_inference_api.h │ │ ├── paddle_pass_builder.h │ │ └── ... │ └── lib/ │ ├── paddle_inference.lib │ ├── paddle_inference.dll │ └── ... ├── third_party/ │ ├── install/ │ │ ├── cuda/ │ │ ├── cudnn/ │ │ ├── tensorrt/ │ │ ├── mkl/ │ │ └── ... │ └── ... ├── version.txt └── ...重點(diǎn)在于paddle/include和paddle/lib。頭文件放的是C API聲明庫文件放的是導(dǎo)入庫和動(dòng)態(tài)庫。third_party目錄里通常會(huì)有Paddle依賴的第三方庫但實(shí)際運(yùn)行時(shí)大多數(shù)還需要系統(tǒng)環(huán)境的CUDA、cuDNN等別指望這個(gè)目錄里的文件能替代你手動(dòng)安裝的CUDA Toolit。version.txt里會(huì)寫明精確的構(gòu)建信息建議打開看一眼確認(rèn)跟你理解的版本一致。在Windows下用VS2019建工程時(shí)配置包含目錄為paddle/include庫目錄為paddle/lib并且把paddle_inference.dll、paddle2ONNX.dll等動(dòng)態(tài)庫拷貝到exe輸出目錄或放到PATH可達(dá)的位置。否則編譯能過運(yùn)行就報(bào)找不到paddle_inference.dll。3.2 最小CMake工程配置我習(xí)慣用CMake來管理Windows下的C工程比直接手寫.vcxproj方便。下面是我驗(yàn)證過可用的CMakeLists.txt模板針對VS2019 Paddle Inference 3.0.0cmake_minimum_required(VERSION 3.16) project(paddle_infer_demo) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CONFIGURATION_TYPES Release CACHE STRING FORCE) # Paddle Inference路徑 set(PADDLE_INFER_DIR D:/paddle_inference CACHE PATH Path to paddle_inference) include_directories(${PADDLE_INFER_DIR}/paddle/include) link_directories(${PADDLE_INFER_DIR}/paddle/lib) # CUDA include_directories(C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.8/include) link_directories(C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.8/lib/x64) # TensorRT set(TENSORRT_DIR D:/TensorRT-8.5.1.7) include_directories(${TENSORRT_DIR}/include) link_directories(${TENSORRT_DIR}/lib) # MKL如果推理時(shí)想用CPU算子MKL路徑也要加 set(MKL_DIR C:/Program Files (x86)/Intel/oneAPI/mkl/latest) include_directories(${MKL_DIR}/include) link_directories(${MKL_DIR}/lib) add_executable(paddle_demo main.cpp) target_link_libraries(paddle_demo paddle_inference cudart nvinfer nvonnxparser # 釋放版本下Paddle還需要關(guān)注paddle2onnx依賴但鏈接paddle_inference時(shí)通常會(huì)自動(dòng)帶 )這里要特別說明兩點(diǎn)。第一CMake的link_directories在Windows下有時(shí)不生效因?yàn)镸SVC在鏈接時(shí)更依賴具體的庫文件路徑。遇到“找不到paddle_inference.lib”的情況最省事的辦法是在target_link_libraries里寫全路徑target_link_libraries(paddle_demo ${PADDLE_INFER_DIR}/paddle/lib/paddle_inference.lib )第二Release模式必須和Release模式匹配。Paddle的預(yù)編譯庫一般是Release版如果你用Debug配置去鏈接大概率會(huì)在運(yùn)行時(shí)出現(xiàn)無法解析的外部符號或堆損壞因?yàn)镸SVC的運(yùn)行時(shí)庫/MD和/MTd不同。3.3 編寫一份能正常加載PIR模型的C推理代碼Paddle Inference 3.0.0的API和2.x有些變化核心頭文件是paddle_inference_api.h。下面是一個(gè)最基礎(chǔ)的單模型GPU推理示例流程是創(chuàng)建Config - 配置模型路徑 - 啟用GPU - 創(chuàng)建Predictor - 構(gòu)造輸入 - Run - 讀取輸出。#include iostream #include vector #include paddle_inference_api.h int main() { // 1. 創(chuàng)建AnalysisConfig paddle_infer::Config config; // 假設(shè)模型是Paddle保存的靜態(tài)圖模型包含model.pdmodel和model.pdiparams config.SetModel(path/to/model.pdmodel, path/to/model.pdiparams); // 2. 開啟GPU推理 config.EnableUseGpu(1024, 0); // 參數(shù)1顯存預(yù)分配大小MB參數(shù)2GPU設(shè)備ID // 如果不想用GPU可以改用config.DisableGpu() // 3. 啟用TensorRT可選 config.EnableTensorRtEngine(1 30 /* workspace_size */, 1 /* batch_size */, 10 /* min_subgraph_size */, paddle_infer::PrecisionType::kFloat32, false /* use_static */, false /* use_calib_mode */); // 4. 開啟MKLDNN僅CPU模式下用GPU模式下此選項(xiàng)一般無效 // config.EnableMKLDNN(); // 5. 創(chuàng)建Predictor auto predictor paddle_infer::CreatePredictor(config); // 6. 獲取輸入輸出張量的名稱 auto input_names predictor-GetInputNames(); auto output_names predictor-GetOutputNames(); // 7. 構(gòu)造輸入 auto input_tensor predictor-GetInputHandle(input_names[0]); // 假設(shè)輸入shape是 [1, 3, 224, 224]float32 std::vectorfloat input_data(1 * 3 * 224 * 224, 0.5f); input_tensor-Reshape({1, 3, 224, 224}); input_tensor-CopyFromCpu(input_data.data()); // 8. 推理 predictor-Run(); // 9. 獲取輸出 auto output_tensor predictor-GetOutputHandle(output_names[0]); std::vectorfloat output_data; output_tensor-CopyToCpu(output_data.data()); // 注意上面這種CopyToCpu方式存在隱患因?yàn)閛utput_data沒有預(yù)分配空間。 // 更穩(wěn)妥的方式是先獲取shape再分配內(nèi)存 // auto out_shape output_tensor-shape(); // int out_num std::accumulate(out_shape.begin(), out_shape.end(), 1, std::multipliesint()); // output_data.resize(out_num); // output_tensor-CopyToCpu(output_data.data()); return 0; }這段代碼有幾個(gè)細(xì)節(jié)容易踩坑。首先GetOutputHandle之后一定要先調(diào)用shape()獲取輸出維度再給vector分配空間最后CopyToCpu。如果直接CopyToCpu到一個(gè)空vector會(huì)觸發(fā)訪問越界或只拷出一部分?jǐn)?shù)據(jù)。我在實(shí)際項(xiàng)目中遇到過輸出數(shù)據(jù)全0的情況排查半天發(fā)現(xiàn)是vector沒resizeCopyToCpu只寫了應(yīng)該寫的長度但程序讀取越界了。其次Config.EnableUseGpu的第一個(gè)參數(shù)是顯存預(yù)分配大小這個(gè)值不是硬性限制Paddle會(huì)在需要時(shí)繼續(xù)申請但預(yù)分配越大運(yùn)行中顯存碎片化越少越不容易因?yàn)轱@存不足報(bào)錯(cuò)。一般圖像分類模型給1024就夠檢測或分割模型給2048以上。另外Paddle的模型文件有兩種一種是舊版的__model__和params文件另一種是新版的.pdmodel和.pdiparams。3.0.0的接口對舊版也有兼容但我建議統(tǒng)一用新版格式保存模型時(shí)用paddle.jit.save。3.4 理解Paddle Inference的模型加載機(jī)制你可能會(huì)問模型文件到底放在哪程序怎么知道網(wǎng)絡(luò)結(jié)構(gòu)這其實(shí)是“靜態(tài)圖”和“動(dòng)態(tài)圖”的問題。訓(xùn)練時(shí)用的是動(dòng)態(tài)圖方便調(diào)試保存推理模型時(shí)用的是靜態(tài)圖把計(jì)算邏輯固化下來。.pdmodel文件就是序列化后的靜態(tài)計(jì)算圖包含所有算子和權(quán)重.pdiparams是權(quán)重文件。Paddle Inference加載模型時(shí)會(huì)做一系列圖優(yōu)化比如算子融合、常量折疊這些優(yōu)化由一系列pass組成。你可以通過config.SwitchIrOptimization(true)或false來開啟或關(guān)閉。我建議默認(rèn)開啟尤其是在GPU TensorRT模式下圖優(yōu)化對性能影響很大。有時(shí)你會(huì)在日志里看到類似“I1125 09:00:01.123456 12345 analysis_predictor.cc:99] Optimize to PaddlePredictor...”的信息這說明圖優(yōu)化生效了。如果模型加載后推理結(jié)果不對可以試著SwitchIrOptimization(false)跑一遍對比結(jié)果看是不是優(yōu)化pass引入的問題。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 用C跑通一個(gè)圖像分類模型的全流程實(shí)錄為了減少變量我用PaddleClas里的MobileNetV3作為示例模型流程如下。第一準(zhǔn)備模型。如果你手頭沒有Paddle模型可以用一行Python代碼導(dǎo)出一個(gè)示例模型import paddle import paddle.vision.models as models model models.mobilenet_v3_small(num_classes1000) model.eval() # 構(gòu)造一個(gè)示例輸入用于固定輸入shape input_spec [paddle.static.InputSpec(shape[-1, 3, 224, 224], dtypefloat32, nameinput)] paddle.jit.save(model, mobilenetv3, input_specinput_spec, output_specNone)這樣會(huì)生成mobilenetv3.pdmodel和mobilenetv3.pdiparams兩個(gè)文件。第二把模型文件放好。我在D盤建了一個(gè)項(xiàng)目目錄結(jié)構(gòu)是D:\paddle_demo\ ├── CMakeLists.txt ├── main.cpp ├── models\ │ ├── mobilenetv3.pdmodel │ └── mobilenetv3.pdiparams └── build\第三編譯工程。在VS2019的“x64 Native Tools Command Prompt”里執(zhí)行cd D:\paddle_demo mkdir build cd build cmake .. -G Visual Studio 16 2019 -A x64 -DPADDLE_INFER_DIRD:/paddle_inference cmake --build . --config Release編譯成功后在build\Release目錄下會(huì)生成paddle_demo.exe。執(zhí)行前確保paddle_inference.dll、cudnn64_8.dll、nvinfer.dll等動(dòng)態(tài)庫都能被找到最保險(xiǎn)的做法是寫一個(gè)bat腳本把這些dll全部復(fù)制到exe同目錄下或者啟動(dòng)前臨時(shí)設(shè)置PATH。第四運(yùn)行。程序跑起來后觀察輸出日志如果能看到Paddle版本信息和模型加載日志基本就通了。遇到問題時(shí)先看日志尾部錯(cuò)誤碼Paddle的錯(cuò)誤碼通常帶有EROR或FATAL字樣直接定位。4.2 CPU推理與MKLDNN的配置細(xì)節(jié)GPU在大多數(shù)服務(wù)器上都有但開發(fā)調(diào)試階段CPU推理反而更常用。Paddle Inference在x86平臺上開啟MKLDNN即oneDNN前身是MKL-DNN后CPU算子的性能提升非常明顯尤其是卷積和矩陣乘。開啟方式非常簡單config.EnableMKLDNN(); config.SetCpuMathLibraryNumThreads(8);SetCpuMathLibraryNumThreads用于設(shè)置CPU線程數(shù)默認(rèn)是物理核心數(shù)。這個(gè)值不是越大越好因?yàn)榫€程切換和內(nèi)存帶寬都會(huì)成為瓶頸我實(shí)測8線程左右對大部分模型性價(jià)比最高。多路CPU的服務(wù)器可能會(huì)更復(fù)雜建議按模型benchmark去搜一下最佳線程數(shù)。MKLDNN模式下Paddle會(huì)自動(dòng)把部分算子替換為oneDNN實(shí)現(xiàn)圖優(yōu)化中也會(huì)多做一層算子融合。還有一個(gè)附加開關(guān)是EnableMKLDNNQuantizer用于INT8量化但一般需要校準(zhǔn)數(shù)據(jù)集工程上用得少。4.3 TensorRT加速的完整開啟方式與參數(shù)選擇TensorRT是GPU推理的核心加速手段。在上面示例代碼里我用了EnableTensorRtEngine但這里有幾個(gè)參數(shù)值得單獨(dú)展開。第一個(gè)參數(shù)workspace_size單位是字節(jié)它表示TensorRT允許使用的顯存上限。設(shè)置太大可能會(huì)因?yàn)轱@存不足導(dǎo)致TensorRT初始化失敗設(shè)置太小TensorRT因?yàn)闊o法執(zhí)行某些優(yōu)化策略性能會(huì)打折扣。我的習(xí)慣是把值設(shè)為顯存大小的三分之一到二分之一比如8GB顯存就設(shè)1GB到2GB左移30位是1GB。第二個(gè)參數(shù)batch_size這是“最優(yōu)batch數(shù)”等于1表示主要優(yōu)化batch1的推理。如果你的業(yè)務(wù)并發(fā)batch是固定的比如batch8這里最好設(shè)置為8TensorRT會(huì)依據(jù)這個(gè)size做kernel選擇。第三個(gè)參數(shù)min_subgraph_size這是子圖融合的最小節(jié)點(diǎn)數(shù)。Paddle會(huì)把支持TensorRT的算子組合成子圖子圖內(nèi)的算子在TensorRT上執(zhí)行子圖外的算子留在Paddle上。min_subgraph_size太小時(shí)一個(gè)單獨(dú)的算子也會(huì)被調(diào)去TensorRT性能反而下降因?yàn)榇罅啃∷阕訒?huì)有額外傳輸開銷太大會(huì)導(dǎo)致TensorRT覆蓋的算子太少加速效果不明顯。官方默認(rèn)值一般在3到5實(shí)踐下來10左右比較均衡。PrecisionType可以選擇kFloat32、kHalf、kInt8。如果對精度要求較高比如醫(yī)療圖像用kFloat32對性能敏感但精度容忍度還行用kHalf也就是FP16。kInt8需要額外校準(zhǔn)數(shù)據(jù)前向inference時(shí)還需要在use_calib_mode參數(shù)設(shè)為true否則可能報(bào)錯(cuò)。另外TensorRT支持序列化engine文件即靜態(tài)engine可以避免每次啟動(dòng)都重新構(gòu)建engine。Paddle里對應(yīng)的是config.EnableTensorRtEngine時(shí)設(shè)置use_statictrue這樣會(huì)把優(yōu)化后的engine緩存到本地文件下次啟動(dòng)直接加載。這個(gè)緩存跟模型、輸入shape、TensorRT版本、顯卡型號都強(qiáng)相關(guān)換環(huán)境或改shape之后一定要?jiǎng)h除緩存否則會(huì)報(bào)“inconsistency”錯(cuò)誤。4.4 動(dòng)態(tài)Shape場景下的TensorRT配置很多實(shí)際部署場景比如檢測模型的輸入shape是動(dòng)態(tài)的例如一張圖可以是大是小。TensorRT對動(dòng)態(tài)shape支持得比靜態(tài)shape復(fù)雜需要在配置時(shí)顯式指定三個(gè)維度范圍min_shape、opt_shape、max_shape。Paddle Inference的接口是config.EnableTensorRtEngine(workspace_size, max_batch_size, min_subgraph_size, precision, use_static, use_calib_mode); config.SetTRTDynamicShapeInfo(min_input_shape, max_input_shape, opt_input_shape, disable_trt_plugin_fp16);其中min_input_shape、opt_input_shape、max_input_shape都是mapkey是輸入張量名value是對應(yīng)shape。舉個(gè)栗子一個(gè)[None, 3, None, None]的輸入std::mapstd::string, std::vectorint min_shape {{input, {1, 3, 32, 32}}}; std::mapstd::string, std::vectorint opt_shape {{input, {1, 3, 448, 448}}}; std::mapstd::string, std::vectorint max_shape {{input, {1, 3, 960, 960}}};這個(gè)配置決定了TensorRT在運(yùn)行時(shí)能接受的輸入范圍。如果輸入超出了max_shape直接會(huì)報(bào)維度錯(cuò)誤如果輸入在min和max之間TensorRT會(huì)嘗試在opt_shape附近做優(yōu)化所以opt值要盡量接近你的真實(shí)輸入尺寸分布中心。動(dòng)態(tài)shape還帶來一個(gè)隱性風(fēng)險(xiǎn)子圖劃分策略在不同shape下可能不同導(dǎo)致同一個(gè)算子有時(shí)在TensorRT里、有時(shí)在Paddle里執(zhí)行表現(xiàn)出的性能差異較大。所以線上服務(wù)如果輸入尺寸波動(dòng)很大建議還是固定到幾個(gè)離散的尺寸規(guī)格比如通過resize統(tǒng)一到448x448或960x960穩(wěn)定性和性能都更好。5. 常見問題與排查技巧實(shí)錄5.1 常見錯(cuò)誤速查表我把實(shí)際部署中遇到的錯(cuò)誤整理成一張表方便大家對照排查。錯(cuò)誤現(xiàn)象可能原因解決方案運(yùn)行時(shí)提示找不到paddle_inference.dll動(dòng)態(tài)庫路徑未加入PATH把paddle/lib加到PATH或拷貝dll到exe目錄提示找不到cudnn64_8.dllcuDNN未安裝或版本不匹配檢查bin目錄下是否存在cudnn64_8.dll復(fù)制到系統(tǒng)PATH初始化GPU時(shí)卡死或報(bào)cudaErrorInsufficientDriver顯卡驅(qū)動(dòng)版本過低更新驅(qū)動(dòng)至525.60.13以上編譯時(shí)無法解析paddle::AnalysisConfig鏈接庫時(shí)找不到paddle_inference.lib檢查CMake鏈接的lib路徑是否寫對用絕對路徑最穩(wěn)運(yùn)行時(shí)報(bào)非法指令I(lǐng)llegal instructionCPU不支持AVX指令集換成支持AVX的機(jī)器或下載noavx版本TensorRT engine初始化失敗TensorRT DLL版本不匹配確認(rèn)nvinfer.dll版本為8.5.1.x且CUDA版本是11.8推理結(jié)果全是0或NaNvector未正確分配空間或輸入數(shù)據(jù)異常檢查輸出tensor的shape分配空間后再CopyToCpu顯存不足CUDA out of memory顯存被其他進(jìn)程占用或workspace_size過大減小EnableUseGpu的預(yù)分配或關(guān)閉其他GPU進(jìn)程日志中出現(xiàn)算子不支持TensorRT當(dāng)前模型某些算子無法被TensorRT識別調(diào)大min_subgraph_size讓不支持的算子留在Paddle里執(zhí)行注意這張表只覆蓋了最常見的問題。實(shí)際上Windows環(huán)境的問題千奇百怪比如殺毒軟件刪dll、動(dòng)態(tài)庫搜索路徑失效、顯卡驅(qū)動(dòng)被系統(tǒng)更新覆蓋等等遇到問題時(shí)先冷靜逐層排查。5.2 DLL加載順序的坑與解決方案Windows加載動(dòng)態(tài)庫的順序是exe所在目錄 - 系統(tǒng)目錄 - system32 - PATH環(huán)境變量。這帶來一個(gè)問題如果系統(tǒng)里殘留了舊版本的cuda DLL或cudnn DLLPaddle可能會(huì)加載到錯(cuò)誤的版本導(dǎo)致莫名其妙的行為。我遇到過的一個(gè)典型案例機(jī)器上裝了Anacondaconda環(huán)境里有自己的一套cudnn加上Paddle的third_party目錄里也有一份dll還有系統(tǒng)裝的CUDA 11.8三份dll一起出現(xiàn)程序運(yùn)行時(shí)根本不知道加載了哪一份。解決方法是在啟動(dòng)exe的bat腳本里顯式把Paddle依賴的DLL目錄放到PATH最前面同時(shí)把conda的Library\bin挪到后面。更激進(jìn)的做法是把工程需要的dll全部拷貝到exe目錄做到一個(gè)目錄全含。另外TeamViewer等遠(yuǎn)程軟件或圖形驅(qū)動(dòng)會(huì)注入一部分庫到進(jìn)程中這類庫跟CUDA本無關(guān)系但偶爾會(huì)改變DLL搜索路徑優(yōu)先級。遇到玄學(xué)問題可以先在干凈環(huán)境下測試。5.3 顯存不足與顯存碎片化的排查思路GPU推理的顯存管理是個(gè)經(jīng)典問題。Paddle Inference默認(rèn)用緩存分配器預(yù)分配顯存后不會(huì)馬上歸還給驅(qū)動(dòng)這跟訓(xùn)練框架類似。在EnableUseGpu里指定的第一個(gè)參數(shù)就是預(yù)分配大小。顯存不足的常見情況推理進(jìn)程啟動(dòng)很慢顯存占用持續(xù)上漲最終報(bào)CUDA out of memory。這時(shí)候先確認(rèn)是不是有多個(gè)GPU進(jìn)程在跑Windows下可以用nvidia-smi查看GPU占用。如果只有一個(gè)進(jìn)程看看是不是模型過大或者TensorRT構(gòu)建engine時(shí)臨時(shí)分配了大量顯存。有時(shí)候訓(xùn)練和推理共用GPU也會(huì)導(dǎo)致沖突。比如顯存只有6GB訓(xùn)練任務(wù)占了5.5GB推理任務(wù)只有500MB可用任何模型都會(huì)OOM。建議配置GPU隔離Windows下一般用環(huán)境變量CUDA_VISIBLE_DEVICES來切換但注意這個(gè)變量在多進(jìn)程場景下要提前設(shè)置好別在代碼里改。如果你想在推理進(jìn)程退出時(shí)完整釋放顯存Paddle提供了paddle_infer::Predictor::ClearInterpreter之類的方法但更實(shí)用的做法是直接調(diào)用config.EnableMemoryOptim(true)開啟內(nèi)存優(yōu)化。這個(gè)選項(xiàng)讓Paddle在算子執(zhí)行前后復(fù)用顯存峰值占用能明顯下降但代價(jià)是增加一點(diǎn)調(diào)度開銷實(shí)際推理性能幾乎無影響。5.4 多模型加載與單例Predictor的設(shè)計(jì)建議實(shí)際項(xiàng)目里很少只跑一個(gè)模型通常會(huì)同時(shí)加載多個(gè)模型或者同一個(gè)模型多個(gè)實(shí)例。Paddle每個(gè)Predictor對應(yīng)一份模型實(shí)例它們之間的顯存和線程是獨(dú)立的所以要注意整體資源控制。我比較推薦的做法是每個(gè)模型建立一個(gè)Predictor池池的大小根據(jù)并發(fā)請求確定。Predictor本身不是線程安全的多個(gè)線程并發(fā)執(zhí)行Run可能會(huì)有問題最安全的方式是每個(gè)線程持有自己的Predictor實(shí)例。Paddle內(nèi)部有一些線程池和常量優(yōu)化如果你有很多Predictor實(shí)例每個(gè)實(shí)例都會(huì)初始化一遍圖優(yōu)化和算子顯存和CPU開銷會(huì)翻幾倍。解決辦法是提前構(gòu)建好TensorRT靜態(tài)engine并緩存避免重復(fù)構(gòu)建。還有一種方案是把多模型融合成一個(gè)模型在某些場景下可行但通用性不高。實(shí)際操作中我通常把模型按業(yè)務(wù)模塊拆分用獨(dú)立的Predictor管理類統(tǒng)一控制生命周期在服務(wù)啟動(dòng)時(shí)預(yù)加載避免運(yùn)行時(shí)頻繁創(chuàng)建銷毀。6. 性能調(diào)優(yōu)從能用變成好用6.1 CPU與GPU推理的取舍很多人拿到Paddle Inference就默認(rèn)用GPU其實(shí)小模型在CPU上可能更快。這涉及一個(gè)基礎(chǔ)概念GPU的延遲不一定比CPU低但吞吐量遠(yuǎn)高于CPU。對于batch1的低延遲場景CPU可能反而有優(yōu)勢因?yàn)椴恍枰截悢?shù)據(jù)到GPU。所以如果你的模型很小比如幾百M(fèi)B的輕量模型且請求量不大CPU推理就夠了MKLDNN開啟后性能也很可觀。跑benchmark時(shí)我習(xí)慣于反復(fù)預(yù)熱后再計(jì)時(shí)因?yàn)镃UDA運(yùn)行時(shí)、TensorRT engine構(gòu)建、Paddle圖優(yōu)化這些都會(huì)在第一次推理時(shí)發(fā)生導(dǎo)致第一次很慢。Paddle也提供了config.SwitchIrOptimization(true)和預(yù)熱循環(huán)的配合用10到20次無關(guān)推理把運(yùn)行時(shí)狀態(tài)跑熱再統(tǒng)計(jì)真實(shí)延遲。6.2 TensorRT與Paddle算子融合的細(xì)節(jié)觀察當(dāng)啟用TensorRT引擎時(shí)Paddle并不會(huì)把所有算子全部交給TensorRT而是先做圖分析把支持的部分切成子圖再交給TensorRT。這意味著最終推理圖可能是“Paddle原生算子 TensorRT子圖”混合的。如果你想知道哪些子圖被切到了TensorRT可以打開調(diào)試日志config.EnableDebug(); config.SwitchIrDebug(true);日志里會(huì)打印pass執(zhí)行情況包括每個(gè)子圖的算子數(shù)量、輸入輸出張量。我常常通過這個(gè)日志判斷為什么某些模型TensorRT加速效果不明顯——往往是因?yàn)榍谐鰜淼淖訄D太小TensorRT根本來不及發(fā)揮優(yōu)化能力。一個(gè)模型如果全是卷積和pooling子圖會(huì)非常大TensorRT加速效果顯著。如果模型里有大量自定義算子、控制流if/loop或動(dòng)態(tài)shape操作子圖會(huì)被切得很碎加速效果大打折扣。這不算錯(cuò)誤只是性能優(yōu)化的約束條件。6.3 顯存預(yù)分配、緩存與批處理的高級調(diào)優(yōu)對于高吞吐場景比如推薦系統(tǒng)或者視頻流處理盡量使用batch推理。Paddle Inference支持動(dòng)態(tài)batch但你需要手動(dòng)拼接輸入數(shù)據(jù)。一張一張推理和批量推理吞吐量差距可能達(dá)到5到10倍尤其是GPU上。一個(gè)常見的誤區(qū)把batch設(shè)得越大越好。實(shí)際上batch太大TensorRT在kernel選擇時(shí)會(huì)傾向并行度更高的策略但模型本身有內(nèi)存帶寬限制超過某個(gè)閾值后吞吐不再增長反而會(huì)因?yàn)轱@存不足報(bào)錯(cuò)。我一般用nvidia-smi看顯存殘量找到batch的上界。還可以考慮多流推理。Paddle對單卡多流的支持比較有限但你可以自己開多個(gè)線程每個(gè)線程一個(gè)Predictor分別跑不同的batch間接實(shí)現(xiàn)多流并行。這種情況下要注意所有Predictor共享同一塊GPU顯存總量要精打細(xì)算。6.4 從Windows到Linux的遷移注意事項(xiàng)雖然本文圍繞Windows展開但很多生產(chǎn)服務(wù)器是Linux。Paddle Inference的Linux預(yù)編譯包同樣有對應(yīng)的版本遷移時(shí)主要注意幾個(gè)點(diǎn)。第一動(dòng)態(tài)庫后綴不同。Windows是dllLinux是so。代碼里不要硬編碼路徑盡量用配置或相對路徑。第二Linux下cuDNN和TensorRT的安裝路徑不同通常用軟鏈接管理版本。第三CUDA的運(yùn)行時(shí)庫搜索路徑是rpath和LD_LIBRARY_PATH需要導(dǎo)出環(huán)境變量。第四Linux下沒有Visual Studio但GCC/G版本要跟預(yù)編譯包要求對應(yīng)一般Paddle官方推薦GCC 8.2以上的版本。我個(gè)人的建議是Windows版用于本地開發(fā)和單機(jī)驗(yàn)證一旦確認(rèn)模型和推理邏輯無誤就用Linux版部署到服務(wù)器。因?yàn)閃indows和Linux的TensorRT engine緩存不通用正式環(huán)境用Linux的包重新構(gòu)建一次engine緩存才能保證最優(yōu)性能。7. 寫在最后的經(jīng)驗(yàn)之談這套Paddle Inference環(huán)境我已經(jīng)在好幾個(gè)項(xiàng)目里用過了一個(gè)非常深刻的感受是版本對齊就是最大的坑但也是最好解決的問題。只要你嚴(yán)格按照CUDA 11.8 cuDNN 8.6.0 TensorRT 8.5.1.7 VS2019這套組合去裝依賴版本兼容性問題會(huì)少很多。反而是那些“順便升級一下”的操作比如把cuDNN從8.6升到8.9、把TensorRT從8.5升到8.6容易引發(fā)各種dll不匹配。另外一個(gè)心得是不要過度依賴預(yù)編譯包里自帶的third_party目錄。它只是把Paddle需要的一些第三方庫打個(gè)包方便你不用單獨(dú)下載MKL之類的東西但CUDA和cuDNN這種重量級依賴還是得你手動(dòng)裝好把環(huán)境弄得干凈可控才是正道。如果你把這個(gè)zip當(dāng)成“解壓就能用”的黑盒那多半會(huì)遇到一堆問題。但如果把它當(dāng)成“Paddle Inference的Windows版本參考實(shí)現(xiàn)”對照著它的編譯選項(xiàng)去配置自己的環(huán)境很多問題就能系統(tǒng)性地避開。我一般會(huì)在項(xiàng)目里寫一個(gè)configure.bat把PATH、MKL、TensorRT、CUDA的路徑全部設(shè)置好每次開新終端都執(zhí)行一遍比手動(dòng)改環(huán)境變量穩(wěn)定多了。最后再提一個(gè)小技巧在Windows上萬一遇到奇怪崩潰先試試把Compile with AVX對應(yīng)的運(yùn)行庫CPU指令集匹配問題排除掉老的CPU比如一些低功耗的奔騰、賽揚(yáng)真的可能不支持AVX換成noavx版本的Paddle Inference包會(huì)立刻解決。這個(gè)坑我?guī)屯屡挪檫^兩次每次都是CPU硬件太老不是代碼的問題。本文還有配套的精品資源點(diǎn)擊獲取 Paddle Inference Windows部署實(shí)戰(zhàn)：CUDA/cuDNN/TensorRT版本匹配與C++推理
簡介本資源是面向Windows平臺AI推理開發(fā)者的Paddle Inference 3.0.0預(yù)編譯開發(fā)包專為需快速集成高性能深度學(xué)習(xí)推理能力的C工程而優(yōu)化適用于模型部署、邊緣計(jì)算及工業(yè)級服務(wù)開發(fā)等場景。壓縮包共623個(gè)文件涵蓋569個(gè)頭文件h/hpp用于接口調(diào)用與類型定義13個(gè)靜態(tài)庫lib和2個(gè)導(dǎo)出文件exp支撐鏈接構(gòu)建5個(gè)核心DLL如paddle_inference.dll、mklml.dll、mkldnn.dll提供運(yùn)行時(shí)推理引擎與數(shù)學(xué)加速能力另有proto與pb文件支持模型序列化解析整體體積達(dá)528.04MB。內(nèi)容預(yù)覽顯示其深度整合Intel MKL含lapacke.h等數(shù)學(xué)接口、CUDA 11.8、cuDNN 8.6.0及TensorRT 8.5.1.7具備AVX指令集優(yōu)化與VS2019兼容性。目前已有132人下載學(xué)習(xí)開箱即用省去復(fù)雜環(huán)境編譯與依賴適配過程顯著降低Windows下PaddlePaddle C推理部署門檻。 拿到這個(gè)文件名的時(shí)候我第一反應(yīng)是這是一臺Windows機(jī)器的Paddle Inference推理環(huán)境全家桶。x86-64-cuda11.8-cudnn8.6.0-trt8.5.1.7-mkl-avx-vs2019-paddle-inference-3.0.0.zip光看名字就能拆出七八個(gè)關(guān)鍵信息。如果你是做深度學(xué)習(xí)模型部署的或者剛接手一個(gè)C推理項(xiàng)目看到這種預(yù)編譯包時(shí)最怕的不是別的就是版本對不上、DLL缺一堆、跑起來直接崩。這篇文章就圍繞這個(gè)包把我實(shí)際部署Paddle Inference時(shí)踩過的坑、驗(yàn)證過的步驟、調(diào)過的參數(shù)全部梳理一遍從環(huán)境匹配講到推理代碼再到TensorRT加速和常見報(bào)錯(cuò)排查爭取讓你拿到包之后能一口氣跑通。先說這個(gè)包具體能干什么。Paddle Inference是PaddlePaddle的官方高性能推理引擎跟訓(xùn)練框架解耦專門為上線部署優(yōu)化。這個(gè)zip是預(yù)編譯好的Windows x64版本編譯時(shí)用的是CUDA 11.8、cuDNN 8.6.0、TensorRT 8.5.1.7同時(shí)開啟了MKL數(shù)學(xué)庫和AVX指令集構(gòu)建環(huán)境對應(yīng)VS2019。什么意思呢就是說只要你的機(jī)器滿足這些依賴版本解壓這個(gè)包配置好環(huán)境變量和CMake工程就能直接做GPU加速的模型推理完全不需要自己從源碼編譯Paddle省下幾個(gè)小時(shí)甚至一整天的編譯時(shí)間。適合誰看剛?cè)胄凶瞿Ｐ筒渴鸬墓こ處?、需要在Windows上集成Paddle推理到C項(xiàng)目的同學(xué)以及被各種CUDA/cuDNN版本折磨過的老哥。1. 內(nèi)容整體設(shè)計(jì)與拆解思路1.1 文件名里的版本矩陣代表什么先把這個(gè)文件名當(dāng)密碼一樣逐段拆開看。x86-64平臺架構(gòu)表示64位x86指令集幾乎所有現(xiàn)代Intel和AMD處理器都適用。如果你的機(jī)器是ARM架構(gòu)比如部分Windows平板、Surface Pro X這個(gè)包就用不了。cuda11.8NVIDIA CUDA Toolkit的版本號。推理庫編譯時(shí)鏈接的是CUDA 11.8的運(yùn)行時(shí)庫意味著你的機(jī)器上必須安裝CUDA 11.8或者更新但兼容的版本向下兼容方面一般驅(qū)動(dòng)版本不能低于525.60.13具體看NVIDIA官方文檔。這里有個(gè)常見誤區(qū)CUDA有兩個(gè)概念一個(gè)是顯卡驅(qū)動(dòng)自帶的運(yùn)行時(shí)兼容層一個(gè)是獨(dú)立的Toolkit后面會(huì)細(xì)說。cudnn8.6.0NVIDIA cuDNN深度學(xué)習(xí)原語庫版本。CUDA負(fù)責(zé)通用并行計(jì)算cuDNN專門對卷積、池化、歸一化等神經(jīng)網(wǎng)絡(luò)核心算子做了深度優(yōu)化兩者配合才能發(fā)揮GPU的性能。trt8.5.1.7TensorRT版本。這是NVIDIA的高性能推理優(yōu)化器能把訓(xùn)練好的模型做層融合、精度校準(zhǔn)、動(dòng)態(tài)shape優(yōu)化再生成推理引擎。Paddle Inference啟用TensorRT之后某些模型的推理延遲可以再降30%到50%。mklIntel Math Kernel Library數(shù)學(xué)核心庫。CPU上跑算子的時(shí)候會(huì)用MKL加速矩陣乘法、卷積等計(jì)算。Paddle Inference在CPU模式下如果沒有MKL性能會(huì)差挺多這個(gè)包默認(rèn)帶上了。avxAdvanced Vector ExtensionsCPU指令集。AVX允許CPU單條指令處理多個(gè)浮點(diǎn)數(shù)據(jù)Paddle為這個(gè)指令集專門優(yōu)化過算子跑CPU推理時(shí)速度提升明顯。注意如果你的老舊CPU不支持AVX這個(gè)包會(huì)直接報(bào)非法指令錯(cuò)誤。vs2019構(gòu)建工具鏈版本Visual Studio 2019。這個(gè)主要影響你編譯C程序時(shí)MSVC運(yùn)行時(shí)版本如果你用VS2015或VS2017去鏈接這個(gè)庫大概率會(huì)遇到運(yùn)行時(shí)庫沖突或者符號解析失敗。paddle-inference-3.0.0Paddle Inference主版本號。3.0.0是相對較新的版本API設(shè)計(jì)和舊版有差異最明顯的是頭文件引用方式變了后面代碼部分會(huì)展示。zip打包格式Windows下直接用解壓工具解壓即可。一句話總結(jié)這個(gè)包是Paddle Inference團(tuán)隊(duì)在特定軟硬件環(huán)境下編譯出來的產(chǎn)物想用好它你的開發(fā)機(jī)環(huán)境要跟這個(gè)版本矩陣對齊。1.2 CUDA、cuDNN、TensorRT三者的“鐵三角”關(guān)系很多人分不清CUDA、cuDNN、TensorRT的關(guān)系我打個(gè)比方。CUDA Toolkit相當(dāng)于GPU的“操作系統(tǒng)API”你寫CUDA代碼、編譯GPU程序、管理顯存都靠它。顯卡驅(qū)動(dòng)是“硬件驅(qū)動(dòng)層”CUDA Toolkit是“用戶態(tài)開發(fā)庫”兩者有對應(yīng)關(guān)系驅(qū)動(dòng)包含一個(gè)兼容層只要驅(qū)動(dòng)版本夠新就能運(yùn)行較舊版本的CUDA Toolkit編譯出來的程序。cuDNN是構(gòu)建在CUDA之上的“深度神經(jīng)網(wǎng)絡(luò)加速庫”它把卷積、LSTM等常用算子優(yōu)化到極致訓(xùn)練和推理框架都會(huì)調(diào)用它。Paddle推理庫編譯時(shí)指定cuDNN 8.6.0運(yùn)行時(shí)就會(huì)去找對應(yīng)版本的cudnn64_8.dll。TensorRT則更上層它是個(gè)“推理引擎優(yōu)化器”。它不關(guān)心你怎么訓(xùn)練模型只負(fù)責(zé)把訓(xùn)練好的模型轉(zhuǎn)換成推理引擎通過層融合、kernel自動(dòng)調(diào)優(yōu)、FP16/INT8量化等手段壓縮推理耗時(shí)。Paddle Inference跑GPU推理時(shí)要啟用TensorRT就必須在運(yùn)行時(shí)加載TensorRT的動(dòng)態(tài)庫nvinfer.dll等版本跟編譯時(shí)保持一致或兼容否則會(huì)報(bào)算子不匹配或版本不兼容的錯(cuò)。這三者的匹配邏輯是驅(qū)動(dòng) CUDA Toolkit cuDNN版本可接受范圍 TensorRT版本可接受范圍。實(shí)際部署中最讓人頭疼的就是dll版本沖突老版本和新版本往往只差一兩個(gè)小版本號但行為卻截然不同。1.3 為什么需要預(yù)編譯的Paddle Inference包可能有人會(huì)問直接pip install paddlepaddle-gpu不就行了對于Python調(diào)用確實(shí)簡單但C部署場景完全不同。首先C推理需要的是靜態(tài)庫和頭文件pip包里雖然有但接口不穩(wěn)定、沒有頭文件、不方便鏈接。其次Paddle Inference源碼編譯在Windows下極其痛苦要裝Python、CMake、VS2019、CUDA、cuDNN、TensorRT還要處理各種依賴沖突編譯一次少說兩小時(shí)。預(yù)編譯包相當(dāng)于把這些都辦好你的任務(wù)只是“解壓 配置 鏈接”。從工程視角看預(yù)編譯包還能保證推理行為的一致性你自己編譯的庫可能因?yàn)榫幾g選項(xiàng)不同算出的結(jié)果有細(xì)微差異但官方預(yù)編譯的版本是統(tǒng)一優(yōu)化過的批量部署時(shí)更可控。2. 環(huán)境配置從零準(zhǔn)備CUDA 11.8、cuDNN和TensorRT2.1 Windows下安裝CUDA 11.8的完整步驟很多人在Windows裝CUDA時(shí)翻車主要原因是把“顯卡驅(qū)動(dòng)”和“CUDA Toolkit”混為一談。實(shí)際上如果你只是要跑現(xiàn)成的Paddle推理包NVIDIA驅(qū)動(dòng)里已經(jīng)包含了最低限度的CUDA運(yùn)行時(shí)兼容庫但頭文件、nvcc編譯器、開發(fā)庫必須額外裝Toolkit。第一步檢查顯卡驅(qū)動(dòng)。打開NVIDIA控制面板左下角“系統(tǒng)信息”里能看到驅(qū)動(dòng)版本。CUDA 11.8要求驅(qū)動(dòng)版本至少525.60.13如果驅(qū)動(dòng)太老后面加載cuda runtime的時(shí)候會(huì)報(bào)找不到入口點(diǎn)或版本不兼容。驅(qū)動(dòng)更新就直接去NVIDIA官網(wǎng)下載Game Ready或Studio驅(qū)動(dòng)都可以開發(fā)機(jī)建議用Studio驅(qū)動(dòng)穩(wěn)定性更好。第二步下載CUDA Toolkit 11.8。到NVIDIA官網(wǎng)的CUDA Toolkit Archive頁面選擇11.8版本W(wǎng)indows x86_64的exe安裝包大概2.8GB。安裝時(shí)選擇“自定義”把CUDA下的“Visual Studio Integration”選上其他組件默認(rèn)。注意安裝路徑不要有中文和空格我習(xí)慣用默認(rèn)的C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8。第三步驗(yàn)證安裝。打開命令行cmd或PowerShell輸入nvcc -V如果正常輸出版本信息說明Toolkit安裝成功。這里我遇到過一個(gè)問題裝完CUDA后命令行輸入nvcc提示不是內(nèi)部或外部命令原因是沒有把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bin加到系統(tǒng)環(huán)境變量PATH里。重新配置環(huán)境變量后重開命令行即可。還有一個(gè)非常常見的坑CUDA安裝的時(shí)候提示需要VS的某類組件如果你機(jī)器上裝的是VS2022而不是VS2019也沒關(guān)系CUDA 11.8對VS2022也有一定支持只是官方在VS2019下驗(yàn)證得最充分。Paddle這個(gè)包標(biāo)注VS2019不代表VS2022不能用只是建議盡量接近構(gòu)建環(huán)境減少鏈接時(shí)的小問題。2.2 cuDNN 8.6.0下載與部署cuDNN的安裝比CUDA簡單本質(zhì)上就是往CUDA目錄里放幾個(gè)文件。到NVIDIA cuDNN Archive頁面選擇Download cuDNN v8.6.0 for CUDA 11.xWindows版本下載得到一個(gè)zip壓縮包。解壓后里面有3個(gè)文件夾bin、include、lib。操作邏輯很直接把bin里的cudnn64_8.dll復(fù)制到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bininclude里的cudnn.h復(fù)制到對應(yīng)的include目錄lib里的cudnn.lib復(fù)制到lib\x64目錄。復(fù)制的時(shí)候記得管理員權(quán)限。驗(yàn)證方式有兩個(gè)。第一查看C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bin下是否存在cudnn64_8.dll第二在命令行執(zhí)行nvidia-smi如果驅(qū)動(dòng)正常再執(zhí)行一個(gè)小的CUDA樣本程序比如bandwidthTest.exe能通過就說明CUDA環(huán)境沒問題cuDNN因?yàn)槭莿?dòng)態(tài)庫只有真正跑深度學(xué)習(xí)推理時(shí)才會(huì)被調(diào)用。關(guān)于cuDNN我多說一句版本號中數(shù)字的兼容性比你想象中嚴(yán)格。比如cuDNN 8.6.0生成的動(dòng)態(tài)庫名為cudnn64_8.dll其中“64_8”表示64位平臺、支持CUDA 11.x的API。如果你換成cudnn 8.9.x文件名可能會(huì)變成cudnn64_9.dll此時(shí)Paddle Inference編譯時(shí)鏈接的還是cudnn64_8這個(gè)導(dǎo)入庫運(yùn)行時(shí)就會(huì)報(bào)找不到dll。所以不要隨便升級cuDNN。2.3 TensorRT 8.5.1.7的安裝與環(huán)境配置TensorRT的安裝也是解壓式。到NVIDIA TensorRT Archive頁面下載TensorRT 8.5.1.7 for Windows x86_64 and CUDA 11.0, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7, 11.8的zip包解壓到一個(gè)你方便找到的路徑比如D:\TensorRT-8.5.1.7。TensorRT包里面包括bin目錄trtexec等工具、include目錄頭文件、lib目錄dll和導(dǎo)入庫、還有python包目錄。我們的核心任務(wù)是把lib目錄加入PATH或者把dll復(fù)制到安全位置。Paddle Inference運(yùn)行時(shí)加載TensorRT是動(dòng)態(tài)加載的它會(huì)在默認(rèn)路徑和PATH中查找nvinfer.dll、nvonnxparser.dll等文件。所以最簡單的方法是把D:\TensorRT-8.5.1.7\lib加到系統(tǒng)環(huán)境變量PATH里并確保在PATH中的位置比較靠前。如果你在開發(fā)機(jī)上不想污染全局環(huán)境也可以在做CMake工程時(shí)通過cmake變量把TensorRT路徑傳進(jìn)去運(yùn)行exe前在腳本里加一下PATH。TensorRT還有個(gè)小坑它在運(yùn)行時(shí)需要額外的CUDA驅(qū)動(dòng)支持如果你用了精簡版驅(qū)動(dòng)或者老驅(qū)動(dòng)初始化TensorRT時(shí)會(huì)卡在加載cudart64_11.dll。所以再次確認(rèn)驅(qū)動(dòng)版本別低于525.60.13。2.4 驗(yàn)證整套環(huán)境是否匹配在開始寫代碼之前先用最簡單的方式驗(yàn)證一下環(huán)境。打開命令行依次執(zhí)行nvcc -V確認(rèn)CUDA 11.8。where cudnn64_8.dll如果能找到路徑說明cuDNN在PATH里。where nvinfer.dll確認(rèn)TensorRT核心庫可見。另外可以用TensorRT自帶的trtexec工具做一次快速自檢比如加載一個(gè)ONNX模型轉(zhuǎn)成engine能跑通說明TensorRT初始化正常D:\TensorRT-8.5.1.7\bin\trtexec.exe --onnxyour_model.onnx --saveEnginetest.engine如果這個(gè)命令報(bào)錯(cuò)先別查Paddle大概率是TensorRT環(huán)境本身的問題早點(diǎn)發(fā)現(xiàn)早點(diǎn)排查。整個(gè)環(huán)境配置下來我的經(jīng)驗(yàn)是能不改系統(tǒng)PATH就盡量不改所有的依賴庫通過拷貝dll到指定目錄的方式管理項(xiàng)目可控性更高。但既然做開發(fā)PATH方式最省事二選一即可。3. Paddle Inference 3.0.0的工程集成與推理實(shí)現(xiàn)3.1 解壓并理解預(yù)編譯包的目錄結(jié)構(gòu)把下載的zip解壓后你會(huì)看到類似這樣的目錄結(jié)構(gòu)paddle_inference/ ├── paddle/ │ ├── include/ │ │ ├── paddle_analysis_config.h │ │ ├── paddle_inference_api.h │ │ ├── paddle_pass_builder.h │ │ └── ... │ └── lib/ │ ├── paddle_inference.lib │ ├── paddle_inference.dll │ └── ... ├── third_party/ │ ├── install/ │ │ ├── cuda/ │ │ ├── cudnn/ │ │ ├── tensorrt/ │ │ ├── mkl/ │ │ └── ... │ └── ... ├── version.txt └── ...重點(diǎn)在于paddle/include和paddle/lib。頭文件放的是C API聲明庫文件放的是導(dǎo)入庫和動(dòng)態(tài)庫。third_party目錄里通常會(huì)有Paddle依賴的第三方庫但實(shí)際運(yùn)行時(shí)大多數(shù)還需要系統(tǒng)環(huán)境的CUDA、cuDNN等別指望這個(gè)目錄里的文件能替代你手動(dòng)安裝的CUDA Toolit。version.txt里會(huì)寫明精確的構(gòu)建信息建議打開看一眼確認(rèn)跟你理解的版本一致。在Windows下用VS2019建工程時(shí)配置包含目錄為paddle/include庫目錄為paddle/lib并且把paddle_inference.dll、paddle2ONNX.dll等動(dòng)態(tài)庫拷貝到exe輸出目錄或放到PATH可達(dá)的位置。否則編譯能過運(yùn)行就報(bào)找不到paddle_inference.dll。3.2 最小CMake工程配置我習(xí)慣用CMake來管理Windows下的C工程比直接手寫.vcxproj方便。下面是我驗(yàn)證過可用的CMakeLists.txt模板針對VS2019 Paddle Inference 3.0.0cmake_minimum_required(VERSION 3.16) project(paddle_infer_demo) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CONFIGURATION_TYPES Release CACHE STRING FORCE) # Paddle Inference路徑 set(PADDLE_INFER_DIR D:/paddle_inference CACHE PATH Path to paddle_inference) include_directories(${PADDLE_INFER_DIR}/paddle/include) link_directories(${PADDLE_INFER_DIR}/paddle/lib) # CUDA include_directories(C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.8/include) link_directories(C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.8/lib/x64) # TensorRT set(TENSORRT_DIR D:/TensorRT-8.5.1.7) include_directories(${TENSORRT_DIR}/include) link_directories(${TENSORRT_DIR}/lib) # MKL如果推理時(shí)想用CPU算子MKL路徑也要加 set(MKL_DIR C:/Program Files (x86)/Intel/oneAPI/mkl/latest) include_directories(${MKL_DIR}/include) link_directories(${MKL_DIR}/lib) add_executable(paddle_demo main.cpp) target_link_libraries(paddle_demo paddle_inference cudart nvinfer nvonnxparser # 釋放版本下Paddle還需要關(guān)注paddle2onnx依賴但鏈接paddle_inference時(shí)通常會(huì)自動(dòng)帶 )這里要特別說明兩點(diǎn)。第一CMake的link_directories在Windows下有時(shí)不生效因?yàn)镸SVC在鏈接時(shí)更依賴具體的庫文件路徑。遇到“找不到paddle_inference.lib”的情況最省事的辦法是在target_link_libraries里寫全路徑target_link_libraries(paddle_demo ${PADDLE_INFER_DIR}/paddle/lib/paddle_inference.lib )第二Release模式必須和Release模式匹配。Paddle的預(yù)編譯庫一般是Release版如果你用Debug配置去鏈接大概率會(huì)在運(yùn)行時(shí)出現(xiàn)無法解析的外部符號或堆損壞因?yàn)镸SVC的運(yùn)行時(shí)庫/MD和/MTd不同。3.3 編寫一份能正常加載PIR模型的C推理代碼Paddle Inference 3.0.0的API和2.x有些變化核心頭文件是paddle_inference_api.h。下面是一個(gè)最基礎(chǔ)的單模型GPU推理示例流程是創(chuàng)建Config - 配置模型路徑 - 啟用GPU - 創(chuàng)建Predictor - 構(gòu)造輸入 - Run - 讀取輸出。#include iostream #include vector #include paddle_inference_api.h int main() { // 1. 創(chuàng)建AnalysisConfig paddle_infer::Config config; // 假設(shè)模型是Paddle保存的靜態(tài)圖模型包含model.pdmodel和model.pdiparams config.SetModel(path/to/model.pdmodel, path/to/model.pdiparams); // 2. 開啟GPU推理 config.EnableUseGpu(1024, 0); // 參數(shù)1顯存預(yù)分配大小MB參數(shù)2GPU設(shè)備ID // 如果不想用GPU可以改用config.DisableGpu() // 3. 啟用TensorRT可選 config.EnableTensorRtEngine(1 30 /* workspace_size */, 1 /* batch_size */, 10 /* min_subgraph_size */, paddle_infer::PrecisionType::kFloat32, false /* use_static */, false /* use_calib_mode */); // 4. 開啟MKLDNN僅CPU模式下用GPU模式下此選項(xiàng)一般無效 // config.EnableMKLDNN(); // 5. 創(chuàng)建Predictor auto predictor paddle_infer::CreatePredictor(config); // 6. 獲取輸入輸出張量的名稱 auto input_names predictor-GetInputNames(); auto output_names predictor-GetOutputNames(); // 7. 構(gòu)造輸入 auto input_tensor predictor-GetInputHandle(input_names[0]); // 假設(shè)輸入shape是 [1, 3, 224, 224]float32 std::vectorfloat input_data(1 * 3 * 224 * 224, 0.5f); input_tensor-Reshape({1, 3, 224, 224}); input_tensor-CopyFromCpu(input_data.data()); // 8. 推理 predictor-Run(); // 9. 獲取輸出 auto output_tensor predictor-GetOutputHandle(output_names[0]); std::vectorfloat output_data; output_tensor-CopyToCpu(output_data.data()); // 注意上面這種CopyToCpu方式存在隱患因?yàn)閛utput_data沒有預(yù)分配空間。 // 更穩(wěn)妥的方式是先獲取shape再分配內(nèi)存 // auto out_shape output_tensor-shape(); // int out_num std::accumulate(out_shape.begin(), out_shape.end(), 1, std::multipliesint()); // output_data.resize(out_num); // output_tensor-CopyToCpu(output_data.data()); return 0; }這段代碼有幾個(gè)細(xì)節(jié)容易踩坑。首先GetOutputHandle之后一定要先調(diào)用shape()獲取輸出維度再給vector分配空間最后CopyToCpu。如果直接CopyToCpu到一個(gè)空vector會(huì)觸發(fā)訪問越界或只拷出一部分?jǐn)?shù)據(jù)。我在實(shí)際項(xiàng)目中遇到過輸出數(shù)據(jù)全0的情況排查半天發(fā)現(xiàn)是vector沒resizeCopyToCpu只寫了應(yīng)該寫的長度但程序讀取越界了。其次Config.EnableUseGpu的第一個(gè)參數(shù)是顯存預(yù)分配大小這個(gè)值不是硬性限制Paddle會(huì)在需要時(shí)繼續(xù)申請但預(yù)分配越大運(yùn)行中顯存碎片化越少越不容易因?yàn)轱@存不足報(bào)錯(cuò)。一般圖像分類模型給1024就夠檢測或分割模型給2048以上。另外Paddle的模型文件有兩種一種是舊版的__model__和params文件另一種是新版的.pdmodel和.pdiparams。3.0.0的接口對舊版也有兼容但我建議統(tǒng)一用新版格式保存模型時(shí)用paddle.jit.save。3.4 理解Paddle Inference的模型加載機(jī)制你可能會(huì)問模型文件到底放在哪程序怎么知道網(wǎng)絡(luò)結(jié)構(gòu)這其實(shí)是“靜態(tài)圖”和“動(dòng)態(tài)圖”的問題。訓(xùn)練時(shí)用的是動(dòng)態(tài)圖方便調(diào)試保存推理模型時(shí)用的是靜態(tài)圖把計(jì)算邏輯固化下來。.pdmodel文件就是序列化后的靜態(tài)計(jì)算圖包含所有算子和權(quán)重.pdiparams是權(quán)重文件。Paddle Inference加載模型時(shí)會(huì)做一系列圖優(yōu)化比如算子融合、常量折疊這些優(yōu)化由一系列pass組成。你可以通過config.SwitchIrOptimization(true)或false來開啟或關(guān)閉。我建議默認(rèn)開啟尤其是在GPU TensorRT模式下圖優(yōu)化對性能影響很大。有時(shí)你會(huì)在日志里看到類似“I1125 09:00:01.123456 12345 analysis_predictor.cc:99] Optimize to PaddlePredictor...”的信息這說明圖優(yōu)化生效了。如果模型加載后推理結(jié)果不對可以試著SwitchIrOptimization(false)跑一遍對比結(jié)果看是不是優(yōu)化pass引入的問題。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 用C跑通一個(gè)圖像分類模型的全流程實(shí)錄為了減少變量我用PaddleClas里的MobileNetV3作為示例模型流程如下。第一準(zhǔn)備模型。如果你手頭沒有Paddle模型可以用一行Python代碼導(dǎo)出一個(gè)示例模型import paddle import paddle.vision.models as models model models.mobilenet_v3_small(num_classes1000) model.eval() # 構(gòu)造一個(gè)示例輸入用于固定輸入shape input_spec [paddle.static.InputSpec(shape[-1, 3, 224, 224], dtypefloat32, nameinput)] paddle.jit.save(model, mobilenetv3, input_specinput_spec, output_specNone)這樣會(huì)生成mobilenetv3.pdmodel和mobilenetv3.pdiparams兩個(gè)文件。第二把模型文件放好。我在D盤建了一個(gè)項(xiàng)目目錄結(jié)構(gòu)是D:\paddle_demo\ ├── CMakeLists.txt ├── main.cpp ├── models\ │ ├── mobilenetv3.pdmodel │ └── mobilenetv3.pdiparams └── build\第三編譯工程。在VS2019的“x64 Native Tools Command Prompt”里執(zhí)行cd D:\paddle_demo mkdir build cd build cmake .. -G Visual Studio 16 2019 -A x64 -DPADDLE_INFER_DIRD:/paddle_inference cmake --build . --config Release編譯成功后在build\Release目錄下會(huì)生成paddle_demo.exe。執(zhí)行前確保paddle_inference.dll、cudnn64_8.dll、nvinfer.dll等動(dòng)態(tài)庫都能被找到最保險(xiǎn)的做法是寫一個(gè)bat腳本把這些dll全部復(fù)制到exe同目錄下或者啟動(dòng)前臨時(shí)設(shè)置PATH。第四運(yùn)行。程序跑起來后觀察輸出日志如果能看到Paddle版本信息和模型加載日志基本就通了。遇到問題時(shí)先看日志尾部錯(cuò)誤碼Paddle的錯(cuò)誤碼通常帶有EROR或FATAL字樣直接定位。4.2 CPU推理與MKLDNN的配置細(xì)節(jié)GPU在大多數(shù)服務(wù)器上都有但開發(fā)調(diào)試階段CPU推理反而更常用。Paddle Inference在x86平臺上開啟MKLDNN即oneDNN前身是MKL-DNN后CPU算子的性能提升非常明顯尤其是卷積和矩陣乘。開啟方式非常簡單config.EnableMKLDNN(); config.SetCpuMathLibraryNumThreads(8);SetCpuMathLibraryNumThreads用于設(shè)置CPU線程數(shù)默認(rèn)是物理核心數(shù)。這個(gè)值不是越大越好因?yàn)榫€程切換和內(nèi)存帶寬都會(huì)成為瓶頸我實(shí)測8線程左右對大部分模型性價(jià)比最高。多路CPU的服務(wù)器可能會(huì)更復(fù)雜建議按模型benchmark去搜一下最佳線程數(shù)。MKLDNN模式下Paddle會(huì)自動(dòng)把部分算子替換為oneDNN實(shí)現(xiàn)圖優(yōu)化中也會(huì)多做一層算子融合。還有一個(gè)附加開關(guān)是EnableMKLDNNQuantizer用于INT8量化但一般需要校準(zhǔn)數(shù)據(jù)集工程上用得少。4.3 TensorRT加速的完整開啟方式與參數(shù)選擇TensorRT是GPU推理的核心加速手段。在上面示例代碼里我用了EnableTensorRtEngine但這里有幾個(gè)參數(shù)值得單獨(dú)展開。第一個(gè)參數(shù)workspace_size單位是字節(jié)它表示TensorRT允許使用的顯存上限。設(shè)置太大可能會(huì)因?yàn)轱@存不足導(dǎo)致TensorRT初始化失敗設(shè)置太小TensorRT因?yàn)闊o法執(zhí)行某些優(yōu)化策略性能會(huì)打折扣。我的習(xí)慣是把值設(shè)為顯存大小的三分之一到二分之一比如8GB顯存就設(shè)1GB到2GB左移30位是1GB。第二個(gè)參數(shù)batch_size這是“最優(yōu)batch數(shù)”等于1表示主要優(yōu)化batch1的推理。如果你的業(yè)務(wù)并發(fā)batch是固定的比如batch8這里最好設(shè)置為8TensorRT會(huì)依據(jù)這個(gè)size做kernel選擇。第三個(gè)參數(shù)min_subgraph_size這是子圖融合的最小節(jié)點(diǎn)數(shù)。Paddle會(huì)把支持TensorRT的算子組合成子圖子圖內(nèi)的算子在TensorRT上執(zhí)行子圖外的算子留在Paddle上。min_subgraph_size太小時(shí)一個(gè)單獨(dú)的算子也會(huì)被調(diào)去TensorRT性能反而下降因?yàn)榇罅啃∷阕訒?huì)有額外傳輸開銷太大會(huì)導(dǎo)致TensorRT覆蓋的算子太少加速效果不明顯。官方默認(rèn)值一般在3到5實(shí)踐下來10左右比較均衡。PrecisionType可以選擇kFloat32、kHalf、kInt8。如果對精度要求較高比如醫(yī)療圖像用kFloat32對性能敏感但精度容忍度還行用kHalf也就是FP16。kInt8需要額外校準(zhǔn)數(shù)據(jù)前向inference時(shí)還需要在use_calib_mode參數(shù)設(shè)為true否則可能報(bào)錯(cuò)。另外TensorRT支持序列化engine文件即靜態(tài)engine可以避免每次啟動(dòng)都重新構(gòu)建engine。Paddle里對應(yīng)的是config.EnableTensorRtEngine時(shí)設(shè)置use_statictrue這樣會(huì)把優(yōu)化后的engine緩存到本地文件下次啟動(dòng)直接加載。這個(gè)緩存跟模型、輸入shape、TensorRT版本、顯卡型號都強(qiáng)相關(guān)換環(huán)境或改shape之后一定要?jiǎng)h除緩存否則會(huì)報(bào)“inconsistency”錯(cuò)誤。4.4 動(dòng)態(tài)Shape場景下的TensorRT配置很多實(shí)際部署場景比如檢測模型的輸入shape是動(dòng)態(tài)的例如一張圖可以是大是小。TensorRT對動(dòng)態(tài)shape支持得比靜態(tài)shape復(fù)雜需要在配置時(shí)顯式指定三個(gè)維度范圍min_shape、opt_shape、max_shape。Paddle Inference的接口是config.EnableTensorRtEngine(workspace_size, max_batch_size, min_subgraph_size, precision, use_static, use_calib_mode); config.SetTRTDynamicShapeInfo(min_input_shape, max_input_shape, opt_input_shape, disable_trt_plugin_fp16);其中min_input_shape、opt_input_shape、max_input_shape都是mapkey是輸入張量名value是對應(yīng)shape。舉個(gè)栗子一個(gè)[None, 3, None, None]的輸入std::mapstd::string, std::vectorint min_shape {{input, {1, 3, 32, 32}}}; std::mapstd::string, std::vectorint opt_shape {{input, {1, 3, 448, 448}}}; std::mapstd::string, std::vectorint max_shape {{input, {1, 3, 960, 960}}};這個(gè)配置決定了TensorRT在運(yùn)行時(shí)能接受的輸入范圍。如果輸入超出了max_shape直接會(huì)報(bào)維度錯(cuò)誤如果輸入在min和max之間TensorRT會(huì)嘗試在opt_shape附近做優(yōu)化所以opt值要盡量接近你的真實(shí)輸入尺寸分布中心。動(dòng)態(tài)shape還帶來一個(gè)隱性風(fēng)險(xiǎn)子圖劃分策略在不同shape下可能不同導(dǎo)致同一個(gè)算子有時(shí)在TensorRT里、有時(shí)在Paddle里執(zhí)行表現(xiàn)出的性能差異較大。所以線上服務(wù)如果輸入尺寸波動(dòng)很大建議還是固定到幾個(gè)離散的尺寸規(guī)格比如通過resize統(tǒng)一到448x448或960x960穩(wěn)定性和性能都更好。5. 常見問題與排查技巧實(shí)錄5.1 常見錯(cuò)誤速查表我把實(shí)際部署中遇到的錯(cuò)誤整理成一張表方便大家對照排查。錯(cuò)誤現(xiàn)象可能原因解決方案運(yùn)行時(shí)提示找不到paddle_inference.dll動(dòng)態(tài)庫路徑未加入PATH把paddle/lib加到PATH或拷貝dll到exe目錄提示找不到cudnn64_8.dllcuDNN未安裝或版本不匹配檢查bin目錄下是否存在cudnn64_8.dll復(fù)制到系統(tǒng)PATH初始化GPU時(shí)卡死或報(bào)cudaErrorInsufficientDriver顯卡驅(qū)動(dòng)版本過低更新驅(qū)動(dòng)至525.60.13以上編譯時(shí)無法解析paddle::AnalysisConfig鏈接庫時(shí)找不到paddle_inference.lib檢查CMake鏈接的lib路徑是否寫對用絕對路徑最穩(wěn)運(yùn)行時(shí)報(bào)非法指令I(lǐng)llegal instructionCPU不支持AVX指令集換成支持AVX的機(jī)器或下載noavx版本TensorRT engine初始化失敗TensorRT DLL版本不匹配確認(rèn)nvinfer.dll版本為8.5.1.x且CUDA版本是11.8推理結(jié)果全是0或NaNvector未正確分配空間或輸入數(shù)據(jù)異常檢查輸出tensor的shape分配空間后再CopyToCpu顯存不足CUDA out of memory顯存被其他進(jìn)程占用或workspace_size過大減小EnableUseGpu的預(yù)分配或關(guān)閉其他GPU進(jìn)程日志中出現(xiàn)算子不支持TensorRT當(dāng)前模型某些算子無法被TensorRT識別調(diào)大min_subgraph_size讓不支持的算子留在Paddle里執(zhí)行注意這張表只覆蓋了最常見的問題。實(shí)際上Windows環(huán)境的問題千奇百怪比如殺毒軟件刪dll、動(dòng)態(tài)庫搜索路徑失效、顯卡驅(qū)動(dòng)被系統(tǒng)更新覆蓋等等遇到問題時(shí)先冷靜逐層排查。5.2 DLL加載順序的坑與解決方案Windows加載動(dòng)態(tài)庫的順序是exe所在目錄 - 系統(tǒng)目錄 - system32 - PATH環(huán)境變量。這帶來一個(gè)問題如果系統(tǒng)里殘留了舊版本的cuda DLL或cudnn DLLPaddle可能會(huì)加載到錯(cuò)誤的版本導(dǎo)致莫名其妙的行為。我遇到過的一個(gè)典型案例機(jī)器上裝了Anacondaconda環(huán)境里有自己的一套cudnn加上Paddle的third_party目錄里也有一份dll還有系統(tǒng)裝的CUDA 11.8三份dll一起出現(xiàn)程序運(yùn)行時(shí)根本不知道加載了哪一份。解決方法是在啟動(dòng)exe的bat腳本里顯式把Paddle依賴的DLL目錄放到PATH最前面同時(shí)把conda的Library\bin挪到后面。更激進(jìn)的做法是把工程需要的dll全部拷貝到exe目錄做到一個(gè)目錄全含。另外TeamViewer等遠(yuǎn)程軟件或圖形驅(qū)動(dòng)會(huì)注入一部分庫到進(jìn)程中這類庫跟CUDA本無關(guān)系但偶爾會(huì)改變DLL搜索路徑優(yōu)先級。遇到玄學(xué)問題可以先在干凈環(huán)境下測試。5.3 顯存不足與顯存碎片化的排查思路GPU推理的顯存管理是個(gè)經(jīng)典問題。Paddle Inference默認(rèn)用緩存分配器預(yù)分配顯存后不會(huì)馬上歸還給驅(qū)動(dòng)這跟訓(xùn)練框架類似。在EnableUseGpu里指定的第一個(gè)參數(shù)就是預(yù)分配大小。顯存不足的常見情況推理進(jìn)程啟動(dòng)很慢顯存占用持續(xù)上漲最終報(bào)CUDA out of memory。這時(shí)候先確認(rèn)是不是有多個(gè)GPU進(jìn)程在跑Windows下可以用nvidia-smi查看GPU占用。如果只有一個(gè)進(jìn)程看看是不是模型過大或者TensorRT構(gòu)建engine時(shí)臨時(shí)分配了大量顯存。有時(shí)候訓(xùn)練和推理共用GPU也會(huì)導(dǎo)致沖突。比如顯存只有6GB訓(xùn)練任務(wù)占了5.5GB推理任務(wù)只有500MB可用任何模型都會(huì)OOM。建議配置GPU隔離Windows下一般用環(huán)境變量CUDA_VISIBLE_DEVICES來切換但注意這個(gè)變量在多進(jìn)程場景下要提前設(shè)置好別在代碼里改。如果你想在推理進(jìn)程退出時(shí)完整釋放顯存Paddle提供了paddle_infer::Predictor::ClearInterpreter之類的方法但更實(shí)用的做法是直接調(diào)用config.EnableMemoryOptim(true)開啟內(nèi)存優(yōu)化。這個(gè)選項(xiàng)讓Paddle在算子執(zhí)行前后復(fù)用顯存峰值占用能明顯下降但代價(jià)是增加一點(diǎn)調(diào)度開銷實(shí)際推理性能幾乎無影響。5.4 多模型加載與單例Predictor的設(shè)計(jì)建議實(shí)際項(xiàng)目里很少只跑一個(gè)模型通常會(huì)同時(shí)加載多個(gè)模型或者同一個(gè)模型多個(gè)實(shí)例。Paddle每個(gè)Predictor對應(yīng)一份模型實(shí)例它們之間的顯存和線程是獨(dú)立的所以要注意整體資源控制。我比較推薦的做法是每個(gè)模型建立一個(gè)Predictor池池的大小根據(jù)并發(fā)請求確定。Predictor本身不是線程安全的多個(gè)線程并發(fā)執(zhí)行Run可能會(huì)有問題最安全的方式是每個(gè)線程持有自己的Predictor實(shí)例。Paddle內(nèi)部有一些線程池和常量優(yōu)化如果你有很多Predictor實(shí)例每個(gè)實(shí)例都會(huì)初始化一遍圖優(yōu)化和算子顯存和CPU開銷會(huì)翻幾倍。解決辦法是提前構(gòu)建好TensorRT靜態(tài)engine并緩存避免重復(fù)構(gòu)建。還有一種方案是把多模型融合成一個(gè)模型在某些場景下可行但通用性不高。實(shí)際操作中我通常把模型按業(yè)務(wù)模塊拆分用獨(dú)立的Predictor管理類統(tǒng)一控制生命周期在服務(wù)啟動(dòng)時(shí)預(yù)加載避免運(yùn)行時(shí)頻繁創(chuàng)建銷毀。6. 性能調(diào)優(yōu)從能用變成好用6.1 CPU與GPU推理的取舍很多人拿到Paddle Inference就默認(rèn)用GPU其實(shí)小模型在CPU上可能更快。這涉及一個(gè)基礎(chǔ)概念GPU的延遲不一定比CPU低但吞吐量遠(yuǎn)高于CPU。對于batch1的低延遲場景CPU可能反而有優(yōu)勢因?yàn)椴恍枰截悢?shù)據(jù)到GPU。所以如果你的模型很小比如幾百M(fèi)B的輕量模型且請求量不大CPU推理就夠了MKLDNN開啟后性能也很可觀。跑benchmark時(shí)我習(xí)慣于反復(fù)預(yù)熱后再計(jì)時(shí)因?yàn)镃UDA運(yùn)行時(shí)、TensorRT engine構(gòu)建、Paddle圖優(yōu)化這些都會(huì)在第一次推理時(shí)發(fā)生導(dǎo)致第一次很慢。Paddle也提供了config.SwitchIrOptimization(true)和預(yù)熱循環(huán)的配合用10到20次無關(guān)推理把運(yùn)行時(shí)狀態(tài)跑熱再統(tǒng)計(jì)真實(shí)延遲。6.2 TensorRT與Paddle算子融合的細(xì)節(jié)觀察當(dāng)啟用TensorRT引擎時(shí)Paddle并不會(huì)把所有算子全部交給TensorRT而是先做圖分析把支持的部分切成子圖再交給TensorRT。這意味著最終推理圖可能是“Paddle原生算子 TensorRT子圖”混合的。如果你想知道哪些子圖被切到了TensorRT可以打開調(diào)試日志config.EnableDebug(); config.SwitchIrDebug(true);日志里會(huì)打印pass執(zhí)行情況包括每個(gè)子圖的算子數(shù)量、輸入輸出張量。我常常通過這個(gè)日志判斷為什么某些模型TensorRT加速效果不明顯——往往是因?yàn)榍谐鰜淼淖訄D太小TensorRT根本來不及發(fā)揮優(yōu)化能力。一個(gè)模型如果全是卷積和pooling子圖會(huì)非常大TensorRT加速效果顯著。如果模型里有大量自定義算子、控制流if/loop或動(dòng)態(tài)shape操作子圖會(huì)被切得很碎加速效果大打折扣。這不算錯(cuò)誤只是性能優(yōu)化的約束條件。6.3 顯存預(yù)分配、緩存與批處理的高級調(diào)優(yōu)對于高吞吐場景比如推薦系統(tǒng)或者視頻流處理盡量使用batch推理。Paddle Inference支持動(dòng)態(tài)batch但你需要手動(dòng)拼接輸入數(shù)據(jù)。一張一張推理和批量推理吞吐量差距可能達(dá)到5到10倍尤其是GPU上。一個(gè)常見的誤區(qū)把batch設(shè)得越大越好。實(shí)際上batch太大TensorRT在kernel選擇時(shí)會(huì)傾向并行度更高的策略但模型本身有內(nèi)存帶寬限制超過某個(gè)閾值后吞吐不再增長反而會(huì)因?yàn)轱@存不足報(bào)錯(cuò)。我一般用nvidia-smi看顯存殘量找到batch的上界。還可以考慮多流推理。Paddle對單卡多流的支持比較有限但你可以自己開多個(gè)線程每個(gè)線程一個(gè)Predictor分別跑不同的batch間接實(shí)現(xiàn)多流并行。這種情況下要注意所有Predictor共享同一塊GPU顯存總量要精打細(xì)算。6.4 從Windows到Linux的遷移注意事項(xiàng)雖然本文圍繞Windows展開但很多生產(chǎn)服務(wù)器是Linux。Paddle Inference的Linux預(yù)編譯包同樣有對應(yīng)的版本遷移時(shí)主要注意幾個(gè)點(diǎn)。第一動(dòng)態(tài)庫后綴不同。Windows是dllLinux是so。代碼里不要硬編碼路徑盡量用配置或相對路徑。第二Linux下cuDNN和TensorRT的安裝路徑不同通常用軟鏈接管理版本。第三CUDA的運(yùn)行時(shí)庫搜索路徑是rpath和LD_LIBRARY_PATH需要導(dǎo)出環(huán)境變量。第四Linux下沒有Visual Studio但GCC/G版本要跟預(yù)編譯包要求對應(yīng)一般Paddle官方推薦GCC 8.2以上的版本。我個(gè)人的建議是Windows版用于本地開發(fā)和單機(jī)驗(yàn)證一旦確認(rèn)模型和推理邏輯無誤就用Linux版部署到服務(wù)器。因?yàn)閃indows和Linux的TensorRT engine緩存不通用正式環(huán)境用Linux的包重新構(gòu)建一次engine緩存才能保證最優(yōu)性能。7. 寫在最后的經(jīng)驗(yàn)之談這套Paddle Inference環(huán)境我已經(jīng)在好幾個(gè)項(xiàng)目里用過了一個(gè)非常深刻的感受是版本對齊就是最大的坑但也是最好解決的問題。只要你嚴(yán)格按照CUDA 11.8 cuDNN 8.6.0 TensorRT 8.5.1.7 VS2019這套組合去裝依賴版本兼容性問題會(huì)少很多。反而是那些“順便升級一下”的操作比如把cuDNN從8.6升到8.9、把TensorRT從8.5升到8.6容易引發(fā)各種dll不匹配。另外一個(gè)心得是不要過度依賴預(yù)編譯包里自帶的third_party目錄。它只是把Paddle需要的一些第三方庫打個(gè)包方便你不用單獨(dú)下載MKL之類的東西但CUDA和cuDNN這種重量級依賴還是得你手動(dòng)裝好把環(huán)境弄得干凈可控才是正道。如果你把這個(gè)zip當(dāng)成“解壓就能用”的黑盒那多半會(huì)遇到一堆問題。但如果把它當(dāng)成“Paddle Inference的Windows版本參考實(shí)現(xiàn)”對照著它的編譯選項(xiàng)去配置自己的環(huán)境很多問題就能系統(tǒng)性地避開。我一般會(huì)在項(xiàng)目里寫一個(gè)configure.bat把PATH、MKL、TensorRT、CUDA的路徑全部設(shè)置好每次開新終端都執(zhí)行一遍比手動(dòng)改環(huán)境變量穩(wěn)定多了。最后再提一個(gè)小技巧在Windows上萬一遇到奇怪崩潰先試試把Compile with AVX對應(yīng)的運(yùn)行庫CPU指令集匹配問題排除掉老的CPU比如一些低功耗的奔騰、賽揚(yáng)真的可能不支持AVX換成noavx版本的Paddle Inference包會(huì)立刻解決。這個(gè)坑我?guī)屯屡挪檫^兩次每次都是CPU硬件太老不是代碼的問題。本文還有配套的精品資源點(diǎn)擊獲取