檢測實(shí)戰(zhàn)：結(jié)構(gòu)、訓(xùn)練與部署指南)
簡介面向目標(biāo)檢測算法研究與輕量化部署場景這份PyTorch實(shí)現(xiàn)的MobileNet-YOLO檢測網(wǎng)絡(luò)資源覆蓋MobilenetV1/V2/V3與YOLOv3/YOLOv4系列模型適合需要對比主干網(wǎng)絡(luò)與檢測頭組合效果的算法工程師和研究生。損失函數(shù)與原始實(shí)現(xiàn)保持一致模型在VOC20072012上訓(xùn)練并在VOC2007上測試權(quán)重采用ImageNet預(yù)訓(xùn)練使用方式貼近原始YOLO可直接沿用其數(shù)據(jù)準(zhǔn)備、訓(xùn)練與評估流程。資源包為zip格式共29個文件大小約240KB包含16個Python腳本模型結(jié)構(gòu)、訓(xùn)練、推理、mAP評估、圖像增強(qiáng)等、5個shell腳本數(shù)據(jù)集下載、lmdb創(chuàng)建、訓(xùn)練、推理、2個YAML配置數(shù)據(jù)路徑與參數(shù)、說明文檔與許可證以及若干示例圖片目錄劃分清楚便于按模塊復(fù)用。已有1944人學(xué)習(xí)/下載。通過該資源可完整復(fù)現(xiàn)輕量化檢測器的訓(xùn)練與推理流程掌握VOC數(shù)據(jù)集預(yù)處理和lmdb轉(zhuǎn)換的細(xì)節(jié)同時可參考eval_mAP、圖像增強(qiáng)等工具腳本快速遷移到自有目標(biāo)檢測任務(wù)中。1. 從跑不動到流暢檢測MobileNet-YOLO-Pytorch 的價值被很多人低估了MobileNet-YOLO-Pytorch 這個項(xiàng)目名看著很長但本質(zhì)很直接把 MobileNet 系列v1/v2/v3當(dāng)作骨干網(wǎng)絡(luò)后端接 YOLO 系列YOLOv3/YOLOv4的檢測頭形成一套可以在 CPU 和嵌入式設(shè)備上實(shí)際跑起來的檢測方案。很多人第一反應(yīng)是“這不就是個縫合怪嗎”但真正在邊緣設(shè)備上部署過的人會明白這一步縫合解決的是實(shí)打?qū)嵉目ú弊訂栴}。我之前在某個項(xiàng)目里要在一個低功耗盒子上跑實(shí)時檢測原版 YOLOv3 的 DarkNet 骨干一幀推理要 400 多毫秒整個業(yè)務(wù)沒法落地。后來把骨干換成 MobileNet同樣的檢測頭推理時間直接降到 50 毫秒檔位精度損失遠(yuǎn)沒有想象中大。這套組合的適用人群很明確手頭有檢測需求、設(shè)備算力受限、又不想從零設(shè)計(jì)網(wǎng)絡(luò)結(jié)構(gòu)的人。接下來我會按“結(jié)構(gòu)原理 → 環(huán)境與訓(xùn)練 → 自定義數(shù)據(jù)適配 → 避坑 → 部署優(yōu)化”這條線展開把我自己踩過的坑和驗(yàn)證過的參數(shù)習(xí)慣都放進(jìn)去。這篇文章適合兩類讀者第一次接觸輕量化目標(biāo)檢測的新手可以直接按步驟復(fù)現(xiàn)已經(jīng)跑過 YOLO 訓(xùn)練的老手可以重點(diǎn)看第五、六章那里有最容易被忽略的細(xì)節(jié)。2. 網(wǎng)絡(luò)結(jié)構(gòu)與代碼組織為什么 MobileNet 能和 YOLO 自由組合先說結(jié)論YOLO 的檢測頭并不綁定特定骨干它對骨干網(wǎng)絡(luò)的依賴主要體現(xiàn)為“尺度數(shù)量、下采樣倍數(shù)、輸出通道”這三件事。MobileNet 系列恰好在這三件事上滿足要求所以組合是順理成章的而不是靠硬改代碼堆出來的。2.1 MobileNet 三代的核心結(jié)構(gòu)差異深度可分離卷積、倒殘差與 NASMobileNet v1 的核心貢獻(xiàn)是深度可分離卷積。常規(guī)卷積同時做空間特征提取和通道融合計(jì)算量是k×k×C_in×C_out拆開之后先用一個k×k的深度卷積只處理每個通道內(nèi)的空間信息再用1×1卷積做跨通道融合計(jì)算量降到k×k×C_in C_in×C_out在 3×3 卷積下大約是原來的九分之一到八分之一。這個思路后來幾乎成了所有輕量骨干的標(biāo)配。MobileNet v2 在 v1 基礎(chǔ)上加了倒殘差結(jié)構(gòu)和線性瓶頸。倒殘差的順序是先1×1擴(kuò)張通道再做深度卷積最后1×1壓縮回來通道數(shù)從窄到寬再到窄。設(shè)計(jì)動機(jī)是 ReLU 對低維特征會產(chǎn)生信息截?cái)嗨栽谄款i層輸出處用線性激活代替 ReLU。如果骨干輸出特征圖的維度已經(jīng)很低你要注意這一點(diǎn)后續(xù)接入檢測頭時盡量不要再人為壓縮通道。MobileNet v3 引入了神經(jīng)架構(gòu)搜索不再完全靠手工設(shè)計(jì)結(jié)構(gòu)。它在 v2 的基礎(chǔ)上加了輕量級注意力模塊 SE同時把網(wǎng)絡(luò)尾部幾個冗余卷積層直接刪掉激活函數(shù)換成了 h-swish。這幾個改動疊加起來讓 v3 在相同精度下體積比 v2 更小、延遲更低。下面這張表格可以快速對比三代的核心差異版本核心結(jié)構(gòu)主要收益明顯代價v1深度可分離卷積計(jì)算量大幅降低通道間信息融合弱精度一般v2倒殘差 線性瓶頸低維特征保留更好精度提升先擴(kuò)張后壓縮內(nèi)存訪問略增v3NAS 搜索 SE h-swish體積更小速度更快結(jié)構(gòu)碎片化部分硬件不友好選 v1 還是 v3取決于你的底線在哪里。我的習(xí)慣是CPU 上跑選 v3-large追求極致體積選 v3-small想在老設(shè)備上穩(wěn)定兼容選 v2。2.2 YOLO 檢測頭對骨干網(wǎng)絡(luò)的三個硬性要求YOLOv3 和 YOLOv4 的檢測頭不接收單個特征圖而是接收三個不同尺度的特征圖。以 416×416 輸入為例三個特征圖尺寸分別是 13×13、26×26、52×52對應(yīng)下采樣 32 倍、16 倍、8 倍。因此骨干網(wǎng)絡(luò)必須能輸出三個尺度的特征這是第一個硬性要求。第二個要求是特征圖的通道數(shù)不能太低。YOLO 檢測頭會在每個尺度上執(zhí)行一系列卷積如果骨干輸出的通道數(shù)過少信息會過早坍縮小目標(biāo)直接檢測不到。MobileNet v2 最后幾個 bottleneck 的輸出通道通常在 96、192、320 這個量級接入檢測頭時通過1×1卷積做通道對齊語義信息不會丟失太多。第三個要求是感受野要覆蓋到足夠大的范圍。YOLO 在 13×13 這樣低分辨率的特征圖上檢測大目標(biāo)單個點(diǎn)對應(yīng)的感受野必須接近整個輸入圖像。MobileNet 雖然全程使用小卷積核但通過多次下采樣積累了足夠的感受野這一點(diǎn)實(shí)測下來是滿足的。如果骨干替換后大目標(biāo)漏檢嚴(yán)重問題往往出在疊加大卷積核或空洞卷積的位置沒配對。2.3 配置驅(qū)動替換骨干三個組合的代碼路徑是怎樣的這種整合項(xiàng)目的代碼組織方式通常不是“每種組合維護(hù)一套模型文件”而是由一個模型構(gòu)建函數(shù)統(tǒng)一加載配置按 key 去實(shí)例化骨干和檢測頭。我一般會在配置里區(qū)分model.backbone和model.detector兩個字段這樣切換組合時只改配置不動模型代碼。model: backbone: mobilenetv3-large # v1 / v2 / v3-small 均可 backbone_pretrained: weights/mbv3_large.pth detector: yolov3 # yolov3 或 yolov4 num_classes: 20 input_size: 416 anchors: - [10, 13, 16, 30, 33, 23] - [30, 61, 62, 45, 59, 119] - [116, 90, 156, 198, 373, 326]上面的 anchors 列表來自公共數(shù)據(jù)集上的默認(rèn)值換自定義數(shù)據(jù)集時必須要重算這一點(diǎn)在第四章展開。模型構(gòu)建的核心邏輯一般長這樣def build_model(cfg): backbone create_backbone( cfg[model][backbone], pretrainedcfg[model][backbone_pretrained], ) detector create_detector( cfg[model][detector], num_classescfg[model][num_classes], anchorscfg[model][anchors], ) return MobileYOLO(backbone, detector) class MobileYOLO(torch.nn.Module): def __init__(self, backbone, detector): super().__init__() self.backbone backbone self.detector detector def forward(self, x): c1, c2, c3 self.backbone(x) # stride 32 / 16 / 8 return self.detector([c1, c2, c3])邏輯說明create_backbone返回的是三個層的輸出不是單個最終特征圖。create_detector接收一個列表然后在內(nèi)部做特征融合和預(yù)測分支計(jì)算。參數(shù)說明里最需要注意的是 anchors 的層級順序列表第一組對應(yīng) 13×13 大尺度特征圖最后一組對應(yīng) 52×52 小尺度特征圖順序?qū)懛磿霈F(xiàn)小目標(biāo)檢測不到但大目標(biāo)正常這種詭異現(xiàn)象。3. 最小可復(fù)現(xiàn)訓(xùn)練流程環(huán)境配置、參數(shù)修改與首輪訓(xùn)練很多人拿到這類項(xiàng)目先急著改網(wǎng)絡(luò)結(jié)構(gòu)結(jié)果環(huán)境都沒跑通。我建議先按默認(rèn)配置完整跑一遍訓(xùn)練再動結(jié)構(gòu)不遲。3.1 環(huán)境版本選擇PyTorch、CUDA 與依賴的匹配關(guān)系這類輕量檢測項(xiàng)目對 PyTorch 版本不算挑剔但有幾個匹配關(guān)系要留意。我實(shí)測下來PyTorch 1.8 到 2.x 都能正常跑通區(qū)別主要體現(xiàn)在兩方面老版本對新顯卡的自適應(yīng)支持差一些新版本在舊顯卡上偶爾會提示算子不可用。# 建議先裝 PyTorch 主庫再裝其余依賴 pip install torch1.10.0 torchvision0.11.0 # 其余依賴一次裝齊 pip install numpy opencv-python pyyaml tqdm邏輯說明torchvision 只在加載 ImageNet 預(yù)訓(xùn)練骨干時用到如果你打算從零訓(xùn)練檢測頭torchvision 可以不裝少一個版本扯皮的地方。參數(shù)說明openvc-python 負(fù)責(zé)數(shù)據(jù)增強(qiáng)里的圖像讀取和縮放pyyaml 負(fù)責(zé)解析配置文件tqdm 只影響進(jìn)度條顯示裝不裝不影響訓(xùn)練結(jié)果。有一個環(huán)境相關(guān)的提醒如果你的顯卡驅(qū)動只支持 CUDA 10.2不要硬裝 PyTorch 2.x它默認(rèn)編譯的 CUDA 版本更高運(yùn)行時會報(bào)驅(qū)動不兼容。遇到這種情況先nvidia-smi看驅(qū)動版本再反推 PyTorch 版本不要倒過來。3.2 三組關(guān)鍵參數(shù)骨干系數(shù)、輸入分辨率與訓(xùn)練超參訓(xùn)練前首先要確定的是輸入分辨率。416 是這類項(xiàng)目的默認(rèn)平衡點(diǎn)608 能提升小目標(biāo) mAP但推理時間幾乎翻倍320 適合追求速度的場景mAP 比 416 低 2 到 5 個點(diǎn)。我的建議是訓(xùn)練用 416部署到邊緣設(shè)備時再用 320 做一次測試如果精度落在可接受范圍就用 320 推理。train: input_size: 416 # 320 / 416 / 608訓(xùn)練和驗(yàn)證保持一致 batch_size: 16 # 顯存不足時優(yōu)先降到 8而不是調(diào)低分辨率 epochs: 200 lr: 0.001 lr_scheduler: cosine warmup_epochs: 3 freeze_backbone: 20 # 前 20 個 epoch 凍結(jié)骨干只訓(xùn)練檢測頭參數(shù)說明freeze_backbone非常關(guān)鍵。MobileNet 骨干如果隨機(jī)初始化需要大量數(shù)據(jù)才能學(xué)到通用特征加載 ImageNet 預(yù)訓(xùn)練權(quán)重后前 20 個 epoch 凍結(jié)骨干讓檢測頭先適應(yīng)特征分布之后再解凍聯(lián)合調(diào)優(yōu)。warmup_epochs在前 3 輪把學(xué)習(xí)率從 0 線性升到目標(biāo)值能有效避免前幾個 batch 的 loss 劇烈波動。cosine調(diào)度器配合 200 個 epoch收斂曲線比 step 下降更平滑。3.3 一條命令跑通訓(xùn)練從預(yù)訓(xùn)練權(quán)重到 loss 輸出依賴裝好、配置改完訓(xùn)練命令本身很簡單。關(guān)鍵在于權(quán)重文件的位置和命名很多項(xiàng)目運(yùn)行的報(bào)錯都是因?yàn)闄?quán)重路徑配置成了相對路徑而當(dāng)前工作目錄不對。python train.py \ --cfg cfg/mobilenetv3_yolov3.yaml \ --data data/custom.data \ --weights weights/mbv3_large_imagenet.pth \ --epochs 200 \ --batch-size 16邏輯說明--cfg指向模型結(jié)構(gòu)配置--data指向數(shù)據(jù)列表文件--weights是骨干預(yù)訓(xùn)練權(quán)重。參數(shù)說明里的data/custom.data是一個文本文件內(nèi)容通常是classes3 traindata/train.txt valdata/val.txt namesdata/custom.names其中train.txt每行是一張訓(xùn)練圖片的絕對路徑。如果這個文件里混入了不存在的路徑訓(xùn)練時會跳過對應(yīng)圖片跑完才發(fā)現(xiàn)數(shù)據(jù)量少了一半這種錯誤很隱蔽。首輪訓(xùn)練建議只跑 30 個 epoch 做驗(yàn)證看 loss 是否在穩(wěn)步下降同時確認(rèn) loss 量級在正常范圍而不是追求一輪跑完。日志里出現(xiàn)loss: 4.2這種數(shù)值是正常的代表初始預(yù)測還不夠準(zhǔn)等檢測頭訓(xùn)練充分后會降到 1 以下。4. 自定義數(shù)據(jù)集訓(xùn)練格式轉(zhuǎn)換、anchors 重算與收斂驗(yàn)證用公共數(shù)據(jù)集訓(xùn)練只是驗(yàn)證環(huán)境真正要落地必須換成自己的數(shù)據(jù)。這一章講清楚從標(biāo)注文件到訓(xùn)練驗(yàn)證的完整鏈路。4.1 把標(biāo)注數(shù)據(jù)轉(zhuǎn)成訓(xùn)練格式最不容易丟坐標(biāo)的腳本標(biāo)注工具導(dǎo)出最多的格式是 Pascal VOC 的 XML適合做數(shù)據(jù)管理但訓(xùn)練通常要的是 YOLO 格式的 TXT。轉(zhuǎn)換腳本不復(fù)雜但有三個地方容易出錯歸一化坐標(biāo)算錯、小目標(biāo)坐標(biāo)被整除丟精度、類別索引和名稱對不上。import os import xml.etree.ElementTree as ET from PIL import Image def voc_to_yolo(xml_path, img_dir, out_dir, class_map): tree ET.parse(xml_path) root tree.getroot() img_name root.find(filename).text img_w, img_h Image.open(os.path.join(img_dir, img_name)).size lines [] for obj in root.iter(object): cls_name obj.find(name).text box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) cx (x1 x2) / 2 / img_w cy (y1 y2) / 2 / img_h bw (x2 - x1) / img_w bh (y2 - y1) / img_h lines.append(f{class_map[cls_name]} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) out_name img_name.rsplit(., 1)[0] .txt with open(os.path.join(out_dir, out_name), w) as f: f.write(\n.join(lines))邏輯說明核心是先把左上角和右下角坐標(biāo)轉(zhuǎn)成中心點(diǎn)加寬高再除以圖片寬高做歸一化。參數(shù)說明里最容易踩的坑是坐標(biāo)字段在部分工具里會導(dǎo)出成整數(shù)或字符串必須顯式轉(zhuǎn)成 float否則除法的結(jié)果會變成 0小目標(biāo)直接從訓(xùn)練集里消失。4.2 用 K-means 為你的數(shù)據(jù)集重算 anchors而不是硬用默認(rèn)值YOLO 的默認(rèn) anchors 是在特定數(shù)據(jù)分布上聚類出來的直接用在自定義數(shù)據(jù)集上典型結(jié)果是訓(xùn)練正常、loss 正常但小目標(biāo) mAP 極低。原因在于預(yù)置 anchors 尺寸與真實(shí)目標(biāo)尺寸的交并比太小訓(xùn)練時無法選出正樣本。解決辦法是重新聚類。import numpy as np def iou_wh(wh, cluster): min_wh np.minimum(wh, cluster[:, None, :]) inter min_wh[..., 0] * min_wh[..., 1] union wh[..., 0] * wh[..., 1] cluster[:, None, :][..., 0] * cluster[:, None, :][..., 1] - inter return inter / np.maximum(union, 1e-6) def kmeans_anchors(wh_list, k9, iters300): wh_list np.asarray(wh_list, dtypenp.float64) clusters wh_list[np.random.choice(len(wh_list), k, replaceFalse)] for _ in range(iters): iou iou_wh(wh_list, clusters) assign np.argmax(iou, axis1) new_clusters np.zeros_like(clusters) for i in range(k): selected wh_list[assign i] if len(selected) 0: new_clusters[i] selected.mean(axis0) else: new_clusters[i] clusters[i] if np.allclose(clusters, new_clusters): break clusters new_clusters return clusters[np.argsort(clusters[:, 0] * clusters[:, 1])]邏輯說明K-means 聚類的距離度量使用 IoU 距離即d 1 - IoU(box, centroid)這樣聚類結(jié)果與檢測框的交并比直接相關(guān)。參數(shù)說明里k9對應(yīng) YOLOv3/v4 的九組 anchors太小會導(dǎo)致正樣本選擇不平衡太大反而在訓(xùn)練時增加回歸難度。聚類完成后把結(jié)果按面積從大到小排列前三個分給 13×13 特征圖中間三個分給 26×26最后三個分給 52×52然后寫回配置文件。4.3 訓(xùn)練中怎么判斷真的收斂了用 mAP 而不是 loss 曲線訓(xùn)練到后期會看到 loss 還在緩慢下降但 mAP 已經(jīng)不再提升。loss 下降代表回歸損失還在優(yōu)化但如果正負(fù)樣本比例失衡loss 里的分類損失被負(fù)樣本主導(dǎo)mAP 不漲就是典型的無效訓(xùn)練。所以收斂判斷必須依賴驗(yàn)證集指標(biāo)。python val.py \ --cfg cfg/mobilenetv3_yolov3.yaml \ --data data/custom.data \ --weights weights/best.pt \ --iou-thres 0.5 \ --conf-thres 0.25邏輯說明--iou-thres 0.5對應(yīng) mAP0.5這是檢測任務(wù)里最常用的主指標(biāo)--conf-thres 0.25是置信度閾值只在評估時影響預(yù)測輸出數(shù)量不影響 mAP 計(jì)算本身。參數(shù)說明里還有一類指標(biāo)是 mAP0.5:0.95它把 IoU 閾值從 0.5 到 0.95 按步長 0.05 取平均更嚴(yán)苛也更能反映邊框回歸精度。我建議自定義數(shù)據(jù)集上至少看 mAP0.5如果這個值上不去優(yōu)先檢查 anchors 和數(shù)據(jù)格式而不是調(diào)學(xué)習(xí)率。5. 訓(xùn)練避坑清單MobileNet-YOLO 常見的四個翻車現(xiàn)場組合型項(xiàng)目因?yàn)樯婕暗慕Y(jié)構(gòu)多出問題時很難一眼定位。下面四條是我在這些項(xiàng)目上遇到最多、也最容易被誤判的問題每條按現(xiàn)象、原因、解決三步展開。5.1 損失在降mAP 卻一直接近零現(xiàn)象訓(xùn)練 50 個 epoch 后 loss 已經(jīng)從 10 降到 2 左右看起來模型在收斂但驗(yàn)證集 mAP 始終是 0 或者不到 0.01。原因最常見的是 anchors 沒重算。自定義數(shù)據(jù)集中目標(biāo)尺寸和公共數(shù)據(jù)集相差太大默認(rèn) anchors 與真實(shí)框的平均 IoU 全部低于正樣本閾值導(dǎo)致訓(xùn)練過程中幾乎沒有正樣本參與回歸。第二個常見原因是輸入分辨率太低比如原圖 800×800輸入設(shè)為 320小目標(biāo)在特征圖上只占不到一個像素。解決先跑一次第四章的 K-means 聚類把結(jié)果寫進(jìn)配置并檢查順序然后把輸入分辨率提高到 416如果顯存壓力大就保持 416 但減小 batch size。這兩步做完后如果 mAP 還在零附近去檢查數(shù)據(jù)路徑是否指向了錯誤的 txt 文件我見過有人訓(xùn)練集里混入大量空標(biāo)注圖片導(dǎo)致正樣本數(shù)量被稀釋。5.2 訓(xùn)練到一半直接 CUDA out of memory現(xiàn)象訓(xùn)練前面幾個 epoch 正常到某個 epoch 突然報(bào)顯存不足或者 batch size 從 16 調(diào)到 32 后加載數(shù)據(jù)階段就崩。原因一個常見原因是訓(xùn)練策略里開啟了多尺度訓(xùn)練輸入尺寸在 320 到 640 之間隨機(jī)切換碰到大批次加高分辨率顯存峰值翻倍。另一個原因是驗(yàn)證階段把整張圖直接送進(jìn)模型沒有做尺度限制驗(yàn)證集里出現(xiàn)超長圖時顯存直接打滿。解決優(yōu)先開梯度累積把有效 batch size 保持住顯存峰值降下來。做法是在優(yōu)化器更新前累積多個 batch 的梯度accumulate 4 # 等價于 batch_size * 4 optimizer.zero_grad() loss.backward() if (step 1) % accumulate 0: optimizer.step() scheduler.step()邏輯說明梯度累積不是把 batch 拼大而是把梯度等權(quán)疊加后再更新一次權(quán)重效果上近似大 batch 訓(xùn)練。參數(shù)說明里accumulate一般設(shè) 2 到 8太大容易導(dǎo)致 BN 統(tǒng)計(jì)值滯后模型收斂變慢。如果顯存還是不夠再把輸入分辨率從 416 降到 384這一步對輕量骨干的 mAP 損失小于減小 batch size。另外檢查一下訓(xùn)練代碼是否開啟了混合精度torch.cuda.amp能把顯存占用再壓下一截。5.3 換 backbone 后權(quán)重加載報(bào)錯loss 直接變 NaN現(xiàn)象配置里把骨干從 mobilenetv2 改成 mobilenetv3加載之前保存的權(quán)重時報(bào) shape mismatch去掉預(yù)訓(xùn)練權(quán)重后從零訓(xùn)練loss 前幾步正常隨后漲到 NaN。原因不同版本的骨干結(jié)構(gòu)差異導(dǎo)致權(quán)重文件不兼容這不是 bug而是預(yù)期行為。另一個更隱蔽的原因是數(shù)據(jù)預(yù)處理的歸一化參數(shù)不一致v1/v2 統(tǒng)一用 ImageNet 的均值標(biāo)準(zhǔn)差v3 有些實(shí)現(xiàn)會按論文里的均值重新調(diào)整兩者混用會讓批量歸一化層的統(tǒng)計(jì)值瞬間混亂梯度爆炸。解決換骨干后不要嘗試加載舊骨干的權(quán)重重新準(zhǔn)備對應(yīng)版本的 ImageNet 預(yù)訓(xùn)練文件。從零訓(xùn)練時把學(xué)習(xí)率降到 0.0001同時強(qiáng)烈建議把freeze_backbone從 0 改為至少 10讓檢測頭在骨干參數(shù)不動的情況下先穩(wěn)定下來。最后對照配置文件檢查歸一化參數(shù)transforms.Normalize( mean[0.485, 0.456, 0.406], # ImageNet 標(biāo)準(zhǔn)參數(shù) std[0.229, 0.224, 0.225] )參數(shù)說明這三個值幾乎是所有視覺骨干通用的輸入歸一化參數(shù)如果你的配置里寫的是[0, 0, 0]和[1, 1, 1]說明跳過歸一化直接訓(xùn)練這種情況更容易觸發(fā) NaN尤其是在加載預(yù)訓(xùn)練骨干權(quán)重時。5.4 訓(xùn)練驗(yàn)證正常單獨(dú)推理時檢測結(jié)果亂飄現(xiàn)象訓(xùn)練集 mAP 和驗(yàn)證集 mAP 都正常但把模型放到視頻里做單幀推理時檢測框位置抖動明顯偶爾整幀漏檢CPU 上尤其嚴(yán)重。原因推理代碼沒有調(diào)用model.eval()。這個問題的本質(zhì)是批量歸一化層還在按訓(xùn)練模式工作單張圖片推理時 BN 用當(dāng)前 batch 的統(tǒng)計(jì)值而不是全局統(tǒng)計(jì)值而 batch1 的統(tǒng)計(jì)方差極大特征分布被嚴(yán)重扭曲。輕量骨干對 BN 擾動更敏感因?yàn)樗闹虚g特征通道數(shù)更少。解決推理前強(qiáng)制切換模型狀態(tài)并關(guān)閉梯度計(jì)算model.eval() # 關(guān)閉 BN 的 batch 統(tǒng)計(jì)更新 with torch.no_grad(): preds model(img)邏輯說明model.eval()讓所有 BatchNorm 層改用訓(xùn)練時保存的全局均值和方差這是一行代碼遺漏掉就是玄學(xué)。參數(shù)說明里還有一個細(xì)節(jié)如果推理服務(wù)是多線程的每個線程都必須拿到自己的模型副本不要多個線程共享同一個 model 實(shí)例否則 eval 狀態(tài)的切換會相互干擾出現(xiàn)偶發(fā)亂飄。6. 推理優(yōu)化與部署技巧ONNX 導(dǎo)出、int8 量化與一個基準(zhǔn)測試習(xí)慣模型訓(xùn)練好后如果你只在 PyTorch 環(huán)境里驗(yàn)證那還沒有真正落地。這一章是部署前最值得花時間的部分。6.1 用 ONNX 做跨設(shè)備推理輕量模型也要跑通用格式PyTorch 模型直接部署會遇到版本綁定問題換臺機(jī)器就可能因?yàn)榄h(huán)境版本不一致而無法加載。先導(dǎo)出 ONNX后面無論是轉(zhuǎn)其他推理框架還是做混合精度優(yōu)化都會方便很多。導(dǎo)出代如下import torch model build_model(cfg) model.load_state_dict(torch.load(weights/best.pt, map_locationcpu)) model.eval() dummy torch.randn(1, 3, 416, 416) torch.onnx.export( model, dummy, mobilenet_yolo.onnx, input_names[input], output_names[boxes, scores], dynamic_axes{input: {0: batch}, boxes: {0: batch}, scores: {0: batch}}, opset_version12, )邏輯說明導(dǎo)出前必須model.eval()否則 BN 層會被當(dāng)作訓(xùn)練模式導(dǎo)出推理結(jié)果和你驗(yàn)證時不一致。參數(shù)說明里dynamic_axes只把 batch 維度設(shè)成動態(tài)保持寬高為固定 416這樣在部分專用推理引擎上能得到更好的算子優(yōu)化。導(dǎo)出后用 ONNX Runtime 做一次推理和 PyTorch 的預(yù)測結(jié)果對比如果兩類結(jié)果的 box 坐標(biāo)差異超過 1%大概率是導(dǎo)出時把后處理邏輯重復(fù)計(jì)算了或者是 eval 狀態(tài)沒設(shè)置正確。6.2 int8 量化把模型體積和速度再壓一檔MobileNet 骨干在 CPU 上的全精度推理已經(jīng)不錯了但真正上邊緣設(shè)備int8 量化帶來的收益仍然明顯。速度提升通常在 1.5 到 3 倍之間模型體積直接縮小到四分之一。用 PyTorch 自帶的動態(tài)量化可以快速驗(yàn)證一下可行性import torch model_quantized torch.quantization.quantize_dynamic( model, {torch.nn.Linear, torch.nn.Conv2d}, dtypetorch.qint8, )邏輯說明動態(tài)量化只把權(quán)重轉(zhuǎn)成 int8激活值仍然按 float 計(jì)算實(shí)現(xiàn)成本最低。參數(shù)說明里有個關(guān)鍵點(diǎn)量化后必須重新跑一遍完整驗(yàn)證集不能只看幾條樣本。輕量骨干的精度余量本來就小量化掉 1 到 3 個 mAP 點(diǎn)是平均水平如果你的任務(wù)本身對精確框位要求高建議改用量化感知訓(xùn)練在訓(xùn)練階段就模擬量化誤差最后的精度損失會明顯小很多。6.3 一個基準(zhǔn)測試習(xí)慣固定視頻段測 200 幀平均時間很多人在 GPU 上測完幀率就覺得完成了但 MobileNet-YOLO 的價值恰恰體現(xiàn)在目標(biāo)設(shè)備上兩者幀率差距可能有十倍。我的習(xí)慣是準(zhǔn)備一段固定 10 秒左右的視頻包含不同目標(biāo)尺度和光照變化每次優(yōu)化后都跑同一段視頻統(tǒng)計(jì) 200 幀的平均耗時。import time import cv2 import torch cap cv2.VideoCapture(benchmark.mp4) times [] model.eval() with torch.no_grad(): for i in range(200): ret, frame cap.read() if not ret: break img preprocess(frame).unsqueeze(0) t0 time.time() preds model(img) times.append(time.time() - t0) avg_ms sum(times) / len(times) * 1000 print(favg latency: {avg_ms:.1f} ms, fps: {1000 / avg_ms:.1f})邏輯說明統(tǒng)計(jì)的是端到端推理耗時不包括視頻解碼和預(yù)處理因?yàn)檫@兩部分受硬件影響太大分開測才能定位瓶頸。參數(shù)說明里preprocess必須和訓(xùn)練時的預(yù)處理完全一致包括 resize 方式、歸一化參數(shù)、通道順序否則測出來的幀率沒有參考價值。我每次做完一個部署方案都會把這份基準(zhǔn)結(jié)果和當(dāng)時的模型配置、量化配置一起存檔。下次換方案時直接對比記錄而不是靠記憶。希望這個習(xí)慣能幫到你也歡迎你在自己的項(xiàng)目里試試這套組合輕量骨干加 YOLO 檢測頭真正跑起來之后你會對它有個全新的認(rèn)識。本文還有配套的精品資源點(diǎn)擊獲取 MobileNet-YOLO輕量化目標(biāo)檢測實(shí)戰(zhàn)：結(jié)構(gòu)、訓(xùn)練與部署指南
簡介面向目標(biāo)檢測算法研究與輕量化部署場景這份PyTorch實(shí)現(xiàn)的MobileNet-YOLO檢測網(wǎng)絡(luò)資源覆蓋MobilenetV1/V2/V3與YOLOv3/YOLOv4系列模型適合需要對比主干網(wǎng)絡(luò)與檢測頭組合效果的算法工程師和研究生。損失函數(shù)與原始實(shí)現(xiàn)保持一致模型在VOC20072012上訓(xùn)練并在VOC2007上測試權(quán)重采用ImageNet預(yù)訓(xùn)練使用方式貼近原始YOLO可直接沿用其數(shù)據(jù)準(zhǔn)備、訓(xùn)練與評估流程。資源包為zip格式共29個文件大小約240KB包含16個Python腳本模型結(jié)構(gòu)、訓(xùn)練、推理、mAP評估、圖像增強(qiáng)等、5個shell腳本數(shù)據(jù)集下載、lmdb創(chuàng)建、訓(xùn)練、推理、2個YAML配置數(shù)據(jù)路徑與參數(shù)、說明文檔與許可證以及若干示例圖片目錄劃分清楚便于按模塊復(fù)用。已有1944人學(xué)習(xí)/下載。通過該資源可完整復(fù)現(xiàn)輕量化檢測器的訓(xùn)練與推理流程掌握VOC數(shù)據(jù)集預(yù)處理和lmdb轉(zhuǎn)換的細(xì)節(jié)同時可參考eval_mAP、圖像增強(qiáng)等工具腳本快速遷移到自有目標(biāo)檢測任務(wù)中。1. 從跑不動到流暢檢測MobileNet-YOLO-Pytorch 的價值被很多人低估了MobileNet-YOLO-Pytorch 這個項(xiàng)目名看著很長但本質(zhì)很直接把 MobileNet 系列v1/v2/v3當(dāng)作骨干網(wǎng)絡(luò)后端接 YOLO 系列YOLOv3/YOLOv4的檢測頭形成一套可以在 CPU 和嵌入式設(shè)備上實(shí)際跑起來的檢測方案。很多人第一反應(yīng)是“這不就是個縫合怪嗎”但真正在邊緣設(shè)備上部署過的人會明白這一步縫合解決的是實(shí)打?qū)嵉目ú弊訂栴}。我之前在某個項(xiàng)目里要在一個低功耗盒子上跑實(shí)時檢測原版 YOLOv3 的 DarkNet 骨干一幀推理要 400 多毫秒整個業(yè)務(wù)沒法落地。后來把骨干換成 MobileNet同樣的檢測頭推理時間直接降到 50 毫秒檔位精度損失遠(yuǎn)沒有想象中大。這套組合的適用人群很明確手頭有檢測需求、設(shè)備算力受限、又不想從零設(shè)計(jì)網(wǎng)絡(luò)結(jié)構(gòu)的人。接下來我會按“結(jié)構(gòu)原理 → 環(huán)境與訓(xùn)練 → 自定義數(shù)據(jù)適配 → 避坑 → 部署優(yōu)化”這條線展開把我自己踩過的坑和驗(yàn)證過的參數(shù)習(xí)慣都放進(jìn)去。這篇文章適合兩類讀者第一次接觸輕量化目標(biāo)檢測的新手可以直接按步驟復(fù)現(xiàn)已經(jīng)跑過 YOLO 訓(xùn)練的老手可以重點(diǎn)看第五、六章那里有最容易被忽略的細(xì)節(jié)。2. 網(wǎng)絡(luò)結(jié)構(gòu)與代碼組織為什么 MobileNet 能和 YOLO 自由組合先說結(jié)論YOLO 的檢測頭并不綁定特定骨干它對骨干網(wǎng)絡(luò)的依賴主要體現(xiàn)為“尺度數(shù)量、下采樣倍數(shù)、輸出通道”這三件事。MobileNet 系列恰好在這三件事上滿足要求所以組合是順理成章的而不是靠硬改代碼堆出來的。2.1 MobileNet 三代的核心結(jié)構(gòu)差異深度可分離卷積、倒殘差與 NASMobileNet v1 的核心貢獻(xiàn)是深度可分離卷積。常規(guī)卷積同時做空間特征提取和通道融合計(jì)算量是k×k×C_in×C_out拆開之后先用一個k×k的深度卷積只處理每個通道內(nèi)的空間信息再用1×1卷積做跨通道融合計(jì)算量降到k×k×C_in C_in×C_out在 3×3 卷積下大約是原來的九分之一到八分之一。這個思路后來幾乎成了所有輕量骨干的標(biāo)配。MobileNet v2 在 v1 基礎(chǔ)上加了倒殘差結(jié)構(gòu)和線性瓶頸。倒殘差的順序是先1×1擴(kuò)張通道再做深度卷積最后1×1壓縮回來通道數(shù)從窄到寬再到窄。設(shè)計(jì)動機(jī)是 ReLU 對低維特征會產(chǎn)生信息截?cái)嗨栽谄款i層輸出處用線性激活代替 ReLU。如果骨干輸出特征圖的維度已經(jīng)很低你要注意這一點(diǎn)后續(xù)接入檢測頭時盡量不要再人為壓縮通道。MobileNet v3 引入了神經(jīng)架構(gòu)搜索不再完全靠手工設(shè)計(jì)結(jié)構(gòu)。它在 v2 的基礎(chǔ)上加了輕量級注意力模塊 SE同時把網(wǎng)絡(luò)尾部幾個冗余卷積層直接刪掉激活函數(shù)換成了 h-swish。這幾個改動疊加起來讓 v3 在相同精度下體積比 v2 更小、延遲更低。下面這張表格可以快速對比三代的核心差異版本核心結(jié)構(gòu)主要收益明顯代價v1深度可分離卷積計(jì)算量大幅降低通道間信息融合弱精度一般v2倒殘差 線性瓶頸低維特征保留更好精度提升先擴(kuò)張后壓縮內(nèi)存訪問略增v3NAS 搜索 SE h-swish體積更小速度更快結(jié)構(gòu)碎片化部分硬件不友好選 v1 還是 v3取決于你的底線在哪里。我的習(xí)慣是CPU 上跑選 v3-large追求極致體積選 v3-small想在老設(shè)備上穩(wěn)定兼容選 v2。2.2 YOLO 檢測頭對骨干網(wǎng)絡(luò)的三個硬性要求YOLOv3 和 YOLOv4 的檢測頭不接收單個特征圖而是接收三個不同尺度的特征圖。以 416×416 輸入為例三個特征圖尺寸分別是 13×13、26×26、52×52對應(yīng)下采樣 32 倍、16 倍、8 倍。因此骨干網(wǎng)絡(luò)必須能輸出三個尺度的特征這是第一個硬性要求。第二個要求是特征圖的通道數(shù)不能太低。YOLO 檢測頭會在每個尺度上執(zhí)行一系列卷積如果骨干輸出的通道數(shù)過少信息會過早坍縮小目標(biāo)直接檢測不到。MobileNet v2 最后幾個 bottleneck 的輸出通道通常在 96、192、320 這個量級接入檢測頭時通過1×1卷積做通道對齊語義信息不會丟失太多。第三個要求是感受野要覆蓋到足夠大的范圍。YOLO 在 13×13 這樣低分辨率的特征圖上檢測大目標(biāo)單個點(diǎn)對應(yīng)的感受野必須接近整個輸入圖像。MobileNet 雖然全程使用小卷積核但通過多次下采樣積累了足夠的感受野這一點(diǎn)實(shí)測下來是滿足的。如果骨干替換后大目標(biāo)漏檢嚴(yán)重問題往往出在疊加大卷積核或空洞卷積的位置沒配對。2.3 配置驅(qū)動替換骨干三個組合的代碼路徑是怎樣的這種整合項(xiàng)目的代碼組織方式通常不是“每種組合維護(hù)一套模型文件”而是由一個模型構(gòu)建函數(shù)統(tǒng)一加載配置按 key 去實(shí)例化骨干和檢測頭。我一般會在配置里區(qū)分model.backbone和model.detector兩個字段這樣切換組合時只改配置不動模型代碼。model: backbone: mobilenetv3-large # v1 / v2 / v3-small 均可 backbone_pretrained: weights/mbv3_large.pth detector: yolov3 # yolov3 或 yolov4 num_classes: 20 input_size: 416 anchors: - [10, 13, 16, 30, 33, 23] - [30, 61, 62, 45, 59, 119] - [116, 90, 156, 198, 373, 326]上面的 anchors 列表來自公共數(shù)據(jù)集上的默認(rèn)值換自定義數(shù)據(jù)集時必須要重算這一點(diǎn)在第四章展開。模型構(gòu)建的核心邏輯一般長這樣def build_model(cfg): backbone create_backbone( cfg[model][backbone], pretrainedcfg[model][backbone_pretrained], ) detector create_detector( cfg[model][detector], num_classescfg[model][num_classes], anchorscfg[model][anchors], ) return MobileYOLO(backbone, detector) class MobileYOLO(torch.nn.Module): def __init__(self, backbone, detector): super().__init__() self.backbone backbone self.detector detector def forward(self, x): c1, c2, c3 self.backbone(x) # stride 32 / 16 / 8 return self.detector([c1, c2, c3])邏輯說明create_backbone返回的是三個層的輸出不是單個最終特征圖。create_detector接收一個列表然后在內(nèi)部做特征融合和預(yù)測分支計(jì)算。參數(shù)說明里最需要注意的是 anchors 的層級順序列表第一組對應(yīng) 13×13 大尺度特征圖最后一組對應(yīng) 52×52 小尺度特征圖順序?qū)懛磿霈F(xiàn)小目標(biāo)檢測不到但大目標(biāo)正常這種詭異現(xiàn)象。3. 最小可復(fù)現(xiàn)訓(xùn)練流程環(huán)境配置、參數(shù)修改與首輪訓(xùn)練很多人拿到這類項(xiàng)目先急著改網(wǎng)絡(luò)結(jié)構(gòu)結(jié)果環(huán)境都沒跑通。我建議先按默認(rèn)配置完整跑一遍訓(xùn)練再動結(jié)構(gòu)不遲。3.1 環(huán)境版本選擇PyTorch、CUDA 與依賴的匹配關(guān)系這類輕量檢測項(xiàng)目對 PyTorch 版本不算挑剔但有幾個匹配關(guān)系要留意。我實(shí)測下來PyTorch 1.8 到 2.x 都能正常跑通區(qū)別主要體現(xiàn)在兩方面老版本對新顯卡的自適應(yīng)支持差一些新版本在舊顯卡上偶爾會提示算子不可用。# 建議先裝 PyTorch 主庫再裝其余依賴 pip install torch1.10.0 torchvision0.11.0 # 其余依賴一次裝齊 pip install numpy opencv-python pyyaml tqdm邏輯說明torchvision 只在加載 ImageNet 預(yù)訓(xùn)練骨干時用到如果你打算從零訓(xùn)練檢測頭torchvision 可以不裝少一個版本扯皮的地方。參數(shù)說明openvc-python 負(fù)責(zé)數(shù)據(jù)增強(qiáng)里的圖像讀取和縮放pyyaml 負(fù)責(zé)解析配置文件tqdm 只影響進(jìn)度條顯示裝不裝不影響訓(xùn)練結(jié)果。有一個環(huán)境相關(guān)的提醒如果你的顯卡驅(qū)動只支持 CUDA 10.2不要硬裝 PyTorch 2.x它默認(rèn)編譯的 CUDA 版本更高運(yùn)行時會報(bào)驅(qū)動不兼容。遇到這種情況先nvidia-smi看驅(qū)動版本再反推 PyTorch 版本不要倒過來。3.2 三組關(guān)鍵參數(shù)骨干系數(shù)、輸入分辨率與訓(xùn)練超參訓(xùn)練前首先要確定的是輸入分辨率。416 是這類項(xiàng)目的默認(rèn)平衡點(diǎn)608 能提升小目標(biāo) mAP但推理時間幾乎翻倍320 適合追求速度的場景mAP 比 416 低 2 到 5 個點(diǎn)。我的建議是訓(xùn)練用 416部署到邊緣設(shè)備時再用 320 做一次測試如果精度落在可接受范圍就用 320 推理。train: input_size: 416 # 320 / 416 / 608訓(xùn)練和驗(yàn)證保持一致 batch_size: 16 # 顯存不足時優(yōu)先降到 8而不是調(diào)低分辨率 epochs: 200 lr: 0.001 lr_scheduler: cosine warmup_epochs: 3 freeze_backbone: 20 # 前 20 個 epoch 凍結(jié)骨干只訓(xùn)練檢測頭參數(shù)說明freeze_backbone非常關(guān)鍵。MobileNet 骨干如果隨機(jī)初始化需要大量數(shù)據(jù)才能學(xué)到通用特征加載 ImageNet 預(yù)訓(xùn)練權(quán)重后前 20 個 epoch 凍結(jié)骨干讓檢測頭先適應(yīng)特征分布之后再解凍聯(lián)合調(diào)優(yōu)。warmup_epochs在前 3 輪把學(xué)習(xí)率從 0 線性升到目標(biāo)值能有效避免前幾個 batch 的 loss 劇烈波動。cosine調(diào)度器配合 200 個 epoch收斂曲線比 step 下降更平滑。3.3 一條命令跑通訓(xùn)練從預(yù)訓(xùn)練權(quán)重到 loss 輸出依賴裝好、配置改完訓(xùn)練命令本身很簡單。關(guān)鍵在于權(quán)重文件的位置和命名很多項(xiàng)目運(yùn)行的報(bào)錯都是因?yàn)闄?quán)重路徑配置成了相對路徑而當(dāng)前工作目錄不對。python train.py \ --cfg cfg/mobilenetv3_yolov3.yaml \ --data data/custom.data \ --weights weights/mbv3_large_imagenet.pth \ --epochs 200 \ --batch-size 16邏輯說明--cfg指向模型結(jié)構(gòu)配置--data指向數(shù)據(jù)列表文件--weights是骨干預(yù)訓(xùn)練權(quán)重。參數(shù)說明里的data/custom.data是一個文本文件內(nèi)容通常是classes3 traindata/train.txt valdata/val.txt namesdata/custom.names其中train.txt每行是一張訓(xùn)練圖片的絕對路徑。如果這個文件里混入了不存在的路徑訓(xùn)練時會跳過對應(yīng)圖片跑完才發(fā)現(xiàn)數(shù)據(jù)量少了一半這種錯誤很隱蔽。首輪訓(xùn)練建議只跑 30 個 epoch 做驗(yàn)證看 loss 是否在穩(wěn)步下降同時確認(rèn) loss 量級在正常范圍而不是追求一輪跑完。日志里出現(xiàn)loss: 4.2這種數(shù)值是正常的代表初始預(yù)測還不夠準(zhǔn)等檢測頭訓(xùn)練充分后會降到 1 以下。4. 自定義數(shù)據(jù)集訓(xùn)練格式轉(zhuǎn)換、anchors 重算與收斂驗(yàn)證用公共數(shù)據(jù)集訓(xùn)練只是驗(yàn)證環(huán)境真正要落地必須換成自己的數(shù)據(jù)。這一章講清楚從標(biāo)注文件到訓(xùn)練驗(yàn)證的完整鏈路。4.1 把標(biāo)注數(shù)據(jù)轉(zhuǎn)成訓(xùn)練格式最不容易丟坐標(biāo)的腳本標(biāo)注工具導(dǎo)出最多的格式是 Pascal VOC 的 XML適合做數(shù)據(jù)管理但訓(xùn)練通常要的是 YOLO 格式的 TXT。轉(zhuǎn)換腳本不復(fù)雜但有三個地方容易出錯歸一化坐標(biāo)算錯、小目標(biāo)坐標(biāo)被整除丟精度、類別索引和名稱對不上。import os import xml.etree.ElementTree as ET from PIL import Image def voc_to_yolo(xml_path, img_dir, out_dir, class_map): tree ET.parse(xml_path) root tree.getroot() img_name root.find(filename).text img_w, img_h Image.open(os.path.join(img_dir, img_name)).size lines [] for obj in root.iter(object): cls_name obj.find(name).text box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) cx (x1 x2) / 2 / img_w cy (y1 y2) / 2 / img_h bw (x2 - x1) / img_w bh (y2 - y1) / img_h lines.append(f{class_map[cls_name]} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) out_name img_name.rsplit(., 1)[0] .txt with open(os.path.join(out_dir, out_name), w) as f: f.write(\n.join(lines))邏輯說明核心是先把左上角和右下角坐標(biāo)轉(zhuǎn)成中心點(diǎn)加寬高再除以圖片寬高做歸一化。參數(shù)說明里最容易踩的坑是坐標(biāo)字段在部分工具里會導(dǎo)出成整數(shù)或字符串必須顯式轉(zhuǎn)成 float否則除法的結(jié)果會變成 0小目標(biāo)直接從訓(xùn)練集里消失。4.2 用 K-means 為你的數(shù)據(jù)集重算 anchors而不是硬用默認(rèn)值YOLO 的默認(rèn) anchors 是在特定數(shù)據(jù)分布上聚類出來的直接用在自定義數(shù)據(jù)集上典型結(jié)果是訓(xùn)練正常、loss 正常但小目標(biāo) mAP 極低。原因在于預(yù)置 anchors 尺寸與真實(shí)目標(biāo)尺寸的交并比太小訓(xùn)練時無法選出正樣本。解決辦法是重新聚類。import numpy as np def iou_wh(wh, cluster): min_wh np.minimum(wh, cluster[:, None, :]) inter min_wh[..., 0] * min_wh[..., 1] union wh[..., 0] * wh[..., 1] cluster[:, None, :][..., 0] * cluster[:, None, :][..., 1] - inter return inter / np.maximum(union, 1e-6) def kmeans_anchors(wh_list, k9, iters300): wh_list np.asarray(wh_list, dtypenp.float64) clusters wh_list[np.random.choice(len(wh_list), k, replaceFalse)] for _ in range(iters): iou iou_wh(wh_list, clusters) assign np.argmax(iou, axis1) new_clusters np.zeros_like(clusters) for i in range(k): selected wh_list[assign i] if len(selected) 0: new_clusters[i] selected.mean(axis0) else: new_clusters[i] clusters[i] if np.allclose(clusters, new_clusters): break clusters new_clusters return clusters[np.argsort(clusters[:, 0] * clusters[:, 1])]邏輯說明K-means 聚類的距離度量使用 IoU 距離即d 1 - IoU(box, centroid)這樣聚類結(jié)果與檢測框的交并比直接相關(guān)。參數(shù)說明里k9對應(yīng) YOLOv3/v4 的九組 anchors太小會導(dǎo)致正樣本選擇不平衡太大反而在訓(xùn)練時增加回歸難度。聚類完成后把結(jié)果按面積從大到小排列前三個分給 13×13 特征圖中間三個分給 26×26最后三個分給 52×52然后寫回配置文件。4.3 訓(xùn)練中怎么判斷真的收斂了用 mAP 而不是 loss 曲線訓(xùn)練到后期會看到 loss 還在緩慢下降但 mAP 已經(jīng)不再提升。loss 下降代表回歸損失還在優(yōu)化但如果正負(fù)樣本比例失衡loss 里的分類損失被負(fù)樣本主導(dǎo)mAP 不漲就是典型的無效訓(xùn)練。所以收斂判斷必須依賴驗(yàn)證集指標(biāo)。python val.py \ --cfg cfg/mobilenetv3_yolov3.yaml \ --data data/custom.data \ --weights weights/best.pt \ --iou-thres 0.5 \ --conf-thres 0.25邏輯說明--iou-thres 0.5對應(yīng) mAP0.5這是檢測任務(wù)里最常用的主指標(biāo)--conf-thres 0.25是置信度閾值只在評估時影響預(yù)測輸出數(shù)量不影響 mAP 計(jì)算本身。參數(shù)說明里還有一類指標(biāo)是 mAP0.5:0.95它把 IoU 閾值從 0.5 到 0.95 按步長 0.05 取平均更嚴(yán)苛也更能反映邊框回歸精度。我建議自定義數(shù)據(jù)集上至少看 mAP0.5如果這個值上不去優(yōu)先檢查 anchors 和數(shù)據(jù)格式而不是調(diào)學(xué)習(xí)率。5. 訓(xùn)練避坑清單MobileNet-YOLO 常見的四個翻車現(xiàn)場組合型項(xiàng)目因?yàn)樯婕暗慕Y(jié)構(gòu)多出問題時很難一眼定位。下面四條是我在這些項(xiàng)目上遇到最多、也最容易被誤判的問題每條按現(xiàn)象、原因、解決三步展開。5.1 損失在降mAP 卻一直接近零現(xiàn)象訓(xùn)練 50 個 epoch 后 loss 已經(jīng)從 10 降到 2 左右看起來模型在收斂但驗(yàn)證集 mAP 始終是 0 或者不到 0.01。原因最常見的是 anchors 沒重算。自定義數(shù)據(jù)集中目標(biāo)尺寸和公共數(shù)據(jù)集相差太大默認(rèn) anchors 與真實(shí)框的平均 IoU 全部低于正樣本閾值導(dǎo)致訓(xùn)練過程中幾乎沒有正樣本參與回歸。第二個常見原因是輸入分辨率太低比如原圖 800×800輸入設(shè)為 320小目標(biāo)在特征圖上只占不到一個像素。解決先跑一次第四章的 K-means 聚類把結(jié)果寫進(jìn)配置并檢查順序然后把輸入分辨率提高到 416如果顯存壓力大就保持 416 但減小 batch size。這兩步做完后如果 mAP 還在零附近去檢查數(shù)據(jù)路徑是否指向了錯誤的 txt 文件我見過有人訓(xùn)練集里混入大量空標(biāo)注圖片導(dǎo)致正樣本數(shù)量被稀釋。5.2 訓(xùn)練到一半直接 CUDA out of memory現(xiàn)象訓(xùn)練前面幾個 epoch 正常到某個 epoch 突然報(bào)顯存不足或者 batch size 從 16 調(diào)到 32 后加載數(shù)據(jù)階段就崩。原因一個常見原因是訓(xùn)練策略里開啟了多尺度訓(xùn)練輸入尺寸在 320 到 640 之間隨機(jī)切換碰到大批次加高分辨率顯存峰值翻倍。另一個原因是驗(yàn)證階段把整張圖直接送進(jìn)模型沒有做尺度限制驗(yàn)證集里出現(xiàn)超長圖時顯存直接打滿。解決優(yōu)先開梯度累積把有效 batch size 保持住顯存峰值降下來。做法是在優(yōu)化器更新前累積多個 batch 的梯度accumulate 4 # 等價于 batch_size * 4 optimizer.zero_grad() loss.backward() if (step 1) % accumulate 0: optimizer.step() scheduler.step()邏輯說明梯度累積不是把 batch 拼大而是把梯度等權(quán)疊加后再更新一次權(quán)重效果上近似大 batch 訓(xùn)練。參數(shù)說明里accumulate一般設(shè) 2 到 8太大容易導(dǎo)致 BN 統(tǒng)計(jì)值滯后模型收斂變慢。如果顯存還是不夠再把輸入分辨率從 416 降到 384這一步對輕量骨干的 mAP 損失小于減小 batch size。另外檢查一下訓(xùn)練代碼是否開啟了混合精度torch.cuda.amp能把顯存占用再壓下一截。5.3 換 backbone 后權(quán)重加載報(bào)錯loss 直接變 NaN現(xiàn)象配置里把骨干從 mobilenetv2 改成 mobilenetv3加載之前保存的權(quán)重時報(bào) shape mismatch去掉預(yù)訓(xùn)練權(quán)重后從零訓(xùn)練loss 前幾步正常隨后漲到 NaN。原因不同版本的骨干結(jié)構(gòu)差異導(dǎo)致權(quán)重文件不兼容這不是 bug而是預(yù)期行為。另一個更隱蔽的原因是數(shù)據(jù)預(yù)處理的歸一化參數(shù)不一致v1/v2 統(tǒng)一用 ImageNet 的均值標(biāo)準(zhǔn)差v3 有些實(shí)現(xiàn)會按論文里的均值重新調(diào)整兩者混用會讓批量歸一化層的統(tǒng)計(jì)值瞬間混亂梯度爆炸。解決換骨干后不要嘗試加載舊骨干的權(quán)重重新準(zhǔn)備對應(yīng)版本的 ImageNet 預(yù)訓(xùn)練文件。從零訓(xùn)練時把學(xué)習(xí)率降到 0.0001同時強(qiáng)烈建議把freeze_backbone從 0 改為至少 10讓檢測頭在骨干參數(shù)不動的情況下先穩(wěn)定下來。最后對照配置文件檢查歸一化參數(shù)transforms.Normalize( mean[0.485, 0.456, 0.406], # ImageNet 標(biāo)準(zhǔn)參數(shù) std[0.229, 0.224, 0.225] )參數(shù)說明這三個值幾乎是所有視覺骨干通用的輸入歸一化參數(shù)如果你的配置里寫的是[0, 0, 0]和[1, 1, 1]說明跳過歸一化直接訓(xùn)練這種情況更容易觸發(fā) NaN尤其是在加載預(yù)訓(xùn)練骨干權(quán)重時。5.4 訓(xùn)練驗(yàn)證正常單獨(dú)推理時檢測結(jié)果亂飄現(xiàn)象訓(xùn)練集 mAP 和驗(yàn)證集 mAP 都正常但把模型放到視頻里做單幀推理時檢測框位置抖動明顯偶爾整幀漏檢CPU 上尤其嚴(yán)重。原因推理代碼沒有調(diào)用model.eval()。這個問題的本質(zhì)是批量歸一化層還在按訓(xùn)練模式工作單張圖片推理時 BN 用當(dāng)前 batch 的統(tǒng)計(jì)值而不是全局統(tǒng)計(jì)值而 batch1 的統(tǒng)計(jì)方差極大特征分布被嚴(yán)重扭曲。輕量骨干對 BN 擾動更敏感因?yàn)樗闹虚g特征通道數(shù)更少。解決推理前強(qiáng)制切換模型狀態(tài)并關(guān)閉梯度計(jì)算model.eval() # 關(guān)閉 BN 的 batch 統(tǒng)計(jì)更新 with torch.no_grad(): preds model(img)邏輯說明model.eval()讓所有 BatchNorm 層改用訓(xùn)練時保存的全局均值和方差這是一行代碼遺漏掉就是玄學(xué)。參數(shù)說明里還有一個細(xì)節(jié)如果推理服務(wù)是多線程的每個線程都必須拿到自己的模型副本不要多個線程共享同一個 model 實(shí)例否則 eval 狀態(tài)的切換會相互干擾出現(xiàn)偶發(fā)亂飄。6. 推理優(yōu)化與部署技巧ONNX 導(dǎo)出、int8 量化與一個基準(zhǔn)測試習(xí)慣模型訓(xùn)練好后如果你只在 PyTorch 環(huán)境里驗(yàn)證那還沒有真正落地。這一章是部署前最值得花時間的部分。6.1 用 ONNX 做跨設(shè)備推理輕量模型也要跑通用格式PyTorch 模型直接部署會遇到版本綁定問題換臺機(jī)器就可能因?yàn)榄h(huán)境版本不一致而無法加載。先導(dǎo)出 ONNX后面無論是轉(zhuǎn)其他推理框架還是做混合精度優(yōu)化都會方便很多。導(dǎo)出代如下import torch model build_model(cfg) model.load_state_dict(torch.load(weights/best.pt, map_locationcpu)) model.eval() dummy torch.randn(1, 3, 416, 416) torch.onnx.export( model, dummy, mobilenet_yolo.onnx, input_names[input], output_names[boxes, scores], dynamic_axes{input: {0: batch}, boxes: {0: batch}, scores: {0: batch}}, opset_version12, )邏輯說明導(dǎo)出前必須model.eval()否則 BN 層會被當(dāng)作訓(xùn)練模式導(dǎo)出推理結(jié)果和你驗(yàn)證時不一致。參數(shù)說明里dynamic_axes只把 batch 維度設(shè)成動態(tài)保持寬高為固定 416這樣在部分專用推理引擎上能得到更好的算子優(yōu)化。導(dǎo)出后用 ONNX Runtime 做一次推理和 PyTorch 的預(yù)測結(jié)果對比如果兩類結(jié)果的 box 坐標(biāo)差異超過 1%大概率是導(dǎo)出時把后處理邏輯重復(fù)計(jì)算了或者是 eval 狀態(tài)沒設(shè)置正確。6.2 int8 量化把模型體積和速度再壓一檔MobileNet 骨干在 CPU 上的全精度推理已經(jīng)不錯了但真正上邊緣設(shè)備int8 量化帶來的收益仍然明顯。速度提升通常在 1.5 到 3 倍之間模型體積直接縮小到四分之一。用 PyTorch 自帶的動態(tài)量化可以快速驗(yàn)證一下可行性import torch model_quantized torch.quantization.quantize_dynamic( model, {torch.nn.Linear, torch.nn.Conv2d}, dtypetorch.qint8, )邏輯說明動態(tài)量化只把權(quán)重轉(zhuǎn)成 int8激活值仍然按 float 計(jì)算實(shí)現(xiàn)成本最低。參數(shù)說明里有個關(guān)鍵點(diǎn)量化后必須重新跑一遍完整驗(yàn)證集不能只看幾條樣本。輕量骨干的精度余量本來就小量化掉 1 到 3 個 mAP 點(diǎn)是平均水平如果你的任務(wù)本身對精確框位要求高建議改用量化感知訓(xùn)練在訓(xùn)練階段就模擬量化誤差最后的精度損失會明顯小很多。6.3 一個基準(zhǔn)測試習(xí)慣固定視頻段測 200 幀平均時間很多人在 GPU 上測完幀率就覺得完成了但 MobileNet-YOLO 的價值恰恰體現(xiàn)在目標(biāo)設(shè)備上兩者幀率差距可能有十倍。我的習(xí)慣是準(zhǔn)備一段固定 10 秒左右的視頻包含不同目標(biāo)尺度和光照變化每次優(yōu)化后都跑同一段視頻統(tǒng)計(jì) 200 幀的平均耗時。import time import cv2 import torch cap cv2.VideoCapture(benchmark.mp4) times [] model.eval() with torch.no_grad(): for i in range(200): ret, frame cap.read() if not ret: break img preprocess(frame).unsqueeze(0) t0 time.time() preds model(img) times.append(time.time() - t0) avg_ms sum(times) / len(times) * 1000 print(favg latency: {avg_ms:.1f} ms, fps: {1000 / avg_ms:.1f})邏輯說明統(tǒng)計(jì)的是端到端推理耗時不包括視頻解碼和預(yù)處理因?yàn)檫@兩部分受硬件影響太大分開測才能定位瓶頸。參數(shù)說明里preprocess必須和訓(xùn)練時的預(yù)處理完全一致包括 resize 方式、歸一化參數(shù)、通道順序否則測出來的幀率沒有參考價值。我每次做完一個部署方案都會把這份基準(zhǔn)結(jié)果和當(dāng)時的模型配置、量化配置一起存檔。下次換方案時直接對比記錄而不是靠記憶。希望這個習(xí)慣能幫到你也歡迎你在自己的項(xiàng)目里試試這套組合輕量骨干加 YOLO 檢測頭真正跑起來之后你會對它有個全新的認(rèn)識。本文還有配套的精品資源點(diǎn)擊獲取