說(shuō)實(shí)話第一次拿到Atlas 300V 24G這塊卡的時(shí)候我第一反應(yīng)是看它的散熱器和供電接口——這分明是一張標(biāo)準(zhǔn)的被動(dòng)散熱PCIe加速卡。但真正把它插進(jìn)服務(wù)器、跑通第一個(gè)YOLO模型之后我才意識(shí)到這卡在推理場(chǎng)景下的分量。網(wǎng)上關(guān)于“Atlas 300V 24G是不是運(yùn)算加速卡”這類問(wèn)題不少也有不少人在問(wèn)怎么在Atlas上部署YOLO。這篇文章就把我從開箱、裝環(huán)境、轉(zhuǎn)模型到實(shí)際推理的完整過(guò)程寫出來(lái)包括那些踩過(guò)的坑和不看文檔根本發(fā)現(xiàn)不了的細(xì)節(jié)給準(zhǔn)備上手或正在被部署問(wèn)題折磨的朋友做個(gè)參考。1. Atlas 300V 24G到底是什么1.1 先回答它是運(yùn)算加速卡嗎結(jié)論先說(shuō)Atlas 300V 24G是一張標(biāo)準(zhǔn)的AI推理加速卡不是訓(xùn)練卡也不是普通的GPU。很多人看到“24G”第一反應(yīng)是拿它和RTX 3090、A10這類GPU比實(shí)際上兩者設(shè)計(jì)思路完全不同。Atlas 300V 24G內(nèi)部集成了昇騰AI處理器核心定位是數(shù)據(jù)中心場(chǎng)景下的深度學(xué)習(xí)推理加速不支持拿來(lái)跑訓(xùn)練也不支持CUDA生態(tài)它走的是華為自研的CANNCompute Architecture for Neural Networks軟件棧。從硬件規(guī)格上看這張卡大致是這么個(gè)配置單卡具備24GB超大顯存HBM適合超大Batch推理或者Transformer類大模型典型功耗70W左右無(wú)需外接供電通過(guò)PCIe插槽取電即可支持FP16、INT8等低精度推理尤其是INT8量化后性能釋放更充分采用無(wú)風(fēng)扇被動(dòng)散熱設(shè)計(jì)依賴服務(wù)器機(jī)箱風(fēng)道散熱。實(shí)際測(cè)試下來(lái)在YOLOv5s模型、INT8精度、輸入分辨率640x640的典型條件下單卡能穩(wěn)定跑出幾百FPS的吞吐功耗卻只有GPU方案的零頭。這就是它“加速卡”名號(hào)的真正含義——不是通用計(jì)算卡而是專門為推理場(chǎng)景優(yōu)化的高能效比設(shè)備。1.2 它適合什么場(chǎng)景Atlas 300V 24G最適合的場(chǎng)景就是視頻分析、邊緣推理服務(wù)器、批量離線推理這類對(duì)吞吐量敏感、對(duì)單卡功耗敏感的生產(chǎn)環(huán)境并且要求有一定的顯存余量以便同時(shí)加載多個(gè)模型或跑較大分辨率的輸入。我自己實(shí)際用它跑過(guò)兩類任務(wù)一類是智慧園區(qū)場(chǎng)景8路1080p視頻流同時(shí)接入每路跑一個(gè)輕量級(jí)目標(biāo)檢測(cè)模型板卡負(fù)載穩(wěn)定在60%左右視頻延遲控制在幾十毫秒以內(nèi)。另一類是離線批量推理幾萬(wàn)張圖片做目標(biāo)檢測(cè)主要吃吞吐而不是延遲這時(shí)把BatchSize調(diào)大、開啟多線程推理整卡利用率能沖到90%以上。相比之下如果你主要在本地做模型訓(xùn)練、調(diào)試、可視化Atlas 300V并不適合——驅(qū)動(dòng)生態(tài)、算子覆蓋和調(diào)試工具都和主流訓(xùn)練框架有不小距離。一句話總結(jié)買它是為了省錢省電跑推理不是為了折騰訓(xùn)練。1.3 單卡軟件棧組成很多從GPU轉(zhuǎn)過(guò)來(lái)的朋友會(huì)覺(jué)得Atlas部署很“重”其實(shí)主要是軟件棧的名字唬人。Atlas系列卡完整的軟件體系包括Driver底層驅(qū)動(dòng)負(fù)責(zé)操作系統(tǒng)與硬件設(shè)備通信Firmware固件包用于升級(jí)設(shè)備管理控制器CANN Toolkit計(jì)算庫(kù)、算子庫(kù)、圖編譯引擎和運(yùn)行時(shí)相當(dāng)于CUDAcuDNN的角色是運(yùn)行推理的必備件AscendCLACLCANN提供的統(tǒng)一推理C語(yǔ)言API類似CUDA Runtime APIMindSpore / PyTorch Adapter如果要跑訓(xùn)練或者做在線推理還需要安裝對(duì)應(yīng)的框架適配層。這個(gè)軟件棧的理解直接影響后續(xù)排障的思路后面我會(huì)詳細(xì)講每個(gè)組件的安裝順序和注意事項(xiàng)。2. 為什么選Atlas而不是GPU——選型邏輯和個(gè)人看法2.1 能效比才是關(guān)鍵從純性能來(lái)看Atlas 300V 24G和同代的中端GPU各有勝負(fù)但功耗差距非常明顯。GPU要想跑出高吞吐往往要犧牲功耗和散熱。Atlas 300V 24G的典型功耗在70W上下比一張中高端GPU低了一半還多。舉個(gè)實(shí)際例子一個(gè)20臺(tái)服務(wù)器規(guī)模的推理集群如果每臺(tái)插4張卡單卡功耗差80W整集群每小時(shí)就差6.4度電一年下來(lái)電費(fèi)差距就是幾萬(wàn)塊。如果算上散熱成本、機(jī)房容量成本這個(gè)差距還會(huì)被放大。這也是很多做視頻分析、做安防、做工業(yè)視覺(jué)的公司最終選Atlas的原因——它不是最快的但適合大規(guī)模鋪開。2.2 24G顯存帶來(lái)的操作空間24G顯存是這張卡非常有吸引力的點(diǎn)。顯存大意味著可以不那么焦慮可以同時(shí)加載多個(gè)模型通過(guò)進(jìn)程或線程隔離一張卡跑多個(gè)任務(wù)可以加載大分辨率輸入比如把YOLO的輸入從640x640提到1280x1280仍然放得下可以加載Transformer類模型比如DeTR系列、ViT系列24G能容納中等規(guī)模的模型權(quán)重和中間激活。實(shí)際測(cè)試中我把YOLOv5s和YOLOv5m兩個(gè)模型同時(shí)加載到卡里分別綁定到兩個(gè)進(jìn)程24G顯存依然有富余。在GPU上這種操作就很奢侈——光一個(gè)YOLOv5m就要好幾個(gè)GB多個(gè)模型同時(shí)駐留很容易爆顯存。2.3 適用邊界的清醒認(rèn)識(shí)不過(guò)必須承認(rèn)Atlas生態(tài)和GPU生態(tài)的差距是客觀存在的。PyTorch的很多高級(jí)功能在昇騰上跑不了一些最新的算子可能沒(méi)有適配Debug工具和社區(qū)討論也少得多。pip install torch這種操作在Atlas上行不通你得裝CANN自帶的PyTorch適配版本或者干脆用ACL的C接口或Python接口做推理。所以我的選型建議是如果你的核心訴求是“用最少的電力把模型推理跑出最高吞吐”Atlas 300V 24G是一個(gè)值得認(rèn)真考慮的候選但如果你需要大量試驗(yàn)性開發(fā)、頻繁改模型結(jié)構(gòu)、依賴最新算法庫(kù)那還是用GPU更順手。3. 在Atlas 300V 24G上部署YOLO——完整實(shí)操記錄3.1 環(huán)境準(zhǔn)備與驅(qū)動(dòng)安裝先列一下我的基礎(chǔ)環(huán)境這部分很重要因?yàn)镃ANN對(duì)不同操作系統(tǒng)和內(nèi)核版本兼容性要求比較嚴(yán)格服務(wù)器雙路x86服務(wù)器PCIe 3.0 x16插槽操作系統(tǒng)Ubuntu 20.04.6 LTS內(nèi)核5.4.0-150-genericCANN版本8.0.RC3固件與驅(qū)動(dòng)版本24.1.rc3安裝步驟建議嚴(yán)格按以下順序來(lái)亂了很容易出奇怪問(wèn)題以root用戶登錄先關(guān)閉系統(tǒng)自帶的Nouveau顯卡驅(qū)動(dòng)如果有NVIDIA卡的話避免設(shè)備沖突安裝固件包Ascend-hdk-310p-firmware_版本.run這是設(shè)備管理相關(guān)的底層軟件安裝驅(qū)動(dòng)包Ascend-hdk-310p-npu-driver_版本.run這個(gè)決定了系統(tǒng)能否識(shí)別設(shè)備安裝CANN ToolkitAscend-cann-toolkit_版本.run這是推理運(yùn)行的核心依賴安裝CANN Kernels包Ascend-cann-kernels-版本.run包含昇騰處理器的算子實(shí)現(xiàn)。每一步安裝完都可以用npu-smi info檢查設(shè)備狀態(tài)正常會(huì)看到類似下面的輸出-------------------------------------------------------------------------------------------- | npu-smi 24.1.rc3 Version: 24.1.rc3 | ------------------------------------------------------------------------------------------ | NPU Name | Health | Power(W) Temp(C) Hugepages-Free(/MB) | | 0 310P | OK | 45.8 45 0 | ------------------------------------------------------------------------------------------注意安裝順序絕對(duì)不能反先固件后驅(qū)動(dòng)再Toolkit。CANN Toolkit的安裝腳本會(huì)自動(dòng)檢測(cè)驅(qū)動(dòng)版本版本不匹配會(huì)直接報(bào)錯(cuò)中斷。3.2 獲取和轉(zhuǎn)換YOLO模型Atlas不能直接加載PyTorch生成的.pt文件需要先把模型導(dǎo)出為ONNX再用ATC工具轉(zhuǎn)換成昇騰推理專用的.om格式。流程是PyTorch模型(.pt) - ONNX(.onnx) - OM(.om)第一步用PyTorch導(dǎo)出ONNX。以YOLOv5s為例在yolov5倉(cāng)庫(kù)目錄下執(zhí)行python export.py --weights yolov5s.pt --include onnx --opset 11 --simplify這里有個(gè)關(guān)鍵細(xì)節(jié)opset一定要設(shè)置合理建議11或12不要太高。昇騰的算子適配對(duì)不同opset的支持程度不同太高容易出現(xiàn)不支持的算子。另外--simplify選項(xiàng)會(huì)調(diào)用onnx-simplifier對(duì)計(jì)算圖進(jìn)行簡(jiǎn)化能去掉很多冗余節(jié)點(diǎn)對(duì)后續(xù)ATC轉(zhuǎn)換的兼容性幫助很大。導(dǎo)出后可以用onnxruntime簡(jiǎn)單驗(yàn)證一下ONNX模型的輸出形狀確認(rèn)沒(méi)有問(wèn)題。第二步用ATC工具把ONNX轉(zhuǎn)成OM。這里需要寫一個(gè)轉(zhuǎn)換命令source /usr/local/Ascend/ascend-toolkit/set_env.sh atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP16 \ --precision_modeallow_fp32_to_fp16參數(shù)說(shuō)明--framework5固定值表示輸入模型是ONNX格式--output輸出OM文件的名稱前綴--input_shape指定模型輸入張量的形狀images必須與ONNX模型實(shí)際的輸入名一致--soc_version非常重要必須與硬件匹配Atlas 300V 24G對(duì)應(yīng)的版本是Ascend310P3填錯(cuò)了會(huì)直接報(bào)錯(cuò)--insert_op_conf插入AI PreprocessingAIPP配置文件用于把圖片縮放、歸一化這些前處理操作下沉到硬件釋放CPU和內(nèi)存帶寬--precision_mode混合精度配置允許FP32算子以FP16方式執(zhí)行提升推理速度。這里AIPP配置文件也值得寫一下我使用的是下面這個(gè)內(nèi)容aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 crop: true load_start_pos_h: 0 load_start_pos_w: 0 resize: true csc_switch: true rbuv_swap_switch: false min_chn_0: 0 max_chn_0: 255 min_chn_1: 0 max_chn_1: 255 min_chn_2: 0 max_chn_2: 255 mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 }這里順帶解釋一下YOLOv5正常推理時(shí)需要把輸入圖片resize到640x640然后在歸一化時(shí)除以255。這些操作如果不做AIPP下沉就會(huì)在推理前后的主機(jī)側(cè)代碼里一遍遍執(zhí)行For循環(huán)拷貝和計(jì)算的開銷在一批批圖片進(jìn)來(lái)的時(shí)候是很可觀的。AIPP配置之后CPU只需要把原始圖片的二進(jìn)制數(shù)據(jù)拷進(jìn)內(nèi)存縮放、通道變換、歸一化全部由昇騰處理器完成整個(gè)前處理鏈路吞吐能提高不少。3.3 編寫推理代碼——用AscendCL實(shí)現(xiàn)模型轉(zhuǎn)換完成后就可以寫推理代碼了。Atlas推理最常用的接口是AscendCLACL支持C和Python。為了照顧大多數(shù)人我這里以Python API為例。import acl import numpy as np import cv2 # 初始化 ret acl.init() ret acl.rt.set_device(0) # 加載模型 model_path byolov5s_bs1.om model_id, ret acl.mdl.load_from_file(model_path) # 準(zhǔn)備輸入輸出內(nèi)存 input_desc acl.mdl.create_tensor_desc(model_id, 0) output_desc acl.mdl.create_tensor_desc(model_id, 0) input_size acl.mdl.get_tensor_size(input_desc) output_size acl.mdl.get_tensor_size(output_desc) # 申請(qǐng)Device內(nèi)存 input_ptr acl.rt.malloc(input_size, 2) output_ptr acl.rt.malloc(output_size, 2) # 讀取圖片 img cv2.imread(test.jpg) img_rgb cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img_resized cv2.resize(img_rgb, (640, 640)) img_np img_resized.astype(np.uint8).flatten() # 拷貝輸入數(shù)據(jù)到Device acl.rt.memcpy(input_ptr, input_size, img_np.ctypes.data, input_size, 1) # 推理 acl.mdl.execute(model_id, [input_ptr], [output_ptr]) # 讀取輸出 output_np np.zeros(output_size, dtypenp.uint8) acl.rt.memcpy(output_np.ctypes.data, output_size, output_ptr, output_size, 1) # 后處理解析YOLO輸出省略錨框解碼部分 ...關(guān)于輸出解析YOLOv5的OM輸出通常已經(jīng)是經(jīng)過(guò)解碼的檢測(cè)結(jié)果包含[batch_id, class_id, score, x1, y1, x2, y2]這樣的格式取決于你導(dǎo)出ONNX時(shí)是否包含后處理部分。建議在導(dǎo)出ONNX時(shí)把后處理一起導(dǎo)出或者使用MindSpore的YOLO實(shí)現(xiàn)輸出解析會(huì)簡(jiǎn)單很多。3.4 部署之后必須驗(yàn)證的幾件事模型能跑起來(lái)只是第一步要確認(rèn)整個(gè)部署是健康的還需要做幾項(xiàng)驗(yàn)證。首先驗(yàn)證精度。找一批標(biāo)注好的測(cè)試圖片對(duì)比PyTorch原始模型的檢測(cè)結(jié)果和OM模型的結(jié)果。因?yàn)锳tlas做了FP16混合精度和INT8量化如果開了量化檢測(cè)框的置信度會(huì)有微小波動(dòng)但I(xiàn)oU和類別的變化應(yīng)在可接受范圍內(nèi)。我自己測(cè)試的YOLOv5s模型FP16模式下mAP下降不超過(guò)0.5%INT8模式下下降約1到2個(gè)百分點(diǎn)都在驗(yàn)收標(biāo)準(zhǔn)內(nèi)。其次是驗(yàn)證吞吐。用同樣的數(shù)據(jù)集跑1000張圖片統(tǒng)計(jì)單卡每秒處理的圖片數(shù)。可以在推理循環(huán)里加上時(shí)間戳也可以用npu-smi info實(shí)時(shí)觀察NPU利用率。如果NPU利用率長(zhǎng)期低于50%說(shuō)明瓶頸可能在數(shù)據(jù)傳輸或前處理上需要優(yōu)化。最后是穩(wěn)定性測(cè)試。連續(xù)推理12小時(shí)觀察是否出現(xiàn)內(nèi)存泄漏、設(shè)備異常、溫度過(guò)高等問(wèn)題。Alas 300V是被動(dòng)散熱機(jī)箱風(fēng)道不好時(shí)溫度會(huì)飆升進(jìn)而觸發(fā)降頻或保護(hù)所以散熱風(fēng)道一定要確認(rèn)好。4. 性能調(diào)優(yōu)的關(guān)鍵參數(shù)4.1 BatchSize和輸入分辨率怎么取舍Atlas 300V 24G的24GB顯存給調(diào)優(yōu)提供了非常大的空間。我實(shí)際測(cè)試了幾組配置的數(shù)據(jù)給大家做個(gè)參考YOLOv5sFP16單卡輸入分辨率BatchSize單卡吞吐FPS顯存占用640x6401約520約4GB640x6408約1200約12GB640x64016約1500約18GB1280x12801約160約6GB1280x12804約400約14GB可以看到在BatchSize1時(shí)算子啟動(dòng)和內(nèi)存搬運(yùn)的開銷占了大頭NPU計(jì)算單元是“吃不飽”的。增大BatchSize之后吞吐明顯提升但超過(guò)一定閾值后提升會(huì)變緩因?yàn)閱未瓮评淼挠?jì)算量增大、內(nèi)存帶寬也成瓶頸。分辨率同理。如果你跑的是小目標(biāo)比較多的場(chǎng)景比如無(wú)人機(jī)視角的圖像1280x1280輸入確實(shí)能提升小目標(biāo)召回率但吞吐會(huì)下降不少。實(shí)際項(xiàng)目里建議在精度可接受的范圍內(nèi)盡量用640x640把BatchSize頂上去性價(jià)比最高。4.2 多卡與多進(jìn)程Atlas 300V 24G單卡能扛的量其實(shí)已經(jīng)很可觀但如果視頻路數(shù)特別多可以考慮一張服務(wù)器插多張卡。多卡的典型用法是每個(gè)進(jìn)程綁定一張卡import os os.environ[ASCEND_DEVICE_ID] 0然后起了幾個(gè)進(jìn)程就設(shè)置不同的ASCEND_DEVICE_ID。進(jìn)程間用隊(duì)列或共享內(nèi)存分發(fā)圖片任務(wù)就能把多張卡的算力榨干。我見過(guò)不少用戶直接用多線程在單進(jìn)程里綁多卡反而因?yàn)镚IL、內(nèi)存鎖等問(wèn)題導(dǎo)致性能不升反降。多進(jìn)程隔離的方式更可靠每張卡的顯存和計(jì)算資源獨(dú)立互不干擾。4.3 開啟異步推理避免拷貝等待另一個(gè)容易忽略的調(diào)優(yōu)點(diǎn)是把同步推理改成異步推理。AscendCL提供了acl.mdl.execute_async接口可以讓數(shù)據(jù)拷貝和模型執(zhí)行重疊。在連續(xù)處理視頻幀時(shí)異步模式能在前一次推理還沒(méi)結(jié)束時(shí)就開始搬運(yùn)下一幀輸入數(shù)據(jù)隱藏掉D2H和H2D的拷貝開銷。實(shí)際測(cè)試中異步模式對(duì)視頻流的吞吐提升大約有10%-20%。代碼邏輯上只需注意輸入輸出內(nèi)存要在調(diào)用前后保持有效不能提前釋放需要顯式調(diào)用acl.rt.synchronize_stream以等待推理完成多路視頻需要為每路設(shè)置獨(dú)立的Stream避免畫面互相阻塞。5. 部署中遇到的問(wèn)題與排查實(shí)錄5.1 常見報(bào)錯(cuò)速查表從我的實(shí)操經(jīng)驗(yàn)以及結(jié)合群友的反饋整理了下面這份高頻問(wèn)題表基本覆蓋了新手期的多數(shù)事故現(xiàn)場(chǎng)。問(wèn)題現(xiàn)象原因分析解決辦法Ascend 310P is not supportedATC參數(shù)soc_version填錯(cuò)確認(rèn)硬件型號(hào)改用Ascend310P3run: no such file or directory忘記source環(huán)境變量執(zhí)行source /usr/local/Ascend/ascend-toolkit/set_env.sh模型加載失敗報(bào)E19999CANN版本和驅(qū)動(dòng)版本不匹配統(tǒng)一升級(jí)到同一版本號(hào)的配套軟件包推理輸出全零或隨機(jī)數(shù)據(jù)輸入數(shù)據(jù)未按RGB/U8格式喂入檢查AIPP配置里input_format和實(shí)際數(shù)據(jù)是否一致卡初始化失敗rt_set_device failed其他進(jìn)程占用NPU或權(quán)限不足用npu-smi info查看占用/權(quán)限添加當(dāng)前用戶到HwHiAiUser組多卡時(shí)指定卡無(wú)效環(huán)境變量ASCEND_DEVICE_ID未生效檢查是否在導(dǎo)入ACL之前設(shè)置環(huán)境變量速度比CPU還慢輸入是單張圖且BatchSize1前處理開銷大增大BatchSize、開異步推理、AIPP下沉前處理長(zhǎng)時(shí)間運(yùn)行后崩潰內(nèi)存泄漏或顯存未釋放檢查acl.rt.free釋放邏輯使用acl.rt.get_mem_info觀察內(nèi)存趨勢(shì)5.2 我自己踩過(guò)的三個(gè)坑這里分享幾個(gè)我當(dāng)時(shí)沒(méi)有立刻想明白的問(wèn)題希望后來(lái)者能繞開。第一個(gè)是AIPP配置里的src_image_size和輸入shape的關(guān)系。我一開始以為AIPP只是做歸一化不需要設(shè)置resize和crop結(jié)果輸入640x640的圖片模型倒是能跑但偶發(fā)檢測(cè)框偏移。排查了很久才發(fā)現(xiàn)問(wèn)題是resize后面的縮放比例不對(duì)原圖不是正方形AIPP裁剪后會(huì)改變目標(biāo)框坐標(biāo)比例。后來(lái)我改成在AIPP里做等比例縮放加填充或者干脆在主機(jī)側(cè)用更完整的letterbox邏輯問(wèn)題解決。第二個(gè)是環(huán)境變量問(wèn)題。用systemd把推理服務(wù)做成守護(hù)進(jìn)程時(shí)服務(wù)環(huán)境的PATH和常規(guī)shell里不一樣set_env.sh不會(huì)被自動(dòng)source。一開始定位了很久才知道是環(huán)境變量沒(méi)帶過(guò)去后來(lái)在systemd service文件里顯式通過(guò)EnvironmentFile或ExecStart前加上/bin/bash -c source ... exec python ...才繞過(guò)來(lái)。第三個(gè)是版本匹配問(wèn)題。CANN的Toolkit、驅(qū)動(dòng)、固件三個(gè)包必須是同一個(gè)版本號(hào)。我當(dāng)時(shí)用8.0的Toolkit配了低版本的驅(qū)動(dòng)拉起模型時(shí)一直報(bào)算子編譯錯(cuò)誤。這個(gè)問(wèn)題的報(bào)錯(cuò)往往很有迷惑性看起來(lái)是模型不兼容實(shí)際純粹是驅(qū)動(dòng)和Toolkit不匹配。建議安裝前直接在官方文檔頁(yè)面下載同一版本的配套包鏈接不要圖方便用通用包互相配。5.3 部署完成后的快速自檢腳本為了確認(rèn)環(huán)境是否OK可以寫一個(gè)簡(jiǎn)單的檢測(cè)腳本#!/bin/bash echo 檢查NPU設(shè)備 npu-smi info | grep -E Name|Health|Power echo 檢查環(huán)境變量 echo ASCEND_HOME_PATH${ASCEND_HOME_PATH} echo LD_LIBRARY_PATH${LD_LIBRARY_PATH} echo 檢查CANN版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg 2/dev/null echo 簡(jiǎn)單推理自檢 python3 -c import acl acl.init() ret acl.rt.set_device(0) print(ACL init OK, device:, ret) 如果最后一段Python腳本能正常打印說(shuō)明ACL運(yùn)行環(huán)境基本正?？梢蚤_始跑模型了。6. 聊聊后續(xù)可以擴(kuò)展的方向如果你已經(jīng)把YOLO在Atlas 300V 24G上跑通了其實(shí)完全可以往更深處探索。這里說(shuō)幾個(gè)我觀察到的值得嘗試的方向。一是接入視頻流推理框架。數(shù)據(jù)面用GStreamer或FFmpeg拉取RTSP流硬解碼后直接送進(jìn)ACL推理推理結(jié)果再推給下游做業(yè)務(wù)邏輯。批量視頻流場(chǎng)景下編解碼卡和Atlas加速卡配合可以做得非常絲滑。CANN也提供了針對(duì)FFmpeg的插件可以少寫很多膠水代碼。二是多模型融合推理。24G顯存余量不小可以同時(shí)駐留一個(gè)檢測(cè)模型和一個(gè)識(shí)別模型比如先檢測(cè)行人再對(duì)行人區(qū)域做屬性識(shí)別。這樣可以在一次取流中完成復(fù)雜邏輯避免多路串聯(lián)的延遲開銷。三是模型量化。ATC的INT8量化工具支持對(duì)ONNX模型做校準(zhǔn)量化量化后推理速度通常還能提升一倍左右。手頭沒(méi)有標(biāo)定集的可以先用一部分驗(yàn)證集圖片做校準(zhǔn)量化后的精度損失一般在可接受范圍內(nèi)。我自己在YOLOv5s上試過(guò)INT8后IOU精度下降不到2%但吞吐提升了將近一倍對(duì)于大規(guī)模上線場(chǎng)景來(lái)說(shuō)非常劃算。四是算子自定義。如果遇到模型里某個(gè)算子CANN不支持可以通過(guò)Ascend C算子開發(fā)工具自研算子把計(jì)算圖完整跑通。這個(gè)功能適合對(duì)性能有極致追求、并且愿意深入底層開發(fā)的朋友上手成本不低但一旦打通很多GPU不擅長(zhǎng)的AI算子反而能在昇騰上跑出驚艷的效果。7. 值得收藏的資源和經(jīng)驗(yàn)關(guān)于資源官方文檔是必須讀的CANN開發(fā)文檔里對(duì)ATC參數(shù)、AIPP配置、ACL接口的說(shuō)明都很詳盡遇到不確定的參數(shù)名直接去文檔里搜索是最穩(wěn)的方式。此外昇騰社區(qū)也有一些開源示例倉(cāng)里面的目標(biāo)檢測(cè)demo可以直接抄作業(yè)。還有一個(gè)小建議不要在初始部署時(shí)追求太新的版本。CANN每個(gè)大版本都有一些改動(dòng)如果是生產(chǎn)環(huán)境選一個(gè)經(jīng)過(guò)驗(yàn)證的穩(wěn)定版本組合遠(yuǎn)比追求“最新特性”要重要。我見過(guò)不少項(xiàng)目因?yàn)樯?jí)CANN版本導(dǎo)致跑得好好的模型突然報(bào)算子編譯錯(cuò)誤最后又回退版本。除非有明確的性能需求或bug修復(fù)需求否則保持版本鎖定是個(gè)好習(xí)慣。最后說(shuō)說(shuō)我個(gè)人在實(shí)際操作中的整體感受。Atlas 300V 24G并不是一個(gè)“什么都能干”的通用計(jì)算卡但如果你清楚自己的需求就是推理、就是高能效比、就是大批量視頻分析它確實(shí)能給出一個(gè)很令人滿意的答案。部署過(guò)程中最耗費(fèi)心力的階段是在前三天——軟件棧裝好、第一個(gè)OM模型跑通之前每一步都像在迷霧中摸索。但一旦把整體流程跑通后面不管是換模型還是加卡都會(huì)變得非常順滑。畢竟卡本身不復(fù)雜復(fù)雜的是從GPU思維切換到昇騰思維的過(guò)程這個(gè)過(guò)程只能靠動(dòng)手一步步趟出來(lái)。