去年年底搞了个边缘检测项目甲方点名要用国产AI加速卡最后落到手里的就是一张Atlas 300V 24G。刚拿到卡的时候团队里还有人问“这玩意是运算加速卡吗”毕竟以前大家只熟NVIDIA的卡。实话说这块卡确实是昇腾系列的推理加速卡而且用它部署YOLO流程和坑都不少但摸顺了之后性能是真的能打。这篇就把我从装驱动、转模型到调优的完整过程掰开揉碎了讲项目里要用Atlas跑YOLO的可以直接照抄。先说结论Atlas 300V 24G是运算加速卡属于昇腾AI处理器的推理产品线定位是边缘侧和数据中心的视频分析、目标检测推理场景。它跟训练卡最大的区别在于你不能直接拿它去微调YOLO而是要把训练好的模型转换成昇腾的OM格式再通过ACL或MindX SDK去调用算力推理。整个部署链路比你想象的要长但每一步都有章可循。1. 先搞清楚Atlas 300V 24G到底是什么卡1.1 定位与硬件参数Atlas 300V 24G是华为昇腾系列的推理加速卡专门做神经网络推理。它用的是昇腾310P芯片Atlas 300V Pro是310P3内部集成了AI Core、CPU Core、DVPP视频预处理模块等。这个芯片的核心是达芬奇架构提供的算力以INT8为主这一点和NVIDIA的T4有点像但不完全一样。我拿到的是Atlas 300V Pro 24G版本几个关键参数我列一下算力INT8精度下约140 TOPSFP16约70 TFLOPS左右不同型号有差异以官方规格为准显存24GB LPDDR4X带宽约204GB/s位宽512bit功耗单卡典型功耗72W无外接供电PCIe插槽取电接口PCIe 4.0 x16半高半长单槽卡支持的精度INT8、FP16、FP32FP32性能较低主要用于精度校验这里有个容易误判的点24GB显存听着很大好像能装下不少模型。但LPDDR4X的带宽和GDDR6/HBM完全不是一个级别204GB/s带宽跑大batch或高分辨率输入时瓶颈很容易卡在显存带宽上。实际部署YOLO模型时24GB的优势是能同时加载多个模型实例或者跑很大的batch而不是单张卡算力有多猛。1.2 昇腾软件栈换个赛道规则不一样很多人拿到Atlas卡第一步就懵了因为习惯了CUDA那一套拿到昇腾卡后不知道该装什么。昇腾的软件栈分几层驱动固件层Ascend HDK包括NPU驱动和固件装好后用npu-smi info能看到卡的状态CANN工具链核心软件包包含算子库、图编译引擎ATC、运行时ACL runtime、推理应用开发库MindX SDK面向行业的应用开发套件封装了推理流水线不想写底层ACL代码的话可以直接用上层框架插件比如PyTorch Adapter让PyTorch模型能跑到昇腾上所以整个部署路径和CUDA生态完全不同PyTorch模型在GPU上直接跑但在Atlas上你要把PyTorch模型导出成ONNX再用ATC工具转成OM格式最后通过ACL接口或MindX SDK加载OM做推理。这个转换链路就是Atlas部署YOLO最核心也最容易踩坑的地方。我的建议是先不要想着什么都要自动化老老实实走一遍PYtorch→ONNX→OM的手动流程把每个环节搞明白后面再考虑端到端的工具链。2. 环境搭建从裸机到能跑模型2.1 硬件安装与驱动固件安装Atlas 300V物理上很简单插到PCIe x16槽里不需要外接供电。但有几个细节要注意服务器BIOS里要开启4G解码和SR-IOV如果要做虚拟化否则BIOS可能识别不到卡PCIe链路要跑在Gen4 x16如果插在x8槽上性能会打折多卡时要注意CPU的PCIe lane分配别和NVMe硬盘抢通道装系统我用的是Ubuntu 20.04.6 LTS内核版本5.4左右这个组合昇腾官方支持得比较好。内核太新比如6.x反而容易出问题因为驱动模块可能没适配。驱动和固件安装时昇腾提供了Ascend HDK安装包里面包含driver驱动和firmware固件。安装流程比较标准# 解压后进入目录以root执行 ./Ascend-hdk-*-driver_*-linux-aarch64.run --full ./Ascend-hdk-*-firmware_*-linux-aarch64.run --full装完重启用npu-smi info验证。如果输出能看到类似以下内容说明驱动和固件都正常了-------------------------------------------------------------------------------------------- | npu-smi 23.0.rc2 Version: 23.0.rc2 | ------------------------------------------------------------------------------------------ | NPU Name | Health | Power | HBM | Memory | Proc | | 0 ..........| OK | 30.2W | 0.0% | 24237 / 24575 MB | 0 | ------------------------------------------------------------------------------------------注意这里有个常见现象Health显示OK但后面的AI Core使用率、Memory占用都是0这很正常因为还没有加载任何模型。如果显示“Unhealthy”或者“Offline”那就要检查PCIe链路和供电了。 ### 2.2 CANN工具包安装与配置 驱动搞定之后接着装CANN。CANN的版本要和驱动版本匹配否则会报错。我用的组合是CANN 7.0.0 RC1 配套的HDK 23.0.rc2。昇腾社区的文档里有版本配套表装之前一定去查一下这是最常见的坑。 CANN的安装有两种方式 - 以root用户安装到/usr/local/Ascend所有用户共享 - 以非root用户安装到home目录当前用户专用 普通用户开发建议用第二种不影响系统环境。安装包是.run格式的解压后安装即可 bash ./Ascend-cann-toolkit_7.0.0_linux-aarch64.run --install装完后需要source一下环境变量source /usr/local/Ascend/ascend-toolkit/set_env.sh建议把这行加到~/.bashrc里省得每次开终端都source。配置完后检查一下ATC工具是否可用which atc atc --version如果输出版本号说明CANN装好了。接下来就可以进入正题——模型转换。3. YOLO模型转换全流程实操3.1 从PyTorch导出干净的ONNX这一步是整个部署链路里最多坑的环节。很多人从yolov5官方仓库直接export.py导出ONNX结果转OM时各种报错。核心原因是推理逻辑里的后处理NMS被一起导出了或者动态shape太自由。我的做法是去掉YOLO模型里的NMS后处理只保留BackboneNeckHead的输出。以YOLOv5为例导出脚本里把NMS部分关掉导出三个特征图的输出import torch from models.experimental import attempt_load # 加载训练好的权重 model attempt_load(yolov5s.pt, map_locationcpu) model.eval() # 去掉NMS等后处理只导出原始输出 model.model[-1].export True # 设置输入尺寸这里用640x640 dummy_input torch.randn(1, 3, 640, 640) # 导出ONNXopset版本建议11~13之间 torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version12, input_names[images], output_names[output0, output1, output2], dynamic_axesNone # 固定shape省去动态shape的麻烦 )这里有几个经验opset_version不要太高11到13最稳新版PyTorch默认11或12都行opset 15以上容易遇到昇腾算子兼容问题导出的ONNX如果带了NMSATC转换时大概率报“不支持的算子”错误动态batch如果非要支持转换时要用dynamic shape的配置但这会降低推理效率边缘侧场景固定batch1就够了导出后用onnxsim优化一下可以把一些冗余的shape操作消掉python -m onnxsim yolov5s.onnx yolov5s_sim.onnx这一步不是必须的但实测能减少转换时的一些警告也能让OM模型小一点。3.2 ATC命令参数详解有了干净ONNX下一步就是用ATC转成OM。先看一个我实际用的命令atc \ --modelyolov5s_sim.onnx \ --framework5 \ --outputyolov5s_640 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --input_formatNCHW \ --output_typeFP32 \ --insert_op_confaipp.cfg \ --precision_modeallow_fp32_to_fp16 \ --logerror这些参数逐个说一下为什么这么设置--framework5表示输入模型是ONNX这个数字是昇腾定义的框架编号ONNX固定是5--soc_versionAscend310P3这里必须是Atlas 300V Pro对应的芯片版本。Atlas 300V Pro对应Ascend310P3如果填成Ascend310甚至Ascend910都会报错。怎么确认在CANN安装目录下执行npu-smi info -t board可以看到芯片型号或者直接用ascend-dmi -i -t board。如果实在不确定试试Ascend310P3基本能对上300V系列--output_typeFP32输出保持FP32精度。YOLO的坐标回归输出对精度比较敏感FP16在一些极端情况下会出现坐标偏移--insert_op_confaipp.cfg这个是AIPP配置作用是让预处理比如图像缩放、归一化直接跑在芯片内置的AIPP模块里CPU不用参与能省不少时间AIPP配置文件里我写的是这样的{ aipp_op: { aipp_mode: static, input_format: RGB888_U8, src_image_size_w: 640, src_image_size_h: 640, crop: false, mean: [0, 0, 0], min: [0, 0, 0], var: [0.003921569, 0.003921569, 0.003921569] } }这里var那一行是做了1/255的归一化等价于PyTorch里的/255.0。mean设成0是因为YOLOv5训练时没有减均值只做了缩放。还有一个关键点如果使用了AIPP做归一化那么ONNX模型里的归一化操作实际上是要去掉的。否则图像数据被AIPP处理后再进模型模型内部又归一化一次等于归一化了两遍检测精度会出问题。我一开始就犯了这错模型精度直接从mAP 0.56掉到0.31排查了半天才发现是重复归一化。3.3 转换后如何检查OM模型转换成功后输出目录会生成yolov5s_640.om文件。用omg --model或者atc自带的model_info工具检查一下模型信息omg --model-info --modelyolov5s_640.om这个命令会输出模型的输入输出信息、算子的统计等。重点看以下几点输入名称和shape是否和预期一致images: 1,3,640,640输出节点是三个还是融合成了一个形状是什么有没有WARNING级别的提示比如某个算子走了CPU fallback昇腾在做图编译时如果遇到不支持用AI Core加速的算子会放到CPU上执行。如果CPU算子太多模型跑起来会很慢这在转换日志里会以WARNING的形式提示。遇到这种情况方案是回到ONNX导出环节把对应的算子替换掉或拆解掉。4. 推理代码与性能调优4.1 用pyACL写推理代码模型转换好了接下来就是用代码把OM跑起来。昇腾推理的底层接口是ACLAscend Computing Language提供了C和Python API。为了快速验证我用的是Python接口pyACL。标准的推理流程分这么几步初始化ACLacl.init()设置设备acl.rt.set_device(0)加载模型acl.mdl.load_model_from_file(yolov5s_640.om)创建输入输出数据集acl.mdl.create_descacl.mdl.get_input_size_by_index准备输入数据把图像数据拷贝到device内存执行推理acl.mdl.execute获取输出把device上的输出拷贝回host后处理解析输出做NMS这里核心代码如下简化版import acl import numpy as np # 初始化 acl.init() acl.rt.set_device(0) # 加载模型 model_path yolov5s_640.om model_id acl.mdl.load_model_from_file(model_path) # 获取模型输入输出信息 input_desc acl.mdl.create_desc() acl.mdl.get_input_desc(input_desc, model_id, 0) input_size acl.mdl.get_input_size_by_index(model_id, 0) output_desc acl.mdl.create_desc() acl.mdl.get_output_desc(output_desc, model_id, 0) output_size acl.mdl.get_output_size_by_index(model_id, 0) # 分配device内存 input_mem acl.rt.malloc(input_size, 2) # 2表示内存对齐为2MB output_mem acl.rt.malloc(output_size, 2) # 预处理 img preprocess(frame) # letterbox AIPP参数匹配 # 拷贝输入数据到device acl.rt.memcpy(input_mem, input_size, img.tobytes(), input_size, acl.ACL_MEMCPY_HOST_TO_DEVICE) # 创建推理用的dataset input_data acl.mdl.create_data_buffer(input_mem, input_size) output_data acl.mdl.create_data_buffer(output_mem, output_size) dataset acl.mdl.create_dataset() acl.mdl.add_dataset_buffer(dataset, input_data) acl.mdl.add_dataset_buffer(dataset, output_data) # 执行推理 ret acl.mdl.execute(model_id, dataset) # 拷贝输出回host output_np np.zeros(output_size, dtypenp.uint8) acl.rt.memcpy(output_np.tobytes(), output_size, output_mem, output_size, acl.ACL_MEMCPY_DEVICE_TO_HOST) # 后处理解析三个输出特征图解码boxesNMS boxes decode_output(output_np) results non_max_suppression(boxes, conf_thres0.25, iou_thres0.45)这段代码看着简单但里面有几个容易忽略的点acl.rt.malloc的第二个参数是内存对齐方式2代表2MB对齐这个对推理性能有明显影响。user input如果用普通的malloc分配数据拷贝效率会低不少输入数据的排布必须是连续的并且shape要和OM的输入一致。如果你的OM输入是640x640那预处理里letterbox之后的图片就要调整到这个尺寸不能直接塞原始1920x1080的图acl.mdl.execute默认是同步调用如果想做异步流水线可以用acl.mdl.execute_async配合stream使用后处理部分可以重叠执行吞吐量能提升不少4.2 性能调优三板斧跑通之后接下来就是调性能。我手上的Atlas 300V Pro跑YOLOv5s 640x640单batch的推理延迟最初在12ms左右经过调优后稳定在6ms这里面有三板斧起了作用。第一板斧AIPP预处理下沉。把图像resize和归一化交给AIPP硬件而不是在CPU上做。注意AIPP的resize只能做等比缩放和padding如果你用了letterbox的灰色填充需要把填充逻辑也配置进AIPP。实测这一项能省掉约2ms的预处理时间推理本身的延迟不变但端到端延迟明显下降。第二板斧固定batch size并启用多线程多路并发。边缘侧检测如果只跑一路视频24GB显存根本用不满。我实际部署时跑8路1080p视频流每路一个模型实例batch1利用昇腾的多核特性并行执行。这里要配合设置acl.rt.set_device和多个线程每个线程绑定一个模型实例。实测8路并发时单路延迟从6ms涨到10ms左右但整个系统的吞吐量从80FPS提升到400FPS这才是这块卡的正确用法。第三板斧减少host和device间的数据拷贝次数。每帧图像从摄像头采集后先做一次H2D拷贝推理完再做D2H拷贝后处理做完再画框编码搞视频流分析时这个链路很容易成为瓶颈。我的做法是用DVPP模块做图像解码和缩放解码后直接输出到device内存省掉了CPU侧的一次中转拷贝。在Atlas上跑视频流强烈建议走DVPP而不是OpenCVCPU占用率和延迟都会好看很多。4.3 常见问题排查实录最后分享几个我在这个项目里踩过的比较典型的问题以及对应的排查方法。现象原因解决方案npu-smi info看不到卡驱动未装好或PCIe识别失败检查BIOS的4G decoding开关重新安装驱动atc转换报E10016ONNX里有不支持的算子或opset版本太高用onnxsim精简模型降低opset到12atc转换报E10020soc_version填错了或者模型输入shape和配置不一致用npu-smi info -t board确认芯片型号核对input_shape推理结果全零或者置信度为零AIPP和模型里都有归一化导致输入数值被缩小二次去掉模型里的归一化操作或者去掉AIPP的var配置推理速度特别慢50ms大量算子走了CPU fallback查看转换日志的WARNING定位CPU算子替换掉相关结构内存分配失败device内存不足或多个进程未释放模型检查npu-smi info的memory占用及时调用acl.mdl.unload还有一个细节昇腾的调试日志默认是关闭的出了问题如果你不知道怎么看日志会一头雾水。调日志的方式是设置环境变量export ASCEND_GLOBAL_LOG_LEVEL1 export ASCEND_SLOG_PRINT_TO_STDOUT1level1是DEBUG级别会输出非常多的算子执行日志。定位完问题后记得改回3INFO级别因为DEBUG日志性能损耗很大生产环境千万别开。另外一个容易坑到人的点多线程推理时acl.init()必须在主线程调用子线程里只做acl.rt.set_device和推理。如果每个线程都调acl.init()会导致句柄冲突程序直接崩掉。我的习惯是写一个init单例进程启动时初始化好环境和设备后面所有线程直接复用。现在我来整体复盘一下这个项目的经验。Atlas 300V 24G这卡用对场景确实很香24GB大显存、72W低功耗、半高卡设计特别适合边缘服务器里堆多卡做视频分析。但它的门槛在于整个软件栈和CUDA生态差别太大了如果你只把CANN当成一个“类似CUDA”的东西来用前面的学习成本会比较高。建议第一次上手的时候老老实实走一遍PyTorch→ONNX→ATC→OM→pyACL这条链路把所有报错都解决一遍基本就能理解昇腾的思维方式了。最后再分享一个小技巧如果你只是想在项目里快速跑起来不追求底层控制可以看一下昇腾的MindX SDK它提供了插件化的推理流水线图像解码、缩放、推理、后处理这些模块都能用现成的插件串起来。我在第二个项目里就用了MindX开发周期从两周压缩到三天。当然如果想做深度性能调优还是得回到ACL这层。建议两手都掌握业务开发用MindX性能攻坚用pyACL这才是Atlas系列的正确打开方式。 
长河君 · 2026/9/25 10:45:46 · 阅读 1.2k 昇腾Atlas 300V上部署YOLO全指南：模型转换与推理优化
去年年底搞了个边缘检测项目甲方点名要用国产AI加速卡最后落到手里的就是一张Atlas 300V 24G。刚拿到卡的时候团队里还有人问“这玩意是运算加速卡吗”毕竟以前大家只熟NVIDIA的卡。实话说这块卡确实是昇腾系列的推理加速卡而且用它部署YOLO流程和坑都不少但摸顺了之后性能是真的能打。这篇就把我从装驱动、转模型到调优的完整过程掰开揉碎了讲项目里要用Atlas跑YOLO的可以直接照抄。先说结论Atlas 300V 24G是运算加速卡属于昇腾AI处理器的推理产品线定位是边缘侧和数据中心的视频分析、目标检测推理场景。它跟训练卡最大的区别在于你不能直接拿它去微调YOLO而是要把训练好的模型转换成昇腾的OM格式再通过ACL或MindX SDK去调用算力推理。整个部署链路比你想象的要长但每一步都有章可循。1. 先搞清楚Atlas 300V 24G到底是什么卡1.1 定位与硬件参数Atlas 300V 24G是华为昇腾系列的推理加速卡专门做神经网络推理。它用的是昇腾310P芯片Atlas 300V Pro是310P3内部集成了AI Core、CPU Core、DVPP视频预处理模块等。这个芯片的核心是达芬奇架构提供的算力以INT8为主这一点和NVIDIA的T4有点像但不完全一样。我拿到的是Atlas 300V Pro 24G版本几个关键参数我列一下算力INT8精度下约140 TOPSFP16约70 TFLOPS左右不同型号有差异以官方规格为准显存24GB LPDDR4X带宽约204GB/s位宽512bit功耗单卡典型功耗72W无外接供电PCIe插槽取电接口PCIe 4.0 x16半高半长单槽卡支持的精度INT8、FP16、FP32FP32性能较低主要用于精度校验这里有个容易误判的点24GB显存听着很大好像能装下不少模型。但LPDDR4X的带宽和GDDR6/HBM完全不是一个级别204GB/s带宽跑大batch或高分辨率输入时瓶颈很容易卡在显存带宽上。实际部署YOLO模型时24GB的优势是能同时加载多个模型实例或者跑很大的batch而不是单张卡算力有多猛。1.2 昇腾软件栈换个赛道规则不一样很多人拿到Atlas卡第一步就懵了因为习惯了CUDA那一套拿到昇腾卡后不知道该装什么。昇腾的软件栈分几层驱动固件层Ascend HDK包括NPU驱动和固件装好后用npu-smi info能看到卡的状态CANN工具链核心软件包包含算子库、图编译引擎ATC、运行时ACL runtime、推理应用开发库MindX SDK面向行业的应用开发套件封装了推理流水线不想写底层ACL代码的话可以直接用上层框架插件比如PyTorch Adapter让PyTorch模型能跑到昇腾上所以整个部署路径和CUDA生态完全不同PyTorch模型在GPU上直接跑但在Atlas上你要把PyTorch模型导出成ONNX再用ATC工具转成OM格式最后通过ACL接口或MindX SDK加载OM做推理。这个转换链路就是Atlas部署YOLO最核心也最容易踩坑的地方。我的建议是先不要想着什么都要自动化老老实实走一遍PYtorch→ONNX→OM的手动流程把每个环节搞明白后面再考虑端到端的工具链。2. 环境搭建从裸机到能跑模型2.1 硬件安装与驱动固件安装Atlas 300V物理上很简单插到PCIe x16槽里不需要外接供电。但有几个细节要注意服务器BIOS里要开启4G解码和SR-IOV如果要做虚拟化否则BIOS可能识别不到卡PCIe链路要跑在Gen4 x16如果插在x8槽上性能会打折多卡时要注意CPU的PCIe lane分配别和NVMe硬盘抢通道装系统我用的是Ubuntu 20.04.6 LTS内核版本5.4左右这个组合昇腾官方支持得比较好。内核太新比如6.x反而容易出问题因为驱动模块可能没适配。驱动和固件安装时昇腾提供了Ascend HDK安装包里面包含driver驱动和firmware固件。安装流程比较标准# 解压后进入目录以root执行 ./Ascend-hdk-*-driver_*-linux-aarch64.run --full ./Ascend-hdk-*-firmware_*-linux-aarch64.run --full装完重启用npu-smi info验证。如果输出能看到类似以下内容说明驱动和固件都正常了-------------------------------------------------------------------------------------------- | npu-smi 23.0.rc2 Version: 23.0.rc2 | ------------------------------------------------------------------------------------------ | NPU Name | Health | Power | HBM | Memory | Proc | | 0 ..........| OK | 30.2W | 0.0% | 24237 / 24575 MB | 0 | ------------------------------------------------------------------------------------------注意这里有个常见现象Health显示OK但后面的AI Core使用率、Memory占用都是0这很正常因为还没有加载任何模型。如果显示“Unhealthy”或者“Offline”那就要检查PCIe链路和供电了。 ### 2.2 CANN工具包安装与配置 驱动搞定之后接着装CANN。CANN的版本要和驱动版本匹配否则会报错。我用的组合是CANN 7.0.0 RC1 配套的HDK 23.0.rc2。昇腾社区的文档里有版本配套表装之前一定去查一下这是最常见的坑。 CANN的安装有两种方式 - 以root用户安装到/usr/local/Ascend所有用户共享 - 以非root用户安装到home目录当前用户专用 普通用户开发建议用第二种不影响系统环境。安装包是.run格式的解压后安装即可 bash ./Ascend-cann-toolkit_7.0.0_linux-aarch64.run --install装完后需要source一下环境变量source /usr/local/Ascend/ascend-toolkit/set_env.sh建议把这行加到~/.bashrc里省得每次开终端都source。配置完后检查一下ATC工具是否可用which atc atc --version如果输出版本号说明CANN装好了。接下来就可以进入正题——模型转换。3. YOLO模型转换全流程实操3.1 从PyTorch导出干净的ONNX这一步是整个部署链路里最多坑的环节。很多人从yolov5官方仓库直接export.py导出ONNX结果转OM时各种报错。核心原因是推理逻辑里的后处理NMS被一起导出了或者动态shape太自由。我的做法是去掉YOLO模型里的NMS后处理只保留BackboneNeckHead的输出。以YOLOv5为例导出脚本里把NMS部分关掉导出三个特征图的输出import torch from models.experimental import attempt_load # 加载训练好的权重 model attempt_load(yolov5s.pt, map_locationcpu) model.eval() # 去掉NMS等后处理只导出原始输出 model.model[-1].export True # 设置输入尺寸这里用640x640 dummy_input torch.randn(1, 3, 640, 640) # 导出ONNXopset版本建议11~13之间 torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version12, input_names[images], output_names[output0, output1, output2], dynamic_axesNone # 固定shape省去动态shape的麻烦 )这里有几个经验opset_version不要太高11到13最稳新版PyTorch默认11或12都行opset 15以上容易遇到昇腾算子兼容问题导出的ONNX如果带了NMSATC转换时大概率报“不支持的算子”错误动态batch如果非要支持转换时要用dynamic shape的配置但这会降低推理效率边缘侧场景固定batch1就够了导出后用onnxsim优化一下可以把一些冗余的shape操作消掉python -m onnxsim yolov5s.onnx yolov5s_sim.onnx这一步不是必须的但实测能减少转换时的一些警告也能让OM模型小一点。3.2 ATC命令参数详解有了干净ONNX下一步就是用ATC转成OM。先看一个我实际用的命令atc \ --modelyolov5s_sim.onnx \ --framework5 \ --outputyolov5s_640 \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --input_formatNCHW \ --output_typeFP32 \ --insert_op_confaipp.cfg \ --precision_modeallow_fp32_to_fp16 \ --logerror这些参数逐个说一下为什么这么设置--framework5表示输入模型是ONNX这个数字是昇腾定义的框架编号ONNX固定是5--soc_versionAscend310P3这里必须是Atlas 300V Pro对应的芯片版本。Atlas 300V Pro对应Ascend310P3如果填成Ascend310甚至Ascend910都会报错。怎么确认在CANN安装目录下执行npu-smi info -t board可以看到芯片型号或者直接用ascend-dmi -i -t board。如果实在不确定试试Ascend310P3基本能对上300V系列--output_typeFP32输出保持FP32精度。YOLO的坐标回归输出对精度比较敏感FP16在一些极端情况下会出现坐标偏移--insert_op_confaipp.cfg这个是AIPP配置作用是让预处理比如图像缩放、归一化直接跑在芯片内置的AIPP模块里CPU不用参与能省不少时间AIPP配置文件里我写的是这样的{ aipp_op: { aipp_mode: static, input_format: RGB888_U8, src_image_size_w: 640, src_image_size_h: 640, crop: false, mean: [0, 0, 0], min: [0, 0, 0], var: [0.003921569, 0.003921569, 0.003921569] } }这里var那一行是做了1/255的归一化等价于PyTorch里的/255.0。mean设成0是因为YOLOv5训练时没有减均值只做了缩放。还有一个关键点如果使用了AIPP做归一化那么ONNX模型里的归一化操作实际上是要去掉的。否则图像数据被AIPP处理后再进模型模型内部又归一化一次等于归一化了两遍检测精度会出问题。我一开始就犯了这错模型精度直接从mAP 0.56掉到0.31排查了半天才发现是重复归一化。3.3 转换后如何检查OM模型转换成功后输出目录会生成yolov5s_640.om文件。用omg --model或者atc自带的model_info工具检查一下模型信息omg --model-info --modelyolov5s_640.om这个命令会输出模型的输入输出信息、算子的统计等。重点看以下几点输入名称和shape是否和预期一致images: 1,3,640,640输出节点是三个还是融合成了一个形状是什么有没有WARNING级别的提示比如某个算子走了CPU fallback昇腾在做图编译时如果遇到不支持用AI Core加速的算子会放到CPU上执行。如果CPU算子太多模型跑起来会很慢这在转换日志里会以WARNING的形式提示。遇到这种情况方案是回到ONNX导出环节把对应的算子替换掉或拆解掉。4. 推理代码与性能调优4.1 用pyACL写推理代码模型转换好了接下来就是用代码把OM跑起来。昇腾推理的底层接口是ACLAscend Computing Language提供了C和Python API。为了快速验证我用的是Python接口pyACL。标准的推理流程分这么几步初始化ACLacl.init()设置设备acl.rt.set_device(0)加载模型acl.mdl.load_model_from_file(yolov5s_640.om)创建输入输出数据集acl.mdl.create_descacl.mdl.get_input_size_by_index准备输入数据把图像数据拷贝到device内存执行推理acl.mdl.execute获取输出把device上的输出拷贝回host后处理解析输出做NMS这里核心代码如下简化版import acl import numpy as np # 初始化 acl.init() acl.rt.set_device(0) # 加载模型 model_path yolov5s_640.om model_id acl.mdl.load_model_from_file(model_path) # 获取模型输入输出信息 input_desc acl.mdl.create_desc() acl.mdl.get_input_desc(input_desc, model_id, 0) input_size acl.mdl.get_input_size_by_index(model_id, 0) output_desc acl.mdl.create_desc() acl.mdl.get_output_desc(output_desc, model_id, 0) output_size acl.mdl.get_output_size_by_index(model_id, 0) # 分配device内存 input_mem acl.rt.malloc(input_size, 2) # 2表示内存对齐为2MB output_mem acl.rt.malloc(output_size, 2) # 预处理 img preprocess(frame) # letterbox AIPP参数匹配 # 拷贝输入数据到device acl.rt.memcpy(input_mem, input_size, img.tobytes(), input_size, acl.ACL_MEMCPY_HOST_TO_DEVICE) # 创建推理用的dataset input_data acl.mdl.create_data_buffer(input_mem, input_size) output_data acl.mdl.create_data_buffer(output_mem, output_size) dataset acl.mdl.create_dataset() acl.mdl.add_dataset_buffer(dataset, input_data) acl.mdl.add_dataset_buffer(dataset, output_data) # 执行推理 ret acl.mdl.execute(model_id, dataset) # 拷贝输出回host output_np np.zeros(output_size, dtypenp.uint8) acl.rt.memcpy(output_np.tobytes(), output_size, output_mem, output_size, acl.ACL_MEMCPY_DEVICE_TO_HOST) # 后处理解析三个输出特征图解码boxesNMS boxes decode_output(output_np) results non_max_suppression(boxes, conf_thres0.25, iou_thres0.45)这段代码看着简单但里面有几个容易忽略的点acl.rt.malloc的第二个参数是内存对齐方式2代表2MB对齐这个对推理性能有明显影响。user input如果用普通的malloc分配数据拷贝效率会低不少输入数据的排布必须是连续的并且shape要和OM的输入一致。如果你的OM输入是640x640那预处理里letterbox之后的图片就要调整到这个尺寸不能直接塞原始1920x1080的图acl.mdl.execute默认是同步调用如果想做异步流水线可以用acl.mdl.execute_async配合stream使用后处理部分可以重叠执行吞吐量能提升不少4.2 性能调优三板斧跑通之后接下来就是调性能。我手上的Atlas 300V Pro跑YOLOv5s 640x640单batch的推理延迟最初在12ms左右经过调优后稳定在6ms这里面有三板斧起了作用。第一板斧AIPP预处理下沉。把图像resize和归一化交给AIPP硬件而不是在CPU上做。注意AIPP的resize只能做等比缩放和padding如果你用了letterbox的灰色填充需要把填充逻辑也配置进AIPP。实测这一项能省掉约2ms的预处理时间推理本身的延迟不变但端到端延迟明显下降。第二板斧固定batch size并启用多线程多路并发。边缘侧检测如果只跑一路视频24GB显存根本用不满。我实际部署时跑8路1080p视频流每路一个模型实例batch1利用昇腾的多核特性并行执行。这里要配合设置acl.rt.set_device和多个线程每个线程绑定一个模型实例。实测8路并发时单路延迟从6ms涨到10ms左右但整个系统的吞吐量从80FPS提升到400FPS这才是这块卡的正确用法。第三板斧减少host和device间的数据拷贝次数。每帧图像从摄像头采集后先做一次H2D拷贝推理完再做D2H拷贝后处理做完再画框编码搞视频流分析时这个链路很容易成为瓶颈。我的做法是用DVPP模块做图像解码和缩放解码后直接输出到device内存省掉了CPU侧的一次中转拷贝。在Atlas上跑视频流强烈建议走DVPP而不是OpenCVCPU占用率和延迟都会好看很多。4.3 常见问题排查实录最后分享几个我在这个项目里踩过的比较典型的问题以及对应的排查方法。现象原因解决方案npu-smi info看不到卡驱动未装好或PCIe识别失败检查BIOS的4G decoding开关重新安装驱动atc转换报E10016ONNX里有不支持的算子或opset版本太高用onnxsim精简模型降低opset到12atc转换报E10020soc_version填错了或者模型输入shape和配置不一致用npu-smi info -t board确认芯片型号核对input_shape推理结果全零或者置信度为零AIPP和模型里都有归一化导致输入数值被缩小二次去掉模型里的归一化操作或者去掉AIPP的var配置推理速度特别慢50ms大量算子走了CPU fallback查看转换日志的WARNING定位CPU算子替换掉相关结构内存分配失败device内存不足或多个进程未释放模型检查npu-smi info的memory占用及时调用acl.mdl.unload还有一个细节昇腾的调试日志默认是关闭的出了问题如果你不知道怎么看日志会一头雾水。调日志的方式是设置环境变量export ASCEND_GLOBAL_LOG_LEVEL1 export ASCEND_SLOG_PRINT_TO_STDOUT1level1是DEBUG级别会输出非常多的算子执行日志。定位完问题后记得改回3INFO级别因为DEBUG日志性能损耗很大生产环境千万别开。另外一个容易坑到人的点多线程推理时acl.init()必须在主线程调用子线程里只做acl.rt.set_device和推理。如果每个线程都调acl.init()会导致句柄冲突程序直接崩掉。我的习惯是写一个init单例进程启动时初始化好环境和设备后面所有线程直接复用。现在我来整体复盘一下这个项目的经验。Atlas 300V 24G这卡用对场景确实很香24GB大显存、72W低功耗、半高卡设计特别适合边缘服务器里堆多卡做视频分析。但它的门槛在于整个软件栈和CUDA生态差别太大了如果你只把CANN当成一个“类似CUDA”的东西来用前面的学习成本会比较高。建议第一次上手的时候老老实实走一遍PyTorch→ONNX→ATC→OM→pyACL这条链路把所有报错都解决一遍基本就能理解昇腾的思维方式了。最后再分享一个小技巧如果你只是想在项目里快速跑起来不追求底层控制可以看一下昇腾的MindX SDK它提供了插件化的推理流水线图像解码、缩放、推理、后处理这些模块都能用现成的插件串起来。我在第二个项目里就用了MindX开发周期从两周压缩到三天。当然如果想做深度性能调优还是得回到ACL这层。建议两手都掌握业务开发用MindX性能攻坚用pyACL这才是Atlas系列的正确打开方式。