ARTICLE DETAIL

资讯详情

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

Atlas 300V 24G加速卡部署YOLO全流程:从环境配置到模型转换

Atlas 300V 24G加速卡部署YOLO全流程:从环境配置到模型转换 后台经常有人私信问我Atlas 300V 24G到底算不算运算加速卡这卡能跑YOLO吗部署起来到底麻不麻烦说实话这两年被各家AI加速卡宣传搞晕的人不在少数。Atlas这个名字确实有点大它既可以是整机服务器也可以是插在服务器里的PCIe加速卡还有可能是一台边缘小盒子。但如果你手头拿到的是一块“Atlas 300V 24G”那我明确告诉你它就是一张运算加速卡而且是一张专门为视频分析、目标检测这类AI推理场景设计的加速卡。我这一年多拿它在产线上跑YOLOv5、YOLOv8踩了不少坑也沉淀了一套完整的部署流程今天干脆一次性整理出来希望能帮你省掉几周的摸索时间。这篇文章主要适合三类人第一次接触Atlas卡、准备在服务器上部署YOLO模型的算法工程师做边缘计算项目、正在纠结选GPU还是加速卡方案的技术负责人以及纯粹好奇AI推理加速卡内部是怎么回事的爱好者。我会先把这张卡的定位讲清楚再手把手带你走完从PyTorch权重到Atlas上跑通YOLO的全部流程最后把我踩过的坑和排查思路原原本本写出来。1. Atlas 300V 24G到底是一张什么卡1.1 它确实是运算加速卡但和你想的“运算卡”不太一样先说结论Atlas 300V 24G严格说市面上常见的是Atlas 300V Pro 24G版本是一张AI推理加速卡采用昇腾310P系列芯片板载24GB显存官方定位是视频分析卡。它最常见的形态就是插在标准x86服务器上通过PCIe接口与CPU通信对外提供INT8/FP16算力。但它和NVIDIA的GPU运算卡有个非常本质的区别GPU是通用并行计算卡除了AI推理你还能拿它做渲染、科学计算、跑CUDA程序而Atlas 300V的服务对象非常聚焦它内部的AI Core是为神经网络算子设计的专用处理单元官方主推的场景就是视频解码、目标检测、图像分类这类推理负载。厂商在设计它的时候甚至在板上直接集成了硬件视频解码单元可以硬解H.264/H.265视频流这在视频分析场景里是实打实的优势。我打个比方你就明白了。GPU像是一个全科医生什么病都能看Atlas 300V更像是一个专科医生你让它做AI推理、视频解码它非常专业效率也很高但你非要让它跑个通用计算的活那就有点为难它了。所以当有人问我“我用GPU的代码能不能直接在这张卡上跑”时答案基本都是不能因为软件栈完全不通用。1.2 一张卡盯一个场景300V在Atlas家族里的位置Atlas这个产品线非常庞大如果不理清楚很容易买错卡、装错驱动。我按自己的理解给你画个粗线条的图谱。Atlas 300系列是插在服务器机箱里的PCIe加速卡面向数据中心的AI推理和训练。其中Atlas 300I Duo是推理卡Atlas 300T系列是训练卡而Atlas 300V系列则专门面向视频分析场景突出多路视频解码和大显存。Atlas 200/500系列则主要用于边缘小站比如Atlas 200 DK开发板、Atlas 500 Pro小盒子。到了Atlas 800/900这个级别就是整机AI服务器了内部可能插了多张300系列卡。所以当你听到“Atlas 300V 24G”的时候第一反应应该是这是一张面向数据中心的视频分析推理卡而不是一台服务器也不是边缘小盒子。它的24G显存非常大什么概念一张YOLOv5s模型加上输入预处理缓冲、多路视频流的数据24G显存可以非常从容地同时处理几十路甚至上百路1080P视频流。如果让我用一句话概括它就是为了“把视频里的人和物认出来”这个单一目标而生的专业卡。2. 为什么偏要拿Atlas去部署YOLO2.1 边缘部署YOLO的三座大山在很多真实的项目里所以人一开始都习惯用GPU服务器跑YOLO。模型训练当然没问题轮到部署的时候就头疼了主要是三座大山。第一是功耗。一张中高端GPU卡动不动两三百瓦数据中心机房的单机柜功耗是有上限的。我接过一个智慧安防项目机房就给了20A的PDU插两台GPU服务器就快跳闸了根本没法扩容。Atlas 300V的整卡功耗只有几十瓦一台2U服务器插四张卡整机功耗轻松控制在几百瓦以内这是它真正能落地的原因之一。第二是成本。GPU推理卡的市场价大家心里都有数对于那种“只需要跑YOLO识别不需要训练”的生产项目用通用GPU其实有点浪费。Atlas 300V这种专用推理卡的单价和整体TCO相对更低尤其在需要大规模铺量的场景下价格差会直接决定项目能不能中标。第三是视频解码。很多目标检测项目不只是对静态图片做推理而是要处理实时视频流。GPU虽然也能解码视频但解码和推理抢的是同一份算力搞不好帧率就掉了。Atlas 300V板上集成了硬件解码器把视频解码、图像缩放这些活从CPU和AI Core上解放出来我在实际测试里处理1080P视频流的整链路时延比通用GPU方案稳定得多。2.2 Atlas方案的核心优势与代价拿Atlas 300V 24G来部署YOLO优势很清晰显存大发热低解码强支持多路并行。但代价同样明显第一生态工具链没有CUDA那么成熟很多在PyTorch里一句话搞定的事到了Atlas这边要自己写后处理第二模型版本支持有滞后最新最前沿的网络不一定能立刻跑到Atlas上第三资料分散官方文档更新频繁网上的教程版本差异大照着旧教程操作经常报错。这也是我写这篇文章的出发点不是吹这张卡有多神而是把真实情况说清楚。如果你的项目是长期跑YOLO推理、对功耗和成本敏感、又需要处理大量视频流那Atlas 300V是一套非常值得考虑的方案。但如果你是搞模型研究、天天要改网络结构做试验那还是老老实实用GPU跑吧别跟自己过不去。3. 部署前的环境准备与CANN工具链3.1 硬件安装和驱动固件刷写流程Atlas 300V 24G的外观就是一块标准全高全长PCIe卡安装本身没什么难度插进服务器PCIe x16插槽、接上辅助供电就行。但真正容易出问题的是驱动和固件的安装。我强烈建议你第一次装的时候单独找一台测试机不要直接在产线上折腾。驱动和固件的安装顺序非常重要基本原则是先装驱动再刷固件最后装CANN Toolkit。驱动负责让操作系统识别硬件固件则管硬件自身的控制和升级CANN是上层软件开发套件。三者版本必须配套否则后患无穷。以我常用的环境为例操作系统是Ubuntu 20.04.5 LTS内核版本5.4昇腾驱动版本为24.1.rc1配套固件也是24.1.rc1CANN Toolkit版本为7.0.0.1。这套组合在我这边跑了半年多非常稳定。# 安装驱动注意是.run文件需要root权限 ./Ascend-hdk-310P-npu-driver_24.1.rc1_linux-aarch64.run --full # 安装固件 ./Ascend-hdk-310P-npu-firmware_24.1.rc1_linux.run --full # 重启后用npu-smi命令查看是否识别到卡 npu-smi infonpu-smi命令类似NVIDIA的nvidia-smi能看到卡的芯片温度、显存占用、算力使用率。如果这条命令能正常列出Atlas 300V说明驱动和固件已经基本就位。注意驱动包和固件包要区分架构x86服务器选x86_64的包ARM服务器选aarch64的包别下错了。3.2 CANN Toolkit安装与配置驱动和固件搞定之后下一步就是安装CANN。CANN是昇腾AI处理器的软件栈总称它包含算子库、图编译引擎、运行时环境、推理应用开发接口等。你在Atlas上跑YOLO本质就是把PyTorch模型转成CANN认识的OM格式然后用CANN提供的API在卡上执行推理。CANN Toolkit的安装比较简单解压后执行安装脚本就行但有几个环境变量必须配好否则编译和运行都会找不到头文件和库文件。我通常把这些配置写到 /etc/profile 或当前用户的 ~/.bashrc 里。# 安装CANN Toolkit以7.0.0.1版本为例 ./Ascend-cann-toolkit_7.0.0.1_linux-x86_64.run --install # 将以下环境变量追加到 ~/.bashrc source /usr/local/Ascend/ascend-toolkit/set_env.sh安装完成后建议跑一下官方自带的样例检测环境是否OK。CANN安装目录下有 samples 目录很多样例可以直接编译运行。比如你可以先跑一个基于ResNet50的图像分类样例如果能输出正确分类结果说明从硬件到软件栈全部打通然后再进入YOLO部署环节。这一步不要省很多人环境没打通就急着转YOLO结果报错都不知道该排查硬件还是软件。4. YOLOv5从PyTorch到Atlas的完整落地4.1 把PyTorch模型导出为ONNXAtlas本身不直接运行PyTorch的.pt权重它认的是OM格式。从PyTorch到OM中间通常要经过ONNX这个中间格式。简单说PyTorch导出ONNXONNX再通过ATC工具转成OM。我用YOLOv5举例因为它的导出脚本最成熟部署资料也多。YOLOv8的做法类似只是输出头的结构不同后处理要自己适配。导出ONNX的命令非常简单YOLOv5官方仓库已经帮你封装好了。python export.py --weights yolov5s.pt --include onnx --opset 11但有几个细节必须注意。第一opset版本尽量选11或12太高可能在ATC转换时报算子不支持。第二导出时如果报错提示某个算子不兼容可以先升级onnx和onnx-simplifier再做简化。我遇到过几次因为版本问题导出的ONNX里带了一些冗余算子用python -m onnxsim yolov5s.onnx yolov5s_sim.onnx简化后ATC转换就通了。第三导出时默认输入是动态shape但我建议在部署阶段固定成静态shape也就是batch size固定为1或4输入尺寸固定为640x640。静态shape可以让Atlas发挥最大性能动态shape虽然灵活但运行时会有额外的shape推导开销。4.2 用ATC把ONNX转成OM模型拿到ONNX文件后下一步就是用ATC把模型转成OM。ATC是CANN工具链里的离线模型转换工具它会对模型做算子调度优化、内存复用规划甚至会针对具体芯片型号做指令重排这一步是Atlas性能的来源之一。ATC转换命令的核心参数就几个但每一个都不能写错。# 关键参数说明 # --model输入ONNX路径 # --framework5表示ONNX # --output输出OM文件路径 # --input_shape指定输入张量形状这里对应导出的ONNX # --soc_version芯片型号300V Pro对应Ascend310P3 # --log日志级别报错时改成debug才能看到详细原因 atc --modelyolov5s_sim.onnx --framework5 --outputyolov5s_bs1 --input_shapeimages:1,3,640,640 --soc_versionAscend310P3 --loginfo这里我强调一下 soc_version 这个参数它是整个命令里最容易出错的地方。Atlas 300V Pro使用的芯片是昇腾310P系列ATC工具要求你必须指定到具体的型号。怎么确认你的卡到底是哪个型号在安装好驱动后执行npu-smi info它会显示芯片名称。如果显示Ascend 310P3那就填Ascend310P3。如果填错了转换过程会直接报错提示当前芯片类型不匹配。转换成功后会在输出路径得到yolov5s_bs1.om这个文件就是Atlas上能直接加载的“可执行模型”了。我可以先给你看转换成功时的关键输出一般末尾会出现[INFO] ATC run success这样的提示没有报错的时候耐心等几分钟就好。4.3 编写pyACL推理程序模型转好后接下来就是写推理代码。Atlas上做推理最常用的接口是ACLAscendCL它分为C语言接口和Python接口Python接口叫pyACL。pyACL的用法和CUDA Runtime API有些类似先初始化设备再加载模型然后分配输入输出内存执行推理最后释放资源。我直接给你一个最小可运行的推理代码框架它的逻辑非常简单就是加载OM模型、构造一个随机输入、执行一次推理然后释放资源。import acl import numpy as np def setup_device(device_id0): acl.init() acl.rt.set_device(device_id) context, ret acl.rt.create_context(device_id) return context def load_model(model_path): model_id, ret acl.mdl.load_from_file(model_path) return model_id def prepare_buffer(model_id): # 获取模型输入输出描述信息 input_desc acl.mdl.get_input_desc(model_id) output_desc acl.mdl.get_output_desc(model_id) # 这里简化处理直接从描述中取尺寸并分配设备内存 input_size acl.mdl.get_input_size_by_index(model_id, 0) output_size acl.mdl.get_output_size_by_index(model_id, 0) input_ptr, ret acl.rt.malloc(input_size, 2) output_ptr, ret acl.rt.malloc(output_size, 2) return input_ptr, input_size, output_ptr, output_size def inference(model_id, input_ptr, input_size, output_ptr, output_size, input_data): # 把numpy数组拷贝到设备内存 acl.rt.memcpy(input_ptr, input_size, input_data.tobytes(), input_size, 1) # 执行推理 acl.mdl.execute(model_id, input_ptr, input_size, output_ptr, output_size) # 把输出拷回主机 output_data acl.rt.memcpy_d2h(output_ptr, output_size) output_np np.frombuffer(output_data, dtypenp.float32) return output_np if __name__ __main__: context setup_device(0) model_id load_model(b./yolov5s_bs1.om) input_ptr, input_size, output_ptr, output_size prepare_buffer(model_id) # 构造一个与模型输入匹配的随机数据1x3x640x640 fake_input np.random.randn(1, 3, 640, 640).astype(np.float32) result inference(model_id, input_ptr, input_size, output_ptr, output_size, fake_input) print(inference done, output shape:, result.shape) acl.mdl.unload(model_id) acl.rt.free(input_ptr) acl.rt.free(output_ptr) acl.rt.reset_device(0) acl.finalize()从这段代码你能看出Atlas推理的基本流程跟CUDA真的很像主机和设备的内存是分开的推理前要把数据拷进去算完再把结果拷出来。但真正的项目里YOLO的输出并不是直接可用的坐标框你还需要做后处理包括解码预测框、置信度过滤、NMS等。这一步各家写法不同但逻辑大同小异。4.4 性能优化三板斧模型能跑通只是第一步生产环境里更关心的是吞吐和时延。我在优化Atlas上YOLO推理性能时主要用三招。第一招是把图像预处理搬到AIPP里。AIPP是CANN提供的硬件图像预处理模块它可以直接在芯片内部完成缩放、减均值、除标准差、颜色空间转换等操作。你在OM转换时加上AIPP配置推理时只需要把原始图片数据塞进去芯片自动帮你对齐到模型输入。这样CPU释放出来了图片预处理耗时可降低一个数量级。这是Atlas和GPU一个很不一样的地方算力分配更灵活。第二招是开启多batch推理。YOLOv5在导ONNX时可以导出固定batch为4或8的版本一次推理同时处理4张图吞吐量能提升好几倍。前提是业务允许攒够一批再推理如果你的场景是对实时性要求极高的单路视频流多batch反而会增加时延要权衡。第三招是使用流和异步执行。pyACL支持创建多个stream推理操作可以放到不同stream上并发执行。再加上图像解码、预处理、推理、后处理按流水线排布整链路吞吐会显著提升。我在一个智慧交通项目里把四路1080P视频流分别放到四个stream里并行执行每一路的推理时延都稳定在十几毫秒级别CPU占用还不到40%。5. 我踩过的坑和排查技巧实录5.1 卡在驱动版本和固件版本不匹配上这个坑我印象最深。有一台新到的服务器我照着手头旧文档的步骤装好了驱动跑npu-smi也能看到卡但是一跑CANN的样例就报驱动版本不兼容。查了半天发现CANN 7.0对驱动版本有最低要求旧驱动虽然能让硬件工作但上层软件栈认不出来。后来我把驱动、固件、CANN全部统一成同一个版本批次问题立刻消失。所以我的经验是在上生产环境之前先去昇腾社区看一下版本配套表严格按照官方推荐的组合来装。驱动的安装日志也可能出现“firmware version is not match”这种字样看到这种提示别犹豫直接升级固件。5.2 模型转换失败常见原因ATC转换报错是新手遇到最多的拦路虎。常见的报错有几类第一类是“Unsupport op”意思是有算子不支持。解决办法是先把ONNX做简化再换一个opset版本重新导出如果还不行就要检查模型里有没有特殊算子。第二类是“Input shape mismatch”常见原因是ATC参数里的input_shape和ONNX的实际输入形状对不上检查一下导出时设置的输入名是不是“images”YOLOv5导出时默认输入节点名就是images。第三类是“Soc version not support”这就是之前说的芯片型号填错了用npu-smi查一下再填。5.3 推理结果不对时的排查思路如果模型转换成功、推理也执行了但输出结果完全不对先不要怀疑卡坏了多半是预处理环节出了问题。YOLOv5训练时对输入图片做的归一化通常是把像素值除以255如果推理时你把0到255的原始像素直接塞进模型输出的置信度会全面漂移。另外图像缩放的方式也有讲究YOLOv5使用的是letterbox等比缩放会在图片四周补灰边如果你直接把图片拉伸成640x640检测框的位置也会偏。排查时建议先固定一张已知结果的图片把预处理后喂给模型的输入数据打印出来对比PyTorch端的结果一步一步缩小范围。只要预处理一致、模型权重一致Atlas的推理结果和GPU端的浮点结果误差通常非常小在目标检测这种任务里基本可以忽略不计。5.4 一张速查表帮你快速定位症状可能原因处理思路npu-smi 看不到卡驱动未装成功或PCIe没识别重装驱动检查lspci是否识别到设备跑样例报版本不兼容驱动/固件/CANN版本不配套按官方版本配套表统一升级ATC转换报Unsupport opONNX算子太新或太旧用onnxsim简化、调整opset版本重新导出ATC转换报Soc version不支持芯片型号填错用npu-smi info查实际芯片型号推理执行但结果全错预处理不一致如没归一化对照PyTorch端预处理逐项排查推理速度很慢未用AIPP或单batch推理开启AIPP考虑多batch和异步流我个人在实际操作中最深的体会是Atlas这块卡本身并不“难”难的是你愿不愿意接受一套和CUDA完全不同的思维模式。不要用写GPU代码的习惯去套尊重它的工具链耐心看版本文档把每一步先跑通再优化。如果你正打算在Atlas 300V 24G上部署YOLO照着我这篇流程走一遍应该能比当初摸黑前进的我少走很多弯路。
返回列表