拿到一块华为Atlas 300V之后我问了自己一个问题这东西到底是不是一张运算加速卡老实说刚拆包装那会儿我盯着散热片上印的“300V 24G”这几个字心里是有点含糊的。直到把它插进服务器、点亮系统、跑通第一个YOLOv5推理任务才算真正摸清了它的脾气。这篇文章我就从一个实际部署过、踩过坑的人的角度把这卡是什么、能不能当运算加速卡用、以及怎么把YOLO模型在Atlas 300V上跑起来这件事从头到尾捋一遍。如果你正准备在昇腾平台上落地目标检测推理或者手头正好有一块Atlas 300V在吃灰又或者单纯想搞清楚Atlas和YOLO部署之间到底隔了几道坎这篇东西应该能省你不少时间。1. Atlas 300V 24G到底是什么定位的卡先说结论Atlas 300V 24G确实是运算加速卡但它的“运算”严格来说是偏向推理的运算不是拿来炼大模型的那种训练卡。1.1 从产品定位看这张卡的本质华为的Atlas系列产品线拉得很长从板卡到服务器再到整机柜都有。300V这张卡从命名上就能看出点门道——“300”属于300系列推理卡“V”指的是它的形态和供电设计“24G”自然就是24GB显存。在华为官方的产品体系里Atlas 300V被归类为AI推理加速卡主要面向数据中心侧的推理场景比如视频分析、OCR、目标检测这类业务。它和训练卡最大的区别在于训练卡要求的是大算力、高带宽、能长时间跑反向传播而推理卡更看重吞吐量、时延、能效比和单位成本。Atlas 300V搭载了昇腾310P系列芯片内置AI Core支持FP16、INT8等低精度推理整卡功耗官方标称大概在72W左右这和动辄几百瓦的GPU训练卡比起来能效优势非常明显。你可能要问了既然它叫“AI加速卡”那和GPU有什么区别这里有个关键点Atlas 300V不是通用计算卡。GPU你拿去做3D渲染、跑CUDA程序、做科学计算都行而Atlas 300V的生态围绕的是AI推理这一个垂直场景。它的计算单元、内存带宽、指令集都是为了神经网络的前向推理设计的。你拿它跑C普通程序会不知所措但让它跑卷积神经网络它能把算力发挥得比同价位GPU更彻底。1.2 规格参数里的隐含信息我不爱念官网页面上那种干巴巴的参数表但有几个关键参数值得掰开揉碎讲因为它们直接决定了你部署YOLO的上限板载内存24GB这个容量看起来和RTX 3090的24GB一样但本质上完全不是一回事。Atlas的24GB是专为AI推理设计的HBM或LPDDR类大内存带宽很高能让模型权重和中间特征图在片上流转时少去“等数据”的尴尬。昇腾310P芯片架构代号是达芬奇Da Vinci核心计算单元叫AI Core每个AI Core有Cube单元负责矩阵运算和Vector单元负责向量运算。YOLO这种卷积激活池化上采样的组合拳在达芬奇架构下能被打得很顺。支持精度FP16、INT8、INT4这些推理常用精度都支持FP32也能跑但用INT8做量化推理才是发挥这张卡性能的正确姿势。接口形态标准PCIe卡多半是双槽位供电走PCIe金手指再加一个辅助供电口。安装上没什么特殊的和插一张GPU网卡一样简单。所以我给这张卡的定义是它是一张为AI推理而生的专用加速卡24GB显存保证了它能扛住大模型和长视频流而“运算加速”这四个字在推理语境下是名副其实的。2. 为什么“atlas部署yolo”能成为搜索热词你去搜“atlas部署yolo”搜出来的东西一大半是新手指南、社区问答、踩坑记录这说明什么说明这个组合足够常见常见到已经形成了一类专门的话题。2.1 YOLO在昇腾生态里的特殊地位YOLOYou Only Look Once系列目标检测算法几乎是整个计算机视觉领域影响力最大的算法族之一。从YOLOv3到YOLOv5、YOLOv8甚至YOLOv9、YOLO11每一代都在刷新精度和速度的平衡点。它不需要两阶段检测那种复杂的区域提议一次前向就能输出目标框和类别天然适合推理加速硬件。华为昇腾的CANNCompute Architecture for Neural Networks工具链里官方支持的模型列表里YOLO相关模型一直排在很靠前的位置。原因是YOLO的结构相对规整——主干网络以卷积和残差结构为主检测头就是几个卷积层中间穿插上采样和拼接操作。这种结构在达芬奇架构里基本不会遇到“算子不支持”这种破事转换起来非常顺滑。这一点很重要我在后面实操部分会具体讲。2.2 用户真正关心的是什么搜索“atlas部署yolo”的人大概率不是想听厂商宣传片里的那套他们真正想知道的是手里的Atlas卡到底能不能跑YOLO帧率有多少模型文件用什么格式PyTorch的.pt文件能直接用吗部署环境怎么搭驱动、固件、CANN这几层到底什么关系报错一堆什么“aclError”“E32669”到底怎么排查这些问题我在部署过程中几乎全遇到过。所以这篇文章我不打算写成一份官方文档翻译而是按实际操作的流程来讲尽量把每个环节的设计意图和踩坑点都摊开。2.3 场景驱动的部署需求现在Atlas部署YOLO最常见的落地场景我总结了一下大致有这几类智慧园区/安防视频流实时分析人、车、物检测通常要求7×24小时稳定运行多路视频并行推理。工业质检在产线上检测产品外观缺陷对单张图片的推理时延要求极高通常需要在几十毫秒内出结果。边缘计算盒子基于Atlas的整机产品如Atlas 500系列在边缘节点跑YOLO需要小而美、低功耗。算法验证与二次开发研究人员或学生买了单卡跑通YOLO后在这个基础上迁移自己的私有检测模型。这些场景对部署方案的要求侧重点不同但基础链路是相同的准备环境→获得模型→转换模型→执行推理。接下来我就按这条链路往下走。3. Atlas 300V上部署YOLO的完整实操这一段是全文的重头戏。我会按照我实际操作的顺序一步步拆解在Atlas 300V 24G上把YOLOv5跑起来的完整流程。硬件环境就是一台普通的x86服务器插着一张Atlas 300V操作系统是Ubuntu 20.04。3.1 环境准备驱动、固件、CANN三件套很多第一次接触昇腾的人会被这一堆名词搞懵昇腾驱动NVIDIA Driver的类比、固件Firmware用于管理NPU硬件状态、CANN类似CUDA的工具链。这三者的关系我习惯这么类比驱动是让操作系统认识这张卡固件是卡自己的底层管理系统CANN是上层AI计算运行时。三者版本必须配套版本对不上后面全是雷。第一步是安装驱动和固件。到昇腾社区官网的软件下载中心选择Atlas 300V对应的软件包下载“Ascend HDK”Hardware Development Kit里面包含了驱动和固件。安装命令建议用root执行# 查看当前系统架构都是x86_64 uname -m # 安装驱动这是标准流程注意参数表示不安装源码包但保留编译目录 ./Ascend-hdk-*.run --install --quiet # 安装固件 ./Ascend-hdk-*-firmware.run --install --quiet安装完成后用npu-smi检查一下卡是否被识别。npu-smi就是昇腾版的nvidia-sminpu-smi info如果能看到类似下面这样的输出说明驱动固件没问题---------------------------------------------------------------------------- | npu-smi 24.0.rc1 Version: 24.0.rc1 | -------------------------------------------------------------------------- | NPU Name | Health | Power | HBM Memory | | 0 300V | OK | 30W | 23.5 / 24 GB | --------------------------------------------------------------------------接下来装CANN Toolkit。这个包比较大几个GB包含了OPP算子包、ATC模型转换工具、运行框架适配层等。装CANN之前系统需要满足一些前置依赖例如Python 3.7至3.10以及一些基础apt包。直接安装主包即可# 以root安装CANN Toolkit ./Ascend-cann-toolkit_版本_linux-x86_64.run --install --quiet # 安装完后CANN默认装在 /usr/local/Ascend 下面需要source环境变量 source /usr/local/Ascend/ascend-toolkit/set_env.sh这个步骤没有太深的技术含量但是有一个细节值得说环境变量的setting。如果你用root用户可能需要手动把set_env.sh写进~/.bashrc不然每次新开会话都要重新source。而CANN版本和驱动版本的配套关系官方有个支持矩阵务必一一对照版本不一致时npu-smi能看到卡但跑推理程序时会报各种“runtime error”。3.2 获取和准备YOLO模型从PyTorch到ONNX再到OM拿到YOLO模型的方式有很多你可能是从Ultralytics/YOLOv5官方仓库下载的预训练权重或者你自己训练好的自定义权重。不管怎样Atlas不能直接读PyTorch的.pt文件也不能直接读ONNX文件——它需要的是CANN的离线模型格式OMOffline Model。可能有人会问为什么非要用OM因为OM是在离线阶段就把算子的调度、内存分配、图优化全部做完了推理阶段只需要在NPU上按图执行不需要在运行时有任何一个“解释器”去临时分析模型结构。这一点对推理卡的性能来说至关重要。你可以把OM类比成编译后的二进制可执行文件而ONNX、PyTorch模型则是源码。虽然每次修改权重都要重新“编译”但运行时开销极小。模型转换的黄金路径是PyTorch → ONNX → OM。第一步PyTorch模型导出为ONNX在Ultralytics YOLOv5目录下官方给了导出脚本。以YOLOv5s为例python export.py --weights yolov5s.pt --include onnx --opset 11这一步会生成yolov5s.onnx。这里有个重点导出时一定要设置好opset版本。我推荐opset11因为这个版本在CANN的算子支持范围里很成熟。opset太高可能引入太新的算子导致后续ATC转换报“Unsupported op”而opset太低部分YOLO结构里的算子比如SiLU激活在ONNX里会被拆成多个基础算子组合会变得很啰嗦影响转换效率。另外一个容易踩的坑是动态维度问题。YOLOv5默认导出的是静态shape输入固定为(1, 3, 640, 640)。如果你的业务场景需要不同分辨率输入比如视频流分辨率不固定需要在导出时把动态轴打开python export.py --weights yolov5s.pt --include onnx --opset 11 --dynamic动态shape在OM转换时也能设置动态维度的范围但会让推理性能打折扣因为NPU里的内存规划和算子融合都要按最大shape预留空间。我的经验是能固定分辨率就固定不要图省事开动态除非业务真的需要。第二步ATC工具将ONNX转换为OMATCAscend Tensor Compiler是CANN自带的模型转换工具。它会把ONNX的计算图逐层分析匹配到昇腾算子库完成算子融合、内存复用、调度优化最后生成.om文件。ATC的命令行参数不算复杂但有几个关键参数必须搞清楚atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg参数逐一解释--model输入ONNX文件路径。--framework55表示ONNX1是MindSpore2是TensorFlow3是Caffe。这个别搞错。--output输出OM文件前缀。--input_shape静态输入shape。格式是“输入名:维度”默认输入名是images这个要跟ONNX导出时的输入名对应。--soc_version芯片型号。Atlas 300V对应的SoC版本是Ascend310P3。查询方法是用npu-smi info看芯片型号或者用CANN自带的ascend_install.info查看。版本写错了转换能跑但下不到卡上。--insert_op_conf图像预处理配置。YOLO模型一般需要输入归一化而AIPPAI Preprocessing可以把归一化/RGB转换这些操作融合进模型输入侧在NPU上完成省掉CPU的预处理开销。说到AIPP很多新手容易忽略它。如果你的YOLO推理管线里有“读图→缩放→减去均值→除以标准差→归一化→转为RGB”这一段代码逻辑那么这部分完全可以用AIPP配置替代。我在aipp.cfg里长这样aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 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 }这一段的意思是输入数据是8bit三通道RGB宽高640把每个像素值乘以var_reci即缩小到0~1范围再送入网络。这样我CPU端只需要做一次最基本的JPG解码和resize剩下的归一化交给NPU。别小看这个把容器在线视频流场景里一张图省下几毫秒CPU时间累积起来就是吞吐量的大幅提升。转换成功后会看到类似“ATC run success”的输出同时会生成一个yolov5s_bs1.om文件。3.3 写推理代码ACL接口与Python绑定模型转换完成后就可以写推理代码了。官方推荐的开发方式有两种一是用Python调用ACLAscend Computing Language接口二是直接基于MindSpore或者PyTorch框架的昇腾适配版。我自己的习惯是直接用PythonACL因为这种方式的依赖最少逻辑最直观方便后续封装服务。ACL的Python接口核心流程就四步初始化→加载模型→准备数据→执行推理。下面给一个最小可运行的示例为了节省篇幅我只保留核心逻辑import acl import numpy as np # 1. 初始化 acl.init() ret acl.rt.set_device(0) # 使用第0张NPU # 2. 加载模型 model_path b./yolov5s_bs1.om model_id acl.mdl.load_from_file(model_path) _, _, _, _, mem_size, weight_size acl.mdl.query_size(model_id) input_data, output_data acl.util.np_to_ptr(np.zeros((1, 3, 640, 640), dtypenp.uint8)), None # 3. 准备输入输出内存这里简化了内存申请实际要用acl.rt.malloc input_dataset acl.mdl.create_dataset() output_dataset acl.mdl.create_dataset() # ... 把数据指针绑定到dataset # 4. 执行推理 ret acl.mdl.execute(model_id, input_dataset, output_dataset) # 5. 取输出做后处理NMS等 # ...这段代码虽然简单但暴露了ACL编程的几个特点所有数据指针都要预先分配内存不能像Python里那样随手new一个list模型加载后要自己管理内存释放输出需要自己根据模型输出shape来解析。对于不熟悉C/C思维的人来说第一次写ACL Python代码会觉得有点别扭但习惯后就好了。如果不想从零造轮子建议直接看官方提供的YOLO样例代码。CANN安装包默认带一些sample路径一般在/usr/local/Ascend/ascend-toolkit/latest/sample里面有个object_detection样例就是基于ACL的YOLO端到端推理实现包含图片预处理、推理、NMS后处理全套逻辑。拿过来改改路径和参数就能跑通。3.4 后处理从模型输出到目标框YOLOv5的ONNX输出一般是一个(1, 25200, 85)的张量——25200代表640×640输入下所有anchor的组合数量85是4个框坐标1个confidence80个类别概率。在Atlas上推理完拿到这个张量后还得自己写NMS非极大值抑制把重复的框滤掉。这一步是在CPU上跑的不算NPU计算。NMS的细节我就不展开了只提一个性能优化技巧用向量化操作替代for循环。比如先把confidence低于阈值的框全部过滤掉再从高到低排序做NMS最后只decode坐标。numpy写好了25200个框的处理时间也能压到几毫秒以内。另外有些新版本的YOLO比如v8、v11输出格式已经发生了变化可能是解耦头多输出几个张量或者直接用DFLDistribution Focal Loss回归框坐标。这些模型在after-treatment上的代码会复杂一些但转换到OM的原理和v5完全一致。4. 性能调优与部署形态选择模型能跑起来只是第一步真正要上线还得看能不能扛住业务压力。4.1 几个影响帧率的隐藏因素我在调优过程中发现同样的OM模型有的人跑出20 FPS有的人能跑到60 FPS差距就藏在这几个地方batch size在Atlas 300V上单batch推理时延低但吞吐不高调高batch size到4或8NPU的AI Core利用率明显提升总体吞吐能翻倍。代价是单帧时延略微增加。如果业务是异步批处理型比如批量图片审计无脑上batch。多路并发Atlas 300V支持多路视频流并发。这里的关键是不要让每路单独申请一份模型内存——模型内存只加载一份多路流共享模型权重每路分配独立的输入输出内存再用线程池调度推理。这样24GB显存能被压榨得很充分。AIPP和图像缩放如果预处理放在CPUCPU可能成为瓶颈。AIPP能缓解一部分但图像缩放Resize不是AIPP的强项最好在解码阶段就缩放到目标尺寸或者用GPU/CPU混合方案。动态shape vs 静态shape上面提到过静态shape性能最好。如果你有多分辨率需求尽量把输入分辨率归一化到固定的几个离散档位而不是完全动态。4.2 在线服务封装从裸推理到可用的推理服务实际业务中很少有人直接拿Python脚本当服务。通用的做法是在ACL外面套一层服务框架。我个人用过两种方案方案一是用Flask/FastAPI封装HTTP接口适合需求简单、调用方很少的情况。处理方法把ACL推理代码放进一个类类初始化时加载模型请求进来时调用类方法执行推理返回JSON结果。需要注意要加一个全局锁因为同一个模型可以并发执行但多个线程同时向同一个NPU提交任务时ACL内部虽然安全但对模型的输入输出内存是有冲突风险的。稳妥做法是给每个线程独立分配输入输出内存或者用ACL自带的队列机制串行化提交。方案二是用gRPC适合大规模并发场景。gRPC的流式传输对视频流很友好而且底层是HTTP/2比JSON的序列化开销小一个数量级。把YOLO推理封装成gRPC服务客户端不断向服务端推到帧图服务端回传检测结果这是目前工业界用得最多的架构。4.3 Atlas 300V和GPU推理卡的选型思路文章开头有人说“Atlas 300V 24G是运算加速卡吗”其实这个问题背后还藏着一层这卡和GPU比怎么样我按实际测试体会说一下单卡性能在YOLOv5s INT8量化、batch1的过程中Atlas 300V的时延大约在5-10ms性能接近入门级GPU但功耗只有一半不到。能耗比Atlas 300V 24G的功耗72W左右同级别的GPU怎么也得180W往上。对机房的功耗预算约束比较严的场景比如边缘机柜、山上站房Atlas优势明显。生态成熟度PyTorch的GPU生态还是无人能敌很多新出的算法都是直接适配CUDA。Atlas的生态虽然有CANN和MindSpore撑着但任何新模型要上Atlas几乎都得走一遍ONNX转换加算子适配的路子这个门槛比GPU高一点。性价比如果你只是偶尔跑个检测模型GPU更灵活如果是有明确且稳定的推理负载比如24小时视频分析Atlas在长期运营成本上更有优势。给一个不太严谨但很实用的总结搞科研选GPU搞产品化交付、强调功耗和单位成本的时候Atlas 300V值得认真考虑。5. 常见问题与排查技巧实录这部分是全文最“值钱”的地方。我把这半年在Atlas 300V上部署YOLO遇到过的典型问题以及对应的排查思路都整理出来。5.1 驱动、固件、CANN版本不匹配问题现象npu-smi info能看到卡但一执行ATC转换或ACL推理就报错常见的有“E32669 error”“set device failed”“runtime error”等。排查思路先查版本匹配关系。在昇腾社区下载中心有“版本配套表”里面列出驱动、固件、CANN、MindSpore的对应版本。我发现不少人装完CANN后忘记装固件或者装了老固件配了新驱动这些都是雷。我给的排查顺序是# 查看驱动版本 npu-smi info # 查看CANN版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg # 对比官方配套表如果版本没问题再用ascend-dmi -i -t做一次硬件自检能过滤掉硬件层面的故障。5.2 模型转换时报Unsupported Op问题现象ATC转换时报“Unsupported op: XXX”。这是所有昇腾新手最怕的报错。其实处理思路很成熟第一步确认ONNX里是什么算子不支持。一般的做法是用onnx库把图打出来定位到红猩猩算子的前后文。第二步去昇腾社区查算子支持列表看看这个算子是否对应昇腾算子库里的某个实现。CANN的可支持范围在持续扩大很多老版本不支持的算子新版本已经覆盖了。第三步如果还不支持策略是“绕”。方法一改ONNX的opset版本重导一次方法二手工把那个op替换成几个基础算子比如某些LayerNorm可以等价拆成mean、sub、pow、mul的组合方法三换模型导出方式例如用MindSpore导出或者用TensorFlow的Pb格式再转。YOLOv5的SiLU激活在旧版本CANN里是个常见的不支持的算子解决方案有两种一种是换到opset13后的ONNX让其自动展开为sigmoidmultiply另一种是用CANN自带的融合规则在新版本中已经自动处理了SiLU。所以如果你用的是新CANN这个坑基本不存在了。注意处理算子问题时善用可视化工具。Netron网页端就能打开ONNX是排查这类问题的最佳搭档把不支持算子的输入输出连到哪、数据维度多少一眼就清楚。5.3 推理结果全为零或框的位置完全不对问题现象模型转换没问题推理也能跑但输出结果全是背景一个目标都检不出来或者检出来的框和图片位置对不上。这类问题九成出在图像预处理和AIPP配置上。YOLO系列的基本约定是输入为RGB顺序像素值归一化到0~1。如果你在CPU端读图用的是BGR又设置AIPP为RGB888_U8那么通道顺序就反了模型自然识别不出来。还有一个常见错误是坐标映射。YOLO输出的坐标是针对模型输入分辨率比如640×640的但如果原图画幅是1920×1080你在preprocessing时用了letterbox缩放那么输出框坐标必须先等比缩放回去再叠加letterbox的偏移量。很多人忘了这一步导致框画错位。排查方法很笨但有效拿一张网上随便下的示例图先用PyTorch原版模型跑一遍拿到理想结果再用OM模型跑同一张图对比中间特征张量或对比最终框。输入预处理如果一致结果一致性应该在99%以上。如果对不上就逐一排查AIPP的均值方差、通道顺序、缩放方式。5.4 NPU内存不足与多路并发崩溃问题现象单独跑一路视频流没问题但起多路并发时跑到第5路或第8路就报“aclrtMalloc failed”“mem pool full”。Analyze这个问题的核心是24GB显存是一张卡的总显存但分配给每个推理任务的输入输出内存是你自己申请的。多路并发时如果每路都申请独立的输入输出内存那内存消耗是线性增长的。我的处理经验用npu-smi info监控HBM内存占用看看24GB到底被什么东西吃掉了。检查model占用用acl.mdl.query_size查询模型权重和中间缓存占了多少MB。YOLOv5s的OM模型本身很小就几十MB。调小每路的申请内存对于YOLOv5s静态shape1,3,640,640输入只要1.2MB输出只有25200×85×4字节约8.5MB加上中间buffer每路单独申请总共也就几十MB。所以内存不足往往不是显存问题而是memory pool碎片化。更稳妥的做法是多路共享模型权重内存输入输出用队列复用创建固定大小的内存池推理完成后立即归还而不是每次请求都malloc和free。5.5 视频流推理中的掉帧与线程安全问题现象使用OpenCV读取摄像头或RTSP视频流送到ACL推理时总隔几秒卡一下甚至掉帧多线程调用同一个model时有随机崩溃。视频流推理的稳定性问题有三板斧可以缓解解码和推理分离视频解码是CPU密集操作推理是NPU密集操作两个放一条流水线里会互相阻塞。正确做法是解码线程持续把帧放进队列推理线程从队列取帧跑ACL后端再跟上NMS和推送。队列大小控制在一定水位积压太多就丢掉旧帧只保留最新帧。ACL线程安全同一个model可以被多线程并发调用前提是每个线程的输入输出内存是独立的。你想省内存复用同一块输入输出内存就必须加锁串行化否则随机崩溃真的一点都不奇怪。用Stream机制ACL本身的rt.stream可以让同一个channel上的任务按顺序执行避免线程互相等待。多路视频分别绑定不同stream调度器由ACL统一管理比多个线程各自提交要优雅得多。6. 经验沉淀与可复制的方法论跑通Atlas 300V上的YOLO部署之后我复盘了整个流程发现有一个核心的心智模型值得记下来。昇腾平台部署AI模型本质上就是一个“翻译加编译”的过程。你手里的PyTorch模型是描述一个数学函数的“高级语言”ONNX是中间表示OM是编译后的机器码。而CANN这个工具链就是整个编译器的其余部分——词法分析算子解析、语法分析图优化、代码生成算子调度、优化器内存复用和融合。理解了这一层你就知道遇到任何“新模型怎么上昇腾”的问题思路都应该是固定的先确认有没有现成的OM没有就导出ONNX然后处理不支持算子最后验证精度。这套方法论可以套用到YOLOv8、此时更先进的目标检测模型甚至分割模型、关键点模型上。而Atlas 300V 24G这张卡的价值我实际用了这么久的体会是它把“单位功耗的推理算力”做到了一个在当时很有竞争力的水平并且24GB大内存让它的适用面比想象中宽。它不是通用GPU没法陪你炼丹跑大模型训练但当你需要一台24小时不间断跑目标检测的机器时它的价值才会真正显现出来。最后再分享一个小技巧在Atlas 300V上部署YOLO不要追求在PyTorch里把模型精度提到多高而是要尽早把INT8量化提上日程。YOLO系列的INT8量化在昇腾工具链的自动化校准下精度损失通常控制在1个mAP以内而性能却能提升2到3倍。这也是同类推理卡最正确的使用姿势。