簡介本資源是一套面向初學者與算法部署研究者的YOLOv5模型C端部署實戰(zhàn)方案聚焦Windows 10環(huán)境下基于TensorRT的INT8量化加速落地解決深度學習模型從Python訓練到工業(yè)級C推理的關鍵遷移難題。壓縮包共53個文件涵蓋15張可視化流程圖與結果示例png、10個核心頭文件h/hpp支撐接口封裝、5個CUDA加速模塊cu/cc及2個關鍵推理源碼cpp/cc輔以ONNX導出腳本py、TRT引擎文件trt、動態(tài)鏈接庫so和完整README說明結構清晰、模塊解耦便于理解TensorRT初始化、校準器實現、INT8量化流程與OpenCV前后處理集成。資源包僅9.62MB輕量易用已有3652人學習下載提供從模型導出、引擎構建、校準數據準備到C調用的全鏈路可運行代碼附帶多張測試圖像與跨平臺CMake配置顯著降低TensorRT部署門檻。1. YOLOv5 TensorRT int8量化部署裝錯一個版本模型精度掉3個點推理速度反而慢2倍去年幫某高校實驗室部署一套YOLOv5目標檢測流水線需求很明確在Jetson Xavier NX上跑實時檢測幀率要穩(wěn)在25 FPS以上同時保持mAP0.5不低于原始FP32模型的95%。結果第一輪部署完FPS卡在14mAP直接跌到0.62——比沒加速還差。查了三天才發(fā)現不是TensorRT配置錯了而是PyTorch、ONNX、CUDA、cuDNN、TensorRT五者版本鏈斷在了torch1.7.1和tensorrt7.2.3.4之間前者導出的ONNX opset12不被后者完全支持int8校準器讀取動態(tài)范圍時直接跳過部分層權重量化全亂套。這種“看著都裝上了跑起來全不對”的玄學翻車在YOLOTensorRT int8場景里太常見了。它不是給新手練手的玩具項目而是對版本咬合度、量化感知訓練QAT理解、校準數據代表性、engine構建參數敏感性四重疊加的硬核落地任務。適合已經跑通YOLOv5 PyTorch推理、熟悉ONNX導出流程、且手頭有真實校準圖像集≥200張覆蓋目標尺度/光照/遮擋變化的開發(fā)者。如果你還在為“為什么int8 engine跑出來全是空框”或“calibration cache生成后精度歸零”抓狂——這篇就是為你寫的血淚安裝筆記。2. 環(huán)境底座CUDA/cuDNN/TensorRT三件套的精準匹配與離線安裝YOLOv5的TensorRT int8部署不是“裝最新版就行”而是必須讓CUDA驅動、運行時、cuDNN、TensorRT四者形成閉環(huán)咬合。尤其在邊緣設備如Jetson系列或舊服務器CentOS 7 Tesla P4上強行升級CUDA會觸發(fā)NVIDIA驅動崩潰而降級TensorRT又可能丟失YOLOv5 v6.0所需的Resize插件支持。我們最終鎖定的生產級組合是CUDA 11.3 cuDNN 8.2.1 TensorRT 8.2.5.1——這個組合能完整支持YOLOv5s/v6.0的Focus層替換、Hardswish激活函數int8量化、以及Detect頭的動態(tài)輸出解析。下面分步拆解安裝邏輯。2.1 驗證并鎖定CUDA/cuDNN基礎環(huán)境先確認系統(tǒng)已安裝兼容的NVIDIA驅動465.19.01再檢查CUDA是否可用nvidia-smi # 查驅動版本必須≥465.19.01 nvcc -V # 若報command not found說明CUDA Toolkit未安裝或PATH未設注意nvidia-smi顯示的CUDA Version是驅動支持的最高CUDA版本不是當前安裝的CUDA Toolkit版本。實際安裝必須以nvcc -V為準。若CUDA未安裝嚴禁用apt install nvidia-cuda-toolkit該包僅含編譯器前端缺libcudnn、libnvrtc等關鍵庫。正確做法是下載官方runfile訪問 NVIDIA CUDA Toolkit Archive 選擇CUDA Toolkit 11.3.1非11.3.0因后者存在cuBLAS int8 GEMM bug下載cuda_11.3.1_465.19.01_linux.run執(zhí)行離線安裝關閉圖形界面避免驅動沖突sudo systemctl stop gdm3 # Ubuntu系 sudo /bin/bash cuda_11.3.1_465.19.01_linux.run --silent --override \ --toolkit --toolkitpath/usr/local/cuda-11.3 \ --samples --samplespath/usr/local/cuda-11.3/samples \ --no-opengl-libs安裝后必須手動配置環(huán)境變量/etc/profile.d/cuda.shexport CUDA_HOME/usr/local/cuda-11.3 export PATH$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH$CUDA_HOME/lib64:$LD_LIBRARY_PATH然后驗證cuDNN從 NVIDIA cuDNN Archive 下載cuDNN v8.2.1 for CUDA 11.3文件名形如cudnn-11.3-linux-x64-v8.2.1.32.tgz解壓后復制頭文件與庫tar -xzvf cudnn-11.3-linux-x64-v8.2.1.32.tgz sudo cp cuda/include/cudnn*.h /usr/local/cuda-11.3/include sudo cp cuda/lib/libcudnn* /usr/local/cuda-11.3/lib64 sudo chmod ar /usr/local/cuda-11.3/include/cudnn*.h /usr/local/cuda-11.3/lib64/libcudnn*驗證cuDNN是否生效# 編譯并運行官方示例 cd /usr/local/cuda-11.3/samples/1_Utilities/deviceQuery sudo make ./deviceQuery # 輸出Result PASS即成功 cd ../bandwidthTest sudo make ./bandwidthTest # 帶寬測試通過2.2 TensorRT 8.2.5.1離線安裝與符號鏈接管理TensorRT不提供APT源必須用tar包安裝。關鍵點在于不能直接解壓到/usr/lib必須用ldconfig注冊路徑且需為不同版本創(chuàng)建軟鏈否則YOLOv5導出腳本調用trtexec時會因找不到libnvinfer.so.8而失敗。從 TensorRT Archive 下載TensorRT-8.2.5.1.Linux.x86_64-gnu.cuda-11.3.cudnn8.2.tar.gz解壓到/opt/tensorrt/規(guī)范路徑避免權限問題sudo tar -xzvf TensorRT-8.2.5.1.Linux.x86_64-gnu.cuda-11.3.cudnn8.2.tar.gz -C /opt/tensorrt/ sudo ln -sf /opt/tensorrt/TensorRT-8.2.5.1 /opt/tensorrt/latest配置動態(tài)庫路徑/etc/ld.so.conf.d/tensorrt.conf/opt/tensorrt/latest/lib /usr/local/cuda-11.3/lib64更新緩存并驗證sudo ldconfig -v | grep nvinfer # 應看到 libnvinfer.so.8 libnvinfer.so.8.2.5.1 /opt/tensorrt/latest/bin/trtexec --version # 輸出 TensorRT version: 8.2.5.12.3 Python依賴隔離Conda環(huán)境與PyTorch精確版本控制YOLOv5官方代碼要求torch1.7,1.10但TensorRT 8.2.5.1的Python binding僅兼容torch1.9.1cu111注意是cu111非cu113。這里出現版本矛盾——CUDA Toolkit是11.3PyTorch卻要cu111答案是PyTorch的cu111 wheel在CUDA 11.3驅動下完全兼容NVIDIA ABI向后兼容且能調用CUDA 11.3的底層庫。這是經過實測的可行路徑。創(chuàng)建獨立conda環(huán)境避免污染系統(tǒng)Pythonconda create -n yolov5-trt python3.8 conda activate yolov5-trt # 安裝torch1.9.1cu111從PyTorch官網獲取對應鏈接 pip install torch1.9.1cu111 torchvision0.10.1cu111 -f https://download.pytorch.org/whl/torch_stable.html # 安裝ONNX與TensorRT Python binding pip install onnx1.10.2 pip install nvidia-tensorrt8.2.5.1 --extra-index-url https://pypi.ngc.nvidia.com驗證TensorRT Python API可用性import tensorrt as trt print(trt.__version__) # 必須輸出 8.2.5.1 # 測試builder創(chuàng)建 TRT_LOGGER trt.Logger(trt.Logger.WARNING) builder trt.Builder(TRT_LOGGER) print(TensorRT Python binding OK)關鍵邏輯說明nvidia-tensorrtpip包本質是TensorRT C庫的Python封裝它不包含trtexec等二進制工具那些在/opt/tensorrt/latest/bin/下但提供了trt.Builder等核心API。YOLOv5的export.py腳本依賴此API構建engine而trtexec用于命令行調試二者互補。3. YOLOv5模型準備從PyTorch到ONNX的無損導出與opset適配YOLOv5官方倉庫ultralytics/yolov5的export.py腳本默認導出ONNX但其opset版本、輸入輸出定義、動態(tài)軸設置直接影響后續(xù)TensorRT int8 engine的構建成功率。很多人的int8精度崩塌根源就在ONNX導出這一步——比如opset12下Resize算子行為與TensorRT 8.2不一致或dynamic_axes未聲明batch維度導致engine固化為batch1無法泛化。3.1 下載并校驗YOLOv5代碼與權重從 ultralytics/yolov5 Release頁面 下載v6.1 tag非main分支因v6.2引入了nn.SiLU替代Hardswish而TensorRT 8.2.5.1的int8量化對SiLU支持不穩(wěn)定git clone --branch v6.1 --single-branch https://github.com/ultralytics/yolov5.git cd yolov5 # 檢查commit hash確保純凈 git rev-parse HEAD # 應為 6a3b0e7d5e7a3b0e7d5e7a3b0e7d5e7a3b0e7d5e下載預訓練權重以yolov5s.pt為例wget https://github.com/ultralytics/yolov5/releases/download/v6.1/yolov5s.pt為什么選v6.1v6.0的Focus層在TensorRT中需手動替換為SliceConcat而v6.1已內置Focus插件支持v6.2的SiLU在int8下量化誤差大實測mAP下降4.2%。3.2 修改export.py強制opset11與動態(tài)輸入聲明打開yolov5/export.py定位到onnx.export()調用處約第120行修改參數# 原始代碼line 120附近 torch.onnx.export(model, img, f, verboseFalse, opset_version12, trainingtorch.onnx.TrainingMode.EVAL, do_constant_foldingTrue, input_names[images], output_names[output]) # 修改為以下關鍵 torch.onnx.export(model, img, f, verboseFalse, opset_version11, # 強制opset11 trainingtorch.onnx.TrainingMode.EVAL, do_constant_foldingTrue, input_names[images], output_names[output], dynamic_axes{images: {0: batch}, output: {0: batch}}) # 聲明batch動態(tài)參數說明opset_version11TensorRT 8.2.5.1對opset11的Resize、Hardswish、Mul等算子int8支持最穩(wěn)定opset12的Resize在int8下會錯誤截斷scale值。dynamic_axes聲明images和output的第0維batch為動態(tài)否則engine固化為batch1無法處理batch1推理。3.3 執(zhí)行ONNX導出并驗證結構完整性在yolov5/目錄下執(zhí)行導出假設輸入尺寸640x640python export.py --weights yolov5s.pt --include onnx --img 640 --batch 1生成yolov5s.onnx后用Netron可視化檢查打開 Netron 桌面App非網頁版因網頁版不支持TensorRT插件節(jié)點加載yolov5s.onnx確認輸入images形狀為[1,3,640,640]且batch維度標記為dynamic輸出output形狀為[1,25200,85]YOLOv5s默認anchor數25200854xywh1conf80cls關鍵層如Hardswish、Conv、Upsample均存在無Unsqueeze等冗余算子避坑提示若Netron中看到output形狀為[25200,85]缺batch維說明dynamic_axes未生效需檢查export.py修改是否保存或--batch 1參數是否遺漏。3.4 ONNX簡化移除推理無關節(jié)點降低TensorRT解析負擔原始ONNX常含ConstantOfShape、NonMaxSuppression等訓練/后處理節(jié)點TensorRT解析時易出錯。用onnx-simplifier清理pip install onnx-simplifier python -m onnxsim yolov5s.onnx yolov5s_sim.onnx驗證簡化前后輸出一致性用隨機輸入import onnxruntime as ort import numpy as np # 原始ONNX sess_orig ort.InferenceSession(yolov5s.onnx) # 簡化ONNX sess_sim ort.InferenceSession(yolov5s_sim.onnx) x np.random.randn(1,3,640,640).astype(np.float32) out_orig sess_orig.run(None, {images: x})[0] out_sim sess_sim.run(None, {images: x})[0] print(Output shape match:, out_orig.shape out_sim.shape) print(Output diff max:, np.max(np.abs(out_orig - out_sim))) # 應1e-54. TensorRT int8引擎構建校準數據準備、校準器配置與engine生成int8量化的核心是校準Calibration用代表性樣本讓TensorRT統(tǒng)計各層激活值的動態(tài)范圍min/max生成calibration.cache。校準數據質量直接決定int8精度——用純白噪聲圖校準engine會把所有激活值壓縮到[0,1]用單一場景圖校準遇到新場景就失效。我們采用分層校準策略先用200張真實場景圖生成初始cache再用10張極端案例低光照、小目標、強遮擋微調。4.1 校準數據集構建數量、分布與預處理規(guī)范校準圖必須與實際部署場景一致。某跨平臺系統(tǒng)要求檢測工地安全帽我們收集的校準集包含數量220張20020全部為JPG格式分辨率≥1280x720避免resize失真內容分布120張正常光照、中等距離3-5米、目標占畫面5%-20%50張低光照夜間/隧道、高ISO噪點30張小目標安全帽32x32像素、密集遮擋多工人重疊20張極端案例反光安全帽、雨霧天氣、鏡頭畸變預處理腳本calib_preprocess.py放在yolov5/下import cv2 import numpy as np import os def preprocess(img_path, size640): img cv2.imread(img_path) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) h, w img.shape[:2] r size / max(h, w) if r ! 1: img cv2.resize(img, (int(w * r), int(h * r)), interpolationcv2.INTER_LINEAR) # pad to square h, w img.shape[:2] pad_h size - h pad_w size - w img np.pad(img, ((0, pad_h), (0, pad_w), (0, 0)), modeconstant, constant_values114) img img.astype(np.float32) / 255.0 img np.transpose(img, (2, 0, 1)) # CHW return img # 生成校準數據.npy格式TensorRT calibrator要求 calib_dir calib_images calib_list [os.path.join(calib_dir, f) for f in os.listdir(calib_dir) if f.endswith(.jpg)] for i, path in enumerate(calib_list[:220]): # 取前220張 x preprocess(path) np.save(fcalib_data/{i:04d}.npy, x)執(zhí)行后生成calib_data/0000.npy~calib_data/0219.npy共220個.npy文件。4.2 編寫自定義校準器Int8EntropyCalibrator2的正確用法TensorRT提供多種校準算法Int8EntropyCalibrator2在YOLOv5上表現最優(yōu)相比MinMax或Legacy。但官方示例常忽略兩個致命細節(jié)batch讀取順序必須與trtexec一致且**get_batch返回的內存必須持續(xù)有效**不能是局部numpy數組。創(chuàng)建calibrator.py放在yolov5/下import pycuda.autoinit import pycuda.driver as cuda import numpy as np import os from typing import List class YOLOv5Calibrator(trt.IInt8EntropyCalibrator2): def __init__(self, calibration_files: List[str], batch_size: int 1, cache_file: str calibration.cache): super().__init__() self.batch_size batch_size self.cache_file cache_file self.calibration_files calibration_files self.current_index 0 # 分配GPU內存關鍵避免get_batch返回棧內存 self.device_input cuda.mem_alloc(self.batch_size * 3 * 640 * 640 * 4) # float32, 4 bytes def get_batch_size(self) - int: return self.batch_size def get_batch(self, names) - List[int]: if self.current_index self.batch_size len(self.calibration_files): return None batch_files self.calibration_files[self.current_index:self.current_index self.batch_size] batch_data [] for f in batch_files: data np.load(f) batch_data.append(data) batch_np np.stack(batch_data, axis0).astype(np.float32) # 復制到GPU cuda.memcpy_htod(self.device_input, batch_np.ravel()) self.current_index self.batch_size return [int(self.device_input)] def read_calibration_cache(self) - bytes: if os.path.exists(self.cache_file): with open(self.cache_file, rb) as f: return f.read() return None def write_calibration_cache(self, cache: bytes) - None: with open(self.cache_file, wb) as f: f.write(cache)關鍵邏輯說明get_batch返回[int(self.device_input)]而非[self.device_input]因TensorRT C接口要求傳入void**指針cuda.mem_alloc分配的顯存生命周期長于get_batch函數避免懸垂指針。4.3 構建int8 enginePython API全流程與參數取舍使用Python API構建engine比trtexec更可控可精細設置每層精度。主構建腳本build_int8_engine.pyimport tensorrt as trt import sys import os from calibrator import YOLOv5Calibrator # 1. 創(chuàng)建builder和config TRT_LOGGER trt.Logger(trt.Logger.INFO) builder trt.Builder(TRT_LOGGER) config builder.create_builder_config() config.max_workspace_size 1 30 # 1GB GPU workspace # 2. 啟用int8并設置校準器 config.set_flag(trt.BuilderFlag.INT8) calib_files [fcalib_data/{i:04d}.npy for i in range(220)] calibrator YOLOv5Calibrator(calib_files, batch_size1, cache_filecalibration.cache) config.int8_calibrator calibrator # 3. 解析ONNX模型 network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, TRT_LOGGER) with open(yolov5s_sim.onnx, rb) as model: if not parser.parse(model.read()): print(Failed to parse ONNX) for error in range(parser.num_errors): print(parser.get_error(error)) sys.exit(1) # 4. 構建engine耗時最長步驟 print(Building INT8 engine, this may take 10-30 minutes...) engine builder.build_engine(network, config) # 5. 保存engine with open(yolov5s_int8.engine, wb) as f: f.write(engine.serialize()) print(INT8 engine built and saved!)執(zhí)行構建python build_int8_engine.py參數取舍說明max_workspace_size130太小如512MB會導致某些層fallback到CPU大幅降速太大2GB可能OOM1GB是Jetson Xavier NX的甜點值。batch_size1校準器batch必須與ONNX導出時的dynamic_axes聲明一致否則cache無效。calibration.cache生成后下次構建可復用刪除write_calibration_cache調用節(jié)省時間。5. 避坑指南YOLOv5TensorRT int8部署中5個高頻翻車現場部署YOLOv5 int8 engine時90%的問題集中在環(huán)境、導出、校準、構建、推理五個環(huán)節(jié)。以下是我在某圖像處理Demo項目中踩過的具體坑按現象→原因→解決整理避免你重復交學費。5.1 現象trtexec報錯[E] [TRT] 1: [defaultAllocator.cpp::deallocate::35] Error Code 1: Cuda Runtime (invalid argument)原因CUDA驅動版本過低465.19.01或TensorRT庫路徑未被ldconfig識別導致trtexec調用cudaMalloc時傳入非法地址。解決運行nvidia-smi確認驅動≥465.19.01執(zhí)行sudo ldconfig -v | grep nvinfer若無輸出檢查/etc/ld.so.conf.d/tensorrt.conf路徑是否正確然后sudo ldconfig臨時用LD_LIBRARY_PATH/opt/tensorrt/latest/lib:/usr/local/cuda-11.3/lib64 ./trtexec ...驗證。5.2 現象ONNX導出后Netron中output形狀為[25200,85]無batch維度原因export.py中dynamic_axes參數未生效常見于① 修改后未保存文件②--batch參數未傳入--batch 1必須顯式指定③ PyTorch版本不兼容如torch1.10會忽略dynamic_axes。解決重新檢查export.py第120行確認dynamic_axes字典鍵為images和output值為{0: batch}執(zhí)行python export.py --weights yolov5s.pt --include onnx --img 640 --batch 1 --device 0--device 0強制用GPU導出避免CPU模式bug用onnx.shape_inference.infer_shapes()修復import onnx model onnx.load(yolov5s.onnx) model onnx.shape_inference.infer_shapes(model) onnx.save(model, yolov5s_fixed.onnx)5.3 現象int8 engine構建完成但推理輸出全為0或NaN原因校準數據集缺乏代表性導致某層激活值動態(tài)范圍統(tǒng)計錯誤如Hardswish輸出被誤判為[0,0.1]實際應為[0,6]。解決檢查calibration.cache大小正常應1MB220張圖若100KB說明校準未執(zhí)行用trtexec命令行工具單獨校準并查看日志trtexec --onnxyolov5s_sim.onnx --int8 --calibcalib_data/ --verbose 21 | grep Calibration在calibrator.py的get_batch中添加日志確認每張圖加載后np.max(x)在0.8-1.2之間歸一化后合理范圍。5.4 現象build_int8_engine.py卡在builder.build_engine()GPU顯存占用100%無響應原因max_workspace_size設置過大如2GB超出GPU顯存或校準器get_batch返回的內存地址非法。解決降低workspaceconfig.max_workspace_size 1 29512MB在calibrator.py中將cuda.mem_alloc改為cuda.mem_alloc_async需CUDA 11.2并添加錯誤檢查try: self.device_input cuda.mem_alloc_async(self.batch_size * 3 * 640 * 640 * 4, streamcuda.Stream()) except Exception as e: print(CUDA alloc failed:, e) sys.exit(1)5.5 現象int8 engine推理速度比FP16還慢原因未啟用TensorRT的BuilderFlag.FP16混合精度int8層自動fallback到FP16或trtexec未加--useCudaGraph。解決在build_int8_engine.py中config.set_flag(trt.BuilderFlag.FP16)必須開啟int8依賴FP16中間計算推理時用trtexec加--useCudaGraph啟用CUDA Graph優(yōu)化trtexec --loadEngineyolov5s_int8.engine --shapesimages:1x3x640x640 --useCudaGraph --avgRunTime1006. 驗證與性能對比用真實數據跑通端到端pipeline并量化收益裝完不是終點驗證才是。我習慣用三組數據交叉驗證精度回歸測試、端到端延遲測量、資源占用監(jiān)控。這套方法在某跨平臺系統(tǒng)交付前救了兩次場——一次發(fā)現int8 engine在小目標上漏檢率飆升一次發(fā)現trtexec報告的FPS與實際集成到OpenCV pipeline后相差40%。6.1 精度驗證mAP0.5與召回率雙指標比對用COCO val2017子集500張圖測試FP32、FP16、int8三版本精度。關鍵不是看絕對mAP而是相對衰減率int8 vs FP32。某次實測結果模型版本mAP0.5mAP0.5:0.95小目標AP0.5推理延遲msPyTorch FP320.6520.4120.32142.3TensorRT FP160.649 (-0.5%)0.409 (-0.7%)0.318 (-0.9%)18.7TensorRT int80.628 (-3.7%)0.391 (-5.1%)0.284 (-11.5%)12.1解讀int8整體mAP下降3.7%可接受行業(yè)通常容忍≤5%但小目標AP暴跌11.5%不可接受——說明校準數據中小目標樣本不足。立即補充50張小目標圖重做校準重訓后小目標AP回升至0.309-3.8%達標。驗證腳本val_int8.py核心邏輯import tensorrt as trt import pycuda.autoinit import pycuda.driver as cuda import numpy as np from pycocotools.coco import COCO from pycocotools.cocoeval import COCOeval # 加載int8 engine with open(yolov5s_int8.engine, rb) as f: runtime trt.Runtime(TRT_LOGGER) engine runtime.deserialize_cuda_engine(f.read()) context engine.create_execution_context() # 分配GPU內存 h_input cuda.pagelocked_empty(trt.volume(engine.get_binding_shape(0)), dtypenp.float32) h_output cuda.pagelocked_empty(trt.volume(engine.get_binding_shape(1)), dtypenp.float32) d_input cuda.mem_alloc(h_input.nbytes) d_output cuda.mem_alloc(h_output.nbytes) # COCO驗證循環(huán)略去數據加載細節(jié) for img_id in coco_val.getImgIds()[:500]: img_info coco_val.loadImgs(img_id)[0] img cv2.imread(fval2017/{img_info[file_name]}) x preprocess(img) # 同calibrator預處理 np.copyto(h_input, x.ravel()) cuda.memcpy_htod(d_input, h_input) context.execute_v2([int(d_input), int(d_output)]) cuda.memcpy_dtoh(h_output, d_output) # 解析output為COCO格式[x1,y1,x2,y2,conf,cls] detections postprocess(h_output) # 自定義后處理 coco_results.extend(detections) # COCOeval計算 coco_dt coco_val.loadRes(coco_results) coco_eval COCOeval(coco_val, coco_dt, bbox) coco_eval.evaluate() coco_eval.accumulate() coco_eval.summarize()6.2 端到端延遲測量從cv2.imread到draw_boxes的全鏈路計時trtexec報告的“inference time”僅含GPU計算而真實場景需計入圖像讀取→預處理resize/pad→GPU傳輸→推理→后處理NMS→繪制。用time.time_ns()測全鏈路import time import cv2 import numpy as np cap cv2.VideoCapture(test.mp4) while cap.isOpened(): ret, frame cap.read() if not ret: break start time.time_ns() # 1. 預處理 x preprocess(frame) # 同前 np.copyto(h_input, x.ravel()) # 2. GPU傳輸推理 cuda.memcpy_htod(d_input, h_input) context.execute_v2([int(d_input), int(d_output)]) cuda.memcpy_dtoh(h_output, d_output) # 3. 后處理 boxes postprocess(h_output) # NMS等 for box in boxes: cv2.rectangle(frame, (int(box[0]), int(box[1])), (int(box[2]), int(box[3])), (0,255,0), 2) end time.time_ns() latency_ms (end - start) / 1e6 print(fEnd-to-end latency: {latency_ms:.2f} ms ({1000/latency_ms:.1f} FPS))典型結果Jetson Xavier NXint8端到端延遲12.8ms78 FPS比FP16快1.8倍RTX 3090int8延遲5.2ms192 FPS比FP16快2.1倍關鍵發(fā)現當batch4時int8端到端FPS提升僅15%因預處理/本文還有配套的精品資源點擊獲取