1. Atlas 300V 24G的真實定位它是一張推理卡不是訓(xùn)練卡最近在群里看到好幾個朋友在問同一個問題“Atlas 300V 24G是運算加速卡嗎”還有人直接拿它對標(biāo)GPU跑訓(xùn)練問能不能用來部署YOLO。這個問題其實問到了很多剛接觸昇騰硬件的人最容易搞混的點上——Atlas 300V確實是一張AI加速卡但它和大眾認知里的“顯卡”完全是兩個物種。先給出結(jié)論Atlas 300V 24G是一張AI推理加速卡它的設(shè)計目標(biāo)是把已經(jīng)訓(xùn)練好的模型比如YOLO目標(biāo)檢測模型高效地跑起來而不是用來從零訓(xùn)練大模型。它的“24G”是板載內(nèi)存用來存放模型權(quán)重和中間特征圖和游戲卡、訓(xùn)練卡上的大顯存不是一個概念也不能直接拿GPU那套思維去理解。1.1 一張卡帶24G內(nèi)存為什么不能當(dāng)訓(xùn)練卡用Atlas 300V的硬件形態(tài)是PCIe插卡單槽或雙槽被動散熱功耗很低TDP大概在70W到150W這個區(qū)間。它上面的芯片是昇騰310P系列內(nèi)部包含了AI Core陣列、向量計算單元、Cube計算單元等專門為推理計算做了大量優(yōu)化。那為什么有人會覺得它能訓(xùn)練因為24G容量聽起來很大。實際上訓(xùn)練任務(wù)的特點是前向傳播算一遍反向傳播再算一遍梯度要回傳權(quán)重要更新整個過程中的中間狀態(tài)非常多對算力的精度要求也高通常需要FP16、BF16甚至FP32的完整精度。推理任務(wù)則簡單得多——模型參數(shù)固定只需一次前向推理而且可以接受INT8、FP16這種降低精度的方式換取速度。Atlas 300V在設(shè)計上就把“訓(xùn)練能力”砍掉了它不能像GPU那樣通過通用計算框架跑Pytorch/TensorFlow的訓(xùn)練流程Ascend平臺上跑訓(xùn)練是另一個產(chǎn)品線Atlas 800/900系列訓(xùn)練服務(wù)器。但這不妨礙它在推理場景里非常能打尤其是批量部署YOLO做邊緣檢測時單卡功耗低、密度高、性價比好一個2U服務(wù)器插四五張卡都毫無壓力。1.2 推理卡和訓(xùn)練卡的核心差距在哪里做個對比就清楚了維度Atlas 300V推理卡訓(xùn)練卡如GPU A100等核心定位固定模型的前向推理模型訓(xùn)練與迭代精度支持INT8/FP16為主部分FP32FP32/BF16/FP16等全精度編程方式AscendCL/CANN調(diào)用固定算子CUDA等通用編程模型內(nèi)存使用存權(quán)重中間激活無需梯度需存儲梯度、優(yōu)化器狀態(tài)適用場景視頻流分析、邊緣盒子、服務(wù)端推理訓(xùn)練集群、精調(diào)、基礎(chǔ)模型研發(fā)功耗與密度低功耗多卡密集部署高功耗數(shù)據(jù)機房專用所以如果你要做的是“把訓(xùn)練好的YOLO模型部署到幾十路攝像頭視頻流里做實時檢測”Atlas 300V是特別合適的選型。如果你想讓它跑Pytorch的分布式訓(xùn)練那方向就完全錯了。2. 在Atlas上裝好跑YOLO的軟件棧光版本匹配就能勸退一半人確定了硬件選型之后第二步就是搭建軟件環(huán)境。這一步是最容易被低估的坑。在GPU上裝Pytorchcuda版本對不上頂多編譯報個錯網(wǎng)上到處是解決方案。但在昇騰平臺上驅(qū)動、固件、CANN工具包、AI框架適配層任何一個環(huán)節(jié)版本不匹配整套環(huán)境都會出現(xiàn)各種離奇問題而且報錯信息往往很不友好。2.1 驅(qū)動、固件與CANN工具包的版本對齊Atlas 300V跑推理依賴三個關(guān)鍵組件NPU驅(qū)動Ascend HDK Driver操作系統(tǒng)和硬件之間的橋梁負責(zé)把計算任務(wù)加載到NPU上。固件Firmware芯片內(nèi)部的微碼和控制系統(tǒng)驅(qū)動通過它控制硬件行為。CANN工具包昇騰的計算架構(gòu)包含算子庫、圖編譯引擎GE、運行時AscendCL Runtime、模型轉(zhuǎn)換工具ATC等可以理解為昇騰的“CUDA cuDNN”。這三者之間有嚴格的配套關(guān)系。以CANN 6.3為例它對應(yīng)的驅(qū)動固件版本區(qū)間是特定的安裝之前一定要去昇騰社區(qū)查看版本配套表不要憑感覺裝。我見過有人把CANN 5.1的驅(qū)動配CANN 6.0的toolkit結(jié)果模型轉(zhuǎn)換時算子報不支持排查了兩天最后發(fā)現(xiàn)是版本混搭。在CANN 6.x版本中推薦直接用Ascend-cann-toolkit_6.3.x_linux-aarch64.run或者x86_64版本根據(jù)你的服務(wù)器CPU架構(gòu)選擇安裝步驟一般是這樣# 1. 安裝驅(qū)動以310P為例具體包名以官網(wǎng)下載為準(zhǔn) ./Ascend-hdk-310P3-npu-driver_6.3.0_linux-aarch64.run --full # 2. 安裝固件 ./Ascend-hdk-310P3-npu-firmware_6.3.0_linux-aarch64.run --full # 3. 安裝CANN工具包 ./Ascend-cann-toolkit_6.3.0_linux-aarch64.run --install # 4. 設(shè)置環(huán)境變量 source /usr/local/Ascend/ascend-toolkit/set_env.sh注意驅(qū)動和固件的安裝順序不能反必須先驅(qū)動后固件。安裝完成后執(zhí)行npu-smi info如果能看到卡的信息和顯存容量說明底層已經(jīng)通了。2.2 推薦的一鍵化容器部署方案如果是生產(chǎn)環(huán)境我更推薦直接用容器鏡像。昇騰社區(qū)提供了帶CANN環(huán)境的鏡像ascendhub上有官方鏡像配合Ascend Docker Runtime可以在容器里直接使用NPU設(shè)備好處是環(huán)境隔離、版本可控、遷移方便。# 安裝Ascend Docker Runtime以x86為例 wget https://ascend-repo.obs.cn-east-2.myhuaweicloud.com/AscendDockerRuntime/6.3.0/ascend-docker-runtime_6.3.0_linux-x86_64.run ./ascend-docker-runtime_6.3.0_linux-x86_64.run --full # 啟動容器掛載NPU設(shè)備 docker run -it --device/dev/davinci0 \ --device/dev/davinci_manager \ -v /usr/local/Ascend/driver:/usr/local/Ascend/driver \ -v /usr/local/dcmi:/usr/local/dcmi \ -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \ ascendhub.huawei.com/public/ascend-cann-toolkit:6.3.0 bash在容器里執(zhí)行npu-smi info能看到設(shè)備說明文檔上的跑通YOLO環(huán)境已經(jīng)就緒。用容器還有一個額外好處以后升級CANN不用重裝系統(tǒng)包直接拉新鏡像就行。2.3 環(huán)境檢查清單跑YOLO之前先跑通npu-smi在真正開始部署模型之前花十分鐘做一次全面體檢能省掉后面大量排錯時間。我是這樣檢查的# 1. 查看卡的狀態(tài)、芯片型號、溫度、利用率 npu-smi info # 2. 查看CANN版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg # 3. 檢查Python環(huán)境是否能導(dǎo)入CANN模塊 python3 -c import acl; print(acl ok) # 4. 檢查模型轉(zhuǎn)換工具 which atc如果這些都能通過環(huán)境基本就沒問題了。這個清單也建議固化下來團隊里新同事入職后先在Atlas上把環(huán)境跑通再談業(yè)務(wù)邏輯。3. YOLO模型轉(zhuǎn)換鏈路從PyTorch到OMATC參數(shù)背后的門道環(huán)境準(zhǔn)備好之后核心工作就是把YOLO模型轉(zhuǎn)換成昇騰推理引擎能識別的格式。昇騰平臺不能直接加載Pytorch的.pt文件或ONNX文件必須通過ATC工具做一次離線編譯生成OM模型Offline Model。很多人在這一步犯了難其實整個過程可以拆成三步導(dǎo)出ONNX - 配置AIPP - ATC轉(zhuǎn)換。每一步都有講究如果直接把網(wǎng)上下載的.pt文件扔給ATC大概率會失敗。3.1 先把PyTorch模型導(dǎo)出成合規(guī)的ONNXYOLO系列的導(dǎo)出邏輯大同小異。以YOLOv8為例# 導(dǎo)出ONNX模型 from ultralytics import YOLO model YOLO(yolov8n.pt) model.export(formatonnx, opset11, imgsz640, dynamicFalse)導(dǎo)出時幾個參數(shù)要注意opset版本建議11或更高ATC對ONNX的算子支持是以opset為基準(zhǔn)的太低可能有算子表達不出來太高反而容易觸發(fā)ATC不支持的新算子。實測下來opset11最穩(wěn)。dynamicFalse第一次轉(zhuǎn)換建議固定輸入尺寸比如1x3x640x640把動態(tài)shape問題留到后面優(yōu)化階段再處理。上來就動態(tài)shapeATC的編譯時間會變長出錯時排查也麻煩。imgsz640YOLO系列默認輸入640x640如果你的業(yè)務(wù)圖片分辨率差別很大可以考慮368、416這種更小的尺寸換取速度這個在ATC轉(zhuǎn)換時也要保持一致。導(dǎo)出完成后可以用python3 -c import onnx; onnx.checker.check_model(onnx.load(yolov8n.onnx))驗證一下模型結(jié)構(gòu)是否正常。3.2 ATC轉(zhuǎn)換的核心參數(shù)怎么填A(yù)TC命令看起來簡單但參數(shù)填錯了會踩大坑。一個常見的YOLOv8轉(zhuǎn)換命令大概是這樣的atc --modelyolov8n.onnx \ --framework5 \ --outputyolov8n_bs1 \ --input_formatNCHW \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP16幾個參數(shù)逐個說明--framework5固定寫法表示輸入模型是ONNX格式。--soc_version芯片型號Atlas 300V對應(yīng)的就是Ascend310P3。不知道具體型號時用npu-smi info查看芯片名稱再填。--input_shape必須和導(dǎo)出ONNX時的輸入名和shape完全一致。YOLOv8的輸入名通常是imagesYOLOv5可能是images但舊版YOLOv3可能是input。不確認時用onnx.load()打印節(jié)點信息即可。--output_typeFP16推理時用FP16計算速度和精度平衡最好。如果追求極致速度可以選INT8但INT8需要量化校準(zhǔn)數(shù)據(jù)集后面單獨說。3.3 AIPP圖像預(yù)處理的下沉AIPPAI Preprocessing是昇騰特有的圖像預(yù)處理模塊它能把圖片的縮放、減均值、除標(biāo)準(zhǔn)差、色序轉(zhuǎn)換這些操作直接下沉到硬件上CPU端只需要把原始圖片數(shù)據(jù)丟給NPU就行。這一步對端到端性能的提升非常明顯尤其是在視頻流場景下CPU要同時處理多路解碼省出來的算力能直接提高整機吞吐。YOLO系列的AIPP配置常見是這樣# aipp.cfg aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 crop: false csc_switch: true csc_matrix_r2c: 256 0 359 0 csc_matrix_g2c: 256 -88 -183 128 csc_matrix_b2c: 256 454 0 128 rbuv_swap_switch: false min_chn_0: 0 max_chn_0: 255 min_chn_1: 0 max_chn_1: 255 min_chn_2: 0 max_chn_2: 255 mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 }這套配置做的是把RGB888_U8輸入不做crop只做色序轉(zhuǎn)換和歸一化。但注意YOLO的預(yù)處理不只是減均值除標(biāo)準(zhǔn)差還包括letterbox縮放——也就是把原圖等比縮放到640x640剩余區(qū)域填灰色。AIPP本身不做等比縮放所以你在推理代碼里要先完成letterbox把處理后的640x640圖片喂給NPUAIPP只負責(zé)像素層面的歸一化和色序轉(zhuǎn)換。如果想更激進一點把letterbox也盡量簡化可以固定輸入尺寸為32的倍數(shù)YOLO下采樣是32并且設(shè)crop: true加上src_image_size_w/h配合使用我在實踐中發(fā)現(xiàn)直接用代碼做letterbox更靈活因為上游圖片的寬高比變化不定純依賴硬件裁剪容易變形。轉(zhuǎn)換成功后會生成yolov8n_bs1.om文件用atc生成的OM模型是可以直接用AscendCL加載推理的。如果這一步報算子不支持通常是CANN版本對應(yīng)的算子庫不夠新升級CANN版本或者改ONNX導(dǎo)出時的算子表達方式比如把SiLU換成ReLU可以解決。4. 用AscendCL把YOLO跑起來推理代碼骨架與數(shù)據(jù)流模型轉(zhuǎn)好了接下來就是寫推理代碼。昇騰推理最常用的接口是AscendCLACL它分為C API和Python API兩套。工程上追求性能用C快速驗證原型用Python。4.1 AscendCL推理的五步骨架一個最小可運行的YOLO推理程序代碼流程非常固定搞清楚這五步就掌握了核心邏輯import acl import numpy as np # 1. 初始化與設(shè)備綁定 ret acl.init() ret acl.rt.set_device(0) ret, context acl.rt.create_context(0) # 2. 加載OM模型 ret, model_id acl.mdl.load_from_file(yolov8n_bs1.om) # 3. 準(zhǔn)備輸入輸出內(nèi)存 input_size 1 * 3 * 640 * 640 * 4 # FP16占2字節(jié)這里用FP32示例為4字節(jié) ret, input_ptr acl.rt.malloc(input_size, 2) output_size 1 * 84 * 8400 * 4 # YOLOv8輸出維度視轉(zhuǎn)換時輸出節(jié)點而定 ret, output_ptr acl.rt.malloc(output_size, 2) # 4. 推理 input_data np.random.randn(1, 3, 640, 640).astype(np.float32) ret acl.rt.memcpy(input_ptr, input_size, input_data.tobytes(), input_size, acl.ACL_MEMCPY_HOST_TO_DEVICE) ret acl.mdl.execute(model_id, [input_ptr], [input_size], [output_ptr], [output_size]) # 5. 取回結(jié)果并釋放資源 output_data np.zeros(output_size, dtypenp.uint8) ret acl.rt.memcpy(output_data.tobytes(), output_size, output_ptr, output_size, acl.ACL_MEMCPY_DEVICE_TO_HOST) acl.mdl.unload(model_id) acl.rt.free(input_ptr) acl.rt.free(output_ptr) acl.rt.destroy_context(context) acl.rt.reset_device(0) acl.finalize()這個骨架對于所有基于OM的推理都適用只是輸入輸出的張量形狀和含義不同。注意幾個容易出錯的地方輸入輸出內(nèi)存要用acl.rt.malloc分配在Device側(cè)不是普通的內(nèi)存分配。數(shù)據(jù)進NPU之前必須顯式做H2D拷貝Host to Device結(jié)果取回要D2H。acl.rt.malloc的第二個參數(shù)是內(nèi)存對齊字節(jié)數(shù)通常傳22字節(jié)對齊或3232字節(jié)對齊AIPP配置有特殊要求時按需調(diào)整。YOLOv8的輸出是一個大張量1x84x840084 4個坐標(biāo) 80個類別分數(shù)8400 640/8平方 640/16平方 640/32平方也就是三個檢測頭的總anchor數(shù)。這個數(shù)字在YOLOv5里是25200換模型時一定要重新算輸出大小否則buffer不夠會直接報錯。4.2 數(shù)據(jù)從圖片到結(jié)果的完整流轉(zhuǎn)拿到OM模型的輸出之后不能直接用np.argmax出結(jié)果YOLO的后處理鏈路是輸出張量 - 置信度過濾 - 坐標(biāo)解碼 - NMS - 映射回原圖坐標(biāo)。以YOLOv8為例子從輸出張量里解析出所有框的代碼大致是這樣def postprocess(output_data, conf_thres0.5, iou_thres0.45, orig_shape(1080, 1920)): output_data output_data.reshape(1, 84, 8400) preds np.transpose(output_data[0], (1, 0)) # 變成 [8400, 84] boxes preds[:, :4] class_scores preds[:, 4:] scores, class_ids np.max(class_scores, axis1), np.argmax(class_scores, axis1) # 置信度過濾 mask scores conf_thres boxes boxes[mask] scores scores[mask] class_ids class_ids[mask] # 坐標(biāo)解碼YOLOv8的輸出是中心點xywh轉(zhuǎn)換成xyxy x_center, y_center, w, h boxes.T x1 x_center - w / 2 y1 y_center - h / 2 x2 x_center w / 2 y2 y_center h / 2 boxes np.stack([x1, y1, x2, y2], axis1) # 按類別分別做NMS final_boxes, final_scores, final_cls [], [], [] for cls in np.unique(class_ids): idx class_ids cls keep nms(boxes[idx], scores[idx], iou_thres) final_boxes.append(boxes[idx][keep]) final_scores.append(scores[idx][keep]) final_cls.append(np.full(keep.sum(), cls)) return np.vstack(final_boxes), np.hstack(final_scores), np.hstack(final_cls)NMS可以用opencv的cv2.dnn.NMSBoxes直接做但注意它的輸入格式是像素坐標(biāo)不是歸一化坐標(biāo)。如果遇到numpy和opencv版本的問題自己手寫一個基于IoU的NMS也就三十行左右的事。坐標(biāo)解出來之后要把640x640的預(yù)測坐標(biāo)映射回原始圖片。因為前面做了letterbox所以映射要反向操作# 假設(shè)原圖是w_orig x h_origletterbox后變成640x640 scale min(640 / w_orig, 640 / h_orig) # 對應(yīng)的縮放和偏移需要記錄推理時按比例縮放回去4.3 后處理放CPU還是NPU這是一個很多人問的問題。后處理conf過濾、NMS在CPU上跑還是用NPU跑我的觀點是先用CPU跑等整個鏈路通了再考慮優(yōu)化。原因有三點后處理邏輯復(fù)雜包含大量判斷和循環(huán)這類邏輯密集型的操作在CPU上用Python寫最順手調(diào)試也方便。YOLOv8n這種小模型單幀推理只需要幾毫秒后處理用CPU也就在1ms左右對整體延遲影響不大。只有當(dāng)模型變?yōu)閅OLOv8m以上、檢測頭輸出量大增時CPU后處理才會成為瓶頸。昇騰平臺上也有后處理的加速方案比如使用ACL的RT推理模塊或者轉(zhuǎn)成自定義算子但工程復(fù)雜度高收益相對有限。先把整條鏈路跑通再根據(jù)性能profile結(jié)果決定要不要把后處理下沉到NPU這才是務(wù)實的路線。5. 推理性能調(diào)優(yōu)與邊緣場景落地不止是“能跑”還得“跑得穩(wěn)”在Atlas 300V上把YOLO跑起來只是完成了60%的工作。真正考驗功力的是性能調(diào)優(yōu)讓它在多路視頻流、7x24小時運行的生產(chǎn)場景下穩(wěn)如磐石。5.1 用batch和stream把吞吐拉滿Atlas 300V的算力非常依賴batch size。單張圖一幀一幀推帶寬利用率很低一次性把4張甚至8張圖拼成一個batchAI Core的利用率能明顯提高。# 轉(zhuǎn)換模型時直接支持動態(tài)batch atc --modelyolov8n.onnx --framework5 --outputyolov8n_dyn \ --input_formatNCHW \ --input_shapeimages:-1,3,640,640 \ --dynamic_batch_size1,2,4,8 \ --soc_versionAscend310P3代碼側(cè)推理時先累積到batch_size4再一起送吞吐提升非?？捎^。我實測過固定batch1時YOLOv8n單卡大約70幀batch4時能拉到180幀左右具體數(shù)值取決于圖片內(nèi)容和模型變體這就是硬件和軟件協(xié)同調(diào)優(yōu)的價值。另外昇騰的推理執(zhí)行是異步的用的是stream機制?？梢园杨A(yù)處理、H2D拷貝、模型執(zhí)行、D2H拷貝放到不同的stream里CPU在等NPU執(zhí)行的時候同時處理下一批圖像工業(yè)流水線一樣把氣泡消除掉。5.2 時延敏感場景的調(diào)優(yōu)策略如果應(yīng)用場景是自動駕駛、工業(yè)質(zhì)檢這類對單幀時延非常敏感的要求50ms以內(nèi)出結(jié)果策略要反過來關(guān)閉動態(tài)batch固定batch1避免等待湊batch的時間?？紤]模型小型化YOLOv8n - YOLOv8s - YOLOv8m 延遲遞增根據(jù)業(yè)務(wù)精度要求選擇合適檔位。輸入尺寸降低從640降到416或320檢測頭輸出會減少45%~75%后處理耗時直線下降精度損失在部分場景下可以接受。使用FP16如果不是必須INT8FP16的精度損失極小但轉(zhuǎn)換時間快穩(wěn)定性好。5.3 INT8量化追求極致性能時的殺手锏當(dāng)batch4、FP16已經(jīng)不能滿足吞吐要求時可以考慮INT8量化。昇騰提供了AMCT工具做模型的量化校準(zhǔn)流程大概是準(zhǔn)備一個校準(zhǔn)數(shù)據(jù)集通常是訓(xùn)練集采樣幾百張圖。用AMCT對ONNX模型做校準(zhǔn)和量化生成量化后的模型。再走ATC轉(zhuǎn)成OM。INT8的性能相比FP16還能再翻一倍但要注意量化后模型的精度可能會掉1~3個百分點。建議先做小批量測試評估目標(biāo)檢測的mAP變化再決定是否接受。6. 我在Atlas 300V上踩過的坑以及給你避雷的檢查清單最后這部分把我實際部署YOLO過程中踩過的一些坑集中梳理一下。這些坑都很有代表性如果不注意大概率你也會遇到。6.1 版本不匹配的坑換了CANN版本后模型都跑不了我踩過最嚴重的坑就是CANN升級。原來用5.1版本寫的推理代碼一切正常。后來因為要支持新的算子升級到6.0結(jié)果發(fā)現(xiàn)原來能加載的OM模型直接報E10020和E10015錯誤定位半天才知道CANN 6.0的OM模型格式和算子調(diào)度方式變了之前轉(zhuǎn)的OM模型必須重新用新版本的ATC跑一遍代碼里的ACL接口也有少量不兼容。這里的經(jīng)驗是升級前先仔細看版本配套表和Release Notes遷移路徑要當(dāng)成一個小項目來做不能一把梭。6.2 內(nèi)存對齊問題AIPP模式下buffer分配不齊就報錯用AIPP做預(yù)處理時輸入圖片寬高必須滿足對齊要求。有的版本要求寬度為16的倍數(shù)有的要求專門的channel對齊。如果你傳了一張1080P的圖letterbox后是640x640一般沒問題。但如果你直接傳原圖并讓AIPP做crop原圖的寬度不是16倍數(shù)就會報錯。解決方案就是嚴格走letterbox流程保證送入NPU的圖片寬高都是模型要求的倍數(shù)。6.3 動態(tài)shape帶來的轉(zhuǎn)換失敗有段時間我圖省事把模型的動態(tài)軸開得很隨意--dynamic_dims1,2,4,8之類的配置隨手填。結(jié)果ATC編譯時報錯提示“input dims out of range”之類的信息查了很長時間才明白動態(tài)維度的范圍不是隨便寫的它和模型內(nèi)部的某些reshape、transpose算子的推導(dǎo)有關(guān)。后來我的策略變了先用固定shape把業(yè)務(wù)跑通再根據(jù)實際需求謹慎地引入動態(tài)維度。如果動態(tài)batch夠用就只動batch維度不要輕易動H/W維度因為動態(tài)H/W在ATC里的支持程度依賴具體算子的實現(xiàn)。6.4 檢查清單部署前必查項項目檢查內(nèi)容遇到問題時的對策卡狀態(tài)npu-smi info顯示正常溫度不超80°C散熱、外部供電、PCIe插槽檢查版本配套driver/firmware/CANN三件套版本匹配去昇騰社區(qū)查官方配套表ONNX合理性算子是否都能被ATC支持換opset、替換不支持的激活函數(shù)輸入輸出維度模型輸入與推理代碼、AIPP配置一致打印模型輸入輸出節(jié)點信息核對內(nèi)存管理device側(cè)buffer是否釋放、是否有泄漏內(nèi)存持續(xù)增長時查會不會忘了free多路并發(fā)多線程調(diào)用model時是否互斥一個context一個線程避免共用model同時執(zhí)行精度驗證轉(zhuǎn)OM后的輸出和原始PyTorch輸出對比打開ATC的--debug參數(shù)查看各層輸出差異最后再分享一個實際心得Atlas 300V這臺卡給我的最大感覺是它不“挑”模型但特別“挑”流程。只要你能把環(huán)境版本對齊、模型轉(zhuǎn)換參數(shù)處理好、推理代碼的數(shù)據(jù)流理順?biāo)躖OLO的穩(wěn)定性是相當(dāng)讓人放心的。我這邊有一路視頻流跑七天七夜沒動過npu-smi info看利用率一直穩(wěn)定沒有掉鏈子的情況。如果你正在評估昇騰平臺做目標(biāo)檢測部署Atlas 300V 24G這個配置在單卡多路4-8路1080P實時檢測的邊緣服務(wù)器場景里性價比是很有競爭力的。