訓(xùn)練好的YOLO26權(quán)重文件躺在weights目錄里并不等于項(xiàng)目完成。真正決定一個(gè)計(jì)算機(jī)視覺項(xiàng)目能不能交差的往往是導(dǎo)出這一步。模型導(dǎo)出是把PyTorch權(quán)重轉(zhuǎn)換成ONNX、OpenVINO、TensorRT、CoreML這些部署格式的必經(jīng)之路也是連接訓(xùn)練和線上的“最后一公里”。導(dǎo)出做得穩(wěn)不穩(wěn)直接影響上線后的推理速度、硬件兼容性以及你凌晨三點(diǎn)被叫起來排查問題的概率。這篇內(nèi)容我就圍繞YOLO26的模型導(dǎo)出把環(huán)境準(zhǔn)備、命令拆解、主流格式實(shí)操、常見坑位和導(dǎo)出后的驗(yàn)證方式一次性講透適合正準(zhǔn)備把YOLO26模型部署到服務(wù)器、邊緣盒子或者嵌入式設(shè)備上的開發(fā)者。1. YOLO26的結(jié)構(gòu)更新給導(dǎo)出環(huán)節(jié)帶來了哪些新變量1.1 為什么“會(huì)用舊版導(dǎo)出命令”不等于會(huì)導(dǎo)YOLO26Ultralytics的導(dǎo)出機(jī)制從YOLOv5一路走到Y(jié)OLO26大方向上確實(shí)是一脈相承的都是通過model.export()這個(gè)入口來完成轉(zhuǎn)換。但這不代表你拿YOLOv8時(shí)代的導(dǎo)出腳本直接套在YOLO26上就能高枕無憂。我在YOLO11剛發(fā)布時(shí)就踩過教訓(xùn)。當(dāng)時(shí)圖省事直接復(fù)用v8的導(dǎo)出腳本導(dǎo)ONNX結(jié)果導(dǎo)出的模型在隨機(jī)輸入下能跑得通但用真實(shí)圖片推理時(shí)檢測(cè)框全部偏移最后排查了半天問題出在導(dǎo)出時(shí)自動(dòng)執(zhí)行的層融合fuse行為變了和舊版解碼邏輯對(duì)不上。YOLO26作為新版本內(nèi)部的基礎(chǔ)模塊、算子組合大概率也做了調(diào)整這意味著導(dǎo)出的計(jì)算圖結(jié)構(gòu)會(huì)和舊版有差異。所以別以為“命令一樣就萬(wàn)事大吉”每次新版本發(fā)布后都值得重新驗(yàn)證一遍完整的導(dǎo)出鏈路。此外YOLO26在結(jié)構(gòu)上確實(shí)有一些社區(qū)討論度很高的變化比如基礎(chǔ)模塊的替換、注意力機(jī)制的引入等。這些變化在PyTorch里訓(xùn)練時(shí)不太容易感知但一旦進(jìn)入ONNX或TensorRT的算子映射階段就可能出現(xiàn)“導(dǎo)出成功但推理報(bào)錯(cuò)”或“算子不支持”的情況。不定死某個(gè)具體算子名但結(jié)論很明確新結(jié)構(gòu) 新的算子兼容性測(cè)試這一步省不掉。1.2 任務(wù)維度擴(kuò)展depth等新任務(wù)進(jìn)入導(dǎo)出清單從最近搜索熱詞看“yolo26 depth”“yolo26 單相機(jī)測(cè)距 輸出距離”的關(guān)注度非常高這說明很多人在嘗試把YOLO26往深度估計(jì)方向推。和傳統(tǒng)的目標(biāo)檢測(cè)不同depth任務(wù)導(dǎo)出的模型輸出tensor的含義和形狀完全是另一套邏輯。檢測(cè)模型的輸出通常是[B, 4 num_classes, N]這種格式N是anchor數(shù)量后面接的是框坐標(biāo)、置信度和類別分?jǐn)?shù)。而深度估計(jì)模型的輸出一般是[B, H, W]或[B, 1, H, W]的深度圖沒有anchor、沒有類別后處理階段也不再需要NMS而是要把每個(gè)像素的深度值映射到真實(shí)距離。這一點(diǎn)需要在導(dǎo)出前就搞清楚否則你會(huì)拿著深度模型的輸出去做目標(biāo)框解碼怎么看怎么不對(duì)。1.3 輕量化導(dǎo)向n/s模型導(dǎo)出時(shí)的取舍“yolo26輕量化”也是高頻詞。輕量化通常意味著用nano或small版本或者通過剪枝、蒸餾把模型做小。到了導(dǎo)出環(huán)節(jié)輕量化模型有一個(gè)典型的優(yōu)化路徑降低輸入分辨率、啟用FP16或INT8量化進(jìn)一步壓榨速度。但每一步都有代價(jià)。我的建議是在導(dǎo)出之前先給模型打一個(gè)精度基線。用同一批驗(yàn)證集圖片記錄下原始PT模型的mAP50、mAP50-95這些指標(biāo)然后每做一次導(dǎo)出調(diào)整比如降到416分辨率、開INT8就用同一批圖片重新測(cè)一遍把指標(biāo)變化記錄下來。別憑感覺判斷“減小分辨率后效果還行”量化之后小目標(biāo)直接消失的情況我見過太多次了。2. 動(dòng)手前的三件事環(huán)境、權(quán)重與工作目錄2.1 版本對(duì)齊先確認(rèn)你的ultralytics包和Python環(huán)境導(dǎo)出失敗的第一大原因不是模型問題而是環(huán)境問題。YOLO26必須使用配套的ultralytics包版本如果你機(jī)器上裝的是幾個(gè)月前的舊版本很可能連模型文件都加載不了更別提導(dǎo)出了。建議用conda或venv新建一個(gè)干凈環(huán)境不要圖省事直接裝在base環(huán)境里。我在不同項(xiàng)目間切換時(shí)最煩的就是A項(xiàng)目要PyTorch 1.13、B項(xiàng)目要2.1最后全部亂套。獨(dú)立環(huán)境能幫你隔離掉這種問題。conda create -n yolo26 python3.10 -y conda activate yolo26 pip install ultralytics pip install onnx onnxruntime裝完之后跑一下版本確認(rèn)確保當(dāng)前加載的就是你預(yù)期的那一版python -c import ultralytics; print(ultralytics.__version__)Python版本方面3.10和3.11通常問題不大如果要用TensorRT導(dǎo)出還需要額外確認(rèn)CUDA和cuDNN的版本。這里給一個(gè)簡(jiǎn)單的版本對(duì)照參考組件建議版本說明Python3.10 / 3.11兼容性最穩(wěn)3.8太老、3.12有些算子庫(kù)還沒跟上ultralytics最新版或YOLO26發(fā)布時(shí)配套版本不追新但別用舊版PyTorch2.x 穩(wěn)定版與CUDA版本匹配CUDA11.8 / 12.1根據(jù)顯卡驅(qū)動(dòng)選擇onnx / onnxruntime最新穩(wěn)定版用于ONNX導(dǎo)出后的驗(yàn)證2.2 獲取模型權(quán)重官方模型下載與自訓(xùn)練權(quán)重導(dǎo)出之前要有一個(gè)合法可用的起點(diǎn)。官方預(yù)訓(xùn)練權(quán)重可以直接從GitHub Releases下載也可以讓ultralytics自動(dòng)下載比如跑一句yolo predict modelyolo26n.pt sourcehttps://ultralytics.com/images/bus.jpg第一次運(yùn)行時(shí)如果本地沒有權(quán)重文件工具會(huì)自動(dòng)下載并緩存。如果要用自己訓(xùn)練的數(shù)據(jù)集權(quán)重那就用訓(xùn)練輸出的best.pt。不管是官方權(quán)重還是自訓(xùn)練權(quán)重我強(qiáng)烈建議先做一次預(yù)測(cè)驗(yàn)證確認(rèn)權(quán)重本身可用再進(jìn)入導(dǎo)出流程。跳過驗(yàn)證直接導(dǎo)出的風(fēng)險(xiǎn)在于如果權(quán)重文件已經(jīng)損壞或版本不匹配導(dǎo)出過程可能報(bào)一些讓人摸不著頭腦的錯(cuò)誤你會(huì)誤以為是導(dǎo)出環(huán)節(jié)出了問題實(shí)際根源在權(quán)重文件上。2.3 建立干凈的工作目錄和導(dǎo)出檔案這個(gè)習(xí)慣是我踩過很多次坑之后才養(yǎng)成的。導(dǎo)出可能連續(xù)操作很多次每次的參數(shù)還都不一樣如果沒有記錄幾天后再看某個(gè)ONNX文件完全想不起來是用什么配置導(dǎo)出來的。推薦的目錄結(jié)構(gòu)大致是這樣的yolo26_export/ ├── weights/ │ ├── yolo26n.pt │ └── best.pt ├── export_log/ │ └── export_records.csv ├── test_imgs/ │ └── bus.jpg └── output/ ├── yolo26n.onnx ├── yolo26n_openvino_model/ └── yolo26n.engine每次導(dǎo)出時(shí)把源commit號(hào)、ultralytics版本、輸入尺寸、導(dǎo)出格式、是否開啟half或dynamic、opset版本這些關(guān)鍵信息記到export_records.csv里。不要相信自己的記憶力項(xiàng)目一多、時(shí)間一長(zhǎng)你會(huì)忘得干干凈凈。2.4 先用最小demo驗(yàn)證環(huán)境正式導(dǎo)出前用最小demo跑一次預(yù)測(cè)確保模型加載、前向推理、結(jié)果可視化整條鏈路都通。這一步耗時(shí)不到一分鐘但能篩掉大部分環(huán)境問題。from ultralytics import YOLO model YOLO(yolo26n.pt) results model.predict(bus.jpg, imgsz640) print(results[0].boxes.xyxy)能看到輸出框坐標(biāo)就說明基礎(chǔ)環(huán)境沒問題可以放心進(jìn)入導(dǎo)出環(huán)節(jié)。3. 導(dǎo)出一條龍命令拆解從export到各格式落地3.1 最基礎(chǔ)的一行命令export到底做了什么YOLO26的導(dǎo)出入口非常簡(jiǎn)單一行代碼搞定from ultralytics import YOLO model YOLO(yolo26n.pt) model.export(formatonnx, imgsz640)這行命令看起來簡(jiǎn)單背后大概做了幾件事先加載權(quán)重然后對(duì)模型執(zhí)行fuse操作把卷積和隨后的BN層融合減少推理時(shí)的計(jì)算量接著把訓(xùn)練時(shí)用的頭部結(jié)構(gòu)切換成推理頭最后把整個(gè)計(jì)算圖映射到ONNX格式并落盤。明白這個(gè)流程對(duì)排查問題很重要。比如你導(dǎo)出后發(fā)現(xiàn)模型推理結(jié)果和PT模型有偏差第一時(shí)間應(yīng)該想到是不是fuse階段和后續(xù)解碼邏輯不匹配。這類問題靠調(diào)導(dǎo)出參數(shù)往往沒用得回頭檢查后處理代碼。3.2 imgsz該填多少輸入尺寸與性能的權(quán)衡imgsz640是YOLO系列最常用的輸入尺寸但不代表所有場(chǎng)景都該用640。導(dǎo)出時(shí)定下的是模型的固定輸入分辨率推理時(shí)的圖像會(huì)被resize到這個(gè)尺寸。如果你想換分辨率要么重新導(dǎo)出對(duì)應(yīng)尺寸的模型要么在導(dǎo)出時(shí)開啟動(dòng)態(tài)尺寸。對(duì)于視頻流或?qū)崟r(shí)檢測(cè)場(chǎng)景把分辨率降到416或320帶來的提速非常明顯代價(jià)是小目標(biāo)的召回率會(huì)下降。如果你的業(yè)務(wù)場(chǎng)景里目標(biāo)本身比較大比如人員檢測(cè)、車輛檢測(cè)416通常夠用如果涉及遠(yuǎn)處小目標(biāo)640甚至更高分辨率會(huì)更穩(wěn)。拿不準(zhǔn)的話用一組典型測(cè)試圖片在幾個(gè)分辨率下對(duì)比一下再?zèng)Q定。3.3 動(dòng)態(tài)尺寸與靜態(tài)尺寸靈活性和效率的取舍導(dǎo)出時(shí)dynamicTrue可以生成支持任意輸入尺寸的模型聽著很美好但實(shí)際部署時(shí)往往會(huì)帶來額外的性能開銷而且不同推理框架對(duì)動(dòng)態(tài)尺寸的支持程度不一樣。拿TensorRT來說動(dòng)態(tài)尺寸需要在構(gòu)建引擎時(shí)配置幾檔profile推理時(shí)輸入尺寸必須在這些檔位范圍內(nèi)配置復(fù)雜度明顯上升。我的建議是沒有強(qiáng)需求就不要開動(dòng)態(tài)尺寸。固定尺寸的模型在速度、顯存占用、兼容性上都更省心。如果真有變尺寸需求優(yōu)先考慮按幾個(gè)常用檔位分別導(dǎo)出固定尺寸模型運(yùn)行時(shí)做切換比你跟動(dòng)態(tài)尺寸死磕要省事得多。3.4 half與int8兩種壓縮思路要分清halfTrue對(duì)應(yīng)FP16精度顯存占用減半、推理速度提升對(duì)精度影響通常很小這是N卡部署的首選方案。INT8量化則是把權(quán)重和激活值壓到8位整數(shù)體積更小、速度更快但精度損失明顯尤其對(duì)密集小目標(biāo)場(chǎng)景。關(guān)鍵一點(diǎn)INT8量化不是簡(jiǎn)單設(shè)置一個(gè)參數(shù)就完事的。TensorRT的INT8量化需要提供校準(zhǔn)數(shù)據(jù)集模型會(huì)統(tǒng)計(jì)激活值的分布來選擇合適的量化范圍。校準(zhǔn)數(shù)據(jù)集選得好不好直接影響量化后的精度。建議從驗(yàn)證集里挑幾百?gòu)埜采w各種場(chǎng)景的圖片作為校準(zhǔn)數(shù)據(jù)不要隨便拿幾張圖湊數(shù)。3.5 導(dǎo)出格式選型先想清楚部署環(huán)境再動(dòng)手不同格式適配不同的部署硬件選型錯(cuò)誤等于白干。我整理了一份常用的選型參考導(dǎo)出格式適用場(chǎng)景優(yōu)點(diǎn)缺點(diǎn)導(dǎo)出參數(shù)ONNX通用中轉(zhuǎn)、跨平臺(tái)生態(tài)好、框架支持廣推理速度取決于運(yùn)行時(shí)formatonnxOpenVINOIntel CPU / 集成顯卡CPU上延遲低、工具鏈成熟N卡上優(yōu)勢(shì)不明顯formatopenvinoTensorRTNVIDIA GPU性能天花板、支持FP16/INT8構(gòu)建時(shí)間長(zhǎng)、環(huán)境要求高formatengineCoreMLmacOS / iOS蘋果生態(tài)原生支持對(duì)其他平臺(tái)無用formatcoremlNCNN移動(dòng)端 / ARM嵌入式輕量、適合手機(jī)和邊緣設(shè)備轉(zhuǎn)出精度可能損失formatncnnTFLite / EdgeTPU樹莓派、EdgeTPU等邊緣設(shè)備兼容性好需要經(jīng)歷兩級(jí)轉(zhuǎn)換formattflite如果目標(biāo)環(huán)境是Windows NVIDIA顯卡優(yōu)先考慮TensorRT如果是Intel CPU服務(wù)器OpenVINO是性價(jià)比之選如果只是做跨平臺(tái)演示或快速驗(yàn)證ONNX是最穩(wěn)的保底方案。4. 四種主流導(dǎo)出格式的實(shí)操記錄4.1 ONNX優(yōu)先導(dǎo)這個(gè)先驗(yàn)證再走下一步我個(gè)人的習(xí)慣是不管最終部署用什么格式第一步永遠(yuǎn)先導(dǎo)ONNX。原因很簡(jiǎn)單ONNX是通用格式生態(tài)最廣導(dǎo)出時(shí)間短方便快速驗(yàn)證模型轉(zhuǎn)換本身有沒有問題。from ultralytics import YOLO model YOLO(yolo26n.pt) model.export(formatonnx, imgsz640, dynamicFalse, halfFalse, opset12)導(dǎo)出完成后可以用ONNX Runtime加載先做一個(gè)最基本的形狀驗(yàn)證import onnxruntime as ort sess ort.InferenceSession(yolo26n.onnx) input_name sess.get_inputs()[0].name print(input shape:, sess.get_inputs()[0].shape) print(output shape:, [o.shape for o in sess.get_outputs()])用隨機(jī)輸入測(cè)試能跑通只說明計(jì)算圖結(jié)構(gòu)沒問題還不能說明語(yǔ)義正確。真正靠譜的驗(yàn)證方式是拿同一張真實(shí)圖片分別用PT模型和ONNX模型推理對(duì)比檢測(cè)結(jié)果。如果類別的置信度和框坐標(biāo)能對(duì)得上說明轉(zhuǎn)換無礙。4.2 OpenVINOCPU部署的好搭檔還能直接用YOLO類加載如果部署目標(biāo)是Intel CPU服務(wù)器OpenVINO導(dǎo)出是個(gè)很舒服的選擇。它會(huì)把模型編譯成針對(duì)Intel CPU優(yōu)化的IR格式推理延遲通常比ONNX Runtime低一截。model.export(formatopenvino, imgsz640, halfFalse)生成的是一個(gè)以_openvino_model結(jié)尾的目錄里面包含.xml和.bin文件。比較意外的是ultralytics支持直接用YOLO類加載OpenVINO模型預(yù)處理后處理的邏輯都被封裝好了用起來和加載原始PT文件幾乎一樣from ultralytics import YOLO model YOLO(yolo26n_openvino_model) results model(bus.jpg) print(results[0].boxes.xyxy)這一點(diǎn)在實(shí)際項(xiàng)目中很香。你不需要手寫圖片預(yù)處理、NMS這些邏輯底層已經(jīng)幫你處理掉了。實(shí)測(cè)下來在Intel i7-12700上運(yùn)行nano模型輸入640分辨率單幀推理能跑到10毫秒以內(nèi)日常業(yè)務(wù)場(chǎng)景完全夠用。4.3 TensorRTN卡上的性能天花板但構(gòu)建期要學(xué)會(huì)等待TensorRT是NVIDIA GPU上的部署王者。同樣的nano模型在RTX 3060上ONNX Runtime推理大概3到5毫秒TensorRT FP16能壓縮到2毫秒左右連續(xù)推理時(shí)吞吐量?jī)?yōu)勢(shì)更明顯。model.export(formatengine, imgsz640, halfTrue, dynamicFalse)導(dǎo)出engine文件的過程比較耗時(shí)有時(shí)會(huì)讓人誤以為卡死了。nano模型通常幾十秒到幾分鐘大模型可能要更久這是正?，F(xiàn)象。構(gòu)建engine時(shí)需要申請(qǐng)顯存如果同時(shí)有其他顯存占用可能報(bào)CUDA out of memory建議導(dǎo)出前關(guān)掉其他GUI應(yīng)用或服務(wù)。TensorRT的engine文件和硬件綁定換一張不同型號(hào)的顯卡就需要重新構(gòu)建。所以拿到新機(jī)器第一件事就是重新導(dǎo)出別把舊機(jī)器上的engine文件直接復(fù)制過去用。4.4 CoreML、NCNN這些邊緣端格式怎么選CoreML面向蘋果生態(tài)。如果你的項(xiàng)目要部署到iPhone或Mac上可以導(dǎo)出試試model.export(formatcoreml, imgsz640)生成的.mlpackage可以用Xcode直接集成到App里蘋果的CoreML工具鏈會(huì)把模型進(jìn)一步優(yōu)化。NCNN則是移動(dòng)端和嵌入式設(shè)備的?？陀绕溥m合ARM架構(gòu)的板子model.export(formatncnn, imgsz640)NCNN導(dǎo)出后會(huì)生成.param和.bin兩個(gè)文件配合ncnn的C或Python接口使用。要注意的是模型經(jīng)過多輪轉(zhuǎn)換PyTorch到ONNX再到NCNN后精度可能有一定損失部署后務(wù)必在真實(shí)設(shè)備上做一輪驗(yàn)證。4.5 導(dǎo)出后的自檢清單模型導(dǎo)出成功不等于部署工作完成我給自己定了一份固定的自檢清單每次導(dǎo)完都過一遍用同一張包含多個(gè)目標(biāo)的典型圖片分別跑PT模型和導(dǎo)出模型對(duì)比檢測(cè)框和置信度。多測(cè)幾張不同尺度、不同光照、不同場(chǎng)景的圖片確認(rèn)沒有偶發(fā)性輸出異常。用導(dǎo)出格式的推理接口連續(xù)跑100幀確認(rèn)沒有內(nèi)存泄漏或顯存持續(xù)增長(zhǎng)。記錄各格式的單幀推理耗時(shí)和模型文件大小為后續(xù)選型提供數(shù)據(jù)。這份清單能攔住絕大多數(shù)“導(dǎo)出成功但部署后出問題”的隱患。5. 導(dǎo)出過程里我踩過的坑按報(bào)錯(cuò)信息復(fù)盤5.1 換機(jī)器后環(huán)境不一致導(dǎo)出報(bào)一堆libtorch錯(cuò)誤有次我在臺(tái)式機(jī)上導(dǎo)出一切正常換到筆記本上同一個(gè)腳本卻報(bào)錯(cuò)提示找不到某個(gè)libtorch動(dòng)態(tài)庫(kù)或ONNX相關(guān)依賴。排查下來發(fā)現(xiàn)筆記本上的Python環(huán)境是從老項(xiàng)目里繼承過來的依賴版本混亂ultralytics和onnx之間版本不匹配。后來我把所有項(xiàng)目都改成獨(dú)立虛擬環(huán)境并在項(xiàng)目的README里寫明環(huán)境構(gòu)建命令。這個(gè)習(xí)慣雖然簡(jiǎn)單卻幫我省掉了大量環(huán)境排查時(shí)間。如果你正在多臺(tái)機(jī)器間切換強(qiáng)烈建議把環(huán)境固定下來。5.2 ONNX opset版本與推理端不匹配還有一次用ONNX Runtime加載同事給的模型時(shí)直接報(bào)錯(cuò)提示算子版本不被支持。查下來發(fā)現(xiàn)對(duì)方是用opset17導(dǎo)出的而我本地的ONNX Runtime版本較舊只支持到13。解決辦法有兩種要么升級(jí)本地ONNX Runtime要么統(tǒng)一在導(dǎo)出時(shí)指定一個(gè)大家都能接受的opset版本比如12或13。項(xiàng)目組里最好定一個(gè)統(tǒng)一的導(dǎo)出規(guī)范避免每個(gè)成員導(dǎo)出時(shí)各用各的參數(shù)。5.3 自定義數(shù)據(jù)集訓(xùn)練出的權(quán)重導(dǎo)出后輸出tensor對(duì)不上自定義數(shù)據(jù)集的類別數(shù)通常和COCO的80類不一樣。如果你的檢測(cè)模型只有3個(gè)類別導(dǎo)出的ONNX輸出形狀就不是[1, 84, 8400]而是[1, 7, 8400]4個(gè)坐標(biāo) 3個(gè)類別分?jǐn)?shù)。這在熟悉YOLO源碼的人眼里是常識(shí)但新手很容易踩坑拿著80類的后處理代碼去處理3類模型的輸出結(jié)果自然是錯(cuò)的。導(dǎo)出后先打印輸出形狀確認(rèn)類別維度和預(yù)期一致再寫后處理邏輯。5.4 TensorRT導(dǎo)出時(shí)顯存不足TensorRT構(gòu)建engine時(shí)會(huì)占用較多顯存尤其用大模型配高分辨率時(shí)特別容易爆顯存。我遇到過同時(shí)開著瀏覽器幾十個(gè)標(biāo)簽頁(yè)再導(dǎo)一個(gè)l-size模型直接就CUDA out of memory。解法很樸素導(dǎo)出前把無關(guān)程序關(guān)掉如果還是不夠適當(dāng)降低imgsz或改用單卡執(zhí)行還可以設(shè)置環(huán)境變量CUDA_VISIBLE_DEVICES指定設(shè)備。如果真遇到分辨率不能降、顯存又不夠的情況可以考慮在空閑機(jī)器上導(dǎo)出engine后再拷到目標(biāo)機(jī)器但記得型號(hào)必須相同。5.5 導(dǎo)出成功但推理結(jié)果不對(duì)的完整排錯(cuò)鏈路最折磨人的場(chǎng)景是模型導(dǎo)出成功、文件能加載、推理不報(bào)錯(cuò)但結(jié)果就是不對(duì)。PT模型好好的ONNX模型檢測(cè)框全面漂移。遇到這種情況我會(huì)按下面的順序排查確認(rèn)預(yù)處理完全一致。PT模型推理時(shí)的圖片縮放邏輯letterbox是否和ONNX推理時(shí)的預(yù)處理一致填充顏色、比例變化都可能影響結(jié)果。確認(rèn)輸出解碼邏輯一致。輸出tensor的排列順序是[cx, cy, w, h]還是[x1, y1, x2, y2]不同版本可能不同。固定輸入尺寸后逐層對(duì)比。如果前兩項(xiàng)都沒問題可以導(dǎo)出某一層的中間輸出和PyTorch模型對(duì)應(yīng)層的輸出做對(duì)比定位差異是從哪一層開始的。檢查是否開啟動(dòng)態(tài)尺寸但推理端實(shí)際輸入尺寸和導(dǎo)出預(yù)設(shè)不一致。這一套鏈路走下來絕大多數(shù)“導(dǎo)出來但用不了”的問題都能定位到根因。6. 導(dǎo)出之后的事用實(shí)戰(zhàn)場(chǎng)景驗(yàn)證模型文件6.1 用導(dǎo)出模型做人員入侵檢測(cè)的最小代碼模型導(dǎo)出的最終目的是接到業(yè)務(wù)場(chǎng)景里。這里給一個(gè)基于OpenVINO導(dǎo)出模型的人員入侵檢測(cè)最小實(shí)現(xiàn)用視頻流做輸入檢測(cè)到人就在畫面上畫框并打印告警import cv2 from ultralytics import YOLO model YOLO(yolo26n_openvino_model) cap cv2.VideoCapture(test_video.mp4) while cap.isOpened(): ret, frame cap.read() if not ret: break results model(frame, imgsz640, conf0.5) boxes results[0].boxes.xyxy.cpu().numpy() clss results[0].boxes.cls.cpu().numpy() for box, cls in zip(boxes, clss): if int(cls) 0: # COCO中類別0是person x1, y1, x2, y2 map(int, box) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.putText(frame, person, (x1, y1 - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 0, 255), 1) print(detect person at:, x1, y1, x2, y2) cv2.imshow(result, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()這段代碼邏輯很直白但能幫你驗(yàn)證整個(gè)部署鏈路是否通暢。真正做項(xiàng)目時(shí)還要考慮跳幀處理、告警去重、多路并發(fā)之類的問題但最基本的框架就是這個(gè)樣子。6.2 depth模型導(dǎo)出后怎么在單相機(jī)測(cè)距場(chǎng)景中輸出距離結(jié)合“yolo26 depth”“單相機(jī)測(cè)距輸出距離”這兩個(gè)關(guān)注點(diǎn)depth模型的導(dǎo)出和檢測(cè)模型類似但驗(yàn)證方式完全不同。深度估計(jì)模型導(dǎo)出的輸出通常是一個(gè)深度圖形狀是[B, H, W]或[B, 1, H, W]每個(gè)像素值代表該點(diǎn)的深度信息。單相機(jī)測(cè)距要走出這幾個(gè)步驟導(dǎo)出depth模型確認(rèn)輸出形狀。推理得到深度圖后先把數(shù)值歸一化到合理范圍。通過標(biāo)定把深度值映射到真實(shí)距離。最常用的方式是準(zhǔn)備一個(gè)已知尺寸的標(biāo)定物比如一塊棋盤格或一個(gè)1米高的紙箱放在已知距離處拍攝后記錄對(duì)應(yīng)位置的深度值建立從深度值到真實(shí)距離的線性映射distance depth_value * scale offset。多測(cè)幾個(gè)距離點(diǎn)擬合出更穩(wěn)的映射關(guān)系。需要提醒的是單目深度估計(jì)的絕對(duì)精度是有限的它依賴模型從二維圖像中“猜”出三維信息光照變化、物體遮擋都會(huì)影響結(jié)果。單相機(jī)測(cè)距適合做輔助判斷比如入侵檢測(cè)里的近距離告警不適合做精確測(cè)量。如果你的業(yè)務(wù)對(duì)距離精度要求很高還是得上雙目相機(jī)或激光雷達(dá)。6.3 導(dǎo)出前后性能如何量化對(duì)比導(dǎo)出完之后用一個(gè)簡(jiǎn)單的基準(zhǔn)測(cè)試對(duì)比各格式的推理性能這種數(shù)據(jù)在項(xiàng)目匯報(bào)時(shí)特別有用。這里給一個(gè)基礎(chǔ)腳本import time import numpy as np from ultralytics import YOLO def benchmark(model_path, img_size640, runs50): model YOLO(model_path) dummy np.random.randint(0, 255, (img_size, img_size, 3), dtypenp.uint8) # 先預(yù)熱幾次排除第一次加載和緩存的影響 for _ in range(5): model.predict(dummy, imgszimg_size, verboseFalse) times [] for _ in range(runs): t0 time.time() model.predict(dummy, imgszimg_size, verboseFalse) times.append(time.time() - t0) avg_time np.mean(times[5:]) * 1000 print(f{model_path}: avg {avg_time:.2f} ms per frame) return avg_time benchmark(yolo26n.pt) benchmark(yolo26n_openvino_model)注意幾個(gè)細(xì)節(jié)先預(yù)熱再計(jì)時(shí)否則第一次加載模型的時(shí)間會(huì)污染數(shù)據(jù)計(jì)算平均值時(shí)丟掉前幾次的結(jié)果runs不要設(shè)太少50次起步才比較穩(wěn)。用隨機(jī)圖做性能測(cè)試沒問題因?yàn)殛P(guān)注的是“跑一幀要多久”不是檢測(cè)正確率。7. 幾個(gè)在導(dǎo)出之外容易被忽略的細(xì)節(jié)模型導(dǎo)出不只是敲一條命令的事周邊工程同樣重要。比如輸入圖片的預(yù)處理YOLO26用的是letterbox加歸一化letterbox的填充顏色、縮放方式在不同版本里可能有細(xì)微差別推理端一定要和訓(xùn)練端保持一致。再比如后處理中的NMS參數(shù)conf閾值和iou閾值在不同格式下不需要改變但如果你用了第三方推理框架就得確認(rèn)它們是否支持自定義NMS參數(shù)。還有一個(gè)容易被忽略的點(diǎn)多線程推理。TensorRT的engine不是線程安全的多個(gè)線程同時(shí)推理時(shí)需要為每個(gè)線程創(chuàng)建獨(dú)立的context或者加鎖串行化。用的時(shí)候多看幾眼框架文檔別想當(dāng)然地共享同一個(gè)engine實(shí)例。另外導(dǎo)出文件的版本管理也很重要。建議把導(dǎo)出文件跟對(duì)應(yīng)的源碼commit關(guān)聯(lián)起來至少用一個(gè)文本文件記錄導(dǎo)出的參數(shù)、時(shí)間和代碼版本。模型一旦更新迭代舊版本的導(dǎo)出文件最好歸檔不要原地覆蓋。我見過有人反復(fù)導(dǎo)出同一份文件結(jié)果某次參數(shù)寫錯(cuò)舊文件被覆蓋新文件有問題線上告警才發(fā)現(xiàn)。版本管理這件事花一分鐘記錄省一個(gè)通宵。最后再分享一個(gè)我自己的小習(xí)慣每次拿到新的YOLO系列模型我做的第一件事不是直接部署而是導(dǎo)出成一個(gè)ONNX文件然后用隨機(jī)輸入過一遍把輸出形狀和數(shù)值范圍打印出來。這一步能讓我在最短時(shí)間內(nèi)理解模型的“脾氣”——輸出是什么結(jié)構(gòu)、數(shù)值大概在什么范圍、需要搭配什么樣的后處理。看懂模型在數(shù)學(xué)層面長(zhǎng)什么樣比背十條部署命令都有用。YOLO26的導(dǎo)出也是這樣先把這份基本功打好后續(xù)不管換什么格式、什么硬件你都會(huì)有底氣。