換到AscendCL推理完整指南)
從PyTorch權(quán)重到昇騰OM模型再到AscendCL推理程序我把Atlas 300V 24G上跑YOLO的完整鏈路捋清楚。這篇文章不聊概念直接講怎么選卡、怎么轉(zhuǎn)換、怎么寫(xiě)代碼、怎么調(diào)優(yōu)把我實(shí)際踩過(guò)的坑和驗(yàn)證過(guò)的方法都放出來(lái)供正要上手這個(gè)組合的人參考。1. Atlas 300V 24G到底算不算“運(yùn)算加速卡”最近總有人在討論區(qū)問(wèn)Atlas 300V 24G是不是運(yùn)算加速卡我尋思這個(gè)問(wèn)題背后其實(shí)是很多人的共同困惑——昇騰的卡型號(hào)多、定位雜光看名字根本分不清它是干什么的。直接說(shuō)結(jié)論**Atlas 300V 24G是AI推理加速卡不是訓(xùn)練卡。**它負(fù)責(zé)的事情很明確就是把已經(jīng)訓(xùn)練好的模型跑起來(lái)做高吞吐、低功耗的推理服務(wù)。1.1 從“是不是運(yùn)算加速卡”這個(gè)疑問(wèn)說(shuō)起“運(yùn)算加速卡”這個(gè)說(shuō)法太寬泛了。CPU也算運(yùn)算GPU也算運(yùn)算NPU也算運(yùn)算。Atlas 300V 24G的全稱是Atlas 300V Pro 24GB推理加速卡基于昇騰310P處理器板載24GB HBM2e顯存PCIe Gen4 x16接口整卡功耗在72W左右。從硬件規(guī)格能明顯看出它跟面向訓(xùn)練的加速卡是兩個(gè)路數(shù)訓(xùn)練卡一般功耗大、散熱規(guī)模大、算力集中在FP32/BF16高精度區(qū)間而300V這種推理卡功耗低、顯存大、算力重點(diǎn)標(biāo)在INT8上。昇騰310P這顆芯片在設(shè)計(jì)上就偏向視頻分析、目標(biāo)檢測(cè)、圖像分類(lèi)這類(lèi)推理任務(wù)。它的默認(rèn)配置里帶了硬件級(jí)視頻解碼能力可以硬解多路視頻流這對(duì)YOLO類(lèi)應(yīng)用來(lái)說(shuō)是天然優(yōu)勢(shì)——想做視頻流實(shí)時(shí)檢測(cè)的不需要額外買(mǎi)昂貴的視頻處理單元300V卡自己就能扛。很多第一次接觸的人會(huì)拿它和NVIDIA的顯卡做對(duì)比問(wèn)能不能像用RTX 3090那樣直接拿來(lái)訓(xùn)練YOLO。我的回答是不建議也沒(méi)有必要。訓(xùn)練需要的是高精度的浮點(diǎn)計(jì)算和靈活的算子支持而300V的強(qiáng)項(xiàng)在INT8低精度推理強(qiáng)行拿它跑訓(xùn)練性能發(fā)揮不出來(lái)工具鏈還不順手。做推理部署選它是站在它主場(chǎng)做訓(xùn)練選它是跟自己過(guò)不去。1.2 跟GPU推理卡比差異在哪用NVIDIA的Tesla T4、A10來(lái)對(duì)標(biāo)比較容易理解。T4功耗70W、INT8算力大概在130 TOPS量級(jí)而Atlas 300V 24G的INT8算力標(biāo)稱在256到280 TOPS之間不同資料口徑略有差異以實(shí)際硬件規(guī)格為準(zhǔn)顯存24GB也比T4的16GB大不少功耗卻維持在相近水平。這種能效比優(yōu)勢(shì)讓它在小機(jī)箱、邊緣機(jī)房、以及需要插多張卡的密集計(jì)算節(jié)點(diǎn)里非常有吸引力。單卡24GB顯存能干什么以YOLOv8m為例FP16模型權(quán)重加中間計(jì)算所需內(nèi)存可能也就1到2GB24GB顯存意味著可以同時(shí)加載多個(gè)模型做多任務(wù)推理或者用較大的batch去做批量推理甚至直接塞一個(gè)不小的模型全家桶。這對(duì)實(shí)際項(xiàng)目非常重要我做過(guò)的工業(yè)質(zhì)檢場(chǎng)景里一臺(tái)機(jī)器上同時(shí)跑了表面缺陷檢測(cè)和OCR兩個(gè)模型一張300V卡全部搞定不用額外擴(kuò)卡。1.3 這個(gè)卡適合誰(shuí)如果你屬于下面這幾類(lèi)情況Atlas 300V 24G是比較對(duì)口的選型安防、交通、園區(qū)場(chǎng)景里做視頻結(jié)構(gòu)化分析需要跑YOLO系列目標(biāo)檢測(cè)模型做邊緣AI盒子或私有化推理服務(wù)器對(duì)功耗和機(jī)箱空間敏感業(yè)務(wù)模型以檢測(cè)、分類(lèi)為主對(duì)INT8量化精度損失比較寬容。反過(guò)來(lái)如果你要經(jīng)常改模型結(jié)構(gòu)、反復(fù)做訓(xùn)練迭代那這條路不適合你老老實(shí)實(shí)用GPU訓(xùn)練訓(xùn)完再考慮部署用什么。2. 部署YOLO前先搞懂昇騰的軟件棧層級(jí)昇騰生態(tài)最勸退新人的不是硬件貴而是名詞太多、層級(jí)太繞。CANN、AscendCL、ATC、MindSpore、torch_npu、Driver、Firmware每個(gè)好像都跟部署有關(guān)但每個(gè)人都說(shuō)不清楚它們之間的關(guān)系。我建議你先別急著敲命令花半小時(shí)把層級(jí)理清楚后面能少走很多彎路。2.1 CANN到底負(fù)責(zé)什么CANN全稱是Compute Architecture for Neural Networks中文叫昇騰計(jì)算架構(gòu)。你可以把它理解成昇騰硬件之上的操作系統(tǒng)它是整個(gè)軟件棧的核心。CANN內(nèi)部包含了幾大模塊圖編譯引擎負(fù)責(zé)把模型編譯成硬件能高效執(zhí)行的指令序列算子庫(kù)提供了神經(jīng)網(wǎng)絡(luò)里常用的算子實(shí)現(xiàn)運(yùn)行時(shí)環(huán)境負(fù)責(zé)設(shè)備管理、內(nèi)存管理、模型執(zhí)行還有工具鏈比如ATC模型轉(zhuǎn)換工具、msprof性能分析工具都在CANN這一層。Driver和Firmware在CANN下面一個(gè)管設(shè)備和系統(tǒng)之間的通信一個(gè)管設(shè)備固件升級(jí)。CANN在上面向上支撐MindSpore這種框架。整個(gè)結(jié)構(gòu)從下往上是硬件、Driver/Firmware、CANN、框架層、應(yīng)用層。部署YOLO這件事絕大部分時(shí)間是在CANN這一層工作尤其是ATC和AscendCL。2.2 走哪條部署技術(shù)路線在昇騰上部署YOLO實(shí)際可選的推理路徑有好幾條。第一條是用MindSpore推理接口加載OM模型優(yōu)點(diǎn)是代碼量小適合快速驗(yàn)證第二條是用torch_npu配合PyTorch框架跑推理適合從PyTorch直接遷移的場(chǎng)景第三條是直接調(diào)用AscendCL的API自己管理設(shè)備、內(nèi)存和模型執(zhí)行。我個(gè)人的選擇是第三條直接寫(xiě)AscendCL。原因很簡(jiǎn)單對(duì)于推理部署這種追求極致吞吐和穩(wěn)定性的場(chǎng)景中間層越少可控性越高。用MindSpore或torch_npu雖然方便但框架層會(huì)幫你做很多隱含的事情一旦出了性能問(wèn)題你很難判斷瓶頸在框架調(diào)度還是硬件執(zhí)行。AscendCL雖然代碼寫(xiě)起來(lái)繁瑣一點(diǎn)但每個(gè)步驟都透明可查——內(nèi)存誰(shuí)申請(qǐng)的、拷貝哪一幀、執(zhí)行在哪里耗時(shí)都能精確測(cè)量。有個(gè)臨界點(diǎn)值得參考如果只是實(shí)驗(yàn)性驗(yàn)證、跑通流程就行用MindSpore或者在線推理服務(wù)即可省事如果要做成生產(chǎn)服務(wù)尤其是多路視頻流、持續(xù)高并發(fā)的場(chǎng)景直接上AscendCL。一句話總結(jié)快速驗(yàn)證用框架生產(chǎn)落地用CL。2.3 版本匹配是第一步也是最大的坑我見(jiàn)過(guò)太多人裝了CANN之后程序跑起來(lái)各種報(bào)錯(cuò)什么“runtime version mismatch”“unknown soc version”最后排查下來(lái)全是版本沒(méi)對(duì)齊。昇騰對(duì)版本組合的約束非常嚴(yán)格不同的CANN版本要求對(duì)應(yīng)的Driver/Firmware版本也要求適配的操作系統(tǒng)版本如果你要的是PyTorch路徑還得看torch_npu的版本匹配表Atlas 300V 24G在不同版本下可用的算子集合、性能調(diào)優(yōu)特性也有差異。開(kāi)工之前務(wù)必去昇騰社區(qū)下載對(duì)應(yīng)版本的“版本配套表”對(duì)照自己的操作系統(tǒng)、硬件型號(hào)、軟件用途把每個(gè)組件的版本鎖定。這里有個(gè)小技巧組件的版本號(hào)不要用最新盡量用配套表里相對(duì)成熟、用戶量大、論壇討論多的組合。最新版大概率有一些新功能但也常常帶來(lái)新的兼容問(wèn)題而你在社區(qū)里找到的解決方案往往都是針對(duì)上一代穩(wěn)定版本的。2.4 ATC和OM模型的關(guān)系很多從GPU生態(tài)過(guò)來(lái)的人不理解我在PyTorch里導(dǎo)出了ONNX為什么還要再轉(zhuǎn)換一次直接推理不行嗎原因是OM是昇騰硬件真正能高效執(zhí)行的格式類(lèi)似TensorRT在NVIDIA生態(tài)里的角色。ATC工具會(huì)把ONNX模型做圖優(yōu)化、算子融合、內(nèi)存規(guī)劃讓它更契合昇騰芯片的執(zhí)行方式。ONNX只是通用交換格式不經(jīng)過(guò)ATC的編譯AscendCL根本無(wú)法加載。把ONNX理解為一份菜譜它描述了一道菜怎么做但每個(gè)廚房的灶具火力不一樣同一個(gè)菜譜需要針對(duì)廚房做調(diào)整才能真正發(fā)揮味道。ATC做的事情就是把通用菜譜翻譯成昇騰廚房的專(zhuān)用操作手冊(cè)。YOLO這類(lèi)結(jié)構(gòu)相對(duì)規(guī)整的網(wǎng)絡(luò)轉(zhuǎn)換過(guò)程還算順利但有幾個(gè)細(xì)節(jié)沒(méi)處理好就會(huì)掉坑下一節(jié)詳細(xì)展開(kāi)。3. YOLO模型轉(zhuǎn)換全流程從PyTorch權(quán)重到OMYOLO系列模型在昇騰上的部署流程是通用的PyTorch訓(xùn)練 - 導(dǎo)出ONNX - onnxsim簡(jiǎn)化 - ATC轉(zhuǎn)換為OM - AscendCL加載推理。這一節(jié)我把每一步的關(guān)鍵操作和容易出錯(cuò)的地方都拆開(kāi)講。3.1 導(dǎo)出ONNX時(shí)的幾個(gè)關(guān)鍵決策在PyTorch側(cè)導(dǎo)出ONNX代碼本身很短但好幾處決策會(huì)影響后面ATC能不能順利轉(zhuǎn)換。opset版本建議選擇11到12太老的版本有些算子表達(dá)不充分太新的版本CANN不一定跟得上。YOLOv5官方倉(cāng)庫(kù)默認(rèn)導(dǎo)出opset 11我實(shí)測(cè)下來(lái)在Atlas 300V上轉(zhuǎn)換很順利。如果你的CANN版本較新用opset 13一般也沒(méi)問(wèn)題但沒(méi)必要追求新穩(wěn)定優(yōu)先。導(dǎo)出時(shí)要固定輸入shape或者約定好動(dòng)態(tài)范圍。ATC轉(zhuǎn)換時(shí)會(huì)根據(jù)你指定的輸入shape做優(yōu)化如果你后面推理時(shí)實(shí)際shape跟轉(zhuǎn)換時(shí)的shape不一致輕則報(bào)錯(cuò)重則產(chǎn)生不可預(yù)期的精度問(wèn)題。最穩(wěn)妥的做法是推理只用一種輸入尺寸在導(dǎo)出和轉(zhuǎn)換時(shí)都固定成同樣的shape。建議在導(dǎo)出后加一步onnxsim簡(jiǎn)化。onnxsim能把ONNX里冗余的常量折疊、無(wú)用的節(jié)點(diǎn)刪除簡(jiǎn)化后的模型結(jié)構(gòu)更干凈ATC轉(zhuǎn)換時(shí)遇到的未知算子風(fēng)險(xiǎn)更少。這個(gè)步驟我強(qiáng)烈建議不要省很多人報(bào)“Operator not supported”的錯(cuò)其實(shí)不是算子缺失而是ONNX里有一堆冗余結(jié)構(gòu)干擾了圖優(yōu)化。YOLOv5官方倉(cāng)庫(kù)的導(dǎo)出命令大致是python export.py --weights best.pt --include onnx --opset 12導(dǎo)出后先用onnxruntime跑一張測(cè)試圖確認(rèn)輸出正常。這一步能過(guò)濾掉模型權(quán)重或?qū)С鲞^(guò)程本身的問(wèn)題避免后面把時(shí)間浪費(fèi)在排查一個(gè)錯(cuò)誤的起點(diǎn)上。3.2 ATC轉(zhuǎn)換命令逐行解釋ONNX在手就可以執(zhí)行ATC轉(zhuǎn)換了。下面是我在Atlas 300V 24G上實(shí)際用過(guò)的命令atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg逐行解釋一下參數(shù)--model指定輸入ONNX文件路徑。--framework5表示輸入模型格式是ONNX。昇騰的ATC框架編號(hào)里1是Caffe3是TensorFlow5是ONNX這個(gè)編號(hào)很多人會(huì)記混。--output指定輸出OM文件的名稱前綴生成的文件是yolov5s_bs1.om。--input_shape指定模型輸入的名稱和shape。YOLOv5s模型的輸入名通常是images這里固定為1x3x640x640。--soc_version要用npu-smi info查到的實(shí)際SoC型號(hào)Atlas 300V 24G對(duì)應(yīng)昇騰310P系列的不同后綴根據(jù)實(shí)際芯片填。--insert_op_conf用于插入AIPP預(yù)處理配置這是讓模型精度不崩的關(guān)鍵。轉(zhuǎn)換成功后同級(jí)目錄下會(huì)生成.om文件。我習(xí)慣在轉(zhuǎn)換后檢查一下輸出日志確認(rèn)沒(méi)有warning級(jí)別的不支持算子。ATC的日志里如果出現(xiàn)“unsupported”之類(lèi)的警告往往意味著模型里的某些算子被降級(jí)到了CPU或通用實(shí)現(xiàn)性能會(huì)打折扣最好能通過(guò)簡(jiǎn)化ONNX或更換opset版本規(guī)避。3.3 AIPP配置昇騰部署中精度保證的關(guān)鍵AIPPAI Preprocessing是昇騰一個(gè)很有特色的機(jī)制把圖像縮放、色域轉(zhuǎn)換、減均值、歸一化這種常規(guī)預(yù)處理下沉到硬件里應(yīng)用側(cè)不需要自己逐像素去算。但AIPP是一把雙刃劍——配對(duì)了能達(dá)到性能和效果的平衡配錯(cuò)了模型輸出會(huì)全亂套。YOLOv5官方訓(xùn)練時(shí)的預(yù)處理邏輯是BGR格式讀圖 - 轉(zhuǎn)RGB - 像素值除以255歸一化 - 按ImageNet的mean和std做標(biāo)準(zhǔn)化。對(duì)應(yīng)到AIPP配置aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_h: 640 src_image_size_w: 640 csc_switch: true rbuv_swap_switch: false mean_chn_0: 123.675 mean_chn_1: 116.28 mean_chn_2: 103.53 var_reci_chn_0: 0.01712475 var_reci_chn_1: 0.017507 var_reci_chn_2: 0.01742919 }配置里的mean是ImageNet均值乘以255var_reci是標(biāo)準(zhǔn)差倒數(shù)的再除以255即var_reci 1/(std*255)。幾個(gè)容易翻車(chē)的地方第一個(gè)是var_reci是倒數(shù)和放縮后的值不是方差本身很多人把std或者方差直接填進(jìn)去輸出結(jié)果完全亂套。第二個(gè)是csc_switch打開(kāi)后硬件會(huì)做色域轉(zhuǎn)換但YOLOv5本來(lái)是在RGB上訓(xùn)練的如果AIPP配置里rgb_swap開(kāi)關(guān)弄反那圖像通道順序就變了模型看到的是一張顏色錯(cuò)亂但輪廓正確的圖檢測(cè)結(jié)果會(huì)明顯變差。第三個(gè)是src_image_size_h和src_image_size_w這兩個(gè)字段在有的CANN版本里填寫(xiě)的是模型輸入尺寸有的版本填寫(xiě)的是原始圖像尺寸不同的ATC版本行為有差異建議以官方文檔為準(zhǔn)多試一次對(duì)比結(jié)果就能確認(rèn)。3.4 動(dòng)態(tài)shape怎么取舍實(shí)際部署YOLO時(shí)有時(shí)候希望同一個(gè)模型能適配不同分辨率或者不同batch大小的輸入。ATC支持動(dòng)態(tài)shape通過(guò)--dynamic_batch_size或--dynamic_image_size參數(shù)指定。但我的建議是能不用就不用必須用就盡量限定范圍。用動(dòng)態(tài)batch配合多路視頻流確實(shí)很推薦命令寫(xiě)法如下atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_dynbs \ --input_shapeimages:-1,3,640,640 \ --dynamic_batch_size1,2,4,8 \ --soc_versionAscend310P3這樣生成的OM模型在推理時(shí)可以通過(guò)aclmdlSetDynamicBatchSize接口在batch 1到8之間動(dòng)態(tài)切換非常適合多個(gè)視頻流動(dòng)態(tài)匯入的場(chǎng)景。但要注意動(dòng)態(tài)batch會(huì)在模型里為每種batch size做優(yōu)化模型體積和內(nèi)存占用變大。而且一旦batch太大性能不升反降——300V單卡推理時(shí)把太多幀塞進(jìn)一次推理反而會(huì)導(dǎo)致某個(gè)中間算子的執(zhí)行時(shí)間被拉長(zhǎng)吞吐下降。我實(shí)測(cè)下來(lái)Atlas 300V上YOLOv5s的batch不超過(guò)8時(shí)吞吐是線性增長(zhǎng)的再往上收益明顯放緩就盡量不要超過(guò)8了。動(dòng)態(tài)分辨率問(wèn)題更復(fù)雜因?yàn)椴煌叽缦绿卣鲌D大小不同AscendCL在計(jì)算時(shí)會(huì)觸發(fā)多套內(nèi)存布局和算子調(diào)度策略性能和穩(wěn)定性都很難保證。我的經(jīng)驗(yàn)是部署時(shí)直接固定模型輸入尺寸640用的最多如果需要處理更小的圖像在預(yù)處理階段統(tǒng)一resize到640不要?jiǎng)幽Ｐ偷膕hape。4. 用AscendCL寫(xiě)YOLO推理程序的完整骨架模型轉(zhuǎn)好之后就到了落地環(huán)節(jié)。這一節(jié)我給出一套能直接跑的AscendCL推理框架包含初始化、顯存管理、推理執(zhí)行、后處理四個(gè)核心部分每一段代碼都逐行解釋為什么這么寫(xiě)。4.1 初始化和設(shè)備管理AscendCL的初始化方式跟CUDA有一些相似但也有自己的特點(diǎn)。核心流程是ao::Error ret aclInit(nullptr); // 設(shè)置計(jì)算設(shè)備0表示第一張卡 ret aclrtSetDevice(0); aclrtContext context; ret aclrtCreateContext(context, 0); uint32_t modelId; ret aclmdlLoadFromFile(yolov5s.om, modelId);**注意順序**必須先aclInit再aclrtSetDevice之后才能aclrtCreateContext。context創(chuàng)建后后續(xù)所有內(nèi)存申請(qǐng)、模型加載都跟這個(gè)context綁定。如果程序里用了多線程每個(gè)線程要用aclrtCreateContext創(chuàng)建自己的context否則并發(fā)訪問(wèn)會(huì)互相干擾。在Atlas 300V 24G這種多卡場(chǎng)景下還要注意ACL設(shè)備編號(hào)的分配。如果機(jī)器里插了兩張卡系統(tǒng)會(huì)識(shí)別成device 0和device 1。多進(jìn)程各自加載一個(gè)設(shè)備要顯式往各自設(shè)備里綁定。很多人在單卡上跑通之后換到多卡環(huán)境就報(bào)“device busy”或“context mismatch”基本都是在設(shè)備初始化時(shí)沒(méi)做好隔離。4.2 輸入輸出的內(nèi)存管理與拷貝模型加載后我們不能直接往里塞數(shù)據(jù)必須通過(guò)模型描述信息獲取輸入輸出的名字、大小和結(jié)構(gòu)然后分配對(duì)應(yīng)的內(nèi)存。aclmdlDesc *modelDesc aclmdlCreateDesc(); aclmdlGetDesc(modelDesc, modelId); size_t inputSize aclmdlGetInputSizeByName(modelDesc, images); size_t outputSize aclmdlGetOutputSizeByIndex(modelDesc, 0); void *inputBuf nullptr; void *outputBuf nullptr; aclrtMalloc(inputBuf, inputSize, ACL_MEM_MALLOC_NORMAL_ONLY); aclrtMalloc(outputBuf, outputSize, ACL_MEM_MALLOC_NORMAL_ONLY);這里有一個(gè)值得強(qiáng)調(diào)的經(jīng)驗(yàn)推理程序不要頻繁申請(qǐng)和釋放顯存。我見(jiàn)過(guò)很多初版代碼每一幀都aclrtMalloc申請(qǐng)、推理完aclrtFree釋放運(yùn)行十幾分鐘沒(méi)問(wèn)題但跑幾小時(shí)之后內(nèi)存碎片越來(lái)越嚴(yán)重最終報(bào)無(wú)法分配連續(xù)顯存的錯(cuò)誤。正確做法是在啟動(dòng)時(shí)一次性分配好輸入輸出緩沖區(qū)推理循環(huán)中反復(fù)復(fù)用進(jìn)程結(jié)束再統(tǒng)一釋放。數(shù)據(jù)從CPU側(cè)到NPU側(cè)的拷貝用aclrtMemcpyaclrtMemcpy(inputBuf, inputSize, hostInput, inputSize, ACL_MEMCPY_HOST_TO_DEVICE);這里有個(gè)隱藏的約束輸入數(shù)據(jù)在host側(cè)的內(nèi)存要連續(xù)。很多用OpenCV讀圖的代碼如果沒(méi)做resetize和concat數(shù)據(jù)是不連續(xù)的拷貝會(huì)報(bào)錯(cuò)或者讀出錯(cuò)誤數(shù)據(jù)。所以較穩(wěn)妥的做法是讀圖后第一時(shí)間統(tǒng)一復(fù)制到一塊連續(xù)內(nèi)存里再做后續(xù)操作。4.3 推理執(zhí)行準(zhǔn)備好輸入輸出后執(zhí)行推理只需要一條調(diào)用ret aclmdlExecute(modelId);aclmdlExecute是同步接口返回時(shí)輸出已經(jīng)就緒。對(duì)于Atlas 300V跑YOLOv5s這種模型單幀推理時(shí)間在幾毫秒量級(jí)同步模式的延遲完全可接受。如果要追求更高吞吐可以用aclmdlExecuteAsync把推理放到異步流上執(zhí)行。異步模式下需要自己管理事件同步代碼復(fù)雜度會(huì)明顯增加。我的一個(gè)經(jīng)驗(yàn)是在YOLO這種任務(wù)上如果單幀延遲本身只有幾毫秒同步模式就夠用了——把精力更多地花在后處理和流水線編排上往往比摳推理執(zhí)行那幾毫秒更劃算。4.4 后處理解碼加NMS要寫(xiě)對(duì)OM模型輸出的原始張量并不是最終的檢測(cè)框必須經(jīng)過(guò)解碼和NMS后處理。YOLOv5s的推理輸出是三個(gè)特征層的原始tensor分別對(duì)應(yīng)80x80、40x40、20x20大小的特征圖。每個(gè)cell會(huì)預(yù)測(cè)多個(gè)框包含邊界框坐標(biāo)、置信度和各個(gè)類(lèi)別的概率。后處理大體分兩步第一步是解碼把網(wǎng)絡(luò)輸出轉(zhuǎn)化為目標(biāo)框坐標(biāo)。YOLOv5輸出的是相對(duì)于輸入圖片大小的相對(duì)坐標(biāo)要乘以輸入尺寸才能換算成像素坐標(biāo)。這一步需要讀取模型輸出的具體信息遍歷每個(gè)特征層的每個(gè)cell。這里要提一個(gè)容易出錯(cuò)的細(xì)節(jié)ATC轉(zhuǎn)換后的OM模型輸出順序跟PyTorch里model的輸出順序不一定完全一致。我發(fā)現(xiàn)有時(shí)候PyTorch是從大特征圖到小特征圖輸出而OM也基本保持了原順序但穩(wěn)妥起見(jiàn)最好打印出三個(gè)輸出tensor的shape確認(rèn)一下別假設(shè)順序一定正確。第二步是篩框和NMS按置信度閾值過(guò)濾低分框再對(duì)每個(gè)類(lèi)別做NMS去除重疊度高的重復(fù)框。NMS邏輯本身不復(fù)雜但在高幀率場(chǎng)景下容易拖后腿。如果圖像里目標(biāo)多、類(lèi)別多純CPU單線程N(yùn)MS可能占掉整條推理鏈路的30%以上。一個(gè)實(shí)用的優(yōu)化辦法是在多路視頻流場(chǎng)景讓每路視頻的NMS跑在不同的工作線程上互不阻塞整體吞吐提升非常明顯。YOLOv8和YOLOv5在后處理上有差異。YOLOv8輸出了一個(gè)shape為[1, 84, 8400]的大tensor前4個(gè)是框坐標(biāo)cx, cy, w, h剩下80個(gè)是類(lèi)別概率。YOLOv8沒(méi)有錨框概念解碼省事一些但NMS依然是必須的。4.5 完整推理循環(huán)的偽代碼把上面幾塊拼起來(lái)推理循環(huán)的骨架大概是初始化ACL和設(shè)備 - 加載模型 申請(qǐng)固定緩沖區(qū)輸入/輸出 循環(huán) 讀一幀圖像 resize 填充letterbox做預(yù)處理 拷貝到設(shè)備內(nèi)存 aclmdlExecute 推理 拷回主機(jī)內(nèi)存 解碼 置信度過(guò)濾 NMS 繪制或發(fā)送結(jié)果 退出 釋放內(nèi)存 - 卸載模型 - 銷(xiāo)毀context - aclFinalize這個(gè)循環(huán)看似簡(jiǎn)單真正跑起來(lái)才發(fā)現(xiàn)工程上最難的不是模型執(zhí)行而是前處理和整個(gè)流水線的穩(wěn)定性。把每一路視頻流的延遲控制住、把隊(duì)列深度控制住、把內(nèi)存復(fù)用做好這些才是部署YOLO時(shí)最花時(shí)間的部分。5. 部署踩坑實(shí)錄與性能調(diào)優(yōu)方向最后這部分我把真實(shí)遇到過(guò)的坑和調(diào)優(yōu)方向整理出來(lái)每個(gè)點(diǎn)后面都加了一個(gè)處置思路希望你能繞過(guò)這些我兜過(guò)的圈子。5.1 AIPP預(yù)處理不一致導(dǎo)致精度崩塌背景在一次項(xiàng)目里把YOLOv5s模型從GPU遷移到Atlas 300V轉(zhuǎn)出來(lái)的OM模型在顯卡上檢測(cè)好好的在昇騰上框的位置偏了、置信度全掉到0.3以下。查了一天最后發(fā)現(xiàn)是AIPP配置里減均值歸一化沒(méi)做模型直接吃到了0到255的原始像素值。處置思路重新梳理訓(xùn)練時(shí)的預(yù)處理鏈路用letterbox把原圖resize到640然后除以255再做標(biāo)準(zhǔn)化。把標(biāo)準(zhǔn)化系數(shù)用逐像素對(duì)比驗(yàn)證打印AIPP預(yù)處理后的輸入圖像和PyTorch預(yù)處理后的圖像確認(rèn)數(shù)值范圍一致。AIPP配置和訓(xùn)練預(yù)處理只要有一個(gè)環(huán)節(jié)對(duì)不上精度問(wèn)題就不可避免。5.2 多路視頻流的推理編排要做成生產(chǎn)者-消費(fèi)者模型背景一開(kāi)始用最簡(jiǎn)單的方式每路視頻單獨(dú)一個(gè)線程做完整鏈路——拉流、解碼、預(yù)處理、推理、后處理。視頻路數(shù)一多頻繁切換線程CPU占用急劇上升推理吞吐反而下降。處置思路改成標(biāo)準(zhǔn)的生產(chǎn)者-消費(fèi)者流水線。每路視頻拉流解碼線程負(fù)責(zé)它自己的采集解碼后的幀放進(jìn)無(wú)鎖隊(duì)列推理線程從隊(duì)列里湊滿一個(gè)batch再統(tǒng)一推理后處理線程從輸出隊(duì)列拿到結(jié)果并行處理。隊(duì)列容量要給上限防止某一路卡頓導(dǎo)致內(nèi)存無(wú)限制增長(zhǎng)。這個(gè)模式下整機(jī)吞吐從原來(lái)的不到100幀每秒提升到了400幀每秒以上。5.3 用msprof定位性能瓶頸而不是靠猜背景模型單幀延遲偏大一開(kāi)始懷疑是量化精度問(wèn)題浪費(fèi)了大量時(shí)間在模型轉(zhuǎn)換上。后來(lái)用msprof工具看耗時(shí)分解才發(fā)現(xiàn)接近一半時(shí)間花在了數(shù)據(jù)拷貝上——每次推理前都新malloc了內(nèi)存拷貝又用了contiguous外的非連續(xù)內(nèi)存。處置思路先用msprof生成profiling數(shù)據(jù)看看耗時(shí)分布在哪幾個(gè)階段。CANN的profiling工具能精確列出每個(gè)算子的執(zhí)行時(shí)間和數(shù)據(jù)傳輸時(shí)間。改掉了內(nèi)存反復(fù)申請(qǐng)的問(wèn)題之后推理耗時(shí)下降了將近一半。用工具定位問(wèn)題是最高效的排查方式比靠直覺(jué)改代碼有效率得多。5.4 INT8量化是性能優(yōu)化的分水嶺背景模型在FP16下跑單卡吞吐基本符合預(yù)期但想要在同樣一臺(tái)機(jī)器上支持更多路視頻算力就顯得不夠了。做INT8 訓(xùn)練后量化之后模型體積縮小約四分之一推理延遲降低到原來(lái)的約六成檢測(cè)精度只掉了不到兩個(gè)點(diǎn)對(duì)于實(shí)際業(yè)務(wù)完全可接受。處置思路用CANN自帶的AMCT工具做離線量化用小規(guī)模但能覆蓋典型場(chǎng)景的數(shù)據(jù)集做校準(zhǔn)。量化時(shí)不要只跑一張圖要盡可能多樣性地覆蓋背景、目標(biāo)大小和光照變化量化后的模型記得用至少一萬(wàn)張真實(shí)業(yè)務(wù)圖做回歸驗(yàn)證。對(duì)YOLO這種檢測(cè)模型INT8量化帶來(lái)的收益非?？捎^有條件一定要做。5.5 一些看似不起眼但影響全局的配置進(jìn)程退出前一定要aclFinalize否則設(shè)備資源釋放不徹底二次啟動(dòng)會(huì)報(bào)設(shè)備被占用。異步推理時(shí)stream和event的數(shù)量是有限的不要每幀都新建要啟動(dòng)時(shí)創(chuàng)建好復(fù)用。算力規(guī)格允許的情況下優(yōu)先把視頻解碼也放到硬件上CPU的空閑資源留給后處理。多卡機(jī)器要注意PCIe帶寬分配兩張卡同時(shí)大批量拷貝數(shù)據(jù)時(shí)可能互相搶帶寬導(dǎo)致兩邊性能都下降。6. 我個(gè)人在實(shí)際部署中積累的一點(diǎn)體會(huì)把YOLO部署到Atlas 300V 24G上整個(gè)鏈路的心態(tài)變化大概要經(jīng)歷三個(gè)階段一開(kāi)始被各種新名詞淹沒(méi)容易急躁中間跑通后逐漸上手覺(jué)得不過(guò)如此真正做性能調(diào)優(yōu)和多路跑量時(shí)才發(fā)現(xiàn)深度學(xué)習(xí)模型的部署除了模型本身還有大量數(shù)據(jù)搬運(yùn)、內(nèi)存管理、異步調(diào)度、持久化穩(wěn)定性的功夫。這套流程中我最想叮囑新人的一點(diǎn)是**用DEBUG時(shí)不要大面積改配置一次只改一個(gè)變量。**AIPP配置里的一個(gè)參數(shù)、輸入shape是否固定、batch大小、量化開(kāi)關(guān)這些變量之間會(huì)互相影響。第一次部署建議固定住除一個(gè)變量外的一切比如只用固定shape、只用FP16把整個(gè)鏈路先跑通再考慮量化、動(dòng)態(tài)batch這些高級(jí)項(xiàng)。最后說(shuō)一句關(guān)于選型的建議如果你只是臨時(shí)跑個(gè)Demo那用GPU最順手但如果要做量產(chǎn)級(jí)的多路視頻分析服務(wù)且在意功耗、顯存、性價(jià)比Atlas 300V 24G是一個(gè)值得認(rèn)真評(píng)估的選項(xiàng)。它雖然有不小的學(xué)習(xí)成本但一旦把工具鏈跑熟后續(xù)換模型架構(gòu)、加路數(shù)、擴(kuò)大部署規(guī)模都是在同一個(gè)框架里做增量工作長(zhǎng)期收益很可觀。 Atlas 300V 24G上跑通YOLO：PyTorch模型轉(zhuǎn)換到AscendCL推理完整指南
從PyTorch權(quán)重到昇騰OM模型再到AscendCL推理程序我把Atlas 300V 24G上跑YOLO的完整鏈路捋清楚。這篇文章不聊概念直接講怎么選卡、怎么轉(zhuǎn)換、怎么寫(xiě)代碼、怎么調(diào)優(yōu)把我實(shí)際踩過(guò)的坑和驗(yàn)證過(guò)的方法都放出來(lái)供正要上手這個(gè)組合的人參考。1. Atlas 300V 24G到底算不算“運(yùn)算加速卡”最近總有人在討論區(qū)問(wèn)Atlas 300V 24G是不是運(yùn)算加速卡我尋思這個(gè)問(wèn)題背后其實(shí)是很多人的共同困惑——昇騰的卡型號(hào)多、定位雜光看名字根本分不清它是干什么的。直接說(shuō)結(jié)論**Atlas 300V 24G是AI推理加速卡不是訓(xùn)練卡。**它負(fù)責(zé)的事情很明確就是把已經(jīng)訓(xùn)練好的模型跑起來(lái)做高吞吐、低功耗的推理服務(wù)。1.1 從“是不是運(yùn)算加速卡”這個(gè)疑問(wèn)說(shuō)起“運(yùn)算加速卡”這個(gè)說(shuō)法太寬泛了。CPU也算運(yùn)算GPU也算運(yùn)算NPU也算運(yùn)算。Atlas 300V 24G的全稱是Atlas 300V Pro 24GB推理加速卡基于昇騰310P處理器板載24GB HBM2e顯存PCIe Gen4 x16接口整卡功耗在72W左右。從硬件規(guī)格能明顯看出它跟面向訓(xùn)練的加速卡是兩個(gè)路數(shù)訓(xùn)練卡一般功耗大、散熱規(guī)模大、算力集中在FP32/BF16高精度區(qū)間而300V這種推理卡功耗低、顯存大、算力重點(diǎn)標(biāo)在INT8上。昇騰310P這顆芯片在設(shè)計(jì)上就偏向視頻分析、目標(biāo)檢測(cè)、圖像分類(lèi)這類(lèi)推理任務(wù)。它的默認(rèn)配置里帶了硬件級(jí)視頻解碼能力可以硬解多路視頻流這對(duì)YOLO類(lèi)應(yīng)用來(lái)說(shuō)是天然優(yōu)勢(shì)——想做視頻流實(shí)時(shí)檢測(cè)的不需要額外買(mǎi)昂貴的視頻處理單元300V卡自己就能扛。很多第一次接觸的人會(huì)拿它和NVIDIA的顯卡做對(duì)比問(wèn)能不能像用RTX 3090那樣直接拿來(lái)訓(xùn)練YOLO。我的回答是不建議也沒(méi)有必要。訓(xùn)練需要的是高精度的浮點(diǎn)計(jì)算和靈活的算子支持而300V的強(qiáng)項(xiàng)在INT8低精度推理強(qiáng)行拿它跑訓(xùn)練性能發(fā)揮不出來(lái)工具鏈還不順手。做推理部署選它是站在它主場(chǎng)做訓(xùn)練選它是跟自己過(guò)不去。1.2 跟GPU推理卡比差異在哪用NVIDIA的Tesla T4、A10來(lái)對(duì)標(biāo)比較容易理解。T4功耗70W、INT8算力大概在130 TOPS量級(jí)而Atlas 300V 24G的INT8算力標(biāo)稱在256到280 TOPS之間不同資料口徑略有差異以實(shí)際硬件規(guī)格為準(zhǔn)顯存24GB也比T4的16GB大不少功耗卻維持在相近水平。這種能效比優(yōu)勢(shì)讓它在小機(jī)箱、邊緣機(jī)房、以及需要插多張卡的密集計(jì)算節(jié)點(diǎn)里非常有吸引力。單卡24GB顯存能干什么以YOLOv8m為例FP16模型權(quán)重加中間計(jì)算所需內(nèi)存可能也就1到2GB24GB顯存意味著可以同時(shí)加載多個(gè)模型做多任務(wù)推理或者用較大的batch去做批量推理甚至直接塞一個(gè)不小的模型全家桶。這對(duì)實(shí)際項(xiàng)目非常重要我做過(guò)的工業(yè)質(zhì)檢場(chǎng)景里一臺(tái)機(jī)器上同時(shí)跑了表面缺陷檢測(cè)和OCR兩個(gè)模型一張300V卡全部搞定不用額外擴(kuò)卡。1.3 這個(gè)卡適合誰(shuí)如果你屬于下面這幾類(lèi)情況Atlas 300V 24G是比較對(duì)口的選型安防、交通、園區(qū)場(chǎng)景里做視頻結(jié)構(gòu)化分析需要跑YOLO系列目標(biāo)檢測(cè)模型做邊緣AI盒子或私有化推理服務(wù)器對(duì)功耗和機(jī)箱空間敏感業(yè)務(wù)模型以檢測(cè)、分類(lèi)為主對(duì)INT8量化精度損失比較寬容。反過(guò)來(lái)如果你要經(jīng)常改模型結(jié)構(gòu)、反復(fù)做訓(xùn)練迭代那這條路不適合你老老實(shí)實(shí)用GPU訓(xùn)練訓(xùn)完再考慮部署用什么。2. 部署YOLO前先搞懂昇騰的軟件棧層級(jí)昇騰生態(tài)最勸退新人的不是硬件貴而是名詞太多、層級(jí)太繞。CANN、AscendCL、ATC、MindSpore、torch_npu、Driver、Firmware每個(gè)好像都跟部署有關(guān)但每個(gè)人都說(shuō)不清楚它們之間的關(guān)系。我建議你先別急著敲命令花半小時(shí)把層級(jí)理清楚后面能少走很多彎路。2.1 CANN到底負(fù)責(zé)什么CANN全稱是Compute Architecture for Neural Networks中文叫昇騰計(jì)算架構(gòu)。你可以把它理解成昇騰硬件之上的操作系統(tǒng)它是整個(gè)軟件棧的核心。CANN內(nèi)部包含了幾大模塊圖編譯引擎負(fù)責(zé)把模型編譯成硬件能高效執(zhí)行的指令序列算子庫(kù)提供了神經(jīng)網(wǎng)絡(luò)里常用的算子實(shí)現(xiàn)運(yùn)行時(shí)環(huán)境負(fù)責(zé)設(shè)備管理、內(nèi)存管理、模型執(zhí)行還有工具鏈比如ATC模型轉(zhuǎn)換工具、msprof性能分析工具都在CANN這一層。Driver和Firmware在CANN下面一個(gè)管設(shè)備和系統(tǒng)之間的通信一個(gè)管設(shè)備固件升級(jí)。CANN在上面向上支撐MindSpore這種框架。整個(gè)結(jié)構(gòu)從下往上是硬件、Driver/Firmware、CANN、框架層、應(yīng)用層。部署YOLO這件事絕大部分時(shí)間是在CANN這一層工作尤其是ATC和AscendCL。2.2 走哪條部署技術(shù)路線在昇騰上部署YOLO實(shí)際可選的推理路徑有好幾條。第一條是用MindSpore推理接口加載OM模型優(yōu)點(diǎn)是代碼量小適合快速驗(yàn)證第二條是用torch_npu配合PyTorch框架跑推理適合從PyTorch直接遷移的場(chǎng)景第三條是直接調(diào)用AscendCL的API自己管理設(shè)備、內(nèi)存和模型執(zhí)行。我個(gè)人的選擇是第三條直接寫(xiě)AscendCL。原因很簡(jiǎn)單對(duì)于推理部署這種追求極致吞吐和穩(wěn)定性的場(chǎng)景中間層越少可控性越高。用MindSpore或torch_npu雖然方便但框架層會(huì)幫你做很多隱含的事情一旦出了性能問(wèn)題你很難判斷瓶頸在框架調(diào)度還是硬件執(zhí)行。AscendCL雖然代碼寫(xiě)起來(lái)繁瑣一點(diǎn)但每個(gè)步驟都透明可查——內(nèi)存誰(shuí)申請(qǐng)的、拷貝哪一幀、執(zhí)行在哪里耗時(shí)都能精確測(cè)量。有個(gè)臨界點(diǎn)值得參考如果只是實(shí)驗(yàn)性驗(yàn)證、跑通流程就行用MindSpore或者在線推理服務(wù)即可省事如果要做成生產(chǎn)服務(wù)尤其是多路視頻流、持續(xù)高并發(fā)的場(chǎng)景直接上AscendCL。一句話總結(jié)快速驗(yàn)證用框架生產(chǎn)落地用CL。2.3 版本匹配是第一步也是最大的坑我見(jiàn)過(guò)太多人裝了CANN之后程序跑起來(lái)各種報(bào)錯(cuò)什么“runtime version mismatch”“unknown soc version”最后排查下來(lái)全是版本沒(méi)對(duì)齊。昇騰對(duì)版本組合的約束非常嚴(yán)格不同的CANN版本要求對(duì)應(yīng)的Driver/Firmware版本也要求適配的操作系統(tǒng)版本如果你要的是PyTorch路徑還得看torch_npu的版本匹配表Atlas 300V 24G在不同版本下可用的算子集合、性能調(diào)優(yōu)特性也有差異。開(kāi)工之前務(wù)必去昇騰社區(qū)下載對(duì)應(yīng)版本的“版本配套表”對(duì)照自己的操作系統(tǒng)、硬件型號(hào)、軟件用途把每個(gè)組件的版本鎖定。這里有個(gè)小技巧組件的版本號(hào)不要用最新盡量用配套表里相對(duì)成熟、用戶量大、論壇討論多的組合。最新版大概率有一些新功能但也常常帶來(lái)新的兼容問(wèn)題而你在社區(qū)里找到的解決方案往往都是針對(duì)上一代穩(wěn)定版本的。2.4 ATC和OM模型的關(guān)系很多從GPU生態(tài)過(guò)來(lái)的人不理解我在PyTorch里導(dǎo)出了ONNX為什么還要再轉(zhuǎn)換一次直接推理不行嗎原因是OM是昇騰硬件真正能高效執(zhí)行的格式類(lèi)似TensorRT在NVIDIA生態(tài)里的角色。ATC工具會(huì)把ONNX模型做圖優(yōu)化、算子融合、內(nèi)存規(guī)劃讓它更契合昇騰芯片的執(zhí)行方式。ONNX只是通用交換格式不經(jīng)過(guò)ATC的編譯AscendCL根本無(wú)法加載。把ONNX理解為一份菜譜它描述了一道菜怎么做但每個(gè)廚房的灶具火力不一樣同一個(gè)菜譜需要針對(duì)廚房做調(diào)整才能真正發(fā)揮味道。ATC做的事情就是把通用菜譜翻譯成昇騰廚房的專(zhuān)用操作手冊(cè)。YOLO這類(lèi)結(jié)構(gòu)相對(duì)規(guī)整的網(wǎng)絡(luò)轉(zhuǎn)換過(guò)程還算順利但有幾個(gè)細(xì)節(jié)沒(méi)處理好就會(huì)掉坑下一節(jié)詳細(xì)展開(kāi)。3. YOLO模型轉(zhuǎn)換全流程從PyTorch權(quán)重到OMYOLO系列模型在昇騰上的部署流程是通用的PyTorch訓(xùn)練 - 導(dǎo)出ONNX - onnxsim簡(jiǎn)化 - ATC轉(zhuǎn)換為OM - AscendCL加載推理。這一節(jié)我把每一步的關(guān)鍵操作和容易出錯(cuò)的地方都拆開(kāi)講。3.1 導(dǎo)出ONNX時(shí)的幾個(gè)關(guān)鍵決策在PyTorch側(cè)導(dǎo)出ONNX代碼本身很短但好幾處決策會(huì)影響后面ATC能不能順利轉(zhuǎn)換。opset版本建議選擇11到12太老的版本有些算子表達(dá)不充分太新的版本CANN不一定跟得上。YOLOv5官方倉(cāng)庫(kù)默認(rèn)導(dǎo)出opset 11我實(shí)測(cè)下來(lái)在Atlas 300V上轉(zhuǎn)換很順利。如果你的CANN版本較新用opset 13一般也沒(méi)問(wèn)題但沒(méi)必要追求新穩(wěn)定優(yōu)先。導(dǎo)出時(shí)要固定輸入shape或者約定好動(dòng)態(tài)范圍。ATC轉(zhuǎn)換時(shí)會(huì)根據(jù)你指定的輸入shape做優(yōu)化如果你后面推理時(shí)實(shí)際shape跟轉(zhuǎn)換時(shí)的shape不一致輕則報(bào)錯(cuò)重則產(chǎn)生不可預(yù)期的精度問(wèn)題。最穩(wěn)妥的做法是推理只用一種輸入尺寸在導(dǎo)出和轉(zhuǎn)換時(shí)都固定成同樣的shape。建議在導(dǎo)出后加一步onnxsim簡(jiǎn)化。onnxsim能把ONNX里冗余的常量折疊、無(wú)用的節(jié)點(diǎn)刪除簡(jiǎn)化后的模型結(jié)構(gòu)更干凈ATC轉(zhuǎn)換時(shí)遇到的未知算子風(fēng)險(xiǎn)更少。這個(gè)步驟我強(qiáng)烈建議不要省很多人報(bào)“Operator not supported”的錯(cuò)其實(shí)不是算子缺失而是ONNX里有一堆冗余結(jié)構(gòu)干擾了圖優(yōu)化。YOLOv5官方倉(cāng)庫(kù)的導(dǎo)出命令大致是python export.py --weights best.pt --include onnx --opset 12導(dǎo)出后先用onnxruntime跑一張測(cè)試圖確認(rèn)輸出正常。這一步能過(guò)濾掉模型權(quán)重或?qū)С鲞^(guò)程本身的問(wèn)題避免后面把時(shí)間浪費(fèi)在排查一個(gè)錯(cuò)誤的起點(diǎn)上。3.2 ATC轉(zhuǎn)換命令逐行解釋ONNX在手就可以執(zhí)行ATC轉(zhuǎn)換了。下面是我在Atlas 300V 24G上實(shí)際用過(guò)的命令atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg逐行解釋一下參數(shù)--model指定輸入ONNX文件路徑。--framework5表示輸入模型格式是ONNX。昇騰的ATC框架編號(hào)里1是Caffe3是TensorFlow5是ONNX這個(gè)編號(hào)很多人會(huì)記混。--output指定輸出OM文件的名稱前綴生成的文件是yolov5s_bs1.om。--input_shape指定模型輸入的名稱和shape。YOLOv5s模型的輸入名通常是images這里固定為1x3x640x640。--soc_version要用npu-smi info查到的實(shí)際SoC型號(hào)Atlas 300V 24G對(duì)應(yīng)昇騰310P系列的不同后綴根據(jù)實(shí)際芯片填。--insert_op_conf用于插入AIPP預(yù)處理配置這是讓模型精度不崩的關(guān)鍵。轉(zhuǎn)換成功后同級(jí)目錄下會(huì)生成.om文件。我習(xí)慣在轉(zhuǎn)換后檢查一下輸出日志確認(rèn)沒(méi)有warning級(jí)別的不支持算子。ATC的日志里如果出現(xiàn)“unsupported”之類(lèi)的警告往往意味著模型里的某些算子被降級(jí)到了CPU或通用實(shí)現(xiàn)性能會(huì)打折扣最好能通過(guò)簡(jiǎn)化ONNX或更換opset版本規(guī)避。3.3 AIPP配置昇騰部署中精度保證的關(guān)鍵AIPPAI Preprocessing是昇騰一個(gè)很有特色的機(jī)制把圖像縮放、色域轉(zhuǎn)換、減均值、歸一化這種常規(guī)預(yù)處理下沉到硬件里應(yīng)用側(cè)不需要自己逐像素去算。但AIPP是一把雙刃劍——配對(duì)了能達(dá)到性能和效果的平衡配錯(cuò)了模型輸出會(huì)全亂套。YOLOv5官方訓(xùn)練時(shí)的預(yù)處理邏輯是BGR格式讀圖 - 轉(zhuǎn)RGB - 像素值除以255歸一化 - 按ImageNet的mean和std做標(biāo)準(zhǔn)化。對(duì)應(yīng)到AIPP配置aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_h: 640 src_image_size_w: 640 csc_switch: true rbuv_swap_switch: false mean_chn_0: 123.675 mean_chn_1: 116.28 mean_chn_2: 103.53 var_reci_chn_0: 0.01712475 var_reci_chn_1: 0.017507 var_reci_chn_2: 0.01742919 }配置里的mean是ImageNet均值乘以255var_reci是標(biāo)準(zhǔn)差倒數(shù)的再除以255即var_reci 1/(std*255)。幾個(gè)容易翻車(chē)的地方第一個(gè)是var_reci是倒數(shù)和放縮后的值不是方差本身很多人把std或者方差直接填進(jìn)去輸出結(jié)果完全亂套。第二個(gè)是csc_switch打開(kāi)后硬件會(huì)做色域轉(zhuǎn)換但YOLOv5本來(lái)是在RGB上訓(xùn)練的如果AIPP配置里rgb_swap開(kāi)關(guān)弄反那圖像通道順序就變了模型看到的是一張顏色錯(cuò)亂但輪廓正確的圖檢測(cè)結(jié)果會(huì)明顯變差。第三個(gè)是src_image_size_h和src_image_size_w這兩個(gè)字段在有的CANN版本里填寫(xiě)的是模型輸入尺寸有的版本填寫(xiě)的是原始圖像尺寸不同的ATC版本行為有差異建議以官方文檔為準(zhǔn)多試一次對(duì)比結(jié)果就能確認(rèn)。3.4 動(dòng)態(tài)shape怎么取舍實(shí)際部署YOLO時(shí)有時(shí)候希望同一個(gè)模型能適配不同分辨率或者不同batch大小的輸入。ATC支持動(dòng)態(tài)shape通過(guò)--dynamic_batch_size或--dynamic_image_size參數(shù)指定。但我的建議是能不用就不用必須用就盡量限定范圍。用動(dòng)態(tài)batch配合多路視頻流確實(shí)很推薦命令寫(xiě)法如下atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_dynbs \ --input_shapeimages:-1,3,640,640 \ --dynamic_batch_size1,2,4,8 \ --soc_versionAscend310P3這樣生成的OM模型在推理時(shí)可以通過(guò)aclmdlSetDynamicBatchSize接口在batch 1到8之間動(dòng)態(tài)切換非常適合多個(gè)視頻流動(dòng)態(tài)匯入的場(chǎng)景。但要注意動(dòng)態(tài)batch會(huì)在模型里為每種batch size做優(yōu)化模型體積和內(nèi)存占用變大。而且一旦batch太大性能不升反降——300V單卡推理時(shí)把太多幀塞進(jìn)一次推理反而會(huì)導(dǎo)致某個(gè)中間算子的執(zhí)行時(shí)間被拉長(zhǎng)吞吐下降。我實(shí)測(cè)下來(lái)Atlas 300V上YOLOv5s的batch不超過(guò)8時(shí)吞吐是線性增長(zhǎng)的再往上收益明顯放緩就盡量不要超過(guò)8了。動(dòng)態(tài)分辨率問(wèn)題更復(fù)雜因?yàn)椴煌叽缦绿卣鲌D大小不同AscendCL在計(jì)算時(shí)會(huì)觸發(fā)多套內(nèi)存布局和算子調(diào)度策略性能和穩(wěn)定性都很難保證。我的經(jīng)驗(yàn)是部署時(shí)直接固定模型輸入尺寸640用的最多如果需要處理更小的圖像在預(yù)處理階段統(tǒng)一resize到640不要?jiǎng)幽Ｐ偷膕hape。4. 用AscendCL寫(xiě)YOLO推理程序的完整骨架模型轉(zhuǎn)好之后就到了落地環(huán)節(jié)。這一節(jié)我給出一套能直接跑的AscendCL推理框架包含初始化、顯存管理、推理執(zhí)行、后處理四個(gè)核心部分每一段代碼都逐行解釋為什么這么寫(xiě)。4.1 初始化和設(shè)備管理AscendCL的初始化方式跟CUDA有一些相似但也有自己的特點(diǎn)。核心流程是ao::Error ret aclInit(nullptr); // 設(shè)置計(jì)算設(shè)備0表示第一張卡 ret aclrtSetDevice(0); aclrtContext context; ret aclrtCreateContext(context, 0); uint32_t modelId; ret aclmdlLoadFromFile(yolov5s.om, modelId);**注意順序**必須先aclInit再aclrtSetDevice之后才能aclrtCreateContext。context創(chuàng)建后后續(xù)所有內(nèi)存申請(qǐng)、模型加載都跟這個(gè)context綁定。如果程序里用了多線程每個(gè)線程要用aclrtCreateContext創(chuàng)建自己的context否則并發(fā)訪問(wèn)會(huì)互相干擾。在Atlas 300V 24G這種多卡場(chǎng)景下還要注意ACL設(shè)備編號(hào)的分配。如果機(jī)器里插了兩張卡系統(tǒng)會(huì)識(shí)別成device 0和device 1。多進(jìn)程各自加載一個(gè)設(shè)備要顯式往各自設(shè)備里綁定。很多人在單卡上跑通之后換到多卡環(huán)境就報(bào)“device busy”或“context mismatch”基本都是在設(shè)備初始化時(shí)沒(méi)做好隔離。4.2 輸入輸出的內(nèi)存管理與拷貝模型加載后我們不能直接往里塞數(shù)據(jù)必須通過(guò)模型描述信息獲取輸入輸出的名字、大小和結(jié)構(gòu)然后分配對(duì)應(yīng)的內(nèi)存。aclmdlDesc *modelDesc aclmdlCreateDesc(); aclmdlGetDesc(modelDesc, modelId); size_t inputSize aclmdlGetInputSizeByName(modelDesc, images); size_t outputSize aclmdlGetOutputSizeByIndex(modelDesc, 0); void *inputBuf nullptr; void *outputBuf nullptr; aclrtMalloc(inputBuf, inputSize, ACL_MEM_MALLOC_NORMAL_ONLY); aclrtMalloc(outputBuf, outputSize, ACL_MEM_MALLOC_NORMAL_ONLY);這里有一個(gè)值得強(qiáng)調(diào)的經(jīng)驗(yàn)推理程序不要頻繁申請(qǐng)和釋放顯存。我見(jiàn)過(guò)很多初版代碼每一幀都aclrtMalloc申請(qǐng)、推理完aclrtFree釋放運(yùn)行十幾分鐘沒(méi)問(wèn)題但跑幾小時(shí)之后內(nèi)存碎片越來(lái)越嚴(yán)重最終報(bào)無(wú)法分配連續(xù)顯存的錯(cuò)誤。正確做法是在啟動(dòng)時(shí)一次性分配好輸入輸出緩沖區(qū)推理循環(huán)中反復(fù)復(fù)用進(jìn)程結(jié)束再統(tǒng)一釋放。數(shù)據(jù)從CPU側(cè)到NPU側(cè)的拷貝用aclrtMemcpyaclrtMemcpy(inputBuf, inputSize, hostInput, inputSize, ACL_MEMCPY_HOST_TO_DEVICE);這里有個(gè)隱藏的約束輸入數(shù)據(jù)在host側(cè)的內(nèi)存要連續(xù)。很多用OpenCV讀圖的代碼如果沒(méi)做resetize和concat數(shù)據(jù)是不連續(xù)的拷貝會(huì)報(bào)錯(cuò)或者讀出錯(cuò)誤數(shù)據(jù)。所以較穩(wěn)妥的做法是讀圖后第一時(shí)間統(tǒng)一復(fù)制到一塊連續(xù)內(nèi)存里再做后續(xù)操作。4.3 推理執(zhí)行準(zhǔn)備好輸入輸出后執(zhí)行推理只需要一條調(diào)用ret aclmdlExecute(modelId);aclmdlExecute是同步接口返回時(shí)輸出已經(jīng)就緒。對(duì)于Atlas 300V跑YOLOv5s這種模型單幀推理時(shí)間在幾毫秒量級(jí)同步模式的延遲完全可接受。如果要追求更高吞吐可以用aclmdlExecuteAsync把推理放到異步流上執(zhí)行。異步模式下需要自己管理事件同步代碼復(fù)雜度會(huì)明顯增加。我的一個(gè)經(jīng)驗(yàn)是在YOLO這種任務(wù)上如果單幀延遲本身只有幾毫秒同步模式就夠用了——把精力更多地花在后處理和流水線編排上往往比摳推理執(zhí)行那幾毫秒更劃算。4.4 后處理解碼加NMS要寫(xiě)對(duì)OM模型輸出的原始張量并不是最終的檢測(cè)框必須經(jīng)過(guò)解碼和NMS后處理。YOLOv5s的推理輸出是三個(gè)特征層的原始tensor分別對(duì)應(yīng)80x80、40x40、20x20大小的特征圖。每個(gè)cell會(huì)預(yù)測(cè)多個(gè)框包含邊界框坐標(biāo)、置信度和各個(gè)類(lèi)別的概率。后處理大體分兩步第一步是解碼把網(wǎng)絡(luò)輸出轉(zhuǎn)化為目標(biāo)框坐標(biāo)。YOLOv5輸出的是相對(duì)于輸入圖片大小的相對(duì)坐標(biāo)要乘以輸入尺寸才能換算成像素坐標(biāo)。這一步需要讀取模型輸出的具體信息遍歷每個(gè)特征層的每個(gè)cell。這里要提一個(gè)容易出錯(cuò)的細(xì)節(jié)ATC轉(zhuǎn)換后的OM模型輸出順序跟PyTorch里model的輸出順序不一定完全一致。我發(fā)現(xiàn)有時(shí)候PyTorch是從大特征圖到小特征圖輸出而OM也基本保持了原順序但穩(wěn)妥起見(jiàn)最好打印出三個(gè)輸出tensor的shape確認(rèn)一下別假設(shè)順序一定正確。第二步是篩框和NMS按置信度閾值過(guò)濾低分框再對(duì)每個(gè)類(lèi)別做NMS去除重疊度高的重復(fù)框。NMS邏輯本身不復(fù)雜但在高幀率場(chǎng)景下容易拖后腿。如果圖像里目標(biāo)多、類(lèi)別多純CPU單線程N(yùn)MS可能占掉整條推理鏈路的30%以上。一個(gè)實(shí)用的優(yōu)化辦法是在多路視頻流場(chǎng)景讓每路視頻的NMS跑在不同的工作線程上互不阻塞整體吞吐提升非常明顯。YOLOv8和YOLOv5在后處理上有差異。YOLOv8輸出了一個(gè)shape為[1, 84, 8400]的大tensor前4個(gè)是框坐標(biāo)cx, cy, w, h剩下80個(gè)是類(lèi)別概率。YOLOv8沒(méi)有錨框概念解碼省事一些但NMS依然是必須的。4.5 完整推理循環(huán)的偽代碼把上面幾塊拼起來(lái)推理循環(huán)的骨架大概是初始化ACL和設(shè)備 - 加載模型 申請(qǐng)固定緩沖區(qū)輸入/輸出 循環(huán) 讀一幀圖像 resize 填充letterbox做預(yù)處理 拷貝到設(shè)備內(nèi)存 aclmdlExecute 推理 拷回主機(jī)內(nèi)存 解碼 置信度過(guò)濾 NMS 繪制或發(fā)送結(jié)果 退出 釋放內(nèi)存 - 卸載模型 - 銷(xiāo)毀context - aclFinalize這個(gè)循環(huán)看似簡(jiǎn)單真正跑起來(lái)才發(fā)現(xiàn)工程上最難的不是模型執(zhí)行而是前處理和整個(gè)流水線的穩(wěn)定性。把每一路視頻流的延遲控制住、把隊(duì)列深度控制住、把內(nèi)存復(fù)用做好這些才是部署YOLO時(shí)最花時(shí)間的部分。5. 部署踩坑實(shí)錄與性能調(diào)優(yōu)方向最后這部分我把真實(shí)遇到過(guò)的坑和調(diào)優(yōu)方向整理出來(lái)每個(gè)點(diǎn)后面都加了一個(gè)處置思路希望你能繞過(guò)這些我兜過(guò)的圈子。5.1 AIPP預(yù)處理不一致導(dǎo)致精度崩塌背景在一次項(xiàng)目里把YOLOv5s模型從GPU遷移到Atlas 300V轉(zhuǎn)出來(lái)的OM模型在顯卡上檢測(cè)好好的在昇騰上框的位置偏了、置信度全掉到0.3以下。查了一天最后發(fā)現(xiàn)是AIPP配置里減均值歸一化沒(méi)做模型直接吃到了0到255的原始像素值。處置思路重新梳理訓(xùn)練時(shí)的預(yù)處理鏈路用letterbox把原圖resize到640然后除以255再做標(biāo)準(zhǔn)化。把標(biāo)準(zhǔn)化系數(shù)用逐像素對(duì)比驗(yàn)證打印AIPP預(yù)處理后的輸入圖像和PyTorch預(yù)處理后的圖像確認(rèn)數(shù)值范圍一致。AIPP配置和訓(xùn)練預(yù)處理只要有一個(gè)環(huán)節(jié)對(duì)不上精度問(wèn)題就不可避免。5.2 多路視頻流的推理編排要做成生產(chǎn)者-消費(fèi)者模型背景一開(kāi)始用最簡(jiǎn)單的方式每路視頻單獨(dú)一個(gè)線程做完整鏈路——拉流、解碼、預(yù)處理、推理、后處理。視頻路數(shù)一多頻繁切換線程CPU占用急劇上升推理吞吐反而下降。處置思路改成標(biāo)準(zhǔn)的生產(chǎn)者-消費(fèi)者流水線。每路視頻拉流解碼線程負(fù)責(zé)它自己的采集解碼后的幀放進(jìn)無(wú)鎖隊(duì)列推理線程從隊(duì)列里湊滿一個(gè)batch再統(tǒng)一推理后處理線程從輸出隊(duì)列拿到結(jié)果并行處理。隊(duì)列容量要給上限防止某一路卡頓導(dǎo)致內(nèi)存無(wú)限制增長(zhǎng)。這個(gè)模式下整機(jī)吞吐從原來(lái)的不到100幀每秒提升到了400幀每秒以上。5.3 用msprof定位性能瓶頸而不是靠猜背景模型單幀延遲偏大一開(kāi)始懷疑是量化精度問(wèn)題浪費(fèi)了大量時(shí)間在模型轉(zhuǎn)換上。后來(lái)用msprof工具看耗時(shí)分解才發(fā)現(xiàn)接近一半時(shí)間花在了數(shù)據(jù)拷貝上——每次推理前都新malloc了內(nèi)存拷貝又用了contiguous外的非連續(xù)內(nèi)存。處置思路先用msprof生成profiling數(shù)據(jù)看看耗時(shí)分布在哪幾個(gè)階段。CANN的profiling工具能精確列出每個(gè)算子的執(zhí)行時(shí)間和數(shù)據(jù)傳輸時(shí)間。改掉了內(nèi)存反復(fù)申請(qǐng)的問(wèn)題之后推理耗時(shí)下降了將近一半。用工具定位問(wèn)題是最高效的排查方式比靠直覺(jué)改代碼有效率得多。5.4 INT8量化是性能優(yōu)化的分水嶺背景模型在FP16下跑單卡吞吐基本符合預(yù)期但想要在同樣一臺(tái)機(jī)器上支持更多路視頻算力就顯得不夠了。做INT8 訓(xùn)練后量化之后模型體積縮小約四分之一推理延遲降低到原來(lái)的約六成檢測(cè)精度只掉了不到兩個(gè)點(diǎn)對(duì)于實(shí)際業(yè)務(wù)完全可接受。處置思路用CANN自帶的AMCT工具做離線量化用小規(guī)模但能覆蓋典型場(chǎng)景的數(shù)據(jù)集做校準(zhǔn)。量化時(shí)不要只跑一張圖要盡可能多樣性地覆蓋背景、目標(biāo)大小和光照變化量化后的模型記得用至少一萬(wàn)張真實(shí)業(yè)務(wù)圖做回歸驗(yàn)證。對(duì)YOLO這種檢測(cè)模型INT8量化帶來(lái)的收益非?？捎^有條件一定要做。5.5 一些看似不起眼但影響全局的配置進(jìn)程退出前一定要aclFinalize否則設(shè)備資源釋放不徹底二次啟動(dòng)會(huì)報(bào)設(shè)備被占用。異步推理時(shí)stream和event的數(shù)量是有限的不要每幀都新建要啟動(dòng)時(shí)創(chuàng)建好復(fù)用。算力規(guī)格允許的情況下優(yōu)先把視頻解碼也放到硬件上CPU的空閑資源留給后處理。多卡機(jī)器要注意PCIe帶寬分配兩張卡同時(shí)大批量拷貝數(shù)據(jù)時(shí)可能互相搶帶寬導(dǎo)致兩邊性能都下降。6. 我個(gè)人在實(shí)際部署中積累的一點(diǎn)體會(huì)把YOLO部署到Atlas 300V 24G上整個(gè)鏈路的心態(tài)變化大概要經(jīng)歷三個(gè)階段一開(kāi)始被各種新名詞淹沒(méi)容易急躁中間跑通后逐漸上手覺(jué)得不過(guò)如此真正做性能調(diào)優(yōu)和多路跑量時(shí)才發(fā)現(xiàn)深度學(xué)習(xí)模型的部署除了模型本身還有大量數(shù)據(jù)搬運(yùn)、內(nèi)存管理、異步調(diào)度、持久化穩(wěn)定性的功夫。這套流程中我最想叮囑新人的一點(diǎn)是**用DEBUG時(shí)不要大面積改配置一次只改一個(gè)變量。**AIPP配置里的一個(gè)參數(shù)、輸入shape是否固定、batch大小、量化開(kāi)關(guān)這些變量之間會(huì)互相影響。第一次部署建議固定住除一個(gè)變量外的一切比如只用固定shape、只用FP16把整個(gè)鏈路先跑通再考慮量化、動(dòng)態(tài)batch這些高級(jí)項(xiàng)。最后說(shuō)一句關(guān)于選型的建議如果你只是臨時(shí)跑個(gè)Demo那用GPU最順手但如果要做量產(chǎn)級(jí)的多路視頻分析服務(wù)且在意功耗、顯存、性價(jià)比Atlas 300V 24G是一個(gè)值得認(rèn)真評(píng)估的選項(xiàng)。它雖然有不小的學(xué)習(xí)成本但一旦把工具鏈跑熟后續(xù)換模型架構(gòu)、加路數(shù)、擴(kuò)大部署規(guī)模都是在同一個(gè)框架里做增量工作長(zhǎng)期收益很可觀。