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