最近后臺(tái)好多人在問(wèn)同一個(gè)問(wèn)題網(wǎng)上說(shuō)的Atlas 300V 24G到底是不是運(yùn)算加速卡能不能拿來(lái)部署YOLO先說(shuō)結(jié)論能而且我實(shí)際測(cè)試下來(lái)它是目前邊緣側(cè)跑YOLO系列模型性價(jià)比很高的一個(gè)方案尤其適合多路視頻分析這類場(chǎng)景。這篇文章我用一次真實(shí)的部署過(guò)程把Atlas 300V 24G的硬件定位、環(huán)境準(zhǔn)備、YOLO模型轉(zhuǎn)換和推理全流程以及我在實(shí)際踩坑中總結(jié)出來(lái)的排錯(cuò)方法一次性講清楚。內(nèi)容完全基于CANN工具鏈和昇騰推理引擎適合手里已經(jīng)有卡、正準(zhǔn)備把目標(biāo)檢測(cè)模型從GPU遷過(guò)來(lái)的同學(xué)也適合正在做硬件選型、想搞明白這張卡和普通GPU到底差在哪兒的算法工程師。1. Atlas 300V 24G是什么先把這個(gè)加速卡的真實(shí)定位搞清楚1.1 它不是GPU而是專用的推理加速卡先說(shuō)直白一點(diǎn)的結(jié)論Atlas 300V 24G部分渠道也叫Atlas 300V Pro是華為昇騰Atlas產(chǎn)品線里的一塊AI推理加速卡不是用來(lái)做訓(xùn)練的GPU。它搭載的是昇騰310P系列芯片板載24GB內(nèi)存主打的是數(shù)據(jù)中心或者邊緣服務(wù)器里的模型推理場(chǎng)景尤其擅長(zhǎng)視頻圖像類的任務(wù)。很多第一次接觸的人會(huì)把它和顯卡混為一談這個(gè)認(rèn)知需要先糾正過(guò)來(lái)它不能插上就裝CUDA也不能直接跑PyTorch的訓(xùn)練腳本它的軟件棧是CANN模型需要經(jīng)過(guò)轉(zhuǎn)換之后才能在卡上運(yùn)行。一張Atlas 300V 24G的卡上通常有多顆AI處理核心官方標(biāo)稱的INT8算力大致在140 TOPS這個(gè)級(jí)別不同批次和型號(hào)可能有差異具體以規(guī)格書為準(zhǔn)。這個(gè)數(shù)字聽(tīng)起來(lái)可能沒(méi)有某些頂級(jí)GPU嚇人但關(guān)鍵在于它的形態(tài)和功耗整卡功耗大概在70W上下被動(dòng)散熱為主不占太多供電資源普通PCIe服務(wù)器上能輕松插多張。對(duì)做視頻分析的人來(lái)說(shuō)這張卡還帶硬件視頻解碼能力H.264/H.265都能解這是很多通用GPU不具備的功能。這里有一個(gè)經(jīng)常被問(wèn)到的點(diǎn)Atlas 300V 24G用來(lái)訓(xùn)練YOLO行不行我的建議是不要這么干。它是推理卡訓(xùn)練效率很低而且很多訓(xùn)練算子根本不支持。正確的用法是在GPU或者云上把YOLO訓(xùn)練好得到權(quán)重文件然后轉(zhuǎn)換格式部署到Atlas 300V上做推理。也就是說(shuō)它解決的是“部署”這一環(huán)而不是“訓(xùn)練”這一環(huán)。1.2 為什么視覺(jué)項(xiàng)目選它的人越來(lái)越多我在實(shí)際項(xiàng)目里選擇Atlas 300V 24G主要是三個(gè)理由。第一是視頻路數(shù)成本。單卡能硬解碼多路1080p視頻流配合YOLO做目標(biāo)檢測(cè)平攤到每路視頻的硬件成本很低比用CPU軟解再推理的方案省太多事。第二是推理性能穩(wěn)定。YOLOv5s、YOLOv8s這類輕量模型在這張卡上能做到很高的吞吐配合batch和stream調(diào)優(yōu)后單卡跑幾十路小目標(biāo)檢測(cè)是常見(jiàn)的。由于算力以INT8為主配合量化后的YOLO模型性能還能再上一個(gè)臺(tái)階。第三是生態(tài)已經(jīng)成熟起來(lái)。CANN工具鏈這幾年迭代很快ATC模型轉(zhuǎn)換、MindX SDK、MindIE這些組件對(duì)ONNX模型的支持已經(jīng)比較完善。YOLO系列作為最常用的檢測(cè)模型官方樣例、社區(qū)教程都有不少遇到問(wèn)題不會(huì)像早期那樣孤立無(wú)援。所以如果項(xiàng)目是邊緣側(cè)的視頻檢測(cè)、工業(yè)質(zhì)檢、智慧安防這類場(chǎng)景預(yù)算有限又要同時(shí)處理多路視頻Atlas 300V 24G是非常值得考慮的。2. 部署YOLO前的硬性準(zhǔn)備驅(qū)動(dòng)、固件和CANN工具鏈2.1 硬件環(huán)境與版本匹配先說(shuō)最容易翻車的地方Atlas 300V 24G是PCIe板卡插在服務(wù)器主板上就能用。服務(wù)器可以是x86也可以是ARMUbuntu 20.04/22.04、openEuler、CentOS等主流Linux發(fā)行版都有對(duì)應(yīng)的驅(qū)動(dòng)和固件包。開(kāi)始裝之前最要緊的一件事是查官方“驅(qū)動(dòng)-固件-CANN”版本兼容列表。我遇到過(guò)很多次奇怪報(bào)錯(cuò)最后發(fā)現(xiàn)是驅(qū)動(dòng)和CANN版本不匹配導(dǎo)致的。這里說(shuō)的“版本匹配”不是簡(jiǎn)單地都裝最新版就行而是要三個(gè)組件的版本在同一個(gè)發(fā)布周期內(nèi)。比如你裝了24.1.RC1的驅(qū)動(dòng)和固件那CANN最好也配套使用同一期的版本。版本錯(cuò)位最常見(jiàn)的表現(xiàn)是驅(qū)動(dòng)裝完后npu-smi info能認(rèn)卡但一跑模型就報(bào)內(nèi)部錯(cuò)誤或者ATC轉(zhuǎn)換時(shí)報(bào)各種找不到算子的錯(cuò)誤。排查起來(lái)非常浪費(fèi)時(shí)間不如裝之前就把版本對(duì)應(yīng)關(guān)系確認(rèn)好。另一個(gè)容易忽略的點(diǎn)是BIOS設(shè)置。某些服務(wù)器默認(rèn)關(guān)掉了PCIe的較大地址空間Resizable BAR或者沒(méi)有開(kāi)啟Above 4G Decoding會(huì)導(dǎo)致大內(nèi)存的加速卡初始化失敗。裝驅(qū)動(dòng)前建議先檢查BIOS里這幾個(gè)選項(xiàng)確保PCIe設(shè)備枚舉正常。另外如果服務(wù)器上插了多張卡還要注意PCIe通道數(shù)量和散熱風(fēng)道這些都會(huì)影響實(shí)際性能。2.2 驅(qū)動(dòng)、固件、CANN的安裝與驗(yàn)證安裝流程本身不復(fù)雜核心是三個(gè)run包驅(qū)動(dòng)包、固件包、CANN工具包。以我常用的Ubuntu 20.04為例拿到對(duì)應(yīng)架構(gòu)的run包后一般是這樣操作# 安裝驅(qū)動(dòng)和固件以實(shí)際包名為準(zhǔn) ./Ascend-hdk-310p-npu-driver_24.1.rc1_linux-x86_64.run --full ./Ascend-hdk-310p-npu-firmware_24.1.rc1_linux.run --full # 重啟后檢查是否被識(shí)別 npu-smi info這里特別提醒驅(qū)動(dòng)和固件的安裝順序有講究不同版本的run包可能要求先裝驅(qū)動(dòng)再裝固件或者反過(guò)來(lái)。我習(xí)慣先裝驅(qū)動(dòng)、重啟機(jī)器再裝固件、再重啟一次。雖然麻煩了點(diǎn)但能避免第一次安裝時(shí)找不到設(shè)備的問(wèn)題。能識(shí)別卡之后接著裝CANN工具包./Ascend-cann-toolkit_8.0.RC3_linux-x86_64.run --install source /usr/local/Ascend/ascend-toolkit/set_env.sh裝完后用npu-smi info看一眼應(yīng)該能看到類似下面的信息芯片溫度、功耗、內(nèi)存占用、AI Core利用率都是0。看到這些字段說(shuō)明卡和工具鏈都正常工作了。如果npu-smi info都報(bào)錯(cuò)不要急著往下走先把這一步解決了再繼續(xù)后面所有問(wèn)題都依賴這一層。3. YOLO模型部署全流程從PyTorch權(quán)重到OM模型再到推理3.1 第一步把YOLO權(quán)重導(dǎo)出成ONNXAtlas卡不能直接加載PyTorch的pt權(quán)重所以第一步要把模型轉(zhuǎn)換成ONNX格式。YOLOv5和YOLOv8官方倉(cāng)庫(kù)都提供了導(dǎo)出腳本以YOLOv8為例yolo export modelyolov8s.pt formatonnx opset12YOLOv5那邊則是python export.py --weights yolov5s.pt --include onnx --opset 12 --img 640 --batch 1導(dǎo)出的時(shí)候有幾個(gè)細(xì)節(jié)要注意。opset不能太低建議11以上否則部分算子轉(zhuǎn)換時(shí)可能出問(wèn)題。導(dǎo)出時(shí)動(dòng)態(tài)維度一般會(huì)默認(rèn)設(shè)置但是為了后續(xù)ATC轉(zhuǎn)換簡(jiǎn)單我通常會(huì)在導(dǎo)出時(shí)把輸入shape固定成模型訓(xùn)練時(shí)的尺寸比如640x640。如果一定要支持多尺寸可以在ATC階段配置動(dòng)態(tài)shape但那會(huì)讓轉(zhuǎn)換和推理都復(fù)雜不少新手不建議一上來(lái)就搞。導(dǎo)出之后用onnxruntime在CPU上跑一次確認(rèn)導(dǎo)出的ONNX模型算出的結(jié)果和PyTorch原模型基本一致。這一步非常重要——它能幫你把“模型導(dǎo)出問(wèn)題”和“Atlas部署問(wèn)題”隔離開(kāi)否則后面精度不對(duì)時(shí)你不知道是卡的問(wèn)題還是導(dǎo)出時(shí)就已經(jīng)錯(cuò)了。實(shí)測(cè)中常見(jiàn)的問(wèn)題包括輸出節(jié)點(diǎn)順序變了、后處理里的NMS沒(méi)有導(dǎo)出YOLOv8默認(rèn)導(dǎo)出時(shí)不帶NMS、預(yù)處理歸一化是否被包含進(jìn)圖里。這些都會(huì)影響后續(xù)在卡上的表現(xiàn)。3.2 第二步ATC模型轉(zhuǎn)換把ONNX變成OMONNX模型準(zhǔn)備好之后用ATC工具把它轉(zhuǎn)換成昇騰的OM格式。OM是Atlas推理引擎真正加載的模型文件轉(zhuǎn)換過(guò)程會(huì)做算子映射、圖優(yōu)化和量化編譯這是Atlas部署和GPU部署最大的不同?；久钍沁@樣atc --modelyolov8s.onnx \ --framework5 \ --outputyolov8s_bs1 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --loginfo各個(gè)參數(shù)的意思framework5表示輸入是ONNX模型soc_version要填你手里那塊卡的芯片版本Atlas 300V 24G一般是Ascend310P3但不同批次可能不一樣不確認(rèn)的話用npu-smi info查或者在官方對(duì)照表里找input_shape要和導(dǎo)出ONNX時(shí)的輸入名、shape完全一致output是輸出文件前綴。這里特別要注意YOLOv5和YOLOv8的ONNX輸入節(jié)點(diǎn)名可能不一樣我見(jiàn)過(guò)有的版本叫images有的叫input一定要先用Netron看一眼再填input_shape。如果你的模型需要?jiǎng)討B(tài)batch可以加--dynamic_batch_size1,2,4,8這樣轉(zhuǎn)換出的OM模型在推理時(shí)能選擇不同batch靈活性更高。但代價(jià)是轉(zhuǎn)換時(shí)間和運(yùn)行性能可能會(huì)有損失所以只做固定分辨率的項(xiàng)目我更推薦靜態(tài)batch一個(gè)batch對(duì)應(yīng)一次編譯性能最穩(wěn)。ATC轉(zhuǎn)換失敗時(shí)日志會(huì)提示具體是哪個(gè)算子不支持。YOLO這種常見(jiàn)模型一般問(wèn)題不大但如果你自定義了模型結(jié)構(gòu)偶爾會(huì)遇到某些算子沒(méi)有被CANN支持。這時(shí)候的常規(guī)處理思路是要么換一個(gè)等價(jià)算子的實(shí)現(xiàn)方式要么升級(jí)到更高版本CANN要么在網(wǎng)絡(luò)上找適配插件。日志信息看多了之后你會(huì)發(fā)現(xiàn)絕大多數(shù)轉(zhuǎn)換失敗都能從日志里定位到具體算子。3.3 第三步用pyACL寫最小推理程序模型轉(zhuǎn)好了接下來(lái)就是寫推理程序。最直接的方式是用pyACLAscend Computing Language的Python接口它和CUDA Runtime API的用法有點(diǎn)像先初始化再加載模型然后創(chuàng)建輸入輸出執(zhí)行推理。下面是一個(gè)最小框架import acl import numpy as np def init(): acl.init() acl.rt.set_device(0) context, ret acl.rt.create_context(0) def load_model(om_path): model_id, ret acl.mdl.load_from_file(om_path) desc acl.mdl.create_desc() ret acl.mdl.get_desc(desc, model_id) return model_id, desc # 根據(jù)desc申請(qǐng)輸入輸出內(nèi)存創(chuàng)建dataset # 用acl.mdl.execute執(zhí)行推理 # 推理完成后釋放資源代碼本身不難但要寫的完整可運(yùn)行還有不少細(xì)節(jié)。比如輸入數(shù)據(jù)要先從PIL或者OpenCV的圖像矩陣轉(zhuǎn)成NCHW排布的連續(xù)內(nèi)存然后copy到設(shè)備側(cè)輸出需要根據(jù)模型描述里的輸出維度申請(qǐng)內(nèi)存。CANN安裝目錄下自帶不少sample里面有完整的pyACL推理程序我第一次部署時(shí)就是照著一個(gè)YOLO的sample改的比自己閉門造車快得多。我在實(shí)際項(xiàng)目里輸入預(yù)處理通常放在Python端做先用OpenCV做letterbox縮放再除以255歸一化然后轉(zhuǎn)成float32的np.array最后喂給模型。這樣處理雖然占用一點(diǎn)CPU但邏輯清晰也方便排查精度問(wèn)題。如果你想追求極致性能可以把圖像解碼和預(yù)處理下沉到卡上用AIPP或者獨(dú)立的圖像處理庫(kù)完成這就是后話了。3.4 第四步驗(yàn)證結(jié)果與基本性能檔案第一個(gè)推理程序跑通之后先不要急著接業(yè)務(wù)。拿幾張有代表性的真實(shí)圖片對(duì)比一下昇騰上的推理結(jié)果和GPU上的推理結(jié)果確認(rèn)檢測(cè)框、置信度都一致再去做性能測(cè)試。性能測(cè)試時(shí)重點(diǎn)看幾個(gè)指標(biāo)單幀時(shí)延、吞吐量、AI Core利用率。用npu-smi info在推理過(guò)程中觀察如果AI Core利用率能跑到70%以上說(shuō)明卡的算力基本被吃滿了如果只有10%左右大概率是數(shù)據(jù)拷貝或者預(yù)處理成了瓶頸需要想辦法把更多操作下沉到卡上。以我實(shí)測(cè)的YOLOv8s為例輸入640x640、batch1時(shí)單幀推理時(shí)延通常在幾毫秒到十幾毫秒之間這個(gè)數(shù)字比很多GPU在小batch下都要好。batch調(diào)到4或8之后吞吐量還能線性增長(zhǎng)這也是Atlas卡在小模型場(chǎng)景下的優(yōu)勢(shì)所在。3.5 進(jìn)階路線多路視頻用MindX SDK更省事如果你的項(xiàng)目不是單張圖片推理而是幾十路視頻流同時(shí)檢測(cè)再繼續(xù)用純pyACL去寫多路并發(fā)代碼量會(huì)變得很大。這時(shí)候更推薦用MindX SDK它是昇騰上一層的推理框架核心思路是把“解碼-縮放-推理-后處理”這些環(huán)節(jié)拆成一個(gè)個(gè)plugin用pipeline配置文件串聯(lián)起來(lái)。一個(gè)典型的視頻檢測(cè)pipeline大致長(zhǎng)這樣視頻流經(jīng)過(guò)mxpi_videodecoder插件做硬解碼輸出圖像幀再經(jīng)過(guò)圖像預(yù)處理插件然后送入mxpi_tensorinfer插件調(diào)用OM模型推理最后從輸出端口拿檢測(cè)結(jié)果。整個(gè)過(guò)程用yaml配置文件描述業(yè)務(wù)代碼只需要關(guān)注數(shù)據(jù)流的輸入和輸出。相比自己用pyACL從零搭多路視頻處理MindX SDK在工程化上省了很多事而且硬解碼和推理的銜接是官方優(yōu)化過(guò)的性能和穩(wěn)定性都有保障。4. 性能和精度的調(diào)優(yōu)思路部署完先別急著上線4.1 性能調(diào)優(yōu)三板斧batch、stream、硬解碼跑通只是第一步真要拿到生產(chǎn)環(huán)境性能調(diào)優(yōu)是繞不開(kāi)的。我總結(jié)了三板斧batch、stream、硬解碼。batch最簡(jiǎn)單。對(duì)于檢測(cè)模型單幀推理往往喂不滿整卡算力把多幀拼成一個(gè)batch一起推理吞吐量能提一大截。但batch不是越大越好要結(jié)合模型的輸出大小、顯存上限和延遲要求來(lái)定。YOLOv8s這種模型在24G版本的卡上batch調(diào)到16甚至更高都不會(huì)爆顯存但如果業(yè)務(wù)對(duì)延遲敏感就適當(dāng)減小batch換時(shí)延。我一般會(huì)做一個(gè)簡(jiǎn)單的粗調(diào)先用batch1測(cè)出單幀時(shí)延再嘗試batch2、4、8畫一條時(shí)延-吞吐曲線找到拐點(diǎn)位置。stream是CANN里更trick的部分。通俗理解batch是讓一條流水線一次處理多份數(shù)據(jù)stream則是開(kāi)多條流水線并行處理。用多個(gè)stream同時(shí)執(zhí)行推理能把AI Core的空閑時(shí)間填得更滿。實(shí)際調(diào)優(yōu)時(shí)我會(huì)先固定batch然后逐步增加stream數(shù)量觀察利用率和時(shí)延的變化找到吞吐和延遲的平衡點(diǎn)。這塊沒(méi)有固定公式不同模型、不同分辨率差距很大只能實(shí)測(cè)。硬解碼則是Atlas卡的獨(dú)特優(yōu)勢(shì)。如果輸入是視頻流優(yōu)先用卡上的硬件解碼器把視頻幀解出來(lái)再走推理這樣CPU占用會(huì)非常低。用軟件解碼加推理的方案即使當(dāng)時(shí)看起來(lái)性能夠一旦視頻路數(shù)增加CPU可能會(huì)先成為瓶頸。所以視頻類項(xiàng)目這一步一定不能省。4.2 精度對(duì)齊的幾個(gè)關(guān)鍵點(diǎn)性能上去了精度也不能丟。昇騰卡跑YOLO的精度問(wèn)題和GPU不太一樣常見(jiàn)的原因有這幾個(gè)。第一是預(yù)處理不一致。GPU上跑的時(shí)候如果你在PyTorch里用了某個(gè)固定的歸一化方式到了昇騰上就必須保持完全一致。letterbox的填充顏色、歸一化的scale因子、通道順序任何一個(gè)細(xì)節(jié)變了檢測(cè)精度都會(huì)受影響。我建議在Python端把預(yù)處理統(tǒng)一封裝好兩邊共用同一套代碼從根上避免這種問(wèn)題。第二是AIPP的錯(cuò)誤使用。AIPP功能很強(qiáng)大它能把圖像解碼、縮放、歸一化這些操作下沉到推理前的硬件管線里但配置稍有差池比如mean和var填反了、輸入格式填成了RGB卻喂了BGR數(shù)據(jù)模型輸出立刻就會(huì)亂套。如果不想在這上面花時(shí)間最簡(jiǎn)單的辦法是把預(yù)處理全部留在Python端完成不要配AIPP等精度驗(yàn)證通過(guò)后再考慮用AIPP提性能。第三是ONNX模型里是否帶了后處理。YOLOv8的導(dǎo)出結(jié)果默認(rèn)是不帶NMS的你在GPU上的后處理邏輯要原樣拿過(guò)來(lái)用不能在昇騰上自創(chuàng)一套。很多精度異常最后查出來(lái)都是后處理代碼和模型輸出節(jié)點(diǎn)對(duì)不上而不是卡本身的問(wèn)題。4.3 一個(gè)多路視頻場(chǎng)景的調(diào)優(yōu)實(shí)例我之前做過(guò)一個(gè)智慧園區(qū)的項(xiàng)目要求同時(shí)檢測(cè)20路1080p視頻里的人、車、物。最初方案是每路視頻單獨(dú)跑一個(gè)pyACL推理實(shí)例結(jié)果AI Core利用率只有20%左右視頻還偶爾掉幀。后來(lái)我做了三處調(diào)整第一視頻解碼全部換成卡上的硬解碼器CPU占用立刻降了一大截第二推理部分改成一個(gè)獨(dú)立線程池用4個(gè)stream并行提交任務(wù)相當(dāng)于把流水線拆成多條避免單stream排隊(duì)第三根據(jù)業(yè)務(wù)對(duì)實(shí)時(shí)性的要求把batch控制在4既保證吞吐又控制單幀延遲。調(diào)整之后20路視頻穩(wěn)定運(yùn)行AI Core利用率能到50%到60%基本符合預(yù)期。這個(gè)案例想說(shuō)明的是Atlas卡的性能是調(diào)出來(lái)的不是裝上就滿血。大多數(shù)人一上來(lái)就怪卡不行其實(shí)是batch和stream配置沒(méi)到位。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 五個(gè)高頻問(wèn)題排錯(cuò)第一個(gè)高頻問(wèn)題是驅(qū)動(dòng)裝完后npu-smi info找不到卡。這種問(wèn)題九成出在版本匹配和BIOS設(shè)置上。先確認(rèn)驅(qū)動(dòng)、固件、CANN三者版本在兼容列表里再檢查BIOS的Above 4G Decoding和Resizable BAR有沒(méi)有開(kāi)啟最后看看PCIe插槽是否被系統(tǒng)正確枚舉?？梢杂胠spci | grep -i ascend來(lái)看系統(tǒng)是否認(rèn)到了PCIe設(shè)備。第二個(gè)是ATC轉(zhuǎn)換時(shí)算子報(bào)錯(cuò)?？吹紼19999一類的錯(cuò)誤碼先別慌打開(kāi)日志目錄下的atc日志搜fail或者unsupported定位到具體算子。常見(jiàn)做法是替換成等價(jià)算子。如果模型來(lái)自YOLO官方倉(cāng)庫(kù)一般不會(huì)有這種問(wèn)題遇到的多是自定義結(jié)構(gòu)。第三個(gè)是推理時(shí)程序崩潰或者報(bào)內(nèi)存錯(cuò)誤。多半是輸入輸出數(shù)據(jù)的shape、類型和模型描述不一致。pyACL對(duì)內(nèi)存對(duì)齊有要求申請(qǐng)?jiān)O(shè)備內(nèi)存時(shí)要用acl提供的接口不能隨便拿numpy數(shù)組直接傳。第四個(gè)是精度和GPU結(jié)果對(duì)不上。先用onnxruntime在相同輸入上跑一遍確認(rèn)識(shí)別結(jié)果和PyTorch一致再在昇騰上用相同預(yù)處理跑逐步對(duì)比每一層的輸出定位哪一步開(kāi)始分叉。實(shí)際處理中大多數(shù)情況都出在預(yù)處理差異上只有少數(shù)是量化精度損失。第五個(gè)是顯存/內(nèi)存占用異?；蛘叨嗫ɡ寐什痪狻z查分配輸入輸出時(shí)是否按batch申請(qǐng)了足夠空間多卡場(chǎng)景則要確認(rèn)任務(wù)是否均勻分發(fā)到了不同卡上避免一張卡跑滿另一張卡閑置。5.2 一張能救急的排查速查表我把項(xiàng)目里最常遇到的問(wèn)題整理成一張表新人遇到類似情況可以直接照著查現(xiàn)象可能原因排查方向npu-smi info報(bào)錯(cuò)或找不到卡驅(qū)動(dòng)固件未裝/版本不匹配/BIOS未開(kāi)啟相關(guān)選項(xiàng)查版本兼容列表重裝匹配版本檢查BIOSATC轉(zhuǎn)換失敗報(bào)E19999算子不支持或CANN版本過(guò)舊查看atc日志定位算子升級(jí)CANN推理結(jié)果明顯錯(cuò)誤預(yù)處理不一致/AIPP配置錯(cuò)誤/后處理對(duì)不上統(tǒng)一Python預(yù)處理先關(guān)閉AIPP推理程序崩潰輸入輸出shape或內(nèi)存對(duì)齊錯(cuò)誤核對(duì)模型desc用acl接口申請(qǐng)內(nèi)存AI Core利用率很低單batch、無(wú)stream、CPU拷貝瓶頸增大batch增加stream下沉重處理多路視頻性能不足未使用硬解碼CPU瓶頸啟用硬件解碼器讓卡處理解碼這張表的價(jià)值在于大部分問(wèn)題在第一次接觸昇騰時(shí)都會(huì)遇到而且都有一個(gè)共同特點(diǎn)不是單一原因?qū)е碌亩菐讉€(gè)前置條件疊加出來(lái)的。所以排查的時(shí)候不要只盯著癥狀本身要從環(huán)境、模型、代碼三個(gè)層面逐項(xiàng)排查。最后說(shuō)點(diǎn)個(gè)人經(jīng)驗(yàn)。用Atlas卡部署模型很多人第一反應(yīng)是把它當(dāng)成GPU來(lái)用這是最大的坑。它和CUDA生態(tài)的思維不一樣CANN強(qiáng)調(diào)圖優(yōu)化和算子歸并所以模型能不能跑得快很多時(shí)候取決于你轉(zhuǎn)OM時(shí)怎么配置圖和預(yù)處理而不是純粹看芯片參數(shù)。我建議新手第一次拿到卡先別急著跑自己的模型把官方提供的YOLO樣例完整跑一遍確認(rèn)環(huán)境沒(méi)問(wèn)題再換自己的權(quán)重。另外驅(qū)動(dòng)、固件、CANN這三個(gè)版本一定要保持對(duì)應(yīng)關(guān)系最好在官方兼容性列表里勾一下能省掉后面很多奇怪的報(bào)錯(cuò)。如果你正在做視頻檢測(cè)類的項(xiàng)目記得把硬解碼器用起來(lái)那才是Atlas卡相比普通GPU最明顯的主場(chǎng)優(yōu)勢(shì)。這張卡不適合所有人但適合它的場(chǎng)景里它確實(shí)能做得又穩(wěn)又省。