尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

Atlas 300V Pro 24G上跑通YOLOv5s:从模型转换到推理加速全指南

发布时间:2026/9/25 6:41:45

资讯中心
01
ARTICLE

Atlas 300V Pro 24G上跑通YOLOv5s:从模型转换到推理加速全指南

Atlas 300V Pro 24G上跑通YOLOv5s:从模型转换到推理加速全指南
最近项目里调过来一块Atlas 300V Pro 24G要在上面把YOLOv5s的检测模型跑起来做视频流实时识别。从拆包到推理上线前后折腾了将近两周大部分时间都耗在环境搭建、模型转换和算子兼容的坑里。写这篇文章一是把从零到能跑通的完整路径整理出来二是顺便回答一个我被问了很多次的问题Atlas 300V 24G到底算不算一块“运算加速卡”它跑YOLO又能跑到什么程度如果你手里刚拿到昇腾系列的卡或者正打算把YOLO系列模型从GPU迁到Atlas上这篇应该能帮你少走不少弯路。1. 硬件认知Atlas 300V Pro 24G到底是一张什么卡1.1 关于“运算加速卡”的纠偏先说结论Atlas 300V Pro 24G是一块典型的AI推理加速卡不是训练卡也不是传统意义上的显卡。很多人一看到“24G”就自动跟显卡的24G显存画等号这个思维要改过来。它板载的24GB是LPDDR4X内存承担的角色类似GPU的显存负责存放模型权重和中间特征图但带宽、延迟和编程方式都和GDDR/ HBM那一套不太一样。昇腾这张卡的定位非常明确边缘推理。常见落地场景包括视频结构化、安防监控里的目标检测、OCR识别、工业质检等等。它的核心优势是单位功耗下的推理吞吐整卡功耗不高却能跑出不错的INT8/FP16性能。你要拿它跑训练那基本是找错对象了反向传播、动态shape这类训练需求不是它的强项官方工具链也完全没有往这个方向优化。所以回到热搜问题本身atlas 300v 24g是运算加速卡吗是的它是运算加速卡准确说是AI推理运算加速卡。但它不是给你打游戏用的显卡也不是能跑CUDA代码的GPU。它的“加速”是有前提的模型要经过离线转换变成昇腾硬件能直接执行的om格式再通过昇腾自己的计算架构CANN来调度。理解了这一点后面的部署流程就顺理成章了。1.2 部署前必须搞清楚的软件栈在动手装东西之前我建议先把昇腾的软件体系在脑子里过一遍。它跟CUDA生态的对应关系大概是这样的驱动层Ascend HDK对标NVIDIA驱动装完以后用npu-smi能看到卡的状态。计算架构层CANN对标CUDA。它里面包含了运行时、算子库、图编译器和各种工具。推理框架层MindX SDK、MindSpore等对标TensorRT和PyTorch。模型格式.om离线模型对标TensorRT的.engine文件。所有模型在部署前都要过一遍ATC工具生成om才算真正“编译”到了昇腾硬件上。初次接触昇腾的人最容易犯的错就是拿着一个PyTorch的.pt权重文件直接问“怎么加载”。在昇腾上没有那么直接的路PyTorch模型不能直接跑必须先导出成ONNX再用ATC转成om。也就是说模型要经过两次格式转换。这个流程初看很麻烦但换个角度想TensorRT部署不也是把模型转成engine吗只是昇腾这套工具链在报错信息、文档完善度上确实和CUDA生态的成熟度还有差距需要多一点耐心。下面我把每一步实际怎么操作踩过哪些坑都写清楚。2. 环境准备从硬件安装到CANN跑通2.1 硬件安装与驱动检查Atlas 300V Pro是PCIe接口的卡安装本身不复杂关机、插卡、上电、开机。需要注意的是供电这张卡的功耗虽然不算夸张但一定要确认主板PCIe插槽能提供足够的功率或者单独接好辅助供电线。我遇到过插上去之后npu-smi里一直看不到卡的情况最后发现是供电不足导致的。开机进系统之后第一步永远是看驱动有没有装上、卡有没有被识别。命令是npu-smi info如果正常会列出卡的型号、芯片信息、温度、功耗、显存占用这些。如果提示找不到命令说明驱动还没装需要先装Ascend HDK。驱动安装包是一个.run文件安装命令基本是chmod x Ascend-hdk-*.run ./Ascend-hdk-*.run --full装完之后再用npu-smi info确认一次。这里有个细节驱动版本和CANN版本有对应关系装之前最好去官网查一下兼容性列表否则后面前后版本不匹配会出现各种诡异的报错排查起来非常头疼。2.2 CANN工具链安装与验证驱动正常之后接下来装CANN。我使用的是CANN Toolkit安装包同样是.run文件。安装命令chmod x Ascend-cann-toolkit_7.0.RC1_linux-aarch64.run ./Ascend-cann-toolkit_7.0.RC1_linux-aarch64.run --full注意我这里的平台是aarch64如果你的机器是x86架构要下载对应版本。安装完成后需要source一下环境变量脚本source /usr/local/Ascend/ascend-toolkit/set_env.sh建议把这个source命令写进.bashrc不然每次开新终端都要手动执行。验证CANN是否装好最简单的方式是跑一下Python接口是否能正常加载import acl print(acl.__version__)能打印出版本号说明CANN的AscendCL接口已经就绪。到这里环境基本算跑通了可以开始处理模型。3. 模型转换把YOLO变成硬件认识的“方言”3.1 先从YOLOv5导出ONNX昇腾硬件不认PyTorch的权重文件所以第一步是把.pt转成ONNX。YOLOv5官方仓库自带导出脚本直接用python export.py --weights yolov5s.pt --include onnx --opset 11 --batch-size 1 --img 640 640这里面有两个参数要特别说明。一是opset版本。我建议用11或者12不要一上来就选最新的opset。昇腾的ATC算子库对ONNX的算子支持是有版本范围的opset太高容易出现“某个算子不支持”的报错opset太低又可能丢失一些新算子的表达。实测下来11是最稳的。二是batch-size和输入尺寸。这里我强烈建议固定成1输入尺寸固定成640。为什么因为ATC转换的时候如果模型是动态shape生成的om在推理时每次遇到不同尺寸都要重新做图优化性能损失非常大。固定shape虽然灵活度低但对推理场景来说batch1是常态640x640也是YOLOv5的默认训练尺寸完全够用。导出之后可以用ONNX Runtime简单验证一下onnx模型能否正常前向推理这一步能提前发现模型本身的问题避免混入后面ATC转换的问题里。3.2 ATC转换核心命令逐段拆解拿到onnx模型之后下一步是用ATC工具把它转成om。这也是整个部署流程里最容易出问题的一步。先看一个能跑通的完整命令atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_fp16 \ --input_shapeimages:1,3,640,640 \ --output_typeFP16 \ --insert_op_confaipp.cfg \ --soc_versionAscend310P3逐个参数说--framework55代表ONNX这是ATC约定好的编码固定别改。--output输出om文件的名称前缀。--input_shape指定输入张量的shape必须和导出onnx时的形状一致。这里YOLOv5的输入名默认是images。--output_typeFP16指定模型权重和计算的精度。昇腾推理卡对FP16和INT8支持最好默认FP16就行能跟FP32拉开不少速度差距精度损失在一个可接受的范围内。--insert_op_conf插入AIPP预处理配置后面单独讲。--soc_version芯片版本号这个不能乱填用npu-smi info能看到当前芯片的具体型号比如Ascend310P3然后填对应的值。执行完之后目录下生成yolov5s_fp16.om这就是能在昇腾硬件上直接执行的离线模型。3.3 AIPP配置把图像预处理搬进硬件AIPP是昇腾特别值得说的一点。它的作用是把图像预处理resize、归一化、通道变换、减均值除方差从CPU/GPU搬到硬件处理单元上推理前自动完成。配置写在一个cfg文件里比如aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 csc_switch: true rbuv_swap_switch: true 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 }这里的关键是颜色通道顺序和归一化参数必须和模型训练时保持一致。YOLOv5官方代码是用OpenCV读图OpenCV读进来是BGR顺序但模型训练时的数据增强是把图片转成RGB做的。所以AIPP配置里input_format要用RGB888_U8rbuv_swap_switch置true让硬件在做通道变换时从BGR转到RGB省去你在CPU上手动转换的开销。var_reci_chn是归一化用的0.003921569约等于1/255。如果训练时用的是标准化减均值除方差就把均值和方差填进去。很多人推理结果不对问题往往不是模型转换而是这个预处理和训练时不一致。4. AscendCL推理从设备初始化到结果输出4.1 设备与上下文初始化转换完成之后进入代码阶段。昇腾的推理编程接口叫AscendCLPython接口的封装程度不错完整写一遍流程大概三四百行。先把最关键的部分拆开说。第一步是初始化设备和上下文这跟CUDA的cudaSetDevice、创建context非常像import acl # 初始化 ret acl.init() assert ret 0 # 设置设备多卡场景按需改 ret acl.rt.set_device(0) assert ret 0 # 创建上下文 context, ret acl.rt.create_context(0) assert ret 0这段没什么坑照抄就行。但要注意进程结束前要调用acl.rt.reset_device和acl.finalize释放资源否则下次跑会报设备占用。4.2 模型加载与输入数据处理然后用acl.mdl.load_from_file加载om模型model_id, ret acl.mdl.load_from_file(yolov5s_fp16.om) assert ret 0加载完成后需要为输入输出申请设备端内存。提前用acl.mdl.get_input_size_by_index拿到输入输出的大小再用acl.rt.malloc分配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)图像数据从CPU搬到设备端使用acl.rt.memcpy# 假设 img_np 是预处理好的 np.ndarray(1,3,640,640) 的 float16 ret acl.rt.memcpy(input_ptr, input_size, img_np.ctypes.data, input_size, acl.rt.MEMCPY_DEVICE_TO_DEVICE if 已在device上 else acl.rt.MEMCPY_HOST_TO_DEVICE)这里要特别强调一个容易迷糊的点如果你开了AIPP那么传入的img_np只需要是原始RGB或BGR图像数据不需要你自己做归一化和resize如果没开AIPP那所有预处理都要在CPU端做完img_np就是float16的归一化张量。我建议能用AIPP就用AIPP因为有些硬件的图像处理单元还会做格式转换比如把JPEG直接解码成模型输入能省很多CPU。4.3 执行推理与取回输出执行推理就一行ret acl.mdl.execute(model_id, input_ptr, input_size, output_ptr, output_size)注意这是同步接口阻塞到推理完成。生产环境建议用异步接口配合acl.rt.subscribe_report能同时处理多路视频流吞吐能高一截。不过异步模式需要考虑队列和资源回收初次上手不建议直接上。推理完成后把结果拷回CPUoutput_np np.zeros(output_size, dtypenp.uint8) # 按实际类型 ret acl.rt.memcpy(output_np.ctypes.data, output_size, output_ptr, output_size, acl.rt.MEMCPY_DEVICE_TO_HOST)然后根据YOLO的输出格式把output_np按float32重新解释shape是(1, 25200, 85)。4.4 YOLO后处理解码、过滤、NMSYOLOv5的输出格式是固定的每个预测框有85个值前4个是xywh坐标第5个是objectness置信度后面80个是COCO类别得分。后处理流程是把xywh转成xyxy。计算最终得分 objectness * 类别最大得分。过滤掉得分低于阈值的框。对每个类别做NMS去除重叠框。一个简化的Numpy实现长这样import numpy as np def postprocess(pred, conf_thres0.25, iou_thres0.45): # pred shape: (25200, 85) box_xy pred[:, :2] box_wh pred[:, 2:4] obj_conf pred[:, 4] cls_conf pred[:, 5:] # 转 xyxy box_xyxy np.concatenate([ box_xy - box_wh / 2.0, box_xy box_wh / 2.0 ], axis1) # 类别得分 cls_ids np.argmax(cls_conf, axis1) cls_scores cls_conf[np.arange(len(cls_ids)), cls_ids] scores obj_conf * cls_scores # 阈值过滤 keep scores conf_thres if not keep.any(): return np.empty((0, 6)) boxes box_xyxy[keep] scores scores[keep] cls_ids cls_ids[keep] # 按类别分别做NMS num_classes cls_conf.shape[1] results [] for cls in range(num_classes): idx np.where(cls_ids cls)[0] if len(idx) 0: continue cls_boxes boxes[idx] cls_scores scores[idx] # 按得分降序 order cls_scores.argsort()[::-1] keep_final [] while order.size 0: i order[0] keep_final.append(i) ious compute_iou(cls_boxes[i], cls_boxes[order[1:]]) order order[1:][ious iou_thres] for i in keep_final: results.append([*cls_boxes[i], cls_scores[i], cls]) return np.array(results) if results else np.empty((0, 6))这段代码的核心是compute_iou函数计算两个框的交并比。用Numpy的向量化实现注意坐标截断到图像边界。如果检测目标多、类别多建议用Cython或者直接上OpenCV的NMS接口做加速纯Python的NMS在视频流场景里会成为瓶颈。5. 踩坑实录与性能调优两周实战问题记录5.1 转换阶段最常见的两类报错先说ATC转换时报错的情况。我遇到的第一类报错是“Unsupport op: Focus”。YOLOv5在v6.0之前用Focus层做下采样这个算子昇腾的ATC支持得不太好。解决方法是升级YOLOv5版本到v6.0以上或者导出onnx前把模型里的Focus替换成普通的Conv加Slice组合。我这里的做法是直接用新版本重新训练权重彻底绕开这个问题。第二类报错是算子不支持或者opset版本不合适比如“E10011: Insert op failed”或者ONNX里某个op在昇腾算子库中找不到。这种时候先去查昇腾CANN文档里的“算子支持列表”确认当前版本支持哪些opset、哪些算子。如果确实不支持可以考虑改模型结构或者升级CANN版本。总的来说ATC的报错信息已经比早期版本友好很多了但跟TensorRT的报错信息相比还是有点晦涩遇到看不懂的报错先搜一下错误码。5.2 推理结果不对的排查方向模型转换成功不代表推理结果正确。我遇到过几次典型的“转成功了但结果全零”的情况排查之后发现主要出在三个方面。一是图像通道顺序。YOLOv5训练时用的是RGB如果你用OpenCV读图直接喂给AIPP而AIPP配置里又设置了RGB888_U8结果会反过来。排查技巧是先用一张单色图测试比如纯红色图看模型输出的类别概率变化很快就能判断通道顺序是否对了。二是归一化参数。AIPP里配置了var_reci_chn0.0039结果在CPU端又手动除了一次255等于做了两遍归一化。这种情况最常见因为很多人开了AIPP之后代码里还留着原来的预处理逻辑。三是输入数据的内存对齐。昇腾的Device侧内存有对齐要求如果输入数据的指针或者size不对齐推理结果会随机出错。建议直接用acl.rt.malloc申请空间不要用普通的Numpy数组直接传。5.3 性能不达标时怎么调跑通之后进入调优阶段。我这里总结三个最有效的优化手段。第一个是固定shape加静态AIPP。模型转换时固定输入尺寸AIPP也配成static模式这样硬件侧不用为每次输入动态分配资源推理延迟能明显下降。如果你是做视频流检测输入尺寸基本都是固定的完全没必要用动态shape。第二个是精度选型。默认用FP16如果你对精度不敏感可以试INT8。INT8量化之后速度能再快一截但需要准备校准数据集做量化。量化做得好精度损失很小做不好会有明显掉点建议先在测试集上验证。第三个是用profiling工具定位性能瓶颈。CANN自带msprof运行推理时开一下抓profiling数据能看每个算子的耗时。很多情况下你会发现某个算子根本不在硬件上执行而是在CPU上兜底跑这种就是算子不兼容导致的性能黑洞需要调整模型结构或者换一个算子组合。这些调优做完之后YOLOv5s在640x640输入下单卡推理延迟大概能稳定在十几毫秒量级配合多路视频流做并行处理吞吐表现很不错。最后分享一点个人的操作体会Atlas这套生态确实不如CUDA生态顺手很多问题网上资料少需要自己翻文档和试错。但一旦把模型转换的流程摸透把AIPP和后处理的逻辑理顺推理阶段是相当稳定的功耗和成本也比同等性能的GPU卡有优势。如果你们项目有边缘端实时检测的需求又不想被GPU的功耗和价格劝退Atlas 300V Pro 24G绝对值得认认真真试一把。
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

◈

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

◐

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

▲

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。