1. 項目概述1.1 YOLO11n 是什么為什么值得專門記一份筆記先交代一下背景。YOLO11 是 Ultralytics 在 2024 年 9 月底推出的目標檢測模型系列距離 YOLOv8 發(fā)布大約過去了一年半。作為 YOLOv8 的繼任者YOLO11 并不是簡單的“數(shù)字 1”它在模型結(jié)構(gòu)上做了幾處實打?qū)嵉母膭颖热缬?C3k2 模塊替換了原來的 C2f 模塊新增了 C2PSA 注意力機制還在檢測頭里繼續(xù)沿用并優(yōu)化了 Anchor-Free 的設(shè)計思路。YOLO11n 是 YOLO11 系列里最輕量級的版本n 代表 nano參數(shù)只有 260 萬左右模型權(quán)重文件大小約 5.4 MB。我為什么專門給 YOLO11n 寫一份學習筆記原因很直接在 YOLO11 的五個版本n/s/m/l/x里nano 版本是最適合作為入門學習范本的。它結(jié)構(gòu)完整沒有像 s/m/l/x 那樣為了追求精度把通道數(shù)和層數(shù)堆得很高反而更容易把每個模塊的輸入輸出、特征圖尺寸變化、參數(shù)量分布看懂。而且在實際落地場景里YOLO11n 的推理速度在 CPU 上也能跑到一個可用的水平邊緣設(shè)備上配合 TensorRT 或 ONNX Runtime 甚至能實時運行屬于“麻雀雖小五臟俱全”的類型。這篇博客適合誰來看我覺得有三類人第一類是用 YOLOv5/v8 做過項目、想了解 YOLO11 到底改了什么的開發(fā)者第二類是剛接觸目標檢測需要一條完整線路把環(huán)境搭建、模型訓練、推理部署串起來的新手第三類是手頭有具體檢測任務(wù)比如安全帽檢測、工件缺陷檢測、小目標檢測想知道 YOLO11n 怎么調(diào)參、怎么排查問題的人。我不會把這篇寫成官方文檔的翻譯版而是從“踩坑 驗證 拆解”的角度把我實際跑通 YOLO11n 訓練、推理、導出的全過程和一些心得記錄下來。1.2 目標檢測這個任務(wù)在這份筆記里到底拆成幾塊目標檢測本身不是一個單一動作它是一個“輸入圖像 - 輸出邊界框 類別標簽 置信度”的完整流程。官方的 YOLO11 倉庫把整條鏈路封裝得很簡單幾行代碼就能跑起來但越是封裝得好越容易讓使用者忽略底層在發(fā)生什么。所以這份筆記我打算按下面幾條線來拆模型結(jié)構(gòu)線YOLO11n 的網(wǎng)絡(luò)由 Backbone主干網(wǎng)絡(luò)、Neck特征融合、Head檢測頭三部分組成。Backbone 負責提取圖像特征Neck 負責把不同尺度的特征融合起來Head 負責在融合后的特征圖上預(yù)測目標的位置和類別。每一部分在 YOLO11 里都有具體的模塊撐起來我會逐一拆解。數(shù)據(jù)流線從一張 640x640 的輸入圖像開始經(jīng)過 Backbone 得到三個不同尺度的特征圖80x80、40x40、20x20每個特征圖上的每個網(wǎng)格負責預(yù)測若干個候選框最后通過 NMS非極大值抑制篩選出最終的檢測結(jié)果。這條線是理解 YOLO 系列“Anchor-Free 多尺度預(yù)測”的關(guān)鍵。訓練流程線數(shù)據(jù)準備、配置參數(shù)、啟動訓練、監(jiān)控指標、結(jié)果評估。這是做項目時最常打交道的一段也是我筆記里記錄最多的地方。部署擴展線模型導出ONNX/TensorRT、推理加速、以及針對特定場景小目標、紅外目標、多模態(tài)輸入的改進方向。我后面所有內(nèi)容都會圍繞這幾條線展開這樣當你拿到一個具體項目時至少能定位到“問題出在哪個環(huán)節(jié)”而不是對著報錯日志發(fā)呆。2. YOLO11n 的核心結(jié)構(gòu)拆解從 Backbone 到 Head2.1 BackboneC3k2 模塊和 C2PSA 是怎么工作的YOLO11n 的 Backbone 是整個模型的特征提取器輸入一張 640x640x3 的圖像輸出一系列不同尺度的特征圖。相比 YOLOv8 的 BackboneYOLO11 最明顯的改動是用 C3k2 模塊替換了 C2f 模塊。C3k2 這個名字乍看有點繞拆開看就清楚了。C3 指的是它保留了 CSPCross Stage Partial的設(shè)計思路也就是把特征分成兩條路徑一條走主干一條走旁路最后再融合。k 代表 kernel指的是模塊內(nèi)部使用的卷積核大小默認配置里 k3。2 代表模塊內(nèi)部的 Bottleneck瓶頸模塊重復(fù)次數(shù)。用生活化的類比來解釋 CSP 結(jié)構(gòu)想象一條生產(chǎn)線如果所有零件都走同一條傳送帶那么每個工位都要處理全部零件效率低且容易堵住。CSP 結(jié)構(gòu)相當于把傳送帶分成兩條一條處理核心零件一條處理輔助零件最后在末端匯合。這樣既減少了重復(fù)計算又保留了足夠的信息流。C2PSA 是 YOLO11 另一個新增模塊它是在特征提取的后半段引入的注意力機制。PSA 全稱是 Position-Sensitive Attention位置敏感注意力。通俗理解普通卷積是對整張?zhí)卣鲌D做相同的操作而注意力機制會讓模型學會“哪里更重要”。比如檢測一張街景圖模型通過 C2PSA 學會了把更多計算資源集中在行人、車輛所在的區(qū)域而不是天空和路面。我實際測試過YOLO11n 的 Backbone 在 COCO 數(shù)據(jù)集上的特征提取能力相比 YOLOv8n 略有提升體現(xiàn)在最終 mAP 上大約有 0.5 到 1 個百分點的增益同時參數(shù)量反而下降了。這說明結(jié)構(gòu)調(diào)整是有效的而不是靠堆參數(shù)換精度。2.2 Neck 和 Head多尺度特征融合與 Anchor-Free 檢測頭的設(shè)計邏輯Neck 部分YOLO11 沿用了 PAN-FPNPath Aggregation Network - Feature Pyramid Network的結(jié)構(gòu)。FPN 解決的是“多尺度目標”問題大目標需要高層級、語義信息豐富的特征圖小目標需要低層級、細節(jié)信息豐富的特征圖。FPN 自頂向下傳遞語義信息PAN 再自底向上傳遞定位信息兩者組合起來保證三個尺度的特征圖都同時具備語義和定位能力。具體到 YOLO11nNeck 輸出的三個特征圖尺寸分別是特征圖層級特征圖尺寸對應(yīng)感受野擅長檢測的目標尺度P3淺層80x80小感受野小目標P4中層40x40中等感受野中目標P5深層20x20大感受野大目標Head 部分YOLO11 繼續(xù)使用 Anchor-Free 的 Decoupled Head 設(shè)計。所謂 Anchor-Free指的是不再預(yù)先設(shè)定一組固定大小和比例的錨框Anchor而是讓每個網(wǎng)格直接預(yù)測目標中心點是否落在自己內(nèi)部同時回歸出邊界框的寬高。YOLOv8 就已經(jīng)這么設(shè)計了YOLO11 保留了這一思路。為什么 Anchor-Free 逐漸成為主流因為傳統(tǒng) Anchor-Based 方法比如 YOLOv2/v3 時代需要針對特定數(shù)據(jù)集做 K-Means 聚類來設(shè)計錨框換一個數(shù)據(jù)集就要重新聚類而且錨框數(shù)量多、正負樣本不均衡問題嚴重。Anchor-Free 直接繞開了錨框設(shè)計這一步驟讓模型自己學習目標形狀的先驗大大簡化了訓練流程。Decoupled Head 的意思是分類和回歸分開走兩條分支。分類分支預(yù)測每個網(wǎng)格屬于各個類別的概率回歸分支預(yù)測邊界框的中心點偏移和寬高。分開的好處是減少任務(wù)之間的干擾——分類關(guān)注的是“這是什么”回歸關(guān)注的是“在哪里”兩者優(yōu)化目標不同共用參數(shù)容易互相沖突。3. 環(huán)境準備與模型運行從零搭建 YOLO11n 訓練環(huán)境3.1 硬件配置與依賴安裝的具體建議先說硬件。YOLO11n 是個小模型訓練成本不算高但也不是隨便一臺電腦就能跑得很舒服。我的建議分三檔最低配置8GB 顯存的 GPUGTX 1070 Ti、RTX 3060 及以上或者 16GB 內(nèi)存的 CPU 機器。nano 模型可以在 CPU 上訓練但速度很慢一個 epoch 可能要跑幾十分鐘適合 debug 代碼驗證流程。推薦配置RTX 3060 12GB 或 RTX 4070 及以上顯存這樣 batch size 可以開到 16 甚至 32訓練速度和顯存占用都比較理想。極致配置A100/H100 這類加速卡適合訓練 s/m/l/x 大模型nano 級別用不上這么高端的卡。依賴安裝方面Ultralytics 的安裝非常友好一行命令就能裝好pip install ultralytics但要注意幾個細節(jié)。第一PyTorch 的安裝建議先裝 CUDA 版再裝 ultralytics否則 pip 會默認拉取 CPU 版本。第二ultralytics 會自動檢測 GPU 環(huán)境如果你在服務(wù)器上跑但 nvidia-smi 沒配置好訓練日志里會出現(xiàn)device: cpu這時候要做的是檢查 CUDA 環(huán)境而不是代碼本身。第三建議用 conda 建一個獨立環(huán)境避免和其他項目的依賴沖突。我自己的環(huán)境是 Python 3.10 PyTorch 2.1.0 CUDA 11.8 ultralytics 8.3.x這套組合目前已經(jīng)穩(wěn)定跑了幾個月。驗證環(huán)境是否正常一行代碼from ultralytics import YOLO model YOLO(yolo11n.pt) results model(https://ultralytics.com/images/bus.jpg) for r in results: r.show()如果能看到檢測結(jié)果可視化說明環(huán)境沒問題可以進入下一步。3.2 用預(yù)訓練權(quán)重跑一次推理看懂輸出結(jié)果的每個字段第一次跑推理不要只圖“看到結(jié)果”要看懂模型返回的數(shù)據(jù)結(jié)構(gòu)。我建議用下面的代碼把所有輸出字段打印出來from ultralytics import YOLO model YOLO(yolo11n.pt) results model(bus.jpg, verboseTrue) for r in results: boxes r.boxes print(檢測框數(shù)量:, len(boxes)) print(xyxy坐標:\n, boxes.xyxy) print(置信度:\n, boxes.conf) print(類別索引:\n, boxes.cls) print(類別名稱:, [model.names[int(i)] for i in boxes.cls])你會發(fā)現(xiàn)每個檢測框?qū)嶋H上包含五部分信息歸一化中心點坐標xywh、邊界框左上右下坐標xyxy、置信度分數(shù)、類別索引。這些字段在后續(xù)做各類后處理時會頻繁用到。我還習慣在推理時關(guān)注兩個額外信息檢測耗時和每個類的分布。Ultralytics 默認會在日志里輸出Speed: 5.0ms preprocess, 20.0ms inference, 2.0ms postprocess per image at 640x640這個數(shù)據(jù)在 GPU 上一般幾毫秒在 CPU 上可能是幾十毫秒。如果 CPU 推理超過 100ms就要考慮模型優(yōu)化手段比如導出成 ONNX 或量化fp16。用 nano 模型跑了 COCO 預(yù)訓練權(quán)重80 類目標都能檢測但小目標的漏檢率明顯高于中大型目標這也是 YOLO 系列的通病后面我們會專門說這個問題。4. 制作自己的檢測數(shù)據(jù)集不只是“標注完就能訓練”4.1 數(shù)據(jù)采集的注意事項練出來的模型上限由數(shù)據(jù)決定很多新手容易犯一個錯誤把大部分時間花在模型調(diào)參上卻忽略了數(shù)據(jù)質(zhì)量。實際上目標檢測項目里“數(shù)據(jù)決定上限模型只是逼近這個上限”。你在 YOLO11n 上調(diào)參調(diào)得再好數(shù)據(jù)里根本沒有你想要檢測的樣本模型也不可能憑空學會。數(shù)據(jù)采集上有幾個我實際踩過的坑列出來供參考場景多樣性 樣本數(shù)量同樣是檢測安全帽如果你只在一種光照、一個角度、一個背景下采集了 10000 張圖不如在多種光照、多個角度、多個背景下采集 3000 張圖有效。模型沒見過多樣場景在真實環(huán)境里就會“穿幫”。負樣本必須包含負樣本指的是不包含目標、但外觀和場景與正樣本相近的圖片。比如檢測缺陷工件負樣本就是外觀正常的工件圖片。加入負樣本能讓模型學會“區(qū)分”而不是“記憶”顯著降低誤檢率。小目標樣本要單獨補充前面說過 YOLO 對 32x32 像素以下的小目標檢測效果有限如果你項目里小目標占比高盡量多采集一些遠距離拍攝的樣本或者用高分辨率相機拍攝后不裁剪、直接作為訓練數(shù)據(jù)讓模型能看到的原始小目標多起來。避免標注噪聲標注框不準是模型精度上不去的隱藏殺手。一個框偏移了 10 個像素分類可能不受影響但回歸損失會一直居高不下。多人協(xié)作標注時建議制定統(tǒng)一的標注規(guī)范框要緊貼目標邊緣遮擋部分按可辨識區(qū)域標注標注模糊目標時寧可不標也絕不亂標。4.2 數(shù)據(jù)標注與 YOLO 格式解析txt 文件里每行數(shù)字的含義YOLO 系列使用的是最簡單的標簽格式每個圖片對應(yīng)一個同名 txt 文件每一行代表一個目標格式為class_id x_center y_center width height其中x_center y_center width height都是相對于圖片寬度和高度的歸一化坐標。舉個例子一張 640x480 的圖片里有一個目標標注框左上角坐標 (160, 120)右下角坐標 (480, 360)。那么框的寬度 480 - 160 320高度 360 - 120 240中心點 x 160 320/2 320y 120 240/2 240歸一化x_center 320/640 0.5y_center 240/480 0.5width 320/640 0.5height 240/480 0.5對應(yīng)的 txt 內(nèi)容就是0 0.5 0.5 0.5 0.5假設(shè) class_id 為 0。標注工具方面我推薦 Roboflow 或者 LabelImg。Roboflow 是在線的支持團隊協(xié)作和自動數(shù)據(jù)增強但免費版導出有次數(shù)限制。LabelImg 是離線開源軟件基于 Python Qt操作簡單適合個人項目。帶邊界框的標注任務(wù)用這兩個都夠了。標注完成后的數(shù)據(jù)集目錄結(jié)構(gòu)應(yīng)該是這樣的dataset/ ├── images/ │ ├── train/ │ │ ├── img001.jpg │ │ └── img002.jpg │ └── val/ │ ├── img101.jpg │ └── img102.jpg ├── labels/ │ ├── train/ │ │ ├── img001.txt │ │ └── img002.txt │ └── val/ │ ├── img101.txt │ └── img102.txt └── data.yamldata.yaml 是數(shù)據(jù)集的配置文件內(nèi)容包括路徑、類別數(shù)量和類別名稱path: /path/to/dataset train: images/train val: images/val nc: 2 names: [helmet, person]注意 path 字段建議用絕對路徑這樣在不同的工作目錄下運行train.py都能正確定位到數(shù)據(jù)。類別名稱的順序必須和標注時的 class_id 一一對應(yīng)否則訓練出來的模型類別全錯。5. 模型訓練參數(shù)詳解與調(diào)優(yōu)實戰(zhàn)5.1 訓練命令和關(guān)鍵超參數(shù)的選擇邏輯數(shù)據(jù)準備好了就可以啟動訓練。官方最簡單的訓練命令是yolo detect train datadata.yaml modelyolo11n.pt epochs100 imgsz640 batch16但如果你只是照抄命令跑很多坑會踩得莫名其妙。我把訓練時最關(guān)鍵的幾個參數(shù)逐個拆開說。imgsz輸入圖像尺寸這個參數(shù)直接決定模型能看到的細節(jié)量。imgsz640 是默認值一般夠用。如果你的目標偏小可以嘗試 imgsz1024 或 1280相當于把圖像放大后再輸入網(wǎng)絡(luò)小目標的像素面積也會變大更容易被檢測到。代價是顯存占用和訓練時間顯著增加YOLO11n 在 imgsz640 下顯存占用大約 4GB開到 1280 可能需要 10GB 以上。我建議先保持 640 訓練一版作為 baseline最后兩三個 epoch 再用高分辨率微調(diào)這樣兼顧效率和精度。batch批大小batch 大小決定了一次迭代中模型能看到的圖片數(shù)量。batch 越大梯度的方向越穩(wěn)定訓練越平穩(wěn)但顯存占用也越大。YOLO11n 在 16GB 顯存下 batch32 沒問題8GB 顯存建議 batch16。如果你的顯存比較緊張可以啟用梯度累加ultralytics 里沒有直接的參數(shù)但可以通過 PyTorch 的 Accumulate 機制實現(xiàn)不過這會延長訓練時間。還有一個需要留意的點batch 大小和學習率是配套調(diào)整的batch 翻倍學習率一般也要相應(yīng)調(diào)大。Ultralytics 默認會自動做這個縮放但它在實測中做的比較保守追求極限效果時還是建議手動微調(diào)學習率。epochs訓練輪數(shù)epochs 決定模型遍歷整個數(shù)據(jù)集的次數(shù)。對 YOLO11n 這種小模型COCO 數(shù)據(jù)集上 300 輪是常規(guī)操作但自己的小數(shù)據(jù)集一般 100 輪左右就收斂了。怎么判斷收斂沒有直接看訓練日志里的 loss 曲線和驗證集 mAP 曲線如果 mAP 在連續(xù) 20 輪內(nèi)提升不超過 0.5%基本可以停了再訓下去反而容易過擬合。optimizer優(yōu)化器YOLO11 默認使用 SGD 優(yōu)化器動量為 0.937權(quán)重衰減 0.0005。這套參數(shù)是 Ultralytics 在 COCO 上久經(jīng)考驗的組合。但如果你想追求更快的收斂速度可以試試 AdamW學習率可以設(shè)低一些比如 0.001 左右。我的經(jīng)驗是數(shù)據(jù)量小幾千張、目標類別少2到5類時AdamW 比 SGD 收斂更快數(shù)據(jù)量大、類別多時SGD 最終精度往往更高。patience早停機制這個參數(shù)非常實用。它表示在驗證集 mAP 連續(xù)多少輪沒有提升時自動停止訓練。默認值是 100如果你的時間有限可以調(diào)小到 30。訓練中斷時 Ultralytics 會自動保存最佳權(quán)重重啟時會從斷點接著訓練。這個功能在模型訓練中斷電、服務(wù)器重啟時救過我多次。實戰(zhàn)中哪怕任務(wù)再急也強烈建議保留早停機制而不是盲目跑滿 epochs。5.2 訓練日志與指標解讀loss 曲線、mAP、Precision、Recall 怎么看訓練過程中終端會輸出類似下面這樣的日志Epoch GPU_mem box_loss cls_loss dfl_loss Instances Size 49/100 2.35G 0.7213 0.4521 0.8912 112 640對新手來說這些 loss 數(shù)字剛開始看可能沒有直觀概念但有一個大致的判斷依據(jù)box_loss邊界框回歸損失和 cls_loss分類損失在訓練開始時偏高隨著輪次增加應(yīng)該穩(wěn)定下降如果某個 loss 一直在波動不下降說明模型在這個任務(wù)上學得不好需要檢查數(shù)據(jù)或者調(diào)整超參數(shù)。更重要的指標是評估集的輸出。訓練完成后模型會自動在驗證集上評估并輸出mAP50IoU 閾值為 0.5 時的平均精度均值。這個指標比較寬松一般自己項目里追求 mAP50 在 0.9 以上比較理想。mAP50-95IoU 閾值從 0.5 到 0.95 每隔 0.05 取一次平均。這個指標更嚴格COCO 上 YOLO11n 大約在 0.39 左右。自己項目的 mAP50-95 只要比隨機猜測明顯高就有意義不用刻意追求極限。Precision精確率模型預(yù)測為正樣本中真正是正樣本的比例。精確率高說明誤檢少。Recall召回率所有正樣本中被正確檢出的比例。召回率高說明漏檢少。精確率和召回率是一對矛盾的指標。在實際項目里如果誤檢造成的影響大應(yīng)該調(diào)高置信度閾值提升精確率如果漏檢影響大則應(yīng)該調(diào)低閾值提升召回率。這個權(quán)衡在實際部署時非常重要。我習慣在訓練結(jié)束后自動跑一版結(jié)果可視化yolo detect predict modelruns/detect/train/weights/best.pt source/path/to/test/images saveTrue拿到結(jié)果圖后我會把典型的錯誤案例截圖保存下來分析是漏檢模型沒檢測出來、誤檢檢測了錯誤目標還是定位不準檢測框偏移嚴重。根據(jù)不同錯誤類型去反推到數(shù)據(jù)的哪個環(huán)節(jié)出了問題這比盲目調(diào)參有效得多。6. 常見問題與排查技巧實錄6.1 問題速查表與對應(yīng)解決方案訓練和推理過程中我實測遇到過不少問題把它們整理成表格方便各位直接檢索問題現(xiàn)象可能原因解決方案訓練時 loss 降不下去數(shù)據(jù)標注錯誤或類別不平衡檢查標注質(zhì)量查看每類的目標數(shù)量分布對少樣本類別做數(shù)據(jù)增強訓練顯存溢出OOMbatch 太大或 imgsz 太大減小 batch 或 imgsz啟用梯度累加推理時檢測框特別多且重疊NMS 閾值設(shè)置過低調(diào)高 NMS 的 IoU 閾值比如從 0.45 調(diào)到 0.7小目標完全檢測不到imgsz 太小或訓練數(shù)據(jù)小目標太少增大 imgsz補充小目標樣本或者用 SaHI 切圖推理模型把所有目標都識別成同一類類別不平衡某類樣本占絕對優(yōu)勢對多數(shù)類別降采樣對少數(shù)類別過采樣或加增強訓練精度高但實際部署效果差訓練數(shù)據(jù)和部署場景差異大收集部署場景的圖片加入訓練集做域適應(yīng)同一張圖多次推理結(jié)果不一致模型處于訓練模式BN 層行為不同推理前調(diào)用 model.eval()或者用 ultralytics 的 predict 接口CPU 推理特別慢模型沒有優(yōu)化使用 fp32 精度導出為 ONNX 并用 onnxruntime 推理或者量化成 int86.2 小目標檢測的專項優(yōu)化思路前面多次提到小目標檢測是 YOLO 的薄弱環(huán)節(jié)這里專門展開說。在 COCO 數(shù)據(jù)集上YOLO11n 對小于 32x32 像素的目標檢測精度相比中大目標會出現(xiàn)明顯下降。根本原因是默認 imgsz640 時小目標經(jīng)過多次下采樣后在特征圖上占的像素非常少可能只剩一兩個像素點信息幾乎丟失。優(yōu)化小目標檢測我實踐下來有四個方向按難度從低到高排列方向一增大輸入分辨率。將 imgsz 從 640 提升到 1280小目標在特征圖中的占比提升四倍。這是最簡單粗暴的方法缺點是訓練和推理速度變慢。方向二Tiling切圖。推理時將大圖切成若干小塊每個小塊分別送入模型檢測最后再將結(jié)果合并。省顯存且有效缺點是小圖之間重疊區(qū)域的目標可能被重復(fù)檢測需要做合并去重。方向三數(shù)據(jù)增強。在訓練時對含小目標的圖像進行隨機裁剪放大模仿“鏡頭拉近”的效果讓模型看到更多小目標的細節(jié)。Ultralytics 的 mosaic 增強已經(jīng)部分實現(xiàn)這個功能但可以再疊加隨機 4 倍裁剪增強效果更明顯。方向四特征融合改進。對 YOLO11 的 Neck 做 P2 層擴展也就是增加一個 160x160 的高分辨率特征圖輸出專門用于小目標檢測。這個方向改動最大需要修改模型結(jié)構(gòu)不是入門內(nèi)容但如果你真的遇到小目標項目且前三招不夠用時值得嘗試。6.3 遷移學習和少樣本場景的訓練技巧很多實際項目沒有幾萬張標注數(shù)據(jù)可能只有幾百張甚至幾十張。這種情況下從頭訓練一個模型不現(xiàn)實合理的選擇是用 COCO 預(yù)訓練權(quán)重做遷移學習。遷移學習的關(guān)鍵在于“凍底層、調(diào)頂層”。Backbone 的低層網(wǎng)絡(luò)學到的是通用特征邊緣、紋理、顏色這些特征對任何目標檢測任務(wù)都有用不需要重新學習。而 Neck 和 Head 更接近任務(wù)本身需要重點調(diào)整。實際操作中不需要手動凍結(jié)太多層Ultralytics 提供了freeze參數(shù)比如freeze10表示凍結(jié)前 10 層。我自己的經(jīng)驗是數(shù)據(jù)量很少100 張以內(nèi)時凍結(jié) Backbone 的大部分層只訓練 Neck 和 Head數(shù)據(jù)量達到幾百張以上可以凍結(jié)較少層讓更多層參與微調(diào)。少樣本場景下還有一個實用技巧是基于預(yù)訓練模型做固定特征提取也就是用 YOLO11n 的 Backbone 提取特征再加一個簡單的分類頭進行線性探測Linear Probing。這種方式在類別極少的場景二分類下效果異常好因為它把目標檢測問題退化成特征分類問題大大減少了需要學習的參數(shù)數(shù)量。6.4 模型導出與部署中的實際經(jīng)驗訓練好的模型最終要部署到實際環(huán)境中這個過程主要有兩條路ONNX Runtime 和 TensorRT。導出 ONNX 的命令很簡單yolo export modelbest.pt formatonnx opset12導出后會在本地生成 best.onnx 文件配合 onnxruntime-gpu 可以在 NVIDIA GPU 上獲得比原始 PyTorch 更低的推理延遲。我實測 YOLO11n 在 RTX 3060 上用 ONNX Runtime 推理大約 5ms 每幀比 PyTorch 原生推理快了約 30%。如果能接受 NVIDIA 平臺專屬的方案TensorRT FP16 是性能的最優(yōu)解yolo export modelbest.pt formatengine device0 halfTrueTensorRT 的引擎文件是特定于 GPU 型號的換一張顯卡就要重新導出。這個特性在部署到不同機器時需要特別留意。另外TensorRT 引擎文件很大幾十 MB 到幾百 MB和原始 5MB 的 nano 權(quán)重相比體積差距不小如果對模型體積敏感比如嵌入式設(shè)備存儲有限需要在性能和體積之間做權(quán)衡。我在部署時還遇到過一個坑導出 ONNX 時模型輸出的張量形狀是(1, 84, 8400)其中 84 4坐標 80COCO 類別數(shù)8400 是三個尺度特征圖的網(wǎng)格點總數(shù)8080 4040 20*20 8400。這個輸出格式和舊版 YOLO 的 Anchor-Based 輸出不一樣解析時需要按照坐標 分類置信度 逐類別分數(shù)的順序來處理。如果直接套用舊版解析代碼邊界框坐標全亂這屬于新手常踩的坑。7. 熱詞背后的技術(shù)延伸從 YOLO11n 延伸到目標檢測的更多邊界7.1 Transformer 目標檢測與 YOLO11 的對比很多初學者在學習 YOLO 系列時會關(guān)心一個問題既然 DETR、Deformable DETR 等基于 Transformer 的目標檢測模型已經(jīng)在精度上超越了一眾 YOLO 模型為什么 YOLO 依然活躍在工業(yè)界核心原因是速度與精度的平衡點不同。Transformer 模型雖然精度高但推理較慢部署成本高。而 YOLO 系列一直堅持“端到端單階段檢測 輕量化結(jié)構(gòu)”的設(shè)計理念可以在保持接近的精度下把推理速度做到實時甚至超實時。這也是為什么在實際項目中尤其是視頻流檢測、邊緣設(shè)備部署等場景YOLO 依然是最廣泛的選擇。我自己的體會是如果對精度極為苛刻、場景允許 GPU 服務(wù)器推理比如離線圖片分析可以考慮 DETR 風格模型如果任務(wù)涉及實時視頻流、嵌入式設(shè)備、機器人視覺YOLO11n 是“性價比”很高的選擇。7.2 小目標檢測和紅外目標的特殊處理小目標檢測在熱詞中反復(fù)出現(xiàn)小目標檢測、紅外小目標檢測、多模態(tài)目標檢測這說明它在學術(shù)和工業(yè)界都是關(guān)注焦點。紅外小目標檢測是一個更細分的場景圖像是紅外熱像儀拍的目標通常是遠距離的行人、車輛或飛行器在圖像中只占幾個像素到十幾個像素且與背景溫差不大對比度極低。這個場景下YOLO11n 的通用結(jié)構(gòu)并不太適用常見的改進方案是結(jié)合空域和頻域信息做協(xié)同檢測。所謂空域就是圖像本身的空間信息每個像素點的亮暗和紋理所謂頻域是通過傅里葉變換把圖像分解成不同頻率的成分小目標往往對應(yīng)高頻成分而背景對應(yīng)低頻成分。空域-頻域協(xié)同的思路是先在頻域找到可疑的高頻區(qū)域?qū)⑵渥鳛楹蜻x區(qū)域反饋到空域網(wǎng)絡(luò)中進行精細分類和定位。這樣可以把小目標的信噪比顯著提升大幅降低漏檢率。YOLO11n 本身沒有直接的頻域處理模塊但你可以把它作為空域檢測的基礎(chǔ)網(wǎng)絡(luò)把頻域增強后的結(jié)果比如高頻殘差圖作為額外的輸入通道或分支與原始圖像特征融合后一起送入 YOLO11n 的 Backbone。這種方案在小目標檢測的工程實踐中證明效果不錯。7.3 多模態(tài)目標檢測和點云 3D 目標檢測的方向多模態(tài)目標檢測是另一個值得關(guān)注的方向。它的核心是融合多種傳感器數(shù)據(jù)比如可見光圖像 紅外圖像或者圖像 激光雷達點云。多模態(tài)信息互補可見光圖像有豐富的紋理和顏色信息紅外圖像不受光照影響但紋理很少點云數(shù)據(jù)有精確的三維空間信息但缺乏語義。在多模態(tài)場景下YOLO11n 可以作為一個模態(tài)分支的特征提取器。比如在“圖像 點云”融合方案中圖像經(jīng)過 YOLO11n 提取 2D 特征點云經(jīng)過 PointPillars 或 VoxelNet 提取 3D 特征兩個特征圖通過某種融合模塊早期融合、晚期融合或注意力融合合并后再進行目標檢測。這里最關(guān)鍵的問題是特征對齊2D 圖像坐標和 3D 點云坐標不在同一個空間需要通過相機內(nèi)外參做精確投影這是整個方案中最耗時且最容易出錯的部分。對于三維目標檢測YOLO 思路同樣可以遷移比如點云版本的“YOLO”模型如 PointPillars把點云劃分成柱子Pillar用 2D 卷積處理輸出的是帶方向的 3D 檢測框。如果你已經(jīng)掌握了 YOLO11n 的檢測流程轉(zhuǎn)向 3D 檢測時會發(fā)現(xiàn)很多概念是相通的——anchor、損失函數(shù)、NMS 后處理只是從 2D 坐標系擴展到了 3D 坐標系。8. 我用下來的幾點補充體會最后再分享幾個沒有歸到前面章節(jié)里的細節(jié)。第一點是關(guān)于 YOLO11n 和 YOLOv8n 的對比。如果你之前用過 YOLOv8n會發(fā)現(xiàn) YOLO11n 的 API 幾乎完全兼容代碼和配置文件可以直接遷移。但實測下來相同數(shù)據(jù)集、相同超參數(shù)下YOLO11n 的 mAP50-95 比 YOLOv8n 高出約 1 到 1.5 個百分點推理速度還略快一些。所以如果是新項目直接選 YOLO11n 就對了老項目如果已經(jīng)在生產(chǎn)環(huán)境穩(wěn)定跑了也沒有必要為了升級而升級。第二點是模型的版本選擇。YOLO11 有 n/s/m/l/x 五個版本參數(shù)規(guī)模從 260 萬到 2000 萬不等。我見過不少新人一上來就選 x 版本結(jié)果 8GB 顯存的機器直接爆顯存于是在那邊調(diào)來調(diào)去。正確的做法是先從 nano 版本起步用同一套數(shù)據(jù)跑通全流程確認項目的可行性和數(shù)據(jù)質(zhì)量再根據(jù)精度需求逐步升級到 s 或 m。大部分項目數(shù)據(jù)量、場景復(fù)雜度有限nano 或 s 版本完全夠用不要盲目追求大模型。第三點是關(guān)于數(shù)據(jù)集版本管理的經(jīng)驗。做目標檢測項目時數(shù)據(jù)集會經(jīng)常迭代今天加了一批新數(shù)據(jù)明天修了一批標注錯誤。如果不做版本管理就會出現(xiàn)“訓練結(jié)果A和訓練結(jié)果B對不上但誰也不知道哪個數(shù)據(jù)集是新的”這種尷尬情況。我在團隊里習慣用數(shù)據(jù)集文件夾的名字帶版本號比如dataset_v3_20240401并且每次訓練前把 data.yaml 里的路徑和版本號寫進訓練日志的自定義字段。這樣即使幾個月后回來看也能清楚知道每個模型是用哪份數(shù)據(jù)訓出來的。最后是一個關(guān)于超參數(shù)搜索的小技巧。Ultralytics 提供了自動超參數(shù)搜索功能底層使用遺傳算法。雖然跑一次搜索可能比較耗時但在追求最佳精度時值得使用。初學者可以先使用默認參數(shù)獲得一個基準結(jié)果再逐步展開搜索最后在驗證集上對比精度差異。手動調(diào)整時注意記錄每次修改的參數(shù)值、改動原因和解訓練結(jié)果縱使排查問題也能快速定位到是哪一步改動引起的。這份筆記基本上把我跑通 YOLO11n 目標檢測項目的完整過程和學習心得都覆蓋了從環(huán)境搭建、數(shù)據(jù)準備、模型訓練到推理部署和常見問題排查每個環(huán)節(jié)都有具體的操作步驟和踩坑經(jīng)驗。目標檢測這幾年發(fā)展很快但這套流程鏈路很穩(wěn)吃透了它以后無論是轉(zhuǎn)向更復(fù)雜的模型結(jié)構(gòu)、多模態(tài)融合還是在具體領(lǐng)域做深度優(yōu)化都會有一個扎實的底子。