去年有個(gè)朋友問我說在二手市場(chǎng)看到一塊叫“atlas 300v 24g”的卡商家說是運(yùn)算加速卡問我能不能買來跑YOLO。我第一反應(yīng)是——這東西確實(shí)是個(gè)加速卡但它不是顯卡和你想的“插上就能用”完全不是一回事。如果你正打算用Atlas系列卡部署YOLO或者已經(jīng)在折騰了但跑不通這篇內(nèi)容應(yīng)該能幫你少走不少?gòu)澛?。我從環(huán)境準(zhǔn)備、模型轉(zhuǎn)換到推理代碼、常見坑點(diǎn)把整個(gè)鏈路完整過一遍盡量說人話讓你照著就能復(fù)現(xiàn)。1. Atlas 300V是什么卡先把“運(yùn)算加速卡”這個(gè)概念捋清楚1.1 熱搜里的“atlas 300v 24g 是運(yùn)算加速卡嗎”到底該怎么理解先說結(jié)論是但它的定位是AI推理加速卡不是圖形顯卡。很多人第一次接觸Atlas都會(huì)拿它和NVIDIA的顯卡做類比然后默認(rèn)“顯存越大越能跑大模型”。這個(gè)思路對(duì)了一半但忽略了最關(guān)鍵的差異——Atlas 300V系列是基于昇騰AI處理器的推理卡它的核心職責(zé)是把已經(jīng)訓(xùn)練好的模型高效地跑起來而不是像GPU那樣兼顧訓(xùn)練、渲染、通用計(jì)算。所以它沒有顯示輸出接口不能接顯示器也不能用來玩3D游戲。那“24G”是什么指的是卡上集成的內(nèi)存容量具體型號(hào)是Atlas 300V Pro內(nèi)存帶寬和容量都比早期版本大不少用來部署YOLO這類目標(biāo)檢測(cè)模型非常合適。很多人搜索“300V 24G是不是運(yùn)算加速卡”本質(zhì)上是因?yàn)楸簧碳矣谩按箫@存”的概念誤導(dǎo)了。你要明白這塊卡的目標(biāo)場(chǎng)景是服務(wù)器端的視頻分析、邊緣推理、智慧園區(qū)這類業(yè)務(wù)不是給你當(dāng)顯卡用的。1.2 昇騰產(chǎn)品矩陣?yán)?00V Pro處在什么位置昇騰的產(chǎn)品線分為訓(xùn)練卡和推理卡兩條線。訓(xùn)練卡常見的是Atlas 800訓(xùn)練服務(wù)器里用的NPU算力強(qiáng)、功耗高、價(jià)格貴推理卡則包括Atlas 300I Duo、Atlas 300V Pro等。300V Pro的算力大約在140 TOPS INT8不同型號(hào)略有差異功耗只有幾十瓦不需要額外接輔助供電通過PCIe接口供電就可以。這個(gè)功耗表現(xiàn)和NVIDIA的T4比較接近但在某些視頻編解碼場(chǎng)景下昇騰的DVPP硬件模塊反而更有優(yōu)勢(shì)。從部署YOLO的角度來看300V Pro屬于“夠用且不浪費(fèi)”的選擇。YOLOv5s的FP16模型在300V Pro上單路推理延遲大概能做到十幾毫秒多路并發(fā)也能扛得住。相比之下如果你用Atlas 200 DK開發(fā)套件去跑YOLO雖然也能跑但受限于散熱和算力性能和穩(wěn)定性都差一截。所以如果你手頭是300V Pro 24G完全值得認(rèn)真調(diào)一調(diào)。1.3 為什么選它跑YOLO算力、顯存、功耗三角關(guān)系跑YOLO這種模型瓶頸通常不在算力而在數(shù)據(jù)搬運(yùn)和后處理。Atlas 300V Pro的24G內(nèi)存意味著你可以把多個(gè)模型的權(quán)重全部駐留在卡上避免頻繁加載模型文件。比如同時(shí)部署YOLOv5檢測(cè)、YOLOv8分割、或者一個(gè)ReID模型24G內(nèi)存都綽綽有余。功耗方面300V Pro的典型功耗在50W左右峰值也不會(huì)超過80W這點(diǎn)比很多GPU卡要友好得多。之前我看到有人拿它和RTX 3060比說3060也能跑YOLO而且更便宜。這話邏輯上沒問題但忽略了一個(gè)事實(shí)Atlas 300V Pro支持硬件視頻解碼可以同時(shí)處理多路RTSP視頻流而RTX 3060的NVENC雖然也支持硬解但在純推理場(chǎng)景下昇騰的DVPP與推理引擎的協(xié)同更高效。簡(jiǎn)單說如果你是做視頻結(jié)構(gòu)化、抓拍機(jī)分析這類項(xiàng)目300V Pro是更對(duì)口的方案。2. 部署YOLO前環(huán)境三板斧驅(qū)動(dòng)、固件、CANN2.1 驅(qū)動(dòng)和固件的版本匹配最容易翻車的地方很多人在Atlas上部署YOLO第一步就卡在驅(qū)動(dòng)上。Atlas 300V Pro不是即插即用的設(shè)備你需要安裝三個(gè)層面的東西驅(qū)動(dòng)、固件、CANN工具包。這三者的版本必須匹配否則會(huì)出現(xiàn)“npu-smi能看到卡但初始化失敗”的詭異問題。具體來說驅(qū)動(dòng)負(fù)責(zé)操作系統(tǒng)和NPU之間的通信固件負(fù)責(zé)NPU芯片自身的運(yùn)行邏輯CANN是昇騰的計(jì)算架構(gòu)類似NVIDIA的CUDA。我的建議是直接安裝“Ascend-cann-toolkit”全家桶因?yàn)镃ANN安裝包里面會(huì)附帶對(duì)應(yīng)版本的驅(qū)動(dòng)和固件。比如我用的CANN 7.0版本對(duì)應(yīng)的驅(qū)動(dòng)就是24.1.rc1這個(gè)版本組合實(shí)測(cè)過穩(wěn)定性不錯(cuò)。# 查看當(dāng)前系統(tǒng)架構(gòu)Atlas只支持aarch64或x86_64 uname -m # 安裝驅(qū)動(dòng)以x86_64為例 ./Ascend-hdk-910b-npu-driver_24.1.rc1_linux-x86_64.run --full # 安裝固件 ./Ascend-hdk-910b-npu-firmware_24.1.rc1_linux-x86_64.run --full # 安裝CANN工具包 ./Ascend-cann-toolkit_7.0.RC1_linux-x86_64.run --install安裝完成后重啟系統(tǒng)然后執(zhí)行npu-smi info如果能正常列出卡的信息說明驅(qū)動(dòng)和固件沒問題。這里有個(gè)容易踩的坑很多人裝完驅(qū)動(dòng)不重啟就直接裝CANN結(jié)果運(yùn)行npu-smi時(shí)提示“driver not ready”誤以為自己安裝失敗其實(shí)是沒重啟導(dǎo)致的。2.2 CANN工具包為什么說它是必須裝的“運(yùn)行時(shí)”CANNCompute Architecture for Neural Networks是昇騰的計(jì)算架構(gòu)包含運(yùn)行時(shí)、算子庫(kù)、圖編譯器和應(yīng)用開發(fā)接口。它類似于CUDA工具包但比CUDA更封閉一些。你在Atlas上跑YOLO無論用哪種推理引擎底層都依賴CANN提供的ACLAscend Computing Language接口。CANN裝好之后還需要設(shè)置環(huán)境變量。我個(gè)人的習(xí)慣是寫一個(gè)環(huán)境變量腳本每次開終端先source一下避免每次都手動(dòng)export。# set_env.sh source /usr/local/Ascend/ascend-toolkit/set_env.sh export ASCEND_DEVICE_ID0 export ASCEND_SLOG_PRINT_TO_STDOUT0 export ASCEND_GLOBAL_LOG_LEVEL3ASCEND_GLOBAL_LOG_LEVEL3表示只輸出ERROR級(jí)別的日志調(diào)試時(shí)改成0可以看到INFO級(jí)別的詳細(xì)輸出。這個(gè)設(shè)置對(duì)排查問題非常有幫助尤其是模型加載失敗、算子不支持這類問題日志里會(huì)明確告訴你哪個(gè)算子出了問題。2.3 Python環(huán)境和推理引擎選型MindX還是純ACLCANN裝好之后你還要選擇一個(gè)推理引擎。昇騰官方提供了MindX推理引擎但如果你只是跑YOLO我建議直接用ACL Python接口原因是依賴少、問題容易定位。MindX雖然封裝得好但版本匹配和依賴沖突很容易讓人崩潰。我個(gè)人跑YOLO用的是acllite這樣的Python封裝庫(kù)或者直接自己寫ACL調(diào)用。CANN安裝包自帶的樣程代碼在/usr/local/Ascend/ascend-toolkit/latest/tools/目錄下里面有現(xiàn)成的目標(biāo)檢測(cè)樣例支持YOLOv3/YOLOv5等模型你可以拿它作為起點(diǎn)。Python版本建議用3.7到3.10之間的版本太新或太舊都可能出現(xiàn).so文件不兼容的問題。實(shí)測(cè)在華為的openEuler系統(tǒng)上Python 3.9配合CANN 7.0是最穩(wěn)的組合。3. YOLO模型轉(zhuǎn)換從PyTorch的.pt到昇騰的.om3.1 為什么要轉(zhuǎn)換模型格式.om和推理引擎的關(guān)系PyTorch訓(xùn)練的模型是.pt格式包含了網(wǎng)絡(luò)結(jié)構(gòu)和權(quán)重但昇騰NPU不能直接運(yùn)行.pt文件你需要先用ATCAscend Tensor Compiler工具把它轉(zhuǎn)換成.om格式。這個(gè)轉(zhuǎn)換過程有點(diǎn)像把Python代碼編譯成二進(jìn)制可執(zhí)行文件轉(zhuǎn)換時(shí)會(huì)做算子融合、內(nèi)存布局優(yōu)化、量化等操作讓模型能在NPU上高效運(yùn)行。這里有一個(gè)很多人不理解的點(diǎn)pt - onnx - om和pt - om是兩條不同的路徑。雖然ATC工具可以直接讀取.pt文件但實(shí)際項(xiàng)目中我們通常先把PyTorch模型導(dǎo)出為ONNX再由ATC做ONNX到OM的轉(zhuǎn)換。這樣做的原因是ONNX格式已經(jīng)把網(wǎng)絡(luò)結(jié)構(gòu)固定下來了不容易出現(xiàn)算子映射丟失的問題而且導(dǎo)出ONNX時(shí)可以順手固定輸入尺寸、批處理大小等參數(shù)避免轉(zhuǎn)換和推理時(shí)出現(xiàn)維度不匹配。3.2 模型轉(zhuǎn)換的完整步驟以YOLOv5s為例我們以YOLOv5s為例走一遍完整流程。注意這里說的YOLOv5s是GitHub上的ultralytics版本整個(gè)轉(zhuǎn)換鏈路比較成熟。第一步在PyTorch環(huán)境里導(dǎo)出ONNX。我習(xí)慣用Python腳本導(dǎo)出而不是命令行因?yàn)榭梢栽趯?dǎo)出時(shí)修改模型結(jié)構(gòu)去掉不必要的輸出層。import torch from models.experimental import attempt_load model attempt_load(yolov5s.pt, map_locationcpu) model.eval() # 固定輸入尺寸640x640是YOLOv5的默認(rèn)輸入 dummy_input torch.randn(1, 3, 640, 640) # 導(dǎo)出ONNXopset版本推薦11 torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version11, input_names[images], output_names[output], dynamic_axesNone # 固定batch和尺寸轉(zhuǎn)換更穩(wěn)定 )導(dǎo)出時(shí)需要注意關(guān)閉dynamic_axes。昇騰NPU對(duì)動(dòng)態(tài)shape支持有限如果開啟動(dòng)態(tài)軸轉(zhuǎn)換后的.om模型推理速度會(huì)明顯下降甚至某些算子直接不支持。如果你非要?jiǎng)討B(tài)shape建議在推理時(shí)用固定shape通過AIPP的裁剪縮放來實(shí)現(xiàn)不同分辨率的輸入這個(gè)后面會(huì)提。第二步用ATC工具轉(zhuǎn)換。在安裝了CANN的環(huán)境里執(zhí)行atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_aipp \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP16 \ --input_shapeimages:1,3,640,640 \ --loginfo關(guān)鍵參數(shù)逐個(gè)說明--framework5表示輸入的是ONNX模型1代表Caffe2代表MindSpore3代表TensorFlow。--soc_version必須和你實(shí)際的芯片型號(hào)一致。Atlas 300V Pro對(duì)應(yīng)的是Ascend310P3如果你不確定可以用npu-smi info查看芯片類型。--insert_op_conf用于插入AIPP預(yù)處理配置通過AIPP可以把圖像縮放、歸一化這些操作直接做到硬件里不再占用NPU計(jì)算單元。--output_typeFP16是精度類型。YOLO這種檢測(cè)模型用FP16基本不掉點(diǎn)但速度能提升不少。AIPP配置文件的寫法如下aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 csc_switch: true rbuv_swap_switch: true min_chn_0: 0 min_chn_1: 0 min_chn_2: 0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }這個(gè)配置的意思是把輸入圖像統(tǒng)一為RGB格式的uint8然后做歸一化。rbuv_swap_switch: true表示交換R和B通道因?yàn)镺penCV讀圖是BGR順序而YOLO訓(xùn)練時(shí)用的是RGB。很多人轉(zhuǎn)換后推理精度崩了就是因?yàn)檫@個(gè)通道順序沒處理好。3.3 轉(zhuǎn)換過程中的算子支持和精度問題ATC轉(zhuǎn)換時(shí)最怕遇到不支持的算子。YOLOv5的模型結(jié)構(gòu)相對(duì)常規(guī)大部分算子都能直接映射到昇騰的底層算子庫(kù)。但有個(gè)常見的坑是torch.onnx.export導(dǎo)出的模型里可能包含ReduceL2或者某些自定義上采樣算子ATC會(huì)提示“Unsupported op”。這時(shí)候不要慌方案有兩個(gè)一是修改模型源碼用標(biāo)準(zhǔn)算子替換掉不支持的算子二是用--op_type_list參數(shù)強(qiáng)制指定替代算子。精度方面FP16轉(zhuǎn)換之后強(qiáng)烈建議做一個(gè)對(duì)比驗(yàn)證。拿同一張測(cè)試圖分別跑PyTorch原始模型和Atlas上的.om模型對(duì)比檢測(cè)框坐標(biāo)和置信度。如果精度差異超過合理范圍比如兩個(gè)模型的檢測(cè)框IoU小于0.5就要考慮是不是AIPP配置里歸一化參數(shù)寫錯(cuò)了或者模型輸出層有額外的后處理沒做對(duì)齊。4. 跑通推理代碼ACL接口下YOLO的預(yù)處理、推理、后處理4.1 初始化流程從acl.init到模型加載模型轉(zhuǎn)換完成后接下來就是寫推理代碼。我們用CANN自帶的ACL Python接口。整個(gè)過程可以分為初始化、加載模型、準(zhǔn)備輸入輸出內(nèi)存、執(zhí)行推理、解析結(jié)果五個(gè)步驟。import acl import numpy as np # 1. 初始化ACL ret acl.init() # 2. 設(shè)置設(shè)備 ret acl.rt.set_device(0) # 3. 創(chuàng)建上下文Context類似CUDA的context context, ret acl.rt.create_context(0) # 4. 加載模型 model_path b./yolov5s_aipp.om model_id, ret acl.mdl.load_from_file(model_path) # 5. 獲取模型描述信息用于后續(xù)分配內(nèi)存 model_desc acl.mdl.create_desc() ret acl.mdl.get_desc(model_desc, model_id) # 獲取輸入輸出大小 input_size acl.mdl.get_num_inputs(model_desc) output_size acl.mdl.get_num_outputs(model_desc)模型加載這一步acl.mdl.load_from_file返回的model_id是一個(gè)整數(shù)標(biāo)識(shí)后續(xù)所有推理操作都要用到。之所以要?jiǎng)?chuàng)建Context是因?yàn)镹PU設(shè)備執(zhí)行任務(wù)時(shí)需要有一個(gè)上下文環(huán)境來管理資源類似進(jìn)程句柄。這里有個(gè)常見的坑如果你用多線程推理每個(gè)線程必須單獨(dú)創(chuàng)建Context或者顯式地切換Context否則會(huì)報(bào)“ACL_ERROR_RT_CONTEXT_NULL”錯(cuò)誤。4.2 推理調(diào)用數(shù)據(jù)搬運(yùn)和模型執(zhí)行數(shù)據(jù)從內(nèi)存到NPU之間需要一個(gè)拷貝過程。ACL中負(fù)責(zé)這件事的是數(shù)據(jù)緩沖區(qū)Data Buffer。我們需要先用acl.rt.malloc在NPU上申請(qǐng)內(nèi)存然后把圖像數(shù)據(jù)拷貝進(jìn)去。# 申請(qǐng)NPU內(nèi)存 input_data np.random.randn(1, 3, 640, 640).astype(np.float16) # 創(chuàng)建數(shù)據(jù)緩沖區(qū) input_buffer acl.rt.malloc(input_data.nbytes, ACL_MEM_MALLOC_NORMAL_ONLY) # 將數(shù)據(jù)拷貝到NPU內(nèi)存 ret acl.rt.memcpy(input_buffer, input_data.nbytes, input_data.ctypes.data, input_data.nbytes, ACL_MEMCPY_HOST_TO_DEVICE) # 執(zhí)行推理 output_data, ret acl.mdl.execute( model_id, [input_buffer], [input_data.nbytes] )這里特別要注意數(shù)據(jù)格式。ACL默認(rèn)的輸入數(shù)據(jù)要求是float16而原始圖像是uint8中間的轉(zhuǎn)換需要用cv2或者numpy完成。如果你在模型轉(zhuǎn)換時(shí)用了AIPP預(yù)處理那么輸入數(shù)據(jù)就是原始的uint8圖像AIPP會(huì)自動(dòng)完成歸一化和縮放這時(shí)的輸入buffer大小就是1 * 3 * 640 * 640字節(jié)而不是乘以2float16是兩個(gè)字節(jié)。acl.mdl.execute是同步接口會(huì)阻塞到推理完成。如果想提升吞吐量可以用acl.mdl.execute_async配合Stream實(shí)現(xiàn)異步推理。異步推理是后面性能調(diào)優(yōu)的關(guān)鍵但先跑通同步版本最重要。4.3 解析輸出YOLO的detect層后處理YOLOv5的輸出是一個(gè)形狀為[1, 25200, 85]的張量。25200是三個(gè)特征圖80x80、40x40、20x20上anchor的總數(shù)85是4個(gè)坐標(biāo)、1個(gè)置信度、80個(gè)類別概率。如果你在導(dǎo)出ONNX時(shí)只保留主干輸出那么后面還需要自己在后處理里完成NMS非極大值抑制。# 這里的output_data已經(jīng)是numpy數(shù)組 predictions output_data.reshape(1, 25200, 85) # 過濾掉置信度低的框 conf_mask predictions[..., 4] 0.5 filtered predictions[conf_mask] # 對(duì)每個(gè)類別做NMS from torchvision.ops import nms boxes filtered[:, :4] scores filtered[:, 4] * filtered[:, 5:].max(axis1) nms_idx nms(torch.from_numpy(boxes), torch.from_numpy(scores), iou_threshold0.5)調(diào)試時(shí)建議先用一張已知的圖片做驗(yàn)證提前用PyTorch跑出標(biāo)準(zhǔn)結(jié)果再和Atlas輸出做對(duì)比。如果發(fā)現(xiàn)檢測(cè)框全部偏移或者置信度全為0大概率是后處理的anchor配置不對(duì)或者模型輸出的坐標(biāo)歸一化方式和你預(yù)期的不一致。5. 實(shí)測(cè)踩坑部署YOLO最容易遇到的5個(gè)問題5.1 推理結(jié)果精度崩了先查letterbox和AIPP第一次在Atlas 300V Pro上跑YOLOv5我遇到最詭異的問題是檢測(cè)框偏了大概十幾像素置信度倒是正常。排查了半天發(fā)現(xiàn)是圖像預(yù)處理不一致導(dǎo)致的。PyTorch訓(xùn)練時(shí)YOLO的預(yù)處理通常是把圖像等比縮放后填充到640x640也就是letterbox操作。但在Atlas部署時(shí)如果直接把原始圖像縮放成640x640輸入給AIPP圖像就會(huì)變形檢測(cè)框自然不準(zhǔn)。解決辦法是在主機(jī)端先完成letterbox然后把處理后的圖像交給AIPP做歸一化?；蛘咧苯釉谥鳈C(jī)端把縮放、填充、歸一化全部做掉AIPP只做數(shù)據(jù)格式轉(zhuǎn)換。我更推薦后一種方式因?yàn)檫壿嬊逦鰡栴}容易定位。def letterbox(img, new_shape640): shape img.shape[:2] r min(new_shape / shape[0], new_shape / shape[1]) new_unpad int(round(shape[1] * r)), int(round(shape[0] * r)) dw (new_shape - new_unpad[0]) / 2 dh (new_shape - new_unpad[1]) / 2 img cv2.resize(img, new_unpad, interpolationcv2.INTER_LINEAR) top, bottom int(round(dh - 0.1)), int(round(dh 0.1)) left, right int(round(dw - 0.1)), int(round(dw 0.1)) img cv2.copyMakeBorder(img, top, bottom, left, right, cv2.BORDER_CONSTANT, value(114, 114, 114)) return img5.2 模型轉(zhuǎn)換時(shí)遇到不支持的算子如何定位并繞過我轉(zhuǎn)換YOLOv8時(shí)遇到過GridSample算子不支持的問題。ATC日志會(huì)直接告訴你哪個(gè)算子、在哪個(gè)節(jié)點(diǎn)、什么原因失敗。定位到具體算子后有兩個(gè)繞法一是用ATC的--enable_small_channel之類的優(yōu)化參數(shù)有時(shí)能自動(dòng)把復(fù)雜算子拆解成多個(gè)簡(jiǎn)單算子二是修改模型源碼把不支持的算子用等價(jià)操作替換。以GridSample為例如果只是用于坐標(biāo)采樣你可以把它拆成多個(gè)Gather和StridedSlice操作雖然代碼變復(fù)雜了但至少能在NPU上跑。還有個(gè)辦法是升級(jí)CANN版本。昇騰的算子庫(kù)迭代很快可能新版本就支持了之前缺失的算子。所以在排查算子問題時(shí)先確認(rèn)CANN版本是不是最新的。5.3 推理速度上不去AIPP和DVPP的正確用法以YOLOv5s為例理論上在300V Pro上跑640x640的輸入單幀延遲應(yīng)該在20毫秒以內(nèi)。如果你發(fā)現(xiàn)延遲超過了100毫秒十有八九是圖像解碼和預(yù)處理占了大部分時(shí)間。Atlas 300V Pro的DVPP硬件模塊支持JPEG解碼和圖像縮放。如果輸入源是JPEG圖片或H.264視頻流建議用DVPP完成解碼、縮放和格式轉(zhuǎn)換而不是用OpenCV的cv2.imread和cv2.resize。DVPP的縮放性能比CPU快一個(gè)數(shù)量級(jí)。我的實(shí)際測(cè)試數(shù)據(jù)CPU端用OpenCV解碼1080p JPEG并resize到640x640單幀耗時(shí)約35毫秒用DVPP解碼加縮放耗時(shí)約8毫秒。在視頻流場(chǎng)景下這個(gè)差距非?？捎^。不過DVPP的使用門檻較高需要申請(qǐng)VPC通道、配置圖像描述符。如果你的業(yè)務(wù)對(duì)延遲不敏感可以暫時(shí)用CPU預(yù)處理但如果是多路視頻并發(fā)建議還是花時(shí)間啃一下DVPP的接口。5.4 多路并發(fā)時(shí)的內(nèi)存泄漏以及如何規(guī)避跑視頻流分析時(shí)最容易出現(xiàn)內(nèi)存緩慢增長(zhǎng)的問題。原因是每次推理循環(huán)里申請(qǐng)的NPU內(nèi)存沒有釋放。ACL的acl.rt.malloc和acl.rt.free必須成對(duì)出現(xiàn)但很多人用的是acl.mdl.execute它會(huì)自動(dòng)申請(qǐng)臨時(shí)內(nèi)存如果不顯式釋放累積下來內(nèi)存就會(huì)爆。我的經(jīng)驗(yàn)是寫一個(gè)資源管理器把每次申請(qǐng)的Buffer對(duì)象記錄下來在不需要時(shí)統(tǒng)一釋放。另外acl.rt.memcpy如果是從Device到Host方向拷貝完成后Host端的內(nèi)存可以復(fù)用不要每次循環(huán)都新建numpy數(shù)組。關(guān)于多路并行300V Pro支持多個(gè)Stream并發(fā)執(zhí)行。你可以為每路視頻創(chuàng)建一個(gè)Stream然后使用acl.mdl.execute_async把推理任務(wù)投遞到不同Stream上。實(shí)測(cè)下來4路視頻流并發(fā)推理時(shí)總吞吐量能達(dá)到單路的3.2倍以上說明多Stream并行是有效果的。5.5 npu-smi監(jiān)控與溫度控制長(zhǎng)時(shí)間運(yùn)行時(shí)建議寫一個(gè)監(jiān)控腳本定時(shí)讀取npu-smi info的輸出重點(diǎn)關(guān)注芯片溫度和內(nèi)存占用。300V Pro是 passively cooled的卡如果機(jī)箱風(fēng)道不好溫度會(huì)飆升到90度以上然后NPU開始降頻推理延遲突然變高。如果你的服務(wù)器是塔式機(jī)箱建議給卡加一個(gè)輔助散熱風(fēng)扇或者把機(jī)箱側(cè)板打開。數(shù)據(jù)中心環(huán)境里通常服務(wù)器的前置風(fēng)扇足夠但在邊緣網(wǎng)關(guān)里這個(gè)問題很常見。6. 性能調(diào)優(yōu)與量產(chǎn)部署建議6.1 延遲和吞吐量的平衡策略部署YOLO到生產(chǎn)環(huán)境時(shí)你要先明確業(yè)務(wù)指標(biāo)是追求單幀延遲低還是多路并發(fā)吞吐高這兩個(gè)方向在300V Pro上的調(diào)優(yōu)策略完全不同。追求延遲時(shí)需要做三件事把模型的batch size固定為1、使用ACL_MEM_MALLOC_HUGE_FIRST分配大頁(yè)內(nèi)存、避免在推理前打印日志。實(shí)測(cè)下大頁(yè)內(nèi)存能降低約10%的延遲因?yàn)樵贜PU和CPU之間搬運(yùn)數(shù)據(jù)時(shí)緩存命中率更高。追求吞吐量時(shí)應(yīng)該用動(dòng)態(tài)batch。ATC轉(zhuǎn)換時(shí)把input_shape設(shè)成1,3,640,640但推理時(shí)通過acl.mdl.set_dynamic_batch_size在運(yùn)行時(shí)設(shè)置batch大小。比如一次輸入4張圖雖然單幀延遲略有增加但整體吞吐量提升了三倍。6.2 多路視頻流的異步推理實(shí)現(xiàn)異步推理的核心是不要阻塞在acl.mdl.execute上而是用Stream把多個(gè)推理任務(wù)串起來。ACL的推理流程是創(chuàng)建多個(gè)Stream每個(gè)Stream綁定一路視頻流的預(yù)處理和推理。每路視頻流循環(huán)執(zhí)行解碼取幀 - 預(yù)處理 - 投遞推理 - 讀取結(jié)果。在實(shí)現(xiàn)上需要注意acl.mdl.execute_async的最后一個(gè)參數(shù)是Stream句柄。如果你希望多路并行一定要給每路創(chuàng)建獨(dú)立的Stream# 每路視頻流創(chuàng)建獨(dú)立的Stream stream_list [] for i in range(4): stream, ret acl.rt.create_stream() stream_list.append(stream) # 推理時(shí)指定stream ret acl.mdl.execute_async(model_id, input_buffer, output_buffer, stream)有個(gè)坑execute_async返回后推理可能還沒完成你需要acl.rt.synchronize_stream(stream)來等待結(jié)果。如果忘了同步讀出來的數(shù)據(jù)可能是舊數(shù)據(jù)。6.3 從Atlas 300V Pro到整個(gè)昇騰部署生態(tài)跑通YOLO之后你會(huì)發(fā)現(xiàn)昇騰生態(tài)有個(gè)別的平臺(tái)沒有的優(yōu)勢(shì)模型轉(zhuǎn)換、推理、編解碼都是閉環(huán)的。如果你需要把結(jié)果傳到云端CANN提供了acldvpp和acllite等模塊可以組合出“視頻接入 - 推理分析 - 結(jié)構(gòu)化輸出 - 上傳”的完整鏈路。部署時(shí)還可以用昇騰官方的ModelBox框架來編排流程。ModelBox類似GStreamer通過配置圖的方式把視頻流、推理、輸出串起來。雖然是圖形化編排但底層還是ACL接口。如果你只是做簡(jiǎn)單驗(yàn)證用Python腳本就夠了但如果是給客戶交付項(xiàng)目建議用ModelBox因?yàn)樗腻e(cuò)誤處理、日志管理、資源釋放都更規(guī)范。關(guān)于模型后續(xù)的維護(hù)建議保留一份ONNX模型文件和AIPP配置文件方便隨CANN版本迭代重新轉(zhuǎn)換。昇騰新版本發(fā)布后舊模型可能需要重新轉(zhuǎn)換才能獲得性能提升有源碼在手就隨時(shí)能重新生成。我個(gè)人在實(shí)際部署中的體會(huì)是Atlas 300V Pro這塊卡的單卡算力雖然不是頂級(jí)但勝在功耗低、內(nèi)存大、視頻處理硬件能力強(qiáng)特別適合YOLO這類目標(biāo)檢測(cè)模型的多路視頻分析場(chǎng)景。最難熬的其實(shí)是第一次從GPU思維切換到NPU思維的過程只要理解了模型轉(zhuǎn)換、AIPP預(yù)處理、ACL推理這三件事后面就順暢了。最后再分享一個(gè)小技巧遇到奇怪問題時(shí)先把ASCEND_GLOBAL_LOG_LEVEL調(diào)成0看完整的INFO日志絕大部分問題都能在日志里找到答案比在網(wǎng)上瞎搜有效得多。