實話說這兩年陸陸續(xù)續(xù)有不少朋友問我Atlas 300V到底能不能跑YOLO是不是插上就能當顯卡用甚至還有人一上來就問24GB版本是不是比12GB的算力翻倍。這些問題的背后其實是對昇騰推理卡產(chǎn)品定位的普遍誤解。我最早接觸Atlas的時候也踩過類似的坑一度把它當成普通GPU對待結(jié)果發(fā)現(xiàn)從驅(qū)動到模型轉(zhuǎn)換再到代碼編寫整個工作流跟CUDA生態(tài)完全是兩套邏輯。寫這篇文章的初衷很簡單把我在Atlas 300V上部署YOLO系列模型包括YOLOv5、YOLOv8的完整過程、遇到的各種坑、以及最終穩(wěn)定運行的配置方案整理成一份可以直接上手的參考。無論你是剛拿到卡準備做目標檢測驗證還是已經(jīng)在遷移過程中被各種報錯卡住了這篇文章都值得你花十分鐘讀完。1. Atlas 300V到底是一張什么樣的卡——先搞清楚定位再動手1.1 它和GPU的本質(zhì)區(qū)別一張推理專用NPU卡很多人見到Atlas 300V的第一反應(yīng)是這不是一張顯卡嗎。表面上看它確實長得像顯卡插在服務(wù)器PCIe插槽上有散熱鰭片甚至有些型號還帶主動風扇。但它內(nèi)部的核心并不是GPU圖形處理器而是NPU神經(jīng)網(wǎng)絡(luò)處理單元更具體地說是基于昇騰AI處理器的專用推理芯片。這個區(qū)別不是換個名字那么簡單它決定了你的整個技術(shù)棧選型方向。GPU做的是通用并行計算CUDA生態(tài)里有大量現(xiàn)成的庫可以調(diào)用PyTorch、TensorFlow開箱即跑。而Atlas 300V上的NPU是面向AI推理場景定制的它不支持CUDA官方支持的是CANNCompute Architecture for Neural Networks這套異構(gòu)計算架構(gòu)。用一句直白的話來總結(jié)GPU是一把瑞士軍刀什么活都能干。NotePad是專用的裁紙刀剪裁推理效率極高但你別指望拿它來起瓶蓋。Atlas 300V就是后者它把算力高度聚焦在卷積、矩陣乘加這類AI算子上面在YOLO模型的推理場景下單位功耗的算力表現(xiàn)相當出色。1.2 24GB到底指的是什么——顯存還是內(nèi)存這個問題的出現(xiàn)頻率高得離譜也是我覺得有必要單獨拎出來講清楚的原因。Atlas 300V 24G里的24GB嚴格來說指的是板載存儲容量——可以理解為NPU自帶的高速緩沖區(qū)規(guī)格為24GBPro版也有同樣容量。它跟NVIDIA顯卡上的24GB顯存在設(shè)計語義上有微妙的區(qū)別但在使用效果上你可以暫時把它當作NPU上的顯存來理解因為模型跑起來之后權(quán)重、中間特征圖都是放在這塊存儲里的。型號方面Atlas 300V有標準版和Pro版后面也有人叫V Pro存儲容量分別有12GB和24GB兩種配置。我實測下來24GB版本跑YOLOv5s的batch size 8相當輕松跑YOLOv8m也沒什么壓力。如果是那種剛?cè)腴T的開發(fā)者拿它來跑一些輕量級模型12GB其實也夠用。注意24GB說的是存儲容量不是算力翻倍。容量大只能說明你能裝下更大的模型、跑更大的batch跟推理速度沒有直接關(guān)系。實際吞吐量還取決于NPU的頻率、內(nèi)存帶寬以及你的預(yù)處理管線的效率。1.3 產(chǎn)品矩陣里的定位Atlas 300V vs 300I vs 300I Pro昇騰推理卡這邊主要幾個型號很多人分不清。簡單理一下Atlas 200/300系列面向邊緣和推理場景的低功耗產(chǎn)品Atlas 300V定位是視頻圖像分析、目標檢測這類視覺推理任務(wù)24GB版本適合中大規(guī)模并發(fā)場景Atlas 300I系列更偏通用AI推理硬件架構(gòu)上跟300V有些差異對我實際部署YOLO來說300V和300I的差別主要體現(xiàn)在支持的格式、特定算子的性能表現(xiàn)上但整體開發(fā)流程完全一致——都是Host側(cè)CPU Device側(cè)NPU的異構(gòu)架構(gòu)都是用CANN工具鏈做模型轉(zhuǎn)換和推理調(diào)用。所以本文后面的大部分內(nèi)容在300I系列上同樣適用。2. 部署YOLO前的第一道坎CANN工具鏈的安裝與環(huán)境配套2.1 一個容易被忽視的事實Atlas不是插上就能用的拿到Atlas 300V之后如果你試圖在系統(tǒng)里像裝NVIDIA驅(qū)動一樣裝個東西就完事那是不現(xiàn)實的。Atlas有嚴格的軟件棧分層從上到下依次是應(yīng)用層你自己的推理代碼可以是PythonPycACL、CAscendCL接口也可以是基于MindX SDK的流程式開發(fā)CANN層核心的算子庫、圖編譯引擎、運行時的總稱類比CUDA Toolkit驅(qū)動和固件層管理NPU設(shè)備、內(nèi)存、通信的底層驅(qū)動類比NVIDIA Driver這三個部分必須搭配合理版本之間不能隨意混用。我第一次部署的時候就是驅(qū)動和CANN版本不匹配導(dǎo)致NPU設(shè)備無法初始化npu-smi info能看到卡但一調(diào)用就報錯。2.2 實操安裝過程與版本配套的一個穩(wěn)妥組合以下是我多次驗證、目前跑得最穩(wěn)的一套組合直接寫在這里供參考操作系統(tǒng)Ubuntu 20.04/22.04 LTS x86_64驅(qū)動固件隨CANN配套發(fā)布的驅(qū)動包在昇騰社區(qū)下載對應(yīng)版本CANN版本CANN 6.3.RC2或更新版本注意區(qū)分商用版和社區(qū)版Python版本3.8~3.10PyTorch1.11.0或2.x版本轉(zhuǎn)ONNX用實際推理不依賴PyTorch安裝步驟大致如下# 1. 以root用戶登錄安裝驅(qū)動和固件 ./Ascend-hdk-*.run --full # 2. 安裝CANN toolkit ./Ascend-cann-toolkit_*-linux-x86_64.run --install # 3. 安裝CANN kernels包算子包 ./Ascend-cann-kernels-*.run --install # 4. 設(shè)置環(huán)境變量 source /usr/local/Ascend/ascend-toolkit/set_env.sh裝完用npu-smi info檢查npu-smi info如果能看到類似下面這樣輸出說明驅(qū)動和固件正常------------------------------------------------------------------------------------------ | NPU Name | Health | Power(W) Temp(C) Hugepages-Usage(page) | | Chip Device | Bus-Id | AICore(%) Memory-Usage(MB) | | 0 300V | OK | 18.8 48 0 / 0 | | 0 0 | 0000:C1:00.0 | 0 0 / 24576 | ------------------------------------------------------------------------------------------看到OK狀態(tài)和Memory-Usage正常顯示就可以進入下一步了。2.3 環(huán)境準備階段最容易翻車的三個細節(jié)第一個細節(jié)是內(nèi)核版本與驅(qū)動兼容性。Atlas驅(qū)動對Linux內(nèi)核版本有嚴格的校驗裝驅(qū)動時如果報header相關(guān)錯誤通常是內(nèi)核頭文件沒有安裝執(zhí)行apt-get install linux-headers-$(uname -r)后再重試。第二個是python依賴沖突。CANN自帶的某些組件比如atc工具依賴特定的protobuf版本如果你在系統(tǒng)里已經(jīng)裝了TensorFlow或Torch很有可能出現(xiàn)protobuf版本沖突。我的建議是用venv或conda單獨建一個干凈環(huán)境來跑CANN相關(guān)的東西跟日常開發(fā)環(huán)境隔離。第三個是set_env.sh一定要在每次新的終端會話里source。這個環(huán)境變量設(shè)置的不只是PATH還包括CANN運行時需要的LD_LIBRARY_PATH和ASCEND_OPP_PATH這些關(guān)鍵變量。漏source了后面跑atc轉(zhuǎn)換模型的時候會報各種找不到so文件的錯誤排查起來很浪費時間。3. 模型轉(zhuǎn)換這一步才是靈魂從PyTorch權(quán)重到OM離線模型3.1 整體轉(zhuǎn)換鏈路PT → ONNX → OMAtlas NPU不直接讀取PyTorch的.pt文件也不像GPU那樣可以隨時用Python跑一個前向傳播。它需要的是經(jīng)過CANN的ATC工具離線編譯生成的**.om文件**Offline Model這種文件里包含經(jīng)過算子調(diào)度編排的NPU可執(zhí)行指令。整個轉(zhuǎn)換鏈路是這樣的PyTorch權(quán)重(.pt) → ONNX(.onnx) → OM(.om) → NPU推理為什么要多轉(zhuǎn)一次ONNX因為ATC工具的原生輸入格式是ONNX或MindSpore模型部分版本也支持TensorFlow的pb模型ONNX作為中間格式兼容性最好。YOLOv5和YOLOv8官方倉庫都支持導(dǎo)出ONNX所以這條鏈路最順。3.2 ATC轉(zhuǎn)換的核心參數(shù)與靜態(tài)shape問題這一步是整個部署過程中的關(guān)鍵也是報錯最多的地方。一個典型的YOLOv5s轉(zhuǎn)換命令長這樣atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --loginfo參數(shù)說明--model輸入ONNX文件路徑--framework固定寫5表示ONNX格式--output輸出OM文件的路徑前綴--soc_version這是最關(guān)鍵也最容易搞錯的參數(shù)必須填你的卡對應(yīng)的芯片型號。300V對應(yīng)的是Ascend310P系列具體是310P3還是310P用npu-smi info或CANN自帶的工具查填錯了會直接報不支持--input_shape固定輸入尺寸。ONNX如果本身是動態(tài)shape這里需要指定這里特別提醒ATC轉(zhuǎn)換時最容易踩的坑就是動態(tài)shape。YOLO官方導(dǎo)出的ONNX如果輸入維度是動態(tài)的轉(zhuǎn)換的時候必須用--input_shape固定下來或者用--dynamic_shape參數(shù)配合動態(tài)AIPP使用。我建議大家第一版直接固定成1,3,640,640先把推理跑通后面再做動態(tài)batch優(yōu)化。提示如果模型里有ATC不支持的算子轉(zhuǎn)換過程會報Not supported或Unsupported op。這時候需要先看是哪個算子常見處理思路是回到PyTorch里改檢測頭用更基礎(chǔ)的算子重新實現(xiàn)或者升級CANN版本新版算子庫覆蓋能力會更強。我自己測下來YOLOv5s的原始檢測頭在CANN 6.3上是能直接轉(zhuǎn)的YOLOv8需要確認最后一個輸出層的處理方式。3.3 算子映射和量化選項如何選很多人在意這個算子NPU支持不支持其實昇騰工具鏈已經(jīng)解決了大部分算子映射問題。ATC會把ONNX里的Conv、BatchNorm、ReLU等OP映射到CANN算子庫里的NPU實現(xiàn)底層是華為做好的高性能算子。如果你的模型里有一些冷門算子例如自定義ROI Align變體或部分上采樣方法ATC會報supportsSdot或提示需要整網(wǎng)下沉之類的信息。這時候有兩個選擇在導(dǎo)出ONNX前對模型結(jié)構(gòu)做修改把自定義算子替換為原生算子自己寫TBE算子實現(xiàn)這個門檻比較高一般項目不推薦量化方面FP16格式在Atlas 300V上是性能/精度平衡點。ATC轉(zhuǎn)換時可以加--output_typeFP16來指定模型輸出精度能顯著降低帶寬壓力但有些任務(wù)精度特別敏感就需要對比校準。如果要用INT8量化需要用CANN的AMCT工具做精度校準雖然推理吞吐更高但YOLO這種目標檢測任務(wù)對量化很敏感mAP掉點可能比較明顯。我的建議是先在FP16上跑通確認精度滿足需求后再考慮INT8。3.4 一個完整的實操案例YOLOv5s轉(zhuǎn)OM全過程這里我記錄一次完整的實操過程方便你對照復(fù)現(xiàn)第一步導(dǎo)出ONNX。用YOLOv5官方環(huán)境python export.py --weights yolov5s.pt --include onnx --opset 11注意opset不要選太高11比較穩(wěn)太高的opset有些算子ATC可能不認。第二步用Python腳本簡化ONNX并修改輸出節(jié)點。YOLOv5原始輸出是三個不同stride的特征圖80x80、40x40、20x20后面通常還會接一個nms后處理。ATC轉(zhuǎn)換成OM時可以把這三個輸出引出來后處理在Host側(cè)做這樣可以保持靈活性。第三步執(zhí)行ATC命令source /usr/local/Ascend/ascend-toolkit/set_env.sh atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1_fp16 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --output_typeFP16 \ --loginfo第四步等轉(zhuǎn)換完成確認輸出目錄里有yolov5s_bs1_fp16.om文件。轉(zhuǎn)換完成后這個.om文件就是部署的核心資產(chǎn)。后面任何推理調(diào)用都要基于它來做不需要再依賴PyTorch環(huán)境。4. 推理代碼怎么改從ACLLite到PycACL的落地實踐4.1 兩種開發(fā)范式ACLLite封裝 vs 原生AscendCL模型有了接下來就是寫推理代碼。昇騰這邊有兩種主流開發(fā)范式一種是直接用**AscendCLACL**的C接口或Python接口自己管理上下文、申請內(nèi)存、拷貝數(shù)據(jù)、執(zhí)行推理。代碼量較大但控制力最強適合需要精細優(yōu)化的場景。另一種是基于昇騰官方或社區(qū)的ACLLite封裝庫。ACLLite提供了一套面向圖像分類、目標檢測等常用場景的高層API把圖片解碼、縮放、channel轉(zhuǎn)換、推理、后處理這些環(huán)節(jié)都封裝好了幾行代碼就能跑一個YOLO檢測。對于剛開始接觸Atlas的開發(fā)者我推薦先走ACLLite路徑跑通全流程再用原生AscendCL做性能優(yōu)化。用一句行話來說先能跑再跑快。4.2 一個可運行的Python推理示例流程我基于PycACL寫過一個極簡的推理腳本核心邏輯大致分這幾步import acl import numpy as np # 1. 初始化ACL ret acl.init() ret acl.rt.set_device(0) context, ret acl.rt.create_context() # 2. 加載OM模型 model_id, ret acl.mdl.load_from_file(yolov5s_bs1_fp16.om) # 3. 獲取模型輸入輸出信息 input_desc acl.mdl.get_input_desc(model_id) model_input_size acl.mdl.get_input_size_by_index(model_id, 0) model_output_size acl.mdl.get_output_size_by_index(model_id, 0) # 4. 拷貝輸入圖像到Device側(cè) input_data preprocess(image) # 得到640x640x3的NCHW數(shù)據(jù) input_np np.array(input_data).tobytes() input_ptr acl.util.numpy_to_ptr(input_np) # 5. 執(zhí)行模型推理 output_ptr acl.mdl.execute(model_id, input_ptr, model_input_size) # 6. 將推理結(jié)果拷回Host output_np acl.util.ptr_to_numpy(output_ptr, (1, output_size), np.uint8) # 后續(xù)對output_np做解析得到檢測框代碼看起來不復(fù)雜但實際部署時真正的復(fù)雜度全都在預(yù)處理和后處理。預(yù)處理上你的輸入圖像必須先完成resize到640x640、歸一化、BGR轉(zhuǎn)RGB、NCHW排布然后搬到Device內(nèi)存。如果搞不定這些可以用AIPPAI Preprocessing功能它能在NPU上自動完成圖像縮放、色域轉(zhuǎn)換、歸一化等操作搬上去的原圖直接就能推理省掉大量Host側(cè)計算時間。后處理更麻煩。YOLOv5原始輸出有三個特征圖每個特征圖上的每個格子預(yù)測若干anchor偏移、目標分數(shù)和類別分數(shù)。你需要自己實現(xiàn)解碼邏輯把output解析成檢測框再做NMS非極大值抑制。這部分邏輯建議先用CPU側(cè)Python跑通再去優(yōu)化成C或使用MindX SDK的模型后處理插件。4.3 AIPP和模型輸入格式對齊的要點很多人部署時遇到檢測不到目標或整體精度崩了的問題十有八九是預(yù)處理跟模型訓(xùn)練時不一致。YOLOv5訓(xùn)練時用的是RGB輸入歸一化方式是除以255。那么在AIPP配置里必須指定{ aipp_op: { input_format: RGB888_U8, crop: false, resize: { src_image_size_w: 640, src_image_size_h: 640 }, mean: [0, 0, 0], min: [0, 0, 0], var: [0.003921569, 0.003921569, 0.003921569] } }var置為1/255相當于把像素值歸一化到0~1mean保持0。如果訓(xùn)練時的歸一化方式是mean[0.485,0.456,0.406]、std[0.229,0.224,0.225]ImageNet標準那你必須把AIPP的mean和var對應(yīng)改成這些值否則精度會掉得很離譜。4.4 多路視頻流并發(fā)推理的思路Atlas 300V的一個核心賣點是多路視頻分析。實測下來在300V 24G版上跑YOLOv5s單路視頻流1080p25fps非常輕松官方宣稱的幾十路并發(fā)主要靠多個Stream和模型實例組合來實現(xiàn)。具體做并發(fā)的時候有幾個關(guān)鍵點用acl.rt.create_stream()創(chuàng)建多個推理流把不同路的預(yù)處理、推理、后處理分散到不同Stream上盡量用異步接口acl.mdl.execute_async避免同步等待浪費NPU算力多路并發(fā)時batch size不一定越大越好1路用1個實例就夠多路合流到同一個實例會引入排隊延遲5. 實測踩坑記錄24GB顯存配額、精度對齊與性能排查5.1 24GB是存儲配額不是無限可用跑了一段時間后會發(fā)現(xiàn)雖然卡上標著24GB但你并不是隨時都能把24GB全部用完。CANN在運行時會預(yù)留一部分內(nèi)存做算子執(zhí)行緩沖、圖執(zhí)行器等開銷。實際可用大小跟模型結(jié)構(gòu)、輸入size、batch size、是否啟用動態(tài)shape都有關(guān)系。我的經(jīng)驗是YOLOv5s 640x640 batch size 8實際占用大約12GBYOLOv8m batch size 4大約14GB。如果是那種特別大的模型或者batch size 16以上建議先用acl.rt.get_mem_info()或者npu-smi實時監(jiān)控內(nèi)存占用別等到OOM再想辦法。OOM的典型報錯是ACL_ERROR_RT_MEMORY_ALLOCATION或HBM alloc failed。遇到之后優(yōu)先降batch size其次考慮精簡預(yù)處理緩沖區(qū)的數(shù)量最后再考慮換更小的模型變體。不要一上來就想調(diào)CANN內(nèi)存池參數(shù)那個容易引發(fā)其他副作用。5.2 YOLO推理精度跟GPU對不上照著這個鏈路查我在項目里踩過一個很深的坑同一個YOLOv5s權(quán)重在GPU上用PyTorch跑得好好的轉(zhuǎn)到OM之后檢測框明顯偏了置信度也低了很多。排查鏈路可以按順序來檢查預(yù)處理參數(shù)確認resize方式是letterbox還是直接拉伸、歸一化方式除以255還是ImageNet均值和方差、色域順序RGB還是BGR。這一步是90%的精度問題的根源。檢查輸入圖像排布確認輸入是NCHW還是NHWC。ONNX默認NCHW但如果你在AIPP里配置成NHWC就會導(dǎo)致通道錯亂。檢查FP16截斷誤差把轉(zhuǎn)換命令里的--output_typeFP16臨時去掉轉(zhuǎn)一個FP32的OM模型對比精度。如果FP32精度恢復(fù)正常說明是FP16下的累積誤差問題可以考慮對模型做混合精度校準或者在關(guān)鍵層保留FP32。檢查后處理解碼邏輯YOLOv5的三個輸出特征圖的順序在OM里和ONNX里不一定保持一致確認你的解碼順序跟模型輸出結(jié)構(gòu)匹配。5.3 性能瓶頸到底在哪用npu-smi和profiling工具定位部署完成后做性能壓測發(fā)現(xiàn)推理耗時不太理想這時候別急著懷疑NPU算力不夠。先用工具看看瓶頸在哪個環(huán)節(jié)。npu-smi info看NPU利用率和內(nèi)存占用如果AI Core利用率長期低于50%說明推理本身沒問題瓶頸可能出在數(shù)據(jù)搬運或后處理上。更精細的排查用CANN自帶的profiling工具msprof --applicationpython infer.py --outputprof_out這個工具會輸出算子級的執(zhí)行時間、數(shù)據(jù)搬運時間、CPU/Device同步等待時間。實測過程中我發(fā)現(xiàn)很多推理慢的案例其實是Host側(cè)圖片解碼和resize太慢NPU一直在等數(shù)據(jù)算力利用率根本提不上來。解決辦法就是上AIPP或者用DVPP硬件解碼把預(yù)處理壓力從CPU挪到專門的硬件模塊上。另外還要檢查是否開啟了aicore和aicpu同步模式的合理搭配。對于純卷積類的YOLO主干aicore是主力如果模型里有很多reshape、transpose這類算子aicpu可能成為瓶頸這時候要考慮在模型轉(zhuǎn)換時用--insert_op_conf做算子融合優(yōu)化。6. 什么樣的人適合拿Atlas 300V跑YOLO——選型建議與擴展思考6.1 GPU與Atlas NPU的取舍對比經(jīng)常有人問我都花了這個錢為什么不去買張NVIDIA顯卡。這個問題的答案得看場景。對比維度NVIDIA GPU如RTX 3060/4070Atlas 300VAI訓(xùn)練支持生態(tài)成熟基本不適合CANN主要面向推理推理性能/功耗中規(guī)中矩功耗偏高同等算力下功耗明顯更低推理并發(fā)能力依賴多Stream編程硬件偏通用面向多路視頻分析場景設(shè)計開發(fā)門檻CUDA生態(tài)資料多需要學(xué)習CANN資料相對少模型兼容性幾乎所有框架直接跑需轉(zhuǎn)換為OM算子可能不兼容如果你做的是AI訓(xùn)練、算法快速迭代這類任務(wù)毫無疑問選GPU。但如果你是做一個已訓(xùn)練好的YOLO模型的高并發(fā)推理服務(wù)要對幾百路視頻流做實時分析而且功耗和機柜空間都有嚴格限制那Atlas 300V這類推理卡是有優(yōu)勢的。6.2 部署形態(tài)的選擇Atlas 300V vs 昇騰AI設(shè)備盒子除了PCIe加速卡昇騰系還有Atlas 200/300系列開發(fā)者套件和智能小站這類一體機產(chǎn)品。如果你的算力需求不大比如只有一兩路視頻流買個小盒子更方便開箱即用不用自己折騰服務(wù)器環(huán)境。但如果是工業(yè)化、規(guī)?；倪吘売嬎慵?00V這種PCIe插卡形態(tài)更靈活可以按需插在不同服務(wù)器上。6.3 未來還可以往哪些方向擴展拿到Atlas 300V并且跑通了YOLO后續(xù)可以做的方向其實很多模型層面從YOLOv5s升級到Y(jié)OLOv8m甚至YOLOX驗證不同檢測頭在NPU上的算子兼容性功能層面接DeepSORT之類的多目標跟蹤算法配合多路視頻流實現(xiàn)端到端的智能分析管線業(yè)務(wù)層面把檢測結(jié)果通過消息隊列推到后端對接告警、統(tǒng)計、檢索等業(yè)務(wù)系統(tǒng)性能層面引入動態(tài)batch、多實例并發(fā)、模型量化等手段把單卡的推理吞吐壓到極限我自己的下一步計劃是把模型推理封裝成一個標準的gRPC服務(wù)對外暴露統(tǒng)一的檢測API這樣不同業(yè)務(wù)方都可以通過HTTP/gRPC調(diào)用同一個推理引擎省得每個人單獨寫一套推理邏輯。這個架構(gòu)在Atlas平臺上完全可行只需要注意多請求并發(fā)時的模型實例排隊策略。說到底Atlas 300V不是一張換了牌子的GPU它是為特定場景深度優(yōu)化過的專用推理引擎。搞明白了它的定位和用法你會發(fā)現(xiàn)它在YOLO部署這件事上絕對稱得上順手——功耗低、并發(fā)能力強、部署形態(tài)靈活唯一要付出的成本是你愿意花點時間去適應(yīng)CANN這套工具鏈。就像我第一次跑通OM轉(zhuǎn)換、看到NPU上實時輸出檢測框時的感受一開始覺得麻煩摸到門路之后真香。