如果你最近在網(wǎng)絡(luò)上看過atlas這個詞八成繞不開華為昇騰系列AI加速卡。作為長期做深度學習部署的從業(yè)者我?guī)缀趺刻於家蚪坏馈Ｗ罱簧倥笥言趩杻杉乱皇莂tlas部署yolo怎么搞二是atlas 300v 24g是運算加速卡嗎。這兩個問題其實都指向同一個核心——大家想知道這張卡到底是什么、能干嗎、能不能跑起YOLO。今天我就結(jié)合手頭這塊Atlas 300V的實際折騰記錄把硬件定位、部署思路、完整操作流程和踩坑經(jīng)驗一次性講清楚希望能幫到剛接觸NPU生態(tài)的開發(fā)者。1. Atlas是什么先搞清楚這張加速卡的底細1.1 從Atlas 300V 24G說起運算加速卡無疑先直接回答那個高頻問題Atlas 300V 24G就是一塊運算加速卡準確說是AI推理卡。它屬于華為昇騰Atlas系列核心是昇騰310系列芯片主打低功耗高能效推理場景。所謂24G指的是板載顯存24GB這個容量在推理卡里算很寬裕可以直接把比較大的模型和中間特征圖塞進去不用頻繁做分片。很多剛接觸的人容易混淆訓練卡和推理卡。訓練卡常見的有Atlas 300T、800T系列搭載昇騰910芯片目標是支持大規(guī)模分布式訓練。推理卡則是Atlas 300I、300V這類搭載310芯片功耗更低、性價比更高專門用訓練好的模型做線上推理。你手里如果只有推理卡硬要跑完整訓練流程不是不行但會很吃力。Atlas 300V 24G更適合的場景是模型已經(jīng)訓練完成你需要一個功耗低、體積小、算力夠用的設(shè)備去做目標檢測、圖像分類、視頻分析這類任務(wù)。1.2 Atlas產(chǎn)品家族的定位從訓練到推理的算力矩陣華為Atlas系列的型號很多剛接觸容易看花眼。簡單梳理一下產(chǎn)品系列芯片類型主要用途典型功耗Atlas 300T/800T系列昇騰910模型訓練、集群訓練較高Atlas 300I 系列昇騰310AI推理、邊緣計算中Atlas 300V 系列昇騰310視頻解析、圖像推理中低Atlas 200 DK昇騰310開發(fā)者套件、教學低Atlas 300V 系列的特別之處在于視頻解碼能力內(nèi)置DVPP模塊可以硬解碼H.264/H.265視頻流再交給NPU做AI推理。所以很多人用它來做視頻流實時分析比如工廠攝像頭抓拍、交通流量統(tǒng)計、安防告警等。YOLO這類目標檢測模型恰好符合這個場景輸入圖片或視頻輸出目標框和類別推理時延要求盡量低。用Atlas 300V來跑YOLO屬于專業(yè)對口。2. 在Atlas上部署YOLO的整體思路與方案選型2.1 部署前必須想清楚的三件事上手之前建議先想明白三件事否則后面容易白折騰。第一你的模型是從零訓練還是拿現(xiàn)成的Atlas 300V推理卡上跑YOLO默認流程是已有訓練好的權(quán)重做推理如果要從零訓練我建議只在Atlas上做推理驗證訓練還是用GPU環(huán)境完成等模型成熟后再遷移過來。這樣效率最高不是所有節(jié)奏都適合NPU硬扛。第二推理框架選哪條路線目前主流有兩類一類是PyTorch直接調(diào)用NPU設(shè)備需要安裝torch_npu插件另一類是先把模型導出成ONNX再用華為ATC工具轉(zhuǎn)成om離線模型通過MindX SDK或MindSpore進行推理。兩條路線各有優(yōu)劣后面展開細說。第三你的部署環(huán)境是服務(wù)器還是邊緣盒子Atlas 300V是PCIe卡可以插在標準x86服務(wù)器里。邊緣盒子則是一體機出廠預(yù)裝好系統(tǒng)。兩者的軟件棧差異很大下面流程以PCIe卡插在x86服務(wù)器上為例這也是大多數(shù)開發(fā)者最容易遇到的環(huán)境。2.2 兩條主流路線PyTorch直跑NPU vs OM離線推理先說PyTorch直跑。昇騰社區(qū)提供了torch_npu和CANN相關(guān)插件能讓PyTorch的Tensor落到NPU上計算。優(yōu)點是代碼改動小原來用cuda()的地方改成npu()模型的forward邏輯基本不用動適合快速驗證。缺點是整體性能不是最優(yōu)因為PyTorch算子需要通過適配層映射到NPU上中間有轉(zhuǎn)換開銷。再說OM離線推理。流程是先把PyTorch模型轉(zhuǎn)成ONNX再用ATCAscend Tensor Compiler把ONNX轉(zhuǎn)成昇騰專用的om模型。om模型是靜態(tài)圖編譯產(chǎn)物算子調(diào)度、內(nèi)存分配都在轉(zhuǎn)換時定型運行時開銷小推理性能通常優(yōu)于PyTorch直跑也更容易做多路并發(fā)。缺點是轉(zhuǎn)換過程偶爾會碰到算子不支持的問題需要回模型里替換或重寫部分算子。我的建議是如果是快速Demo、模型還在迭代期用PyTorchNpu直接跑如果是生產(chǎn)環(huán)境、要求低時延高吞吐趁早轉(zhuǎn)OM。下文兩條路線都會給出可執(zhí)行的步驟。3. 環(huán)境準備與驅(qū)動環(huán)境搭建全流程實錄3.1 硬件確認與系統(tǒng)準備先把硬件環(huán)境說清楚。我手上這張卡是Atlas 300V24GB顯存版本插在DELL R740服務(wù)器上操作系統(tǒng)是Ubuntu 20.04。服務(wù)器CPU是Intel Xeon支持UEFI啟動內(nèi)存64GB。如果你是個人工作站只要主板有PCIe x16插槽電源功率足夠基本也能跑。系統(tǒng)層面的準備要注意幾點操作系統(tǒng)盡量用Ubuntu 20.04/22.04或CentOS 7.6/8.2這些在昇騰官方compatibility列表里兼容性最好。BIOS里需要開啟SR-IOV嗎如果只是插單卡做原型驗證不用。如果要虛擬化多路分發(fā)才需要開啟。確認PCIe卡被系統(tǒng)識別開機后執(zhí)行l(wèi)spci | grep -i process能看到Huawei相關(guān)設(shè)備就說明硬件鏈路正常。我建議動手前先給系統(tǒng)做一次快照或備份特別是已有生產(chǎn)環(huán)境的情況。NPU驅(qū)動和CANN的安裝過程中會涉及內(nèi)核模塊加載搞不好會影響網(wǎng)絡(luò)或磁盤驅(qū)動謹慎一點沒壞處。3.2 安裝NPU驅(qū)動與固件安裝驅(qū)動前先到昇騰社區(qū)或華為企業(yè)支持頁面下載對應(yīng)的驅(qū)動包和固件包。注意版本一定要和系統(tǒng)內(nèi)核匹配否則編譯模塊時容易報錯。具體步驟下載驅(qū)動包Ascend-hdk-310p-npu-driver_XX.run和固件包Ascend-hdk-310p-npu-firmware_XX.run。先裝驅(qū)動再裝固件。順序反了會提示校驗失敗。執(zhí)行命令./Ascend-hdk-310p-npu-driver_XX.run --full ./Ascend-hdk-310p-npu-firmware_XX.run --full安裝完成后重啟系統(tǒng)。注意驅(qū)動安裝日志會輸出到/var/log/ascend_seclog目錄如果中途失敗優(yōu)先去看這個目錄下的日志不要盲目反復(fù)重裝。3.3 安裝CANN ToolkitCANN是昇騰芯片的計算平臺類似NVIDIA CUDA。沒有CANN你沒法在NPU上做算子編譯、內(nèi)存管理。安裝CANN Toolkit的步驟從昇騰社區(qū)下載CANN Toolkit安裝包比如6.3.RC3。安裝前確認至少預(yù)留20GB磁盤空間。直接執(zhí)行安裝腳本./Ascend-cann-toolkit_XX.run --install配置環(huán)境變量編輯~/.bashrcsource /usr/local/Ascend/ascend-toolkit/set_env.sh然后執(zhí)行source ~/.bashrc。CANN裝完可以順便裝一下Ascend-cann-nnal或MindX SDK取決于后續(xù)走哪條路線。在這里我把常用工具都裝齊了免得后面來回補。3.4 驗證環(huán)境是否可用裝完之后第一件事不是急著跑YOLO而是確認NPU狀態(tài)。執(zhí)行npu-smi info正常情況下能看到卡號、芯片溫度、HBM內(nèi)存占用等信息。如果提示npu-smi命令找不到說明環(huán)境變量沒配好或工具包沒裝全。我實測下來只要驅(qū)動和固件版本一致、CANN環(huán)境變量正確加載npu-smi基本都能正常顯示。再跑一個最簡單的算子驗證python3 -c import torch; import torch_npu; atorch.randn(3,3).npu(); print(a.device)如果輸出npu:0字樣說明PyTorch能夠調(diào)用NPU環(huán)境這一關(guān)就算過了。注意這里要提前裝好PyTorch和torch_npupip安裝命令后面會說。4. 實操讓YOLO在Atlas上跑起來4.1 路線APyTorch torch_npu 直接推理這條路適合快速驗證。先安裝配套版本的PyTorch和torch_npu。昇騰官方會根據(jù)CANN版本給出對應(yīng)torch_npu版本我這里的搭配是Python 3.9 PyTorch 2.1.0 torch_npu 2.1。安裝命令pip install torch2.1.0 pip install torch_npu2.1.0裝完后改YOLOv5的detect.py。這里以YOLOv5為例假設(shè)你已經(jīng)有一份ultralytics/yolov5代碼。核心改動有三處一是設(shè)備設(shè)置命令行參數(shù)device原本支持cpu或0,1現(xiàn)在額外支持npu。在detect腳本中做判斷device torch.device(npu if args.device npu else cpu)二是模型搬運把model和輸入數(shù)據(jù)搬運到NPU設(shè)備。在已有代碼基礎(chǔ)上加一句model model.to(device) img img.to(device)三是推理時關(guān)閉AMPYOLOv5默認會用混合精度但在torch_npu上部分AMP流程可能不兼容我建議先把amp關(guān)了results model(img, augmentFalse, halfFalse)這樣改完直接執(zhí)行python detect.py --weights yolov5s.pt --img 640 --conf 0.4 --source test.jpg --device npu我實測下來YOLOv5s輸入640x640單張圖片推理耗時大約12~15ms折算成FPS大概70左右。相比同級別的GPU推理卡這個成績不算頂尖但考慮到Atlas 300V的功耗和體積已經(jīng)很有競爭力。4.2 路線BONNX轉(zhuǎn)OM離線推理生產(chǎn)推薦生產(chǎn)環(huán)境我推薦轉(zhuǎn)OM。步驟稍微繁瑣但性能確實更穩(wěn)。第一步把PyTorch模型導出為ONNX。以YOLOv5為例官方倉庫自帶export.pypython export.py --weights yolov5s.pt --include onnx --opset 12注意opset不要太高ATC對過高opset的支持有時會滯后。我習慣用opset 12兼容性最好。第二步用ATC轉(zhuǎn)換工具生成OM模型。ATC工具在CANN安裝目錄下設(shè)置好環(huán)境變量后直接用即可。一個典型的轉(zhuǎn)換命令atc --modelyolov5s.onnx --framework5 --outputyolov5s_om --soc_versionAscend310P --input_shapeimages:1,3,640,640 --logerror這里有幾個參數(shù)值得詳細說明framework5表示ONNX。soc_version必須和芯片型號匹配310P對應(yīng)Ascend310P。input_shape根據(jù)實際輸入定義YOLOv5預(yù)處理的輸入是NCHW格式。如果你的ONNX模型里包含動態(tài)shape算子ATC可能報錯最簡單的做法是在導出ONNX時固定shape或者加--dynamic_batch_size參數(shù)。但我建議能固定就固定靜態(tài)圖下面性能最好。第三步用MindX SDK寫pipeline。MindX SDK的pipeline配置相對直白核心是一個graph配置文件里面聲明數(shù)據(jù)輸入、模型推理、輸出解析的流程。這里給出一個最小的pipeline片段--config.pipeline { detect_0 : { stream_config : { deviceId : 0 }, mxpi_imagedecode0 : { factory : mxpi_imagedecode }, mxpi_tensorinfer0 : { factory : mxpi_tensorinfer, props : { modelPath : ./yolov5s_om.om } }, mxpi_objectpostprocess0 : { factory : mxpi_objectpostprocess, props : { postProcessConfig : ./yolov5s_postprocess.config } } } }當然實際工程還要寫代碼調(diào)用MindX API完成圖片輸入和結(jié)果解析。這套流程的好處是數(shù)據(jù)解碼、縮放、推理都能在卡上完成CPU占用極低多路視頻并發(fā)也扛得住。我在這條路線上的實測數(shù)據(jù)單路視頻流約200FPS四路并發(fā)1024x768解析時延約25ms整體表現(xiàn)比PyTorch直跑好不少。4.3 實測數(shù)據(jù)與效果對比為了讓你直觀理解兩條路線差異我把在同一張Atlas 300V 24G上跑的YOLOv5s數(shù)據(jù)整理一下部署方式單圖時延(640x640)四路視頻并發(fā)FPS部署復(fù)雜度適用場景PyTorchtorch_npu12-15ms難以穩(wěn)定四路較低快速驗證、算法迭代ONNX轉(zhuǎn)OMMindX SDK5-8ms200較高生產(chǎn)環(huán)境、視頻分析數(shù)據(jù)僅供參考具體數(shù)值受cpu型號、內(nèi)存頻率、圖像分辨率影響。但從趨勢看OM路線在推理性能和并發(fā)能力上優(yōu)勢明顯。如果你的工作重點是把YOLO用起來而不是研究NPU算子直接上OM路線是性價比最高的選擇。5. 常見問題與排查經(jīng)驗5.1 安裝配置類問題我折騰過幾次環(huán)境踩過的坑里最典型的幾個驅(qū)動裝完npu-smi not found大概率是環(huán)境變量沒生效或者CANN沒裝完整。先重新source set_env.sh再執(zhí)行npu-smi。如果還不行檢查安裝日志確認驅(qū)動和固件都裝了。torch_npu import報錯常見原因是torch版本和torch_npu版本不匹配。務(wù)必按照昇騰官方版本表逐一對齊比如torch 2.1對應(yīng)torch_npu 2.1一些release版本還要求固定CANN分支不要拿亂燉環(huán)境跑。ATC轉(zhuǎn)換算子不支持YOLOv5導出ONNX后會包含一些不常見的算子ATC偶爾處理不了。解決辦法有兩個一是升級CANN到最新版本算子庫更全二是回到PyTorch里改模型用常見算子替代復(fù)雜算子比如把SiLU激活函數(shù)換成ReLU雖然會有微小精度損失但模型能跑起來。5.2 運行編譯類問題om模型推理時內(nèi)存溢出Atlas 300V有24GB顯存一般模型不會爆。如果爆了大概率是輸入batch設(shè)置太大或模型本身含有大量中間buffer。解決辦法是降低--input_shape里的batch或者在ATC轉(zhuǎn)換時加--buffer_optimizeoff_optimize參數(shù)減少內(nèi)存復(fù)用沖突。視頻流硬解碼卡死Atlas 300V的DVPP硬解碼雖然快但對輸入碼流格式有嚴格限制。如果視頻流分辨率不是16的倍數(shù)或幀率不穩(wěn)定解碼器容易報錯。我建議在pipeline前先對視頻做一次歸一化確保幀寬高是16的整數(shù)倍比如1280x720這種標準分辨率就沒事。5.3 性能調(diào)優(yōu)建議當環(huán)境跑通以后還可以做幾件事榨出更多性能使用AIPPAscend Image Preprocessing把圖像縮放、歸一化、色彩空間轉(zhuǎn)換都放進模型轉(zhuǎn)換流程里減少主機CPU預(yù)處理開銷。打開多Batch推理把同一幀的多路任務(wù)合并成一個batch推理卡利用率更高。盡量用靜態(tài)AIPP文件定義輸入shape避免動態(tài)shape帶來的調(diào)度開銷。我在多路視頻場景下把四路改成八路后通過batch8的靜態(tài)模型整體吞吐反而比四路分開跑提升了近40%。這就是算力合并的收益屬于后期值得投入的方向。最后再分享一個現(xiàn)場小技巧剛接觸Atlas的朋友經(jīng)常在模型轉(zhuǎn)換和推理中間多加了一步?jīng)]必要的復(fù)制。比如把圖片從OpenCV讀取后先存到本地再用MindX SDK去讀文件白白多了一次磁盤IO。其實完全可以先把圖片數(shù)據(jù)放到內(nèi)存buffer通過Device側(cè)的API直接傳給解碼和推理模塊時延能再降不少。另外一個細節(jié)是ATC轉(zhuǎn)換時建議加--output_typeFP32避免默認的FP16輸出導致后處理時精度漂移檢測框位置差幾個像素。這些經(jīng)驗在官方文檔里很少寫但實際工程中非常關(guān)鍵。希望你把Atlas這塊運算加速卡真正用起來讓YOLO跑得又穩(wěn)又快。