戰(zhàn))
1. Atlas到底是什么為什么我用它跑YOLO先說結(jié)論華為Atlas 300V 24G確實(shí)是一塊運(yùn)算加速卡但它不是普通顯卡而是專門為AI推理設(shè)計(jì)的NPU計(jì)算卡。我之所以把YOLO檢測模型從GPU遷移到Atlas上核心原因就三個(gè)字性價(jià)比、能效比、國產(chǎn)化要求。這兩年目標(biāo)檢測需求量太大了安防巡檢、工業(yè)質(zhì)檢、園區(qū)管理、智慧交通到處都在跑YOLOv5、YOLOv8這類模型。以往大家第一反應(yīng)就是上NVIDIA的GPU比如T4、3080、A10之類的。但在實(shí)際項(xiàng)目中你早晚會遇到這么幾個(gè)問題GPU缺貨溢價(jià)、功耗和散熱限制、機(jī)柜空間緊張、以及一部分政企客戶明確要求全鏈路國產(chǎn)化。這時(shí)候Atlas 300V就是一個(gè)值得認(rèn)真評估的替代方案。Atlas 300V 24G這張卡單卡內(nèi)存24GB算力主要走昇騰自研的AI Core不是CUDA Core所以它和GPU的關(guān)系更像是“術(shù)業(yè)有專攻”——圖像渲染、通用計(jì)算它不擅長但跑卷積神經(jīng)網(wǎng)絡(luò)這種算子密集型負(fù)載尤其是低精度推理它能做到很高的吞吐同時(shí)功耗控制得比同級別GPU更好。再說說“Atlas部署YOLO”這件事本身。很多人一聽“部署”就以為是把.pt文件拷貝過去然后調(diào)個(gè)接口實(shí)際遠(yuǎn)沒這么簡單。從NVIDIA生態(tài)切到昇騰生態(tài)需要經(jīng)歷數(shù)據(jù)格式、網(wǎng)絡(luò)結(jié)構(gòu)、算子映射、圖優(yōu)化的全鏈路適配。YOLO模型本身結(jié)構(gòu)并不復(fù)雜就是卷積加殘差加檢測頭但它里面的算子種類不少加上訓(xùn)練用的PyTorch框架和昇騰推理框架的算子實(shí)現(xiàn)有差異所以部署流程里最容易出問題的地方反而不是“能不能跑”而是“怎么讓它跑得快、跑得穩(wěn)、不報(bào)算子不支持”。這篇文章我會按照我實(shí)際做過的一個(gè)項(xiàng)目來走一遍完整流程包括硬件選型、軟件棧梳理、PyTorch模型轉(zhuǎn)ONNX再轉(zhuǎn)昇騰OM格式、AscendCL推理代碼編寫、性能調(diào)優(yōu)和常見報(bào)錯(cuò)排查?？赐曛蠹词鼓闶堑谝淮谓佑|昇騰平臺也能對“Atlas上跑YOLO”這件事有一個(gè)整體可落地的認(rèn)知。2. 部署前必須搞清楚的硬件與軟件棧2.1 Atlas 300V 24G硬件定位與參數(shù)理解Atlas 300V 24G在昇騰產(chǎn)品線里屬于邊緣計(jì)算推理卡和訓(xùn)練卡比如Atlas 800T定位完全不同。它主打的是低功耗、高能效推理適合部署在邊緣服務(wù)器、工控機(jī)、智能盒子這類環(huán)境里。先糾正一個(gè)常見誤解這張卡是“運(yùn)算加速卡”沒錯(cuò)但它并不像顯卡一樣直接插上就能顯示畫面或者拿來跑CUDA程序。它需要配合昇騰的驅(qū)動和CANN工具包才能工作本質(zhì)上是“AI協(xié)處理器”所有編程模型都圍繞昇騰自己的AscendCLAscend Computing Language接口來寫。我用的這張卡具體參數(shù)大概是這樣項(xiàng)目規(guī)格說明內(nèi)存容量24GB注意這里指的是板載內(nèi)存相當(dāng)于GPU顯存的作用內(nèi)存帶寬實(shí)測在邊緣推理場景下足夠支撐多路視頻流的并發(fā)檢測推理精度主要跑INT8也支持FP16FP32性能相對弱一些接口形態(tài)PCIe標(biāo)準(zhǔn)卡支持普通x86服務(wù)器也支持鯤鵬/飛騰等ARM平臺核心架構(gòu)昇騰AI Core算力由多個(gè)AI Core集群提供為什么“24G大內(nèi)存”這么重要因?yàn)閅OLO模型本身權(quán)重不大YOLOv5s才14MB左右占內(nèi)存的主要是中間特征圖。當(dāng)你要跑批量推理比如batch設(shè)為4或8連續(xù)處理1080P視頻流時(shí)特征圖會迅速堆積。24G內(nèi)存意味著你可以把更大的batch和數(shù)據(jù)預(yù)處理管線都放在卡上不用頻繁地和CPU來回拷貝數(shù)據(jù)這對推理吞吐提升非常明顯。2.2 昇騰部署的整體軟件棧與概念梳理如果你以前只接觸過CUDA生態(tài)第一次看到昇騰這套軟件棧可能會有點(diǎn)懵。別怕我?guī)湍惆牙锩娴慕巧砬宄Ｗ畹讓邮球?qū)動和固件這一層負(fù)責(zé)讓操作系統(tǒng)識別設(shè)備相當(dāng)于GPU驅(qū)動。往上走是CANNCompute Architecture for Neural Networks它相當(dāng)于昇騰的CUDA工具包加TensorRT的結(jié)合體提供算子庫、圖編譯引擎GE、運(yùn)行時(shí)環(huán)境。再往上是各種推理框架的適配層你可以用MindSpore直接跑昇騰也可以用pyACLPython版AscendCL手寫推理代碼甚至通過ONNX Runtime昇騰版或OpenCV的dnn模塊走昇騰后端。這里有一個(gè)最容易混淆的點(diǎn)我們平時(shí)用的PyTorch模型并不能直接在Atlas上跑至少不能直接跑得像GPU上那么順。常規(guī)做法是先把PyTorch模型導(dǎo)出為ONNX再用CANN自帶的ATC工具把ONNX編譯成昇騰專屬的OM模型Offline Model最后在運(yùn)行環(huán)境里加載OM進(jìn)行推理。為什么不直接用PyTorch原生推理因?yàn)镻yTorch在昇騰上默認(rèn)走算子逐層調(diào)用圖優(yōu)化不夠深性能會打折扣。ATC會做算子融合、內(nèi)存復(fù)用、數(shù)據(jù)格式轉(zhuǎn)換等一系列優(yōu)化把整個(gè)計(jì)算圖固化下來相當(dāng)于為這張卡“量身定制”了一版模型。所以O(shè)M模型才是Atlas上真正的高效形態(tài)。另外還有一個(gè)容易踩坑的版本對齊問題。昇騰生態(tài)的版本管理相當(dāng)嚴(yán)格驅(qū)動、固件、CANN、MindSpore/ACL這幾個(gè)版本必須互相匹配否則你會看到一堆莫名其妙的報(bào)錯(cuò)。我建議什么功課都不要做直接去昇騰社區(qū)查“版本配套表”照著表上能對上的版本組合來安裝千萬別混搭新版本CANN配舊版本驅(qū)動血的教訓(xùn)。2.3 為什么用Notebook式驗(yàn)證而不是一上來就寫大工程在實(shí)際動手之前我強(qiáng)烈推薦先在一臺裝了昇騰環(huán)境的服務(wù)器上用Python交互式環(huán)境把每一步跑通而不是一上來就寫完整的推理工程。原因很簡單模型轉(zhuǎn)換、推理調(diào)用這個(gè)階段你碰到的絕大多數(shù)問題是環(huán)境問題不是代碼邏輯問題。一旦環(huán)境通了后面寫業(yè)務(wù)代碼就會非常順暢。我之前踩過最大的坑就是“一次性集成”。把模型加載、預(yù)處理、推理、后處理全寫完結(jié)果一跑也不知道是環(huán)境問題還是代碼問題排查起來特別痛苦。正確的姿勢是先用一個(gè)最簡單的ONNX模型做最小驗(yàn)證比如隨機(jī)生成一張輸入圖片能跑出結(jié)果證明“驅(qū)動CANNATCACL”這條鏈路是通的再在這個(gè)基礎(chǔ)上逐漸加入YOLO模型和后處理邏輯。這樣一來每個(gè)環(huán)節(jié)出了問題都能快速定位。3. YOLO模型遷移實(shí)戰(zhàn)從PyTorch權(quán)重到昇騰OM模型3.1 YOLO模型的選型與推理分支取舍我自己在Atlas上部署得最多的是YOLOv5和YOLOv8。就部署難度而言YOLOv5更成熟網(wǎng)上能找到的昇騰案例也更多YOLOv8的檢測頭結(jié)構(gòu)稍微不一樣但整體適配也不難。這里先說一個(gè)關(guān)鍵取舍導(dǎo)出的ONNX模型到底帶不帶后處理NMS我的建議是導(dǎo)出的時(shí)候去掉NMS只保留Backbone加Neck加Head的輸出。理由有三點(diǎn)。第一ONNX里的NMS算子在不同框架實(shí)現(xiàn)差異很大ATC轉(zhuǎn)換時(shí)比較容易出幺蛾子第二NMS的輸入張量結(jié)果是動態(tài)數(shù)量檢測框數(shù)量不確定這在靜態(tài)圖優(yōu)化比較強(qiáng)的昇騰平臺上會帶來額外復(fù)雜度第三從推理性能角度看把后處理放在CPU上或者自己用向量化計(jì)算寫反而更容易調(diào)優(yōu)也更靈活。所以你的導(dǎo)出目標(biāo)其實(shí)很純粹輸入是[1, 3, H, W]的三通道圖像輸出是YOLO檢測頭的原始預(yù)測比如YOLOv5就是一個(gè)[1, 25200, 85]的張量其中25200表示三個(gè)尺度輸出的候選框總數(shù)85表示4個(gè)框坐標(biāo)加1個(gè)目標(biāo)置信度加80個(gè)類別分?jǐn)?shù)。3.2 PyTorch模型轉(zhuǎn)ONNX的常見細(xì)節(jié)這里用一個(gè)YOLOv5s的導(dǎo)出示例來演示。你需要在訓(xùn)練好的模型上調(diào)用torch.onnx.export導(dǎo)出時(shí)有幾個(gè)參數(shù)非常關(guān)鍵。第一是opset_version我一般固定用opset_version11。太低的算子版本有些新算子不支持太高的話昇騰ATC在解析時(shí)可能出現(xiàn)未知算子。第11版是目前昇騰兼容性最好的平衡點(diǎn)。第二是dynamic_axes。如果你想在推理時(shí)自由切換不同分辨率可以把它設(shè)成動態(tài)維度。但實(shí)際上我個(gè)人建議盡量固定輸入形狀比如固定成1x3x640x640。理由很簡單動態(tài)輸入意味著ATC沒法做充分的內(nèi)存規(guī)劃和算子融合性能會有明顯折損而且動態(tài)shape處理不當(dāng)還會導(dǎo)致模型加載或推理時(shí)出現(xiàn)奇奇怪怪的報(bào)錯(cuò)。如果你確實(shí)有變分辨率需求更好的方式是保存幾個(gè)不同分辨率的OM模型推理時(shí)根據(jù)輸入尺寸切換。第三是輸出張量的順序。YOLOv5官方導(dǎo)出腳本輸出的張量形狀是[1, 25200, 85]這個(gè)信息在推理代碼里要用到所以我一般導(dǎo)完ONNX之后會寫兩行代碼驗(yàn)證一下確認(rèn)形狀符合預(yù)期import onnx model onnx.load(yolov5s.onnx) for inp in model.graph.input: print(input:, inp.name, [d.dim_value for d in inp.type.tensor_type.shape.dim]) for out in model.graph.output: print(output:, out.name, [d.dim_value for d in out.type.tensor_type.shape.dim])如果你發(fā)現(xiàn)輸出是[1, 85, 25200]這樣的排列做后處理的時(shí)候就要先轉(zhuǎn)置這個(gè)到推理代碼部分再細(xì)說。3.3 ATC模型轉(zhuǎn)換核心參數(shù)與AIPP配置拿到ONNX模型之后接下里就是用ATC工具把它編譯成OM模型。ATC命令位于CANN安裝目錄的/usr/local/Ascend/ascend-toolkit/latest/bin下通常配置好環(huán)境變量后直接在終端敲atc就能用。我的一條典型轉(zhuǎn)換命令長這樣atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_om \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --insert_op_confaipp.cfg \ --output_typeFP32逐個(gè)解釋一下這些參數(shù)--framework55代表ONNX。--soc_version這個(gè)必須填你實(shí)際芯片的型號。Atlas 300V 24G對應(yīng)的昇騰芯片當(dāng)前是Ascend310P系列的某一款具體從npu-smi info能看到。如果填錯(cuò)了轉(zhuǎn)換可能成功但加載到卡上會報(bào)版本不匹配的錯(cuò)誤。--input_shape和你導(dǎo)出的ONNX輸入保持一致。這里images是輸入節(jié)點(diǎn)的名字不能寫錯(cuò)可以用前面的Python腳本查看。--insert_op_conf這就是很多人忽略的AIPP配置。AIPP的作用是在硬件層面完成圖像預(yù)處理包括縮放、顏色空間轉(zhuǎn)換、歸一化。YOLO系列輸入通常是RGB分布到0到1之間如果你不配置AIPP就得在推理代碼里自己用CPU或DVPP做完這些操作不僅麻煩還會讓預(yù)處理成為性能瓶頸。我的AIPP配置文件大概長這樣aipp_op { aipp_mode: static input_format: RGB src_image_size_w: 640 src_image_size_h: 640 crop: true load_start_pos_h: 0 load_start_pos_w: 0 resize: true resize_output_w: 640 resize_output_h: 640 mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 min_chn_0: 255.0 min_chn_1: 255.0 min_chn_2: 255.0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }這個(gè)配置表示輸入圖像是RGB順序模型期望RGB如果模型訓(xùn)練時(shí)用的是BGR你就改成BGR。min_chn和var_reci_chn組合起來的作用就是把像素從0-255縮放到0-1。src_image_size_w/h和resize_output_w/h在模型輸入是固定尺寸時(shí)可以直接寫成模型的輸入尺寸這樣ATC轉(zhuǎn)換時(shí)會自動在圖里插入縮放算子省掉你在預(yù)處理代碼里自己寫resize的煩惱。還有一點(diǎn)值得提如果你喂給模型的圖片比例不對直接在AIPP里做resize容易讓物體形狀扭曲。通常YOLO訓(xùn)練本身足夠魯棒這一點(diǎn)影響不大。如果實(shí)在在意可以在預(yù)處理代碼里先做letterbox填充再做resize但這樣一來AIPP的自動縮放就沒法用了需要關(guān)閉AIPP的resize自己準(zhǔn)備好已經(jīng)resize到640x640的圖片數(shù)據(jù)。3.4 模型轉(zhuǎn)換環(huán)節(jié)的典型坑我在這里列幾個(gè)自己遇到過的報(bào)錯(cuò)。第一個(gè)是“unsupported op”。比如某些算子ATC不識別最常見于SiLU激活函數(shù)或者一些新版本PyTorch導(dǎo)出的自定義算子。解決辦法一般是兩個(gè)方向一是換PyTorch版本或ONNX導(dǎo)出的opset版本二是看能不能把不支持的算子改寫成等效的算子組合比如把SiLU替換成Sigmoid加乘法的組合。如果實(shí)在繞不過去可以查一下飛槳或MindSpore的算子映射表往往能找到經(jīng)驗(yàn)。第二個(gè)是“static aipp with dynamic shape failed”這類錯(cuò)誤。多半是你在--input_shape里傳了-1但又開了AIPP。AIPP在靜態(tài)模式要求輸入shape完全固定所以要么把shape改成固定的要么關(guān)掉AIPP。我上文建議固定shape就是為了和AIPP配合順暢。第三個(gè)是轉(zhuǎn)換成功但推理輸出全為0或固定值。這種情況大概率是AIPP里歸一化參數(shù)配錯(cuò)了導(dǎo)致輸入數(shù)據(jù)分布完全偏離訓(xùn)練分布。檢查一下min_chn與var_reci_chn到底在做什么以及輸入數(shù)據(jù)的格式到底是CHW還是HWC就能找到問題。4. 寫推理代碼AscendCLpyACL完整流程4.1 初始化設(shè)備與運(yùn)行上下文模型轉(zhuǎn)換完畢OM文件拿到手接下來就是寫推理程序。昇騰的CANN提供了C語言接口也提供Python包pyACL。生產(chǎn)環(huán)境最終一般用C寫高并發(fā)服務(wù)但做原型驗(yàn)證或者并發(fā)要求不高的業(yè)務(wù)Python完全夠用。整個(gè)pyACL推理程序的結(jié)構(gòu)可以看作五個(gè)階段初始化設(shè)備、加載模型、準(zhǔn)備輸入輸出、執(zhí)行推理、處理輸出。第一件事是設(shè)置環(huán)境變量和初始化設(shè)備import acl # 初始化 ret acl.init() assert ret 0 # 指定設(shè)備這里以0號卡為例 ret acl.rt.set_device(0) assert ret 0 # 創(chuàng)建運(yùn)行上下文 context, ret acl.rt.create_context(0) assert ret 0 # 創(chuàng)建推理流 stream, ret acl.rt.create_stream() assert ret 0這里的“設(shè)備”就是指Atlas 300V卡一張卡對應(yīng)一個(gè)物理設(shè)備。如果你服務(wù)器里插了多張卡可以通過環(huán)境變量或代碼指定使用哪一張。上下文和流的概念和CUDA很相似理解起來沒有障礙不過要注意在程序結(jié)束前釋放資源和銷毀流否則會有資源泄露的報(bào)錯(cuò)。4.2 加載OM模型并管理輸入輸出buffer加載模型使用acl.mdl.load_from_file它會返回一個(gè)模型ID后續(xù)所有推理操作都靠這個(gè)ID來引用模型model_id, ret acl.mdl.load_from_file(yolov5s_om.om) assert ret 0 # 獲取模型描述信息 model_desc acl.mdl.create_desc() ret acl.mdl.get_desc(model_desc, model_id)有了模型描述你可以從里面讀出模型的輸入輸出維度、數(shù)據(jù)類型、buffer大小然后根據(jù)這些信息分配Device側(cè)內(nèi)存。這一步是重點(diǎn)因?yàn)槟阍贖ost側(cè)準(zhǔn)備好的圖片數(shù)據(jù)是不能直接被模型使用的必須拷貝到Device側(cè)。通常的做法是給模型的每個(gè)輸入申請一塊Device內(nèi)存再把圖像數(shù)據(jù)顯示拷貝過去。pyACL里最常見的是先使用acl.mdl.get_input_size_by_index拿到輸入size再調(diào)用acl.rt.malloc分配內(nèi)存然后使用acl.rt.memcpy把Host數(shù)據(jù)拷貝到Device內(nèi)存。這里有一個(gè)容易繞暈的點(diǎn)輸入數(shù)據(jù)到底怎么擺放。AIPP配置成靜態(tài)模式后模型輸入節(jié)點(diǎn)期望的是已經(jīng)經(jīng)過AIPP處理的“裸數(shù)據(jù)”也就是分辨率匹配的、未歸一化的原始圖像像素。聽起來有點(diǎn)繞簡單說就是你只需要把解碼后的圖片resize到640x640并轉(zhuǎn)成RGB/BGR排好然后直接往Device內(nèi)存里扔剩下的縮放、歸一化由AIPP在硬件上完成。如果你的AIPP沒有開resize你還要自己在Host側(cè)把圖resize成640x640再拷貝。也別忘了排查圖像數(shù)據(jù)的內(nèi)存排列方式很多格式問題出在通道順序和步長上。4.3 圖像預(yù)處理細(xì)節(jié)可以不依賴opencv的部分圖像預(yù)處理在GPU部署時(shí)代往往被忽視因?yàn)镺penCV足夠方便。但在音視頻平臺或嵌入式環(huán)境里OpenCV的依賴有時(shí)候會給你帶來額外的交叉編譯成本所以我一般建議盡量把預(yù)處理職責(zé)劃分清楚圖像解碼如果是JPEG建議用昇騰的DVPP圖像解碼接口它的耗時(shí)遠(yuǎn)低于CPU端OpenCV的imdecode。DVPP是昇騰硬件上的媒體處理單元能硬解碼視頻和圖片。圖像縮放如果AIPP沒有啟用resize可以用DVPP的VPC做硬件縮放。如果AIPP啟用了resize那就直接在Host側(cè)用OpenCV或Numpy插值因?yàn)檫@一步會被AIPP替代。數(shù)據(jù)格式轉(zhuǎn)換DVPP輸出的圖像格式默認(rèn)是YUV420SP這張圖分類任務(wù)里可以直接送AIPP轉(zhuǎn)RGB但在目標(biāo)檢測中你需要把YUV數(shù)據(jù)再轉(zhuǎn)成RGB這塊頭緒比較多我建議初學(xué)階段直接用OpenCV解碼resize功能優(yōu)先性能后調(diào)。等整個(gè)鏈路跑通了再考慮用DVPP來替換瓶頸。每次踩坑都可能是內(nèi)存對齊問題。昇騰的Device內(nèi)存通常要求對齊到32字節(jié)或64字節(jié)。如果你自己構(gòu)造輸入buffer務(wù)必讓每一行數(shù)據(jù)長度對齊到16或32的倍數(shù)否則會出現(xiàn)當(dāng)你檢查數(shù)據(jù)明明是對的、但模型輸出誤差很大的情況。這也是為什么很多時(shí)候用一個(gè)現(xiàn)成的推理插件比手寫完整流程更省心的原因——很多對齊問題“前輩們”已經(jīng)替你處理過了。4.4 執(zhí)行推理帶示例代碼用pyACL執(zhí)行一次推理整體代碼如下# 創(chuàng)建輸出數(shù)據(jù)集 output_desc acl.mdl.create_dataset() output_size acl.mdl.get_output_size_by_index(model_desc, 0) # 申請輸出設(shè)備內(nèi)存 out_buffer, ret acl.rt.malloc(output_size, 2 * 1024 * 1024) assert ret 0 output_data acl.create_data_buffer(out_buffer, output_size) ret acl.mdl.add_dataset_buffer(output_desc, output_data) # 創(chuàng)建輸入數(shù)據(jù)集 input_desc acl.mdl.create_dataset() # input_buffer 是之前申請并拷貝好圖片數(shù)據(jù)的Device內(nèi)存 input_data acl.create_data_buffer(input_buffer, input_size) ret acl.mdl.add_dataset_buffer(input_desc, input_data) # 執(zhí)行推理 ret acl.mdl.execute(model_id, input_desc, output_desc) assert ret 0 # 同步等待這里可以替換成流同步 ret acl.rt.synchronize_stream(stream) assert ret 0 # 從device內(nèi)存拷貝回host內(nèi)存 out_result np.zeros(output_size, dtypenp.uint8) ret acl.rt.memcpy(out_result, output_size, out_buffer, output_size, acl.ACL_MEMCPY_DEVICE_TO_HOST) assert ret 0 # 解析輸出后面會展開這段代碼就是一個(gè)完整的推理閉環(huán)。把其中的acl.mdl.execute理解成和cudaMemcpy加cudaLaunchKernel的組合操作會有助于快速理解它為什么要區(qū)分輸入輸出數(shù)據(jù)集、為什么要專門從device拷回host。4.5 后處理YOLO輸出解碼與NMS模型輸出的原始數(shù)據(jù)通常是[1, 25200, 85]的浮點(diǎn)數(shù)組你需要將它轉(zhuǎn)換為你實(shí)際使用的檢測框。后處理的關(guān)鍵步驟為將輸出reshape成[1, 25200, 85]。通過閾值篩選目標(biāo)置信度高于置信度閾值的框。對每個(gè)類別分別執(zhí)行NMS非極大值抑制去掉重疊框。將坐標(biāo)還原到原圖尺寸尺度變換。如果你用的是YOLOv5它的輸出解碼方式是已知的框的坐標(biāo)是相對于輸出特征圖尺寸的需要乘以輸入尺寸和原尺寸的比例來還原到原圖坐標(biāo)同時(shí)要記得坐標(biāo)是cxcywh格式。YOLOv8的結(jié)構(gòu)稍微有一點(diǎn)點(diǎn)不同但現(xiàn)在主流的各種開源YOLO項(xiàng)目基本都提供了后處理參考代碼你只要把輸入從[batch, 84, 8400]改成自己的[1, 85, 25200]排列就能快速適配。這里我要特別提醒經(jīng)過ATC轉(zhuǎn)換后的OM輸出其輸出布局可能與你導(dǎo)出ONNX時(shí)觀察到的不同。ATC可能會重排輸出張量的維度導(dǎo)致你在代碼里拿到的shape不是預(yù)想的[1,25200,85]而可能是[1,85,25200,1]之類的奇怪排列。解決的辦法是在加載模型后先根據(jù)模型描述打印所有輸出的shape拿這個(gè)實(shí)際shape來寫后處理解析代碼。不要死搬ONNX里的shape這是我個(gè)人踩過最無語的一個(gè)坑。5. 工程化部署中不得不說的性能與穩(wěn)定性問題跑通單張圖片的推理只是第一步。實(shí)際項(xiàng)目中輸入往往是一條視頻流或者一個(gè)文件夾里幾千張圖這時(shí)候你要考慮的不再是“能不能跑”而是“能不能扛得住”。5.1 多路視頻流與batch推理的策略Atlas 300V 24G的優(yōu)勢之一就是能同時(shí)處理多路視頻流。但多路并非簡單地開多個(gè)線程跑多次推理更優(yōu)的方案是利用batch推理。首先YOLO模型在ATC轉(zhuǎn)換時(shí)就可以設(shè)置固定batch比如--input_shapeimages:4,3,640,640。推理時(shí)每次喂4張圖進(jìn)去讓AI Core同時(shí)處理4張圖。通常batch從1提到4吞吐量能提升2-3倍這個(gè)收益非?？捎^。但batch推理的難點(diǎn)在于你的輸入圖片必須是同一個(gè)尺寸且同時(shí)準(zhǔn)備好。對于一個(gè)單路視頻流你沒法同時(shí)拿到4幀對于多路視頻流你可以把4路視頻的當(dāng)前幀拼成一個(gè)大batch送進(jìn)去。實(shí)際工程上我會用一個(gè)緩沖隊(duì)列把多個(gè)輸入源的幀按順序排好攢夠一個(gè)batch就推理一次。如果某一幀處理時(shí)間太長就做丟幀或排隊(duì)策略保證整個(gè)系統(tǒng)的延遲可控。5.2 內(nèi)存復(fù)用與資源釋放很多人在Atlas上跑Python推理時(shí)部署一段時(shí)間后發(fā)現(xiàn)內(nèi)存越來越大最后程序崩潰。原因往往是每幀推理都重新申請Device內(nèi)存、創(chuàng)建數(shù)據(jù)緩沖卻忘了釋放。我的習(xí)慣是在初始化階段一次性申請好輸入輸出buffer推理過程中反復(fù)復(fù)用同一個(gè)buffer。只有當(dāng)輸入圖像尺寸變化時(shí)才重新分配。這樣既減少了設(shè)備側(cè)內(nèi)存分配的系統(tǒng)調(diào)用開銷也避免了內(nèi)存泄漏。對應(yīng)的釋放流程也別忘程序退出時(shí)要依次調(diào)用acl.rt.free釋放Device內(nèi)存、acl.mdl.unload卸載模型、acl.rt.destroy_stream銷毀流、acl.rt.destroy_context銷毀上下文最后acl.finalize。如果省掉這些步驟最典型的后果是多次加載/卸載模型時(shí)顯存一直被占著不釋放最終設(shè)備不可用。5.3 使用profiling工具定位性能瓶頸昇騰提供了一套性能分析工具叫msprof它會采集算子耗時(shí)、數(shù)據(jù)拷貝耗時(shí)、NPU利用率等信息。這個(gè)工具是排查性能問題的重要幫手。比如你在推理中發(fā)現(xiàn)幀率怎么都上不去不要先懷疑模型算力不夠。用msprof采一下數(shù)據(jù)你會經(jīng)?？吹竭@樣的情況NPUAI Core利用率不到50%但延遲已經(jīng)很高。這種時(shí)候瓶頸壓根不在模型推理而是數(shù)據(jù)拷貝或預(yù)處理耗時(shí)占比太大。解決辦法通常是把預(yù)處理挪到DVPP設(shè)備端去或者在Host側(cè)用多線程并發(fā)做預(yù)處理。如果是NPU利用率已經(jīng)接近100%那瓶頸確實(shí)在模型側(cè)這時(shí)候可以考慮用精度更低的INT8量化模型、減少輸入分辨率、或者換用更輕量的YOLO變體如YOLOv5n、YOLOv8s。5.4 性能數(shù)據(jù)速查表根據(jù)我的實(shí)測整理我在同型號Atlas 300V 24G上測試過幾組配置整理出來的數(shù)據(jù)可以參考模型版本輸入分辨率單幀耗時(shí)ms說明YOLOv5s640x6408-12默認(rèn)FP16推理單batchYOLOv5s640x6404-6batch4時(shí)單幀平均耗時(shí)顯著下降YOLOv8s640x64010-14模型稍大算子稍多但差距可控YOLOv5s1280x128030-40大分辨率適合小目標(biāo)檢測但耗時(shí)會漲YOLOv5s INT8量化640x6403-5INT8帶來明顯加速但需要校準(zhǔn)數(shù)據(jù)集需要說明的是這個(gè)數(shù)據(jù)受到驅(qū)動版本、CANN版本、服務(wù)器CPU性能、以及是否使用DVPP預(yù)處理等因素影響。但對于評估“Atlas到底行不行”恐怕足夠了單卡跑到接近100幀每秒的YOLOv5s處理能力在邊緣側(cè)已經(jīng)相當(dāng)實(shí)用。6. 常見問題與排查技巧實(shí)錄部署過程中遇到的報(bào)錯(cuò)千奇百怪但歸納下來無非集中在以下幾個(gè)方面我按出現(xiàn)概率排個(gè)序。6.1 環(huán)境與設(shè)備問題出現(xiàn)概率最高報(bào)錯(cuò)形如acl.rt.set_device ... run error或者[ERROR] GE( ... Failed to init device。這個(gè)基本就是驅(qū)動和固件沒配對。第一種可能是驅(qū)動沒裝好npu-smi info都看不到卡第二種可能是Ascend環(huán)境變量沒source你在終端每開一個(gè)新窗口都要記得source一遍/usr/local/Ascend/ascend-toolkit/set_env.sh否則Python里根本import不到acl模塊或者找不到運(yùn)行庫。第三種是權(quán)限問題普通用戶訪問不了設(shè)備節(jié)點(diǎn)需要把用戶加入HwHiAiUser用戶組或用root運(yùn)行。排查這個(gè)階段我的固定做法是先跑一下npu-smi info確認(rèn)設(shè)備健康然后跑一個(gè)最簡單的設(shè)備初始化腳本比如只調(diào)用acl.init()和acl.rt.set_device(0)成功后再往下走。6.2 模型轉(zhuǎn)換與算子報(bào)錯(cuò)最需要耐心已經(jīng)在3.4節(jié)講了一部分這里補(bǔ)充兩個(gè)經(jīng)驗(yàn)。第一個(gè)經(jīng)驗(yàn)是“算子不支持”的排查路徑。ATC轉(zhuǎn)換報(bào)錯(cuò)日志經(jīng)常非常長你只需要關(guān)注最后幾行里提到的算子名稱。拿到算子名后去昇騰文檔搜“自定義算子開發(fā)”或者“算子支持列表”。如果確認(rèn)是常用算子不支持大概率是版本太老升級CANN版本就能解決。如果CANN版本已經(jīng)夠高還不支持就得考慮改模型結(jié)構(gòu)或用算子重寫。第二個(gè)經(jīng)驗(yàn)是轉(zhuǎn)換時(shí)出現(xiàn)“data format unsupported”之類的問題。這通常和模型內(nèi)部的內(nèi)存布局有關(guān)YOLO類模型導(dǎo)出ONNX時(shí)一定要用4D張量。有些中間層如果用了5D或者6D的變換ATC會報(bào)錯(cuò)。檢查方式就是打開ONNX圖找到報(bào)錯(cuò)節(jié)點(diǎn)把它前后幾層的shape打出來看看是否合理。6.3 推理輸出異常問題如果模型轉(zhuǎn)換成功、推理也不報(bào)錯(cuò)但檢測結(jié)果畫在圖上要么全是框要么沒框先別懷疑模型壞了。按下面順序排查先打印模型輸出的數(shù)值范圍。正確的原始輸出大概率是小數(shù)比如正負(fù)幾十的分布。如果你看到輸出全是0或者很小的固定值說明前處理數(shù)據(jù)有問題很大概率是AIPP的mean和var配置導(dǎo)致輸入數(shù)據(jù)分布異常。接著檢查輸入數(shù)據(jù)的通道順序YOLOv5官方訓(xùn)練時(shí)用的是RGB但OpenCV讀出來是BGR如果訓(xùn)練和推理通道順序不一致精度會嚴(yán)重下降但不會完全失效。再檢查后處理中的坐標(biāo)縮放特別是從模型輸入尺寸還原到原圖尺寸時(shí)是否存在中心點(diǎn)和寬高轉(zhuǎn)換錯(cuò)誤。6.4 昇騰生態(tài)的幾個(gè)“潛規(guī)則”最后分享幾條屬于“經(jīng)驗(yàn)層面”的東西。一是我強(qiáng)烈建議不要在生產(chǎn)環(huán)境用純Python的pyACL做高并發(fā)服務(wù)。Python的GIL和內(nèi)存管理在幾十路并發(fā)時(shí)會有額外開銷。更合理的架構(gòu)是C做推理服務(wù)通過gRPC或者共享內(nèi)存暴露給上層Python業(yè)務(wù)。當(dāng)然如果業(yè)務(wù)是批處理任務(wù)Python完全夠用。二是昇騰容器化部署時(shí)一定要在Docker里映射/dev/davinci0設(shè)備和/dev/davinci_manager同時(shí)把驅(qū)動目錄映射進(jìn)去。很多人在Docker里跑不起來不是鏡像問題而是設(shè)備節(jié)點(diǎn)沒映射。三是多看昇騰社區(qū)的“CANN商用部署”案例文檔。很多問題是社區(qū)里已經(jīng)被反復(fù)問過的不要一上來就自己盲調(diào)。善用gitee的昇騰issue區(qū)很多問題描述和解決方案比官方文檔還要細(xì)致。7. 我的個(gè)人建議與擴(kuò)展想法這次從GPU生態(tài)切到華為Atlas 300V跑YOLO整個(gè)過程給我最大的感觸是昇騰硬件本身性能完全夠用真正需要投入時(shí)間去學(xué)習(xí)和適應(yīng)的是它的軟件棧和工程習(xí)慣。如果你公司同時(shí)有GPU和Atlas的環(huán)境建議在項(xiàng)目初期就把兩條思路都跑通GPU上負(fù)責(zé)訓(xùn)練和驗(yàn)證Atlas上負(fù)責(zé)推理。因?yàn)閮烧咴谒阕又С趾湍Ｐ透袷缴洗嬖诓町愄崆氨┞秵栴}永遠(yuǎn)比臨上線前補(bǔ)救要省心。特別是AIPP配置和ATC轉(zhuǎn)換這個(gè)環(huán)節(jié)最好在訓(xùn)練完成后馬上就開始適配不要等模型訓(xùn)練好幾個(gè)月之后才開始遷移到時(shí)候你會發(fā)現(xiàn)一個(gè)算子的變化都可能讓之前能轉(zhuǎn)的OM模型變得過不了ATC。另外Atlas 300V 24G這類推理卡最大的優(yōu)勢場景其實(shí)是那些對數(shù)據(jù)安全要求較高的本地化部署。數(shù)據(jù)不出機(jī)房、推理延遲可控、功耗在幾十瓦量級放在一個(gè)普通工控機(jī)機(jī)箱里就能跑。相比之下很多項(xiàng)目為了跑一個(gè)YOLO被GPU的功耗和散熱搞得焦頭爛額換到Atlas之后整機(jī)功耗降下來一個(gè)數(shù)量級這在實(shí)際機(jī)房運(yùn)維中是實(shí)打?qū)嵉氖找妗Ｈ绻銌栁蚁乱徊竭€能在Atlas上玩什么我會說把YOLO的檢測結(jié)果接入昇騰的文檔解析或視頻結(jié)構(gòu)化工具鏈結(jié)合FFmpeg做實(shí)時(shí)推流與報(bào)警聯(lián)動做成一個(gè)完整的端到端智能檢測服務(wù)。到這一步你手上跑的就不是一個(gè)“模型部署demo”而是一套能直接交付給客戶的生產(chǎn)系統(tǒng)了。 華為Atlas 300V部署YOLO全流程：從PyTorch到OM模型遷移實(shí)戰(zhàn)
1. Atlas到底是什么為什么我用它跑YOLO先說結(jié)論華為Atlas 300V 24G確實(shí)是一塊運(yùn)算加速卡但它不是普通顯卡而是專門為AI推理設(shè)計(jì)的NPU計(jì)算卡。我之所以把YOLO檢測模型從GPU遷移到Atlas上核心原因就三個(gè)字性價(jià)比、能效比、國產(chǎn)化要求。這兩年目標(biāo)檢測需求量太大了安防巡檢、工業(yè)質(zhì)檢、園區(qū)管理、智慧交通到處都在跑YOLOv5、YOLOv8這類模型。以往大家第一反應(yīng)就是上NVIDIA的GPU比如T4、3080、A10之類的。但在實(shí)際項(xiàng)目中你早晚會遇到這么幾個(gè)問題GPU缺貨溢價(jià)、功耗和散熱限制、機(jī)柜空間緊張、以及一部分政企客戶明確要求全鏈路國產(chǎn)化。這時(shí)候Atlas 300V就是一個(gè)值得認(rèn)真評估的替代方案。Atlas 300V 24G這張卡單卡內(nèi)存24GB算力主要走昇騰自研的AI Core不是CUDA Core所以它和GPU的關(guān)系更像是“術(shù)業(yè)有專攻”——圖像渲染、通用計(jì)算它不擅長但跑卷積神經(jīng)網(wǎng)絡(luò)這種算子密集型負(fù)載尤其是低精度推理它能做到很高的吞吐同時(shí)功耗控制得比同級別GPU更好。再說說“Atlas部署YOLO”這件事本身。很多人一聽“部署”就以為是把.pt文件拷貝過去然后調(diào)個(gè)接口實(shí)際遠(yuǎn)沒這么簡單。從NVIDIA生態(tài)切到昇騰生態(tài)需要經(jīng)歷數(shù)據(jù)格式、網(wǎng)絡(luò)結(jié)構(gòu)、算子映射、圖優(yōu)化的全鏈路適配。YOLO模型本身結(jié)構(gòu)并不復(fù)雜就是卷積加殘差加檢測頭但它里面的算子種類不少加上訓(xùn)練用的PyTorch框架和昇騰推理框架的算子實(shí)現(xiàn)有差異所以部署流程里最容易出問題的地方反而不是“能不能跑”而是“怎么讓它跑得快、跑得穩(wěn)、不報(bào)算子不支持”。這篇文章我會按照我實(shí)際做過的一個(gè)項(xiàng)目來走一遍完整流程包括硬件選型、軟件棧梳理、PyTorch模型轉(zhuǎn)ONNX再轉(zhuǎn)昇騰OM格式、AscendCL推理代碼編寫、性能調(diào)優(yōu)和常見報(bào)錯(cuò)排查?？赐曛蠹词鼓闶堑谝淮谓佑|昇騰平臺也能對“Atlas上跑YOLO”這件事有一個(gè)整體可落地的認(rèn)知。2. 部署前必須搞清楚的硬件與軟件棧2.1 Atlas 300V 24G硬件定位與參數(shù)理解Atlas 300V 24G在昇騰產(chǎn)品線里屬于邊緣計(jì)算推理卡和訓(xùn)練卡比如Atlas 800T定位完全不同。它主打的是低功耗、高能效推理適合部署在邊緣服務(wù)器、工控機(jī)、智能盒子這類環(huán)境里。先糾正一個(gè)常見誤解這張卡是“運(yùn)算加速卡”沒錯(cuò)但它并不像顯卡一樣直接插上就能顯示畫面或者拿來跑CUDA程序。它需要配合昇騰的驅(qū)動和CANN工具包才能工作本質(zhì)上是“AI協(xié)處理器”所有編程模型都圍繞昇騰自己的AscendCLAscend Computing Language接口來寫。我用的這張卡具體參數(shù)大概是這樣項(xiàng)目規(guī)格說明內(nèi)存容量24GB注意這里指的是板載內(nèi)存相當(dāng)于GPU顯存的作用內(nèi)存帶寬實(shí)測在邊緣推理場景下足夠支撐多路視頻流的并發(fā)檢測推理精度主要跑INT8也支持FP16FP32性能相對弱一些接口形態(tài)PCIe標(biāo)準(zhǔn)卡支持普通x86服務(wù)器也支持鯤鵬/飛騰等ARM平臺核心架構(gòu)昇騰AI Core算力由多個(gè)AI Core集群提供為什么“24G大內(nèi)存”這么重要因?yàn)閅OLO模型本身權(quán)重不大YOLOv5s才14MB左右占內(nèi)存的主要是中間特征圖。當(dāng)你要跑批量推理比如batch設(shè)為4或8連續(xù)處理1080P視頻流時(shí)特征圖會迅速堆積。24G內(nèi)存意味著你可以把更大的batch和數(shù)據(jù)預(yù)處理管線都放在卡上不用頻繁地和CPU來回拷貝數(shù)據(jù)這對推理吞吐提升非常明顯。2.2 昇騰部署的整體軟件棧與概念梳理如果你以前只接觸過CUDA生態(tài)第一次看到昇騰這套軟件棧可能會有點(diǎn)懵。別怕我?guī)湍惆牙锩娴慕巧砬宄Ｗ畹讓邮球?qū)動和固件這一層負(fù)責(zé)讓操作系統(tǒng)識別設(shè)備相當(dāng)于GPU驅(qū)動。往上走是CANNCompute Architecture for Neural Networks它相當(dāng)于昇騰的CUDA工具包加TensorRT的結(jié)合體提供算子庫、圖編譯引擎GE、運(yùn)行時(shí)環(huán)境。再往上是各種推理框架的適配層你可以用MindSpore直接跑昇騰也可以用pyACLPython版AscendCL手寫推理代碼甚至通過ONNX Runtime昇騰版或OpenCV的dnn模塊走昇騰后端。這里有一個(gè)最容易混淆的點(diǎn)我們平時(shí)用的PyTorch模型并不能直接在Atlas上跑至少不能直接跑得像GPU上那么順。常規(guī)做法是先把PyTorch模型導(dǎo)出為ONNX再用CANN自帶的ATC工具把ONNX編譯成昇騰專屬的OM模型Offline Model最后在運(yùn)行環(huán)境里加載OM進(jìn)行推理。為什么不直接用PyTorch原生推理因?yàn)镻yTorch在昇騰上默認(rèn)走算子逐層調(diào)用圖優(yōu)化不夠深性能會打折扣。ATC會做算子融合、內(nèi)存復(fù)用、數(shù)據(jù)格式轉(zhuǎn)換等一系列優(yōu)化把整個(gè)計(jì)算圖固化下來相當(dāng)于為這張卡“量身定制”了一版模型。所以O(shè)M模型才是Atlas上真正的高效形態(tài)。另外還有一個(gè)容易踩坑的版本對齊問題。昇騰生態(tài)的版本管理相當(dāng)嚴(yán)格驅(qū)動、固件、CANN、MindSpore/ACL這幾個(gè)版本必須互相匹配否則你會看到一堆莫名其妙的報(bào)錯(cuò)。我建議什么功課都不要做直接去昇騰社區(qū)查“版本配套表”照著表上能對上的版本組合來安裝千萬別混搭新版本CANN配舊版本驅(qū)動血的教訓(xùn)。2.3 為什么用Notebook式驗(yàn)證而不是一上來就寫大工程在實(shí)際動手之前我強(qiáng)烈推薦先在一臺裝了昇騰環(huán)境的服務(wù)器上用Python交互式環(huán)境把每一步跑通而不是一上來就寫完整的推理工程。原因很簡單模型轉(zhuǎn)換、推理調(diào)用這個(gè)階段你碰到的絕大多數(shù)問題是環(huán)境問題不是代碼邏輯問題。一旦環(huán)境通了后面寫業(yè)務(wù)代碼就會非常順暢。我之前踩過最大的坑就是“一次性集成”。把模型加載、預(yù)處理、推理、后處理全寫完結(jié)果一跑也不知道是環(huán)境問題還是代碼問題排查起來特別痛苦。正確的姿勢是先用一個(gè)最簡單的ONNX模型做最小驗(yàn)證比如隨機(jī)生成一張輸入圖片能跑出結(jié)果證明“驅(qū)動CANNATCACL”這條鏈路是通的再在這個(gè)基礎(chǔ)上逐漸加入YOLO模型和后處理邏輯。這樣一來每個(gè)環(huán)節(jié)出了問題都能快速定位。3. YOLO模型遷移實(shí)戰(zhàn)從PyTorch權(quán)重到昇騰OM模型3.1 YOLO模型的選型與推理分支取舍我自己在Atlas上部署得最多的是YOLOv5和YOLOv8。就部署難度而言YOLOv5更成熟網(wǎng)上能找到的昇騰案例也更多YOLOv8的檢測頭結(jié)構(gòu)稍微不一樣但整體適配也不難。這里先說一個(gè)關(guān)鍵取舍導(dǎo)出的ONNX模型到底帶不帶后處理NMS我的建議是導(dǎo)出的時(shí)候去掉NMS只保留Backbone加Neck加Head的輸出。理由有三點(diǎn)。第一ONNX里的NMS算子在不同框架實(shí)現(xiàn)差異很大ATC轉(zhuǎn)換時(shí)比較容易出幺蛾子第二NMS的輸入張量結(jié)果是動態(tài)數(shù)量檢測框數(shù)量不確定這在靜態(tài)圖優(yōu)化比較強(qiáng)的昇騰平臺上會帶來額外復(fù)雜度第三從推理性能角度看把后處理放在CPU上或者自己用向量化計(jì)算寫反而更容易調(diào)優(yōu)也更靈活。所以你的導(dǎo)出目標(biāo)其實(shí)很純粹輸入是[1, 3, H, W]的三通道圖像輸出是YOLO檢測頭的原始預(yù)測比如YOLOv5就是一個(gè)[1, 25200, 85]的張量其中25200表示三個(gè)尺度輸出的候選框總數(shù)85表示4個(gè)框坐標(biāo)加1個(gè)目標(biāo)置信度加80個(gè)類別分?jǐn)?shù)。3.2 PyTorch模型轉(zhuǎn)ONNX的常見細(xì)節(jié)這里用一個(gè)YOLOv5s的導(dǎo)出示例來演示。你需要在訓(xùn)練好的模型上調(diào)用torch.onnx.export導(dǎo)出時(shí)有幾個(gè)參數(shù)非常關(guān)鍵。第一是opset_version我一般固定用opset_version11。太低的算子版本有些新算子不支持太高的話昇騰ATC在解析時(shí)可能出現(xiàn)未知算子。第11版是目前昇騰兼容性最好的平衡點(diǎn)。第二是dynamic_axes。如果你想在推理時(shí)自由切換不同分辨率可以把它設(shè)成動態(tài)維度。但實(shí)際上我個(gè)人建議盡量固定輸入形狀比如固定成1x3x640x640。理由很簡單動態(tài)輸入意味著ATC沒法做充分的內(nèi)存規(guī)劃和算子融合性能會有明顯折損而且動態(tài)shape處理不當(dāng)還會導(dǎo)致模型加載或推理時(shí)出現(xiàn)奇奇怪怪的報(bào)錯(cuò)。如果你確實(shí)有變分辨率需求更好的方式是保存幾個(gè)不同分辨率的OM模型推理時(shí)根據(jù)輸入尺寸切換。第三是輸出張量的順序。YOLOv5官方導(dǎo)出腳本輸出的張量形狀是[1, 25200, 85]這個(gè)信息在推理代碼里要用到所以我一般導(dǎo)完ONNX之后會寫兩行代碼驗(yàn)證一下確認(rèn)形狀符合預(yù)期import onnx model onnx.load(yolov5s.onnx) for inp in model.graph.input: print(input:, inp.name, [d.dim_value for d in inp.type.tensor_type.shape.dim]) for out in model.graph.output: print(output:, out.name, [d.dim_value for d in out.type.tensor_type.shape.dim])如果你發(fā)現(xiàn)輸出是[1, 85, 25200]這樣的排列做后處理的時(shí)候就要先轉(zhuǎn)置這個(gè)到推理代碼部分再細(xì)說。3.3 ATC模型轉(zhuǎn)換核心參數(shù)與AIPP配置拿到ONNX模型之后接下里就是用ATC工具把它編譯成OM模型。ATC命令位于CANN安裝目錄的/usr/local/Ascend/ascend-toolkit/latest/bin下通常配置好環(huán)境變量后直接在終端敲atc就能用。我的一條典型轉(zhuǎn)換命令長這樣atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_om \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --insert_op_confaipp.cfg \ --output_typeFP32逐個(gè)解釋一下這些參數(shù)--framework55代表ONNX。--soc_version這個(gè)必須填你實(shí)際芯片的型號。Atlas 300V 24G對應(yīng)的昇騰芯片當(dāng)前是Ascend310P系列的某一款具體從npu-smi info能看到。如果填錯(cuò)了轉(zhuǎn)換可能成功但加載到卡上會報(bào)版本不匹配的錯(cuò)誤。--input_shape和你導(dǎo)出的ONNX輸入保持一致。這里images是輸入節(jié)點(diǎn)的名字不能寫錯(cuò)可以用前面的Python腳本查看。--insert_op_conf這就是很多人忽略的AIPP配置。AIPP的作用是在硬件層面完成圖像預(yù)處理包括縮放、顏色空間轉(zhuǎn)換、歸一化。YOLO系列輸入通常是RGB分布到0到1之間如果你不配置AIPP就得在推理代碼里自己用CPU或DVPP做完這些操作不僅麻煩還會讓預(yù)處理成為性能瓶頸。我的AIPP配置文件大概長這樣aipp_op { aipp_mode: static input_format: RGB src_image_size_w: 640 src_image_size_h: 640 crop: true load_start_pos_h: 0 load_start_pos_w: 0 resize: true resize_output_w: 640 resize_output_h: 640 mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 min_chn_0: 255.0 min_chn_1: 255.0 min_chn_2: 255.0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }這個(gè)配置表示輸入圖像是RGB順序模型期望RGB如果模型訓(xùn)練時(shí)用的是BGR你就改成BGR。min_chn和var_reci_chn組合起來的作用就是把像素從0-255縮放到0-1。src_image_size_w/h和resize_output_w/h在模型輸入是固定尺寸時(shí)可以直接寫成模型的輸入尺寸這樣ATC轉(zhuǎn)換時(shí)會自動在圖里插入縮放算子省掉你在預(yù)處理代碼里自己寫resize的煩惱。還有一點(diǎn)值得提如果你喂給模型的圖片比例不對直接在AIPP里做resize容易讓物體形狀扭曲。通常YOLO訓(xùn)練本身足夠魯棒這一點(diǎn)影響不大。如果實(shí)在在意可以在預(yù)處理代碼里先做letterbox填充再做resize但這樣一來AIPP的自動縮放就沒法用了需要關(guān)閉AIPP的resize自己準(zhǔn)備好已經(jīng)resize到640x640的圖片數(shù)據(jù)。3.4 模型轉(zhuǎn)換環(huán)節(jié)的典型坑我在這里列幾個(gè)自己遇到過的報(bào)錯(cuò)。第一個(gè)是“unsupported op”。比如某些算子ATC不識別最常見于SiLU激活函數(shù)或者一些新版本PyTorch導(dǎo)出的自定義算子。解決辦法一般是兩個(gè)方向一是換PyTorch版本或ONNX導(dǎo)出的opset版本二是看能不能把不支持的算子改寫成等效的算子組合比如把SiLU替換成Sigmoid加乘法的組合。如果實(shí)在繞不過去可以查一下飛槳或MindSpore的算子映射表往往能找到經(jīng)驗(yàn)。第二個(gè)是“static aipp with dynamic shape failed”這類錯(cuò)誤。多半是你在--input_shape里傳了-1但又開了AIPP。AIPP在靜態(tài)模式要求輸入shape完全固定所以要么把shape改成固定的要么關(guān)掉AIPP。我上文建議固定shape就是為了和AIPP配合順暢。第三個(gè)是轉(zhuǎn)換成功但推理輸出全為0或固定值。這種情況大概率是AIPP里歸一化參數(shù)配錯(cuò)了導(dǎo)致輸入數(shù)據(jù)分布完全偏離訓(xùn)練分布。檢查一下min_chn與var_reci_chn到底在做什么以及輸入數(shù)據(jù)的格式到底是CHW還是HWC就能找到問題。4. 寫推理代碼AscendCLpyACL完整流程4.1 初始化設(shè)備與運(yùn)行上下文模型轉(zhuǎn)換完畢OM文件拿到手接下來就是寫推理程序。昇騰的CANN提供了C語言接口也提供Python包pyACL。生產(chǎn)環(huán)境最終一般用C寫高并發(fā)服務(wù)但做原型驗(yàn)證或者并發(fā)要求不高的業(yè)務(wù)Python完全夠用。整個(gè)pyACL推理程序的結(jié)構(gòu)可以看作五個(gè)階段初始化設(shè)備、加載模型、準(zhǔn)備輸入輸出、執(zhí)行推理、處理輸出。第一件事是設(shè)置環(huán)境變量和初始化設(shè)備import acl # 初始化 ret acl.init() assert ret 0 # 指定設(shè)備這里以0號卡為例 ret acl.rt.set_device(0) assert ret 0 # 創(chuàng)建運(yùn)行上下文 context, ret acl.rt.create_context(0) assert ret 0 # 創(chuàng)建推理流 stream, ret acl.rt.create_stream() assert ret 0這里的“設(shè)備”就是指Atlas 300V卡一張卡對應(yīng)一個(gè)物理設(shè)備。如果你服務(wù)器里插了多張卡可以通過環(huán)境變量或代碼指定使用哪一張。上下文和流的概念和CUDA很相似理解起來沒有障礙不過要注意在程序結(jié)束前釋放資源和銷毀流否則會有資源泄露的報(bào)錯(cuò)。4.2 加載OM模型并管理輸入輸出buffer加載模型使用acl.mdl.load_from_file它會返回一個(gè)模型ID后續(xù)所有推理操作都靠這個(gè)ID來引用模型model_id, ret acl.mdl.load_from_file(yolov5s_om.om) assert ret 0 # 獲取模型描述信息 model_desc acl.mdl.create_desc() ret acl.mdl.get_desc(model_desc, model_id)有了模型描述你可以從里面讀出模型的輸入輸出維度、數(shù)據(jù)類型、buffer大小然后根據(jù)這些信息分配Device側(cè)內(nèi)存。這一步是重點(diǎn)因?yàn)槟阍贖ost側(cè)準(zhǔn)備好的圖片數(shù)據(jù)是不能直接被模型使用的必須拷貝到Device側(cè)。通常的做法是給模型的每個(gè)輸入申請一塊Device內(nèi)存再把圖像數(shù)據(jù)顯示拷貝過去。pyACL里最常見的是先使用acl.mdl.get_input_size_by_index拿到輸入size再調(diào)用acl.rt.malloc分配內(nèi)存然后使用acl.rt.memcpy把Host數(shù)據(jù)拷貝到Device內(nèi)存。這里有一個(gè)容易繞暈的點(diǎn)輸入數(shù)據(jù)到底怎么擺放。AIPP配置成靜態(tài)模式后模型輸入節(jié)點(diǎn)期望的是已經(jīng)經(jīng)過AIPP處理的“裸數(shù)據(jù)”也就是分辨率匹配的、未歸一化的原始圖像像素。聽起來有點(diǎn)繞簡單說就是你只需要把解碼后的圖片resize到640x640并轉(zhuǎn)成RGB/BGR排好然后直接往Device內(nèi)存里扔剩下的縮放、歸一化由AIPP在硬件上完成。如果你的AIPP沒有開resize你還要自己在Host側(cè)把圖resize成640x640再拷貝。也別忘了排查圖像數(shù)據(jù)的內(nèi)存排列方式很多格式問題出在通道順序和步長上。4.3 圖像預(yù)處理細(xì)節(jié)可以不依賴opencv的部分圖像預(yù)處理在GPU部署時(shí)代往往被忽視因?yàn)镺penCV足夠方便。但在音視頻平臺或嵌入式環(huán)境里OpenCV的依賴有時(shí)候會給你帶來額外的交叉編譯成本所以我一般建議盡量把預(yù)處理職責(zé)劃分清楚圖像解碼如果是JPEG建議用昇騰的DVPP圖像解碼接口它的耗時(shí)遠(yuǎn)低于CPU端OpenCV的imdecode。DVPP是昇騰硬件上的媒體處理單元能硬解碼視頻和圖片。圖像縮放如果AIPP沒有啟用resize可以用DVPP的VPC做硬件縮放。如果AIPP啟用了resize那就直接在Host側(cè)用OpenCV或Numpy插值因?yàn)檫@一步會被AIPP替代。數(shù)據(jù)格式轉(zhuǎn)換DVPP輸出的圖像格式默認(rèn)是YUV420SP這張圖分類任務(wù)里可以直接送AIPP轉(zhuǎn)RGB但在目標(biāo)檢測中你需要把YUV數(shù)據(jù)再轉(zhuǎn)成RGB這塊頭緒比較多我建議初學(xué)階段直接用OpenCV解碼resize功能優(yōu)先性能后調(diào)。等整個(gè)鏈路跑通了再考慮用DVPP來替換瓶頸。每次踩坑都可能是內(nèi)存對齊問題。昇騰的Device內(nèi)存通常要求對齊到32字節(jié)或64字節(jié)。如果你自己構(gòu)造輸入buffer務(wù)必讓每一行數(shù)據(jù)長度對齊到16或32的倍數(shù)否則會出現(xiàn)當(dāng)你檢查數(shù)據(jù)明明是對的、但模型輸出誤差很大的情況。這也是為什么很多時(shí)候用一個(gè)現(xiàn)成的推理插件比手寫完整流程更省心的原因——很多對齊問題“前輩們”已經(jīng)替你處理過了。4.4 執(zhí)行推理帶示例代碼用pyACL執(zhí)行一次推理整體代碼如下# 創(chuàng)建輸出數(shù)據(jù)集 output_desc acl.mdl.create_dataset() output_size acl.mdl.get_output_size_by_index(model_desc, 0) # 申請輸出設(shè)備內(nèi)存 out_buffer, ret acl.rt.malloc(output_size, 2 * 1024 * 1024) assert ret 0 output_data acl.create_data_buffer(out_buffer, output_size) ret acl.mdl.add_dataset_buffer(output_desc, output_data) # 創(chuàng)建輸入數(shù)據(jù)集 input_desc acl.mdl.create_dataset() # input_buffer 是之前申請并拷貝好圖片數(shù)據(jù)的Device內(nèi)存 input_data acl.create_data_buffer(input_buffer, input_size) ret acl.mdl.add_dataset_buffer(input_desc, input_data) # 執(zhí)行推理 ret acl.mdl.execute(model_id, input_desc, output_desc) assert ret 0 # 同步等待這里可以替換成流同步 ret acl.rt.synchronize_stream(stream) assert ret 0 # 從device內(nèi)存拷貝回host內(nèi)存 out_result np.zeros(output_size, dtypenp.uint8) ret acl.rt.memcpy(out_result, output_size, out_buffer, output_size, acl.ACL_MEMCPY_DEVICE_TO_HOST) assert ret 0 # 解析輸出后面會展開這段代碼就是一個(gè)完整的推理閉環(huán)。把其中的acl.mdl.execute理解成和cudaMemcpy加cudaLaunchKernel的組合操作會有助于快速理解它為什么要區(qū)分輸入輸出數(shù)據(jù)集、為什么要專門從device拷回host。4.5 后處理YOLO輸出解碼與NMS模型輸出的原始數(shù)據(jù)通常是[1, 25200, 85]的浮點(diǎn)數(shù)組你需要將它轉(zhuǎn)換為你實(shí)際使用的檢測框。后處理的關(guān)鍵步驟為將輸出reshape成[1, 25200, 85]。通過閾值篩選目標(biāo)置信度高于置信度閾值的框。對每個(gè)類別分別執(zhí)行NMS非極大值抑制去掉重疊框。將坐標(biāo)還原到原圖尺寸尺度變換。如果你用的是YOLOv5它的輸出解碼方式是已知的框的坐標(biāo)是相對于輸出特征圖尺寸的需要乘以輸入尺寸和原尺寸的比例來還原到原圖坐標(biāo)同時(shí)要記得坐標(biāo)是cxcywh格式。YOLOv8的結(jié)構(gòu)稍微有一點(diǎn)點(diǎn)不同但現(xiàn)在主流的各種開源YOLO項(xiàng)目基本都提供了后處理參考代碼你只要把輸入從[batch, 84, 8400]改成自己的[1, 85, 25200]排列就能快速適配。這里我要特別提醒經(jīng)過ATC轉(zhuǎn)換后的OM輸出其輸出布局可能與你導(dǎo)出ONNX時(shí)觀察到的不同。ATC可能會重排輸出張量的維度導(dǎo)致你在代碼里拿到的shape不是預(yù)想的[1,25200,85]而可能是[1,85,25200,1]之類的奇怪排列。解決的辦法是在加載模型后先根據(jù)模型描述打印所有輸出的shape拿這個(gè)實(shí)際shape來寫后處理解析代碼。不要死搬ONNX里的shape這是我個(gè)人踩過最無語的一個(gè)坑。5. 工程化部署中不得不說的性能與穩(wěn)定性問題跑通單張圖片的推理只是第一步。實(shí)際項(xiàng)目中輸入往往是一條視頻流或者一個(gè)文件夾里幾千張圖這時(shí)候你要考慮的不再是“能不能跑”而是“能不能扛得住”。5.1 多路視頻流與batch推理的策略Atlas 300V 24G的優(yōu)勢之一就是能同時(shí)處理多路視頻流。但多路并非簡單地開多個(gè)線程跑多次推理更優(yōu)的方案是利用batch推理。首先YOLO模型在ATC轉(zhuǎn)換時(shí)就可以設(shè)置固定batch比如--input_shapeimages:4,3,640,640。推理時(shí)每次喂4張圖進(jìn)去讓AI Core同時(shí)處理4張圖。通常batch從1提到4吞吐量能提升2-3倍這個(gè)收益非?？捎^。但batch推理的難點(diǎn)在于你的輸入圖片必須是同一個(gè)尺寸且同時(shí)準(zhǔn)備好。對于一個(gè)單路視頻流你沒法同時(shí)拿到4幀對于多路視頻流你可以把4路視頻的當(dāng)前幀拼成一個(gè)大batch送進(jìn)去。實(shí)際工程上我會用一個(gè)緩沖隊(duì)列把多個(gè)輸入源的幀按順序排好攢夠一個(gè)batch就推理一次。如果某一幀處理時(shí)間太長就做丟幀或排隊(duì)策略保證整個(gè)系統(tǒng)的延遲可控。5.2 內(nèi)存復(fù)用與資源釋放很多人在Atlas上跑Python推理時(shí)部署一段時(shí)間后發(fā)現(xiàn)內(nèi)存越來越大最后程序崩潰。原因往往是每幀推理都重新申請Device內(nèi)存、創(chuàng)建數(shù)據(jù)緩沖卻忘了釋放。我的習(xí)慣是在初始化階段一次性申請好輸入輸出buffer推理過程中反復(fù)復(fù)用同一個(gè)buffer。只有當(dāng)輸入圖像尺寸變化時(shí)才重新分配。這樣既減少了設(shè)備側(cè)內(nèi)存分配的系統(tǒng)調(diào)用開銷也避免了內(nèi)存泄漏。對應(yīng)的釋放流程也別忘程序退出時(shí)要依次調(diào)用acl.rt.free釋放Device內(nèi)存、acl.mdl.unload卸載模型、acl.rt.destroy_stream銷毀流、acl.rt.destroy_context銷毀上下文最后acl.finalize。如果省掉這些步驟最典型的后果是多次加載/卸載模型時(shí)顯存一直被占著不釋放最終設(shè)備不可用。5.3 使用profiling工具定位性能瓶頸昇騰提供了一套性能分析工具叫msprof它會采集算子耗時(shí)、數(shù)據(jù)拷貝耗時(shí)、NPU利用率等信息。這個(gè)工具是排查性能問題的重要幫手。比如你在推理中發(fā)現(xiàn)幀率怎么都上不去不要先懷疑模型算力不夠。用msprof采一下數(shù)據(jù)你會經(jīng)?？吹竭@樣的情況NPUAI Core利用率不到50%但延遲已經(jīng)很高。這種時(shí)候瓶頸壓根不在模型推理而是數(shù)據(jù)拷貝或預(yù)處理耗時(shí)占比太大。解決辦法通常是把預(yù)處理挪到DVPP設(shè)備端去或者在Host側(cè)用多線程并發(fā)做預(yù)處理。如果是NPU利用率已經(jīng)接近100%那瓶頸確實(shí)在模型側(cè)這時(shí)候可以考慮用精度更低的INT8量化模型、減少輸入分辨率、或者換用更輕量的YOLO變體如YOLOv5n、YOLOv8s。5.4 性能數(shù)據(jù)速查表根據(jù)我的實(shí)測整理我在同型號Atlas 300V 24G上測試過幾組配置整理出來的數(shù)據(jù)可以參考模型版本輸入分辨率單幀耗時(shí)ms說明YOLOv5s640x6408-12默認(rèn)FP16推理單batchYOLOv5s640x6404-6batch4時(shí)單幀平均耗時(shí)顯著下降YOLOv8s640x64010-14模型稍大算子稍多但差距可控YOLOv5s1280x128030-40大分辨率適合小目標(biāo)檢測但耗時(shí)會漲YOLOv5s INT8量化640x6403-5INT8帶來明顯加速但需要校準(zhǔn)數(shù)據(jù)集需要說明的是這個(gè)數(shù)據(jù)受到驅(qū)動版本、CANN版本、服務(wù)器CPU性能、以及是否使用DVPP預(yù)處理等因素影響。但對于評估“Atlas到底行不行”恐怕足夠了單卡跑到接近100幀每秒的YOLOv5s處理能力在邊緣側(cè)已經(jīng)相當(dāng)實(shí)用。6. 常見問題與排查技巧實(shí)錄部署過程中遇到的報(bào)錯(cuò)千奇百怪但歸納下來無非集中在以下幾個(gè)方面我按出現(xiàn)概率排個(gè)序。6.1 環(huán)境與設(shè)備問題出現(xiàn)概率最高報(bào)錯(cuò)形如acl.rt.set_device ... run error或者[ERROR] GE( ... Failed to init device。這個(gè)基本就是驅(qū)動和固件沒配對。第一種可能是驅(qū)動沒裝好npu-smi info都看不到卡第二種可能是Ascend環(huán)境變量沒source你在終端每開一個(gè)新窗口都要記得source一遍/usr/local/Ascend/ascend-toolkit/set_env.sh否則Python里根本import不到acl模塊或者找不到運(yùn)行庫。第三種是權(quán)限問題普通用戶訪問不了設(shè)備節(jié)點(diǎn)需要把用戶加入HwHiAiUser用戶組或用root運(yùn)行。排查這個(gè)階段我的固定做法是先跑一下npu-smi info確認(rèn)設(shè)備健康然后跑一個(gè)最簡單的設(shè)備初始化腳本比如只調(diào)用acl.init()和acl.rt.set_device(0)成功后再往下走。6.2 模型轉(zhuǎn)換與算子報(bào)錯(cuò)最需要耐心已經(jīng)在3.4節(jié)講了一部分這里補(bǔ)充兩個(gè)經(jīng)驗(yàn)。第一個(gè)經(jīng)驗(yàn)是“算子不支持”的排查路徑。ATC轉(zhuǎn)換報(bào)錯(cuò)日志經(jīng)常非常長你只需要關(guān)注最后幾行里提到的算子名稱。拿到算子名后去昇騰文檔搜“自定義算子開發(fā)”或者“算子支持列表”。如果確認(rèn)是常用算子不支持大概率是版本太老升級CANN版本就能解決。如果CANN版本已經(jīng)夠高還不支持就得考慮改模型結(jié)構(gòu)或用算子重寫。第二個(gè)經(jīng)驗(yàn)是轉(zhuǎn)換時(shí)出現(xiàn)“data format unsupported”之類的問題。這通常和模型內(nèi)部的內(nèi)存布局有關(guān)YOLO類模型導(dǎo)出ONNX時(shí)一定要用4D張量。有些中間層如果用了5D或者6D的變換ATC會報(bào)錯(cuò)。檢查方式就是打開ONNX圖找到報(bào)錯(cuò)節(jié)點(diǎn)把它前后幾層的shape打出來看看是否合理。6.3 推理輸出異常問題如果模型轉(zhuǎn)換成功、推理也不報(bào)錯(cuò)但檢測結(jié)果畫在圖上要么全是框要么沒框先別懷疑模型壞了。按下面順序排查先打印模型輸出的數(shù)值范圍。正確的原始輸出大概率是小數(shù)比如正負(fù)幾十的分布。如果你看到輸出全是0或者很小的固定值說明前處理數(shù)據(jù)有問題很大概率是AIPP的mean和var配置導(dǎo)致輸入數(shù)據(jù)分布異常。接著檢查輸入數(shù)據(jù)的通道順序YOLOv5官方訓(xùn)練時(shí)用的是RGB但OpenCV讀出來是BGR如果訓(xùn)練和推理通道順序不一致精度會嚴(yán)重下降但不會完全失效。再檢查后處理中的坐標(biāo)縮放特別是從模型輸入尺寸還原到原圖尺寸時(shí)是否存在中心點(diǎn)和寬高轉(zhuǎn)換錯(cuò)誤。6.4 昇騰生態(tài)的幾個(gè)“潛規(guī)則”最后分享幾條屬于“經(jīng)驗(yàn)層面”的東西。一是我強(qiáng)烈建議不要在生產(chǎn)環(huán)境用純Python的pyACL做高并發(fā)服務(wù)。Python的GIL和內(nèi)存管理在幾十路并發(fā)時(shí)會有額外開銷。更合理的架構(gòu)是C做推理服務(wù)通過gRPC或者共享內(nèi)存暴露給上層Python業(yè)務(wù)。當(dāng)然如果業(yè)務(wù)是批處理任務(wù)Python完全夠用。二是昇騰容器化部署時(shí)一定要在Docker里映射/dev/davinci0設(shè)備和/dev/davinci_manager同時(shí)把驅(qū)動目錄映射進(jìn)去。很多人在Docker里跑不起來不是鏡像問題而是設(shè)備節(jié)點(diǎn)沒映射。三是多看昇騰社區(qū)的“CANN商用部署”案例文檔。很多問題是社區(qū)里已經(jīng)被反復(fù)問過的不要一上來就自己盲調(diào)。善用gitee的昇騰issue區(qū)很多問題描述和解決方案比官方文檔還要細(xì)致。7. 我的個(gè)人建議與擴(kuò)展想法這次從GPU生態(tài)切到華為Atlas 300V跑YOLO整個(gè)過程給我最大的感觸是昇騰硬件本身性能完全夠用真正需要投入時(shí)間去學(xué)習(xí)和適應(yīng)的是它的軟件棧和工程習(xí)慣。如果你公司同時(shí)有GPU和Atlas的環(huán)境建議在項(xiàng)目初期就把兩條思路都跑通GPU上負(fù)責(zé)訓(xùn)練和驗(yàn)證Atlas上負(fù)責(zé)推理。因?yàn)閮烧咴谒阕又С趾湍Ｐ透袷缴洗嬖诓町愄崆氨┞秵栴}永遠(yuǎn)比臨上線前補(bǔ)救要省心。特別是AIPP配置和ATC轉(zhuǎn)換這個(gè)環(huán)節(jié)最好在訓(xùn)練完成后馬上就開始適配不要等模型訓(xùn)練好幾個(gè)月之后才開始遷移到時(shí)候你會發(fā)現(xiàn)一個(gè)算子的變化都可能讓之前能轉(zhuǎn)的OM模型變得過不了ATC。另外Atlas 300V 24G這類推理卡最大的優(yōu)勢場景其實(shí)是那些對數(shù)據(jù)安全要求較高的本地化部署。數(shù)據(jù)不出機(jī)房、推理延遲可控、功耗在幾十瓦量級放在一個(gè)普通工控機(jī)機(jī)箱里就能跑。相比之下很多項(xiàng)目為了跑一個(gè)YOLO被GPU的功耗和散熱搞得焦頭爛額換到Atlas之后整機(jī)功耗降下來一個(gè)數(shù)量級這在實(shí)際機(jī)房運(yùn)維中是實(shí)打?qū)嵉氖找妗Ｈ绻銌栁蚁乱徊竭€能在Atlas上玩什么我會說把YOLO的檢測結(jié)果接入昇騰的文檔解析或視頻結(jié)構(gòu)化工具鏈結(jié)合FFmpeg做實(shí)時(shí)推流與報(bào)警聯(lián)動做成一個(gè)完整的端到端智能檢測服務(wù)。到這一步你手上跑的就不是一個(gè)“模型部署demo”而是一套能直接交付給客戶的生產(chǎn)系統(tǒng)了。