Benchmark與TensorRT部署驗證)
簡介YOLOv5、YOLOv6與YOLOv7是當前目標檢測領域應用最廣的YOLO系列模型這份資料從工程實踐視角系統(tǒng)比較三者mAP精度、FPS推理速度及CPU/GPU適配表現(xiàn)適合算法工程師、計算機視覺初學者與模型選型決策者閱讀。內容圍繞CPU、RTX 4090、V100、P100等多類硬件環(huán)境展開實測覆蓋Nano、Tiny及大模型的多檔配置并回應了哪個模型CPU上最快、GPU上最快、小物體檢測如何選、訓練需多大顯存等高頻問題。文檔還重點分析了游戲GPU與AI GPU對FPS的影響以及Tiny/Nano模型在部分GPU上性能下降的原因為實際項目提供可落地的選型依據(jù)。壓縮包內含1個docx文檔大小408KB數(shù)據(jù)和圖表豐富輕量便于快速查閱。已有4927人學習或下載適合需要在精度與速度間尋找平衡點的目標檢測開發(fā)者。1. 引言三代YOLO速度爭議背后到底缺什么不同博主測出來的YOLOv5、YOLOv6、YOLOv7 FPS經常對不上甚至出現(xiàn)“參數(shù)更小的v5比v7更慢”這種反直覺結論。問題出在測試口徑有沒有預熱、開不開cudnn benchmark、后處理算沒算進時延、batch是不是1都會讓同一個模型跑出兩倍差距。標題里的“速度與準確度比較”真正考驗的不是框架能力而是你控制變量的水平。這篇內容會從結構演進講到可復現(xiàn)的benchmark腳本再講到TensorRT驗證目的是讓這套比較不再停留在別人截圖的mAP和FPS上。適合正在選模型、準備做yolo部署、或者想知道yolo第幾代才能滿足業(yè)務目標的工程師。2. YOLOv5、YOLOv6、YOLOv7模型結構演進與準確度提升來源2.1 Backbone、Neck、Head的代際變化YOLOv5真正有價值的設計是把CSPNet引入Darknet骨干把梯度流切成兩個分支讓網絡在加深時不會出現(xiàn)過多重復梯度計算。它的Neck使用PANet結構在FPN基礎上加了一條自底向上的通路小目標的上下文信息因此保留得更完整。這套結構在今天看并不驚艷但勝在穩(wěn)定導出ONNX后幾乎所有推理框架都能原樣支持所以很長一段時間里yolo部署教程上的默認選項都是v5。YOLOv6走的是另一條路。骨干換成EfficientRep訓練時依賴多分支結構讓梯度互不干擾部署前通過重參數(shù)化Re-parameterization把多分支壓縮成單路卷積。這樣計算圖變短顯存訪問次數(shù)也減少。代價是部署流程里必須多做一步先調用模型內部的switch_to_deploy方法把權重轉換后再導出否則測出來的時延比正常模型高一截。很多人在這一步踩坑后誤以為YOLOv6速度不行。YOLOv7在結構上最顯著的是E-ELAN模塊。它不追求把分支合并成類似RepVGG的單路結構而是通過Grouped Convolution和shuffle操作讓不同特征的感受野在更細粒度上互相融合。這種設計在GPU上有出色并行度因為組卷積可以被拆成多個小矩陣乘交由CUDA core并發(fā)處理。再加上SPPCSPC結構把池化結果按通道拼接實際推理時內存占用沒有隨感受野擴大而線性上升。這也是為什么v7同樣尺寸下的mAP通常比v5高但FPS并不吃虧。2.1.1 算子友好度比FLOPs更重要比較速度時盯著FLOPs沒有意義。YOLOv7的推理路徑上包含大量組卷積和shuffle操作在V100、A100這種高帶寬GPU上非常高效換到Jetson或者其他低功耗設備組卷積的訪存模式反而可能拖慢速度。YOLOv6的重參數(shù)化結構減少了對高帶寬的依賴在邊緣設備上往往更穩(wěn)。所以“哪個模型快”必須綁定硬件和推理后端才能回答。2.2 訓練策略如何影響準確度標簽分配與損失函數(shù)YOLOv5使用Anchor-Based預測通過聚類預設一組錨框然后與GT做IoU匹配來確定正樣本。損失函數(shù)使用CIoU它同時懲罰外接框重疊面積、中心點距離和長寬比差異收斂速度比DIoU穩(wěn)定。這套邏輯簡單問題在于預設錨框對數(shù)據(jù)集分布敏感換到自定義數(shù)據(jù)集后如果沒重新聚類mAP會掉不少。YOLOv6引入Task Alignment Learning它的核心思路是不再單純使用IoU作為正樣本匹配標準而是計算分類得分與回歸質量的聯(lián)合對齊度。這樣選出的正樣本既能用于分類分支學習也能用于回歸分支學習避免兩個任務目標相互拉扯。損失函數(shù)方面分類分支使用Varifocal Loss回歸分支繼續(xù)用GIoU或CIoU整體上小目標召回率有提升。YOLOv7在訓練時加入輔助訓練頭這個頭僅在反向傳播中存在推理階段被移除。輔助頭可以接受來自主層的梯度信號讓網絡深層在早期訓練時就獲得足夠反饋。標簽分配上則采用由粗到細的引導策略先用寬松IoU生成候選正樣本再用精確IoU微調。這種訓練階段的額外開銷為模型帶來了“免費”的準確度提升正確復現(xiàn)后mAP收益通常高于簡單增加網絡深度。2.3 從部署視角看三者的算子差異模型骨干/Neck輸出頭訓練后需處理的部署步驟YOLOv5CSPDarknet PANetAnchor-Based直接導出兼容性好YOLOv6EfficientRep RepPANAnchor-Free先switch_to_deploy再導ONNXYOLOv7E-ELAN SPPCSPCAnchor-Based部分框架需自研組卷積算子這張表的價值在排錯。如果你用YOLOv6做TensorRT部署沒有完成重參數(shù)化轉換模型可能保留多個分支計算圖變大測出的延遲沒有參考價值。YOLOv7在ONNX Runtime上如果算子支持不全推理會回落到CPU implementation性能立刻下降。遇到這種情況先檢查日志里算子所在的provider而不是懷疑模型本身。2.4 為什么YOLOv6在推理速度上有自己的天花板重參數(shù)化讓v6的推理圖變短但這只解決卷積層的并行問題不能保證NMS和后處理也高效。官方倉庫更關注訓練吞吐默認配置下NMS寫在Python側和v5的圖內NMS比在batch1時慢5%到10%。你需要在benchmark時把兩個模型的NMS都放到圖里或者都放到圖外才能得到可公平對比的模型純推理速度。這也是做yolo模型訓練以及選型時最容易被忽略的一環(huán)。3. 搭建一套公平的YOLOv5/v6/v7性能比較評測腳本3.1 環(huán)境隔離與固定版本不要試圖在同一個conda環(huán)境里同時跑三個官方倉庫。YOLOv5的requirements鎖定的numpy版本和YOLOv7的pyyaml經常沖突裝到后面會出現(xiàn)“import torch成功、import模型卻報GLIBC錯誤”這種問題。我會拆成三個獨立環(huán)境并且統(tǒng)一Torch版本conda create -n yolo5 python3.9 -y conda activate yolo5 pip install torch2.0.1 torchvision0.15.2 # 再安裝YOLOv5官方倉庫的requirements.txt conda create -n yolo6 python3.9 -y conda activate yolo6 pip install torch2.0.1 torchvision0.15.2 # 再安裝YOLOv6官方倉庫的requirements.txt conda create -n yolo7 python3.9 -y conda activate yolo7 pip install torch2.0.1 torchvision0.15.2 # 再安裝YOLOv7官方倉庫的requirements.txt固定Torch版本是為了排除cuDNN版本差異對卷積選擇的干擾。實際業(yè)務里你可能會用更高的版本但對比三個模型時統(tǒng)一基礎依賴比追新更重要。每個環(huán)境里還要單獨確認torch.cuda.is_available()輸出為True避免裝了CPU版torch而毫無察覺。3.2 用官方驗證腳本跑準確度準確度建議直接用官方val腳本因為每個項目對數(shù)據(jù)預處理的細節(jié)實現(xiàn)不同手寫一個評估流程很容易引入額外偏差。下面是一組常用的命令# YOLOv5環(huán)境 python val.py --weights yolov5s.pt --data coco.yaml --img 640 \ --conf 0.001 --iou 0.65 --batch 32 # YOLOv7環(huán)境 python test.py --weights yolov7-tiny.pt --data coco.yaml --img 640 \ --conf 0.001 --iou 0.65 --batch 32 # YOLOv6環(huán)境 python tools/eval.py --weights yolov6s.pt \ --data data/coco.yaml --img 640 --batch 32參數(shù)說明--conf 0.001表示保留置信度很低的預測框這樣能得到完整的PR曲線mAP計算更接近COCO官方協(xié)議--iou 0.65是NMS閾值值越大保留的框越多小目標mAP會偏高--batch 32保證GPU顯存利用率足夠高避免數(shù)據(jù)加載階段成為瓶頸。三個腳本對準確度的更新邏輯一致都是統(tǒng)計每一張圖片的預測結果再統(tǒng)一計算。輸出會包含[email protected]和[email protected]:0.95兩組值后者對邊框位置更敏感更適合做嚴格選型。3.3 用統(tǒng)一前向接口測量FPS準確度可以跑官方腳本速度不能直接采信打印結果。官方val腳本打印的時間包含數(shù)據(jù)解碼和預處理不是純粹的模型推理時延。我建議寫一個獨立計時函數(shù)統(tǒng)一處理三個模型import time import torch def time_model_forward(model, devicecuda, imgsz640, warmup20, repeats100): 輸入已經加載的model輸出平均單張推理耗時。 model的forward需要只做前向推理不要在里面做NMS和畫圖。 x torch.rand(1, 3, imgsz, imgsz).to(device) # 預熱讓cudnn benchmark和CUDA context先初始化 for _ in range(warmup): with torch.inference_mode(): model(x) torch.cuda.synchronize() start time.perf_counter() for _ in range(repeats): with torch.inference_mode(): model(x) torch.cuda.synchronize() avg_cost (time.perf_counter() - start) / repeats return 1.0 / avg_cost這段代碼用隨機張量而不是真實圖片是為了把預處理和圖片IO從計時中隔離出去。torch.cuda.synchronize()必須在計時前和計時后都調用否則time.perf_counter()測的是CPU發(fā)出的指令時間GPU可能還沒執(zhí)行完。torch.inference_mode()比torch.no_grad()更徹底它連autograd的整條圖狀態(tài)都跳過減少少量開銷。使用YOLOv6時加載模型后要先生成deploy模式的推理網絡再做計時否則測出來的FPS會低于真實部署。3.4 匯總性能矩陣與記錄環(huán)境把前面兩步得到的mAP和FPS放進一張統(tǒng)一的表模型參數(shù)量輸入尺寸mAP [email protected]:0.95batch1 FPSbatch16 FPSYOLOv5s約7.3M640待測待測待測YOLOv6s待測640待測待測待測YOLOv7-tiny約6.2M640待測待測待測表里的權重版本必須寫清楚。不同小版本號的權重文件可能使用不同的訓練schedule直接比會產生誤導。另外在表下方固定記錄GPU型號、顯存、CUDA版本、cuDNN版本、torch版本、是否開啟FP16。缺失這些信息的性能對比表沒有任何復用價值甚至會誤導后續(xù)的yolo模型訓練決策。4. 性能數(shù)據(jù)怎么讀速度與準確度權衡的邊界條件4.1 延遲分位數(shù)比平均FPS更可靠平均FPS只反映整體吞吐線上部署更怕的是長尾延遲。一個模型平均30FPS但P99延遲達到200ms說明它在某些shape和內存分配場景下會出現(xiàn)脈沖式卡頓。正確的做法是記錄每一次推理時延按升序拍列后取P50和P95。建議repeats至少跑200次少于50次的數(shù)據(jù)統(tǒng)計意義太弱。如果P95明顯高于P50優(yōu)先檢查顯存碎片和TensorRT的context緩存而不是模型本身。4.2 后處理和動態(tài)shape的影響YOLOv5可以在導出時把NMS寫入模型圖YOLOv7和v6默認不這樣做。如果你對比時只測“去掉NMS的純卷積耗時”結論會偏離實際生產。我的做法是保持每個官方倉庫的默認后處理但把后處理函數(shù)也包進計時。這樣得到的數(shù)值雖然包含Python循環(huán)但更貼近用戶感知到的單幀延遲。若想看模型純能力則統(tǒng)一使用同一套Python后處理腳本替換各倉庫的NMS。無論哪種都要在報告中注明。4.3 復現(xiàn)YOLO bench時最容易被忽略的開關下面這條命令看起來只是運行了一次前向實際上它驗證了cudnn benchmark對速度的影響python -c import torch, time m torch.nn.Conv2d(64, 64, 3, padding1).cuda().eval() x torch.rand(1, 64, 64, 64).cuda() torch.backends.cudnn.benchmark False for _ in range(5): m(x) torch.cuda.synchronize(); t0time.time() for _ in range(50): m(x) torch.cuda.synchronize(); print(cudnn off, (time.time()-t0)/50) torch.backends.cudnn.benchmark True for _ in range(5): m(x) torch.cuda.synchronize(); t0time.time() for _ in range(50): m(x) torch.cuda.synchronize(); print(cudnn on, (time.time()-t0)/50) 觀察最后兩行輸出你大概率會看到cudnn benchmark打開后前向耗時低20%以上。這說明在一次測評中所有模型必須在同樣的benchmark開關狀態(tài)下運行。默認情況下YOLOv7代碼會在train.py里設置True但val.py未必設置YOLOv5則依賴torch.backends.cudnn.benchmark True。比較前先顯式統(tǒng)一設置并固定torch.set_num_threads(1)避免CPU端線程競爭污染GPU時間數(shù)據(jù)。4.4 排除GPU硬件差異的校準方法相同型號的GPU會因為溫度、功耗墻、甚至PCIe鏈路寬度出現(xiàn)頻率漂移。最嚴謹?shù)淖龇ㄊ擎iGPU時鐘nvidia-smi -lgc 1500,1500 # 把SM時鐘固定到1500MHz適用于多數(shù)Ampere卡測完再恢復nvidia-smi -rgc鎖頻后同一張卡上的FPS抖動會明顯變小。注意不同GPU的base clock不同鎖定過高可能導致掉驅動建議使用nvidia-smi --query-gpuclocks.max.sm --formatcsv先查允許的最大頻率。鎖頻狀態(tài)下比較YOLOv5、v6和v7的差異才更接近純粹模型結構差異。5. 把比較結果落到部署選型模型導出與工程驗證5.1 不同目標硬件的選擇嵌入式設備優(yōu)先考慮YOLOv5s或YOLOv7-tiny并做TensorRT FP16優(yōu)化服務器環(huán)境追求高吞吐時YOLOv7的E-ELAN在批量推理上有優(yōu)勢AMD顯卡和純CPU環(huán)境則建議YOLOv5s導出ONNX。不少yolo部署教程沒有提到AMD的ROCm雖然能跑torch但算子覆蓋度有限YOLOv7的組卷積優(yōu)化不如v5平滑。5.2 導出ONNX和TensorRT進行第二輪比較源碼跑完第一輪后還需要驗證部署版性能。先各自導出# YOLOv5 python export.py --weights yolov5s.pt --include onnx # YOLOv6 python deploy/ONNX/export_onnx.py --weights yolov6s.pt # YOLOv7 python export.py --weights yolov7-tiny.pt --grid然后在TensorRT下用同一條命令測trtexec --onnxyolov7-tiny.onnx --saveEngineengine.engine \ --fp16 --minShapesimages:1x3x640x640 \ --optShapesimages:8x3x640x640 \ --maxShapesimages:16x3x640x640--fp16開啟半精度顯存占用低速度通常接近翻倍--minShapes、--optShapes和--maxShapes定義了動態(tài)shape范圍如果只設一個固定shapeTensorRT會降低算子選擇策略測出來的延遲反而偏高。三個模型必須用同樣的shape范圍和精度參數(shù)導出結果才可比較。5.3 一份可直接復制的驗證流程固定COCO val2017中隨機抽樣的1000張圖片統(tǒng)一使用letterbox預處理。對每個模型跑三組測試每組重復200次取P50時間。記錄GPU實時頻率nvidia-smi --query-gpuname,clocks.sm,power.draw --formatcsv。在TensorRT模式下先加載engine并完成反序列化再把從host拷貝到device到NMS完成作為一個整體計時。如果你要發(fā)布這份對比數(shù)據(jù)記得把gpu頻率和cudnn開關狀態(tài)截圖一起貼出來比單獨貼mAP更有說服力。本文還有配套的精品資源點擊獲取 YOLOv5/v6/v7速度與準確度對比：可復現(xiàn)Benchmark與TensorRT部署驗證
簡介YOLOv5、YOLOv6與YOLOv7是當前目標檢測領域應用最廣的YOLO系列模型這份資料從工程實踐視角系統(tǒng)比較三者mAP精度、FPS推理速度及CPU/GPU適配表現(xiàn)適合算法工程師、計算機視覺初學者與模型選型決策者閱讀。內容圍繞CPU、RTX 4090、V100、P100等多類硬件環(huán)境展開實測覆蓋Nano、Tiny及大模型的多檔配置并回應了哪個模型CPU上最快、GPU上最快、小物體檢測如何選、訓練需多大顯存等高頻問題。文檔還重點分析了游戲GPU與AI GPU對FPS的影響以及Tiny/Nano模型在部分GPU上性能下降的原因為實際項目提供可落地的選型依據(jù)。壓縮包內含1個docx文檔大小408KB數(shù)據(jù)和圖表豐富輕量便于快速查閱。已有4927人學習或下載適合需要在精度與速度間尋找平衡點的目標檢測開發(fā)者。1. 引言三代YOLO速度爭議背后到底缺什么不同博主測出來的YOLOv5、YOLOv6、YOLOv7 FPS經常對不上甚至出現(xiàn)“參數(shù)更小的v5比v7更慢”這種反直覺結論。問題出在測試口徑有沒有預熱、開不開cudnn benchmark、后處理算沒算進時延、batch是不是1都會讓同一個模型跑出兩倍差距。標題里的“速度與準確度比較”真正考驗的不是框架能力而是你控制變量的水平。這篇內容會從結構演進講到可復現(xiàn)的benchmark腳本再講到TensorRT驗證目的是讓這套比較不再停留在別人截圖的mAP和FPS上。適合正在選模型、準備做yolo部署、或者想知道yolo第幾代才能滿足業(yè)務目標的工程師。2. YOLOv5、YOLOv6、YOLOv7模型結構演進與準確度提升來源2.1 Backbone、Neck、Head的代際變化YOLOv5真正有價值的設計是把CSPNet引入Darknet骨干把梯度流切成兩個分支讓網絡在加深時不會出現(xiàn)過多重復梯度計算。它的Neck使用PANet結構在FPN基礎上加了一條自底向上的通路小目標的上下文信息因此保留得更完整。這套結構在今天看并不驚艷但勝在穩(wěn)定導出ONNX后幾乎所有推理框架都能原樣支持所以很長一段時間里yolo部署教程上的默認選項都是v5。YOLOv6走的是另一條路。骨干換成EfficientRep訓練時依賴多分支結構讓梯度互不干擾部署前通過重參數(shù)化Re-parameterization把多分支壓縮成單路卷積。這樣計算圖變短顯存訪問次數(shù)也減少。代價是部署流程里必須多做一步先調用模型內部的switch_to_deploy方法把權重轉換后再導出否則測出來的時延比正常模型高一截。很多人在這一步踩坑后誤以為YOLOv6速度不行。YOLOv7在結構上最顯著的是E-ELAN模塊。它不追求把分支合并成類似RepVGG的單路結構而是通過Grouped Convolution和shuffle操作讓不同特征的感受野在更細粒度上互相融合。這種設計在GPU上有出色并行度因為組卷積可以被拆成多個小矩陣乘交由CUDA core并發(fā)處理。再加上SPPCSPC結構把池化結果按通道拼接實際推理時內存占用沒有隨感受野擴大而線性上升。這也是為什么v7同樣尺寸下的mAP通常比v5高但FPS并不吃虧。2.1.1 算子友好度比FLOPs更重要比較速度時盯著FLOPs沒有意義。YOLOv7的推理路徑上包含大量組卷積和shuffle操作在V100、A100這種高帶寬GPU上非常高效換到Jetson或者其他低功耗設備組卷積的訪存模式反而可能拖慢速度。YOLOv6的重參數(shù)化結構減少了對高帶寬的依賴在邊緣設備上往往更穩(wěn)。所以“哪個模型快”必須綁定硬件和推理后端才能回答。2.2 訓練策略如何影響準確度標簽分配與損失函數(shù)YOLOv5使用Anchor-Based預測通過聚類預設一組錨框然后與GT做IoU匹配來確定正樣本。損失函數(shù)使用CIoU它同時懲罰外接框重疊面積、中心點距離和長寬比差異收斂速度比DIoU穩(wěn)定。這套邏輯簡單問題在于預設錨框對數(shù)據(jù)集分布敏感換到自定義數(shù)據(jù)集后如果沒重新聚類mAP會掉不少。YOLOv6引入Task Alignment Learning它的核心思路是不再單純使用IoU作為正樣本匹配標準而是計算分類得分與回歸質量的聯(lián)合對齊度。這樣選出的正樣本既能用于分類分支學習也能用于回歸分支學習避免兩個任務目標相互拉扯。損失函數(shù)方面分類分支使用Varifocal Loss回歸分支繼續(xù)用GIoU或CIoU整體上小目標召回率有提升。YOLOv7在訓練時加入輔助訓練頭這個頭僅在反向傳播中存在推理階段被移除。輔助頭可以接受來自主層的梯度信號讓網絡深層在早期訓練時就獲得足夠反饋。標簽分配上則采用由粗到細的引導策略先用寬松IoU生成候選正樣本再用精確IoU微調。這種訓練階段的額外開銷為模型帶來了“免費”的準確度提升正確復現(xiàn)后mAP收益通常高于簡單增加網絡深度。2.3 從部署視角看三者的算子差異模型骨干/Neck輸出頭訓練后需處理的部署步驟YOLOv5CSPDarknet PANetAnchor-Based直接導出兼容性好YOLOv6EfficientRep RepPANAnchor-Free先switch_to_deploy再導ONNXYOLOv7E-ELAN SPPCSPCAnchor-Based部分框架需自研組卷積算子這張表的價值在排錯。如果你用YOLOv6做TensorRT部署沒有完成重參數(shù)化轉換模型可能保留多個分支計算圖變大測出的延遲沒有參考價值。YOLOv7在ONNX Runtime上如果算子支持不全推理會回落到CPU implementation性能立刻下降。遇到這種情況先檢查日志里算子所在的provider而不是懷疑模型本身。2.4 為什么YOLOv6在推理速度上有自己的天花板重參數(shù)化讓v6的推理圖變短但這只解決卷積層的并行問題不能保證NMS和后處理也高效。官方倉庫更關注訓練吞吐默認配置下NMS寫在Python側和v5的圖內NMS比在batch1時慢5%到10%。你需要在benchmark時把兩個模型的NMS都放到圖里或者都放到圖外才能得到可公平對比的模型純推理速度。這也是做yolo模型訓練以及選型時最容易被忽略的一環(huán)。3. 搭建一套公平的YOLOv5/v6/v7性能比較評測腳本3.1 環(huán)境隔離與固定版本不要試圖在同一個conda環(huán)境里同時跑三個官方倉庫。YOLOv5的requirements鎖定的numpy版本和YOLOv7的pyyaml經常沖突裝到后面會出現(xiàn)“import torch成功、import模型卻報GLIBC錯誤”這種問題。我會拆成三個獨立環(huán)境并且統(tǒng)一Torch版本conda create -n yolo5 python3.9 -y conda activate yolo5 pip install torch2.0.1 torchvision0.15.2 # 再安裝YOLOv5官方倉庫的requirements.txt conda create -n yolo6 python3.9 -y conda activate yolo6 pip install torch2.0.1 torchvision0.15.2 # 再安裝YOLOv6官方倉庫的requirements.txt conda create -n yolo7 python3.9 -y conda activate yolo7 pip install torch2.0.1 torchvision0.15.2 # 再安裝YOLOv7官方倉庫的requirements.txt固定Torch版本是為了排除cuDNN版本差異對卷積選擇的干擾。實際業(yè)務里你可能會用更高的版本但對比三個模型時統(tǒng)一基礎依賴比追新更重要。每個環(huán)境里還要單獨確認torch.cuda.is_available()輸出為True避免裝了CPU版torch而毫無察覺。3.2 用官方驗證腳本跑準確度準確度建議直接用官方val腳本因為每個項目對數(shù)據(jù)預處理的細節(jié)實現(xiàn)不同手寫一個評估流程很容易引入額外偏差。下面是一組常用的命令# YOLOv5環(huán)境 python val.py --weights yolov5s.pt --data coco.yaml --img 640 \ --conf 0.001 --iou 0.65 --batch 32 # YOLOv7環(huán)境 python test.py --weights yolov7-tiny.pt --data coco.yaml --img 640 \ --conf 0.001 --iou 0.65 --batch 32 # YOLOv6環(huán)境 python tools/eval.py --weights yolov6s.pt \ --data data/coco.yaml --img 640 --batch 32參數(shù)說明--conf 0.001表示保留置信度很低的預測框這樣能得到完整的PR曲線mAP計算更接近COCO官方協(xié)議--iou 0.65是NMS閾值值越大保留的框越多小目標mAP會偏高--batch 32保證GPU顯存利用率足夠高避免數(shù)據(jù)加載階段成為瓶頸。三個腳本對準確度的更新邏輯一致都是統(tǒng)計每一張圖片的預測結果再統(tǒng)一計算。輸出會包含[email protected]和[email protected]:0.95兩組值后者對邊框位置更敏感更適合做嚴格選型。3.3 用統(tǒng)一前向接口測量FPS準確度可以跑官方腳本速度不能直接采信打印結果。官方val腳本打印的時間包含數(shù)據(jù)解碼和預處理不是純粹的模型推理時延。我建議寫一個獨立計時函數(shù)統(tǒng)一處理三個模型import time import torch def time_model_forward(model, devicecuda, imgsz640, warmup20, repeats100): 輸入已經加載的model輸出平均單張推理耗時。 model的forward需要只做前向推理不要在里面做NMS和畫圖。 x torch.rand(1, 3, imgsz, imgsz).to(device) # 預熱讓cudnn benchmark和CUDA context先初始化 for _ in range(warmup): with torch.inference_mode(): model(x) torch.cuda.synchronize() start time.perf_counter() for _ in range(repeats): with torch.inference_mode(): model(x) torch.cuda.synchronize() avg_cost (time.perf_counter() - start) / repeats return 1.0 / avg_cost這段代碼用隨機張量而不是真實圖片是為了把預處理和圖片IO從計時中隔離出去。torch.cuda.synchronize()必須在計時前和計時后都調用否則time.perf_counter()測的是CPU發(fā)出的指令時間GPU可能還沒執(zhí)行完。torch.inference_mode()比torch.no_grad()更徹底它連autograd的整條圖狀態(tài)都跳過減少少量開銷。使用YOLOv6時加載模型后要先生成deploy模式的推理網絡再做計時否則測出來的FPS會低于真實部署。3.4 匯總性能矩陣與記錄環(huán)境把前面兩步得到的mAP和FPS放進一張統(tǒng)一的表模型參數(shù)量輸入尺寸mAP [email protected]:0.95batch1 FPSbatch16 FPSYOLOv5s約7.3M640待測待測待測YOLOv6s待測640待測待測待測YOLOv7-tiny約6.2M640待測待測待測表里的權重版本必須寫清楚。不同小版本號的權重文件可能使用不同的訓練schedule直接比會產生誤導。另外在表下方固定記錄GPU型號、顯存、CUDA版本、cuDNN版本、torch版本、是否開啟FP16。缺失這些信息的性能對比表沒有任何復用價值甚至會誤導后續(xù)的yolo模型訓練決策。4. 性能數(shù)據(jù)怎么讀速度與準確度權衡的邊界條件4.1 延遲分位數(shù)比平均FPS更可靠平均FPS只反映整體吞吐線上部署更怕的是長尾延遲。一個模型平均30FPS但P99延遲達到200ms說明它在某些shape和內存分配場景下會出現(xiàn)脈沖式卡頓。正確的做法是記錄每一次推理時延按升序拍列后取P50和P95。建議repeats至少跑200次少于50次的數(shù)據(jù)統(tǒng)計意義太弱。如果P95明顯高于P50優(yōu)先檢查顯存碎片和TensorRT的context緩存而不是模型本身。4.2 后處理和動態(tài)shape的影響YOLOv5可以在導出時把NMS寫入模型圖YOLOv7和v6默認不這樣做。如果你對比時只測“去掉NMS的純卷積耗時”結論會偏離實際生產。我的做法是保持每個官方倉庫的默認后處理但把后處理函數(shù)也包進計時。這樣得到的數(shù)值雖然包含Python循環(huán)但更貼近用戶感知到的單幀延遲。若想看模型純能力則統(tǒng)一使用同一套Python后處理腳本替換各倉庫的NMS。無論哪種都要在報告中注明。4.3 復現(xiàn)YOLO bench時最容易被忽略的開關下面這條命令看起來只是運行了一次前向實際上它驗證了cudnn benchmark對速度的影響python -c import torch, time m torch.nn.Conv2d(64, 64, 3, padding1).cuda().eval() x torch.rand(1, 64, 64, 64).cuda() torch.backends.cudnn.benchmark False for _ in range(5): m(x) torch.cuda.synchronize(); t0time.time() for _ in range(50): m(x) torch.cuda.synchronize(); print(cudnn off, (time.time()-t0)/50) torch.backends.cudnn.benchmark True for _ in range(5): m(x) torch.cuda.synchronize(); t0time.time() for _ in range(50): m(x) torch.cuda.synchronize(); print(cudnn on, (time.time()-t0)/50) 觀察最后兩行輸出你大概率會看到cudnn benchmark打開后前向耗時低20%以上。這說明在一次測評中所有模型必須在同樣的benchmark開關狀態(tài)下運行。默認情況下YOLOv7代碼會在train.py里設置True但val.py未必設置YOLOv5則依賴torch.backends.cudnn.benchmark True。比較前先顯式統(tǒng)一設置并固定torch.set_num_threads(1)避免CPU端線程競爭污染GPU時間數(shù)據(jù)。4.4 排除GPU硬件差異的校準方法相同型號的GPU會因為溫度、功耗墻、甚至PCIe鏈路寬度出現(xiàn)頻率漂移。最嚴謹?shù)淖龇ㄊ擎iGPU時鐘nvidia-smi -lgc 1500,1500 # 把SM時鐘固定到1500MHz適用于多數(shù)Ampere卡測完再恢復nvidia-smi -rgc鎖頻后同一張卡上的FPS抖動會明顯變小。注意不同GPU的base clock不同鎖定過高可能導致掉驅動建議使用nvidia-smi --query-gpuclocks.max.sm --formatcsv先查允許的最大頻率。鎖頻狀態(tài)下比較YOLOv5、v6和v7的差異才更接近純粹模型結構差異。5. 把比較結果落到部署選型模型導出與工程驗證5.1 不同目標硬件的選擇嵌入式設備優(yōu)先考慮YOLOv5s或YOLOv7-tiny并做TensorRT FP16優(yōu)化服務器環(huán)境追求高吞吐時YOLOv7的E-ELAN在批量推理上有優(yōu)勢AMD顯卡和純CPU環(huán)境則建議YOLOv5s導出ONNX。不少yolo部署教程沒有提到AMD的ROCm雖然能跑torch但算子覆蓋度有限YOLOv7的組卷積優(yōu)化不如v5平滑。5.2 導出ONNX和TensorRT進行第二輪比較源碼跑完第一輪后還需要驗證部署版性能。先各自導出# YOLOv5 python export.py --weights yolov5s.pt --include onnx # YOLOv6 python deploy/ONNX/export_onnx.py --weights yolov6s.pt # YOLOv7 python export.py --weights yolov7-tiny.pt --grid然后在TensorRT下用同一條命令測trtexec --onnxyolov7-tiny.onnx --saveEngineengine.engine \ --fp16 --minShapesimages:1x3x640x640 \ --optShapesimages:8x3x640x640 \ --maxShapesimages:16x3x640x640--fp16開啟半精度顯存占用低速度通常接近翻倍--minShapes、--optShapes和--maxShapes定義了動態(tài)shape范圍如果只設一個固定shapeTensorRT會降低算子選擇策略測出來的延遲反而偏高。三個模型必須用同樣的shape范圍和精度參數(shù)導出結果才可比較。5.3 一份可直接復制的驗證流程固定COCO val2017中隨機抽樣的1000張圖片統(tǒng)一使用letterbox預處理。對每個模型跑三組測試每組重復200次取P50時間。記錄GPU實時頻率nvidia-smi --query-gpuname,clocks.sm,power.draw --formatcsv。在TensorRT模式下先加載engine并完成反序列化再把從host拷貝到device到NMS完成作為一個整體計時。如果你要發(fā)布這份對比數(shù)據(jù)記得把gpu頻率和cudnn開關狀態(tài)截圖一起貼出來比單獨貼mAP更有說服力。本文還有配套的精品資源點擊獲取