最近把手头一个目标检测项目从GPU环境迁到了昇腾Atlas平台上跑折腾了大概两周把YOLO从模型转换到NPU推理整条链路走通了。网上关于Atlas部署YOLO的资料比较零散很多细节官方文档没写透实操时踩了不少坑。这篇文章就把整个过程记录下来从Atlas 300V 24G这张卡到底是不是运算加速卡开始说起到工具链安装、模型转换、推理代码编写、性能优化和问题排查一条龙讲清楚。我用的硬件是Atlas 300V 24G推理卡配在X86服务器上使用系统是Ubuntu 20.04。目标很明确把已经训练好的YOLOv5s模型部署到这张NPU卡上实现实时流媒体画面的目标检测要求耗时控制在单帧20ms以内。整个项目做完之后我最大的感受是Atlas和GPU的玩法差异不小但只要把工具链和转换流程捋顺性能是能打的很漂亮的。1. Atlas平台与300V 24G先搞明白这张卡能干哪些活1.1 Atlas 300V 24G的核心定位与参数解读先说结论Atlas 300V 24G确实是运算加速卡但它和你在PC上见的游戏显卡完全是两回事。它是一张基于昇腾310系列处理器的AI推理加速卡主打数据中心场景下的视频分析、图像分类、目标检测等推理任务不是用来做模型训练的。这张24G版本最显眼的参数就是板载24GB内存。很多第一次接触的人会有误解以为这24GB相当于GPU的显存能塞进去一个大模型。实际定位上它更接近“给NPU用的存储空间”主要用来承载模型权重、中间特征图和多路视频流的数据缓冲。24GB对于当前主流的视觉模型YOLOv5、YOLOv8、ResNet、OpenPose这一档已经非常宽裕夸张一点说单卡并发跑多个模型都不一定会碰内存瓶颈。从算力角度看昇腾310系列处理器主打低功耗高能效比的INT8推理理论INT8算力在100~200 TOPS这个区间取决于具体型号和频率。这个数字看起来比很多GPU的FP16算力高不少但要注意计算精度的差异。INT8推理实测性能取决于模型量化质量和算子优化程度不能只看纸面TOPS这也是后面要花大量篇幅讲模型转换和算子适配的原因。另外Atlas 300V 24G是一张标准的PCIe卡接口协议是PCIe 3.0 x16理论带宽约16GB/s。整卡功耗控制在70W左右不需要额外供电接口这一点和动辄300W的GPU比起来部署成本和散热压力小得多。对于机房里有闲置PCIe插槽的服务器来说插上这张卡就是一台低功耗的AI推理节点。1.2 为什么选它而不是GPU算一笔部署账选型的时候我其实纠结过是继续用现有的T4还是换Atlas。最后让我下决心的不是芯片参数而是整体落地成本。先说采购成本。同样支持24GB存储的推理卡NVIDIA阵营的L4、T4价格都偏高而Atlas 300V 24G在同等显存规格下便宜不少尤其在意批量采购做边缘节点或机房扩容时差价非常明显。再说整机功耗。一张T4的TDP是70W看起来和Atlas差不多但GPU服务器通常还会带额外的散热、供电模块。Atlas这边单卡功耗低甚至可以用在部分商用服务器上不用改造供电线路。我实测整张卡满载时功耗一直稳定在75W以内机箱温度比之前装GPU时低了不少。还有一个很实际的因素是扩展性。一张Atlas 300V 24G被识别为独立的PCIe设备一台普通双路服务器可以插多张卡每张卡对应处理一路或几路视频流这样就能按需横向扩容不用一上来就上整台GPU服务器。我已经在测试机上同时插了两张卡互不干扰方便做多路负载均衡。当然选它也有代价。最大的代价就是软件生态不如CUDA那么顺手很多在GPU上跑得飞快的代码不能直接拿过来跑需要适配。这个内容我会在下一节详细展开大家也好评估自己手里的项目迁移成本。2. 部署YOLO前的完整准备环境、工具链与设备检查2.1 驱动、固件与CANN的版本配套关系Atlas这块的软件栈和GPU完全不同核心工具链叫CANNCompute Architecture for Neural Networks昇腾计算架构你可以把它理解为昇腾版的CUDA cuDNN。CANN包含了驱动、runtime、算子库、图编译器和推理引擎等组件版本配套非常严格乱装很容易出现设备无法识别或者ATC转换报错的问题。我的安装顺序和版本如下供参考操作系统Ubuntu 20.04.6 LTS内核5.4固件与驱动Ascend-hdk-310p-npu-firmware_8.0.0.zip Ascend-hdk-310p-npu-driver_8.0.0.zipCANN ToolkitAscend-cann-toolkit_8.0.RC1_linux-aarch64.run确认服务器是x86还是ARM下载对应版本CANN KernelsAscend-cann-kernels-310p_8.0.RC1_linux.run昇腾310P系列需要单独装kernel包安装时有个容易忽略的点必须先装固件再装驱动最后装CANN Toolkit和Kernels。如果顺序反了可能出现驱动加载成功但设备状态为“离线”的诡异现象。我第一遍就是先装了CANN再回补驱动结果npu-smi始终看不到卡全部卸载重来才正常。安装驱动的命令比较简单chmod x Ascend-hdk-310p-npu-driver_8.0.0_linux.run ./Ascend-hdk-310p-npu-driver_8.0.0_linux.run --full装完重启后用npu-smi info检查设备能看到类似下面这样的输出就说明正常------------------------------------------------------------------------------------------- | npu-smi 8.0.0 Version: 8.0.0 | ----------------------------------------------------------------------------------------- | NPU Name Health | Power HBM Temp | Bus-Id | | 0 310P OK | 45W 24G 55C | 0000:01:00.0 | -----------------------------------------------------------------------------------------注意看两个指标Health状态是不是OKHBM或板载内存是不是正确识别为24G。如果Health是“Fault”或者“Offline”多半是固件驱动版本不匹配去官网对照CANN版本兼容表重新来一遍。2.2 我建议装完先做这三步“体检”环境装好后别急着跑模型先花十几分钟做个基础检查能省掉后面一大半排查时间。第一步用npu-smi info查看设备拓扑确认PCIe链路速率是否是x16。如果显示x8或者x4虽然也能用但数据传输带宽会打折推理性能会受到影响。这种情况优先查服务器PCIe插槽是否插在了物理x16的槽位上以及BIOS里PCIe bifurcation的设置。第二步执行/usr/local/Ascend/driver/tools/upgrade-tool --device_index 0 --system_version查看固件版本是否和驱动匹配。版本不一致时后续跑ATC转换容易报“Device not ready”。第三步检查系统日志里有没有和昇腾相关的错误。用dmesg | grep -i ascend看一下正常情况只会有驱动加载成功的记录如果出现“fail to load”或者“timeout”字样需要先解决掉再继续。我每次在新机器上部署都会习惯性把这套“体检”走一遍因为Atlas的报错有时候不是直接说驱动坏了而是到推理阶段才给你一个模棱两可的“run failed”错误到时候再回头看环境就晚了。2.3 图形化辅助工具MindX Insight不是必装但建议装CANN套件里有一个叫MindX Insight的可视化工具可以查看模型转换后的算子信息、推理耗时分布、内存占用情况界面类似浏览器访问的本地服务。它虽然不是运行必需但如果你和我一样第一次接触昇腾部署强烈建议装上性能调优时能省不少力气。安装方式是在CANN安装包列表里找Ascend-mindx-insight_*.run直接执行即可。装好之后用mindxinsight --start启动浏览器打开http://localhost:8080就能看到NPU上的运行任务。后面讲到性能优化时我会展示怎么用它定位耗时瓶颈。环境准备到此为止下面进入正题把YOLO模型装进能跑起来的OM格式。3. 从PyTorch到OM模型转换的完整实操3.1 先导出ONNX别在源头上埋雷Atlas不直接吃PyTorch的.pt文件标准流程是PyTorch - ONNX - OMAscend的离线模型格式。这一步听起来简单但我在导出ONNX时踩过好几个坑源头错了后面全白搭。先把PyTorch模型转成ONNXimport torch model torch.load(yolov5s.pt, map_locationcpu)[model].float() model.eval() dummy_input torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version11, input_names[images], output_names[output], dynamic_axes{ images: {0: batch}, output: {0: batch} } )三个需要特别注意的细节第一个是opset_version。昇腾ATC对ONNX算子支持度最好的是opset 11我试过opset 13和17部分算子比如一些上采样类算子转换时容易报“Unsupport op”。如果你是用最新版PyTorch导出的ONNX默认opset可能偏高导出时显式指定成11最稳。第二个是模型结构要固定。我用的YOLOv5官方仓库代码模型里带有slice、concat等操作导出时PyTorch会自动把它们展开成标准ONNX算子这一步没什么问题。但如果你在neck部分用了自定义算子比如自定义的注意力模块或者特殊C3结构很可能会变成ONNX里不支持的“自定义类型”后面ATC要么报错要么强行转换后精度丢失。遇到这种情况唯一的办法就是把自定义模块改写成标准卷积、concat算子组合或者用onnx-simplifier简化一遍。第三个是batch维度。我建议导出时把batch从1开始并保留动态batch能力。虽然ATC转换时可以固定到某个batch大小但保留动态维度有利于后续在同一个OM模型上测试不同并发数不用反复重新转换模型。具体动态轴配置在ATC命令里再设置。导出之后用onnx.checker.check_model验证一下再用onnxsim简化一遍是常规操作能把一些冗余的reshape、transpose去掉减少ATC的转换压力。3.2 ATC转换参数详解一条命令背后的门道模型从ONNX转成OM核心工具是ATCAscend Tensor Compiler它是CANN里类似“编译器”的角色把ONNX计算图编译成NPU能高效执行的指令序列。我的ATC转换命令长这样atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --input_formatNCHW \ --insert_op_confaipp.cfg \ --precision_modeallow_fp32_to_fp16 \ --output_typeFP16逐个解释这几个参数的含义以及我是怎么定值的。--framework5表示输入模型是ONNX格式这个数值是固定的不用改。--soc_version要和你手里的芯片型号对应。我的Atlas 300V 24G内部是310P系列芯片所以填的是Ascend310P3。具体型号可以在CANN安装目录下跑npu-smi info的详细输出里查或者直接跑sloginfo -d看芯片型号。填错了ATC不会立刻报错但生成的OM在推理时可能无法加载非常坑。--input_shape定义了输入张量的形状和导出ONNX时的dummy_input一致。这里固定为1,3,640,640batch先设成1。如果想做多batch推理可以设成4,3,640,640但要注意内存占用是按batch倍数增长的。--insert_op_confaipp.cfg这个参数非常关键它告诉ATC把图像预处理算子AIPPAscend Image Preprocessing直接编译进模型里这样推理时就不需要CPU/NPU来回搬运原始图像数据了。后面我会单独讲AIPP怎么配。--precision_modeallow_fp32_to_fp16的意思是允许模型里的FP32算子转成FP16计算以换取更快的推理速度和更少的内存占用。YOLOv5s这个量级的模型FP16精度损失几乎可以忽略我实测过mAP下降在0.5%以内。整个转换过程会在终端输出很多日志看到ATC run success就说明转换成功当前目录下会生成yolov5s.om文件。如果中途报错请保持心态平和这很正常下一节我会把最高频的报错和解决方案列清楚。3.3 AIPP配置把resize和归一化交给NPUAIPP可以说是Atlas平台特别值得利用的一个特性。它让你把图像缩放、色彩空间转换、均值减除、归一化这些预处理操作全部下沉到NPU硬件上执行CPU那边只负责把原始图像数据传过去省掉的预处理耗时非常可观。我的aipp.cfg配置如下aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_h: 640 src_image_size_w: 640 crop: 1 load_start_pos_h: 0 load_start_pos_w: 0 crop_size_h: 640 crop_size_w: 640 mean: 0.0 0.0 0.0 min_chn_0: 0.0 min_chn_1: 0.0 min_chn_2: 0.0 var_reci_chn_0: 0.00392156862745098 var_reci_chn_1: 0.00392156862745098 var_reci_chn_2: 0.00392156862745098 }这里有几个要点。input_format我设成了RGB888_U8因为我的图像源是摄像头采集的BGR格式我在CPU端顺手转成了RGB。如果你在CPU端不太方便转格式也可以用BGR888_U8但要注意和模型训练时用的通道顺序一致否则推理结果会完全错乱。mean和var_reci部分对应的是YOLOv5原始仓库里归一化操作除以255。我直接在硬件里用var_reci_chn 1/255来计算这样CPU端就把图像转成RGB后直接丢给NPU不需要再做任何浮点运算。实测下来这块每帧能省2ms左右对整体20ms的延迟指标来说非常可观。有个容易忽略的点src_image_size_h和src_image_size_w要填的是输入给AIPP的图像尺寸而不是模型输入尺寸。我的图像源是1920x1080的视频流但模型输入是640x640所以我会在代码里先用OpenCV的resize把画面等比缩放到640x640直接把缩放这件事给AIPP去做配置里把src_image_size_h/w设成640就行。如果你想让AIPP直接处理1920x1080的原始帧步骤会复杂不少需要等比缩放和letterbox处理AIPP配置里也要增加padding相关的参数。就我目前的项目来说把resize放在AIPP里CPU端只保留BGR转RGB和丢图数据已经足够满足实时性的需求。这块后续如果做多路并发我可能会进一步把resize也下沉到设备端但那是另一个复杂度的工程了。4. 推理代码编写一张图走通NPU4.1 用Python ACLLite库封装推理逻辑模型转换完成后接下来是写推理代码。昇腾官方提供了Python版的ACLLite库封装了设备初始化、模型加载、推理执行等底层操作对快速开发非常友好不需要自己写C代码调ACL接口。一个最简的推理流程如下import acl import cv2 import numpy as np import acllite_utils as utils from acllite_model import AclLiteModel from acllite_image import AclLiteImage from acllite_resource import AclLiteResource # 初始化设备 acl_resource AclLiteResource() acl_resource.init() # 加载OM模型 model AclLiteModel(yolov5s.om) # 读图并做预处理BGR转RGB、resize到640x640 image cv2.imread(test.jpg) image cv2.cvtColor(image, cv2.COLOR_BGR2RGB) image cv2.resize(image, (640, 640)) input_data np.ascontiguousarray(image).astype(np.uint8) # 推理 result model.execute([input_data])代码看起来很简单但中间其实隐藏了几个容易踩坑的点。AclLiteModel.execute接收的是一个list每个元素是对应输入tensor的numpy数组。因为YOLOv5只有一个输入images所以这里就传一个元素。如果你的模型有多个输入按转换ONNX时定义的input_names顺序依次传入。输入数据的dtype、shape都要和OM模型严格一致。我之前没注意dtype默认读进来的图像是uint8没问题但如果你的输入经过了某些numpy计算变成了float32而OM模型里是uint8会直接报“input data type mismatch”。推理输出的result是一个list每个元素对应模型的一个输出tensor。YOLOv5s在导出ONNX时输出的是一个(batch, 25200, 85)张量以640x640输入为例25200是3个尺度特征图的总anchor数85是xywhobjectness80类概率但经过ATC转换后输出可能被拆成了几个子张量数量和形状取决于模型导出的具体结构。我在实操中遇到的情况是输出被展开成了3个(1, 255, 80, 80)(1, 255, 40, 40)(1, 255, 20, 20)的格式需要自己在后处理时做一定还原。这里建议在拿到模型之后先跑一次print(result)看一下输出的实际shape再写对应的后处理代码不要假设输出结构和PyTorch里完全一致。4.2 后处理YOLO输出解码与NMS后处理部分和GPU版本区别不大核心就三件事解码预测框、按置信度过滤、做NMS。但既然换到NPU推理后处理跑在CPU上也要尽量快否则整体延迟会被拖后腿。我的后处理逻辑大致如下def postprocess(outputs, conf_thres0.25, iou_thres0.45): # 将输出reshape成 (batch, anchor_count, 85) 的统一格式 # 对每个anchor计算边框坐标、置信度、类别概率 # 用np.where做置信度阈值过滤 # 对过滤后的框执行向量化NMS ...这里有一个性能关键点尽量用numpy的向量化操作替代for循环尤其是NMS部分。我第一版写了一个纯Python的for循环NMS处理一帧要花15ms比NPU推理时间还长怎么优化都跑不进20ms。后来改成用numpy数组一次性算IoU矩阵再把循环里最大IOU剔除的部分用向量化实现NMS的耗时直接降到了2ms以内。如果不想自己写也可以直接用torchvision.ops.nms但那样得把numpy数组搬回PyTorch tensor多一次数据转换开销。对于追求极致延迟的场景还是用纯numpy实现更划算。Attention这一步的耗时和你的检测框数量直接相关。视频画面里目标多的时候NMS耗时会上涨反之目标少的时候耗时很低。如果发现后处理太慢可以考虑先用一个粗糙的快速NMS过滤掉大量低分框再做精确NMS效果类似两阶段筛选。4.3 实测性能单帧延迟、吞吐量与功耗模型在Atlas 300V 24G上跑起来后我对YOLOv5s输入640x640FP16推理AIPP预处理做了几轮基准测试结果如下指标实测值说明单帧端到端延迟12~15ms包含AIPP预处理NPU推理后处理不含图像采集时间NPU推理耗时8~10ms用ACLLite内部计时器获得主要瓶颈在算子执行后处理耗时2~4ms与目标数量相关功耗45W~55W推理状态整卡功耗满载不超过75W吞吐量约70FPS纯推理batch1时的理论吞吐实际视频流处理约50FPS这个成绩我很满意了比之前用CPU跑YOLOv5s快了接近一个数量级。如果追求极致吞吐量可以把batch设成4或8用多batch推理吞吐能进一步逼近甚至超过100FPS。有一点需要提醒这些数值是在单卡、单路视频流的场景下测的。如果你要同时处理多路视频流不能简单地把单帧耗时除以路数因为内存带宽和算子执行模块会被多路请求竞争。具体能跑几路需要实测一般用卡上的24GB内存和NPU算力综合评估。5. 性能优化从够用到好用5.1 找准瓶颈先看耗时分布再动手优化之前最重要的不是瞎调而是先搞清楚时间花在哪里。我的办法是在代码里给预处理、模型推理、后处理分别打time戳统计各自的平均耗时和最大耗时。以我实测的数据为例初始版本大概是这个分布图像BGR转RGB resize3~4msNPU推理8~10ms后处理解码NMS10~15ms一眼就能看出后处理反而是最大的瓶颈。很多人跟GPU项目一样拿到卡就猛调模型侧参数完全忽略了后处理结果性能始终上不去。针对后处理优化我做了两件事。第一把所有后处理操作全部用numpy重写避免循环。第二利用AIPP把图像缩放和归一化下沉到NPU这样CPU端省下来3ms左右的预处理时间。优化后的耗时分布变成了预处理仅图像格式转换1~2msNPU推理8~10ms后处理解码NMS2~4ms整体从30ms降到了14ms左右效果非常明显。5.2 利用MindX Insight定位算子耗时CANN自带的MindX Insight可以分析OM模型在NPU上每个算子的执行耗时。进入界面后选择“模型分析”导入OM文件就可以看到整个计算图里每个算子的耗时饼图。这个工具帮了我大忙。我原本以为模型里的C3模块最耗时结果MindX Insight告诉我实际上最耗时的是Transpose和Reshape操作总共占了NPU推理耗时的30%以上。原因不难理解ONNX模型里YOLO的输出部分有大量的维度变换操作在NPU上这些算子如果没有专门优化执行效率确实不高。定位到这个问题后我尝试在导出ONNX时对输出头做一些调整把部分transpose放到GPU侧或者后处理代码里做而不是在NPU的模型计算图里执行。这块优化比较tricky因为改动输出结构会影响ATC转换需要反复试验。如果时间紧张一个相对简单的替代方案是接受这些算子的开销毕竟整体性能已经能达标没必要为了最后一个百分点过度优化。5.3 多batch并发把吞吐推上去如果你有批量处理的需求比如一次检测一个视频片段里的所有帧用多batch推理会有惊喜。ATC转换时指定batch4PI或4帧一推理总耗时相比单batch跑4次会有明显下降因为算子执行和内存访问可以复用。我的实际测试数据batch1时跑4帧的总耗时约50ms单帧12.5msbatch4时跑4帧的总耗时约32ms单帧8ms吞吐提升超过35%。如果再把多batch和AIPP配合起来预处理的开销也能平摊到每一帧上。多batch带来的问题是延迟变高了要凑齐4帧才能开始推理首帧延迟会被拉高。如果你的场景是实时视频流建议优先用batch1跑流把并发放在多路场景上如果你做的是批量离线分析batch4或8会更划算。5.4 多路视频流并发少就是多项目中我需要处理多路摄像头画面最初的做法是每一路视频流跑一个Python线程共享同一个模型实例。结果发现NPU利用率上不去有时候反而因为Python GIL和ACLLite内部锁导致整体吞吐下降。换了思路之后我改成单条推理线程 多条采集/后处理线程的结构采集线程把每帧图丢进一个队列推理线程从队列取batch并执行推理后处理线程拿推理结果做解码和NMS。这种“异步流水线”的方式让NPU始终保持忙碌实测三路1080p视频流同时检测可以达到实时效果整体CPU占用也不算高。如果你想追求极致可以尝试用C重写推理部分或者用多进程代替多线程但工程复杂度会高一个量级。对当前这个量级的项目来说Python 异步流水线已经够用了。6. 常见问题速查表与实用避坑经验6.1 高频报错对照表下面这些是我在部署和调试中真正遇到过、并且有明确解决办法的问题整理成速查表方便大家比对。现象直接原因解决方案ATC转换报错“Unsupport op”ONNX模型里含有ATC不支持的算子降低opset到11简化模型图替换自定义算子ATC转换报错“soc version mismatch”--soc_version填错用npu-smi info或CANN工具查实际芯片型号加载OM文件失败报“device not ready”驱动、固件、CANN版本不匹配按官方兼容表统一版本卸载重装推理结果全零或随机框输入图像通道顺序跟训练时不符检查BGR/RGB顺序核对均值除和归一化配置推理耗时比GPU还慢模型没量化或算子没有完全下沉开启FP16、AIPP确认后缀非CPU回退AclLiteModel.execute报数据类型错误输入numpy数组dtype或shape与OM不一致打印OM输入要求严格对齐dtype/shape多线程同时调execute报ACL错误ACLLite内部资源冲突改为单线程推理 队列异步分发6.2 我踩过的几个坑按心痛程度排序第一个坑是版本配套。我在一台ARM服务器上误装了x86版本的CANN结果驱动装完系统直接不识别设备折腾了两天才意识到是架构不对。建议大家在下载CANN时先确认好自己的服务器架构别光看“linux”字样就直接装。第二个坑是ATC的input_format和AIPP里的input_format搞混。这两个参数一个是给模型引擎看的一个是给AIPP预处理看的两者必须和你的真实数据保持一致。我第一次用模型默认的NCHW格式配置AIPP里又写了NHWC结果推理出来的结果完全错乱全是乱框。第三个坑是后处理耗时。很多人第一次跑通NPU推理后发现整个程序还是慢得离谱第一反应是“NPU不行”。实际上很可能是后处理代码写得太拉了Python循环一层套一层时间全耗在CPU上。把这个优化好性能立刻上一个台阶。第四个坑是思维定式我一直拿GPU那套“数据从CPU到GPU再拷回去”的思路来理解NPU结果发现Atlas的AHB/NPU内存体系和CUDA有很大区别建议新人先读一下昇腾的“内存管理”文档再动手能少走很多弯路。6.3 几个随时用得上的实用技巧最后分享几个实际操作中摸索出来的小技巧不写在官方文档里但非常实用。推理代码里可以启用CANN的profiling功能给推理流程加环境变量ASCEND_GLOBAL_LOG_LEVEL1和ASCEND_SLOG_PRINT_TO_STDOUT1这样在跑程序时就能看到每个算子的耗时、设备利用率等信息对定位问题非常有帮助。上线前记得把这些关掉否则日志会指数级增长严重影响性能。如果需要反复加载同一个OM文件做性能测试建议一次性加载到内存里并复用不要每帧都重新读取文件。ACLLite的AclLiteModel在实例化时就会加载模型这个操作很耗时有差不多几百毫秒所以务必只加载一次后面全部复用同一个对象。AIPP的crop和padding参数针对“输入图像不规整”的情况有奇效。如果你的图像源是16:9的视频帧而模型输入是1:1与其在CPU端用OpenCV做letterbox不如把letterbox放到AIPP里做CPU省下来的时间很可观。这个方案我还没有完全落地但已经验证了可行性等完善了再单独写一篇分享。最后建议把OM文件和aipp.cfg一起备份到代码仓库里。模型转一次OM不容易中间可能有版本依赖万一以后环境重装没有备份就要重新折腾一遍。我吃过这个亏现在每个模型目录下都会留存一份转换脚本和对应配置。整个项目下来我对Atlas平台从陌生到顺手最大的体会是这类NPU产品的硬件算力本身不是短板真正决定项目成败的是你对工具链和部署细节的熟悉程度。把ATC、AIPP和内存管理这几块吃透YOLO部署在Atlas上完全能达到商用标准。如果正在读这篇文章的你也在折腾昇腾部署希望这份实操记录能帮你少踩几个坑。
