拿到Atlas 300V 24G这块卡的第一时间我就知道又有很多人要踩坑了。后台经常收到两类私信一类是问我“Atlas 300V 24G是运算加速卡吗”另一类就是“Atlas部署YOLO到底能不能跑起来、怎么跑起来”。今天我把这两件事放到一起回答这块卡确实是推理加速卡不是通用GPU而用它部署YOLO只要你把环境和转换流程摸透一天内就能出第一版结果。我最早接触Atlas系列的时候也犯过用GPU的习惯去揣测它结果被驱动、算子、模型转换这些环节轮番教育了一顿。后来在多个项目里用Atlas 300V做过视频流检测、工业缺陷识别、园区安防的推理部署慢慢才摸清楚这套工具链的脾气。这篇内容我不讲PPT上的参数只聊实际动手部署YOLO时会遇到的真实问题卡是什么定位、环境怎么搭、模型怎么转、跑起来之后怎么调优、挂了怎么排查全程按我自己的操作习惯来写。1. 项目背景与核心需求拆解1.1 Atlas 300V 24G到底算什么卡很多人第一次看到Atlas 300V 24G第一反应是拿来和NVIDIA的RTX系列比然后问它能不能训练。这里必须先说清楚Atlas 300V不是通用GPU它是一张AI推理加速卡拿它做训练属于用错工具。从硬件规格看Atlas 300V集成的是昇腾310P系列芯片24GB的LPDDR4X显存整卡功耗大概72W半高半长单槽设计能塞进大多数2U服务器。INT8算力在280 TOPS左右这个数字听起来很吓人但实际使用时要分清楚它主要吃的是定点推理负载而不是FP32高精度训练负载。你可以把它理解成一个专门做“填空题”的加速器——模型训练好之后它的职责就是拿训练好的参数去对新输入做快速计算而不是自己去调整参数。所以在选型的时候我的判断标准一般是这么几条如果需求是训练模型、调网络结构、做实验优先用GPU。如果需求是把一个训练好的YOLO模型部署到生产环境做视频流或图片检测Atlas 300V是很有性价比的选择。如果需求同时包含训练和推理且推理侧要求低延迟、低功耗可以训练用GPU、推理用Atlas两边各干各的。1.2 部署YOLO的真实场景和预期收益Atlas部署YOLO的应用场景我接触最多的是视频结构化分析。比如一个工厂有几十路摄像头要实时检测人员有没有戴安全帽、有没有越界或者园区里检测车辆违停这类任务共同的特点是模型本身不算太大但视频路数多、要求长期稳定运行。用Atlas 300V做这样的活优势恰好能发挥出来24GB显存能装下好几个模型实例或者把输入batch调大提高吞吐72W功耗放在机房里根本不叫事单槽设计不占空间一台4U服务器插4到8张卡都很方便。从我实测的情况看一个YOLOv5s模型转成OM格式之后在Atlas 300V上跑1080P视频流单路推理延迟能控制在十几毫秒到几十毫秒之间具体看输入分辨率和batch设置。如果只做单张图片检测延迟会更低。这样的性能用来做实时检测绰绰有余关键是成本控制和功耗控制比GPU方案强不少。2. 硬件选型与整体方案设计2.1 为什么选Atlas 300V而不是其他型号Atlas系列里还有Atlas 300I Pro、Atlas 300T等型号我第一次做选型的时候也纠结过。后来按项目需求捋了一遍发现选卡主要看三件事算力类型、显存容量、物理接口。Atlas 300V有24GB显存这是它最吸引我的地方。很多推理模型本身不大但输入分辨率高或者用了较大的batch显存就容易吃紧。24GB在这个价位段能覆盖绝大部分YOLO部署需求不用天天琢磨怎么压缩输入尺寸。对比Atlas 300I Pro那张卡主打的是低功耗和小体积显存相对小一些适合对功耗极其敏感的嵌入式场景而Atlas 300V更适合标准服务器机箱性能和显存比较均衡。如果是要跑特别大的模型比如YOLOv5x或者YOLOv8x还想开大batch那就要考虑更大显存的型号或者用多卡并行。但大多数人手里的业务YOLOv5s、YOLOv5m、YOLOv8s这个级别就够用了24GB完全撑得住。2.2 软硬件协同的整体架构Atlas部署YOLO不是光插一张卡就能跑的它需要一套完整的软件栈。我习惯把整个架构拆成四层第一层是硬件层就是Atlas 300V物理卡和服务器。注意服务器主板要有PCIe x16插槽供电要够散热风道要合理尤其是多卡场景卡与卡之间的距离直接影响散热效率。第二层是驱动和固件层。NVIDIA有NVIDIA DriverAtlas这边有对应的驱动包和固件包安装后通过npu-smi工具能看到卡的状态。这一层如果不装好后面一切免谈。第三层是CANN工具链。CANN是昇腾的计算架构类似于CUDA的角色。它包含运行时、算子库、图编译工具还有Python接口。模型转换用的ATC工具就集成在CANN里。第四层是应用层也就是我们自己的推理程序和业务逻辑。可以用C写也可以用Python写官方提供了pyACL和MindSpore Lite两套推理API。这套架构和GPU开发的CUDAcuDNNTensorRT的组合非常相似。如果你之前搞过TensorRT理解起来会非常快ATC转换相当于用TensorRT生成engineOM模型相当于TensorRT的engine文件pyACL调用就相当于用TensorRT的Python绑定跑推理。2.3 驱动、固件与CANN版本匹配的坑说到CANN就不得不提版本匹配的问题。这是我见过的翻车率最高的环节也是最容易被忽略的。Atlas 300V的驱动、固件、CANN三者必须严格匹配否则就会出现“卡能被系统识别但跑不了推理”或者“ATC转换时报内部错误”的诡异问题。我装过几次之后总结出一个原则去昇腾官网的软件包列表页面找到对应硬件型号的“驱动-固件-CANN配套表”按这个表格选版本不要自己乱搭配。具体操作时先装驱动和固件再装CANN。装CANN的时候可以选社区版或商业版社区版功能足够个人学习和一般商用项目使用。装完之后用npu-smi info验证驱动是否正常然后跑一个简单的CANN样例比如ResNet50推理确认整个链路通了再继续做YOLO部署。3. 环境准备与基础配置3.1 服务器系统与依赖包清单我用来部署的服务器系统是Ubuntu 20.04 x86_64这也是昇腾官方支持比较成熟的组合。系统装好后先做基础配置安装gcc、g、make等编译工具因为CANN有的组件需要本地编译。安装Python 3.7到3.10之间的版本官方对Python版本有要求太新太旧都可能出问题。我推荐Python 3.8或3.9兼容性最稳。配置pip源后续安装依赖包会快很多。设置BIOS里的PCIe为Gen4模式如果主板支持确保卡能跑满带宽。有个小细节服务器的内存不要太小虽然推理主要在NPU上跑但数据预处理图像解码、缩放、归一化还是占CPU和内存的。我建议至少32GB内存起步如果同时开多路视频流64GB更保险。3.2 CANN工具链安装的完整流程CANN安装步骤不复杂但每一步都可能踩出莫名其妙的坑。我把我验证过的流程写出来下载驱动和固件包文件名一般是Ascend-hdk-...run格式。以root用户执行驱动安装脚本./Ascend-hdk-....run --full。安装完成后用npu-smi info查看卡信息确认有正常的芯片信息和温度显示。如果有多个驱动版本残留先清干净再装。用npu-smi info如果显示异常多半是驱动没装干净。下载CANN toolkit执行./Ascend-cann-toolkit_...run --install。安装路径默认在/usr/local/Ascend我没有改过建议按默认来省得后面环境变量出幺蛾子。配置环境变量把/usr/local/Ascend/ascend-toolkit/set_env.sh加入/etc/profile或~/.bashrc。装完之后验证一下终端输入atc --version如果能输出版本号说明ATC工具正常。输入python -c import acl如果不报错说明Python接口正常。3.3 用npu-smi确认卡是否正常识别这里我多说一句npu-smi的使用。很多朋友第一次拿到Atlas卡插上之后发现npu-smi info看不到卡第一反应是卡坏了。其实大多数情况是驱动没装好或者卡没被系统枚举到。排查顺序是这样的先看操作系统是否识别到PCIe设备lspci | grep -i ascend或lspci | grep -i huawei确认有设备出现。再确认驱动是否加载lsmod | grep drv_pcie看到驱动模块才说明驱动已经加载。最后用npu-smi info看卡详情。还有一种情况服务器启动了IOMMU可能导致PCIe设备无法正常访问。这不是Atlas特有的问题所有PCIe加速卡都会受影响。解决方法是进BIOS关掉IOMMU或者在内核启动参数里加iommupt。这个坑比较隐蔽我一度以为是卡坏了后来排查了半天发现是BIOS设置问题。4. YOLO模型转换从PyTorch到OM4.1 ONNX导出模型转换的第一步Atlas的推理模型是OM格式但平时训练模型用PyTorch、TensorFlow或者MindSpore不可能直接拿训练出的权重文件去跑推理。常规路线是先把PyTorch模型导出为ONNX再用CANN的ATC工具把ONNX转成OM。YOLO系列的ONNX导出我建议直接用官方仓库里的export.py脚本。以YOLOv5为例python export.py --weights yolov5s.pt --include onnx --opset 11这里有个关键参数--opset。ATC工具对ONNX算子版本有兼容性要求我实测用opset 11最稳用更高的opset版本偶尔会出现算子不支持的情况需要额外处理。导出之后用onnxsim对模型做一次简化是一个好习惯。因为PyTorch导出的ONNX里往往带着不必要的形状推测节点和冗余算子简化之后不仅文件体积变小ATC转换的成功率也会提高python -m onnxsim yolov5s.onnx yolov5s_sim.onnx4.2 ATC转换命令与常用参数解析模型转换是很容易出问题的一步。我用得最多的ATC命令是这样atc --modelyolov5s_sim.onnx \ --framework5 \ --outputyolov5s_16 \ --input_shapeimages:1,3,640,640 \ --input_formatNCHW \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP16 \ --precision_modeforce_fp16各参数的意思分别是--model输入ONNX文件路径。--framework5表示输入模型是ONNX。--output输出OM文件的路径前缀。--input_shape固定输入形状。这里写成1,3,640,640表示batch为1、3通道、640x640分辨率。--input_format输入数据排布格式NCHW是默认常用。--soc_version芯片型号。Atlas 300V对应的soc_version一般是Ascend310P3这个可以在昇腾官方文档里查到。--insert_op_conf插入AIPP预处理配置。--output_type和--precision_mode控制输出精度和转换精度模式一般保持FP16。input_shape里面有一个容易被忽略的点YOLO模型导出后输入名字默认是images但不同版本的YOLO仓库可能把它改成别的名字。转换报错提示找不到输入节点的时候用netron打开ONNX文件看一眼输入节点名称就知道该填什么了。4.3 AIPP预处理配置让预处理进硬件AIPP是Atlas的一个特色功能可以在模型转换阶段把图像预处理缩放、减均值、除方差、通道变换固化到模型里推理时只要往NPU里丢原始图像数据就行省掉CPU上的预处理时间。我使用的aipp.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: false crop: false mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 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尺寸通道顺序是RGB不做裁剪把像素值除以255即乘1/255。注意YOLOv5在训练时归一化是除以255这里直接对应上传原始图像数据进模型即可。如果输入图像不是固定尺寸需要缩放AIPP也有resize的配置项。但我的经验是如果服务器CPU算力足够把resize留在CPU上做反而更灵活因为有时候输入的宽高比和模型的640x640不同单纯拉伸会导致检测精度下降需要自己控制等比缩放和填充的细节。AIPP适合输入基本固定、追求极致吞吐的场景。4.4 动态batch与多路视频流场景的转换策略实际部署时经常遇到这样的需求同一路视频流有时需要单帧检测有时需要合并几帧一起送进去提高利用率。这种情况下模型如果只支持固定batch1用起来就很被动。ATC工具支持动态batch在转换时把input_shape里的batch设成动态范围--input_shapeimages:-1,3,640,640 \ --dynamic_batch_size1,2,4,8这样生成的OM模型可以在运行时从1、2、4、8这几个batch中选一个灵活度明显提高。但动态batch会占用更多NPU内存因为NPU需要为每一种可能的分档预留资源。我的建议是分档不要设太多1、2、4、8四个档位足够覆盖绝大多数场景运行推理时优先用大batch能显著提高吞吐。5. 推理代码实现与调优5.1 基于acllite的Python快速实现我之前做过一段时间的GPU推理转到Atlas之后最大的感受是底层接口确实跟CUDA不一样但用官方封装好的acllite库之后写代码的复杂度直线下降。acllite把图像解码、缩放、模型推理、后处理封装成了简单的接口对快速验证非常友好。一个最简推理流程的例子import acl from acllite.acllite_model import AclLiteModel from acllite.acllite_image import AclLiteImage from acllite.acllite_utils import * ACL_DEVICE_ID 0 def init(): ret acl.init() assert ret 0 ret acl.rt.set_device(ACL_DEVICE_ID) assert ret 0 def main(): init() model AclLiteModel(yolov5s_16.om) image AclLiteImage(test.jpg) result model.execute(image) print(result) if __name__ __main__: main()这段代码只是演示链路是否通畅真正生产环境还要加上后处理。YOLO模型的输出是三个尺度的特征图每个尺度包含边界框坐标、置信度和类别概率需要经过解码、NMS、坐标映射才能得到最终检测框。这部分逻辑我建议完全复用YOLOv5官方仓库里的后处理代码只是把输入从PyTorch张量换成NPU推理得到的numpy数组即可。5.2 使用numpy从NPU输出解析YOLO结果的思路Atlas推理输出的原始数据是一个numpy数组但它的形状往往不是我们习惯的PyTorch张量形状。不同版本的YOLO导出后的输出节点数量不同比如YOLOv5的三个输出节点每个节点形状大致是[1, 255, 80, 80]、[1, 255, 40, 40]、[1, 255, 20, 20]这里的255等于(5 类别数) * 35是x,y,w,h,conf3是anchor数量。拿到输出后需要把它从CHW格式reshape成更适合后处理的格式再把三个尺度的结果concat起来最后做阈值过滤和NMS。这些操作在CPU上跑也不会成为瓶颈因为输入分辨率不大、目标数量有限。有一点要提醒如果不使用AIPP那么送入NPU的图片必须在CPU侧提前做减均值、除方差、通道变换。YOLOv5的预处理逻辑是BGR转RGB、除以255、再缩放。跟AIPP配置相比CPU侧预处理更灵活但会占用CPU时间。在视频流场景里如果CPU核数少、路数多建议还是把预处理交给AIPPCPU只负责解码和送帧。5.3 24GB显存如何规划batch和并发路数24GB显存并不是越多越好因为要平衡延迟和吞吐。YOLOv5s输入640x640时单张图的NPU内存占用并不大但模型转换时动态batch、多档分档会额外预留内存。固定batch1时整张OM模型的NPU内存占用大概在几百MB到1GB之间所以24GB理论上可以加载多个模型实例。我常用的规划方法是按“模型实例数 × 单个实例内存”来估算。比如一个YOLOv5s的OM模型占用约800MB那么24GB可以放20多个实例。但实际不会这么激进因为还要留出输入输出缓冲区和系统管理内存。多实例有两种玩法一种是在Python进程里创建多个AclLiteModel对象每个对象绑定同一个NPU设备的不同context分别跑不同视频流另一种是启动多个进程每个进程加载同一个OM模型通过进程隔离提高稳定性。我实际建议用多进程因为Python的GIL会限制多线程推理效率多进程能真正用满NPU。在单进程多线程的模式下我也做过测试并发路数超过一定值后推理延迟会明显上升原因是NPU任务排队。24GB显存够用但推理带宽上限是硬件决定的不是显存决定的。一般建议每张Atlas 300V跑4到8路1080P视频流具体要测一下实际帧率和延迟。5.4 推理延迟的评估方法评估Atlas推理性能不能只看单帧推理时间还要看整体流水线的耗时。我一般用三个指标单帧NPU推理延迟从调用模型推理接口到拿到输出原始数据的时间。端到端检测延迟从图像采集、预处理、推理、后处理到拿到结果框的时间。吞吐量单位时间内处理多少帧或多少路视频流。具体测试时用time.time()打点记录每个阶段的耗时。如果发现端到端延迟远大于NPU推理延迟瓶颈大概率在图像解码或预处理上。这种情况可以尝试用硬件解码器Atlas卡上带有视频解码能力或者优化图像resize的算法。还有一个评估细节NPU推理有预热过程。第一次调用推理接口时耗时明显偏长这是正常现象。连续跑几十帧之后耗时才会稳定在正常水平。所以测性能时一定要先跑一定数量的warmup再开始统计。6. 高频问题与排查实录6.1 算子不支持导致ATC转换失败这是Atlas部署YOLO最常见的问题。ATC转换时报错信息里包含类似Unsupported op或Cannot find op的提示后面跟着一个算子名字。排查思路很简单用netron打开ONNX模型找到报错算子所在的位置看它是什么类型的算子。YOLO系列里最容易出问题的算子一般是动态shape相关的操作比如Resize在某些opset版本下会展开成多个算子ATC对其中部分不支持。GridSample或者一些自定义算子这种情况基本无解需要换模型实现方式。Split、Concat等常规算子在特定维度配置下偶尔也会报错这种时候可以尝试更新CANN版本。最常见的解决方法是先试opset 11重新导出ONNX因为ATC对opset 11的支持最稳定。如果还不行再考虑升级CANN到新版本新版本通常会补齐一些算子支持。另外force_fp16精度模式有时候会触发算子不支持的报错。可以试试去掉--precision_mode用默认的混合精度模式代价是性能略有下降但兼容性会好很多。6.2 NPU内存不足模型转换和运行时报错运行推理时报错信息里出现out of memory和GPU上的显存不足很像但排查的方向不太一样。首先要看动态batch的分档比如设了dynamic_batch_size为1、2、4、8、16NPU会为所有档位预留内存档位越多、预留越多。如果只在部分档位跑可以把不需要的档位删掉。其次要检查是不是加载了多个模型实例。多个模型同时驻留NPU时内存占用是累加的。如果模型很多但每个模型只在特定时段使用可以在不用的时候释放它model.destroy()最后看输入输出缓冲区是否有内存泄漏。尤其是长时间运行的视频流检测程序如果每帧都申请新的numpy数组而不释放内存会缓慢上涨最终触达上限导致进程被杀。这种问题用npu-smi info查看NPU内存使用率如果持续增长基本可以断定是程序问题。6.3 精度异常检测框偏移或漏检模型在GPU上跑得好好的转成OM之后发现检测框偏了、置信度低、漏检率高这种情况很常见。原因主要是精度模式导致的。force_fp16模式把模型里的权重全部转成FP16精度会有一点损失但一般不会特别严重。如果发现明显异常可以试试去掉--precision_mode让ATC按默认方式处理。对模型做量化校准而不是简单强制FP16。用AMCT工具做PTQ量化能有效缩小精度损失。检查AIPP配置里的归一化参数是否和训练时一致。很多精度问题其实不是量化导致的而是预处理不一致导致的。比如训练时用RGBAIPP里也设了RGB但实际送进来的解码图像是BGR模型就乱了。我遇到过最隐蔽的一次精度问题是AIPP的mean_chn_0/1/2把RGB三个通道当成同一个值去减但训练时使用的是逐通道不同的均值。这种细节不仔细核对训练代码光看模型根本发现不了。6.4 视频流场景掉帧与CPU资源瓶颈视频流部署还有一个常见的坑NPU没跑满但系统卡得不行掉帧严重。这时候瓶颈往往在CPU的视频解码和图像缩放上。Atlas 300V本身带有硬件解码能力通过DVPP模块可以接管视频解码和图像缩放CPU只需要做轻量级的逻辑控制。我建议在处理视频流时优先使用DVPP而不是用OpenCV的VideoCapture做软解码。代码层面的优化手段包括使用多线程把视频解码、预处理、NPU推理、后处理做成流水线避免阻塞。给解码线程设置独立队列队列满时丢帧而不是阻塞。控制输入图像的分辨率如果业务不需要检测小目标把输入从1080P降到720P预处理压力会小很多。7. 性能优化与长期稳定运行建议7.1 多进程并发推理的几个设计要点把多个视频流分配给多个进程这套架构我用了很久稳定性不错。关键设计有这么几个每个进程绑定一个模型实例不要多个进程共享同一个模型实例省心且不会互相干扰。进程间通信使用共享内存或消息队列传递的是图像路径或编码后的数据而不是原始大图像。CPU核数要能匹配进程数。假如有8路视频流、启动8个推理进程每个进程还需要解码线程8核机器会非常紧张。建议至少16核起步。给每个进程配置独立的日志输出定位问题时方便很多。否则多个进程日志混到一起排查问题要花半天时间。7.2 模型量化与精度校准的实用经验如果想进一步提升吞吐可以尝试量化。昇腾的量化工具是AMCT它支持对ONNX模型做离线量化生成INT8模型再通过ATC转成OM。量化的收益很直接INT8推理速度比FP16快不少而且内存占用更低。但精度损失需要校准来弥补。校准的过程是准备一批有代表性的图片喂给量化工具让工具统计每层激活值的分布从而确定合适的量化参数。校准集的质量直接决定量化精度。我用过几种校准集效果最好的是一组和线上业务分布一致的图片包含各种光线、角度、目标数量。如果校准集太单一量化后的模型在复杂场景下漏检率会明显上升。另外量化后一定要在完整的测试集上评估而不是只看几个样本。我见过量化后mAP从0.7掉到0.5的例子原因就是校准集和测试集分布差异太大。7.3 长时间运行的内存监控与看护策略生产环境最怕的不是推理慢而是跑着跑着进程没了。Atlas的NPU内存、CPU内存、显存使用率都要纳入监控。我一般会在部署脚本里加一个守护逻辑定期检查进程存活状态如果进程退出自动拉起来如果NPU使用率异常记录日志并重启对应进程。npu-smi info可以作为监控数据源它的输出格式比较稳定写个脚本解析就行。还有一个容易忽略的点模型文件被反复加载和卸载会积累碎片内存长期运行可能出现NPU内存碎片化。遇到这个问题最好定期重启推理进程或者错峰加载模型、避免频繁创建销毁模型实例。8. 从一次实际项目复盘看整体落地效果8.1 多路视频流检测的真实数据我曾经在一个园区安防项目里部署了1张Atlas 300V跑了8路1080P视频流模型是YOLOv5s输入640x640AIPP开启预处理动态batch设成1和4两档。实际运行两周的结果是8路视频流全部保持实时端到端检测延迟平均在50毫秒左右NPU推理延迟平均在15到20毫秒之间CPU占用率控制在60%以下NPU显存占用大约6GB到8GB之间。如果只跑4路视频流NPU推理延迟能进一步降到10毫秒以内。这个性能对大多数安防检测、工业质检场景都够用了。如果模型换成YOLOv5m单卡跑8路就会吃力一点建议降到4到6路更保险。8.2 项目中遇到的三个典型问题和解决过程第一次调试时ATC转YOLOv5m一直报Resize算子不支持把opset从13降到11后问题消失。这说明ONNX导出时选对opset版本有多重要。第二次是量化后模型漏检率偏高检查发现校准图像全是白天的图像晚上光线不足时检测效果很差。后来校准集里加入夜间数据漏检率恢复正常。第三次是运行一周后NPU内存持续增长排查发现是Python代码里每帧调用np.array(...)创建数组没有显式释放循环引用导致垃圾回收不及时。改成及时删除不再使用的大数组对象内存曲线恢复平稳。这类问题在文档里很难找到标准答案基本靠经验积累。如果你也在做类似部署遇到诡异问题不妨先怀疑版本匹配和内存管理这两块占了Atlas踩坑的大头。8.3 后续扩展方向Atlas 300V用来跑YOLO只是起点同一套部署流程完全可以迁移到其他检测模型、关键点模型或者分割模型上。如果后续业务量上涨多张Atlas 300V插在同一台服务器里通过负载均衡把不同视频流分发到不同卡上吞吐量可以线性扩展。我个人在实际操作中的体会是Atlas这套工具链虽然在生态成熟度上比不过GPU但只要愿意花时间把模型转换和部署流程理清它完全能扛起生产环境的推理任务尤其是在功耗、成本和边缘机房部署这些讲究务实指标的场景里性价比非常突出。最后再分享一个小技巧拿到一块Atlas 300V之后别急着跑大模型。先跑通一个最小的YOLOv5s端到端流程从导出ONNX到ATC转换再到Python推理出结果把这套流程里的每个环节都验证一遍后面再换模型、加路数、做优化都会顺很多。
