換到性能調(diào)優(yōu))
最近被問得最多的兩個(gè)問題一個(gè)是“atlas部署yolo怎么搞”另一個(gè)就是“atlas 300v 24g 是運(yùn)算加速卡嗎”。我猜很多人是在選型階段或者剛拿到卡準(zhǔn)備跑模型對這張卡的認(rèn)識還停留在“華為出的一個(gè)加速卡”的層面。剛好這段時(shí)間我自己完完整整把一張Atlas 300V 24G從拆箱、驅(qū)動、工具鏈到跑通YOLOv5推理走了一遍中間踩了不少坑也把很多網(wǎng)上說得模棱兩可的細(xì)節(jié)給確認(rèn)了。這篇就把整條鏈路寫清楚從這卡到底是什么到模型怎么轉(zhuǎn)再到推理代碼怎么調(diào)、常見報(bào)錯(cuò)怎么排查一次性講透。如果你是屬于下面這幾類人這篇文章應(yīng)該正好對胃口剛拿到Atlas 300V準(zhǔn)備做視頻檢測的部署工程師正在評估推理卡選型、想知道24G顯存到底有沒有用的算法負(fù)責(zé)人以及被要求“把YOLO部署到昇騰上”但還沒摸清CANN、ATC、OM這些概念的同學(xué)。我會盡量用部署現(xiàn)場的口吻講少一點(diǎn)官方文檔腔多一點(diǎn)實(shí)操里能直接用上的東西。1. 先說結(jié)論Atlas 300V 24G到底是一張什么卡1.1 “運(yùn)算加速卡”這個(gè)說法不準(zhǔn)確準(zhǔn)確叫AI推理加速卡直接回應(yīng)標(biāo)題里的問題Atlas 300V 24G是運(yùn)算加速卡但要加一個(gè)限定詞——它是一張AI推理加速卡不是一張通用的并行計(jì)算卡。這個(gè)區(qū)別很重要。我們平時(shí)說的GPU比如NVIDIA的A100、L40S那是通用GPGPU既能做訓(xùn)練也能做推理還能跑CUDA做各種通用計(jì)算。Atlas 300V不一樣它內(nèi)部核心是昇騰310P芯片硬件上大量面積給了AI Core這種專用計(jì)算單元算力調(diào)度邏輯、指令集、內(nèi)存訪問模式都是圍繞神經(jīng)網(wǎng)絡(luò)算子設(shè)計(jì)的。你可以把它理解成一個(gè)“模型推理專用加速器”跑卷積、矩陣乘法、激活函數(shù)這些深度學(xué)習(xí)算子非?？斓阋钦嫦肽盟軅€(gè)通用并行任務(wù)或者寫一段自定義的向量化計(jì)算邏輯基本無從下手。所以很多第一次接觸Atlas的人會陷入一個(gè)思維誤區(qū)拿它去和GPU做全面對比問“能不能跑CUDA”“能不能兼容PyTorch”。實(shí)話說不兼容。PyTorch跑在Atlas上要么通過MindSpore或者torch_npu這類適配層重新編譯算子要么得先把模型導(dǎo)成ONNX再轉(zhuǎn)成昇騰自己的OM格式然后調(diào)用ACLAscend Computing Language的接口去推理。這套流程我在后面幾節(jié)里會詳細(xì)講這里先記住一個(gè)基本認(rèn)知Atlas 300V不是用來替代你手頭GPU的它是給“已經(jīng)訓(xùn)練好的模型”做固定場景批量推理用的。從應(yīng)用形態(tài)上看Atlas 300V 24G是一塊標(biāo)準(zhǔn)的PCIe板卡常見形態(tài)是單插槽寬度被動散熱或者主動散熱都有最大功耗我記得在幾十瓦量級和一張動輒兩三百瓦的GPU比起來功耗低得非常明顯。這意味著什么一臺普通的2U服務(wù)器里你可以輕松插上四五張甚至更多組成一個(gè)高密度推理節(jié)點(diǎn)。比如一個(gè)需要同時(shí)處理幾十路攝像頭畫面的視頻分析系統(tǒng)用GPU去跑卡的功耗和成本都會很難受用Atlas 300V這種低功耗推理卡反而很合適——單卡能做的事情不多但堆卡密度高整體吞吐很可觀。這一點(diǎn)在后面的性能調(diào)優(yōu)部分我會專門展開。1.2 24G這個(gè)容量到底能干什么用很多第一次看到“24G”的人第一反應(yīng)是“這卡比我的3060顯存還大是不是很?！?。要潑一盆冷水Atlas 300V上的24G和我們一般理解里的GPU顯存不太一樣它的作用是給推理模型存放權(quán)重、中間特征圖和運(yùn)行時(shí)buffer用的。大容量當(dāng)然有好處你能同時(shí)加載更大的模型、開更大的batch或者同時(shí)駐留多個(gè)模型但它是“容量”優(yōu)勢不是“帶寬”優(yōu)勢。如果你是想在24G里跑大語言模型那思路就錯(cuò)了——Atlas 300V的定位是視覺推理場景最舒服的活是YOLO、ResNet這類CNN模型的目標(biāo)檢測、分類、分割任務(wù)。以YOLOv5s舉例FP16精度的權(quán)重本身只有不到30MB推理一張640x640圖片時(shí)中間特征圖占用的空間也就幾百M(fèi)B。哪怕batch開到16整個(gè)模型的運(yùn)行時(shí)內(nèi)存可能也就占用1~2GB。那么24G是不是浪費(fèi)不一定。你在實(shí)際部署時(shí)一個(gè)很常見的做法是把多個(gè)模型同時(shí)加載進(jìn)內(nèi)存或者把幾路視頻流各自建獨(dú)立的推理實(shí)例這種情況下內(nèi)存就是硬通貨。比如同一張卡里掛YOLOv5做檢測、掛一個(gè)人臉識別模型做特征提取再掛一個(gè)分類模型做二次過濾如果把所有模型的推理實(shí)例都跑在一個(gè)NPU上并發(fā)調(diào)度24G的余量會給你很大的設(shè)計(jì)空間。算力方面Atlas 300V 24G官方標(biāo)稱的INT8算力在百TOPS級別FP16大概減半。這個(gè)數(shù)字放在今天的AI加速卡市場里不算最頂級但考慮到它的功耗能效比確實(shí)不錯(cuò)。實(shí)際跑YOLOv5s如果前處理和后處理都做了比較充分的優(yōu)化單卡跑到幾百FPS是常見水平。別拿這個(gè)數(shù)字和張A100比A100跑同樣的模型也不是不能跑但你要比的是“每瓦特能處理多少路視頻流”Atlas 300V這種卡的優(yōu)勢一下就出來了。2. 部署前環(huán)境準(zhǔn)備版本永遠(yuǎn)是最大的坑2.1 硬件確認(rèn)與驅(qū)動安裝不管你是買的整機(jī)還是只有一張板卡先確認(rèn)服務(wù)器本身沒問題。Atlas 300V 24G走的是PCIe 3.0 x16接口理論上近五六年內(nèi)的x86服務(wù)器都有這個(gè)插槽。關(guān)鍵是供電有些老的服務(wù)器PCIe插槽供電能力弱尤其是插滿多張卡之后建議提前確認(rèn)服務(wù)器背板供電規(guī)格避免推理時(shí)掉卡或者性能不穩(wěn)定。硬件裝好后最優(yōu)先的一步就是裝驅(qū)動和固件。華為的昇騰軟件棧分成幾個(gè)層次最下面是HDKHuawei Development Kit里面包含驅(qū)動和固件再往上是CANNAscend Computing NN工具鏈相當(dāng)于CUDA Toolkit的角色。裝驅(qū)動的過程我用的是華為官方提供的run包在root權(quán)限下執(zhí)行安裝安裝時(shí)會自動加載內(nèi)核模塊。裝完先別急著裝CANN先用命令npu-smi info驗(yàn)證一下驅(qū)動是否工作正常。如果能看到卡的名稱、芯片型號、顯存大小、溫度這些信息說明底層已經(jīng)通了這時(shí)候再繼續(xù)往上層走。這里強(qiáng)烈建議裝完驅(qū)動后做一個(gè)記錄把npu-smi info里顯示的芯片型號抄下來。后面模型轉(zhuǎn)換時(shí)要填--soc_version參數(shù)這個(gè)參數(shù)對不上ATC轉(zhuǎn)換必然報(bào)錯(cuò)。比如Atlas 300V Pro 24G用的昇騰310P系列芯片不同小步進(jìn)的soc_version寫法不一樣常見有Ascend310P1、Ascend310P3等裝完驅(qū)動npu-smi info里看到的芯片型號是最直接的參考。2.2 CANN工具鏈的版本對齊裝CANN之前先把版本對應(yīng)關(guān)系查清楚。昇騰整個(gè)軟件棧對版本匹配要求比較嚴(yán)格驅(qū)動版本、固件版本、CANN版本三者之間有配套關(guān)系如果你隨便拿一個(gè)舊版本驅(qū)動配一個(gè)新版本CANN很可能會出現(xiàn)“能裝上但跑不通”的情況。我這次踩過最典型的坑就是驅(qū)動是舊版本的CANN用了最新的6.x結(jié)果模型轉(zhuǎn)換和推理時(shí)總是報(bào)一些莫名其妙的錯(cuò)誤比如runtime初始化失敗、設(shè)備不存在查了半天最后把所有組件都降到配套版本才解決。安裝時(shí)建議用一個(gè)干凈的Ubuntu 20.04或者22.04系統(tǒng)x86_64架構(gòu)。整個(gè)安裝流程可以拆成三步# 1. 以root身份安裝HDK驅(qū)動固件 ./Ascend-hdk-*.run --full --install # 2. 安裝CANN toolkit ./Ascend-cann-toolkit_*.run --install # 3. 設(shè)置環(huán)境變量 source /usr/local/Ascend/ascend-toolkit/set_env.shCANN裝好之后ascend-toolkit目錄下會有atc、msame等工具。atc是模型轉(zhuǎn)換工具負(fù)責(zé)把ONNX轉(zhuǎn)成OMmsame是一個(gè)簡易的推理測試工具后面驗(yàn)證模型用得上。建議裝完后順手建一個(gè)環(huán)境變量文件把set_env.sh的source語句寫進(jìn)去不然每次新開終端都要手動執(zhí)行一遍。還有一點(diǎn)如果你的操作系統(tǒng)是CentOS或者其他較老的發(fā)行版裝之前先確認(rèn)內(nèi)核版本是否在官方支持列表內(nèi)。昇騰驅(qū)動是內(nèi)核模塊內(nèi)核版本和gcc版本不匹配會導(dǎo)致編譯失敗。真遇到編譯失敗不用死磕先確認(rèn)內(nèi)核頭文件是不是已經(jīng)裝了yum install kernel-devel-$(uname -r)這種操作會很常見。2.3 CANN的“系統(tǒng)里到底多了什么”裝完CANN后很多人會疑惑這玩意兒裝了一大堆東西到底哪些是我用得上的我簡單梳理一下幾個(gè)核心組件atc模型轉(zhuǎn)換編譯器。管你把ONNX、TensorFlow的pb、MindSpore的模型轉(zhuǎn)成OM格式轉(zhuǎn)換時(shí)可以指定輸入shape、AIPP配置、量化參數(shù)。msame離線推理驗(yàn)證工具。不需要寫代碼給定一個(gè)OM模型和輸入數(shù)據(jù)跑一次推理輸出結(jié)果適合快速驗(yàn)證模型在NPU上是否正確運(yùn)行。pyACLACL的Python綁定。官方提供了一套Python接口繞開C編譯的麻煩直接寫Python調(diào)用推理卡。profiling工具性能分析工具。如果你發(fā)現(xiàn)卡上的推理性能達(dá)不到預(yù)期可以靠它看每個(gè)算子的耗時(shí)、NPU利用率、帶寬瓶頸在哪兒。把這些工具用熟了你部署一個(gè)新模型的基本流程就固定了拿到模型權(quán)重轉(zhuǎn)ONNX用atc轉(zhuǎn)成OM再用msame或pyACL做推理驗(yàn)證最后按業(yè)務(wù)場景封裝成服務(wù)。理解了這個(gè)流程你就知道為什么我說Atlas的部署鏈路雖然麻煩但一旦版本環(huán)境理順了后面換模型其實(shí)挺模式的。3. YOLO模型上卡全流程從pt到om再到推理3.1 首先導(dǎo)出一個(gè)干凈的ONNX在Atlas 300V上跑YOLO前提是得有一個(gè)ONNX模型。為什么是ONNX因?yàn)锳TC目前最穩(wěn)定的輸入格式就是ONNXPyTorch的pt文件不能直接吃TensorFlow的pb也不是最優(yōu)路徑。YOLOv5官方倉庫本身帶了導(dǎo)出腳本操作起來很直接python export.py --weights yolov5s.pt --include onnx --opset 11這個(gè)命令會生成一個(gè)yolov5s.onnx。這里要特別注意幾個(gè)細(xì)節(jié)第一輸入尺寸最好固定。YOLOv5默認(rèn)訓(xùn)練尺寸是640x640導(dǎo)出時(shí)默認(rèn)就是640x640。你在做推理時(shí)如果圖片分辨率不固定后面要么通過AIPP做縮放要么在CPU側(cè)做預(yù)處理。推理卡在做靜態(tài)shape的模型時(shí)性能是最好的所以強(qiáng)烈建議導(dǎo)出時(shí)就固定一個(gè)輸入尺寸不要使用動態(tài)shape。雖然ATC支持動態(tài)shape但動態(tài)shape意味著NPU運(yùn)行時(shí)需要?jiǎng)討B(tài)規(guī)劃內(nèi)存和計(jì)算圖往往會對性能產(chǎn)生不小的損耗。第二導(dǎo)出時(shí)不要包含后處理。YOLOv5的官方導(dǎo)出腳本默認(rèn)只導(dǎo)出到檢測頭之前的網(wǎng)絡(luò)結(jié)構(gòu)輸出是類似[1, 25200, 85]的張量也就是每個(gè)anchor框的坐標(biāo)、置信度和類別概率。很多業(yè)務(wù)方希望導(dǎo)出端到端的模型把NMS也包進(jìn)去這樣做的好處是部署代碼簡單但壞處是ATC轉(zhuǎn)換可能失敗后處理算子不一定是昇騰的高效算子反而不如把NMS留在CPU上用成熟的OpenCV和NumPy實(shí)現(xiàn)來得靈活。我建議的做法是ONNX只包含主干網(wǎng)絡(luò)和檢測頭NMS全部留在應(yīng)用層這樣模型的通用性和可調(diào)試性都更好。導(dǎo)出后可以用onnx庫快速檢查一下模型的基本信息import onnx model onnx.load(yolov5s.onnx) print(model.graph.input) print(model.graph.output)確認(rèn)輸入是[1,3,640,640]輸出是[1,25200,85]之類就說明模型導(dǎo)出的結(jié)構(gòu)是完整的。3.2 用ATC把ONNX轉(zhuǎn)成OMONNX準(zhǔn)備好之后下一步就是用atc做轉(zhuǎn)換。命令長這樣atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --output_typeFP16簡單解釋幾個(gè)關(guān)鍵參數(shù)--framework5表示輸入是ONNX--output是輸出OM文件的前綴--input_shape固定輸入尺寸和batch--soc_version填型號對應(yīng)的芯片版本比如Atlas 300V Pro常見的Ascend310P3--output_typeFP16把網(wǎng)絡(luò)權(quán)重轉(zhuǎn)成半精度推理速度和內(nèi)存占用都會更友好。轉(zhuǎn)換過程可能遇到的主要問題是算子不支持。比如YOLOv5導(dǎo)出時(shí)如果opset版本太高某些算子ATC不認(rèn)識會直接報(bào)錯(cuò)。解決辦法一般是把opset降到11或12重新導(dǎo)出AT科學(xué)在ONNX算子兼容性上對于低版本的算子支持要好很多。如果遇到單個(gè)算子不支持的情況就需要通過修改模型結(jié)構(gòu)規(guī)避比如替換某些自定義激活函數(shù)、把某些特殊上采樣方式改成標(biāo)準(zhǔn)Upsample。這一步是最花時(shí)間的但成熟模型一般不太需要大改。ATC轉(zhuǎn)換成功后會生成一個(gè).om文件。這個(gè)文件可以理解成“針對當(dāng)前芯片版本的NPU可執(zhí)行程序”它和具體的soc_version綁定也就是說你在Ascend310P3上轉(zhuǎn)換的OM拿去另一個(gè)芯片型號不同的Atlas卡上是跑不了的。這也是為什么前面強(qiáng)調(diào)要提前確認(rèn)芯片型號。3.3 AIPP到底要不要配怎么配AIPP是昇騰里一個(gè)容易被忽視但影響很大的概念。簡單說AIPP是一套預(yù)處理加速機(jī)制讓你在模型輸入之前把圖像縮放、色域轉(zhuǎn)換、歸一化這些操作從CPU挪到NPU的專用硬件單元里去執(zhí)行。配置好AIPP后CPU只需要把原始圖像數(shù)據(jù)扔給卡卡在硬件層面上幫你完成resize和RGB/BGR轉(zhuǎn)換能明顯降低CPU開銷提升整條處理鏈路的吞吐。AIPP的配置是通過一個(gè)單獨(dú)的cfg文件在ATC轉(zhuǎn)換時(shí)用--insert_op_conf參數(shù)嵌進(jìn)OM里。下面是一個(gè)常見的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: true }這個(gè)配置的含義是輸入圖像是RGB888格式的原始8位數(shù)據(jù)尺寸已經(jīng)是640x640同時(shí)做色域轉(zhuǎn)換和R/B通道交換。配置好AIPP后你的預(yù)處理就簡化成“把圖像數(shù)據(jù)按指定尺寸放好直接喂給卡”剩下的交給硬件。但這里有一個(gè)YOLO系列獨(dú)有的坑LetterBox。YOLOv5在預(yù)處理時(shí)并不是簡單的resize而是先把長邊縮放到640再把短邊填充到640保證原始寬高比不變。AIPP自帶的能力里resize是硬縮放沒有l(wèi)etterbox的“等比縮放加填充”這種組合操作。如果你直接把一張1920x1080的圖扔給AIPP做resize它會變成變形的640x640推理結(jié)果完全不可用。我這次實(shí)際采用了兩種方案之一第一種如果業(yè)務(wù)上允許輕微的形變比如車牌識別或者文檔檢測對這種形變不敏感直接讓AIPP做resize推理速度最快第二種如果場景對檢測框精度要求高就在CPU側(cè)先完成letterbox轉(zhuǎn)換后的640x640圖再交給AIPP做色域轉(zhuǎn)換和歸一化AIPP不參與resize。選擇哪種方案取決于你對精度的容忍度但你必須清楚AIPP不能自動幫你完成letterbox否則會在預(yù)處理上栽大跟頭。3.4 推理代碼與運(yùn)行驗(yàn)證模型轉(zhuǎn)好后先別急著寫業(yè)務(wù)代碼用msame工具跑一次確認(rèn)模型在卡上真的能輸出正常結(jié)果。msame的用法很簡單msame --model yolov5s_bs1.om \ --input ./input_data.bin \ --output ./output/輸入數(shù)據(jù)建議用一個(gè)預(yù)處理好的640x640 RGB raw文件可以用Python先導(dǎo)出一個(gè)bin。運(yùn)行完之后output目錄下會有一個(gè)二進(jìn)制輸出文件這個(gè)文件就是模型的原始輸出對應(yīng)的就是[1,25200,85]格式。能正常輸出且數(shù)值不為空就說明OM模型本身沒問題。如果msame這一步都過不了就不要往后寫代碼了先回頭查轉(zhuǎn)換參數(shù)。確認(rèn)模型OK之后下一步就可以用pyACL寫推理腳本了。核心流程穩(wěn)定且模式化大致是四個(gè)步驟初始化設(shè)備、加載模型、構(gòu)造輸入輸出、執(zhí)行推理。import acl # 1. 初始化 acl.init() acl.rt.set_device(0) context, ret acl.rt.create_context(0) # 2. 加載模型 model_path byolov5s_bs1.om model_id, ret acl.mdl.load_from_file(model_path) # 3. 準(zhǔn)備輸入輸出簡化示意 input_data preprocess_image(test.jpg) # 返回 numpy 數(shù)組 # 這里需要把 numpy 轉(zhuǎn)成 ACL 的 Tensor/DataBuffer參數(shù)較多建議參考CANN官方sample # 4. 執(zhí)行推理 ret acl.mdl.execute(model_id, input_buffer, output_buffer) # 5. 釋放資源 acl.mdl.unload(model_id) acl.rt.destroy_context(context) acl.rt.reset_device(0) acl.finalize()實(shí)際代碼會比這個(gè)長不少主要在于numpy數(shù)組和ACL數(shù)據(jù)緩沖區(qū)的轉(zhuǎn)換、輸出后處理這兩塊但核心思路就是這個(gè)節(jié)奏。建議不要從零寫直接去CANN安裝目錄下找官方樣例一般有resnet50或者目標(biāo)檢測的sample把里面的輸入輸出處理邏輯抄過來改一改比自己造輪子快得多。推理完成后拿到的是[1,25200,85]的原始張量。后處理要做的事是把位置信息和置信度解析出來然后做NMS去除重疊框。YOLOv5輸出格式里最后85個(gè)維度的前4個(gè)是box坐標(biāo)第5個(gè)是objectness后面80個(gè)是各類別分?jǐn)?shù)。你需要先把box坐標(biāo)按照letterbox變換的縮放比例映射回原圖坐標(biāo)再過濾低置信度框最后做NMS。這部分的優(yōu)化對整體FPS影響很大我后面會專門說。4. 性能調(diào)優(yōu)與問題排查記錄4.1 影響部署體驗(yàn)的三個(gè)關(guān)鍵因素模型能跑通只是第一步真正上線關(guān)注的是吞吐和時(shí)延。在Atlas 300V上部署YOLO我發(fā)現(xiàn)影響最終體驗(yàn)的核心因素有三個(gè)。第一個(gè)是batch size和并發(fā)模式。如果你對時(shí)延敏感用batch1單發(fā)模式單張圖片延遲最低如果你對吞吐更在意盡量把多路視頻幀攢一起用較大batch一次推理比如batch4或batch8卡上計(jì)算單元的利用率會明顯提高。實(shí)際項(xiàng)目中一個(gè)很實(shí)用的方案是建立幀緩沖池把多個(gè)視頻流來源的幀按批湊齊再統(tǒng)一推理吞吐能提升好幾倍。第二個(gè)是前處理和后處理的位置。AIPP能幫忙分擔(dān)resize和色域轉(zhuǎn)換但letterbox和NMS這類操作目前基本只能在CPU上跑。在一個(gè)多路視頻的部署場景里如果每幀圖像的分辨率特別大CPU光做resize和letterbox就可能成為瓶頸你就會看到模型在NPU上算得飛快但整體FPS就是上不去原因是CPU被預(yù)處理拖垮了。我的建議是先用一個(gè)簡單的性能剖析工具看看CPU占用如果預(yù)處理占用了超過30%的CPU優(yōu)先考慮把resize挪到AIPP里或者啟用多線程處理。第三個(gè)是模型量化和精度權(quán)衡。FP16推理比FP32快不少內(nèi)存占用也更低但如果你要追求極致性能可以嘗試INT8量化。ATC支持對ONNX做INT8量化和校準(zhǔn)量化后的YOLOv5s在Atlas 300V上推理速度會有明顯提升精度損失通?？梢越邮?。不過量化需要對驗(yàn)證集做校準(zhǔn)不是一步到位的如果精度掉了太多可以先做部分層量化或混合精度也可以直接回到FP16不用死磕INT8。4.2 常見報(bào)錯(cuò)與現(xiàn)象排查表部署過程中會遇到各種報(bào)錯(cuò)我整理了幾個(gè)最常見的問題和排查思路現(xiàn)象可能原因排查方向npu-smi info看不到卡驅(qū)動未正確加載或PCIe鏈路異常使用lspci | grep -i ascend查看硬件是否被系統(tǒng)識別modprobe drv_pcie手動加載驅(qū)動模塊確認(rèn)BIOS里PCIe slot是否被禁用ATC轉(zhuǎn)換報(bào)錯(cuò)E12001或算子不支持ONNX中算子版本與AT科學(xué)兼容算子不匹配降低onnx opset版本重新導(dǎo)出用onnxsim簡化模型結(jié)構(gòu)把模型里特殊算子替換成標(biāo)準(zhǔn)算子推理輸出全為0或結(jié)果瘋狂預(yù)處理與訓(xùn)練時(shí)不一致核對AIPP的色域配置、歸一化系數(shù)、letterbox方式檢查輸入數(shù)據(jù)是否BGR/RGB順序反了逐個(gè)嘗試不同預(yù)處理策略模型推理FPS遠(yuǎn)低于預(yù)期瓶頸在CPU預(yù)處理或者batch太小先跑msame測純NPU推理耗時(shí)排除CPU干擾將resize和色域轉(zhuǎn)換挪到AIPP增大batch檢查是否有動態(tài)shape導(dǎo)致的額外開銷加載模型報(bào)內(nèi)存不足24G內(nèi)存不足或模型太大/駐留太多實(shí)例用npu-smi info查看顯存占用檢查是否有遺漏釋放的推理實(shí)例降低batch size或同時(shí)駐留模型數(shù)量推理時(shí)隨機(jī)崩潰或復(fù)位供電不足或驅(qū)動固件版本不穩(wěn)定檢查PCIe供電和散熱升級驅(qū)動固件到配套版本查看系統(tǒng)日志中的NPU錯(cuò)誤信息這些排查思路能覆蓋大部分部署問題。如果遇到上述列表以外的情況最有效的方法是去昇騰社區(qū)或者GitHub上搜一下錯(cuò)誤碼很多問題都是文檔里看不到、但社區(qū)里已經(jīng)有人踩過坑并給出解決辦法的。4.3 三個(gè)值得提前知道的“經(jīng)驗(yàn)之談”第一個(gè)經(jīng)驗(yàn)是拿到卡后第一件事是跑通官方sample而不是直接上自己的模型。官方提供的resnet50或者目標(biāo)檢測樣例是經(jīng)過充分驗(yàn)證的環(huán)境如果連官方sample都跑不通說明你的驅(qū)動、CANN版本或服務(wù)器環(huán)境有問題這時(shí)候不要懷疑自己的模型回頭查環(huán)境。我這次是先把resnet50的sample跑通再換成YOLOv5s整體路徑順了很多。第二個(gè)經(jīng)驗(yàn)是升級CANN之前先做回歸。昇騰的軟件棧版本更新頻率很快新版本通常會帶來性能提升和新算子支持但也會帶來兼容性問題。我在部署過程中有一次從CANN 5.1.x升到6.x結(jié)果原本能正常轉(zhuǎn)換的ONNX模型突然報(bào)錯(cuò)最后只能回退到舊版本。如果你當(dāng)前環(huán)境已經(jīng)穩(wěn)定運(yùn)行不要為了一個(gè)“看起來更好”的新版本貿(mào)然升級先在一個(gè)測試環(huán)境里做完整回歸確認(rèn)沒有問題再應(yīng)用到生產(chǎn)上。第三個(gè)經(jīng)驗(yàn)是用profiling工具看數(shù)據(jù)別用猜。很多人覺得推理性能不夠第一反應(yīng)是“換更高規(guī)格的卡”但很多時(shí)候瓶頸根本不在NPU。CANN自帶的profiling工具能給出NPU占用率、算子耗時(shí)、內(nèi)存帶寬等數(shù)據(jù)用數(shù)據(jù)判斷瓶頸在哪里再決定是優(yōu)化預(yù)處理、增大batch還是調(diào)整模型結(jié)構(gòu)比盲目調(diào)參要靠譜得多。最后再分享一點(diǎn)我的實(shí)際感受幾輪折騰下來我的體會是Atlas 300V 24G這類推理加速卡最大的舒適區(qū)是“模型已經(jīng)固定、業(yè)務(wù)已經(jīng)定型、需要海量并發(fā)推理”的階段。如果你還在頻繁改網(wǎng)絡(luò)結(jié)構(gòu)、還在做各種實(shí)驗(yàn)?zāi)荊PU或者直接用CPU都比它方便但如果你已經(jīng)明確要在幾十上百路視頻流上穩(wěn)定跑一個(gè)YOLO模型那它的低功耗、高密度部署特點(diǎn)就會變得非常明顯。一臺服務(wù)器插幾張Atlas 300V一個(gè)標(biāo)準(zhǔn)的視頻分析節(jié)點(diǎn)就搭起來了整體功耗比同級別的GPU方案友好太多。如果你現(xiàn)在正準(zhǔn)備做選型或者剛拿到卡我建議你給自己留出至少一周的環(huán)境熟悉時(shí)間第一天裝驅(qū)動和CANN第二天跑通官方樣例第三天完成自己的YOLO模型轉(zhuǎn)換后面幾天專門調(diào)精度和性能。不要指望半天時(shí)間就能把YOLO跑起來環(huán)境問題、版本問題和預(yù)處理問題都是需要時(shí)間磨的。最后一個(gè)小技巧所有關(guān)鍵步驟的命令、版本號、報(bào)錯(cuò)信息都記錄下來昇騰這套軟件棧的排查可以說大半靠版本記錄手上有記錄遇到問題能少走很多彎路。 昇騰Atlas 300V推理卡部署YOLOv5：從模型轉(zhuǎn)換到性能調(diào)優(yōu)
最近被問得最多的兩個(gè)問題一個(gè)是“atlas部署yolo怎么搞”另一個(gè)就是“atlas 300v 24g 是運(yùn)算加速卡嗎”。我猜很多人是在選型階段或者剛拿到卡準(zhǔn)備跑模型對這張卡的認(rèn)識還停留在“華為出的一個(gè)加速卡”的層面。剛好這段時(shí)間我自己完完整整把一張Atlas 300V 24G從拆箱、驅(qū)動、工具鏈到跑通YOLOv5推理走了一遍中間踩了不少坑也把很多網(wǎng)上說得模棱兩可的細(xì)節(jié)給確認(rèn)了。這篇就把整條鏈路寫清楚從這卡到底是什么到模型怎么轉(zhuǎn)再到推理代碼怎么調(diào)、常見報(bào)錯(cuò)怎么排查一次性講透。如果你是屬于下面這幾類人這篇文章應(yīng)該正好對胃口剛拿到Atlas 300V準(zhǔn)備做視頻檢測的部署工程師正在評估推理卡選型、想知道24G顯存到底有沒有用的算法負(fù)責(zé)人以及被要求“把YOLO部署到昇騰上”但還沒摸清CANN、ATC、OM這些概念的同學(xué)。我會盡量用部署現(xiàn)場的口吻講少一點(diǎn)官方文檔腔多一點(diǎn)實(shí)操里能直接用上的東西。1. 先說結(jié)論Atlas 300V 24G到底是一張什么卡1.1 “運(yùn)算加速卡”這個(gè)說法不準(zhǔn)確準(zhǔn)確叫AI推理加速卡直接回應(yīng)標(biāo)題里的問題Atlas 300V 24G是運(yùn)算加速卡但要加一個(gè)限定詞——它是一張AI推理加速卡不是一張通用的并行計(jì)算卡。這個(gè)區(qū)別很重要。我們平時(shí)說的GPU比如NVIDIA的A100、L40S那是通用GPGPU既能做訓(xùn)練也能做推理還能跑CUDA做各種通用計(jì)算。Atlas 300V不一樣它內(nèi)部核心是昇騰310P芯片硬件上大量面積給了AI Core這種專用計(jì)算單元算力調(diào)度邏輯、指令集、內(nèi)存訪問模式都是圍繞神經(jīng)網(wǎng)絡(luò)算子設(shè)計(jì)的。你可以把它理解成一個(gè)“模型推理專用加速器”跑卷積、矩陣乘法、激活函數(shù)這些深度學(xué)習(xí)算子非?？斓阋钦嫦肽盟軅€(gè)通用并行任務(wù)或者寫一段自定義的向量化計(jì)算邏輯基本無從下手。所以很多第一次接觸Atlas的人會陷入一個(gè)思維誤區(qū)拿它去和GPU做全面對比問“能不能跑CUDA”“能不能兼容PyTorch”。實(shí)話說不兼容。PyTorch跑在Atlas上要么通過MindSpore或者torch_npu這類適配層重新編譯算子要么得先把模型導(dǎo)成ONNX再轉(zhuǎn)成昇騰自己的OM格式然后調(diào)用ACLAscend Computing Language的接口去推理。這套流程我在后面幾節(jié)里會詳細(xì)講這里先記住一個(gè)基本認(rèn)知Atlas 300V不是用來替代你手頭GPU的它是給“已經(jīng)訓(xùn)練好的模型”做固定場景批量推理用的。從應(yīng)用形態(tài)上看Atlas 300V 24G是一塊標(biāo)準(zhǔn)的PCIe板卡常見形態(tài)是單插槽寬度被動散熱或者主動散熱都有最大功耗我記得在幾十瓦量級和一張動輒兩三百瓦的GPU比起來功耗低得非常明顯。這意味著什么一臺普通的2U服務(wù)器里你可以輕松插上四五張甚至更多組成一個(gè)高密度推理節(jié)點(diǎn)。比如一個(gè)需要同時(shí)處理幾十路攝像頭畫面的視頻分析系統(tǒng)用GPU去跑卡的功耗和成本都會很難受用Atlas 300V這種低功耗推理卡反而很合適——單卡能做的事情不多但堆卡密度高整體吞吐很可觀。這一點(diǎn)在后面的性能調(diào)優(yōu)部分我會專門展開。1.2 24G這個(gè)容量到底能干什么用很多第一次看到“24G”的人第一反應(yīng)是“這卡比我的3060顯存還大是不是很?！?。要潑一盆冷水Atlas 300V上的24G和我們一般理解里的GPU顯存不太一樣它的作用是給推理模型存放權(quán)重、中間特征圖和運(yùn)行時(shí)buffer用的。大容量當(dāng)然有好處你能同時(shí)加載更大的模型、開更大的batch或者同時(shí)駐留多個(gè)模型但它是“容量”優(yōu)勢不是“帶寬”優(yōu)勢。如果你是想在24G里跑大語言模型那思路就錯(cuò)了——Atlas 300V的定位是視覺推理場景最舒服的活是YOLO、ResNet這類CNN模型的目標(biāo)檢測、分類、分割任務(wù)。以YOLOv5s舉例FP16精度的權(quán)重本身只有不到30MB推理一張640x640圖片時(shí)中間特征圖占用的空間也就幾百M(fèi)B。哪怕batch開到16整個(gè)模型的運(yùn)行時(shí)內(nèi)存可能也就占用1~2GB。那么24G是不是浪費(fèi)不一定。你在實(shí)際部署時(shí)一個(gè)很常見的做法是把多個(gè)模型同時(shí)加載進(jìn)內(nèi)存或者把幾路視頻流各自建獨(dú)立的推理實(shí)例這種情況下內(nèi)存就是硬通貨。比如同一張卡里掛YOLOv5做檢測、掛一個(gè)人臉識別模型做特征提取再掛一個(gè)分類模型做二次過濾如果把所有模型的推理實(shí)例都跑在一個(gè)NPU上并發(fā)調(diào)度24G的余量會給你很大的設(shè)計(jì)空間。算力方面Atlas 300V 24G官方標(biāo)稱的INT8算力在百TOPS級別FP16大概減半。這個(gè)數(shù)字放在今天的AI加速卡市場里不算最頂級但考慮到它的功耗能效比確實(shí)不錯(cuò)。實(shí)際跑YOLOv5s如果前處理和后處理都做了比較充分的優(yōu)化單卡跑到幾百FPS是常見水平。別拿這個(gè)數(shù)字和張A100比A100跑同樣的模型也不是不能跑但你要比的是“每瓦特能處理多少路視頻流”Atlas 300V這種卡的優(yōu)勢一下就出來了。2. 部署前環(huán)境準(zhǔn)備版本永遠(yuǎn)是最大的坑2.1 硬件確認(rèn)與驅(qū)動安裝不管你是買的整機(jī)還是只有一張板卡先確認(rèn)服務(wù)器本身沒問題。Atlas 300V 24G走的是PCIe 3.0 x16接口理論上近五六年內(nèi)的x86服務(wù)器都有這個(gè)插槽。關(guān)鍵是供電有些老的服務(wù)器PCIe插槽供電能力弱尤其是插滿多張卡之后建議提前確認(rèn)服務(wù)器背板供電規(guī)格避免推理時(shí)掉卡或者性能不穩(wěn)定。硬件裝好后最優(yōu)先的一步就是裝驅(qū)動和固件。華為的昇騰軟件棧分成幾個(gè)層次最下面是HDKHuawei Development Kit里面包含驅(qū)動和固件再往上是CANNAscend Computing NN工具鏈相當(dāng)于CUDA Toolkit的角色。裝驅(qū)動的過程我用的是華為官方提供的run包在root權(quán)限下執(zhí)行安裝安裝時(shí)會自動加載內(nèi)核模塊。裝完先別急著裝CANN先用命令npu-smi info驗(yàn)證一下驅(qū)動是否工作正常。如果能看到卡的名稱、芯片型號、顯存大小、溫度這些信息說明底層已經(jīng)通了這時(shí)候再繼續(xù)往上層走。這里強(qiáng)烈建議裝完驅(qū)動后做一個(gè)記錄把npu-smi info里顯示的芯片型號抄下來。后面模型轉(zhuǎn)換時(shí)要填--soc_version參數(shù)這個(gè)參數(shù)對不上ATC轉(zhuǎn)換必然報(bào)錯(cuò)。比如Atlas 300V Pro 24G用的昇騰310P系列芯片不同小步進(jìn)的soc_version寫法不一樣常見有Ascend310P1、Ascend310P3等裝完驅(qū)動npu-smi info里看到的芯片型號是最直接的參考。2.2 CANN工具鏈的版本對齊裝CANN之前先把版本對應(yīng)關(guān)系查清楚。昇騰整個(gè)軟件棧對版本匹配要求比較嚴(yán)格驅(qū)動版本、固件版本、CANN版本三者之間有配套關(guān)系如果你隨便拿一個(gè)舊版本驅(qū)動配一個(gè)新版本CANN很可能會出現(xiàn)“能裝上但跑不通”的情況。我這次踩過最典型的坑就是驅(qū)動是舊版本的CANN用了最新的6.x結(jié)果模型轉(zhuǎn)換和推理時(shí)總是報(bào)一些莫名其妙的錯(cuò)誤比如runtime初始化失敗、設(shè)備不存在查了半天最后把所有組件都降到配套版本才解決。安裝時(shí)建議用一個(gè)干凈的Ubuntu 20.04或者22.04系統(tǒng)x86_64架構(gòu)。整個(gè)安裝流程可以拆成三步# 1. 以root身份安裝HDK驅(qū)動固件 ./Ascend-hdk-*.run --full --install # 2. 安裝CANN toolkit ./Ascend-cann-toolkit_*.run --install # 3. 設(shè)置環(huán)境變量 source /usr/local/Ascend/ascend-toolkit/set_env.shCANN裝好之后ascend-toolkit目錄下會有atc、msame等工具。atc是模型轉(zhuǎn)換工具負(fù)責(zé)把ONNX轉(zhuǎn)成OMmsame是一個(gè)簡易的推理測試工具后面驗(yàn)證模型用得上。建議裝完后順手建一個(gè)環(huán)境變量文件把set_env.sh的source語句寫進(jìn)去不然每次新開終端都要手動執(zhí)行一遍。還有一點(diǎn)如果你的操作系統(tǒng)是CentOS或者其他較老的發(fā)行版裝之前先確認(rèn)內(nèi)核版本是否在官方支持列表內(nèi)。昇騰驅(qū)動是內(nèi)核模塊內(nèi)核版本和gcc版本不匹配會導(dǎo)致編譯失敗。真遇到編譯失敗不用死磕先確認(rèn)內(nèi)核頭文件是不是已經(jīng)裝了yum install kernel-devel-$(uname -r)這種操作會很常見。2.3 CANN的“系統(tǒng)里到底多了什么”裝完CANN后很多人會疑惑這玩意兒裝了一大堆東西到底哪些是我用得上的我簡單梳理一下幾個(gè)核心組件atc模型轉(zhuǎn)換編譯器。管你把ONNX、TensorFlow的pb、MindSpore的模型轉(zhuǎn)成OM格式轉(zhuǎn)換時(shí)可以指定輸入shape、AIPP配置、量化參數(shù)。msame離線推理驗(yàn)證工具。不需要寫代碼給定一個(gè)OM模型和輸入數(shù)據(jù)跑一次推理輸出結(jié)果適合快速驗(yàn)證模型在NPU上是否正確運(yùn)行。pyACLACL的Python綁定。官方提供了一套Python接口繞開C編譯的麻煩直接寫Python調(diào)用推理卡。profiling工具性能分析工具。如果你發(fā)現(xiàn)卡上的推理性能達(dá)不到預(yù)期可以靠它看每個(gè)算子的耗時(shí)、NPU利用率、帶寬瓶頸在哪兒。把這些工具用熟了你部署一個(gè)新模型的基本流程就固定了拿到模型權(quán)重轉(zhuǎn)ONNX用atc轉(zhuǎn)成OM再用msame或pyACL做推理驗(yàn)證最后按業(yè)務(wù)場景封裝成服務(wù)。理解了這個(gè)流程你就知道為什么我說Atlas的部署鏈路雖然麻煩但一旦版本環(huán)境理順了后面換模型其實(shí)挺模式的。3. YOLO模型上卡全流程從pt到om再到推理3.1 首先導(dǎo)出一個(gè)干凈的ONNX在Atlas 300V上跑YOLO前提是得有一個(gè)ONNX模型。為什么是ONNX因?yàn)锳TC目前最穩(wěn)定的輸入格式就是ONNXPyTorch的pt文件不能直接吃TensorFlow的pb也不是最優(yōu)路徑。YOLOv5官方倉庫本身帶了導(dǎo)出腳本操作起來很直接python export.py --weights yolov5s.pt --include onnx --opset 11這個(gè)命令會生成一個(gè)yolov5s.onnx。這里要特別注意幾個(gè)細(xì)節(jié)第一輸入尺寸最好固定。YOLOv5默認(rèn)訓(xùn)練尺寸是640x640導(dǎo)出時(shí)默認(rèn)就是640x640。你在做推理時(shí)如果圖片分辨率不固定后面要么通過AIPP做縮放要么在CPU側(cè)做預(yù)處理。推理卡在做靜態(tài)shape的模型時(shí)性能是最好的所以強(qiáng)烈建議導(dǎo)出時(shí)就固定一個(gè)輸入尺寸不要使用動態(tài)shape。雖然ATC支持動態(tài)shape但動態(tài)shape意味著NPU運(yùn)行時(shí)需要?jiǎng)討B(tài)規(guī)劃內(nèi)存和計(jì)算圖往往會對性能產(chǎn)生不小的損耗。第二導(dǎo)出時(shí)不要包含后處理。YOLOv5的官方導(dǎo)出腳本默認(rèn)只導(dǎo)出到檢測頭之前的網(wǎng)絡(luò)結(jié)構(gòu)輸出是類似[1, 25200, 85]的張量也就是每個(gè)anchor框的坐標(biāo)、置信度和類別概率。很多業(yè)務(wù)方希望導(dǎo)出端到端的模型把NMS也包進(jìn)去這樣做的好處是部署代碼簡單但壞處是ATC轉(zhuǎn)換可能失敗后處理算子不一定是昇騰的高效算子反而不如把NMS留在CPU上用成熟的OpenCV和NumPy實(shí)現(xiàn)來得靈活。我建議的做法是ONNX只包含主干網(wǎng)絡(luò)和檢測頭NMS全部留在應(yīng)用層這樣模型的通用性和可調(diào)試性都更好。導(dǎo)出后可以用onnx庫快速檢查一下模型的基本信息import onnx model onnx.load(yolov5s.onnx) print(model.graph.input) print(model.graph.output)確認(rèn)輸入是[1,3,640,640]輸出是[1,25200,85]之類就說明模型導(dǎo)出的結(jié)構(gòu)是完整的。3.2 用ATC把ONNX轉(zhuǎn)成OMONNX準(zhǔn)備好之后下一步就是用atc做轉(zhuǎn)換。命令長這樣atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --output_typeFP16簡單解釋幾個(gè)關(guān)鍵參數(shù)--framework5表示輸入是ONNX--output是輸出OM文件的前綴--input_shape固定輸入尺寸和batch--soc_version填型號對應(yīng)的芯片版本比如Atlas 300V Pro常見的Ascend310P3--output_typeFP16把網(wǎng)絡(luò)權(quán)重轉(zhuǎn)成半精度推理速度和內(nèi)存占用都會更友好。轉(zhuǎn)換過程可能遇到的主要問題是算子不支持。比如YOLOv5導(dǎo)出時(shí)如果opset版本太高某些算子ATC不認(rèn)識會直接報(bào)錯(cuò)。解決辦法一般是把opset降到11或12重新導(dǎo)出AT科學(xué)在ONNX算子兼容性上對于低版本的算子支持要好很多。如果遇到單個(gè)算子不支持的情況就需要通過修改模型結(jié)構(gòu)規(guī)避比如替換某些自定義激活函數(shù)、把某些特殊上采樣方式改成標(biāo)準(zhǔn)Upsample。這一步是最花時(shí)間的但成熟模型一般不太需要大改。ATC轉(zhuǎn)換成功后會生成一個(gè).om文件。這個(gè)文件可以理解成“針對當(dāng)前芯片版本的NPU可執(zhí)行程序”它和具體的soc_version綁定也就是說你在Ascend310P3上轉(zhuǎn)換的OM拿去另一個(gè)芯片型號不同的Atlas卡上是跑不了的。這也是為什么前面強(qiáng)調(diào)要提前確認(rèn)芯片型號。3.3 AIPP到底要不要配怎么配AIPP是昇騰里一個(gè)容易被忽視但影響很大的概念。簡單說AIPP是一套預(yù)處理加速機(jī)制讓你在模型輸入之前把圖像縮放、色域轉(zhuǎn)換、歸一化這些操作從CPU挪到NPU的專用硬件單元里去執(zhí)行。配置好AIPP后CPU只需要把原始圖像數(shù)據(jù)扔給卡卡在硬件層面上幫你完成resize和RGB/BGR轉(zhuǎn)換能明顯降低CPU開銷提升整條處理鏈路的吞吐。AIPP的配置是通過一個(gè)單獨(dú)的cfg文件在ATC轉(zhuǎn)換時(shí)用--insert_op_conf參數(shù)嵌進(jìn)OM里。下面是一個(gè)常見的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: true }這個(gè)配置的含義是輸入圖像是RGB888格式的原始8位數(shù)據(jù)尺寸已經(jīng)是640x640同時(shí)做色域轉(zhuǎn)換和R/B通道交換。配置好AIPP后你的預(yù)處理就簡化成“把圖像數(shù)據(jù)按指定尺寸放好直接喂給卡”剩下的交給硬件。但這里有一個(gè)YOLO系列獨(dú)有的坑LetterBox。YOLOv5在預(yù)處理時(shí)并不是簡單的resize而是先把長邊縮放到640再把短邊填充到640保證原始寬高比不變。AIPP自帶的能力里resize是硬縮放沒有l(wèi)etterbox的“等比縮放加填充”這種組合操作。如果你直接把一張1920x1080的圖扔給AIPP做resize它會變成變形的640x640推理結(jié)果完全不可用。我這次實(shí)際采用了兩種方案之一第一種如果業(yè)務(wù)上允許輕微的形變比如車牌識別或者文檔檢測對這種形變不敏感直接讓AIPP做resize推理速度最快第二種如果場景對檢測框精度要求高就在CPU側(cè)先完成letterbox轉(zhuǎn)換后的640x640圖再交給AIPP做色域轉(zhuǎn)換和歸一化AIPP不參與resize。選擇哪種方案取決于你對精度的容忍度但你必須清楚AIPP不能自動幫你完成letterbox否則會在預(yù)處理上栽大跟頭。3.4 推理代碼與運(yùn)行驗(yàn)證模型轉(zhuǎn)好后先別急著寫業(yè)務(wù)代碼用msame工具跑一次確認(rèn)模型在卡上真的能輸出正常結(jié)果。msame的用法很簡單msame --model yolov5s_bs1.om \ --input ./input_data.bin \ --output ./output/輸入數(shù)據(jù)建議用一個(gè)預(yù)處理好的640x640 RGB raw文件可以用Python先導(dǎo)出一個(gè)bin。運(yùn)行完之后output目錄下會有一個(gè)二進(jìn)制輸出文件這個(gè)文件就是模型的原始輸出對應(yīng)的就是[1,25200,85]格式。能正常輸出且數(shù)值不為空就說明OM模型本身沒問題。如果msame這一步都過不了就不要往后寫代碼了先回頭查轉(zhuǎn)換參數(shù)。確認(rèn)模型OK之后下一步就可以用pyACL寫推理腳本了。核心流程穩(wěn)定且模式化大致是四個(gè)步驟初始化設(shè)備、加載模型、構(gòu)造輸入輸出、執(zhí)行推理。import acl # 1. 初始化 acl.init() acl.rt.set_device(0) context, ret acl.rt.create_context(0) # 2. 加載模型 model_path byolov5s_bs1.om model_id, ret acl.mdl.load_from_file(model_path) # 3. 準(zhǔn)備輸入輸出簡化示意 input_data preprocess_image(test.jpg) # 返回 numpy 數(shù)組 # 這里需要把 numpy 轉(zhuǎn)成 ACL 的 Tensor/DataBuffer參數(shù)較多建議參考CANN官方sample # 4. 執(zhí)行推理 ret acl.mdl.execute(model_id, input_buffer, output_buffer) # 5. 釋放資源 acl.mdl.unload(model_id) acl.rt.destroy_context(context) acl.rt.reset_device(0) acl.finalize()實(shí)際代碼會比這個(gè)長不少主要在于numpy數(shù)組和ACL數(shù)據(jù)緩沖區(qū)的轉(zhuǎn)換、輸出后處理這兩塊但核心思路就是這個(gè)節(jié)奏。建議不要從零寫直接去CANN安裝目錄下找官方樣例一般有resnet50或者目標(biāo)檢測的sample把里面的輸入輸出處理邏輯抄過來改一改比自己造輪子快得多。推理完成后拿到的是[1,25200,85]的原始張量。后處理要做的事是把位置信息和置信度解析出來然后做NMS去除重疊框。YOLOv5輸出格式里最后85個(gè)維度的前4個(gè)是box坐標(biāo)第5個(gè)是objectness后面80個(gè)是各類別分?jǐn)?shù)。你需要先把box坐標(biāo)按照letterbox變換的縮放比例映射回原圖坐標(biāo)再過濾低置信度框最后做NMS。這部分的優(yōu)化對整體FPS影響很大我后面會專門說。4. 性能調(diào)優(yōu)與問題排查記錄4.1 影響部署體驗(yàn)的三個(gè)關(guān)鍵因素模型能跑通只是第一步真正上線關(guān)注的是吞吐和時(shí)延。在Atlas 300V上部署YOLO我發(fā)現(xiàn)影響最終體驗(yàn)的核心因素有三個(gè)。第一個(gè)是batch size和并發(fā)模式。如果你對時(shí)延敏感用batch1單發(fā)模式單張圖片延遲最低如果你對吞吐更在意盡量把多路視頻幀攢一起用較大batch一次推理比如batch4或batch8卡上計(jì)算單元的利用率會明顯提高。實(shí)際項(xiàng)目中一個(gè)很實(shí)用的方案是建立幀緩沖池把多個(gè)視頻流來源的幀按批湊齊再統(tǒng)一推理吞吐能提升好幾倍。第二個(gè)是前處理和后處理的位置。AIPP能幫忙分擔(dān)resize和色域轉(zhuǎn)換但letterbox和NMS這類操作目前基本只能在CPU上跑。在一個(gè)多路視頻的部署場景里如果每幀圖像的分辨率特別大CPU光做resize和letterbox就可能成為瓶頸你就會看到模型在NPU上算得飛快但整體FPS就是上不去原因是CPU被預(yù)處理拖垮了。我的建議是先用一個(gè)簡單的性能剖析工具看看CPU占用如果預(yù)處理占用了超過30%的CPU優(yōu)先考慮把resize挪到AIPP里或者啟用多線程處理。第三個(gè)是模型量化和精度權(quán)衡。FP16推理比FP32快不少內(nèi)存占用也更低但如果你要追求極致性能可以嘗試INT8量化。ATC支持對ONNX做INT8量化和校準(zhǔn)量化后的YOLOv5s在Atlas 300V上推理速度會有明顯提升精度損失通?？梢越邮?。不過量化需要對驗(yàn)證集做校準(zhǔn)不是一步到位的如果精度掉了太多可以先做部分層量化或混合精度也可以直接回到FP16不用死磕INT8。4.2 常見報(bào)錯(cuò)與現(xiàn)象排查表部署過程中會遇到各種報(bào)錯(cuò)我整理了幾個(gè)最常見的問題和排查思路現(xiàn)象可能原因排查方向npu-smi info看不到卡驅(qū)動未正確加載或PCIe鏈路異常使用lspci | grep -i ascend查看硬件是否被系統(tǒng)識別modprobe drv_pcie手動加載驅(qū)動模塊確認(rèn)BIOS里PCIe slot是否被禁用ATC轉(zhuǎn)換報(bào)錯(cuò)E12001或算子不支持ONNX中算子版本與AT科學(xué)兼容算子不匹配降低onnx opset版本重新導(dǎo)出用onnxsim簡化模型結(jié)構(gòu)把模型里特殊算子替換成標(biāo)準(zhǔn)算子推理輸出全為0或結(jié)果瘋狂預(yù)處理與訓(xùn)練時(shí)不一致核對AIPP的色域配置、歸一化系數(shù)、letterbox方式檢查輸入數(shù)據(jù)是否BGR/RGB順序反了逐個(gè)嘗試不同預(yù)處理策略模型推理FPS遠(yuǎn)低于預(yù)期瓶頸在CPU預(yù)處理或者batch太小先跑msame測純NPU推理耗時(shí)排除CPU干擾將resize和色域轉(zhuǎn)換挪到AIPP增大batch檢查是否有動態(tài)shape導(dǎo)致的額外開銷加載模型報(bào)內(nèi)存不足24G內(nèi)存不足或模型太大/駐留太多實(shí)例用npu-smi info查看顯存占用檢查是否有遺漏釋放的推理實(shí)例降低batch size或同時(shí)駐留模型數(shù)量推理時(shí)隨機(jī)崩潰或復(fù)位供電不足或驅(qū)動固件版本不穩(wěn)定檢查PCIe供電和散熱升級驅(qū)動固件到配套版本查看系統(tǒng)日志中的NPU錯(cuò)誤信息這些排查思路能覆蓋大部分部署問題。如果遇到上述列表以外的情況最有效的方法是去昇騰社區(qū)或者GitHub上搜一下錯(cuò)誤碼很多問題都是文檔里看不到、但社區(qū)里已經(jīng)有人踩過坑并給出解決辦法的。4.3 三個(gè)值得提前知道的“經(jīng)驗(yàn)之談”第一個(gè)經(jīng)驗(yàn)是拿到卡后第一件事是跑通官方sample而不是直接上自己的模型。官方提供的resnet50或者目標(biāo)檢測樣例是經(jīng)過充分驗(yàn)證的環(huán)境如果連官方sample都跑不通說明你的驅(qū)動、CANN版本或服務(wù)器環(huán)境有問題這時(shí)候不要懷疑自己的模型回頭查環(huán)境。我這次是先把resnet50的sample跑通再換成YOLOv5s整體路徑順了很多。第二個(gè)經(jīng)驗(yàn)是升級CANN之前先做回歸。昇騰的軟件棧版本更新頻率很快新版本通常會帶來性能提升和新算子支持但也會帶來兼容性問題。我在部署過程中有一次從CANN 5.1.x升到6.x結(jié)果原本能正常轉(zhuǎn)換的ONNX模型突然報(bào)錯(cuò)最后只能回退到舊版本。如果你當(dāng)前環(huán)境已經(jīng)穩(wěn)定運(yùn)行不要為了一個(gè)“看起來更好”的新版本貿(mào)然升級先在一個(gè)測試環(huán)境里做完整回歸確認(rèn)沒有問題再應(yīng)用到生產(chǎn)上。第三個(gè)經(jīng)驗(yàn)是用profiling工具看數(shù)據(jù)別用猜。很多人覺得推理性能不夠第一反應(yīng)是“換更高規(guī)格的卡”但很多時(shí)候瓶頸根本不在NPU。CANN自帶的profiling工具能給出NPU占用率、算子耗時(shí)、內(nèi)存帶寬等數(shù)據(jù)用數(shù)據(jù)判斷瓶頸在哪里再決定是優(yōu)化預(yù)處理、增大batch還是調(diào)整模型結(jié)構(gòu)比盲目調(diào)參要靠譜得多。最后再分享一點(diǎn)我的實(shí)際感受幾輪折騰下來我的體會是Atlas 300V 24G這類推理加速卡最大的舒適區(qū)是“模型已經(jīng)固定、業(yè)務(wù)已經(jīng)定型、需要海量并發(fā)推理”的階段。如果你還在頻繁改網(wǎng)絡(luò)結(jié)構(gòu)、還在做各種實(shí)驗(yàn)?zāi)荊PU或者直接用CPU都比它方便但如果你已經(jīng)明確要在幾十上百路視頻流上穩(wěn)定跑一個(gè)YOLO模型那它的低功耗、高密度部署特點(diǎn)就會變得非常明顯。一臺服務(wù)器插幾張Atlas 300V一個(gè)標(biāo)準(zhǔn)的視頻分析節(jié)點(diǎn)就搭起來了整體功耗比同級別的GPU方案友好太多。如果你現(xiàn)在正準(zhǔn)備做選型或者剛拿到卡我建議你給自己留出至少一周的環(huán)境熟悉時(shí)間第一天裝驅(qū)動和CANN第二天跑通官方樣例第三天完成自己的YOLO模型轉(zhuǎn)換后面幾天專門調(diào)精度和性能。不要指望半天時(shí)間就能把YOLO跑起來環(huán)境問題、版本問題和預(yù)處理問題都是需要時(shí)間磨的。最后一個(gè)小技巧所有關(guān)鍵步驟的命令、版本號、報(bào)錯(cuò)信息都記錄下來昇騰這套軟件棧的排查可以說大半靠版本記錄手上有記錄遇到問題能少走很多彎路。