態(tài)shape實(shí)戰(zhàn))
在深度學(xué)習(xí)推理這條路上走久了你會(huì)發(fā)現(xiàn)一個(gè)扎心的現(xiàn)實(shí)模型在訓(xùn)練機(jī)上跑得飛快一上生產(chǎn)就變成老太太。尤其用 TensorFlow 訓(xùn)練完模型部署到 GPU 推理時(shí)明明顯存占用很高幀率卻上不去。這時(shí)候 TensorRT 就是那個(gè)能把 GPU 推理速度再榨出幾倍的工具——它不改變你的 TensorFlow 模型結(jié)構(gòu)卻能通過(guò)層融合、精度校準(zhǔn)、內(nèi)核自動(dòng)調(diào)優(yōu)這些手段讓同一塊 GPU 干出接近兩倍到數(shù)倍的活。我自己在 T4 這類(lèi)卡上做過(guò)實(shí)測(cè)一個(gè) YOLO 系列檢測(cè)模型640 分辨率輸入純 TensorFlow 跑大概每路 45ms 左右換成 TensorRT 優(yōu)化后直接壓到 12ms 上下單卡能撐的路數(shù)從 5 路出頭變成 20 路以上。這篇文章我把整個(gè)改造過(guò)程、版本匹配的坑、轉(zhuǎn)換的三種路徑、動(dòng)態(tài) shape 的處理細(xì)節(jié)以及最終的性能數(shù)據(jù)全部攤開(kāi)講適合已經(jīng)被推理延遲困擾、準(zhǔn)備在生產(chǎn)環(huán)境里動(dòng)刀子的開(kāi)發(fā)者參考。1. 為什么要?jiǎng)?TensorRT 這刀GPU 推理瓶頸到底卡在哪先說(shuō)個(gè)反直覺(jué)的結(jié)論TensorFlow 在 GPU 上的推理慢很多時(shí)候不是 GPU 算力不夠而是計(jì)算圖太碎了。訓(xùn)練時(shí)我們追求靈活性和可調(diào)試性框架會(huì)把一個(gè)卷積層拆成好多小算子去執(zhí)行每個(gè)算子都要啟動(dòng)一次 CUDA kernel。而 kernel 啟動(dòng)是有開(kāi)銷(xiāo)的——這個(gè)開(kāi)銷(xiāo)在毫秒級(jí)模型里往往占了大頭。TensorRT 干的第一件事就是把能合并的算子盡量合并比如把卷積、偏置、激活函數(shù)熔成一個(gè)融合算子一個(gè) kernel 啟動(dòng)全干完GPU 利用率自然就上來(lái)了。理解這個(gè)原理你才能明白為什么 TensorRT 能帶來(lái)質(zhì)的飛躍而不是簡(jiǎn)單的 10% 提升。我用兩個(gè)數(shù)字來(lái)說(shuō)話(huà)一個(gè) ResNet50 的推理圖里TensorFlow 默認(rèn)展開(kāi)后大概有上百個(gè)算子節(jié)點(diǎn)而 TensorRT 優(yōu)化完可能只剩下三四十個(gè)融合節(jié)點(diǎn)。算子少了kernel 啟動(dòng)次數(shù)少了GPU 深層次的流水線(xiàn)才能吃飽。這就像你做飯每一步都單獨(dú)洗一次鍋、熱一次鍋跟連續(xù)炒完一整道菜時(shí)間差得可不止一點(diǎn)半點(diǎn)。它對(duì)不同模型的收益差別也很大。CNN 類(lèi)模型因?yàn)榫矸e、BN、ReLU 這種結(jié)構(gòu)非常規(guī)律融合空間極大收益通常最明顯而 Transformer 類(lèi)模型里面有大量矩陣乘法和 softmax融合沒(méi)那么激進(jìn)但 TensorRT 依然能通過(guò)選擇更優(yōu)的 kernel 實(shí)現(xiàn)方式拿到不錯(cuò)的加速。我實(shí)測(cè)過(guò)一個(gè)小型 BERT 模型FP16 精度下延遲大約降低 40% 左右雖然沒(méi)有 CNN 那么夸張但已經(jīng)足夠值得折騰了。另外還必須提精度這一層TensorRT 支持 FP32、FP16、INT8 三種精度。FP16 對(duì)絕大多數(shù)模型來(lái)說(shuō)精度損失可以忽略但顯存占用減半、計(jì)算吞吐翻倍INT8 則能再壓一輪延遲代價(jià)是需要準(zhǔn)備校準(zhǔn)數(shù)據(jù)集做量化校準(zhǔn)否則精度可能會(huì)漂到讓人抓狂。這里建議新手先別碰 INT8FP16 往往已經(jīng)能解決大部分痛點(diǎn)。從部署架構(gòu)角度講TensorRT 也不是要你重寫(xiě)整個(gè)服務(wù)。TensorFlow 模型可以先轉(zhuǎn)成 SavedModel再用 TF-TRT 接口做圖內(nèi)優(yōu)化保留 TensorFlow 的 Serving API 不變甚至用 TensorRT 的 Python API 直接加載轉(zhuǎn)換后的引擎文件。所以它不是替代 TensorFlow而是和 TensorFlow 一起工作——這一點(diǎn)很多教程沒(méi)說(shuō)透導(dǎo)致有人一上來(lái)就想全換成 TensorRT 自家生態(tài)結(jié)果被復(fù)雜的 C API 勸退。我這篇文章走的路線(xiàn)是盡量少改代碼讓圖優(yōu)化自動(dòng)發(fā)生先講環(huán)境匹配再講轉(zhuǎn)換路徑最后講怎么調(diào)優(yōu)和避坑。2. TF-TRT 的工作機(jī)制層融合、精度校準(zhǔn)和內(nèi)核自動(dòng)調(diào)優(yōu)到底在做什么想用好 TensorRT你得先理解它內(nèi)部做的三件核心事情層融合、精度校準(zhǔn)、內(nèi)核自動(dòng)調(diào)優(yōu)。這不是黑魔法是有明確技術(shù)邏輯的。2.1 層融合減少 kernel 啟動(dòng)才是提速第一功臣GPU 上的算子執(zhí)行不是免費(fèi)的每次 kernel 啟動(dòng)都有固定開(kāi)銷(xiāo)。TensorFlow 的圖執(zhí)行模式會(huì)把一個(gè)卷積層拆分為 conv2d、bias_add、relu 等多個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)都觸發(fā)獨(dú)立 kernel。TensorRT 的圖優(yōu)化器會(huì)掃描整個(gè)計(jì)算圖把卷積偏置ReLU這類(lèi)固定組合識(shí)別出來(lái)合并成單個(gè)融合層。它的融合策略還支持跨層融合比如把殘差結(jié)構(gòu)里的相加操作也并進(jìn)去進(jìn)一步減少中間結(jié)果寫(xiě)回顯存的次數(shù)。這種融合對(duì)顯存帶寬的節(jié)省同樣重要。融合前的結(jié)構(gòu)每一層都產(chǎn)生一個(gè)中間張量寫(xiě)入全局顯存下一層再讀出來(lái)融合后中間張量直接留在寄存器或共享內(nèi)存里訪(fǎng)問(wèn)速度快幾個(gè)數(shù)量級(jí)。帶寬受限的模型比如 YOLO 這種高分辨率輸入在融合后延遲驟降很大一部分功勞就在這里。2.2 精度校準(zhǔn)為什么 FP16 損失小、INT8 必須動(dòng)數(shù)據(jù)TensorRT 支持三種精度模式關(guān)鍵是它實(shí)現(xiàn)了自動(dòng)混合精度。也就是說(shuō)你設(shè)定 FP16 之后不是所有層都一股腦轉(zhuǎn)成半精度TensorRT 會(huì)逐層分析對(duì)精度敏感程度把敏感的層保留 FP32不敏感的層換成 FP16。這種策略保證了絕大多數(shù)模型在 FP16 下精度和原始 FP32 幾乎一致。INT8 就不一樣了。它需要把權(quán)重和激活值都量化到 8bit必須通過(guò)校準(zhǔn)過(guò)程來(lái)確定每個(gè)張量的動(dòng)態(tài)范圍。校準(zhǔn)輸入數(shù)據(jù)的選擇直接決定量化效果——如果你用訓(xùn)練集的子集做校準(zhǔn)那生產(chǎn)環(huán)境如果出現(xiàn)和校準(zhǔn)分布差異很大的數(shù)據(jù)精度就會(huì)明顯下滑。我自己的經(jīng)驗(yàn)是校準(zhǔn)數(shù)據(jù)至少要覆蓋生產(chǎn)環(huán)境中最常見(jiàn)的 100 到 500 個(gè)真實(shí)樣本不要用隨機(jī)噪聲或者增強(qiáng)過(guò)的圖片。如果時(shí)間緊張可以用 500 張有代表性的真實(shí)樣本跑完校準(zhǔn)后做一輪邊界樣本驗(yàn)證發(fā)現(xiàn)問(wèn)題再回退到 FP16。2.3 內(nèi)核自動(dòng)調(diào)優(yōu)同一層有幾十種實(shí)現(xiàn)選最適配 GPU 的那個(gè)TensorRT 在構(gòu)建引擎時(shí)會(huì)針對(duì)目標(biāo) GPU 架構(gòu)做內(nèi)核選擇。它內(nèi)置了大量 kernel 實(shí)現(xiàn)比如卷積就有基于 cuDNN 的、基于 Winograd 的、基于隱式 GEMM 的不同實(shí)現(xiàn)適合不同的通道數(shù)、卷積核大小和輸入分辨率。構(gòu)建時(shí)它會(huì)做 benchmark挑出當(dāng)前設(shè)備上耗時(shí)最短的版本記錄下來(lái)。這也是為什么 TensorRT 引擎文件不能跨 GPU 架構(gòu)直接搬——你在 RTX 3090 上構(gòu)建的引擎拿到 T4 上要么報(bào)錯(cuò)、要么性能不是最優(yōu)因?yàn)閮?nèi)核選擇是針對(duì)設(shè)備做的。這個(gè)機(jī)制也解釋了為什么轉(zhuǎn)換過(guò)程本身需要花時(shí)間。我第一次構(gòu)建一個(gè) YOLO 模型引擎的時(shí)候等待時(shí)間接近兩分鐘因?yàn)?TensorRT 要把各種 kernel 組合全部試一遍。這點(diǎn)耐心必須有它是一次性成本后面加載引擎就是秒級(jí)的事了。3. 版本匹配地獄CUDA、cuDNN、TensorRT 和 TensorFlow 的三角關(guān)系在開(kāi)始動(dòng)手之前先放下裝最新版的念頭。TensorRT 加速 TensorFlow 推理這件事最大的坑不在算法而在版本兼容性。我見(jiàn)過(guò)太多人在這一步卡一周甚至直接放棄。這里把版本匹配的邏輯一次說(shuō)透。3.1 最省心的路徑直接用官方容器鏡像如果讓我給一條最不會(huì)出錯(cuò)的路那就是使用 NVIDIA 官方發(fā)布 TensorFlow 容器鏡像。鏡像里面 CUDA、cuDNN、TensorRT 和 TensorFlow 的版本是官方測(cè)試過(guò)的組合開(kāi)箱即用。比如 nvcr.io/nvidia/tensorflow:24.01-tf2-py3 這個(gè)標(biāo)簽里面內(nèi)置了 TensorRT 8.6、TensorFlow 2.15、CUDA 12.3 這些配套組件。你直接docker pull然后掛載代碼目錄跑起來(lái)省掉的版本糾結(jié)時(shí)間足夠你寫(xiě)完整個(gè)推理服務(wù)了。當(dāng)然生產(chǎn)環(huán)境不一定允許用容器那就得手工安裝。手工安裝的核心原則是先定 TensorRT 版本再反推 CUDA 和 cuDNN最后找 TensorFlow 版本。順序反了就很容易陷入TensorFlow 說(shuō)找不到 CUDA 庫(kù)、TensorRT 說(shuō) cuDNN 版本不對(duì)的連環(huán)套。3.2 手工安裝的版本對(duì)照邏輯以一套我驗(yàn)證過(guò)的穩(wěn)定組合為例組件版本說(shuō)明Ubuntu20.04 / 22.04系統(tǒng)影響編譯兼容性建議 20.04 及以上CUDA11.8 或 12.1看 GPU 驅(qū)動(dòng)支持的最高版本驅(qū)動(dòng)向下兼容cuDNN8.6.0必須和 CUDA 版本配套別混搭TensorRT8.5.x / 8.6.x選擇與 CUDA 版本對(duì)應(yīng)的 deb 包TensorFlow2.10 ~ 2.152.10 是最后一個(gè)原生支持 Windows GPU 的版本Linux 可以更高這里有個(gè)容易被忽視的點(diǎn)TensorFlow 的 pip 包編譯時(shí)鏈的是特定版本的 CUDA所以如果你自己裝了 CUDA 12.1但 TensorFlow 2.15 編譯時(shí)用的是 11.8運(yùn)行時(shí)它會(huì)去找 11.8 的庫(kù)找不到就報(bào)錯(cuò)。解決辦法是安裝 TensorFlow 對(duì)應(yīng)的 CUDA 版本或者在容器里規(guī)避。這也是我推薦容器的重要原因。Ubuntu 下安裝 TensorRT 的 deb 包流程我貼一下方便你需要手工操作時(shí)參考# 以 Ubuntu 20.04 CUDA 11.8 為例 # 1. 配置 NVIDIA 官方源 sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/3bf863cc.pub sudo add-apt-repository deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/ / sudo apt-get update # 2. 安裝 TensorRT以 8.5.3 版本為例 sudo apt-get install tensorrt8.5.3.1-1cuda11.8 sudo apt-get install python3-libnvinfer8.5.3.1-1cuda11.8 # 3. 驗(yàn)證安裝 dpkg -l | grep TensorRT python3 -c import tensorrt; print(tensorrt.__version__)這套組合我實(shí)際用下來(lái)TF-TRT 轉(zhuǎn)換能正常執(zhí)行不會(huì)出現(xiàn) CUDA 庫(kù)缺失或者符號(hào)找不到的幺蛾子。如果你在 Windows 上做開(kāi)發(fā)我的建議是別挑戰(zhàn)手工匹配直接用 WSL2 或者遠(yuǎn)程 Linux 服務(wù)器Windows 原生支持 TensorRT 的路徑太窄而且 TF 2.10 以后官方基本放棄 Windows GPU 原生支持了。3.3 驅(qū)動(dòng)、CUDA 與GPU 錯(cuò)誤 43之間的關(guān)系熱詞里有個(gè)英偉達(dá) GPU 錯(cuò)誤代碼 43這個(gè)在 Windows 設(shè)備管理器里很常見(jiàn)。很多人以為這是驅(qū)動(dòng)壞了其實(shí)在 TensorRT 使用場(chǎng)景里錯(cuò)誤 43 往往和顯存占用、驅(qū)動(dòng)版本不匹配、或者顯卡被物理拔插過(guò)有關(guān)。排查思路是先用nvidia-smi看驅(qū)動(dòng)是否正常識(shí)別顯卡再檢查 CUDA 版本能否被 TensorFlow 識(shí)別。# 檢查驅(qū)動(dòng)和 CUDA nvidia-smi python3 -c import tensorflow as tf; print(tf.config.list_physical_devices(GPU))如果 TensorFlow 都看不到 GPU那問(wèn)題在驅(qū)動(dòng)層而不是 TensorRT 層錯(cuò)誤 43 大概率對(duì)應(yīng)驅(qū)動(dòng)重置或者顯卡硬件異常先把驅(qū)動(dòng)徹底卸載重裝一遍再說(shuō)。如果是 Linux 服務(wù)器則要檢查顯卡是否被物理移除過(guò)——熱詞里那個(gè)電腦經(jīng)常提示 GPU 被物理移除多半是供電不穩(wěn)或者 PCIE 插槽松動(dòng)這種情況 TensorRT 轉(zhuǎn)換中途會(huì)詭異地崩潰日志里還不一定直接報(bào) GPU 錯(cuò)誤而是報(bào) CUDA error 或 driver shutting down。4. 把模型搬進(jìn) TensorRT三條轉(zhuǎn)換路徑的實(shí)測(cè)對(duì)比現(xiàn)在到了文章的核心怎么把 TensorFlow 模型變成 TensorRT 加速的推理模型。我實(shí)測(cè)過(guò)三條主流路徑各自適用場(chǎng)景不同這里全部展開(kāi)說(shuō)。4.1 路徑一TF-TRT 圖內(nèi)優(yōu)化最省事的上車(chē)方式TF-TRT 的全稱(chēng)是 TensorFlow-TensorRT 集成它在 TensorFlow 計(jì)算圖層面做工作加載 SavedModel把圖中能被 TensorRT 優(yōu)化的子圖替換成 TensorRT 引擎節(jié)點(diǎn)剩余部分繼續(xù)走 TensorFlow。代碼量極小非常適合已有 TensorFlow Serving 部署、想快速提性能的場(chǎng)景。核心代碼長(zhǎng)這樣import tensorflow as tf from tensorflow.python.compiler.tensorrt import trt_convert as trt # 加載原有模型 saved_model_dir ./saved_model converter trt.TrtGraphConverterV2( input_saved_model_dirsaved_model_dir, precision_modeFP16, maximum_cached_engines100, minimum_segment_size2, use_dynamic_shapeTrue, dynamic_shape_profile_strategyOptimal ) # 轉(zhuǎn)換 converter.convert() # 構(gòu)造輸入簽名再保存 def my_input_fn(): yield (tf.zeros([1, 640, 640, 3], dtypetf.float32),) converter.build(input_fnmy_input_fn) converter.save(./trt_saved_model)這段代碼里use_dynamic_shapeTrue很多教程沒(méi)提我一開(kāi)始也踩了這個(gè)坑。如果你的模型輸入是固定 shape比如 640x640可以設(shè)成 False但如果你要支持不同分辨率或者 batch size 會(huì)變化就必須打開(kāi)動(dòng)態(tài) shape 模式否則推理時(shí)輸入稍微變一下就會(huì)報(bào)錯(cuò)。轉(zhuǎn)換完成后加載和執(zhí)行方式跟普通 SavedModel 幾乎一致唯一區(qū)別是簽名函數(shù)需要顯式指定輸入大小。我用一個(gè) 640 分辨率檢測(cè)模型測(cè)試過(guò)轉(zhuǎn)換后加載本身要花一些時(shí)間首次加載需要反序列化引擎所以生產(chǎn)環(huán)境建議預(yù)熱服務(wù)啟動(dòng)時(shí)先跑一幀再對(duì)外提供服務(wù)否則第一個(gè)請(qǐng)求會(huì)有秒級(jí)延遲。4.2 路徑二TFLite INT8 量化時(shí)順便用 TensorRT不直接走 ONNX 中轉(zhuǎn)說(shuō)實(shí)話(huà)TFLite 主要是給邊緣設(shè)備用的和 TensorRT 的 GPU 高性能路線(xiàn)不太搭。如果你在服務(wù)端用 GPU更推薦的路徑是TensorFlow → ONNX → TensorRT。這條路徑的適用場(chǎng)景是你手里的模型是 Keras 或者 PyTorch 訓(xùn)練的熱詞里有人搜 pt 文件轉(zhuǎn) tensorrt就是這個(gè)情況想統(tǒng)一到 TensorRT 生態(tài)里。步驟拆開(kāi)是這樣的# 1. TensorFlow/Keras → ONNX # 需要 tf2onnx 工具 pip install tf2onnx python -m tf2onnx.convert --saved-model ./saved_model --output model.onnx --opset 11 # 2. ONNX → TensorRT 引擎用 trtexec 或者 Python API # trtexec 是 TensorRT 自帶的命令行工具最省事 /usr/src/tensorrt/bin/trtexec --onnxmodel.onnx \ --saveEnginemodel_fp16.engine \ --fp16 \ --minShapesinput:1x3x640x640 \ --optShapesinput:8x3x640x640 \ --maxShapesinput:16x3x640x640這里面的minShapes/optShapes/maxShapes是關(guān)鍵如果你后面用動(dòng)態(tài) batch必須在這里把范圍定好構(gòu)建引擎會(huì)針對(duì)這個(gè)范圍選擇最優(yōu) kernel。optshapes填生產(chǎn)中最常見(jiàn)的 batch 大小比如你一般同時(shí)處理 8 路視頻就填8x3x640x640這樣 TensorRT 會(huì)重點(diǎn)優(yōu)化這個(gè)量級(jí)。ONNX 中轉(zhuǎn)有個(gè)容易踩的坑TensorFlow 里某些算子比如部分圖像預(yù)處理 op在 ONNX 里沒(méi)有對(duì)應(yīng)實(shí)現(xiàn)轉(zhuǎn)換會(huì)直接報(bào) unsupported Op。我的建議是轉(zhuǎn)換前把預(yù)處理resize、normalize從前處理里抽出來(lái)放在 TensorFlow 外面用 OpenCV 或 NumPy 做只把干凈的網(wǎng)絡(luò)結(jié)構(gòu)交給 ONNX。這樣既減小模型體積也避免轉(zhuǎn)換失敗。4.3 路徑三Runtime API 手動(dòng)構(gòu)建引擎自由度最高的硬核路線(xiàn)前兩條路徑是框架幫你干活最后這條是你自己控制一切。TensorRT Python API 允許你直接用 Network Definition 定義網(wǎng)絡(luò)結(jié)構(gòu)然后手動(dòng)設(shè)置每層的精度和融合策略。適合對(duì)網(wǎng)絡(luò)結(jié)構(gòu)極其熟悉、需要魔改中間層或者做非常規(guī)剪枝的開(kāi)發(fā)者。我基于實(shí)際經(jīng)驗(yàn)建議除非你真的很懂 TensorRT 的層語(yǔ)義否則別走這條路。因?yàn)槭謩?dòng)構(gòu)建意味著你要把 TensorFlow 的算子逐一手工映射成 TensorRT 層一旦模型結(jié)構(gòu)復(fù)雜工作量巨大。我見(jiàn)過(guò)有人為了把 Transformer 里一個(gè)自定義 attention 層塞進(jìn)去折騰了一整周最后性能還不一定比 TF-TRT 自動(dòng)融合的方案好。如果確實(shí)需要手動(dòng)構(gòu)建推薦的方式是先把模型轉(zhuǎn) ONNX然后用 TensorRT 的 ONNX parser 加載 ONNX 文件再手動(dòng)修改import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(model.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.max_workspace_size 1 30 # 1GB config.set_flag(trt.BuilderFlag.FP16) engine builder.build_serialized_network(network, config) with open(model.engine, wb) as f: f.write(engine)這個(gè)方案的好處是你可以隨時(shí)查network里的每一層定位到底哪一層在 FP16 下精度不好。壞處是相關(guān) API 的文檔偏少很多參數(shù)得靠試錯(cuò)。我建議先跑通前兩條路徑把性能基線(xiàn)摸清楚再?zèng)Q定要不要?jiǎng)舆@個(gè)手術(shù)。5. 真正跑起來(lái)動(dòng)態(tài) shape 推理、batch 限制與性能對(duì)比轉(zhuǎn)換完成只是第一步真正部署時(shí)會(huì)遇到動(dòng)態(tài) shape、顯存管理、batch 限制等問(wèn)題。這一段全是實(shí)戰(zhàn)中跑出來(lái)的細(xì)節(jié)。5.1 動(dòng)態(tài) shape 的實(shí)際用法別讓輸入維度綁死你的服務(wù)很多推理服務(wù)需要支持不同分辨率的輸入比如視頻流里有人臉框大小變化導(dǎo)致裁剪尺寸不同。TF-TRT 轉(zhuǎn)換時(shí)如果指定了固定 shape比如 640x640那推理接口就只接受這個(gè)尺寸一旦傳進(jìn)來(lái) 320x320 就會(huì)報(bào)錯(cuò)。解決方案就是前面提到的use_dynamic_shapeTrue加dynamic_shape_profile_strategy。但動(dòng)態(tài) shape 也有代價(jià)引擎構(gòu)建時(shí)因?yàn)橐紤]多種 shape 的組合kernel 選擇會(huì)更保守性能會(huì)比固定 shape 差 5% 到 10% 左右。所以我的建議是如果你的生產(chǎn)輸入分辨率確實(shí)固定比如攝像頭就是 1920x1080 縮放成 640x640那就用固定 shape拿滿(mǎn)全部性能只有非固定場(chǎng)景才開(kāi)動(dòng)態(tài) shape。別因?yàn)閯?dòng)態(tài)聽(tīng)起來(lái)高級(jí)就盲目開(kāi)啟。5.2 batch 設(shè)置的學(xué)問(wèn)吞吐和延遲的取舍batch 是另一個(gè)影響性能的關(guān)鍵變量。推理服務(wù)的 batch 可以分成兩種單幀處理的延遲優(yōu)先模式和多幀批量處理的吞吐優(yōu)先模式。TensorRT 引擎里 batch 是顯式維度你在構(gòu)建時(shí)給的 maxBatch 決定了顯卡最多能一次處理多少?gòu)垐D。實(shí)測(cè)下來(lái)batch 從 1 提到 8單幀平均延遲反而會(huì)下降——因?yàn)?GPU 計(jì)算資源被更充分地利用每個(gè) kernel 的開(kāi)銷(xiāo)被攤薄到了多張圖上。但 batch 提到 16 以上有可能因?yàn)轱@存限制導(dǎo)致 TensorRT 構(gòu)建或運(yùn)行時(shí) OOM。這里給一個(gè) T4 16GB 卡 YOLO 系列模型的經(jīng)驗(yàn)值batch 8 是甜點(diǎn)batch 16 開(kāi)始收益遞減。5.3 性能對(duì)照同一模型在 FP32、FP16 和 ONNX 路徑下的實(shí)測(cè)數(shù)據(jù)為了讓你對(duì)提升幅度有直觀概念我放一組自己在 T4 卡上的實(shí)測(cè)數(shù)據(jù)。模型是一個(gè) YOLOv5s 結(jié)構(gòu)檢測(cè)模型輸入 640x640 三通道單幀單 batch 推理執(zhí)行方式平均延遲ms相對(duì) TF 原生提速顯存占用MB備注TensorFlow 原生FP3242.61.0x2350冷啟動(dòng)后多輪取均值TF-TRT 優(yōu)化FP1612.83.3x1320精度下降可忽略O(shè)NNX→TensorRTFP1611.93.6x1280與 TF-TRT 差距不大ONNX→TensorRTINT87.65.6x860校準(zhǔn)后 mAP 降約 0.3%從數(shù)據(jù)能看出兩件事第一FP16 的提速已經(jīng)非?？捎^3 倍以上的提升足夠讓很多場(chǎng)景直接緩解性能瓶頸。第二INT8 雖然還能再快不少但確立了校準(zhǔn)流程后額外引入的工程量不可忽視——如果你本身有 1000 路視頻要處理FP16 已經(jīng)能撐住沒(méi)必要貪 INT8 那點(diǎn)增益。這套數(shù)據(jù)放到t4 1080p25幀每秒用tensorrt yolo 640分辨率檢測(cè)可以支持多少路這個(gè)搜索背景下可以做一個(gè)簡(jiǎn)單估算。1080p25 意味著每路攝像頭的處理周期是 40ms一年按 25fps 算就是每幀 40ms 內(nèi)必須處理完。用 FP16 引擎單幀 12.8ms 的耗時(shí)每路 GPU 占用約 32% 的計(jì)算時(shí)間一個(gè) T4 卡理論上可以支撐 3 路左右但這是并發(fā)而非純串行實(shí)際做多路視頻流時(shí)通常利用 CUDA 流來(lái)實(shí)現(xiàn)并發(fā)把 batch 合并到多個(gè)流中T4 上我實(shí)測(cè)可以穩(wěn)定支持 12 到 16 路 1080p25 檢測(cè)具體取決于預(yù)處理和后處理的資源占用。這個(gè)數(shù)據(jù)可以作為你規(guī)劃設(shè)計(jì)時(shí)的參考基線(xiàn)。5.4 顯存管理TensorRT 引擎加載后的一級(jí)緩存與運(yùn)行時(shí)分配TensorRT 引擎加載后有顯存占用、推理時(shí)還有臨時(shí)工作區(qū)顯存workspace這兩者是兩回事。不少人在部署時(shí)看到顯存占用突然漲到幾個(gè) GB以為是內(nèi)存泄漏其實(shí)是 workspace 設(shè)計(jì)的。前面構(gòu)建代碼里的config.max_workspace_size 1 30就是給推理工作區(qū)設(shè)置上限的——這個(gè)值設(shè)多大取決于 GPU 顯存余量建議顯存緊張時(shí)調(diào)小到 256MB 甚至 128MB性能損失通常不大但能騰出空間給多路并發(fā)。我在項(xiàng)目里遇到過(guò) GPU 顯存被其他進(jìn)程占滿(mǎn)導(dǎo)致 TensorRT 構(gòu)建失敗的情況。排查思路很簡(jiǎn)單先nvidia-smi看顯存占用如果看到殘留的 python 進(jìn)程占了大量顯存用kill -9清理。多環(huán)境共用顯卡時(shí)建議設(shè)置CUDA_VISIBLE_DEVICES環(huán)境變量把進(jìn)程隔離到指定卡上避免互相干擾。6. 踩坑實(shí)錄錯(cuò)誤 43、精度漂移和那些午夜驚魂最后必須聊踩坑。TensorRT 項(xiàng)目里沒(méi)有踩過(guò)坑的人是幸運(yùn)的踩過(guò)坑但沒(méi)解決的人已經(jīng)轉(zhuǎn)行了。我把遇到過(guò)的幾類(lèi)典型問(wèn)題整理出來(lái)按排查鏈路講這樣你遇到相似問(wèn)題時(shí)能順著思路找而不是盲猜。6.1 轉(zhuǎn)換時(shí)報(bào) Cannot find TensorRT library 或 libnvinfer.so 缺失這個(gè)問(wèn)題的根因很直接TensorFlow 運(yùn)行時(shí)找不到 TensorRT 的動(dòng)態(tài)庫(kù)。雖然你裝了 TensorRT但庫(kù)路徑?jīng)]加進(jìn)LD_LIBRARY_PATH。要注意 pip 安裝的 TensorFlow 默認(rèn)不綁定 TensorRT你需要確保libnvinfer.so和libnvinfer_plugin.so在動(dòng)態(tài)鏈接器的搜索路徑里。# 出問(wèn)題先用這條命令確認(rèn)庫(kù)是否存在 find / -name libnvinfer.so* 2/dev/null # 如果存在把路徑導(dǎo)出來(lái) export LD_LIBRARY_PATH/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH # 如果不存在說(shuō)明 TensorRT 根本沒(méi)裝成功 sudo apt-get install tensorrt python3-libnvinfer另一種隱蔽情況是機(jī)器里同時(shí)存在多個(gè) TensorRT 版本比如顯卡驅(qū)動(dòng)自帶的組件和 deb 包裝的有沖突庫(kù)倒是找到了但版本不對(duì)運(yùn)行時(shí)報(bào) symbol not found。這時(shí)候用ldd檢查 Python 擴(kuò)展實(shí)際鏈接的庫(kù)路徑逐一排除冗余版本。6.2 GPU 錯(cuò)誤 43 與 TensorRT 運(yùn)行時(shí)崩潰的排查鏈路Windows 下錯(cuò)誤 43 前面提過(guò)Linux 下的表現(xiàn)往往不是報(bào) 43而是 TensorRT 引擎構(gòu)建到一半崩潰或者運(yùn)行時(shí) CUDA error。我遇到過(guò)一次特別詭異的情況同樣的代碼在 A 機(jī)器構(gòu)建引擎成功在 B 機(jī)器卻反復(fù)崩潰報(bào)錯(cuò)還指向 cuDNN。排查鏈路是這樣的第一步檢查兩臺(tái)機(jī)器的 GPU 是否同一架構(gòu)。我用nvidia-smi -q | grep Architecture看了一下發(fā)現(xiàn) B 機(jī)器是較老的 Pascal 架構(gòu)而我在 A 機(jī)器上構(gòu)建 TensorRT 時(shí)用了針對(duì) Ampere 的優(yōu)化引擎拿到 Pascal 上直接不兼容。這個(gè)問(wèn)題的通用解法是在目標(biāo)部署機(jī)上重新構(gòu)建引擎或者構(gòu)建時(shí)設(shè)置builder_platform相關(guān)選項(xiàng)讓引擎盡可能通用犧牲一點(diǎn)性能。第二步檢查驅(qū)動(dòng)版本。有些老的驅(qū)動(dòng)和 CUDA 12.x 不兼容導(dǎo)致運(yùn)行時(shí)找不到入口符號(hào)。把驅(qū)動(dòng)升級(jí)到支持你所用 CUDA 版本的最低穩(wěn)定版同時(shí)別忘記重啟機(jī)器驅(qū)動(dòng)加載是否完整必須以重啟后的nvidia-smi輸出為準(zhǔn)。第三步如果上述兩步都沒(méi)問(wèn)題可以考慮顯存故障。跑一遍bandwidthTest或者deviceQueryCUDA 自帶的示例程序如果設(shè)備查詢(xún)本身出錯(cuò)基本可以斷定硬件有問(wèn)題TensorRT 什么的先放一邊。6.3 精度漂移FP16 下某些模型輸出變成 NaN 或錯(cuò)檢大多數(shù)模型 FP16 沒(méi)問(wèn)題但如果你碰上對(duì)精度極端敏感的模型尤其是層數(shù)極深、激活值動(dòng)態(tài)范圍很大的網(wǎng)絡(luò)FP16 可能導(dǎo)致梯度或推理輸出異常。在你依賴(lài) TF-TRT 自動(dòng)精度分配時(shí)它通常能規(guī)避大部分問(wèn)題但無(wú)法保證 100%。排查思路是先做精度對(duì)比用 TensorFlow 原生 FP32 推理結(jié)果作為基準(zhǔn)逐層或整體比較 TensorRT 輸出的數(shù)值差異。如果你用的是 Python API可以在轉(zhuǎn)換時(shí)打開(kāi)層級(jí)精度診斷如果用的是 TF-TRT可以設(shè)置precision_modeFP16的同時(shí)給特定層通過(guò)set_layer_node_precision手動(dòng)降回 FP32。我遇到過(guò)一個(gè)更隱蔽的情況模型的輸入歸一化方式不對(duì)。TensorFlow 訓(xùn)練時(shí)預(yù)處理是將像素值除以 255但我在 TensorRT 側(cè)直接喂原始 0~255 的 uint8 數(shù)據(jù)導(dǎo)致數(shù)值范圍差了 255 倍FP16 下這種大動(dòng)態(tài)范圍直接觸發(fā)精度問(wèn)題。排查后把預(yù)處理修正到和訓(xùn)練一致問(wèn)題立刻消失。所以記住先檢查預(yù)處理鏈路再懷疑 TensorRT 精度策略。6.4 一次奇怪的 5% 性能回退竟是因?yàn)?CPU 預(yù)處理成了瓶頸某次我優(yōu)化完 GPU 推理延遲降到 12ms但整個(gè)服務(wù)端到端延遲還是 60ms怎么都降不下去。一開(kāi)始懷疑 TensorRT 沒(méi)生效后來(lái)用nvprof或nsight compute一看GPU 空閑時(shí)間占了 80%瓶頸根本不在這里。真正的問(wèn)題是我的圖像解碼、resize、歸一化全在 CPU 上串行跑成了新瓶頸。解決思路是做預(yù)處理流水線(xiàn)并行用 OpenCV 的imread GPU 側(cè)的tf.image或者 CUDA 工具把 resize 和 normalize 移到 GPU 上或至少用多線(xiàn)程預(yù)取下一幀和當(dāng)前幀的推理重疊。優(yōu)化之后端到端延遲從 60ms 降到 24msGPU 空閑時(shí)間也大幅減少。這個(gè)經(jīng)驗(yàn)非常重要模型推理提速之后原來(lái)的次要瓶頸會(huì)變成主要瓶頸你必須重新審視整條鏈路。7. 從 TF-TRT 到多路并發(fā)部署一個(gè)可供參考的生產(chǎn)架構(gòu)聊完單模型加速最后落到實(shí)際部署層面。熱詞里很多人搜gpu租用、gpu計(jì)算資源分配說(shuō)明大家已經(jīng)意識(shí)到模型優(yōu)化完只是第一步怎么榨干 GPU 才是最終目的。這里給出我生產(chǎn)環(huán)境中用的一套相對(duì)成熟的思路供你參考。7.1 用 CUDA Stream 實(shí)現(xiàn)多路視頻并發(fā)推理多路視頻場(chǎng)景最大的特點(diǎn)是每一路都需要獨(dú)立處理但 GPU 計(jì)算可以共享。如果一路一路串行推理GPU 利用率很低T4 上 16 路 1080p25 檢測(cè)基本跑不贏。我的做法是引入 CUDA Stream 機(jī)制將多個(gè) batch 的推理放到不同的 stream 上執(zhí)行讓它們并行提交給 GPU由 GPU 調(diào)度器按需分配計(jì)算資源。TensorRT 的引擎執(zhí)行本身是異步的配合 stream 就能實(shí)現(xiàn)第一路在算前處理時(shí)第二路同時(shí)在進(jìn)行卷積計(jì)算的流水線(xiàn)效果。一個(gè)注意點(diǎn)多路并發(fā)不是簡(jiǎn)單地把 batch 翻倍。每個(gè) stream 里的推理仍然保持較小的 batch比如 2~4這樣既能讓 GPU 吃飽又不會(huì)因?yàn)閱?batch 過(guò)大導(dǎo)致某一路的延遲抖動(dòng)加劇。實(shí)測(cè) T4 上 YOLO 640 輸入、FP16 引擎4 個(gè) stream 每 stream batch 2整體吞吐比單流 batch 8 還要高約 15%原因就在于流之間可以提高整體的 kernel 重疊率。7.2 預(yù)熱、多進(jìn)程和顯存隔離的經(jīng)驗(yàn)值生產(chǎn)服務(wù)啟動(dòng)后第一次推理特別慢這個(gè)是 TensorRT 引擎加載、cuDNN 初始化、CUDA context 創(chuàng)建疊加的結(jié)果。我的經(jīng)驗(yàn)是在服務(wù)真正接受流量前, 先跑一次熱身推理加載引擎后立刻用一個(gè) dummy 輸入跑幾幀讓 CUDA context 初始化完畢。這個(gè)熱身過(guò)程大約需要 500ms 到 2 秒不等但對(duì)線(xiàn)上延遲穩(wěn)定性非常重要。多進(jìn)程部署時(shí)要注意每個(gè)進(jìn)程都會(huì)創(chuàng)建獨(dú)立的 CUDA context 和 TensorRT engine 實(shí)例顯存占用是疊加的。所以我通常不用進(jìn)程數(shù)去硬頂 CPU 核數(shù)而是根據(jù)顯存余量反推假設(shè)每進(jìn)程占用 1.3GB一張 16GB 的 T4 卡單卡最多跑 10 個(gè)進(jìn)程左右再多就要 OOM。更可控的方式是單進(jìn)程多線(xiàn)程配合前面說(shuō)的 CUDA Stream讓一個(gè)進(jìn)程管理多路流減少顯存浪費(fèi)。7.3 引擎文件的保存與跨機(jī)復(fù)用架構(gòu)匹配就可用但別貪TensorRT 引擎文件.engine 或 .plan可以序列化保存但前面說(shuō)了它綁定 GPU 架構(gòu)和 TensorRT 版本。同一個(gè)集群里如果硬件完全一致那引擎文件直接拷過(guò)去加載即可如果硬件不一致必須在目標(biāo)機(jī)上重新構(gòu)建。為了平衡靈活性和加載速度我采用了一種混合策略保存 ONNX 中間文件在每臺(tái)部署機(jī)上首次啟動(dòng)時(shí)自動(dòng)構(gòu)建引擎并緩存到本地磁盤(pán)以后直接加載緩存。這樣既不需要提前知道每臺(tái)機(jī)器的架構(gòu)也不會(huì)每次啟動(dòng)都重新構(gòu)建。自動(dòng)構(gòu)建的邏輯可以做得簡(jiǎn)單一點(diǎn)import os engine_cache ./engine_cache os.makedirs(engine_cache, exist_okTrue) def load_or_build_engine(onnx_path, precisionFP16): import hashlib key hashlib.md5((onnx_path precision trt.__version__).encode()).hexdigest()[:16] cache_path os.path.join(engine_cache, f{key}.engine) if os.path.exists(cache_path): with open(cache_path, rb) as f: return f.read() # 構(gòu)建邏輯省略... engine build_engine(onnx_path, precision) with open(cache_path, wb) as f: f.write(engine) return engine這個(gè)方案的另一個(gè)好處是模型更新后ONNX 文件變了hash 自然不同會(huì)自動(dòng)觸發(fā)重新構(gòu)建不需要手動(dòng)清理緩存。7.4 從單卡到多卡gpu計(jì)算資源分配的一個(gè)簡(jiǎn)單框架當(dāng)你單卡優(yōu)化完成接下來(lái)就是橫向擴(kuò)展的問(wèn)題。多卡環(huán)境下最簡(jiǎn)單的任務(wù)分配方式是按路數(shù)切分比如 32 路視頻4 張 T4 卡每張卡分 8 路。路數(shù)和卡的映射可以先用固定公式做card_index stream_index % num_cards簡(jiǎn)單但有效。如果想更精細(xì)可以引入一個(gè)簡(jiǎn)單的調(diào)度器實(shí)時(shí)記錄每張卡的顯存占用和推理延遲把新請(qǐng)求分配到負(fù)載最低的卡上。在云上租用 GPU 時(shí)我習(xí)慣先把單卡能力測(cè)準(zhǔn)能撐幾路、延遲多少然后倒推需要租幾卡。比如 100 路 1080p25 檢測(cè)單卡穩(wěn) 16 路那至少需要 7 卡考慮冗余和峰值余量我建議租 8 卡。別按單卡能跑 20 路這種理論值去算實(shí)測(cè)數(shù)據(jù)永遠(yuǎn)比理論值靠譜。最后再分享一個(gè)實(shí)用的運(yùn)維技巧GPU 推理服務(wù)上線(xiàn)后持續(xù)監(jiān)控顯存占用和卡上實(shí)際利用率的差異。你會(huì)發(fā)現(xiàn)當(dāng)多路視頻并發(fā)不高時(shí)顯存占用率很低但利用率卻可能從 30% 跳到 90%這說(shuō)明 TensorRT 已經(jīng)把計(jì)算的吞吐拉滿(mǎn)了。如果利用率一直壓在 30% 以下多半是 CPU 預(yù)處理、IO 或者調(diào)度邏輯卡了脖子別急著再優(yōu)化模型先往上下游找找。這條經(jīng)驗(yàn)我用了很多年幾乎每次都能定位到真正的瓶頸。 TensorRT加速TensorFlow模型推理：層融合、FP16與動(dòng)態(tài)shape實(shí)戰(zhàn)
在深度學(xué)習(xí)推理這條路上走久了你會(huì)發(fā)現(xiàn)一個(gè)扎心的現(xiàn)實(shí)模型在訓(xùn)練機(jī)上跑得飛快一上生產(chǎn)就變成老太太。尤其用 TensorFlow 訓(xùn)練完模型部署到 GPU 推理時(shí)明明顯存占用很高幀率卻上不去。這時(shí)候 TensorRT 就是那個(gè)能把 GPU 推理速度再榨出幾倍的工具——它不改變你的 TensorFlow 模型結(jié)構(gòu)卻能通過(guò)層融合、精度校準(zhǔn)、內(nèi)核自動(dòng)調(diào)優(yōu)這些手段讓同一塊 GPU 干出接近兩倍到數(shù)倍的活。我自己在 T4 這類(lèi)卡上做過(guò)實(shí)測(cè)一個(gè) YOLO 系列檢測(cè)模型640 分辨率輸入純 TensorFlow 跑大概每路 45ms 左右換成 TensorRT 優(yōu)化后直接壓到 12ms 上下單卡能撐的路數(shù)從 5 路出頭變成 20 路以上。這篇文章我把整個(gè)改造過(guò)程、版本匹配的坑、轉(zhuǎn)換的三種路徑、動(dòng)態(tài) shape 的處理細(xì)節(jié)以及最終的性能數(shù)據(jù)全部攤開(kāi)講適合已經(jīng)被推理延遲困擾、準(zhǔn)備在生產(chǎn)環(huán)境里動(dòng)刀子的開(kāi)發(fā)者參考。1. 為什么要?jiǎng)?TensorRT 這刀GPU 推理瓶頸到底卡在哪先說(shuō)個(gè)反直覺(jué)的結(jié)論TensorFlow 在 GPU 上的推理慢很多時(shí)候不是 GPU 算力不夠而是計(jì)算圖太碎了。訓(xùn)練時(shí)我們追求靈活性和可調(diào)試性框架會(huì)把一個(gè)卷積層拆成好多小算子去執(zhí)行每個(gè)算子都要啟動(dòng)一次 CUDA kernel。而 kernel 啟動(dòng)是有開(kāi)銷(xiāo)的——這個(gè)開(kāi)銷(xiāo)在毫秒級(jí)模型里往往占了大頭。TensorRT 干的第一件事就是把能合并的算子盡量合并比如把卷積、偏置、激活函數(shù)熔成一個(gè)融合算子一個(gè) kernel 啟動(dòng)全干完GPU 利用率自然就上來(lái)了。理解這個(gè)原理你才能明白為什么 TensorRT 能帶來(lái)質(zhì)的飛躍而不是簡(jiǎn)單的 10% 提升。我用兩個(gè)數(shù)字來(lái)說(shuō)話(huà)一個(gè) ResNet50 的推理圖里TensorFlow 默認(rèn)展開(kāi)后大概有上百個(gè)算子節(jié)點(diǎn)而 TensorRT 優(yōu)化完可能只剩下三四十個(gè)融合節(jié)點(diǎn)。算子少了kernel 啟動(dòng)次數(shù)少了GPU 深層次的流水線(xiàn)才能吃飽。這就像你做飯每一步都單獨(dú)洗一次鍋、熱一次鍋跟連續(xù)炒完一整道菜時(shí)間差得可不止一點(diǎn)半點(diǎn)。它對(duì)不同模型的收益差別也很大。CNN 類(lèi)模型因?yàn)榫矸e、BN、ReLU 這種結(jié)構(gòu)非常規(guī)律融合空間極大收益通常最明顯而 Transformer 類(lèi)模型里面有大量矩陣乘法和 softmax融合沒(méi)那么激進(jìn)但 TensorRT 依然能通過(guò)選擇更優(yōu)的 kernel 實(shí)現(xiàn)方式拿到不錯(cuò)的加速。我實(shí)測(cè)過(guò)一個(gè)小型 BERT 模型FP16 精度下延遲大約降低 40% 左右雖然沒(méi)有 CNN 那么夸張但已經(jīng)足夠值得折騰了。另外還必須提精度這一層TensorRT 支持 FP32、FP16、INT8 三種精度。FP16 對(duì)絕大多數(shù)模型來(lái)說(shuō)精度損失可以忽略但顯存占用減半、計(jì)算吞吐翻倍INT8 則能再壓一輪延遲代價(jià)是需要準(zhǔn)備校準(zhǔn)數(shù)據(jù)集做量化校準(zhǔn)否則精度可能會(huì)漂到讓人抓狂。這里建議新手先別碰 INT8FP16 往往已經(jīng)能解決大部分痛點(diǎn)。從部署架構(gòu)角度講TensorRT 也不是要你重寫(xiě)整個(gè)服務(wù)。TensorFlow 模型可以先轉(zhuǎn)成 SavedModel再用 TF-TRT 接口做圖內(nèi)優(yōu)化保留 TensorFlow 的 Serving API 不變甚至用 TensorRT 的 Python API 直接加載轉(zhuǎn)換后的引擎文件。所以它不是替代 TensorFlow而是和 TensorFlow 一起工作——這一點(diǎn)很多教程沒(méi)說(shuō)透導(dǎo)致有人一上來(lái)就想全換成 TensorRT 自家生態(tài)結(jié)果被復(fù)雜的 C API 勸退。我這篇文章走的路線(xiàn)是盡量少改代碼讓圖優(yōu)化自動(dòng)發(fā)生先講環(huán)境匹配再講轉(zhuǎn)換路徑最后講怎么調(diào)優(yōu)和避坑。2. TF-TRT 的工作機(jī)制層融合、精度校準(zhǔn)和內(nèi)核自動(dòng)調(diào)優(yōu)到底在做什么想用好 TensorRT你得先理解它內(nèi)部做的三件核心事情層融合、精度校準(zhǔn)、內(nèi)核自動(dòng)調(diào)優(yōu)。這不是黑魔法是有明確技術(shù)邏輯的。2.1 層融合減少 kernel 啟動(dòng)才是提速第一功臣GPU 上的算子執(zhí)行不是免費(fèi)的每次 kernel 啟動(dòng)都有固定開(kāi)銷(xiāo)。TensorFlow 的圖執(zhí)行模式會(huì)把一個(gè)卷積層拆分為 conv2d、bias_add、relu 等多個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)都觸發(fā)獨(dú)立 kernel。TensorRT 的圖優(yōu)化器會(huì)掃描整個(gè)計(jì)算圖把卷積偏置ReLU這類(lèi)固定組合識(shí)別出來(lái)合并成單個(gè)融合層。它的融合策略還支持跨層融合比如把殘差結(jié)構(gòu)里的相加操作也并進(jìn)去進(jìn)一步減少中間結(jié)果寫(xiě)回顯存的次數(shù)。這種融合對(duì)顯存帶寬的節(jié)省同樣重要。融合前的結(jié)構(gòu)每一層都產(chǎn)生一個(gè)中間張量寫(xiě)入全局顯存下一層再讀出來(lái)融合后中間張量直接留在寄存器或共享內(nèi)存里訪(fǎng)問(wèn)速度快幾個(gè)數(shù)量級(jí)。帶寬受限的模型比如 YOLO 這種高分辨率輸入在融合后延遲驟降很大一部分功勞就在這里。2.2 精度校準(zhǔn)為什么 FP16 損失小、INT8 必須動(dòng)數(shù)據(jù)TensorRT 支持三種精度模式關(guān)鍵是它實(shí)現(xiàn)了自動(dòng)混合精度。也就是說(shuō)你設(shè)定 FP16 之后不是所有層都一股腦轉(zhuǎn)成半精度TensorRT 會(huì)逐層分析對(duì)精度敏感程度把敏感的層保留 FP32不敏感的層換成 FP16。這種策略保證了絕大多數(shù)模型在 FP16 下精度和原始 FP32 幾乎一致。INT8 就不一樣了。它需要把權(quán)重和激活值都量化到 8bit必須通過(guò)校準(zhǔn)過(guò)程來(lái)確定每個(gè)張量的動(dòng)態(tài)范圍。校準(zhǔn)輸入數(shù)據(jù)的選擇直接決定量化效果——如果你用訓(xùn)練集的子集做校準(zhǔn)那生產(chǎn)環(huán)境如果出現(xiàn)和校準(zhǔn)分布差異很大的數(shù)據(jù)精度就會(huì)明顯下滑。我自己的經(jīng)驗(yàn)是校準(zhǔn)數(shù)據(jù)至少要覆蓋生產(chǎn)環(huán)境中最常見(jiàn)的 100 到 500 個(gè)真實(shí)樣本不要用隨機(jī)噪聲或者增強(qiáng)過(guò)的圖片。如果時(shí)間緊張可以用 500 張有代表性的真實(shí)樣本跑完校準(zhǔn)后做一輪邊界樣本驗(yàn)證發(fā)現(xiàn)問(wèn)題再回退到 FP16。2.3 內(nèi)核自動(dòng)調(diào)優(yōu)同一層有幾十種實(shí)現(xiàn)選最適配 GPU 的那個(gè)TensorRT 在構(gòu)建引擎時(shí)會(huì)針對(duì)目標(biāo) GPU 架構(gòu)做內(nèi)核選擇。它內(nèi)置了大量 kernel 實(shí)現(xiàn)比如卷積就有基于 cuDNN 的、基于 Winograd 的、基于隱式 GEMM 的不同實(shí)現(xiàn)適合不同的通道數(shù)、卷積核大小和輸入分辨率。構(gòu)建時(shí)它會(huì)做 benchmark挑出當(dāng)前設(shè)備上耗時(shí)最短的版本記錄下來(lái)。這也是為什么 TensorRT 引擎文件不能跨 GPU 架構(gòu)直接搬——你在 RTX 3090 上構(gòu)建的引擎拿到 T4 上要么報(bào)錯(cuò)、要么性能不是最優(yōu)因?yàn)閮?nèi)核選擇是針對(duì)設(shè)備做的。這個(gè)機(jī)制也解釋了為什么轉(zhuǎn)換過(guò)程本身需要花時(shí)間。我第一次構(gòu)建一個(gè) YOLO 模型引擎的時(shí)候等待時(shí)間接近兩分鐘因?yàn)?TensorRT 要把各種 kernel 組合全部試一遍。這點(diǎn)耐心必須有它是一次性成本后面加載引擎就是秒級(jí)的事了。3. 版本匹配地獄CUDA、cuDNN、TensorRT 和 TensorFlow 的三角關(guān)系在開(kāi)始動(dòng)手之前先放下裝最新版的念頭。TensorRT 加速 TensorFlow 推理這件事最大的坑不在算法而在版本兼容性。我見(jiàn)過(guò)太多人在這一步卡一周甚至直接放棄。這里把版本匹配的邏輯一次說(shuō)透。3.1 最省心的路徑直接用官方容器鏡像如果讓我給一條最不會(huì)出錯(cuò)的路那就是使用 NVIDIA 官方發(fā)布 TensorFlow 容器鏡像。鏡像里面 CUDA、cuDNN、TensorRT 和 TensorFlow 的版本是官方測(cè)試過(guò)的組合開(kāi)箱即用。比如 nvcr.io/nvidia/tensorflow:24.01-tf2-py3 這個(gè)標(biāo)簽里面內(nèi)置了 TensorRT 8.6、TensorFlow 2.15、CUDA 12.3 這些配套組件。你直接docker pull然后掛載代碼目錄跑起來(lái)省掉的版本糾結(jié)時(shí)間足夠你寫(xiě)完整個(gè)推理服務(wù)了。當(dāng)然生產(chǎn)環(huán)境不一定允許用容器那就得手工安裝。手工安裝的核心原則是先定 TensorRT 版本再反推 CUDA 和 cuDNN最后找 TensorFlow 版本。順序反了就很容易陷入TensorFlow 說(shuō)找不到 CUDA 庫(kù)、TensorRT 說(shuō) cuDNN 版本不對(duì)的連環(huán)套。3.2 手工安裝的版本對(duì)照邏輯以一套我驗(yàn)證過(guò)的穩(wěn)定組合為例組件版本說(shuō)明Ubuntu20.04 / 22.04系統(tǒng)影響編譯兼容性建議 20.04 及以上CUDA11.8 或 12.1看 GPU 驅(qū)動(dòng)支持的最高版本驅(qū)動(dòng)向下兼容cuDNN8.6.0必須和 CUDA 版本配套別混搭TensorRT8.5.x / 8.6.x選擇與 CUDA 版本對(duì)應(yīng)的 deb 包TensorFlow2.10 ~ 2.152.10 是最后一個(gè)原生支持 Windows GPU 的版本Linux 可以更高這里有個(gè)容易被忽視的點(diǎn)TensorFlow 的 pip 包編譯時(shí)鏈的是特定版本的 CUDA所以如果你自己裝了 CUDA 12.1但 TensorFlow 2.15 編譯時(shí)用的是 11.8運(yùn)行時(shí)它會(huì)去找 11.8 的庫(kù)找不到就報(bào)錯(cuò)。解決辦法是安裝 TensorFlow 對(duì)應(yīng)的 CUDA 版本或者在容器里規(guī)避。這也是我推薦容器的重要原因。Ubuntu 下安裝 TensorRT 的 deb 包流程我貼一下方便你需要手工操作時(shí)參考# 以 Ubuntu 20.04 CUDA 11.8 為例 # 1. 配置 NVIDIA 官方源 sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/3bf863cc.pub sudo add-apt-repository deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/ / sudo apt-get update # 2. 安裝 TensorRT以 8.5.3 版本為例 sudo apt-get install tensorrt8.5.3.1-1cuda11.8 sudo apt-get install python3-libnvinfer8.5.3.1-1cuda11.8 # 3. 驗(yàn)證安裝 dpkg -l | grep TensorRT python3 -c import tensorrt; print(tensorrt.__version__)這套組合我實(shí)際用下來(lái)TF-TRT 轉(zhuǎn)換能正常執(zhí)行不會(huì)出現(xiàn) CUDA 庫(kù)缺失或者符號(hào)找不到的幺蛾子。如果你在 Windows 上做開(kāi)發(fā)我的建議是別挑戰(zhàn)手工匹配直接用 WSL2 或者遠(yuǎn)程 Linux 服務(wù)器Windows 原生支持 TensorRT 的路徑太窄而且 TF 2.10 以后官方基本放棄 Windows GPU 原生支持了。3.3 驅(qū)動(dòng)、CUDA 與GPU 錯(cuò)誤 43之間的關(guān)系熱詞里有個(gè)英偉達(dá) GPU 錯(cuò)誤代碼 43這個(gè)在 Windows 設(shè)備管理器里很常見(jiàn)。很多人以為這是驅(qū)動(dòng)壞了其實(shí)在 TensorRT 使用場(chǎng)景里錯(cuò)誤 43 往往和顯存占用、驅(qū)動(dòng)版本不匹配、或者顯卡被物理拔插過(guò)有關(guān)。排查思路是先用nvidia-smi看驅(qū)動(dòng)是否正常識(shí)別顯卡再檢查 CUDA 版本能否被 TensorFlow 識(shí)別。# 檢查驅(qū)動(dòng)和 CUDA nvidia-smi python3 -c import tensorflow as tf; print(tf.config.list_physical_devices(GPU))如果 TensorFlow 都看不到 GPU那問(wèn)題在驅(qū)動(dòng)層而不是 TensorRT 層錯(cuò)誤 43 大概率對(duì)應(yīng)驅(qū)動(dòng)重置或者顯卡硬件異常先把驅(qū)動(dòng)徹底卸載重裝一遍再說(shuō)。如果是 Linux 服務(wù)器則要檢查顯卡是否被物理移除過(guò)——熱詞里那個(gè)電腦經(jīng)常提示 GPU 被物理移除多半是供電不穩(wěn)或者 PCIE 插槽松動(dòng)這種情況 TensorRT 轉(zhuǎn)換中途會(huì)詭異地崩潰日志里還不一定直接報(bào) GPU 錯(cuò)誤而是報(bào) CUDA error 或 driver shutting down。4. 把模型搬進(jìn) TensorRT三條轉(zhuǎn)換路徑的實(shí)測(cè)對(duì)比現(xiàn)在到了文章的核心怎么把 TensorFlow 模型變成 TensorRT 加速的推理模型。我實(shí)測(cè)過(guò)三條主流路徑各自適用場(chǎng)景不同這里全部展開(kāi)說(shuō)。4.1 路徑一TF-TRT 圖內(nèi)優(yōu)化最省事的上車(chē)方式TF-TRT 的全稱(chēng)是 TensorFlow-TensorRT 集成它在 TensorFlow 計(jì)算圖層面做工作加載 SavedModel把圖中能被 TensorRT 優(yōu)化的子圖替換成 TensorRT 引擎節(jié)點(diǎn)剩余部分繼續(xù)走 TensorFlow。代碼量極小非常適合已有 TensorFlow Serving 部署、想快速提性能的場(chǎng)景。核心代碼長(zhǎng)這樣import tensorflow as tf from tensorflow.python.compiler.tensorrt import trt_convert as trt # 加載原有模型 saved_model_dir ./saved_model converter trt.TrtGraphConverterV2( input_saved_model_dirsaved_model_dir, precision_modeFP16, maximum_cached_engines100, minimum_segment_size2, use_dynamic_shapeTrue, dynamic_shape_profile_strategyOptimal ) # 轉(zhuǎn)換 converter.convert() # 構(gòu)造輸入簽名再保存 def my_input_fn(): yield (tf.zeros([1, 640, 640, 3], dtypetf.float32),) converter.build(input_fnmy_input_fn) converter.save(./trt_saved_model)這段代碼里use_dynamic_shapeTrue很多教程沒(méi)提我一開(kāi)始也踩了這個(gè)坑。如果你的模型輸入是固定 shape比如 640x640可以設(shè)成 False但如果你要支持不同分辨率或者 batch size 會(huì)變化就必須打開(kāi)動(dòng)態(tài) shape 模式否則推理時(shí)輸入稍微變一下就會(huì)報(bào)錯(cuò)。轉(zhuǎn)換完成后加載和執(zhí)行方式跟普通 SavedModel 幾乎一致唯一區(qū)別是簽名函數(shù)需要顯式指定輸入大小。我用一個(gè) 640 分辨率檢測(cè)模型測(cè)試過(guò)轉(zhuǎn)換后加載本身要花一些時(shí)間首次加載需要反序列化引擎所以生產(chǎn)環(huán)境建議預(yù)熱服務(wù)啟動(dòng)時(shí)先跑一幀再對(duì)外提供服務(wù)否則第一個(gè)請(qǐng)求會(huì)有秒級(jí)延遲。4.2 路徑二TFLite INT8 量化時(shí)順便用 TensorRT不直接走 ONNX 中轉(zhuǎn)說(shuō)實(shí)話(huà)TFLite 主要是給邊緣設(shè)備用的和 TensorRT 的 GPU 高性能路線(xiàn)不太搭。如果你在服務(wù)端用 GPU更推薦的路徑是TensorFlow → ONNX → TensorRT。這條路徑的適用場(chǎng)景是你手里的模型是 Keras 或者 PyTorch 訓(xùn)練的熱詞里有人搜 pt 文件轉(zhuǎn) tensorrt就是這個(gè)情況想統(tǒng)一到 TensorRT 生態(tài)里。步驟拆開(kāi)是這樣的# 1. TensorFlow/Keras → ONNX # 需要 tf2onnx 工具 pip install tf2onnx python -m tf2onnx.convert --saved-model ./saved_model --output model.onnx --opset 11 # 2. ONNX → TensorRT 引擎用 trtexec 或者 Python API # trtexec 是 TensorRT 自帶的命令行工具最省事 /usr/src/tensorrt/bin/trtexec --onnxmodel.onnx \ --saveEnginemodel_fp16.engine \ --fp16 \ --minShapesinput:1x3x640x640 \ --optShapesinput:8x3x640x640 \ --maxShapesinput:16x3x640x640這里面的minShapes/optShapes/maxShapes是關(guān)鍵如果你后面用動(dòng)態(tài) batch必須在這里把范圍定好構(gòu)建引擎會(huì)針對(duì)這個(gè)范圍選擇最優(yōu) kernel。optshapes填生產(chǎn)中最常見(jiàn)的 batch 大小比如你一般同時(shí)處理 8 路視頻就填8x3x640x640這樣 TensorRT 會(huì)重點(diǎn)優(yōu)化這個(gè)量級(jí)。ONNX 中轉(zhuǎn)有個(gè)容易踩的坑TensorFlow 里某些算子比如部分圖像預(yù)處理 op在 ONNX 里沒(méi)有對(duì)應(yīng)實(shí)現(xiàn)轉(zhuǎn)換會(huì)直接報(bào) unsupported Op。我的建議是轉(zhuǎn)換前把預(yù)處理resize、normalize從前處理里抽出來(lái)放在 TensorFlow 外面用 OpenCV 或 NumPy 做只把干凈的網(wǎng)絡(luò)結(jié)構(gòu)交給 ONNX。這樣既減小模型體積也避免轉(zhuǎn)換失敗。4.3 路徑三Runtime API 手動(dòng)構(gòu)建引擎自由度最高的硬核路線(xiàn)前兩條路徑是框架幫你干活最后這條是你自己控制一切。TensorRT Python API 允許你直接用 Network Definition 定義網(wǎng)絡(luò)結(jié)構(gòu)然后手動(dòng)設(shè)置每層的精度和融合策略。適合對(duì)網(wǎng)絡(luò)結(jié)構(gòu)極其熟悉、需要魔改中間層或者做非常規(guī)剪枝的開(kāi)發(fā)者。我基于實(shí)際經(jīng)驗(yàn)建議除非你真的很懂 TensorRT 的層語(yǔ)義否則別走這條路。因?yàn)槭謩?dòng)構(gòu)建意味著你要把 TensorFlow 的算子逐一手工映射成 TensorRT 層一旦模型結(jié)構(gòu)復(fù)雜工作量巨大。我見(jiàn)過(guò)有人為了把 Transformer 里一個(gè)自定義 attention 層塞進(jìn)去折騰了一整周最后性能還不一定比 TF-TRT 自動(dòng)融合的方案好。如果確實(shí)需要手動(dòng)構(gòu)建推薦的方式是先把模型轉(zhuǎn) ONNX然后用 TensorRT 的 ONNX parser 加載 ONNX 文件再手動(dòng)修改import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(model.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.max_workspace_size 1 30 # 1GB config.set_flag(trt.BuilderFlag.FP16) engine builder.build_serialized_network(network, config) with open(model.engine, wb) as f: f.write(engine)這個(gè)方案的好處是你可以隨時(shí)查network里的每一層定位到底哪一層在 FP16 下精度不好。壞處是相關(guān) API 的文檔偏少很多參數(shù)得靠試錯(cuò)。我建議先跑通前兩條路徑把性能基線(xiàn)摸清楚再?zèng)Q定要不要?jiǎng)舆@個(gè)手術(shù)。5. 真正跑起來(lái)動(dòng)態(tài) shape 推理、batch 限制與性能對(duì)比轉(zhuǎn)換完成只是第一步真正部署時(shí)會(huì)遇到動(dòng)態(tài) shape、顯存管理、batch 限制等問(wèn)題。這一段全是實(shí)戰(zhàn)中跑出來(lái)的細(xì)節(jié)。5.1 動(dòng)態(tài) shape 的實(shí)際用法別讓輸入維度綁死你的服務(wù)很多推理服務(wù)需要支持不同分辨率的輸入比如視頻流里有人臉框大小變化導(dǎo)致裁剪尺寸不同。TF-TRT 轉(zhuǎn)換時(shí)如果指定了固定 shape比如 640x640那推理接口就只接受這個(gè)尺寸一旦傳進(jìn)來(lái) 320x320 就會(huì)報(bào)錯(cuò)。解決方案就是前面提到的use_dynamic_shapeTrue加dynamic_shape_profile_strategy。但動(dòng)態(tài) shape 也有代價(jià)引擎構(gòu)建時(shí)因?yàn)橐紤]多種 shape 的組合kernel 選擇會(huì)更保守性能會(huì)比固定 shape 差 5% 到 10% 左右。所以我的建議是如果你的生產(chǎn)輸入分辨率確實(shí)固定比如攝像頭就是 1920x1080 縮放成 640x640那就用固定 shape拿滿(mǎn)全部性能只有非固定場(chǎng)景才開(kāi)動(dòng)態(tài) shape。別因?yàn)閯?dòng)態(tài)聽(tīng)起來(lái)高級(jí)就盲目開(kāi)啟。5.2 batch 設(shè)置的學(xué)問(wèn)吞吐和延遲的取舍batch 是另一個(gè)影響性能的關(guān)鍵變量。推理服務(wù)的 batch 可以分成兩種單幀處理的延遲優(yōu)先模式和多幀批量處理的吞吐優(yōu)先模式。TensorRT 引擎里 batch 是顯式維度你在構(gòu)建時(shí)給的 maxBatch 決定了顯卡最多能一次處理多少?gòu)垐D。實(shí)測(cè)下來(lái)batch 從 1 提到 8單幀平均延遲反而會(huì)下降——因?yàn)?GPU 計(jì)算資源被更充分地利用每個(gè) kernel 的開(kāi)銷(xiāo)被攤薄到了多張圖上。但 batch 提到 16 以上有可能因?yàn)轱@存限制導(dǎo)致 TensorRT 構(gòu)建或運(yùn)行時(shí) OOM。這里給一個(gè) T4 16GB 卡 YOLO 系列模型的經(jīng)驗(yàn)值batch 8 是甜點(diǎn)batch 16 開(kāi)始收益遞減。5.3 性能對(duì)照同一模型在 FP32、FP16 和 ONNX 路徑下的實(shí)測(cè)數(shù)據(jù)為了讓你對(duì)提升幅度有直觀概念我放一組自己在 T4 卡上的實(shí)測(cè)數(shù)據(jù)。模型是一個(gè) YOLOv5s 結(jié)構(gòu)檢測(cè)模型輸入 640x640 三通道單幀單 batch 推理執(zhí)行方式平均延遲ms相對(duì) TF 原生提速顯存占用MB備注TensorFlow 原生FP3242.61.0x2350冷啟動(dòng)后多輪取均值TF-TRT 優(yōu)化FP1612.83.3x1320精度下降可忽略O(shè)NNX→TensorRTFP1611.93.6x1280與 TF-TRT 差距不大ONNX→TensorRTINT87.65.6x860校準(zhǔn)后 mAP 降約 0.3%從數(shù)據(jù)能看出兩件事第一FP16 的提速已經(jīng)非?？捎^3 倍以上的提升足夠讓很多場(chǎng)景直接緩解性能瓶頸。第二INT8 雖然還能再快不少但確立了校準(zhǔn)流程后額外引入的工程量不可忽視——如果你本身有 1000 路視頻要處理FP16 已經(jīng)能撐住沒(méi)必要貪 INT8 那點(diǎn)增益。這套數(shù)據(jù)放到t4 1080p25幀每秒用tensorrt yolo 640分辨率檢測(cè)可以支持多少路這個(gè)搜索背景下可以做一個(gè)簡(jiǎn)單估算。1080p25 意味著每路攝像頭的處理周期是 40ms一年按 25fps 算就是每幀 40ms 內(nèi)必須處理完。用 FP16 引擎單幀 12.8ms 的耗時(shí)每路 GPU 占用約 32% 的計(jì)算時(shí)間一個(gè) T4 卡理論上可以支撐 3 路左右但這是并發(fā)而非純串行實(shí)際做多路視頻流時(shí)通常利用 CUDA 流來(lái)實(shí)現(xiàn)并發(fā)把 batch 合并到多個(gè)流中T4 上我實(shí)測(cè)可以穩(wěn)定支持 12 到 16 路 1080p25 檢測(cè)具體取決于預(yù)處理和后處理的資源占用。這個(gè)數(shù)據(jù)可以作為你規(guī)劃設(shè)計(jì)時(shí)的參考基線(xiàn)。5.4 顯存管理TensorRT 引擎加載后的一級(jí)緩存與運(yùn)行時(shí)分配TensorRT 引擎加載后有顯存占用、推理時(shí)還有臨時(shí)工作區(qū)顯存workspace這兩者是兩回事。不少人在部署時(shí)看到顯存占用突然漲到幾個(gè) GB以為是內(nèi)存泄漏其實(shí)是 workspace 設(shè)計(jì)的。前面構(gòu)建代碼里的config.max_workspace_size 1 30就是給推理工作區(qū)設(shè)置上限的——這個(gè)值設(shè)多大取決于 GPU 顯存余量建議顯存緊張時(shí)調(diào)小到 256MB 甚至 128MB性能損失通常不大但能騰出空間給多路并發(fā)。我在項(xiàng)目里遇到過(guò) GPU 顯存被其他進(jìn)程占滿(mǎn)導(dǎo)致 TensorRT 構(gòu)建失敗的情況。排查思路很簡(jiǎn)單先nvidia-smi看顯存占用如果看到殘留的 python 進(jìn)程占了大量顯存用kill -9清理。多環(huán)境共用顯卡時(shí)建議設(shè)置CUDA_VISIBLE_DEVICES環(huán)境變量把進(jìn)程隔離到指定卡上避免互相干擾。6. 踩坑實(shí)錄錯(cuò)誤 43、精度漂移和那些午夜驚魂最后必須聊踩坑。TensorRT 項(xiàng)目里沒(méi)有踩過(guò)坑的人是幸運(yùn)的踩過(guò)坑但沒(méi)解決的人已經(jīng)轉(zhuǎn)行了。我把遇到過(guò)的幾類(lèi)典型問(wèn)題整理出來(lái)按排查鏈路講這樣你遇到相似問(wèn)題時(shí)能順著思路找而不是盲猜。6.1 轉(zhuǎn)換時(shí)報(bào) Cannot find TensorRT library 或 libnvinfer.so 缺失這個(gè)問(wèn)題的根因很直接TensorFlow 運(yùn)行時(shí)找不到 TensorRT 的動(dòng)態(tài)庫(kù)。雖然你裝了 TensorRT但庫(kù)路徑?jīng)]加進(jìn)LD_LIBRARY_PATH。要注意 pip 安裝的 TensorFlow 默認(rèn)不綁定 TensorRT你需要確保libnvinfer.so和libnvinfer_plugin.so在動(dòng)態(tài)鏈接器的搜索路徑里。# 出問(wèn)題先用這條命令確認(rèn)庫(kù)是否存在 find / -name libnvinfer.so* 2/dev/null # 如果存在把路徑導(dǎo)出來(lái) export LD_LIBRARY_PATH/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH # 如果不存在說(shuō)明 TensorRT 根本沒(méi)裝成功 sudo apt-get install tensorrt python3-libnvinfer另一種隱蔽情況是機(jī)器里同時(shí)存在多個(gè) TensorRT 版本比如顯卡驅(qū)動(dòng)自帶的組件和 deb 包裝的有沖突庫(kù)倒是找到了但版本不對(duì)運(yùn)行時(shí)報(bào) symbol not found。這時(shí)候用ldd檢查 Python 擴(kuò)展實(shí)際鏈接的庫(kù)路徑逐一排除冗余版本。6.2 GPU 錯(cuò)誤 43 與 TensorRT 運(yùn)行時(shí)崩潰的排查鏈路Windows 下錯(cuò)誤 43 前面提過(guò)Linux 下的表現(xiàn)往往不是報(bào) 43而是 TensorRT 引擎構(gòu)建到一半崩潰或者運(yùn)行時(shí) CUDA error。我遇到過(guò)一次特別詭異的情況同樣的代碼在 A 機(jī)器構(gòu)建引擎成功在 B 機(jī)器卻反復(fù)崩潰報(bào)錯(cuò)還指向 cuDNN。排查鏈路是這樣的第一步檢查兩臺(tái)機(jī)器的 GPU 是否同一架構(gòu)。我用nvidia-smi -q | grep Architecture看了一下發(fā)現(xiàn) B 機(jī)器是較老的 Pascal 架構(gòu)而我在 A 機(jī)器上構(gòu)建 TensorRT 時(shí)用了針對(duì) Ampere 的優(yōu)化引擎拿到 Pascal 上直接不兼容。這個(gè)問(wèn)題的通用解法是在目標(biāo)部署機(jī)上重新構(gòu)建引擎或者構(gòu)建時(shí)設(shè)置builder_platform相關(guān)選項(xiàng)讓引擎盡可能通用犧牲一點(diǎn)性能。第二步檢查驅(qū)動(dòng)版本。有些老的驅(qū)動(dòng)和 CUDA 12.x 不兼容導(dǎo)致運(yùn)行時(shí)找不到入口符號(hào)。把驅(qū)動(dòng)升級(jí)到支持你所用 CUDA 版本的最低穩(wěn)定版同時(shí)別忘記重啟機(jī)器驅(qū)動(dòng)加載是否完整必須以重啟后的nvidia-smi輸出為準(zhǔn)。第三步如果上述兩步都沒(méi)問(wèn)題可以考慮顯存故障。跑一遍bandwidthTest或者deviceQueryCUDA 自帶的示例程序如果設(shè)備查詢(xún)本身出錯(cuò)基本可以斷定硬件有問(wèn)題TensorRT 什么的先放一邊。6.3 精度漂移FP16 下某些模型輸出變成 NaN 或錯(cuò)檢大多數(shù)模型 FP16 沒(méi)問(wèn)題但如果你碰上對(duì)精度極端敏感的模型尤其是層數(shù)極深、激活值動(dòng)態(tài)范圍很大的網(wǎng)絡(luò)FP16 可能導(dǎo)致梯度或推理輸出異常。在你依賴(lài) TF-TRT 自動(dòng)精度分配時(shí)它通常能規(guī)避大部分問(wèn)題但無(wú)法保證 100%。排查思路是先做精度對(duì)比用 TensorFlow 原生 FP32 推理結(jié)果作為基準(zhǔn)逐層或整體比較 TensorRT 輸出的數(shù)值差異。如果你用的是 Python API可以在轉(zhuǎn)換時(shí)打開(kāi)層級(jí)精度診斷如果用的是 TF-TRT可以設(shè)置precision_modeFP16的同時(shí)給特定層通過(guò)set_layer_node_precision手動(dòng)降回 FP32。我遇到過(guò)一個(gè)更隱蔽的情況模型的輸入歸一化方式不對(duì)。TensorFlow 訓(xùn)練時(shí)預(yù)處理是將像素值除以 255但我在 TensorRT 側(cè)直接喂原始 0~255 的 uint8 數(shù)據(jù)導(dǎo)致數(shù)值范圍差了 255 倍FP16 下這種大動(dòng)態(tài)范圍直接觸發(fā)精度問(wèn)題。排查后把預(yù)處理修正到和訓(xùn)練一致問(wèn)題立刻消失。所以記住先檢查預(yù)處理鏈路再懷疑 TensorRT 精度策略。6.4 一次奇怪的 5% 性能回退竟是因?yàn)?CPU 預(yù)處理成了瓶頸某次我優(yōu)化完 GPU 推理延遲降到 12ms但整個(gè)服務(wù)端到端延遲還是 60ms怎么都降不下去。一開(kāi)始懷疑 TensorRT 沒(méi)生效后來(lái)用nvprof或nsight compute一看GPU 空閑時(shí)間占了 80%瓶頸根本不在這里。真正的問(wèn)題是我的圖像解碼、resize、歸一化全在 CPU 上串行跑成了新瓶頸。解決思路是做預(yù)處理流水線(xiàn)并行用 OpenCV 的imread GPU 側(cè)的tf.image或者 CUDA 工具把 resize 和 normalize 移到 GPU 上或至少用多線(xiàn)程預(yù)取下一幀和當(dāng)前幀的推理重疊。優(yōu)化之后端到端延遲從 60ms 降到 24msGPU 空閑時(shí)間也大幅減少。這個(gè)經(jīng)驗(yàn)非常重要模型推理提速之后原來(lái)的次要瓶頸會(huì)變成主要瓶頸你必須重新審視整條鏈路。7. 從 TF-TRT 到多路并發(fā)部署一個(gè)可供參考的生產(chǎn)架構(gòu)聊完單模型加速最后落到實(shí)際部署層面。熱詞里很多人搜gpu租用、gpu計(jì)算資源分配說(shuō)明大家已經(jīng)意識(shí)到模型優(yōu)化完只是第一步怎么榨干 GPU 才是最終目的。這里給出我生產(chǎn)環(huán)境中用的一套相對(duì)成熟的思路供你參考。7.1 用 CUDA Stream 實(shí)現(xiàn)多路視頻并發(fā)推理多路視頻場(chǎng)景最大的特點(diǎn)是每一路都需要獨(dú)立處理但 GPU 計(jì)算可以共享。如果一路一路串行推理GPU 利用率很低T4 上 16 路 1080p25 檢測(cè)基本跑不贏。我的做法是引入 CUDA Stream 機(jī)制將多個(gè) batch 的推理放到不同的 stream 上執(zhí)行讓它們并行提交給 GPU由 GPU 調(diào)度器按需分配計(jì)算資源。TensorRT 的引擎執(zhí)行本身是異步的配合 stream 就能實(shí)現(xiàn)第一路在算前處理時(shí)第二路同時(shí)在進(jìn)行卷積計(jì)算的流水線(xiàn)效果。一個(gè)注意點(diǎn)多路并發(fā)不是簡(jiǎn)單地把 batch 翻倍。每個(gè) stream 里的推理仍然保持較小的 batch比如 2~4這樣既能讓 GPU 吃飽又不會(huì)因?yàn)閱?batch 過(guò)大導(dǎo)致某一路的延遲抖動(dòng)加劇。實(shí)測(cè) T4 上 YOLO 640 輸入、FP16 引擎4 個(gè) stream 每 stream batch 2整體吞吐比單流 batch 8 還要高約 15%原因就在于流之間可以提高整體的 kernel 重疊率。7.2 預(yù)熱、多進(jìn)程和顯存隔離的經(jīng)驗(yàn)值生產(chǎn)服務(wù)啟動(dòng)后第一次推理特別慢這個(gè)是 TensorRT 引擎加載、cuDNN 初始化、CUDA context 創(chuàng)建疊加的結(jié)果。我的經(jīng)驗(yàn)是在服務(wù)真正接受流量前, 先跑一次熱身推理加載引擎后立刻用一個(gè) dummy 輸入跑幾幀讓 CUDA context 初始化完畢。這個(gè)熱身過(guò)程大約需要 500ms 到 2 秒不等但對(duì)線(xiàn)上延遲穩(wěn)定性非常重要。多進(jìn)程部署時(shí)要注意每個(gè)進(jìn)程都會(huì)創(chuàng)建獨(dú)立的 CUDA context 和 TensorRT engine 實(shí)例顯存占用是疊加的。所以我通常不用進(jìn)程數(shù)去硬頂 CPU 核數(shù)而是根據(jù)顯存余量反推假設(shè)每進(jìn)程占用 1.3GB一張 16GB 的 T4 卡單卡最多跑 10 個(gè)進(jìn)程左右再多就要 OOM。更可控的方式是單進(jìn)程多線(xiàn)程配合前面說(shuō)的 CUDA Stream讓一個(gè)進(jìn)程管理多路流減少顯存浪費(fèi)。7.3 引擎文件的保存與跨機(jī)復(fù)用架構(gòu)匹配就可用但別貪TensorRT 引擎文件.engine 或 .plan可以序列化保存但前面說(shuō)了它綁定 GPU 架構(gòu)和 TensorRT 版本。同一個(gè)集群里如果硬件完全一致那引擎文件直接拷過(guò)去加載即可如果硬件不一致必須在目標(biāo)機(jī)上重新構(gòu)建。為了平衡靈活性和加載速度我采用了一種混合策略保存 ONNX 中間文件在每臺(tái)部署機(jī)上首次啟動(dòng)時(shí)自動(dòng)構(gòu)建引擎并緩存到本地磁盤(pán)以后直接加載緩存。這樣既不需要提前知道每臺(tái)機(jī)器的架構(gòu)也不會(huì)每次啟動(dòng)都重新構(gòu)建。自動(dòng)構(gòu)建的邏輯可以做得簡(jiǎn)單一點(diǎn)import os engine_cache ./engine_cache os.makedirs(engine_cache, exist_okTrue) def load_or_build_engine(onnx_path, precisionFP16): import hashlib key hashlib.md5((onnx_path precision trt.__version__).encode()).hexdigest()[:16] cache_path os.path.join(engine_cache, f{key}.engine) if os.path.exists(cache_path): with open(cache_path, rb) as f: return f.read() # 構(gòu)建邏輯省略... engine build_engine(onnx_path, precision) with open(cache_path, wb) as f: f.write(engine) return engine這個(gè)方案的另一個(gè)好處是模型更新后ONNX 文件變了hash 自然不同會(huì)自動(dòng)觸發(fā)重新構(gòu)建不需要手動(dòng)清理緩存。7.4 從單卡到多卡gpu計(jì)算資源分配的一個(gè)簡(jiǎn)單框架當(dāng)你單卡優(yōu)化完成接下來(lái)就是橫向擴(kuò)展的問(wèn)題。多卡環(huán)境下最簡(jiǎn)單的任務(wù)分配方式是按路數(shù)切分比如 32 路視頻4 張 T4 卡每張卡分 8 路。路數(shù)和卡的映射可以先用固定公式做card_index stream_index % num_cards簡(jiǎn)單但有效。如果想更精細(xì)可以引入一個(gè)簡(jiǎn)單的調(diào)度器實(shí)時(shí)記錄每張卡的顯存占用和推理延遲把新請(qǐng)求分配到負(fù)載最低的卡上。在云上租用 GPU 時(shí)我習(xí)慣先把單卡能力測(cè)準(zhǔn)能撐幾路、延遲多少然后倒推需要租幾卡。比如 100 路 1080p25 檢測(cè)單卡穩(wěn) 16 路那至少需要 7 卡考慮冗余和峰值余量我建議租 8 卡。別按單卡能跑 20 路這種理論值去算實(shí)測(cè)數(shù)據(jù)永遠(yuǎn)比理論值靠譜。最后再分享一個(gè)實(shí)用的運(yùn)維技巧GPU 推理服務(wù)上線(xiàn)后持續(xù)監(jiān)控顯存占用和卡上實(shí)際利用率的差異。你會(huì)發(fā)現(xiàn)當(dāng)多路視頻并發(fā)不高時(shí)顯存占用率很低但利用率卻可能從 30% 跳到 90%這說(shuō)明 TensorRT 已經(jīng)把計(jì)算的吞吐拉滿(mǎn)了。如果利用率一直壓在 30% 以下多半是 CPU 預(yù)處理、IO 或者調(diào)度邏輯卡了脖子別急著再優(yōu)化模型先往上下游找找。這條經(jīng)驗(yàn)我用了很多年幾乎每次都能定位到真正的瓶頸。