戰(zhàn))
上個(gè)月項(xiàng)目里要上一批邊緣端的視頻結(jié)構(gòu)化節(jié)點(diǎn)硬件選型時(shí)拿到了一塊Atlas 300V 24G加速卡。一開始我以為這東西跟普通GPU一樣插上、裝驅(qū)動(dòng)、跑YOLO就完事了結(jié)果真上手才發(fā)現(xiàn)完全不是這么回事。它是一塊NPU推理卡從驅(qū)動(dòng)到模型轉(zhuǎn)換再到推理代碼每一步都有一堆和CUDA生態(tài)不一樣的規(guī)矩。這篇就把我從零開始把YOLOv5s部署到Atlas 300V上的完整過程寫出來包括硬件選型邏輯、環(huán)境搭建、模型轉(zhuǎn)換、AscendCL推理代碼、性能調(diào)優(yōu)以及一路排查過的各種報(bào)錯(cuò)。想用這塊卡跑YOLO系列模型的可以直接跟著走一遍。1. 先搞清楚Atlas 300V到底是什么卡推理卡和訓(xùn)練卡不是一回事很多第一次接觸華為Atlas系列的人看到“加速卡”三個(gè)字就容易把它和NVIDIA的顯卡畫等號(hào)。實(shí)際上Atlas 300V 24G是一塊標(biāo)準(zhǔn)的AI推理卡Inference Card不是訓(xùn)練卡。這一點(diǎn)如果沒搞清楚后面整個(gè)項(xiàng)目方向都會(huì)跑偏。1.1 Atlas 300V在昇騰產(chǎn)品線里的位置Atlas系列按用途可以粗分成幾類訓(xùn)練服務(wù)器里的加速模塊、邊緣計(jì)算盒子里的加速卡、數(shù)據(jù)中心用的PCIe推理卡。Atlas 300V 24G就屬于PCIe推理卡這一檔外形上和一張普通顯卡差不多插在服務(wù)器的PCIe x16插槽里就能用。它不承擔(dān)訓(xùn)練任務(wù)也不是用來做通用計(jì)算的它的核心目標(biāo)是把訓(xùn)練好的模型比如YOLO、ResNet、BERT這類以盡可能低的延遲跑起來。這塊卡最顯眼的參數(shù)就是24GB的DDR內(nèi)存。對(duì)推理卡來說大容量顯存的意義在于能裝下更大的模型、更大的批量batch或者直接緩存多路視頻流的預(yù)處理數(shù)據(jù)。比如做16路甚至32路視頻流同時(shí)推理時(shí)24GB能讓你不用頻繁換模型、不用頻繁搬運(yùn)中間數(shù)據(jù)這對(duì)實(shí)際項(xiàng)目的穩(wěn)定性幫助很大。當(dāng)然實(shí)際有效容量需要扣除系統(tǒng)預(yù)留部分Atlas 300V 24G版可用的NPU內(nèi)存一般在22GB左右具體以實(shí)機(jī)npu-smi info顯示為準(zhǔn)。另外需要糾正一個(gè)常見誤解Atlas 300V 24G不支持FP32高精度訓(xùn)練它主要跑INT8量化模型部分場(chǎng)景支持FP16。這意味著你從PyTorch里訓(xùn)練出來的FP32權(quán)重不能直接扔給它跑要先做模型轉(zhuǎn)換而且想吃到性能紅利最好做INT8量化。對(duì)YOLO這類模型來說INT8量化后精度損失通常能控制在可接受范圍內(nèi)但轉(zhuǎn)換時(shí)要小心處理輸入輸出的數(shù)據(jù)格式后面會(huì)細(xì)說。1.2 和GPU卡在開發(fā)流程上的差異如果用慣了CUDA你會(huì)發(fā)現(xiàn)Atlas的整個(gè)開發(fā)流程是“三板斧”用ASTON/PyTorch訓(xùn)練權(quán)重、把權(quán)重轉(zhuǎn)成ONNX、再用ATC工具轉(zhuǎn)成昇騰的OM離線模型最后用AscendCL簡(jiǎn)稱ACL或者M(jìn)indSpore的推理接口加載OM執(zhí)行推理。這里有個(gè)關(guān)鍵點(diǎn)OM模型是昇騰專用的不能直接在PyTorch或TensorFlow里加載。也就是說模型一旦轉(zhuǎn)成OM后續(xù)調(diào)試基本只能在昇騰的環(huán)境里做。這跟TensorRTTRT的做法有點(diǎn)像——都是把通用模型轉(zhuǎn)成廠商私有格式但Atlas的生態(tài)更封閉一些文檔和社區(qū)資料也不如CUDA豐富所以踩坑只能自己多試。還要注意Atlas 300V雖然也是PCIe卡但它沒有視頻輸出接口也不支持接顯示器。它是純計(jì)算設(shè)備所有推理結(jié)果都通過PCIe總線返回給主機(jī)CPU。這個(gè)定位決定了它適合放在服務(wù)器端做離線或?qū)崟r(shí)推理比如視頻分析服務(wù)器、智能網(wǎng)關(guān)、工業(yè)質(zhì)檢機(jī)而不是桌面圖形工作站。對(duì)部署YOLO來說理解這層區(qū)別的意義在于你的代碼結(jié)構(gòu)要從“GPU顯存管理”思維切換成“設(shè)備內(nèi)存管理”思維顯存拷貝、緩沖區(qū)申請(qǐng)、模型加載這些操作都要調(diào)用ACL自己的API不能拿cudaMalloc那一套硬套。2. 環(huán)境搭建實(shí)戰(zhàn)驅(qū)動(dòng)、固件和CANN工具鏈的版本配合是最大的坑環(huán)境搭建階段我被三個(gè)東西反復(fù)折磨NPU驅(qū)動(dòng)、固件、CANN工具包。這三者各有各的版本號(hào)而且必須互相匹配任何一個(gè)版本對(duì)不上后續(xù)模型轉(zhuǎn)換和推理都會(huì)遇到莫名其妙的錯(cuò)誤。2.1 安裝順序和版本配套邏輯正確順序是先裝NPU驅(qū)動(dòng)再裝固件最后裝CANN工具包。驅(qū)動(dòng)讓操作系統(tǒng)能識(shí)別到NPU設(shè)備固件是NPU上運(yùn)行的底層軟件CANN則是給開發(fā)者用的SDK包含ATC模型轉(zhuǎn)換工具、AscendCL運(yùn)行時(shí)、各種算子庫。我第一次安裝時(shí)圖省事直接用了網(wǎng)上流傳的“一鍵腳本”結(jié)果驅(qū)動(dòng)和固件版本不匹配npu-smi info偶爾能看到卡一跑推理就報(bào)199runtime internal error。后來只能按官方兼容性列表老老實(shí)實(shí)對(duì)了一遍驅(qū)動(dòng)版本、固件版本、CANN版本三者必須完全符合配套關(guān)系。這一步?jīng)]有任何捷徑建議直接查昇騰社區(qū)官方文檔里最新的“驅(qū)動(dòng)固件與CANN版本配套表”。安裝命令通常類似這樣# 安裝驅(qū)動(dòng)以Ascend-hdk-310p-npu-driver_xxx.run為例 ./Ascend-hdk-310p-npu-driver_xxx.run --full --install # 安裝固件 ./Ascend-hdk-310p-npu-firmware_xxx.run --full --install # 安裝CANN工具包 ./Ascend-cann-toolkit_xxx.run --install安裝完成后務(wù)必設(shè)置環(huán)境變量source /usr/local/Ascend/ascend-toolkit/set_env.sh如果你用了非root用戶還需要把當(dāng)前用戶加入ascend組否則會(huì)報(bào)權(quán)限不足。2.2 如何確認(rèn)安裝成功裝完后先別急著寫代碼先把環(huán)境驗(yàn)一遍。第一步用npu-smi info看看卡是否正常被識(shí)別npu-smi info正常情況下能看到卡的型號(hào)、芯片溫度、內(nèi)存占用、算力狀態(tài)等基本信息。如果是Atlas 300V 24G芯片名通常顯示為Ascend 310P系列。這一步看不到卡或者顯示“N/A”說明驅(qū)動(dòng)沒裝好先不用往下走。第二步驗(yàn)證CANN工具鏈?zhǔn)欠窨捎胊tc --version能正常輸出版本號(hào)說明ATC轉(zhuǎn)換工具已經(jīng)裝好。此時(shí)還可以用CANN自帶的樣例跑一個(gè)簡(jiǎn)單的resnet50推理測(cè)試比如位于/usr/local/Ascend/ascend-toolkit/latest/.../sample目錄下的樣例工程跑通了再進(jìn)入下一步。這里有個(gè)容易被忽略的點(diǎn)Atlas 300V 24G對(duì)應(yīng)的soc_version不是Ascend310也不是Ascend910而是Ascend310P系列具體是310P幾代可以用npu-smi info -t board查看或者在ATC轉(zhuǎn)換時(shí)用一個(gè)能識(shí)別芯片類型的工具確認(rèn)。我自己的卡查出來是Ascend310P3后面ATC轉(zhuǎn)換參數(shù)里就要寫--soc_versionAscend310P3。寫錯(cuò)這個(gè)參數(shù)模型轉(zhuǎn)換階段會(huì)直接報(bào)錯(cuò)。2.3 雙機(jī)互聯(lián)和Docker部署的額外注意事項(xiàng)Atlas 300V是PCIe卡理論上只要服務(wù)器有空的PCIe x16插槽就行。但實(shí)際部署要注意幾點(diǎn)一是供電部分服務(wù)器主板單個(gè)PCIe插槽供電有限如果卡在滿載時(shí)發(fā)現(xiàn)異常重啟要考慮輔助供電二是散熱Atlas 300V無風(fēng)扇設(shè)計(jì)居多依賴服務(wù)器機(jī)箱風(fēng)道如果塞在不通風(fēng)的機(jī)器里推理時(shí)間一長芯片溫度容易沖到90℃以上性能會(huì)自動(dòng)下降。如果想把推理服務(wù)容器化注意CANN的Docker鏡像需要單獨(dú)下載不能直接用宿主機(jī)里的.so文件掛載進(jìn)去就完事。因?yàn)镃ANN版本和驅(qū)動(dòng)之間有嚴(yán)格的配套關(guān)系容器里的CANN版本必須和宿主機(jī)驅(qū)動(dòng)兼容否則設(shè)備映射進(jìn)容器后同樣會(huì)報(bào)錯(cuò)。建議直接用昇騰官方發(fā)布的Ascend Docker Runtime并在創(chuàng)建容器時(shí)掛載/dev/davinci0設(shè)備文件和/usr/local/Ascend/driver目錄而不是手動(dòng)拷貝CANN包。3. YOLO模型上卡PyTorch權(quán)重轉(zhuǎn)ONNX再轉(zhuǎn)OM的完整鏈路環(huán)境準(zhǔn)備好之后真正的重頭戲來了把PyTorch訓(xùn)練好的YOLO權(quán)重部署到Atlas 300V上。整個(gè)過程可以簡(jiǎn)化為“PyTorch權(quán)重 → ONNX → OM”其中每一步都有各自的坑尤其是ONNX導(dǎo)出和ATC轉(zhuǎn)換這兩個(gè)環(huán)節(jié)稍不注意就前功盡棄。3.1 從PyTorch導(dǎo)出ONNX降算符版本是第一個(gè)坑我用的YOLOv5s為例在官方倉庫基礎(chǔ)上訓(xùn)練完權(quán)重為best.pt。導(dǎo)出ONNX時(shí)官方腳本一般會(huì)帶--opset參數(shù)很多人直接默認(rèn)導(dǎo)出opset版本可能高達(dá)17甚至更高。但昇騰ATC工具對(duì)ONNX算符的支持是分版本演進(jìn)的某些新版算子它還沒完全適配。我的做法是顯式指定一個(gè)相對(duì)保守的opset版本比如opset11import torch model torch.load(best.pt, map_locationcpu)[model].float() model.eval() dummy_input torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version11, input_names[images], output_names[output], dynamic_axes{images: {0: batch}, output: {0: batch}} )注意這里我用dynamic_axes把batch維度設(shè)成了動(dòng)態(tài)。有些場(chǎng)景固定batch1也可以但考慮到后續(xù)要做多路視頻并發(fā)推理動(dòng)態(tài)batch會(huì)更靈活。實(shí)際測(cè)試下來opset11的ONNX在ATC里的兼容性比opset17好很多轉(zhuǎn)OM基本一次通過。另外一個(gè)容易踩的坑導(dǎo)出ONNX時(shí)如果模型本身包含一些自定義算子或后處理層比如NMS這些算子有時(shí)在ONNX里能被表示但ATC不一定認(rèn)識(shí)。建議導(dǎo)出時(shí)把后處理剝離模型只保留主干部分的原始輸出NMS等后處理放到昇騰推理完成之后在主機(jī)CPU上做或者用Atlas環(huán)境里提供的非極大值抑制算子單獨(dú)處理。這樣能避免大量轉(zhuǎn)換報(bào)錯(cuò)調(diào)試也方便。3.2 ATC轉(zhuǎn)換成OMinput_shape和AIPP配置直接影響性能和正確性得到ONNX之后用ATC工具轉(zhuǎn)OM。我的常用命令如下atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_310p3 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --logerror--framework5表示輸入是ONNX模型--soc_version必須和你實(shí)際的芯片型號(hào)一致這一步錯(cuò)不得。轉(zhuǎn)完會(huì)生成一個(gè)yolov5s_310p3.om文件這就是能在Atlas 300V上直接加載的離線模型。如果只是做最簡(jiǎn)單的驗(yàn)證上面的命令就夠了。但要把性能吃透AIPPArtificial Intelligence Pre-Processing配置幾乎繞不開。YOLO推理時(shí)輸入圖像要從BGR或RGB的uint8數(shù)據(jù)轉(zhuǎn)成浮點(diǎn)、歸一化到0~1、再resize到640×640。這些操作如果在CPU上用OpenCV做每一路視頻流都會(huì)白白占用大量CPU資源而且數(shù)據(jù)從CPU內(nèi)存拷到NPU內(nèi)存還要多一次搬運(yùn)。昇騰的做法是把這些預(yù)處理步驟直接下沉到NPU里的AIPP模塊ATC轉(zhuǎn)換時(shí)把預(yù)處理參數(shù)寫進(jìn)OM模型推理時(shí)NPU直接讀取原始圖像數(shù)據(jù)預(yù)處理和推理一條流水線完成。AIPP配置文件大概長這樣aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 crop: false resize: true resize_w: 640 resize_h: 640 padding: false csc_switch: true rbuv_swap_switch: true min_chn: 0.0 max_chn: 255.0 mean_chn: 0.0 0.0 0.0 var_reci_chn: 0.00392156862745098 0.00392156862745098 0.00392156862745098 }其中input_format要按你實(shí)際送入的數(shù)據(jù)格式來寫。比如你用opencv讀圖默認(rèn)是BGR如果不做轉(zhuǎn)換就要寫B(tài)GR888_U8并且配合rbuv_swap_switch做通道交換YOLO訓(xùn)練時(shí)一般用RGB。mean_chn和var_reci_chn對(duì)應(yīng)訓(xùn)練時(shí)的歸一化參數(shù)YOLOv5通常是不減均值、除以255所以mean全0var_reci_chn是1/255。AIPP配置錯(cuò)最典型的癥狀是模型能推理、能出框但框的位置和類別全亂。這種問題不報(bào)錯(cuò)特別難查。我的經(jīng)驗(yàn)是先用最簡(jiǎn)單的方式不帶AIPP在CPU上做預(yù)處理跑通一遍確認(rèn)OM模型本身沒問題再逐步把AIPP加上去出問題就容易定位了。還有一個(gè)細(xì)節(jié)是動(dòng)態(tài)分辨率。YOLO如果想讓輸入尺寸在640、1280之間切換需要在ONNX導(dǎo)出時(shí)把寬高也設(shè)為動(dòng)態(tài)同時(shí)ATC命令里用--dynamic_shape。但動(dòng)態(tài)形狀推理的性能通常不如固定形狀如果項(xiàng)目沒有強(qiáng)烈需求建議固定尺寸省心也更快。3.3 INT8量化性能翻倍背后的精度權(quán)衡若追求極致性能下一步是INT8量化。Atlas 300V的INT8算力標(biāo)稱遠(yuǎn)高于FP16理論推理速度可以快幾倍。昇騰的AMCTAscend Model Compression Toolkit工具支持對(duì)ONNX模型做量化校準(zhǔn)。量化流程大致是準(zhǔn)備一批代表性的校準(zhǔn)圖片幾百張到幾千張不等用AMCT在推理時(shí)統(tǒng)計(jì)各層激活值的分布然后生成量化后的OM模型。實(shí)際操作時(shí)要注意量化對(duì)YOLO小目標(biāo)檢測(cè)的影響比較大尤其是小物體或密集場(chǎng)景量化后可能丟檢。建議校準(zhǔn)圖片要盡量覆蓋實(shí)際業(yè)務(wù)場(chǎng)景中的光照、目標(biāo)大小和類別分布不要隨便拿COCO的圖湊數(shù)。我在自己的數(shù)據(jù)集上做過對(duì)比YOLOv5s FP16模型mAP約0.82INT8量化后約0.79下降了3個(gè)點(diǎn)左右但單路推理延遲從12ms降到了5ms左右?guī)侍嵘黠@。如果業(yè)務(wù)對(duì)精度不敏感比如只做人流量統(tǒng)計(jì)、區(qū)域入侵告警量化收益非?？捎^。4. 用AscendCL寫推理代碼ACL接口和YOLO后處理的銜接OM模型就緒后要用AscendCLACL寫推理代碼。Atlas 300V的推理接口和TensorRT完全不同但思路類似初始化、加載模型、準(zhǔn)備輸入輸出、執(zhí)行推理、解析結(jié)果。以下是我的Python版本推理代碼骨架C版本邏輯也是一樣的。4.1 ACL推理核心流程import acl import numpy as np # 初始化 ret acl.init() ret acl.rt.set_device(0) # 加載模型 model_path byolov5s_310p3.om model_id, ret acl.mdl.load_from_file(model_path) # 獲取模型輸入輸出信息 input_desc acl.mdl.create_desc() ret acl.mdl.get_input_desc(input_desc, model_id, 0) input_size acl.mdl.get_desc_size(input_desc) input_dims acl.mdl.get_desc_dims(input_desc) output_desc acl.mdl.create_desc() ret acl.mdl.get_output_desc(output_desc, model_id, 0) output_size acl.mdl.get_desc_size(output_desc) output_dims acl.mdl.get_desc_dims(output_desc)關(guān)鍵點(diǎn)是ACL要求輸入和輸出數(shù)據(jù)必須放在設(shè)備內(nèi)存NPU內(nèi)存里。所以你需要用acl.rt.malloc申請(qǐng)?jiān)O(shè)備內(nèi)存然后用acl.rt.memcpy把CPU上的圖像數(shù)據(jù)拷貝過去。這個(gè)方式和cudaMemcpy非常像但API名字完全不同。# 申請(qǐng)?jiān)O(shè)備內(nèi)存 input_ptr, ret acl.rt.malloc(input_size, ACL_MEM_MALLOC_NORMAL_ONLY) output_ptr, ret acl.rt.malloc(output_size, ACL_MEM_MALLOC_NORMAL_ONLY) # CPU數(shù)據(jù)拷貝到設(shè)備 ret acl.rt.memcpy(input_ptr, input_size, cpu_input_data_ptr, input_size, ACL_MEMCPY_HOST_TO_DEVICE) # 執(zhí)行推理 stream acl.rt.create_stream() ret acl.mdl.execute_async(model_id, [input_ptr], [output_ptr], stream) acl.rt.synchronize_stream(stream) # 把結(jié)果拷回CPU output_data np.zeros(output_size, dtypenp.uint8) ret acl.rt.memcpy(output_data.__array_interface__[data][0], output_size, output_ptr, output_size, ACL_MEMCPY_DEVICE_TO_HOST)acl.mdl.execute_async是異步接口執(zhí)行完必須調(diào)用acl.rt.synchronize_stream同步否則可能讀到未完成的結(jié)果。這一點(diǎn)和CUDA的stream同步如出一轍。4.2 YOLO輸出解析從一維buffer到邊界框YOLOv5s的輸出shape通常是[1, 25200, 85]25200 3個(gè)尺度 × (80×80 40×40 20×20)個(gè)anchor格點(diǎn)85 4個(gè)坐標(biāo) 1個(gè)置信度 80個(gè)類別。從模型拿到的output_data是一維字節(jié)流需要按shape解析output_np np.frombuffer(output_data, dtypenp.float32).reshape(1, 25200, 85)然后照抄YOLOv5的后處理邏輯先過濾置信度低于閾值的框再按類別做非極大值抑制NMS。如果轉(zhuǎn)換ONNX時(shí)把后處理剝掉了這段邏輯就得在CPU上自己實(shí)現(xiàn)。注意如果你在ATC轉(zhuǎn)換時(shí)設(shè)置過輸出節(jié)點(diǎn)為原始輸出可能拿到的數(shù)據(jù)布局不一樣務(wù)必先用一個(gè)已知圖片對(duì)比PyTorch原始輸出確認(rèn)通道順序和數(shù)值范圍。我的做法是先用同一張圖片分別跑PyTorch模型和OM模型直接對(duì)比輸出張量的數(shù)值誤差在1e-3以內(nèi)才說明轉(zhuǎn)換無誤。ACL推理本身不復(fù)雜復(fù)雜的是數(shù)據(jù)布局和內(nèi)存管理。尤其要小心acl.rt.memset之類的接口很容易被忽略多次推理時(shí)如果不清空輸出Buffer上一次的殘留數(shù)據(jù)會(huì)干擾下一次解析。每次執(zhí)行前最好把輸出內(nèi)存清零。4.3 Python和C的性能差異如果只是做算法驗(yàn)證Python版ACL完全夠用。但真正接入生產(chǎn)級(jí)視頻流服務(wù)時(shí)建議用C。原因有二一是Python的ACL接口每次調(diào)用都有Python解釋器開銷在每路視頻都需要循環(huán)預(yù)處理、推理、后處理的高并發(fā)場(chǎng)景下這部分開銷會(huì)被放大二是Python的GIL會(huì)影響多路并發(fā)推理想用好Atlas 300V的多核并行能力C配合多線程是最穩(wěn)妥的選擇。C版的接口邏輯幾乎和Python版一一對(duì)應(yīng)只要先跑通Python版驗(yàn)證模型正確性再翻譯成C并不會(huì)太痛苦。如果團(tuán)隊(duì)實(shí)在沒有C人力也可以用Python寫多進(jìn)程每個(gè)進(jìn)程綁一個(gè)NPU芯片Atlas 300V上多芯片時(shí)通過acl.rt.set_device指定設(shè)備號(hào)也能繞開GIL的限制但內(nèi)存占用會(huì)稍高。5. 性能表現(xiàn)與調(diào)優(yōu)如何把Atlas 300V的算力真正壓榨出來部署和推理跑通只是第一步。我實(shí)際測(cè)試完第一版說實(shí)話有點(diǎn)失望單路YOLOv5s FP16推理端到端延遲接近16ms跟預(yù)期差了一大截。但經(jīng)過幾輪調(diào)優(yōu)最終壓到了6ms以內(nèi)算力利用率有明顯提升。這里分享一下關(guān)鍵的優(yōu)化方向。5.1 性能測(cè)試的基準(zhǔn)數(shù)據(jù)先說測(cè)試環(huán)境避免數(shù)據(jù)失真主機(jī)CPU為Intel Xeon Gold 6330內(nèi)存64GBAtlas 300V 24G插在PCIe 4.0 x16插槽上。測(cè)試模型YOLOv5s 640×640分別測(cè)了FP16和INT8兩種情況。模型精度單幀推理耗時(shí)ms吞吐fps備注FP165.2190純NPU推理時(shí)間FP16 CPU預(yù)處理12.878包含圖像預(yù)處理和后處理FP16 AIPP7.5130預(yù)處理已下沉NPUINT8 AIPP4.5220多batch進(jìn)一步提升注意上面的數(shù)據(jù)是“純NPU推理耗時(shí)”和“端到端耗時(shí)”的對(duì)比。很多人只看NPU推理時(shí)間覺得很快但實(shí)際接入視頻流后CPU處理瓶頸會(huì)立刻暴露特別是圖像resize、顏色空間轉(zhuǎn)換、NMS后處理這些都要花錢。5.2 調(diào)優(yōu)優(yōu)先級(jí)排序第一優(yōu)先級(jí)把AIPP用起來。這是最立竿見影的優(yōu)化能省掉CPU做resize、歸一化、通道轉(zhuǎn)換的時(shí)間。做完這一步端到端延遲基本能減半。第二優(yōu)先級(jí)多batch推理。如果業(yè)務(wù)能接受把多路視頻幀拼成一個(gè)batch處理Atlas 300V的利用率會(huì)大幅提升。比如4路視頻每路取一幀拼成[4, 3, 640, 640]輸入推理總耗時(shí)可能只比單幀多30%~50%平均每路成本就低很多。# 轉(zhuǎn)OM時(shí)指定動(dòng)態(tài)batch atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_dynamic \ --soc_versionAscend310P3 \ --input_shapeimages:-1,3,640,640 \ --dynamic_batch_size1,2,4,8推理時(shí)按實(shí)際拼好的batch數(shù)加載對(duì)應(yīng)shape執(zhí)行。第三優(yōu)先級(jí)多線程并發(fā)。Atlas 300V內(nèi)部有多個(gè)AI Core單條推理線程并不一定能占滿所有核心。C下可以用多個(gè)線程同時(shí)調(diào)用acl.mdl.execute_async讓不同線程處理不同路的視頻流或者拆分到不同的芯片上提高整體吞吐。這里有個(gè)實(shí)測(cè)經(jīng)驗(yàn)線程數(shù)不是越多越好。當(dāng)并發(fā)線程超過芯片AI Core數(shù)量后再往上加線程反而會(huì)增加調(diào)度開銷吞吐可能不升反降。建議從1個(gè)線程起步逐步增加到2、4、8找到吞吐拐點(diǎn)。第四優(yōu)先級(jí)減少內(nèi)存拷貝。把每路視頻流的輸入Buffer常駐在設(shè)備端避免每次推理都申請(qǐng)和釋放內(nèi)存。用AscendCL的acl.rt.malloc申請(qǐng)一次循環(huán)復(fù)用。同理輸出Buffer也可以復(fù)用只更新后處理要用的部分。5.3 一個(gè)容易忽略的坑CPU后處理成為瓶頸當(dāng)推理速度足夠快之后后處理的耗時(shí)占比會(huì)變得非常明顯。YOLO的NMS在純Python里跑一幀可能就要花一到兩毫秒如果平臺(tái)上再疊加幾個(gè)模型并行跑后處理線程很容易吃滿CPU。建議把NMS邏輯用Cython或C重新實(shí)現(xiàn)或者直接用昇騰環(huán)境里集成好的后處理算子如NonMaxSuppression在NPU上完成減少CPU壓力。另外實(shí)際做視頻流分析時(shí)視頻解碼也要考慮。如果同時(shí)解16路1080p視頻CPU軟解基本撐不住建議用硬解碼卡分擔(dān)或者直接選帶視頻解碼能力的昇騰硬件平臺(tái)把解碼、預(yù)處理、推理、后處理整條鏈路全部放到NPU側(cè)。6. 常見報(bào)錯(cuò)與排障手冊(cè)我踩過的那些坑希望你別再踩最后這部分把我在部署過程中真正踩過且印象深刻的報(bào)錯(cuò)和排查過程列出來按“現(xiàn)象 → 排查鏈路 → 解決方案”的方式寫。這些錯(cuò)誤不一定每個(gè)項(xiàng)目都會(huì)遇到但遇到了很耽誤時(shí)間希望能幫你少走彎路。6.1 推理時(shí)報(bào)錯(cuò)199或506009環(huán)境不一致有一次跑推理剛開始一切正常跑了幾分鐘后突然報(bào)錯(cuò)錯(cuò)誤碼是199或者506009沒有任何詳細(xì)堆棧。這種錯(cuò)誤俗稱“環(huán)境不一致”驅(qū)動(dòng)、固件、CANN三方版本不配套或者當(dāng)前用戶權(quán)限制約了NPU設(shè)備訪問。我的排查鏈路先用npu-smi info看設(shè)備是否正常、驅(qū)動(dòng)是否掛了再執(zhí)行l(wèi)s /dev/davinci*確認(rèn)設(shè)備文件存在然后跑CANN自帶的ascend-dmi工具做一次自檢。最終發(fā)現(xiàn)是我升級(jí)了宿主機(jī)內(nèi)核驅(qū)動(dòng)沒有重新編譯內(nèi)核模塊和當(dāng)前內(nèi)核版本不匹配導(dǎo)致NPU狀態(tài)異常。重裝驅(qū)動(dòng)并重啟后問題解決。6.2 ATC轉(zhuǎn)換報(bào)錯(cuò)E19999算子不支持或參數(shù)不對(duì)用ONNX轉(zhuǎn)OM時(shí)ATC偶爾會(huì)報(bào)E19999內(nèi)部錯(cuò)誤。第一次遇到這類錯(cuò)誤我被一大段堆棧繞暈了后來發(fā)現(xiàn)日志里隱藏著關(guān)鍵信息比如“Unsupported op”或“The shape is invalid”。此時(shí)分別排查一是ONNX導(dǎo)出時(shí)opset是否過高可以重新導(dǎo)出opset11二是模型里有沒有自定義算子比如某些版本YOLO的Focus層換成普通卷積替代后再導(dǎo)出三是--soc_version是否正確Atlas 300V必須寫Ascend310P系列寫錯(cuò)會(huì)直接報(bào)錯(cuò)。排障時(shí)務(wù)必加上--logdebug讓ATC把詳細(xì)的轉(zhuǎn)換日志輸出到文件里。不詳細(xì)的日志真沒法定位debug輸出雖然量大但能精確到是哪個(gè)算子、哪個(gè)節(jié)點(diǎn)出的問題用grep過濾ERROR關(guān)鍵字就能快速鎖定。6.3 推理結(jié)果框錯(cuò)位AIPP通道順序搞反第一次把AIPP打開后模型不報(bào)錯(cuò)但檢測(cè)框大量錯(cuò)位檢測(cè)出的目標(biāo)類別也混亂像是把顏色通道張冠李戴。我排查了這個(gè)報(bào)錯(cuò)的根因YOLOv5訓(xùn)練用的是RGB輸入但opencv默認(rèn)讀進(jìn)來是BGRAIPP配置時(shí)沒有做通道互換模型看到的相當(dāng)于每個(gè)通道的顏色和訓(xùn)練時(shí)不一致語義也就變了。解決方式在AIPP配置文件中設(shè)置rbuv_swap_switch: true把BGR變成RGB或者把input_format寫成RGB888_U8并在拷貝數(shù)據(jù)前先把圖像在CPU上轉(zhuǎn)為RGB。前者省了一次顏色轉(zhuǎn)換推薦前者。這類“能跑但結(jié)果不對(duì)”的問題最難查因?yàn)橄到y(tǒng)不會(huì)報(bào)錯(cuò)所有API都正常返回。我的教訓(xùn)是做任何預(yù)處理相關(guān)配置后務(wù)必用已知結(jié)果的測(cè)試圖做自動(dòng)化回歸別只靠肉眼掃幾幀。6.4 多線程推理時(shí)偶發(fā)崩潰stream和context管理多線程并發(fā)推理時(shí)偶爾會(huì)出現(xiàn)段錯(cuò)誤、卡死而且復(fù)現(xiàn)概率不穩(wěn)定。排查下來發(fā)現(xiàn)多個(gè)線程都調(diào)用了acl.rt.create_stream()但沒有顯式切換context導(dǎo)致stream上下文混亂操作了未初始化的內(nèi)存。解決方案每個(gè)線程內(nèi)部都要先acl.rt.set_context(ACL_CONTEXT_DEVICE)顯式指定設(shè)備上下文然后確保每個(gè)線程的stream獨(dú)立創(chuàng)建、獨(dú)立同步、獨(dú)立銷毀。以下是在C多線程環(huán)境下的最小結(jié)構(gòu)// 每個(gè)線程內(nèi) aclrtContext context; aclrtSetDevice(0); aclrtCreateContext(context, 0); aclrtSetCurrentContext(context); aclrtStream stream; aclrtCreateStream(stream); // 推理 aclrtMalloc(...); aclrtMemcpyAsync(...); aclrtLaunch(...); // 具體接口依CANN版本而定 aclrtSynchronizeStream(stream); // 釋放 aclrtDestroyStream(stream); aclrtDestroyContext(context);用Python時(shí)也有類似問題但由于Python線程受GIL限制踩的坑比C少一些?？傊瓵CL對(duì)線程上下文的管理要求很嚴(yán)每個(gè)線程都要“自己的設(shè)備、自己的context、自己的stream”不能圖省事共用。6.5 顯存越用越少最終申請(qǐng)不到內(nèi)存長時(shí)間運(yùn)行后推理突然報(bào)錯(cuò)說設(shè)備內(nèi)存不足。用npu-smi info一看NPU內(nèi)存占用率接近100%。這通常不是真正泄漏而是推理循環(huán)里的設(shè)備內(nèi)存申請(qǐng)后沒有釋放。反查發(fā)現(xiàn)我在編寫代碼時(shí)為了圖方便每幀推理都調(diào)用了acl.rt.malloc申請(qǐng)輸入輸出Buffer卻沒有在循環(huán)結(jié)束后釋放。解法非常簡(jiǎn)單循環(huán)外一次性申請(qǐng)好所有Buffer循環(huán)內(nèi)只拷數(shù)據(jù)、推理、讀結(jié)果全部結(jié)束后統(tǒng)一釋放。能極大降低內(nèi)存碎片和分配開銷。如果你確實(shí)需要?jiǎng)討B(tài)申請(qǐng)和釋放建議用acl.rt.malloc搭配acl.rt.memset清零而不是每次再去調(diào)用acl.rt.free。7. 最后再聊兩句項(xiàng)目落地體會(huì)算下來整個(gè)部署過程環(huán)境搭建和模型轉(zhuǎn)換占的時(shí)間比實(shí)際寫推理代碼多得多。Atlas這套工具鏈不像CUDA那樣有海量資料和社區(qū)回答很多問題只能靠官方文檔和自己試驗(yàn)來解。但一旦把OM模型和推理服務(wù)跑順?biāo)谶吘壎送评韴?chǎng)景的性價(jià)比確實(shí)很突出尤其是視頻分析和多路并發(fā)場(chǎng)景下穩(wěn)定性比預(yù)期要好。如果你也是第一次在Atlas 300V上跑YOLO我建議路徑這樣走先別一上來就追求INT8量化先用FP16完整跑通一版確認(rèn)全鏈路正確再去逐步優(yōu)化。每一次只做一項(xiàng)改動(dòng)改了就用同一批測(cè)試圖回歸直到確認(rèn)無誤再動(dòng)下一項(xiàng)。所有出過的報(bào)錯(cuò)、改過的命令最好都留著記錄——Atlas這類封閉生態(tài)里你親手積累的排障經(jīng)驗(yàn)就是最值錢的生產(chǎn)力。 YOLOv5s部署到華為Atlas 300V NPU推理卡實(shí)戰(zhàn)
上個(gè)月項(xiàng)目里要上一批邊緣端的視頻結(jié)構(gòu)化節(jié)點(diǎn)硬件選型時(shí)拿到了一塊Atlas 300V 24G加速卡。一開始我以為這東西跟普通GPU一樣插上、裝驅(qū)動(dòng)、跑YOLO就完事了結(jié)果真上手才發(fā)現(xiàn)完全不是這么回事。它是一塊NPU推理卡從驅(qū)動(dòng)到模型轉(zhuǎn)換再到推理代碼每一步都有一堆和CUDA生態(tài)不一樣的規(guī)矩。這篇就把我從零開始把YOLOv5s部署到Atlas 300V上的完整過程寫出來包括硬件選型邏輯、環(huán)境搭建、模型轉(zhuǎn)換、AscendCL推理代碼、性能調(diào)優(yōu)以及一路排查過的各種報(bào)錯(cuò)。想用這塊卡跑YOLO系列模型的可以直接跟著走一遍。1. 先搞清楚Atlas 300V到底是什么卡推理卡和訓(xùn)練卡不是一回事很多第一次接觸華為Atlas系列的人看到“加速卡”三個(gè)字就容易把它和NVIDIA的顯卡畫等號(hào)。實(shí)際上Atlas 300V 24G是一塊標(biāo)準(zhǔn)的AI推理卡Inference Card不是訓(xùn)練卡。這一點(diǎn)如果沒搞清楚后面整個(gè)項(xiàng)目方向都會(huì)跑偏。1.1 Atlas 300V在昇騰產(chǎn)品線里的位置Atlas系列按用途可以粗分成幾類訓(xùn)練服務(wù)器里的加速模塊、邊緣計(jì)算盒子里的加速卡、數(shù)據(jù)中心用的PCIe推理卡。Atlas 300V 24G就屬于PCIe推理卡這一檔外形上和一張普通顯卡差不多插在服務(wù)器的PCIe x16插槽里就能用。它不承擔(dān)訓(xùn)練任務(wù)也不是用來做通用計(jì)算的它的核心目標(biāo)是把訓(xùn)練好的模型比如YOLO、ResNet、BERT這類以盡可能低的延遲跑起來。這塊卡最顯眼的參數(shù)就是24GB的DDR內(nèi)存。對(duì)推理卡來說大容量顯存的意義在于能裝下更大的模型、更大的批量batch或者直接緩存多路視頻流的預(yù)處理數(shù)據(jù)。比如做16路甚至32路視頻流同時(shí)推理時(shí)24GB能讓你不用頻繁換模型、不用頻繁搬運(yùn)中間數(shù)據(jù)這對(duì)實(shí)際項(xiàng)目的穩(wěn)定性幫助很大。當(dāng)然實(shí)際有效容量需要扣除系統(tǒng)預(yù)留部分Atlas 300V 24G版可用的NPU內(nèi)存一般在22GB左右具體以實(shí)機(jī)npu-smi info顯示為準(zhǔn)。另外需要糾正一個(gè)常見誤解Atlas 300V 24G不支持FP32高精度訓(xùn)練它主要跑INT8量化模型部分場(chǎng)景支持FP16。這意味著你從PyTorch里訓(xùn)練出來的FP32權(quán)重不能直接扔給它跑要先做模型轉(zhuǎn)換而且想吃到性能紅利最好做INT8量化。對(duì)YOLO這類模型來說INT8量化后精度損失通常能控制在可接受范圍內(nèi)但轉(zhuǎn)換時(shí)要小心處理輸入輸出的數(shù)據(jù)格式后面會(huì)細(xì)說。1.2 和GPU卡在開發(fā)流程上的差異如果用慣了CUDA你會(huì)發(fā)現(xiàn)Atlas的整個(gè)開發(fā)流程是“三板斧”用ASTON/PyTorch訓(xùn)練權(quán)重、把權(quán)重轉(zhuǎn)成ONNX、再用ATC工具轉(zhuǎn)成昇騰的OM離線模型最后用AscendCL簡(jiǎn)稱ACL或者M(jìn)indSpore的推理接口加載OM執(zhí)行推理。這里有個(gè)關(guān)鍵點(diǎn)OM模型是昇騰專用的不能直接在PyTorch或TensorFlow里加載。也就是說模型一旦轉(zhuǎn)成OM后續(xù)調(diào)試基本只能在昇騰的環(huán)境里做。這跟TensorRTTRT的做法有點(diǎn)像——都是把通用模型轉(zhuǎn)成廠商私有格式但Atlas的生態(tài)更封閉一些文檔和社區(qū)資料也不如CUDA豐富所以踩坑只能自己多試。還要注意Atlas 300V雖然也是PCIe卡但它沒有視頻輸出接口也不支持接顯示器。它是純計(jì)算設(shè)備所有推理結(jié)果都通過PCIe總線返回給主機(jī)CPU。這個(gè)定位決定了它適合放在服務(wù)器端做離線或?qū)崟r(shí)推理比如視頻分析服務(wù)器、智能網(wǎng)關(guān)、工業(yè)質(zhì)檢機(jī)而不是桌面圖形工作站。對(duì)部署YOLO來說理解這層區(qū)別的意義在于你的代碼結(jié)構(gòu)要從“GPU顯存管理”思維切換成“設(shè)備內(nèi)存管理”思維顯存拷貝、緩沖區(qū)申請(qǐng)、模型加載這些操作都要調(diào)用ACL自己的API不能拿cudaMalloc那一套硬套。2. 環(huán)境搭建實(shí)戰(zhàn)驅(qū)動(dòng)、固件和CANN工具鏈的版本配合是最大的坑環(huán)境搭建階段我被三個(gè)東西反復(fù)折磨NPU驅(qū)動(dòng)、固件、CANN工具包。這三者各有各的版本號(hào)而且必須互相匹配任何一個(gè)版本對(duì)不上后續(xù)模型轉(zhuǎn)換和推理都會(huì)遇到莫名其妙的錯(cuò)誤。2.1 安裝順序和版本配套邏輯正確順序是先裝NPU驅(qū)動(dòng)再裝固件最后裝CANN工具包。驅(qū)動(dòng)讓操作系統(tǒng)能識(shí)別到NPU設(shè)備固件是NPU上運(yùn)行的底層軟件CANN則是給開發(fā)者用的SDK包含ATC模型轉(zhuǎn)換工具、AscendCL運(yùn)行時(shí)、各種算子庫。我第一次安裝時(shí)圖省事直接用了網(wǎng)上流傳的“一鍵腳本”結(jié)果驅(qū)動(dòng)和固件版本不匹配npu-smi info偶爾能看到卡一跑推理就報(bào)199runtime internal error。后來只能按官方兼容性列表老老實(shí)實(shí)對(duì)了一遍驅(qū)動(dòng)版本、固件版本、CANN版本三者必須完全符合配套關(guān)系。這一步?jīng)]有任何捷徑建議直接查昇騰社區(qū)官方文檔里最新的“驅(qū)動(dòng)固件與CANN版本配套表”。安裝命令通常類似這樣# 安裝驅(qū)動(dòng)以Ascend-hdk-310p-npu-driver_xxx.run為例 ./Ascend-hdk-310p-npu-driver_xxx.run --full --install # 安裝固件 ./Ascend-hdk-310p-npu-firmware_xxx.run --full --install # 安裝CANN工具包 ./Ascend-cann-toolkit_xxx.run --install安裝完成后務(wù)必設(shè)置環(huán)境變量source /usr/local/Ascend/ascend-toolkit/set_env.sh如果你用了非root用戶還需要把當(dāng)前用戶加入ascend組否則會(huì)報(bào)權(quán)限不足。2.2 如何確認(rèn)安裝成功裝完后先別急著寫代碼先把環(huán)境驗(yàn)一遍。第一步用npu-smi info看看卡是否正常被識(shí)別npu-smi info正常情況下能看到卡的型號(hào)、芯片溫度、內(nèi)存占用、算力狀態(tài)等基本信息。如果是Atlas 300V 24G芯片名通常顯示為Ascend 310P系列。這一步看不到卡或者顯示“N/A”說明驅(qū)動(dòng)沒裝好先不用往下走。第二步驗(yàn)證CANN工具鏈?zhǔn)欠窨捎胊tc --version能正常輸出版本號(hào)說明ATC轉(zhuǎn)換工具已經(jīng)裝好。此時(shí)還可以用CANN自帶的樣例跑一個(gè)簡(jiǎn)單的resnet50推理測(cè)試比如位于/usr/local/Ascend/ascend-toolkit/latest/.../sample目錄下的樣例工程跑通了再進(jìn)入下一步。這里有個(gè)容易被忽略的點(diǎn)Atlas 300V 24G對(duì)應(yīng)的soc_version不是Ascend310也不是Ascend910而是Ascend310P系列具體是310P幾代可以用npu-smi info -t board查看或者在ATC轉(zhuǎn)換時(shí)用一個(gè)能識(shí)別芯片類型的工具確認(rèn)。我自己的卡查出來是Ascend310P3后面ATC轉(zhuǎn)換參數(shù)里就要寫--soc_versionAscend310P3。寫錯(cuò)這個(gè)參數(shù)模型轉(zhuǎn)換階段會(huì)直接報(bào)錯(cuò)。2.3 雙機(jī)互聯(lián)和Docker部署的額外注意事項(xiàng)Atlas 300V是PCIe卡理論上只要服務(wù)器有空的PCIe x16插槽就行。但實(shí)際部署要注意幾點(diǎn)一是供電部分服務(wù)器主板單個(gè)PCIe插槽供電有限如果卡在滿載時(shí)發(fā)現(xiàn)異常重啟要考慮輔助供電二是散熱Atlas 300V無風(fēng)扇設(shè)計(jì)居多依賴服務(wù)器機(jī)箱風(fēng)道如果塞在不通風(fēng)的機(jī)器里推理時(shí)間一長芯片溫度容易沖到90℃以上性能會(huì)自動(dòng)下降。如果想把推理服務(wù)容器化注意CANN的Docker鏡像需要單獨(dú)下載不能直接用宿主機(jī)里的.so文件掛載進(jìn)去就完事。因?yàn)镃ANN版本和驅(qū)動(dòng)之間有嚴(yán)格的配套關(guān)系容器里的CANN版本必須和宿主機(jī)驅(qū)動(dòng)兼容否則設(shè)備映射進(jìn)容器后同樣會(huì)報(bào)錯(cuò)。建議直接用昇騰官方發(fā)布的Ascend Docker Runtime并在創(chuàng)建容器時(shí)掛載/dev/davinci0設(shè)備文件和/usr/local/Ascend/driver目錄而不是手動(dòng)拷貝CANN包。3. YOLO模型上卡PyTorch權(quán)重轉(zhuǎn)ONNX再轉(zhuǎn)OM的完整鏈路環(huán)境準(zhǔn)備好之后真正的重頭戲來了把PyTorch訓(xùn)練好的YOLO權(quán)重部署到Atlas 300V上。整個(gè)過程可以簡(jiǎn)化為“PyTorch權(quán)重 → ONNX → OM”其中每一步都有各自的坑尤其是ONNX導(dǎo)出和ATC轉(zhuǎn)換這兩個(gè)環(huán)節(jié)稍不注意就前功盡棄。3.1 從PyTorch導(dǎo)出ONNX降算符版本是第一個(gè)坑我用的YOLOv5s為例在官方倉庫基礎(chǔ)上訓(xùn)練完權(quán)重為best.pt。導(dǎo)出ONNX時(shí)官方腳本一般會(huì)帶--opset參數(shù)很多人直接默認(rèn)導(dǎo)出opset版本可能高達(dá)17甚至更高。但昇騰ATC工具對(duì)ONNX算符的支持是分版本演進(jìn)的某些新版算子它還沒完全適配。我的做法是顯式指定一個(gè)相對(duì)保守的opset版本比如opset11import torch model torch.load(best.pt, map_locationcpu)[model].float() model.eval() dummy_input torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version11, input_names[images], output_names[output], dynamic_axes{images: {0: batch}, output: {0: batch}} )注意這里我用dynamic_axes把batch維度設(shè)成了動(dòng)態(tài)。有些場(chǎng)景固定batch1也可以但考慮到后續(xù)要做多路視頻并發(fā)推理動(dòng)態(tài)batch會(huì)更靈活。實(shí)際測(cè)試下來opset11的ONNX在ATC里的兼容性比opset17好很多轉(zhuǎn)OM基本一次通過。另外一個(gè)容易踩的坑導(dǎo)出ONNX時(shí)如果模型本身包含一些自定義算子或后處理層比如NMS這些算子有時(shí)在ONNX里能被表示但ATC不一定認(rèn)識(shí)。建議導(dǎo)出時(shí)把后處理剝離模型只保留主干部分的原始輸出NMS等后處理放到昇騰推理完成之后在主機(jī)CPU上做或者用Atlas環(huán)境里提供的非極大值抑制算子單獨(dú)處理。這樣能避免大量轉(zhuǎn)換報(bào)錯(cuò)調(diào)試也方便。3.2 ATC轉(zhuǎn)換成OMinput_shape和AIPP配置直接影響性能和正確性得到ONNX之后用ATC工具轉(zhuǎn)OM。我的常用命令如下atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_310p3 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --logerror--framework5表示輸入是ONNX模型--soc_version必須和你實(shí)際的芯片型號(hào)一致這一步錯(cuò)不得。轉(zhuǎn)完會(huì)生成一個(gè)yolov5s_310p3.om文件這就是能在Atlas 300V上直接加載的離線模型。如果只是做最簡(jiǎn)單的驗(yàn)證上面的命令就夠了。但要把性能吃透AIPPArtificial Intelligence Pre-Processing配置幾乎繞不開。YOLO推理時(shí)輸入圖像要從BGR或RGB的uint8數(shù)據(jù)轉(zhuǎn)成浮點(diǎn)、歸一化到0~1、再resize到640×640。這些操作如果在CPU上用OpenCV做每一路視頻流都會(huì)白白占用大量CPU資源而且數(shù)據(jù)從CPU內(nèi)存拷到NPU內(nèi)存還要多一次搬運(yùn)。昇騰的做法是把這些預(yù)處理步驟直接下沉到NPU里的AIPP模塊ATC轉(zhuǎn)換時(shí)把預(yù)處理參數(shù)寫進(jìn)OM模型推理時(shí)NPU直接讀取原始圖像數(shù)據(jù)預(yù)處理和推理一條流水線完成。AIPP配置文件大概長這樣aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 crop: false resize: true resize_w: 640 resize_h: 640 padding: false csc_switch: true rbuv_swap_switch: true min_chn: 0.0 max_chn: 255.0 mean_chn: 0.0 0.0 0.0 var_reci_chn: 0.00392156862745098 0.00392156862745098 0.00392156862745098 }其中input_format要按你實(shí)際送入的數(shù)據(jù)格式來寫。比如你用opencv讀圖默認(rèn)是BGR如果不做轉(zhuǎn)換就要寫B(tài)GR888_U8并且配合rbuv_swap_switch做通道交換YOLO訓(xùn)練時(shí)一般用RGB。mean_chn和var_reci_chn對(duì)應(yīng)訓(xùn)練時(shí)的歸一化參數(shù)YOLOv5通常是不減均值、除以255所以mean全0var_reci_chn是1/255。AIPP配置錯(cuò)最典型的癥狀是模型能推理、能出框但框的位置和類別全亂。這種問題不報(bào)錯(cuò)特別難查。我的經(jīng)驗(yàn)是先用最簡(jiǎn)單的方式不帶AIPP在CPU上做預(yù)處理跑通一遍確認(rèn)OM模型本身沒問題再逐步把AIPP加上去出問題就容易定位了。還有一個(gè)細(xì)節(jié)是動(dòng)態(tài)分辨率。YOLO如果想讓輸入尺寸在640、1280之間切換需要在ONNX導(dǎo)出時(shí)把寬高也設(shè)為動(dòng)態(tài)同時(shí)ATC命令里用--dynamic_shape。但動(dòng)態(tài)形狀推理的性能通常不如固定形狀如果項(xiàng)目沒有強(qiáng)烈需求建議固定尺寸省心也更快。3.3 INT8量化性能翻倍背后的精度權(quán)衡若追求極致性能下一步是INT8量化。Atlas 300V的INT8算力標(biāo)稱遠(yuǎn)高于FP16理論推理速度可以快幾倍。昇騰的AMCTAscend Model Compression Toolkit工具支持對(duì)ONNX模型做量化校準(zhǔn)。量化流程大致是準(zhǔn)備一批代表性的校準(zhǔn)圖片幾百張到幾千張不等用AMCT在推理時(shí)統(tǒng)計(jì)各層激活值的分布然后生成量化后的OM模型。實(shí)際操作時(shí)要注意量化對(duì)YOLO小目標(biāo)檢測(cè)的影響比較大尤其是小物體或密集場(chǎng)景量化后可能丟檢。建議校準(zhǔn)圖片要盡量覆蓋實(shí)際業(yè)務(wù)場(chǎng)景中的光照、目標(biāo)大小和類別分布不要隨便拿COCO的圖湊數(shù)。我在自己的數(shù)據(jù)集上做過對(duì)比YOLOv5s FP16模型mAP約0.82INT8量化后約0.79下降了3個(gè)點(diǎn)左右但單路推理延遲從12ms降到了5ms左右?guī)侍嵘黠@。如果業(yè)務(wù)對(duì)精度不敏感比如只做人流量統(tǒng)計(jì)、區(qū)域入侵告警量化收益非?？捎^。4. 用AscendCL寫推理代碼ACL接口和YOLO后處理的銜接OM模型就緒后要用AscendCLACL寫推理代碼。Atlas 300V的推理接口和TensorRT完全不同但思路類似初始化、加載模型、準(zhǔn)備輸入輸出、執(zhí)行推理、解析結(jié)果。以下是我的Python版本推理代碼骨架C版本邏輯也是一樣的。4.1 ACL推理核心流程import acl import numpy as np # 初始化 ret acl.init() ret acl.rt.set_device(0) # 加載模型 model_path byolov5s_310p3.om model_id, ret acl.mdl.load_from_file(model_path) # 獲取模型輸入輸出信息 input_desc acl.mdl.create_desc() ret acl.mdl.get_input_desc(input_desc, model_id, 0) input_size acl.mdl.get_desc_size(input_desc) input_dims acl.mdl.get_desc_dims(input_desc) output_desc acl.mdl.create_desc() ret acl.mdl.get_output_desc(output_desc, model_id, 0) output_size acl.mdl.get_desc_size(output_desc) output_dims acl.mdl.get_desc_dims(output_desc)關(guān)鍵點(diǎn)是ACL要求輸入和輸出數(shù)據(jù)必須放在設(shè)備內(nèi)存NPU內(nèi)存里。所以你需要用acl.rt.malloc申請(qǐng)?jiān)O(shè)備內(nèi)存然后用acl.rt.memcpy把CPU上的圖像數(shù)據(jù)拷貝過去。這個(gè)方式和cudaMemcpy非常像但API名字完全不同。# 申請(qǐng)?jiān)O(shè)備內(nèi)存 input_ptr, ret acl.rt.malloc(input_size, ACL_MEM_MALLOC_NORMAL_ONLY) output_ptr, ret acl.rt.malloc(output_size, ACL_MEM_MALLOC_NORMAL_ONLY) # CPU數(shù)據(jù)拷貝到設(shè)備 ret acl.rt.memcpy(input_ptr, input_size, cpu_input_data_ptr, input_size, ACL_MEMCPY_HOST_TO_DEVICE) # 執(zhí)行推理 stream acl.rt.create_stream() ret acl.mdl.execute_async(model_id, [input_ptr], [output_ptr], stream) acl.rt.synchronize_stream(stream) # 把結(jié)果拷回CPU output_data np.zeros(output_size, dtypenp.uint8) ret acl.rt.memcpy(output_data.__array_interface__[data][0], output_size, output_ptr, output_size, ACL_MEMCPY_DEVICE_TO_HOST)acl.mdl.execute_async是異步接口執(zhí)行完必須調(diào)用acl.rt.synchronize_stream同步否則可能讀到未完成的結(jié)果。這一點(diǎn)和CUDA的stream同步如出一轍。4.2 YOLO輸出解析從一維buffer到邊界框YOLOv5s的輸出shape通常是[1, 25200, 85]25200 3個(gè)尺度 × (80×80 40×40 20×20)個(gè)anchor格點(diǎn)85 4個(gè)坐標(biāo) 1個(gè)置信度 80個(gè)類別。從模型拿到的output_data是一維字節(jié)流需要按shape解析output_np np.frombuffer(output_data, dtypenp.float32).reshape(1, 25200, 85)然后照抄YOLOv5的后處理邏輯先過濾置信度低于閾值的框再按類別做非極大值抑制NMS。如果轉(zhuǎn)換ONNX時(shí)把后處理剝掉了這段邏輯就得在CPU上自己實(shí)現(xiàn)。注意如果你在ATC轉(zhuǎn)換時(shí)設(shè)置過輸出節(jié)點(diǎn)為原始輸出可能拿到的數(shù)據(jù)布局不一樣務(wù)必先用一個(gè)已知圖片對(duì)比PyTorch原始輸出確認(rèn)通道順序和數(shù)值范圍。我的做法是先用同一張圖片分別跑PyTorch模型和OM模型直接對(duì)比輸出張量的數(shù)值誤差在1e-3以內(nèi)才說明轉(zhuǎn)換無誤。ACL推理本身不復(fù)雜復(fù)雜的是數(shù)據(jù)布局和內(nèi)存管理。尤其要小心acl.rt.memset之類的接口很容易被忽略多次推理時(shí)如果不清空輸出Buffer上一次的殘留數(shù)據(jù)會(huì)干擾下一次解析。每次執(zhí)行前最好把輸出內(nèi)存清零。4.3 Python和C的性能差異如果只是做算法驗(yàn)證Python版ACL完全夠用。但真正接入生產(chǎn)級(jí)視頻流服務(wù)時(shí)建議用C。原因有二一是Python的ACL接口每次調(diào)用都有Python解釋器開銷在每路視頻都需要循環(huán)預(yù)處理、推理、后處理的高并發(fā)場(chǎng)景下這部分開銷會(huì)被放大二是Python的GIL會(huì)影響多路并發(fā)推理想用好Atlas 300V的多核并行能力C配合多線程是最穩(wěn)妥的選擇。C版的接口邏輯幾乎和Python版一一對(duì)應(yīng)只要先跑通Python版驗(yàn)證模型正確性再翻譯成C并不會(huì)太痛苦。如果團(tuán)隊(duì)實(shí)在沒有C人力也可以用Python寫多進(jìn)程每個(gè)進(jìn)程綁一個(gè)NPU芯片Atlas 300V上多芯片時(shí)通過acl.rt.set_device指定設(shè)備號(hào)也能繞開GIL的限制但內(nèi)存占用會(huì)稍高。5. 性能表現(xiàn)與調(diào)優(yōu)如何把Atlas 300V的算力真正壓榨出來部署和推理跑通只是第一步。我實(shí)際測(cè)試完第一版說實(shí)話有點(diǎn)失望單路YOLOv5s FP16推理端到端延遲接近16ms跟預(yù)期差了一大截。但經(jīng)過幾輪調(diào)優(yōu)最終壓到了6ms以內(nèi)算力利用率有明顯提升。這里分享一下關(guān)鍵的優(yōu)化方向。5.1 性能測(cè)試的基準(zhǔn)數(shù)據(jù)先說測(cè)試環(huán)境避免數(shù)據(jù)失真主機(jī)CPU為Intel Xeon Gold 6330內(nèi)存64GBAtlas 300V 24G插在PCIe 4.0 x16插槽上。測(cè)試模型YOLOv5s 640×640分別測(cè)了FP16和INT8兩種情況。模型精度單幀推理耗時(shí)ms吞吐fps備注FP165.2190純NPU推理時(shí)間FP16 CPU預(yù)處理12.878包含圖像預(yù)處理和后處理FP16 AIPP7.5130預(yù)處理已下沉NPUINT8 AIPP4.5220多batch進(jìn)一步提升注意上面的數(shù)據(jù)是“純NPU推理耗時(shí)”和“端到端耗時(shí)”的對(duì)比。很多人只看NPU推理時(shí)間覺得很快但實(shí)際接入視頻流后CPU處理瓶頸會(huì)立刻暴露特別是圖像resize、顏色空間轉(zhuǎn)換、NMS后處理這些都要花錢。5.2 調(diào)優(yōu)優(yōu)先級(jí)排序第一優(yōu)先級(jí)把AIPP用起來。這是最立竿見影的優(yōu)化能省掉CPU做resize、歸一化、通道轉(zhuǎn)換的時(shí)間。做完這一步端到端延遲基本能減半。第二優(yōu)先級(jí)多batch推理。如果業(yè)務(wù)能接受把多路視頻幀拼成一個(gè)batch處理Atlas 300V的利用率會(huì)大幅提升。比如4路視頻每路取一幀拼成[4, 3, 640, 640]輸入推理總耗時(shí)可能只比單幀多30%~50%平均每路成本就低很多。# 轉(zhuǎn)OM時(shí)指定動(dòng)態(tài)batch atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_dynamic \ --soc_versionAscend310P3 \ --input_shapeimages:-1,3,640,640 \ --dynamic_batch_size1,2,4,8推理時(shí)按實(shí)際拼好的batch數(shù)加載對(duì)應(yīng)shape執(zhí)行。第三優(yōu)先級(jí)多線程并發(fā)。Atlas 300V內(nèi)部有多個(gè)AI Core單條推理線程并不一定能占滿所有核心。C下可以用多個(gè)線程同時(shí)調(diào)用acl.mdl.execute_async讓不同線程處理不同路的視頻流或者拆分到不同的芯片上提高整體吞吐。這里有個(gè)實(shí)測(cè)經(jīng)驗(yàn)線程數(shù)不是越多越好。當(dāng)并發(fā)線程超過芯片AI Core數(shù)量后再往上加線程反而會(huì)增加調(diào)度開銷吞吐可能不升反降。建議從1個(gè)線程起步逐步增加到2、4、8找到吞吐拐點(diǎn)。第四優(yōu)先級(jí)減少內(nèi)存拷貝。把每路視頻流的輸入Buffer常駐在設(shè)備端避免每次推理都申請(qǐng)和釋放內(nèi)存。用AscendCL的acl.rt.malloc申請(qǐng)一次循環(huán)復(fù)用。同理輸出Buffer也可以復(fù)用只更新后處理要用的部分。5.3 一個(gè)容易忽略的坑CPU后處理成為瓶頸當(dāng)推理速度足夠快之后后處理的耗時(shí)占比會(huì)變得非常明顯。YOLO的NMS在純Python里跑一幀可能就要花一到兩毫秒如果平臺(tái)上再疊加幾個(gè)模型并行跑后處理線程很容易吃滿CPU。建議把NMS邏輯用Cython或C重新實(shí)現(xiàn)或者直接用昇騰環(huán)境里集成好的后處理算子如NonMaxSuppression在NPU上完成減少CPU壓力。另外實(shí)際做視頻流分析時(shí)視頻解碼也要考慮。如果同時(shí)解16路1080p視頻CPU軟解基本撐不住建議用硬解碼卡分擔(dān)或者直接選帶視頻解碼能力的昇騰硬件平臺(tái)把解碼、預(yù)處理、推理、后處理整條鏈路全部放到NPU側(cè)。6. 常見報(bào)錯(cuò)與排障手冊(cè)我踩過的那些坑希望你別再踩最后這部分把我在部署過程中真正踩過且印象深刻的報(bào)錯(cuò)和排查過程列出來按“現(xiàn)象 → 排查鏈路 → 解決方案”的方式寫。這些錯(cuò)誤不一定每個(gè)項(xiàng)目都會(huì)遇到但遇到了很耽誤時(shí)間希望能幫你少走彎路。6.1 推理時(shí)報(bào)錯(cuò)199或506009環(huán)境不一致有一次跑推理剛開始一切正常跑了幾分鐘后突然報(bào)錯(cuò)錯(cuò)誤碼是199或者506009沒有任何詳細(xì)堆棧。這種錯(cuò)誤俗稱“環(huán)境不一致”驅(qū)動(dòng)、固件、CANN三方版本不配套或者當(dāng)前用戶權(quán)限制約了NPU設(shè)備訪問。我的排查鏈路先用npu-smi info看設(shè)備是否正常、驅(qū)動(dòng)是否掛了再執(zhí)行l(wèi)s /dev/davinci*確認(rèn)設(shè)備文件存在然后跑CANN自帶的ascend-dmi工具做一次自檢。最終發(fā)現(xiàn)是我升級(jí)了宿主機(jī)內(nèi)核驅(qū)動(dòng)沒有重新編譯內(nèi)核模塊和當(dāng)前內(nèi)核版本不匹配導(dǎo)致NPU狀態(tài)異常。重裝驅(qū)動(dòng)并重啟后問題解決。6.2 ATC轉(zhuǎn)換報(bào)錯(cuò)E19999算子不支持或參數(shù)不對(duì)用ONNX轉(zhuǎn)OM時(shí)ATC偶爾會(huì)報(bào)E19999內(nèi)部錯(cuò)誤。第一次遇到這類錯(cuò)誤我被一大段堆棧繞暈了后來發(fā)現(xiàn)日志里隱藏著關(guān)鍵信息比如“Unsupported op”或“The shape is invalid”。此時(shí)分別排查一是ONNX導(dǎo)出時(shí)opset是否過高可以重新導(dǎo)出opset11二是模型里有沒有自定義算子比如某些版本YOLO的Focus層換成普通卷積替代后再導(dǎo)出三是--soc_version是否正確Atlas 300V必須寫Ascend310P系列寫錯(cuò)會(huì)直接報(bào)錯(cuò)。排障時(shí)務(wù)必加上--logdebug讓ATC把詳細(xì)的轉(zhuǎn)換日志輸出到文件里。不詳細(xì)的日志真沒法定位debug輸出雖然量大但能精確到是哪個(gè)算子、哪個(gè)節(jié)點(diǎn)出的問題用grep過濾ERROR關(guān)鍵字就能快速鎖定。6.3 推理結(jié)果框錯(cuò)位AIPP通道順序搞反第一次把AIPP打開后模型不報(bào)錯(cuò)但檢測(cè)框大量錯(cuò)位檢測(cè)出的目標(biāo)類別也混亂像是把顏色通道張冠李戴。我排查了這個(gè)報(bào)錯(cuò)的根因YOLOv5訓(xùn)練用的是RGB輸入但opencv默認(rèn)讀進(jìn)來是BGRAIPP配置時(shí)沒有做通道互換模型看到的相當(dāng)于每個(gè)通道的顏色和訓(xùn)練時(shí)不一致語義也就變了。解決方式在AIPP配置文件中設(shè)置rbuv_swap_switch: true把BGR變成RGB或者把input_format寫成RGB888_U8并在拷貝數(shù)據(jù)前先把圖像在CPU上轉(zhuǎn)為RGB。前者省了一次顏色轉(zhuǎn)換推薦前者。這類“能跑但結(jié)果不對(duì)”的問題最難查因?yàn)橄到y(tǒng)不會(huì)報(bào)錯(cuò)所有API都正常返回。我的教訓(xùn)是做任何預(yù)處理相關(guān)配置后務(wù)必用已知結(jié)果的測(cè)試圖做自動(dòng)化回歸別只靠肉眼掃幾幀。6.4 多線程推理時(shí)偶發(fā)崩潰stream和context管理多線程并發(fā)推理時(shí)偶爾會(huì)出現(xiàn)段錯(cuò)誤、卡死而且復(fù)現(xiàn)概率不穩(wěn)定。排查下來發(fā)現(xiàn)多個(gè)線程都調(diào)用了acl.rt.create_stream()但沒有顯式切換context導(dǎo)致stream上下文混亂操作了未初始化的內(nèi)存。解決方案每個(gè)線程內(nèi)部都要先acl.rt.set_context(ACL_CONTEXT_DEVICE)顯式指定設(shè)備上下文然后確保每個(gè)線程的stream獨(dú)立創(chuàng)建、獨(dú)立同步、獨(dú)立銷毀。以下是在C多線程環(huán)境下的最小結(jié)構(gòu)// 每個(gè)線程內(nèi) aclrtContext context; aclrtSetDevice(0); aclrtCreateContext(context, 0); aclrtSetCurrentContext(context); aclrtStream stream; aclrtCreateStream(stream); // 推理 aclrtMalloc(...); aclrtMemcpyAsync(...); aclrtLaunch(...); // 具體接口依CANN版本而定 aclrtSynchronizeStream(stream); // 釋放 aclrtDestroyStream(stream); aclrtDestroyContext(context);用Python時(shí)也有類似問題但由于Python線程受GIL限制踩的坑比C少一些?？傊瓵CL對(duì)線程上下文的管理要求很嚴(yán)每個(gè)線程都要“自己的設(shè)備、自己的context、自己的stream”不能圖省事共用。6.5 顯存越用越少最終申請(qǐng)不到內(nèi)存長時(shí)間運(yùn)行后推理突然報(bào)錯(cuò)說設(shè)備內(nèi)存不足。用npu-smi info一看NPU內(nèi)存占用率接近100%。這通常不是真正泄漏而是推理循環(huán)里的設(shè)備內(nèi)存申請(qǐng)后沒有釋放。反查發(fā)現(xiàn)我在編寫代碼時(shí)為了圖方便每幀推理都調(diào)用了acl.rt.malloc申請(qǐng)輸入輸出Buffer卻沒有在循環(huán)結(jié)束后釋放。解法非常簡(jiǎn)單循環(huán)外一次性申請(qǐng)好所有Buffer循環(huán)內(nèi)只拷數(shù)據(jù)、推理、讀結(jié)果全部結(jié)束后統(tǒng)一釋放。能極大降低內(nèi)存碎片和分配開銷。如果你確實(shí)需要?jiǎng)討B(tài)申請(qǐng)和釋放建議用acl.rt.malloc搭配acl.rt.memset清零而不是每次再去調(diào)用acl.rt.free。7. 最后再聊兩句項(xiàng)目落地體會(huì)算下來整個(gè)部署過程環(huán)境搭建和模型轉(zhuǎn)換占的時(shí)間比實(shí)際寫推理代碼多得多。Atlas這套工具鏈不像CUDA那樣有海量資料和社區(qū)回答很多問題只能靠官方文檔和自己試驗(yàn)來解。但一旦把OM模型和推理服務(wù)跑順?biāo)谶吘壎送评韴?chǎng)景的性價(jià)比確實(shí)很突出尤其是視頻分析和多路并發(fā)場(chǎng)景下穩(wěn)定性比預(yù)期要好。如果你也是第一次在Atlas 300V上跑YOLO我建議路徑這樣走先別一上來就追求INT8量化先用FP16完整跑通一版確認(rèn)全鏈路正確再去逐步優(yōu)化。每一次只做一項(xiàng)改動(dòng)改了就用同一批測(cè)試圖回歸直到確認(rèn)無誤再動(dòng)下一項(xiàng)。所有出過的報(bào)錯(cuò)、改過的命令最好都留著記錄——Atlas這類封閉生態(tài)里你親手積累的排障經(jīng)驗(yàn)就是最值錢的生產(chǎn)力。