Atlas 300V 24G這塊卡最近在安防視頻分析和邊緣計(jì)算圈子里討論度很高。我搜了下后臺(tái)數(shù)據(jù)atlas部署yolo和atlas 300v 24g 是運(yùn)算加速卡嗎這兩組詞被問(wèn)得最多說(shuō)明不少人拿到卡之后第一件事就是想跑目標(biāo)檢測(cè)卻又對(duì)這塊卡的定位和部署鏈路一知半解。這篇文章我不講虛的就圍繞我實(shí)際把YOLOv5部署到Atlas 300V 24G上的完整經(jīng)歷來(lái)寫從硬件選型到模型轉(zhuǎn)換再到性能調(diào)優(yōu)把能復(fù)現(xiàn)的步驟和踩過(guò)的坑一并交代清楚。先回答那個(gè)被問(wèn)了無(wú)數(shù)次的問(wèn)題Atlas 300V 24G確實(shí)是運(yùn)算加速卡但它是推理加速卡不是訓(xùn)練卡更不是用來(lái)跑CUDA的GPU。搞清楚這一點(diǎn)后面所有部署思路都不會(huì)走偏。1. Atlas 300V 24G到底是一張什么卡1.1 先搞懂Atlas家族的定位華為Atlas產(chǎn)品線特別容易把人繞暈300I、300V、300T、200 DK、500 A2名字長(zhǎng)得像用途差很多。我拿手里這批卡梳理一下一張表就能看明白型號(hào)芯片定位典型場(chǎng)景Atlas 300I昇騰310P純推理加速卡通用深度學(xué)習(xí)推理、OCR、分類Atlas 300V昇騰310P視頻推理加速卡視頻結(jié)構(gòu)化、智能安防、目標(biāo)檢測(cè)跟蹤Atlas 300T昇騰910訓(xùn)練加速卡模型訓(xùn)練、大規(guī)模并行計(jì)算Atlas 200 DK昇騰310開(kāi)發(fā)者套件學(xué)習(xí)、原型驗(yàn)證、嵌入式開(kāi)發(fā)Atlas 500 A2昇騰310P智能邊緣小站邊緣盒子、一體機(jī)方案我第一次拿到Atlas 300V 24G的時(shí)候第一反應(yīng)是找它的CUDA核心數(shù)找了一圈發(fā)現(xiàn)這思路本身就有問(wèn)題。昇騰芯片用的是達(dá)芬奇架構(gòu)根本不存在CUDA的概念算力單位是TOPS衡量的是INT8整數(shù)運(yùn)算能力。300V Pro這顆310P芯片的INT8算力大約在140 TOPS相當(dāng)于什么概念呢一張中高端GPU能跑的推理負(fù)載它基本都能接得住但功耗只有幾十瓦。1.2 它確實(shí)是運(yùn)算加速卡但跟GPU玩法完全不一樣回到搜索熱詞的問(wèn)題本身Atlas 300V 24G是運(yùn)算加速卡這一點(diǎn)沒(méi)有任何疑問(wèn)。它專門干的就是矩陣運(yùn)算、卷積運(yùn)算、神經(jīng)網(wǎng)絡(luò)推理這些重計(jì)算的活。24G這個(gè)顯存容量在推理卡里屬于大塊頭我記得第一次用npu-smi看顯存占用時(shí)還愣了一下——一張推理卡給到24G意味著你可以同時(shí)塞進(jìn)去好幾個(gè)模型或者跑那種吃顯存的超大batch推理這在純推理場(chǎng)景里是很奢侈的配置。但要注意它和GPU有本質(zhì)區(qū)別。GPU是通用并行計(jì)算架構(gòu)什么都能跑靈活但功耗大Atlas 300V是專用推理架構(gòu)只能跑CANN生態(tài)里的模型格式好處是能效比高、單位成本低壞處是你得適應(yīng)它的工具鏈。很多從GPU平臺(tái)遷移過(guò)來(lái)的朋友上來(lái)就習(xí)慣性想用PyTorch直接推理這是最大的認(rèn)知誤區(qū)。1.3 300V和300I、300T別買錯(cuò)300V和300I都用310P芯片算力基本一致但300V多了一個(gè)殺手锏——硬件視頻編解碼能力。DVPP硬件單元可以硬解H.264/H.265視頻流直接輸出YUV數(shù)據(jù)給AI處理器做分析全程不占CPU。這一點(diǎn)決定了300V特別適合接攝像頭視頻流做實(shí)時(shí)分析而300I更適合以圖片為輸入的通用推理場(chǎng)景。我做視頻結(jié)構(gòu)化項(xiàng)目的時(shí)候一路1080P視頻流在GPU平臺(tái)上需要額外吃不少CPU去做解碼換上300V之后解碼直接被硬件接管CPU占用肉眼可見(jiàn)地降了下來(lái)。如果你的核心業(yè)務(wù)是讀視頻幀→做檢測(cè)→輸出結(jié)果300V就是那個(gè)專門為你優(yōu)化的答案。至于300T那是面向訓(xùn)練場(chǎng)景的四卡八卡互聯(lián)做分布式訓(xùn)練用的單張插在PCIE槽上跑推理屬于暴殄天物。選型的時(shí)候把訓(xùn)練和推理這兩條線分開(kāi)想基本不會(huì)買錯(cuò)。2. 為什么YOLO部署選Atlas的人越來(lái)越多2.1 視頻流處理是300V的甜點(diǎn)區(qū)YOLO系列模型在安防和工業(yè)質(zhì)檢領(lǐng)域處于絕對(duì)統(tǒng)治地位而這些場(chǎng)景里絕大部分輸入都是視頻流。前端攝像頭不斷產(chǎn)生H.264/H.265碼流傳統(tǒng)做法是拉流后在CPU上解碼成幀再用GPU逐幀推理。這種方式有個(gè)隱性問(wèn)題多路視頻并發(fā)時(shí)CPU解碼會(huì)成為瓶頸解碼速度跟不上推理速度GPU在那里空轉(zhuǎn)等數(shù)據(jù)。Atlas 300V的設(shè)計(jì)思路是直接把解碼和推理放進(jìn)同一張卡里。DVPP硬件解碼出來(lái)的YUV數(shù)據(jù)可以在顯存內(nèi)直接作為AI計(jì)算的輸入不走PCIe回傳省掉了大量數(shù)據(jù)搬移開(kāi)銷。我在實(shí)際測(cè)試中單卡接8路1080P視頻流做YOLOv5s實(shí)時(shí)檢測(cè)CPU占用率能控制在10%以內(nèi)這是GPU方案很難做到的。2.2 能效比和單路成本優(yōu)勢(shì)明顯數(shù)據(jù)中心和機(jī)房對(duì)功耗有硬性指標(biāo)。一張GPU推理卡動(dòng)輒兩三百瓦配套的散熱、電源、機(jī)柜空間都得跟著升級(jí)。Atlas 300V的最大功耗大概在72W左右一張GPU的功耗能供電給三四張300V單路視頻流的硬件成本攤薄下來(lái)很有吸引力。還有個(gè)容易被忽略的點(diǎn)AI推理芯片的TCO不僅看硬件采購(gòu)價(jià)還要看TDP和部署密度。同樣的4U機(jī)箱裝GPU可能只能塞4張卡裝300V這種低功耗卡可以塞滿整體算力密度翻倍。對(duì)于做安防平臺(tái)或者智慧園區(qū)的集成商來(lái)說(shuō)這個(gè)賬很好算。2.3 從GPU遷移到Ascend要面對(duì)的現(xiàn)實(shí)既然有這么多優(yōu)勢(shì)為啥大家還是習(xí)慣用GPU因?yàn)檫w移成本是真實(shí)的。CUDA生態(tài)成熟到近乎無(wú)腦PyTorch寫完了直接跑昇騰這邊你要面對(duì)的是ONNX導(dǎo)出、ATC模型轉(zhuǎn)換、AscendCL接口調(diào)用、算子兼容性排查每一步都可能出問(wèn)題。所以理性看待這件事很重要。如果你的業(yè)務(wù)是快速原型驗(yàn)證、模型頻繁迭代、算法團(tuán)隊(duì)沒(méi)有專門做部署優(yōu)化的人GPU依然是最省心的選擇。但如果你的業(yè)務(wù)是相對(duì)固定的推理負(fù)載比如就那幾個(gè)YOLO模型版本場(chǎng)景明確、并發(fā)量大、對(duì)功耗和成本敏感那花一兩周時(shí)間把CANN這套工具鏈吃透長(zhǎng)期回報(bào)非常可觀。我自己的判斷標(biāo)準(zhǔn)是單模型持續(xù)運(yùn)行時(shí)長(zhǎng)超過(guò)三個(gè)月就值得遷移到Atlas。3. 部署第一步環(huán)境準(zhǔn)備與工具鏈安裝3.1 硬件連接與固件驅(qū)動(dòng)確認(rèn)先說(shuō)硬件安裝。Atlas 300V是標(biāo)準(zhǔn)PCIe全高卡外形尺寸和GPU差不多插到服務(wù)器的PCIe x16槽位上即可。需要注意供電我用的服務(wù)器是雙電源冗余配置單卡功耗雖然低但多卡滿載時(shí)還是建議確認(rèn)電源余量充足。裝好卡之后第一件事是確認(rèn)系統(tǒng)能識(shí)別到設(shè)備。在Ubuntu服務(wù)器上執(zhí)行l(wèi)spci | grep -i ascend npu-smi infonpu-smi是昇騰的設(shè)備管理工具類似于NVIDIA的nvidia-smi能看到芯片溫度、功耗、顯存占用、算力利用率。我當(dāng)時(shí)新卡插上去執(zhí)行npu-smi info報(bào)了Driver not initialized不用慌說(shuō)明驅(qū)動(dòng)還沒(méi)裝。驅(qū)動(dòng)和固件的安裝包在昇騰社區(qū)下載中心記得要匹配操作系統(tǒng)的內(nèi)核版本。3.2 CANN工具鏈怎么裝才不踩坑CANN是昇騰的計(jì)算架構(gòu)相當(dāng)于CUDA在GPU生態(tài)里的位置。必須裝沒(méi)有它什么模型都跑不起來(lái)。安裝的核心邏輯是先驅(qū)動(dòng)后固件再CANN工具包順序不能亂。我建議用root權(quán)限裝完所有基礎(chǔ)依賴后再切換到普通用戶跑推理避免各種權(quán)限引發(fā)的玄學(xué)問(wèn)題。安裝命令大致如下# 安裝驅(qū)動(dòng)注意包名要與內(nèi)核版本匹配 ./Ascend-hdk-310p-npu-driver_xxx_linux-aarch64.run --full # 安裝固件 ./Ascend-hdk-310p-npu-firmware_xxx.run --full # 安裝CANN toolkit ./Ascend-cann-toolkit_xxx_linux-aarch64.run --install安裝完成后配置環(huán)境變量把以下內(nèi)容加到~/.bashrcsource /usr/local/Ascend/ascend-toolkit/set_env.sh source /usr/local/Ascend/driver/tools/version.info然后重新執(zhí)行npu-smi info能看到卡的狀態(tài)變成OK芯片溫度、顯存總?cè)萘?4G這些都正常顯示環(huán)境就算通了。3.3 模型文件的翻譯思路Atlas只能跑.om格式的離線模型而我們訓(xùn)練出來(lái)的PyTorch模型是.pt或.onnx格式。這就需要一個(gè)翻譯官把通用模型轉(zhuǎn)成昇騰能認(rèn)的格式這個(gè)工具叫ATCAscend Tensor Compiler。轉(zhuǎn)換邏輯是.pt→.onnx→.om。為什么中間要過(guò)一道ONNX因?yàn)镻yTorch模型格式跟昇騰芯片綁定的計(jì)算圖規(guī)范差得太遠(yuǎn)ONNX作為一個(gè)開(kāi)放的中間表示是生態(tài)之間最通用的橋梁。這一步在GPU平臺(tái)上完全不需要但在昇騰上它是必經(jīng)之路。理解了這個(gè)鏈路后面每一步出錯(cuò)你都知道問(wèn)題出在哪個(gè)環(huán)節(jié)。4. 實(shí)操YOLOv5在Atlas 300V上的完整部署4.1 從PyTorch導(dǎo)出干凈的ONNX模型我用的是YOLOv5 v6.0版本的官方權(quán)重這個(gè)版本在工業(yè)界用得最多、資料也最全。導(dǎo)出ONNX這一步最容易埋雷很多人后面轉(zhuǎn)換失敗都是因?yàn)檫@里沒(méi)處理好。首先確保模型文件完整然后執(zhí)行導(dǎo)出命令python export.py --weights yolov5s.pt --include onnx --opset 11 --batch-size 1這里有兩個(gè)關(guān)鍵參數(shù)要解釋。--opset 11是ONNX算子集版本昇騰的ATC工具對(duì)opset 11的支持最成熟用太新的版本容易遇到算子不兼容--batch-size 1是固定batch為1如果后面要做動(dòng)態(tài)batch這里可以先固定1等基礎(chǔ)流程跑通再優(yōu)化。導(dǎo)出后用onnxsim做一次圖優(yōu)化把冗余節(jié)點(diǎn)清理掉python -m onnxsim yolov5s.onnx yolov5s_sim.onnx這一步不是必須的但我實(shí)測(cè)做了圖簡(jiǎn)化之后ATC轉(zhuǎn)換的成功率和推理性能都有提升因?yàn)閯h掉了大量無(wú)效的Shape和Identity節(jié)點(diǎn)。4.2 ATC離線轉(zhuǎn)換把ONNX變成OM拿到干凈的ONNX文件后開(kāi)始轉(zhuǎn)換。我用的ATC命令是這樣atc --modelyolov5s_sim.onnx \ --framework5 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --outputyolov5s_bs1 \ --insert_op_confaipp.cfg \ --output_typeFP32 \ --logerror逐個(gè)參數(shù)解釋一下--framework5表示輸入是ONNX格式這個(gè)數(shù)字是固定的別改。--soc_versionAscend310P3對(duì)應(yīng)310P芯片的版本一定要跟你的實(shí)際芯片型號(hào)匹配可以用npu-smi info查看具體型號(hào)后確認(rèn)。我之前在這上面吃過(guò)虧填錯(cuò)版本直接報(bào)E10001: soc version invalid。--input_shape必須跟導(dǎo)出ONNX時(shí)的輸入尺寸一致。YOLOv5默認(rèn)輸入是1,3,640,640即1張3通道640×640的圖。--insert_op_confaipp.cfg是圖像預(yù)處理配置這是昇騰的一大特色。AIPP硬件模塊可以在推理前自動(dòng)完成resize、歸一化、顏色空間轉(zhuǎn)換等于把圖像預(yù)處理從CPU上搬到了硬件上。aipp.cfg的內(nèi)容長(zhǎng)這樣aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 csc_switch: false rbuv_swap_switch: false 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 }這里的0.003921569是1/255也就是把像素從0~255歸一化到0~1。關(guān)鍵是這個(gè)配置里的預(yù)處理要和訓(xùn)練時(shí)保持一致YOLOv5訓(xùn)練時(shí)用到的歸一化就是除以255所以這里配置的歸一化是匹配的。轉(zhuǎn)換成功后會(huì)在當(dāng)前目錄生成yolov5s_bs1.om文件這個(gè)就是能在Atlas 300V上跑的最終模型文件。4.3 Python推理代碼的骨架模型轉(zhuǎn)換好了接下來(lái)就是寫推理程序。昇騰提供了AscendCLACL底層接口類似CUDA Runtime API也提供了更上層的MindX SDK封裝得更徹底。我習(xí)慣先用ACL把底層鏈路打通這樣出了問(wèn)題好排查。核心推理代碼的邏輯很簡(jiǎn)單先初始化設(shè)備再加載模型然后準(zhǔn)備輸入輸出內(nèi)存執(zhí)行推理最后取回結(jié)果import numpy as np from acl import acl # 初始化 ret acl.init() ret acl.rt.set_device(0) context, ret acl.rt.create_context(0) # 加載模型 model_id, ret acl.mdl.load_from_file(yolov5s_bs1.om) model_desc acl.mdl.create_desc() ret acl.mdl.get_desc(model_desc, model_id) # 獲取模型輸入輸出信息 input_size acl.mdl.get_input_size_by_index(model_desc, 0) output_num acl.mdl.get_num_outputs(model_desc) output_size acl.mdl.get_output_size_by_index(model_desc, 0) # 分配設(shè)備內(nèi)存 input_data np.random.randn(1, 3, 640, 640).astype(np.float32) input_buffer, ret acl.rt.malloc(input_size, 2) acl.rt.memcpy(input_buffer, input_size, input_data.tobytes(), input_size, 2) output_buffer, ret acl.rt.malloc(output_size, 2) # 執(zhí)行推理 stream, ret acl.rt.create_stream() ret acl.mdl.execute_async(model_id, [input_buffer], [output_buffer], stream) ret acl.rt.synchronize_stream(stream) # 取回結(jié)果 output np.zeros(output_size, dtypenp.uint8) acl.rt.memcpy(output.tobytes(), output_size, output_buffer, output_size, 3) # 清理資源 acl.rt.free(input_buffer) acl.rt.free(output_buffer) acl.mdl.unload(model_id) acl.rt.destroy_context(context) acl.finalize()這段代碼是最小可用版本實(shí)際項(xiàng)目中你要把輸入數(shù)據(jù)的獲取改成讀視頻幀或讀圖片用cv2.imread讀進(jìn)來(lái)的圖像是HWC格式要先轉(zhuǎn)成CHW再根據(jù)aipp.cfg的配置做resize到640×640然后轉(zhuǎn)成float32。要注意的是如果用了AIPP歸一化輸入到模型的原始數(shù)據(jù)就是0~255的uint8而不是歸一化后的float這個(gè)細(xì)節(jié)搞錯(cuò)了推理結(jié)果會(huì)全亂。4.4 輸出解析從張量到檢測(cè)框推理拿到的那一堆原始輸出不是直接能用的檢測(cè)框。YOLOv5的輸出是一個(gè)1×25200×85的張量25200是三種不同尺度特征圖80×80、40×40、20×20預(yù)測(cè)框的總數(shù)85是4個(gè)坐標(biāo)1個(gè)置信度80個(gè)類別概率。后處理流程包括置信度過(guò)濾、非極大值抑制NMS、坐標(biāo)映射。這部分代碼量不小但邏輯固定。我自己是把Ultralytics官方倉(cāng)庫(kù)里的后處理邏輯移植過(guò)來(lái)改了一下坐標(biāo)縮放因?yàn)锳tlas上做預(yù)處理時(shí)已經(jīng)把圖resize到640了輸出坐標(biāo)要映射回原始圖像尺寸才能畫框。如果你不想從零寫后處理可以看看MindX SDK里自帶的YOLOv5后處理插件或者參考昇騰社區(qū)開(kāi)源的mxVision推理樣例那里面的輸出解析模塊是現(xiàn)成的稍微改改就能用。4.5 性能壓測(cè)與關(guān)鍵參數(shù)調(diào)優(yōu)基礎(chǔ)流程通了之后下一步就是壓性能。我用一段1920×1080的視頻做了測(cè)試記錄推理耗時(shí)和端到端吞吐。先說(shuō)結(jié)論YOLOv5s、640×640輸入、batch1的情況下單卡純推理時(shí)延實(shí)測(cè)在2~5毫秒?yún)^(qū)間加上解碼、縮放、后處理的全流程時(shí)延控制在15毫秒以內(nèi)處理單路1080P視頻做到實(shí)時(shí)25幀以上綽綽有余。如果發(fā)現(xiàn)性能沒(méi)達(dá)到預(yù)期按以下優(yōu)先級(jí)排查調(diào)優(yōu)優(yōu)化項(xiàng)操作方式收益開(kāi)啟AIPP硬件預(yù)處理在ATC轉(zhuǎn)換時(shí)配置aipp.cfg釋放CPU降低端到端時(shí)延使用動(dòng)態(tài)batch--dynamic_batch_size1,2,4多路請(qǐng)求合并推理提升吞吐多Stream并行AC L里創(chuàng)建多個(gè)stream并發(fā)推理充分利用多核AI Core減少CPU拷貝輸入數(shù)據(jù)盡量直接在Device側(cè)準(zhǔn)備減少PCIe傳輸開(kāi)銷模型低精度量化使用INT8量化后的OM模型推理速度成倍提升我最推薦的還是模型量化。昇騰對(duì)INT8的支持很成熟YOLOv5s量化成INT8之后在保證mAP損失可控通常下降不到1%的前提下推理速度能再翻一倍。量化工具在CANN自帶用amct_onnx工具先做校準(zhǔn)數(shù)據(jù)集的統(tǒng)計(jì)再重新走一遍ATC轉(zhuǎn)換鏈路清晰。5. 部署中踩過(guò)的坑一次說(shuō)完5.1 常見(jiàn)錯(cuò)誤速查表這一路部署下來(lái)我整理了一份高頻問(wèn)題對(duì)照表遇到報(bào)錯(cuò)直接對(duì)著查報(bào)錯(cuò)信息或現(xiàn)象根因解決辦法E10001: soc version invalidATC的--soc_version填錯(cuò)npu-smi info查看芯片型號(hào)后修改Driver not initialized驅(qū)動(dòng)沒(méi)裝好或內(nèi)核模塊沖突重新安裝驅(qū)動(dòng)確認(rèn)內(nèi)核版本匹配model not exist or occupy failed顯存不足或模型路徑錯(cuò)誤確認(rèn)24G顯存剩余檢查文件權(quán)限推理輸出全是0AIPP歸一化與模型輸入不符核對(duì)是否重復(fù)歸一化檢查輸入數(shù)據(jù)格式轉(zhuǎn)換時(shí)報(bào)op not supportONNX算子不被ATC支持檢查opset版本用onnxsim簡(jiǎn)化圖多路視頻CPU占用高沒(méi)用DVPP硬解碼在CPU上軟解改用MindX SDK的VideoDecoder模塊推理結(jié)果框的位置偏移后處理坐標(biāo)沒(méi)映射回原圖尺寸用縮放比例還原坐標(biāo)最陰間的要算推理輸出全是0這個(gè)問(wèn)題表面上看模型加載成功、推理執(zhí)行成功但結(jié)果就是不對(duì)。我排查了兩天才發(fā)現(xiàn)是輸入數(shù)據(jù)的數(shù)值范圍問(wèn)題——AIPP里已經(jīng)配置了除以255的歸一化我還在代碼里手動(dòng)做了一遍歸一化等于歸一化了兩次數(shù)據(jù)被壓到了接近0模型自然什么都識(shí)別不出來(lái)。5.2 一些值得記住的實(shí)操心得關(guān)于顯存管理我發(fā)現(xiàn)分配Device內(nèi)存時(shí)最好用acl.rt.malloc而不是依賴框架自動(dòng)管理雖然底層代碼會(huì)多幾行但長(zhǎng)時(shí)間運(yùn)行不會(huì)出現(xiàn)內(nèi)存碎片越積越多的問(wèn)題。有一次我的程序跑了三天三夜之后突然報(bào)顯存不夠重啟進(jìn)程又好了后來(lái)定位到是反復(fù)創(chuàng)建銷毀Context導(dǎo)致的設(shè)備內(nèi)存泄漏。CANN這套接口和CUDA一樣資源用完必須手動(dòng)釋放這個(gè)習(xí)慣要養(yǎng)成。關(guān)于多模型部署24G大顯存有個(gè)特別實(shí)用的玩法把YOLOv5檢測(cè)模型、一個(gè)ReID模型、一個(gè)人臉特征提取模型同時(shí)加載到一個(gè)Context里用同一路視頻流做級(jí)聯(lián)推理。這樣一張卡就頂一個(gè)多模型流水線極大簡(jiǎn)化了系統(tǒng)架構(gòu)。我實(shí)測(cè)同時(shí)加載三個(gè)模型只占了大概8G顯存還很寬裕。關(guān)于調(diào)試手段CANN提供了msprof性能分析工具能導(dǎo)出算子級(jí)的時(shí)間消耗分析瓶頸非常有用。我第一次用的時(shí)候發(fā)現(xiàn)圖像縮放算子占了很大比例后來(lái)把縮放從CPU手寫改到AIPP硬件處理性能立刻上了一個(gè)臺(tái)階。遇到性能問(wèn)題別瞎猜拿profiling數(shù)據(jù)說(shuō)話這是最有效率的排查方式。6. 結(jié)個(gè)尾說(shuō)點(diǎn)實(shí)在的Atlas 300V 24G是一塊被低估的推理加速卡。它確實(shí)是運(yùn)算加速卡而且是專門為視頻分析場(chǎng)景優(yōu)化過(guò)的運(yùn)算加速卡配合YOLO系列模型在安防、交通、工業(yè)質(zhì)檢這些需要大規(guī)模處理視頻流的業(yè)務(wù)里能效比優(yōu)勢(shì)非常明顯。心理預(yù)期要放對(duì)它不是CUDA的平替是一套獨(dú)立的推理生態(tài)一旦把CANN的工具鏈跑通了這套東西的穩(wěn)定性和性價(jià)比都能超出預(yù)期。最后分享一個(gè)我個(gè)人的習(xí)慣做昇騰項(xiàng)目部署永遠(yuǎn)先跑通最小的端到端鏈路——一張圖進(jìn)去、一個(gè)檢測(cè)框出來(lái)再想并行優(yōu)化、多路接入的事。每次試錯(cuò)就改一個(gè)變量不要同時(shí)動(dòng)模型版本、ATC參數(shù)和推理代碼。我見(jiàn)過(guò)太多同事一次性改了七八個(gè)地方出了錯(cuò)根本定位不了是哪一步的問(wèn)題。耐住性子一步步驗(yàn)證Atlas這套東西其實(shí)比想象中要老實(shí)得多。