年初調(diào)一個(gè)邊緣端項(xiàng)目客戶要求業(yè)務(wù)部門現(xiàn)有的YOLO檢測鏈路不能換但硬件平臺(tái)要換成Atlas。當(dāng)時(shí)拿到Atlas 300V 24G的樣卡第一反應(yīng)是這玩意到底算不算一張運(yùn)算加速卡能不能直接把GPU上的推理代碼搬過來用網(wǎng)上資料翻了一圈要么是官方文檔的術(shù)語堆砌要么是廣告味十足的軟文真正講清楚“這卡能干什么、不能干什么、怎么把模型跑起來”的實(shí)操貼少得可憐。那陣子前后折騰了兩周多踩了不少坑也把Atlas這套從驅(qū)動(dòng)到CANN工具鏈的底摸了個(gè)大概。這篇文章不打算重復(fù)官方手冊就按我實(shí)際動(dòng)手的順序把Atlas是什么、300V 24G這個(gè)型號(hào)的真實(shí)定位、YOLO模型遷移部署的完整過程以及那些文檔里不會(huì)寫的問題挨個(gè)梳理一遍。想給自家業(yè)務(wù)選型、或者正準(zhǔn)備在Atlas上跑目標(biāo)檢測模型的讀者一個(gè)參照。1. 認(rèn)識(shí)Atlas它解決的是算力“最后一公里”問題1.1 Atlas產(chǎn)品線從邊緣盒子到訓(xùn)練集群華為的Atlas系列本質(zhì)上是一整套圍繞AI計(jì)算打造的硬件和軟件棧覆蓋場景非常寬小到一盞電源就能帶動(dòng)的邊緣計(jì)算盒子大到能撐起千億參數(shù)大模型訓(xùn)練的集群級(jí)設(shè)備。很多人一說Atlas就以為是一張卡其實(shí)這是整個(gè)產(chǎn)品家族的統(tǒng)稱。我接觸過的型號(hào)大致可以分三檔邊緣側(cè)Atlas 200/300系列功耗極低適合做視頻流分析、智能攝像頭這類端側(cè)推理通常以開發(fā)者套件或加速模塊的形式出現(xiàn)。推理側(cè)Atlas 300系列有PCIe插卡形態(tài)也有板載形態(tài)主要給服務(wù)器做推理加速。300V 24G就是這一檔的產(chǎn)品。訓(xùn)練側(cè)Atlas 800/900系列面向數(shù)據(jù)中心大規(guī)模訓(xùn)練搭載昇騰910等高性能芯片。不同檔位的卡定位差距非常大。200系列是極致低功耗算力有限300系列是通用服務(wù)器推理場景的加速卡800以上才碰訓(xùn)練。很多人拿Atlas和NVIDIA的GPU直接比嚴(yán)格來說是拿整個(gè)產(chǎn)品線跟對方全系列比容易產(chǎn)生誤讀。1.2 Atlas的核心優(yōu)勢到底在哪里拋開具體的芯片不談Atlas平臺(tái)真正的護(hù)城河在于軟件棧。CANNCompute Architecture for Neural Networks是昇騰的計(jì)算架構(gòu)承擔(dān)了和CUDA類似的作用負(fù)責(zé)把上層框架PyTorch、TensorFlow、MindSpore的計(jì)算邏輯映射到底層硬件上。硬件是骨架CANN才是靈魂。剛開始理解這點(diǎn)很重要——單純看Atlas的芯片規(guī)格、TOPS數(shù)值其實(shí)很難判斷它在實(shí)際業(yè)務(wù)中的表現(xiàn)。同樣的算力指標(biāo)軟件棧調(diào)度效率、算子優(yōu)化程度不同真實(shí)推理延遲可能差出一倍。Atlas的硬件設(shè)計(jì)比較強(qiáng)調(diào)AI計(jì)算的專用性比如矩陣運(yùn)算單元做了專門強(qiáng)化這讓它在跑CNN這類算子密集的模型時(shí)效率不錯(cuò)但通用計(jì)算能力就遠(yuǎn)不如GPU了。這也是我后面在部署YOLO時(shí)體會(huì)最深的一點(diǎn)算法適配得好不好比卡本身的算力數(shù)字更關(guān)鍵。2. Atlas 300V 24G是不是一張“運(yùn)算加速卡”——拆開看真相Atlas 300V 24G這個(gè)型號(hào)在知乎、CSDN上一度被反復(fù)搜索。問的人多半和我當(dāng)時(shí)一樣手里有張卡或者采購單上出現(xiàn)這個(gè)型號(hào)不確定它到底是拿來挖礦的、跑圖形的、還是正經(jīng)做AI推理的。直接給結(jié)論這卡是標(biāo)準(zhǔn)的AI推理運(yùn)算加速卡全稱是Atlas 300V Pro融合了昇騰610芯片顯存24GB主打的是數(shù)據(jù)中心的視頻分析、目標(biāo)檢測、圖像分類等推理加速場景和圖形渲染、科學(xué)計(jì)算這類通用計(jì)算完全不搭邊。2.1 硬件規(guī)格與“24G顯存”的真實(shí)含義300V 24G的硬件規(guī)格我整理了一個(gè)表格方便直觀對照參數(shù)Atlas 300V 24G芯片昇騰610顯存24GB形態(tài)PCIe 4.0 x16 全高全長功耗最大150W典型場景推理加速、視頻分析、CV模型INT8算力約400TOPS視具體型號(hào)支持精度INT8 / FP16部分型號(hào)支持系統(tǒng)兼容鯤鵬服務(wù)器 / x86服務(wù)器需平臺(tái)適配“24G”指的是HBM顯存容量主要服務(wù)對象是AI推理中的權(quán)重和中間特征圖。它不負(fù)責(zé)輸出畫面所以別指望拿它接顯示器跑游戲也跟挖礦沒有關(guān)系——挖礦講究的是高并發(fā)通用計(jì)算而300V的架構(gòu)是為矩陣運(yùn)算深度優(yōu)化的專用推理設(shè)計(jì)跟這類場景完全不在一個(gè)頻道上?？ㄉ蠘?biāo)注的INT8算力確實(shí)亮眼但這是模型量化之后的數(shù)字實(shí)際使用FP16或FP32推理時(shí)算力會(huì)明顯回落。我個(gè)人實(shí)測下來300V跑滿血FP16的YOLOv8s吞吐量和INT8模式差兩倍以上。所以看規(guī)格書時(shí)別只盯著峰值TOPS要問清楚這個(gè)數(shù)字是在什么精度下得出的。2.2 與GPU加速卡的定位差異用一張300V替換服務(wù)器里的某塊GPU做AI推理理論可行但中間有一段不短的遷移成本。最大的差異在于軟件生態(tài)NVIDIA有CUDA cuDNN TensorRT這套成熟得不能再熟的鏈路PyTorch模型轉(zhuǎn)成TensorRT引擎社區(qū)教程一抓一大把。Atlas對應(yīng)的是CANN ATC模型轉(zhuǎn)換工具 AscendCL推理接口鏈路本身是完整的但資料密度和社區(qū)活躍度遠(yuǎn)不如CUDA生態(tài)遇到問題經(jīng)常得自己啃手冊。我把這張卡部署到測試服務(wù)器上之后第一感覺就是“硬件插上容易軟件跑通不容易”。驅(qū)動(dòng)、固件、CANN工具箱三層軟件必須版本匹配缺一個(gè)對不上就報(bào)錯(cuò)。這一點(diǎn)后面單獨(dú)講。另外功耗和散熱的差異也值得注意。300V滿負(fù)載時(shí)功耗可以達(dá)到150W左右如果服務(wù)器本身是給GPU預(yù)留的散熱設(shè)計(jì)問題不大但如果是普通CPU服務(wù)器PCIe槽位的供電和風(fēng)道可能不夠跑高負(fù)載時(shí)卡溫度會(huì)快速爬升。我一開始在大機(jī)箱里裸跑沒加輔助散熱連續(xù)推理半小時(shí)后卡面溫度到了85度以上。2.3 什么業(yè)務(wù)適合選它結(jié)合我自己以及周邊同行的使用反饋300V 24G適合這么幾類情況政企項(xiàng)目硬性要求國產(chǎn)化硬件CPU、服務(wù)器、加速卡都有信創(chuàng)合規(guī)指標(biāo)業(yè)務(wù)場景相對固定模型結(jié)構(gòu)不是三天兩頭就換比如安防攝像頭里的固定目標(biāo)檢測推理并發(fā)量中等不需要像大規(guī)模GPU集群那樣彈性擴(kuò)展有算法團(tuán)隊(duì)愿意投入一到兩周做模型遷移和性能調(diào)優(yōu)。反過來如果團(tuán)隊(duì)很小、沒人愿意碰CANN工具鏈或者模型迭代頻繁、每周都在改網(wǎng)絡(luò)結(jié)構(gòu)那先用GPU把業(yè)務(wù)跑起來、回頭再評(píng)估遷移可能更穩(wěn)妥。技術(shù)選型沒有絕對的好壞關(guān)鍵看有沒有人力承接遷移成本。3. 在Atlas 300V上部署YOLO的完整路徑Atlas部署YOLO是我這次踩坑的起點(diǎn)也是最值得展開的部分。長話短說從一張干凈的x86服務(wù)器到Y(jié)OLOv5在300V上穩(wěn)定跑起來我大概用了四天其中兩天半在折騰環(huán)境和模型轉(zhuǎn)換。下面按步驟拆解。3.1 環(huán)境準(zhǔn)備驅(qū)動(dòng)、固件、CANN三層缺一不可Atlas的軟件棧分為三個(gè)層次順序不能亂驅(qū)動(dòng)Driver操作系統(tǒng)與硬件通信的基礎(chǔ)固件Firmware與芯片底層交互通常和驅(qū)動(dòng)一起發(fā)布CANN工具包偏上層包含模型轉(zhuǎn)換工具ATC、推理運(yùn)行時(shí)AscendCL、算子庫等。只看官方文檔的時(shí)候容易被長長的版本對照表整暈。實(shí)際上核心原則很簡單驅(qū)動(dòng)、固件、CANN三個(gè)包必須從同一個(gè)昇騰軟件版本索引里下載三者的版本要一一對應(yīng)。我用的組合是Ubuntu 20.04 x86_64 CANN 7.0.0 對應(yīng)驅(qū)動(dòng)固件包。安裝過程走的是一個(gè).sh腳本中間會(huì)檢測系統(tǒng)環(huán)境和PCIe設(shè)備。這里有個(gè)容易忽略的點(diǎn)如果你是在虛擬機(jī)上裝驅(qū)動(dòng)很可能裝不上因?yàn)锳tlas設(shè)備通常要求直通物理硬件。安裝順序建議是先裝驅(qū)動(dòng)重啟確認(rèn)卡能被識(shí)別再裝固件然后裝CANN。驗(yàn)證驅(qū)動(dòng)是否正常的小命令npu-smi info如果輸出里有設(shè)備ID、芯片溫度、內(nèi)存占用這些信息說明驅(qū)動(dòng)和固件都正常了。這是我排查環(huán)境問題用的第一個(gè)工具。提示 安裝前用uname -a查一下內(nèi)核版本官方對內(nèi)核有明確支持范圍不匹配的話驅(qū)動(dòng)編不過后面排查起來很麻煩。3.2 模型轉(zhuǎn)換從PyTorch權(quán)重到OM離線模型Atlas推理不支持直接加載PyTorch的.pt權(quán)重必須先把模型轉(zhuǎn)換成CANN專用的OM格式。轉(zhuǎn)換工具是ATCAscend Tensor Compiler。這里要特別強(qiáng)調(diào)不要手寫.onnx導(dǎo)出再指望ATC自動(dòng)完成所有優(yōu)化中間很多坑是需要人工介入的。我的標(biāo)準(zhǔn)轉(zhuǎn)換流程如下首先在PyTorch側(cè)把訓(xùn)練好的YOLOv5模型導(dǎo)出為ONNX。注意YOLOv5默認(rèn)的導(dǎo)出腳本會(huì)帶上NMS后處理算子但這個(gè)算子往往不被CANN完整支持。我的做法是導(dǎo)出時(shí)加參數(shù)--no-nms把檢測頭的原始輸出導(dǎo)出來NMS放到推理后處理里用代碼實(shí)現(xiàn)。python export.py --weights yolov5s.pt --include onnx --opset 11 --no-nms導(dǎo)出后建議先用onnx-simplifier瘦身一下刪掉部分冗余算子能降低后續(xù)ATC轉(zhuǎn)換的失敗率python -m onnxsim yolov5s.onnx yolov5s_sim.onnx然后執(zhí)行ATC轉(zhuǎn)換atc --modelyolov5s_sim.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend610 \ --output_typeFP16參數(shù)說明--framework55代表ONNX1代表MindSpore2代表TensorFlow--soc_versionAscend610必須和卡上芯片匹配填錯(cuò)直接報(bào)錯(cuò)--output_typeFP16模型計(jì)算精度FP16性能和精度權(quán)衡比較好--input_shape輸入尺寸batch size先設(shè)為1調(diào)通了再改。轉(zhuǎn)換過程中ATC會(huì)輸出每一層的算子映射日志這里能提前發(fā)現(xiàn)哪些算子不支持。我第一次轉(zhuǎn)換時(shí)遇到一個(gè)HardSigmoid算子不兼容日志明確標(biāo)紅了。解決辦法是在PyTorch導(dǎo)出前把激活函數(shù)替換成ReLU6或者用CANN支持的組合算子重新訓(xùn)練或者重導(dǎo)一次。3.3 推理代碼改造熟悉AscendCL的調(diào)用邏輯模型轉(zhuǎn)換完真正要寫代碼的部分來了。CANN的推理接口叫AscendCL直接對著C/C啃效率太低幸好官方提供了Python接口torch_npu和mindspore兩者都支持加載OM模型。如果你傾向用PyTorch的推理風(fēng)格最順手的方案是torch_npu。它能讓你以接近PyTorch原生代碼的方式加載OM模型做推理。下面是我實(shí)際跑通YOLOv5推理的簡化邏輯import torch import torch_npu import numpy as np import cv2 from ais_bench.infer.interface import InferSession # 加載OM模型 session InferSession(device_id0, model_pathyolov5s_bs1.om) # 預(yù)處理resize normalize與導(dǎo)出ONNX時(shí)保持一致 img cv2.imread(test.jpg) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img cv2.resize(img, (640, 640)) img img.astype(np.float32) / 255.0 img img.transpose(2, 0, 1) # HWC - CHW # 推理 outputs session.infer(feeds[img]) # outputs為list包含檢測頭的原始輸出 # 后處理解析bbox、score做NMS關(guān)于InferSession它是ais_bench推理工具鏈提供的封裝接口比直接操作AscendCL的C接口友好太多官方昇騰社區(qū)有配套源碼可以直接pip安裝。它支持多batch、動(dòng)態(tài)shape、輸入輸出內(nèi)存管理等基本上把CANN的復(fù)雜度擋在了外層。后處理部分是另一個(gè)容易踩坑的地方。導(dǎo)出的ONNX去掉了NMS所以輸出層的shape是類似[1, 25200, 85]這樣的結(jié)構(gòu)根據(jù)模型版本可能不同需要自己實(shí)現(xiàn)解碼邊界框、過濾低置信度的框、執(zhí)行NMS。這里的坐標(biāo)解碼方式和YOLOv5官方代碼完全一致直接復(fù)用就行。3.4 靜態(tài)batch與動(dòng)態(tài)shape的選擇推理性能有一個(gè)關(guān)鍵開關(guān)靜態(tài)batch還是動(dòng)態(tài)shape。剛開始我擔(dān)心視頻流里目標(biāo)數(shù)量波動(dòng)大想用動(dòng)態(tài)shape但隨即發(fā)現(xiàn)問題動(dòng)態(tài)shape模式下AscendCL每次推理前要對輸入做shape推導(dǎo)和內(nèi)存重分配性能損耗明顯。對于固定分辨率、固定batch的檢測場景用靜態(tài)shape能發(fā)揮硬件最優(yōu)性能。我最后的生產(chǎn)配置是輸入固定為1×3×640×640batch size為1。實(shí)測單張圖片在300V上FP16推理耗時(shí)約8到12毫秒這個(gè)成績對多數(shù)視頻流場景足夠了。如果追求更高吞吐量可以轉(zhuǎn)出batch size為4或8的OM模型推理時(shí)一次性喂多幀圖像吞吐量能往上走一大截但每幀時(shí)延會(huì)略有升高。業(yè)務(wù)上根據(jù)吞吐優(yōu)先還是時(shí)延優(yōu)先去平衡。4. 部署中的坑與排查經(jīng)驗(yàn)4.1 ATC模型轉(zhuǎn)換失敗算子不兼容是頭號(hào)難題模型轉(zhuǎn)換這一步前期基本是在跟算子死磕。YOLOv5官方實(shí)現(xiàn)里用了不少在GPU生態(tài)里稀松平常的操作比如nn.SiLU就是Swish激活函數(shù)在CANN的算子庫里雖然支持但某些特殊組合下依舊可能出現(xiàn)映射失敗。我踩到的一個(gè)具體問題是模型里有一層nn.SiLU算子在ACT轉(zhuǎn)換時(shí)提示“GatherND”算子不兼容。后來查閱CANN的算子支持清單發(fā)現(xiàn)是某個(gè)版本的算子庫對GatherND在4D張量上的支持不完整。解決思路有兩種升級(jí)CANN版本治標(biāo)不治本新版本可能引入新問題修改模型結(jié)構(gòu)把GatherND換成等價(jià)的臨時(shí)處理治本。第二種方案會(huì)動(dòng)模型結(jié)構(gòu)調(diào)整后需要重新訓(xùn)練或微調(diào)。如果想省事建議一開始就換用官方發(fā)布的YOLOv5 6.0以上版本它對ONNX導(dǎo)出的兼容度更好。另一個(gè)容易讓人疑惑的問題是ATC轉(zhuǎn)換成功的OM模型跑起來結(jié)果不對坐標(biāo)全亂。這種情況多半是輸入圖像預(yù)處理與模型訓(xùn)練時(shí)不一致。YOLOv5官方源碼里的預(yù)處理是letterbox等比縮放補(bǔ)邊如果你推理代碼里直接粗暴resize寬高比變形就會(huì)帶來精度大幅下降。我一開始為了省事用直接resize結(jié)果mAP掉了將近10個(gè)點(diǎn)排查半天才意識(shí)到是這個(gè)原因。4.2 驅(qū)動(dòng)與CANN的版本兼容性Atlas的軟件棧版本兼容性問題幾乎是所有新手繞不過去的一道坎。CANN不同版本支持的算子種類不一樣驅(qū)動(dòng)也有最低版本要求三者有一方不合適就會(huì)冒出各種奇怪的報(bào)錯(cuò)[ERROR] RUNTIME(30000) kernel execute failed這類錯(cuò)誤流程上就是算子執(zhí)行失敗但觸發(fā)因素可能非常多顯存不足、輸入數(shù)據(jù)尺寸不對、驅(qū)動(dòng)與固件版本不匹配。排查方式?jīng)]有捷徑只能一層層剝先確認(rèn)npu-smi info顯示設(shè)備正常再跑CANN自帶的樣例程序最后才輪到你自己的模型。官方社區(qū)其實(shí)給了很多適配好的demo跑通demo再往自己代碼上遷移是效率最高的路徑。我第二次部署新環(huán)境時(shí)直接先跑了CANN包里自帶的ResNet50推理樣例確認(rèn)環(huán)境沒問題再開始轉(zhuǎn)換YOLO模型問題定位速度快很多。4.3 Onnx導(dǎo)出時(shí)的動(dòng)態(tài)軸設(shè)置隱患再補(bǔ)充一個(gè)我一開始忽略的細(xì)節(jié)ONNX導(dǎo)出時(shí)如果對動(dòng)態(tài)軸處理不當(dāng)ATC轉(zhuǎn)換出來的OM模型推理會(huì)非常慢甚至報(bào)錯(cuò)。YOLOv5的export.py默認(rèn)把batch維設(shè)成動(dòng)態(tài)我一開始沒管ATC轉(zhuǎn)換時(shí)輸入shape寫的是-1,3,640,640結(jié)果模型能轉(zhuǎn)能跑但每幀推理耗時(shí)飆到40多毫秒比固定shape慢了三倍以上。原因很簡單動(dòng)態(tài)維度的模型在AscendCL底層調(diào)度時(shí)放棄了部分算子的預(yù)編譯優(yōu)化每次推理都走了一個(gè)更通用的執(zhí)行路徑。固定shape能把算子的計(jì)算圖編譯優(yōu)化做到極致這是Atlas這類專用架構(gòu)的優(yōu)勢所在前提是你得把shape定死。所以模型轉(zhuǎn)換建議直接用--input_shapeimages:1,3,640,640不要用-1除非業(yè)務(wù)對動(dòng)態(tài)分辨率有硬性要求。4.4 推理時(shí)內(nèi)存增長的排查思路還有一次測試長時(shí)間運(yùn)行發(fā)現(xiàn)顯存占用一直在漲跑了幾個(gè)小時(shí)后卡死。用npu-smi info觀察內(nèi)存從2G漲到接近滿。這通常指向推理側(cè)沒有及時(shí)釋放中間張量。AscendCL的接口設(shè)計(jì)中輸入輸出張量需要顯式管理內(nèi)存不像PyTorch那樣有自動(dòng)回收機(jī)制。如果用的是InferSession建議在每輪推理后主動(dòng)釋放上一次的輸出引用或者干脆復(fù)用同一塊輸入輸出內(nèi)存可以有效避免內(nèi)存增長。# 每次推理前給輸入賦值而不是新建數(shù)組 session.infer(feeds[img_ndarray])這行代碼看起來平平無奇但如果你在循環(huán)里每次都創(chuàng)建一個(gè)新的numpy數(shù)組喂進(jìn)去長時(shí)間跑下來內(nèi)存就會(huì)緩緩爬升。定位到這個(gè)問題之后我改成預(yù)分配輸入輸出buffer再跑48小時(shí)內(nèi)存穩(wěn)定不動(dòng)。4.5 性能調(diào)優(yōu)別急著改代碼先確認(rèn)瓶頸位置性能不達(dá)標(biāo)的時(shí)候很容易陷入瞎調(diào)參的循環(huán)。我的經(jīng)驗(yàn)是先做定性判斷看npu-smi info的輸出如果推理時(shí)NPU利用率很低說明瓶頸在CPU側(cè)的數(shù)據(jù)預(yù)處理或后處理不在卡上如果NPU利用率接近滿載但幀率依然不夠才需要優(yōu)化模型本身比如換更小的YOLO版本、降低輸入分辨率、做量化。實(shí)際測試中YOLOv5s在300V上的FP16推理速度是跑不滿卡的因?yàn)轭A(yù)處理環(huán)節(jié)的resize、歸一化、通道轉(zhuǎn)換都跑在CPU上CPU成了瓶頸。解決思路有幾個(gè)開多線程預(yù)處理、把數(shù)據(jù)流水線化或者把圖像尺寸進(jìn)一步縮小到480×480。我在視頻流場景里把分辨率從640降到480精度下降不到1個(gè)點(diǎn)吞吐量提升了接近40%這個(gè)換算是很劃算的。4.6 常見報(bào)錯(cuò)速查表為了方便排查我把這幾周遇到的高頻報(bào)錯(cuò)整理成了表格報(bào)錯(cuò)信息可能原因解決方向driver package install failed內(nèi)核版本不匹配確認(rèn)系統(tǒng)內(nèi)核在支持列表內(nèi)ATC model convert failed, unsupported op模型含不兼容算子更換算子或升級(jí)CANN版本runtime kernel execute failed顯存不足或shape錯(cuò)誤檢查輸入尺寸和顯存占用device open failed驅(qū)動(dòng)未加載或權(quán)限不足執(zhí)行npu-smi info檢查設(shè)備model compile failed動(dòng)態(tài)shape未正確設(shè)定改用固定shape重新轉(zhuǎn)換5. 為什么Atlas更適合“模型固定、場景專注”的業(yè)務(wù)把YOLO跑起來之后我對Atlas的適用邊界想得更清楚了。它跟GPU的區(qū)別有點(diǎn)像一個(gè)專用機(jī)床和一個(gè)萬能工作臺(tái)的關(guān)系萬能工作臺(tái)GPU什么活兒都能接但每個(gè)活兒都不是最精細(xì)的專用機(jī)床Atlas只針對特定形狀的加工做了極致優(yōu)化換產(chǎn)品類型就要換刀具。如果你所在業(yè)務(wù)正好是長期跑同一個(gè)檢測模型場景不會(huì)頻繁變動(dòng)Atlas完全可以作為主力推理硬件。尤其目標(biāo)檢測這類CV任務(wù)算子結(jié)構(gòu)相對統(tǒng)一Atlas的INT8算力優(yōu)勢能發(fā)揮得比較充分。反過來如果團(tuán)隊(duì)做的是探索性AI實(shí)驗(yàn)今天跑個(gè)Transformer、明天跑個(gè)擴(kuò)散模型那Atlas的靈活度會(huì)明顯掣肘。另外Atlas在推理任務(wù)上有一個(gè)隱性優(yōu)勢功耗比做得不錯(cuò)。300V標(biāo)稱150W而一塊對應(yīng)性能的GPU顯卡往往要200W到300W長時(shí)間7×24小時(shí)跑電費(fèi)差異是一個(gè)可觀的數(shù)字。對運(yùn)維來說也意味著同樣的機(jī)柜能塞下更多算力機(jī)房的整體規(guī)劃和散熱壓力更小。6. 一個(gè)真實(shí)的數(shù)據(jù)300V跑YOLOv8的實(shí)測結(jié)果作為參考數(shù)據(jù)我給出在300V 24G上跑YOLOv8s的一個(gè)實(shí)測記錄。使用的環(huán)境是Ubuntu 20.04CANN 7.0模型輸入640×640FP16精度batch1。推理時(shí)間主要分三段數(shù)據(jù)預(yù)處理、算子推理、后處理。階段耗時(shí)毫秒數(shù)據(jù)預(yù)處理圖像讀取、resize、歸一化約4-6算子推理NPU執(zhí)行約8-12后處理解碼、NMS約2-4端到端單幀總耗時(shí)約15-20按這個(gè)耗時(shí)算單卡能跑大約50-60FPS的視頻流實(shí)際部署時(shí)按25FPS接入多路視頻余量比較充足。如果是YOLOv5s模型推理階段還能再快一些端到端能到15毫秒以內(nèi)。注意 數(shù)字受到模型版本、圖尺寸、CANN版本和服務(wù)器CPU性能的多重影響。CPU弱的環(huán)境里預(yù)處理占比會(huì)明顯上升上述數(shù)據(jù)僅供參考不代表所有環(huán)境都能復(fù)現(xiàn)。7. 一個(gè)容易被忽略的點(diǎn)模型生命周期管理把OM模型部署上線只是第一步之后的迭代維護(hù)才是長線問題。YOLO模型不是訓(xùn)練一次就固定不變的數(shù)據(jù)變了、誤檢多了總要重新訓(xùn)練。每次訓(xùn)練新版本OM模型就要重新轉(zhuǎn)換、重新測試、重新灰度發(fā)布。這時(shí)候如果手工操作過程繁瑣且容易出錯(cuò)。我后期的做法是寫了一套自動(dòng)化腳本訓(xùn)練完P(guān)yTorch權(quán)重自動(dòng)觸發(fā)ONNX導(dǎo)出再做ATC轉(zhuǎn)換然后跑一組固定的驗(yàn)證集mAP達(dá)標(biāo)就推送測試環(huán)境。整個(gè)流程從半天縮減到二十分鐘也降低了人工誤操作的概率。有一點(diǎn)必須提醒ATC轉(zhuǎn)換的目標(biāo)--soc_version參數(shù)和CANN版本必須和線上環(huán)境一致。如果你在開發(fā)機(jī)上用新版本CANN轉(zhuǎn)換而生產(chǎn)環(huán)境還是老版本驅(qū)動(dòng)很可能出現(xiàn)OM模型加載失敗或性能回退。最好開發(fā)、測試、生產(chǎn)三套環(huán)境的CANN版本保持一致。8. 最后分享兩個(gè)小經(jīng)驗(yàn)第一個(gè)經(jīng)驗(yàn)是關(guān)于團(tuán)隊(duì)協(xié)作的。Atlas的調(diào)試工具鏈不像CUDA生態(tài)那么豐富出了問題可參考的資料有限。我建了個(gè)小團(tuán)隊(duì)內(nèi)部文檔把每次報(bào)錯(cuò)、排查步驟、解決方案都記錄下來包括CANN版本、驅(qū)動(dòng)版本、模型結(jié)構(gòu)、轉(zhuǎn)換命令這些信息。這周積累下來的文檔后面成了團(tuán)隊(duì)里新同學(xué)上手最快的培訓(xùn)材料比讓他們自己啃官方手冊高效太多。建議凡是準(zhǔn)備長期使用Atlas的團(tuán)隊(duì)都做這么一件事。第二個(gè)經(jīng)驗(yàn)是關(guān)于采購和驗(yàn)收的。如果采購Atlas 300V 24G到貨后先用npu-smi info驗(yàn)證設(shè)備再跑一遍CANN自帶的樣例模型同時(shí)測試平臺(tái)兼容性。我見過有同行因?yàn)榉?wù)器BIOS設(shè)置問題導(dǎo)致PCIe識(shí)別不到卡排查了好幾天的例子。這些和卡本身無關(guān)但確實(shí)是部署時(shí)最常見的一類問題。提前把環(huán)境底子打牢后面做算法遷移才能把注意力集中在模型本身。