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