ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Atlas 300V加速卡部署YOLO实战:从CANN到OM模型转换全流程

Atlas 300V加速卡部署YOLO实战:从CANN到OM模型转换全流程 1. 先搞清楚Atlas 300V到底是个什么东西1.1 一张卡解决的事24G显存意味着什么最近不少朋友在群里问“Atlas 300V 24G是不是运算加速卡”我估计很多人是被这个名字搞得一头雾水。先说结论它确实是运算加速卡而且是专门干AI推理这活的加速卡不是那种通用计算GPU。Atlas 300V Pro是华为昇腾系列里面向边缘和推理场景的主力型号板载24GB显存核心是昇腾310P处理器主打的就是“视频分析、目标检测、图像分类”这类高吞吐推理任务。24G这个容量放在推理卡里算是相当够用的。以YOLOv5s为例FP16精度的模型权重也就30MB左右一张24G的卡理论上能同时塞下十几个模型实例实际部署时我们更关心的是算力能不能吃满。Atlas 300V Pro的INT8算力在140TOPS左右FP16算力大约70TFLOPS这个数字对标的是NVIDIA的Tesla T4但价格和功耗都要低不少板卡功耗只有72W左右不需要额外供电线插上就能跑。1.2 它和GPU的差别以及为什么选它用过GPU做推理的朋友转过来用Atlas最直观的感受是“生态不一样”。GPU那边是CUDA一统天下PyTorch、TensorRT、onnxruntime随便选Atlas这边走的是昇腾的CANNCompute Architecture for Neural Networks软件栈模型要先转成OM格式才能跑。听起来麻烦但一旦跑通性能和稳定性其实不差尤其在做视频流多路推理时Atlas的硬件解码能力和多路并行设计优势很明显。选Atlas而不是GPU主要是三方面考虑一是成本同样24G显存级别的推理卡Atlas 300V Pro比同档GPU便宜不少二是功耗和部署形态72W功耗意味着普通服务器电源就能带甚至可以用在无风扇的工业边缘设备上三是国产化要求很多安防、电力、工业质检项目明确要求用国产算力Atlas天然满足。如果你是在做视频监控、车牌识别、安全帽检测这类场景Atlas 300V基本是绕不开的选项。2. 部署YOLO前的软件栈搭建2.1 驱动、固件和CANN三件套装齐硬件插到服务器上只是第一步真正麻烦的是软件环境。Atlas的软件栈分三层底层是驱动Driver和固件Firmware中间是CANN工具包上层才是你跑的推理框架。这三层版本必须严格配套否则各种诡异报错会找上门。先装驱动和固件。到昇腾社区下载对应版本的Ascend HDKHardware Development Kit里面包含了driver和firmware两个安装包。安装前用npu-smi info命令看看卡是否被识别如果识别不到先检查PCIe插槽和供电。驱动装完后用npu-smi info能看到卡的型号、显存、算力状态确认显示“OK”再继续。接下来装CANN。CANN是整个昇腾软件栈的核心类似CUDA toolkit的角色里面包含了模型转换工具atc、推理运行时ACLAscendCL、各种算子和图优化引擎。安装包有社区版和商业版之分个人开发和测试用社区版就够了。安装时注意操作系统推荐Ubuntu 20.04/22.04 x86_64或ARM版本CentOS 7.6以上也行但坑多一些安装用户建议用普通用户不要用root跑推理否则权限模型容易出问题安装完必须source /usr/local/Ascend/ascend-toolkit/set_env.sh设置环境变量否则找不到atc和msopst命令2.2 两种开发路径怎么选软件栈装好后你会面临一个选择用MindSpore还是PyTorch我的建议是如果只是把已有的YOLO模型迁移过来做推理直接用PyTorch torch_npu插件如果是从零开始训练并在昇腾上落地可以考虑MindSpore但它对YOLO这类检测模型的支持目前还是不如PyTorch生态顺手。实际部署中大多数人走的是这条路PyTorch训练/导出模型 → ONNX中间格式 → atc转换成OM → 用ACL推理。这套流程的好处是训练侧完全不用改还是在GPU或CPU上做只有推理侧需要适配昇腾。torch_npu这个插件现在也支持直接在昇腾上跑PyTorch训练但性能调优的门槛比较高新手不建议一上来就搞。注意CANN版本和torch_npu版本、PyTorch版本有严格对应关系装之前先去昇腾社区的版本配套表里查清楚别拿最新版硬配否则导入torch_npu时会直接报错。3. YOLO模型从PyTorch到Ascend的迁移3.1 模型导出成ONNX时的注意事项模型迁移不是把.pt文件直接丢给atc就完事中间需要经过ONNX这层“翻译官”。用YOLOv5官方仓库的export.py脚本可以导出ONNX但有几个细节必须处理第一导出时固定输入尺寸。YOLOv5默认是640x640导出时用--img 640参数指定后面推理时输入必须严格保持这个尺寸。atc转换时也会用到这个尺寸两者不一致会导致推理结果错乱。第二关闭动态shape。昇腾的atc转换支持动态shape但动态shape会带来额外的性能开销边缘场景下输入尺寸是固定的建议用--dynamic_batch_size或直接固定batch为1换取更好的性能。如果你确实需要动态batch可以设置--dynamic_batch_size 1,2,4但推理时要在ACL里做对应配置麻烦不少。第三导出的ONNX里有一些算子昇腾不支持。比如YOLOv5导出时会带一些Split、Resize、Concat算子的变体atc转换时如果报“unsupported operator”一般有两种解法一个是修改YOLOv5的检测头逻辑把后处理从模型里拆出来放到CPU上做另一个是使用MIndStudio或ATC自带的算子映射表看有没有可替换的算子。我强烈建议用第一种把NMS非极大值抑制和置信度过滤放到模型外面处理这个在后面讲推理流程时细说。3.2 atc转换工具与OM模型生成ONNX准备好后用atc工具做转换。下面是我在实际项目里用的一条转换命令atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP16 \ --input_formatNCHW几个参数逐个说清楚--framework5表示输入的是ONNX模型这个数字是CANN规定的ONNX固定是5--soc_version要写对Atlas 300V Pro对应的soc版本是Ascend310P3写错会直接报错--insert_op_conf指定AIPP配置文件AIPP就是图像预处理模块可以在硬件层面完成resize、归一化、颜色空间转换省掉CPU的预处理开销--output_typeFP16指定模型权重精度一般推理用FP16够用如果追求更高精度可以保持FP32但推理速度会慢一些AIPP配置文件长这样aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_h: 640 src_image_size_w: 640 csc_switch: true rbuv_swap_switch: false min_chn_0: 0 min_chn_1: 0 min_chn_2: 0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }这个配置实现的操作是把输入的RGB888图像缩放到640x640然后除以255做归一化。注意YOLOv5训练时用的归一化是除以255如果你训练时用的是mean/std方式这里的参数要改成对应的均值和方差倒数否则推理精度会掉得惨不忍睹。转换完成后会生成一个.om文件这就是昇腾的模型格式。用atc --model转换时可以在日志里看到每个算子的映射情况注意看有没有走CPU的算子如果有说明模型里有不支持的算子被降级到CPU了会极大拉低性能。4. 推理部署的完整流程4.1 用ACL接口跑推理模型转好之后就到了推理环节。昇腾上官方推荐的推理方式是使用ACLAscendCL接口类似CUDA Runtime API。整个流程分五步初始化设备、加载模型、准备输入输出内存、执行推理、释放资源。下面给一个完整的C推理示例框架Python版本类似但C性能更好#include acl/acl.h #include opencv2/opencv.hpp int main() { // 1. 初始化 aclInit(nullptr); aclrtSetDevice(0); aclrtContext context; aclrtCreateContext(context, 0); // 2. 加载模型 aclmdlDesc *modelDesc aclmdlCreateDesc(); aclmdlLoadFromFile(yolov5s_bs1.om, modelId); aclmdlGetDesc(modelDesc, modelId); // 3. 申请输入输出内存 size_t inputSize aclmdlGetInputSizeByIndex(modelDesc, 0); size_t outputSize aclmdlGetOutputSizeByIndex(modelDesc, 0); aclrtMalloc(inputBuf, inputSize, ACL_MEM_MALLOC_HUGE_FIRST); aclrtMalloc(outputBuf, outputSize, ACL_MEM_MALLOC_HUGE_FIRST); // 4. 数据预处理resize后拷贝到inputBuf cv::Mat image cv::imread(test.jpg); cv::Mat resized; cv::resize(image, resized, cv::Size(640, 640)); // 注意这里要转成RGB格式AIPP里我们配置的是RGB888 memcpy(inputBuf, resized.data, inputSize); // 5. 执行推理 aclmdlExecute(modelId, inputBuf, outputSize, outputBuf); // 6. 解析输出根据YOLO的输出格式做后处理 // YOLOv5的输出shape是[1, 25200, 85]每个anchor有85个值 // 这里要做阈值过滤和NMS // 7. 释放资源 aclrtFree(inputBuf); aclrtFree(outputBuf); aclmdlUnload(modelId); aclrtDestroyContext(context); aclrtResetDevice(0); aclFinalize(); }每一步都有对应的高级封装你也可以用Python的pyACL接口代码会更简洁。注意在内存拷贝时如果输入图像和模型要求的尺寸不一致一定要先做resize再拷贝AIPP的src_image_size_h/w只是告知模型原始输入尺寸不是自动resize。4.2 性能调优的几个关键参数模型能跑起来和跑得快是两回事。我在调优过程中发现几个影响性能的关键点第一个是batch size。Atlas 300V的推理性能在batch size为1时其实表现一般多batch能明显提升吞吐。如果你做的是视频流分析可以把多路视频帧拼成batch一起推理例如4路视频每路取一帧拼成batch 4推理时间和batch 1差不多吞吐直接翻4倍。不过batch加深会增加显存占用和延迟需要根据业务侧重取舍。第二个是AIPP和推理的流水线。尽量把所有图像预处理扔给AIPP让昇腾的DVPP硬件模块去处理resize和颜色转换CPU只负责DMA搬运。实测下来用AIPP替代CPU预处理端到端延迟能降低30%左右。第三个是进程/线程模型。ACL执行推理时aclrtSetDevice和aclrtCreateContext可以创建多个context实现多路并发。如果你有16路视频流可以开4个线程每个线程绑一个context每个context里跑batch 4的推理这样能充分发挥310P的多核能力。5. 实战中踩过的坑与排查思路5.1 常见报错速查把这一年多跑Atlas踩过的坑整理成一个速查表希望能帮你少走弯路现象可能原因解决办法npu-smi info看不到卡驱动未装好或PCIe链路异常重新安装驱动检查卡是否插紧lspciatc转换报E10001输入路径错误或ONNX模型不完整检查ONNX文件能否用onnxruntime加载重新导出atc转换报E40004算子不支持模型里有昇腾未实现的算子修改模型结构把不支持算子移到后处理或换模型版本aclmdlLoadFromFile返回ACL_ERROR_MODEL_MISSING_OMOM模型与当前CANN版本不匹配用当前版本的atc重新转换模型推理结果全为0或NaN输入数据格式不对或未归一化确认输入是RGB且已归一化AIPP配置与训练一致推理延迟很高有算子落到CPU执行用msopst或atc --dump_model检查算子分配替换不支持的算子多线程推理崩溃context未正确绑定线程确保每个线程创建并绑定了独立的context线程间不共享context5.2 几个容易被忽略的细节第一虚拟内存和shm大小。Atlas推理时会在/dev/shm中分配共享内存默认的docker容器/dev/shm只有64MB跑大模型或高并发时会直接报No space left on device。用docker跑的话加--shm-size8g参数。第二电源管理策略。服务器BIOS里如果开启了CPU节能模式会影响数据搬运和预处理的速度。做性能测试时建议把系统设为性能模式保证推理延迟稳定。第三和OpenCV的版本兼容。C推理时经常遇到OpenCV的imread和Atlas的DVPP模块冲突的问题升级OpenCV到4.x能解决大部分兼容性报错。另外图像解码尽量用DVPP的jpeg解码接口比OpenCV的imread快很多尤其在处理大量图片时差距很明显。5.3 产品选型的一些建议最后聊一下选型的问题。Atlas 300V Pro24G适合什么场景如果你跑的是YOLOv5/YOLOv8这类主流检测模型且需要处理多路视频流8路以上这个卡是性价比很高的选择。但如果你要训练模型或者跑的是超大模型比如YOLOv5x的FP16版本24G显存虽然够但训练这活还是交给GPU吧Atlas系列目前定位就是推理。另外提醒一句Atlas 300V有标准版和Pro版之分Pro版才带24G显存标准版是16G。采购时别只看“Atlas 300V”这个名字一定要确认型号后缀。还有一个容易踩的坑是Atlas 300V和Atlas 300I虽然外观相似但300I是另一款面向视频分析的卡接口和软件栈差异不小别买错了。我个人在实际操作中的体会是Atlas这套东西最大的门槛不在硬件而在软件栈的学习成本。CANN的文档虽然齐全但组织得比较散新手容易在版本配套和工具链上卡住。我的建议是第一次跑通别贪功能就用最简单的固定shape、单batch、C/Python最简接口先把端到端流程跑通再逐步加batch、加AIPP、加多路并发。等把流程摸熟了你会发现Atlas 300V这块卡在推理场景下的性价比是真的能打。
返回列表