最近后台收到好几条关于“Atlas部署YOLO”的提问还有人直接问“Atlas 300V 24G是运算加速卡吗”。恰好上一周我完整做完了一个基于Atlas 300V系列推理卡的YOLOv5目标检测部署项目从硬件选型、环境搭建到模型转换、推理调优全流程走了一遍。这篇文章就把整个实践过程整理出来包括我自己踩过的坑和最终沉淀下来的部署模板给正准备上手的朋友一份可以直接参考的路线图。1. 初识Atlas 300V 24G它到底是不是一张“运算加速卡”1.1 先从产品定位聊起很多人第一次接触Atlas这个名词第一反应是“这是不是类似NVIDIA T4 / A10那种GPU”。这个理解方向对一半。Atlas 300V 24G本质上是昇腾生态面向AI推理场景推出的一张PCIe加速卡它的核心任务是给深度学习模型提供高性能、低功耗的推理计算能力。跟通用GPU不一样它不强调图形渲染而是专攻矩阵运算、卷积、池化这类神经网络里最常见的计算模式。用大白话说这就是为“跑模型”而生的一张卡不是用来打游戏或者做3D渲染的。这张卡显存24GB面向视频分析、目标检测、OCR、图像分类等典型的边缘侧和数据中心侧推理业务。拿它来部署YOLO属于非常典型的应用方式。很多人第一次拿到卡会习惯性地去查“它能不能像CUDA一样直接跑PyTorch”这里要提醒一句昇腾的软件栈是独立的思路不等于CUDA生态那套但整体逻辑是相通的掌握了模型转换和推理接口上手速度会很快。1.2 Atlas 300V 24G的关键硬件特征从我实际使用的体验来看这张卡最值得关注的点是24GB显存。目标检测模型的输入分辨率往往会推到1280x1280甚至更高显存不够是很多推理卡在真实场景里的硬伤。24GB意味着你可以单卡加载更大batch的模型输入提升吞吐同时跑多路视频流的检测任务使用更高精度的FP16/INT8模型而不用担心显存溢出关注点说明对YOLO部署的意义显存容量24GB可以支撑高分辨率输入、大批次推理硬件解码能力支持视频/图片硬件解码加速视频流检测时有效减轻CPU负担推理计算单元专为神经网络算子设计卷积、反卷积、池化等算子执行效率高对外接口标准PCIe接口普通服务器即可接入不需要专用整机软件生态昇腾CANN工具链提供模型转换与推理API衔接PyTorch/ONNX等模型从我项目里记录的实测数据来看在1280分辨率、原始FP16精度条件下单张Atlas 300V 24G处理YOLOv5s的吞吐表现很稳定而且功耗比同级别的通用GPU要低。对于长时间跑7x24小时推理业务的环境来说功耗和发热控制是实打实的成本优势。1.3 定位上的误区纠正“运算加速卡”这个说法其实不算错但不够精确。我在不少交流群里看到有人把这卡当成“训练卡”来用试图在上面训练YOLO模型这是一个容易踩的坑。Atlas 300V 24G的设计重心是推理加速虽然理论上一些小的训练任务也能跑但它的驱动和工具链针对推理场景做了深度优化。建议把训练和推理分工训练继续用GPU集群或云上资源训练完导出ONNX模型再用Atlas 300V 24G做部署推理。这个分工方式是当前昇腾推理卡最主流的用法也是性能释放最彻底的方式。2. 为什么拿它跑YOLO业务场景与方案选型2.1 这类组合最适合什么场景YOLO是目标检测任务里被用得最多的模型之一部署需求遍布安防、工业质检、智慧交通、明厨亮灶等领域。Atlas 300V 24G和YOLO的组合适合以下情况视频流检测多路RTSP流接入实时框出目标物比如工厂安全帽检测、周界入侵检测图像批处理每天几百万张图片的离线审核、归档筛查要求处理速度快、单卡吞吐高边缘一体机把卡集成进自研AI盒子配合多路摄像头做现场实时分析国产化项目对硬件平台有自主可控要求的项目昇腾系列是比较常见的选择我当时接到的项目是做厂区视频安防要求对16路高清摄像头做实时安全帽检测同时保留对历史视频的抽帧分析能力。评估过几套方案之后最终选了Atlas 300V 24G核心原因就两条一是显存够大单卡能撑起多路视频流的并发推理二是硬件解码能力好16路视频不需要额外的解码卡CPU占用也压得住。2.2 模型选型和部署方式的权衡部署YOLO首先要想清楚一个问题你要部署的是哪个版本的YOLO。目前我在实际项目里接触到的YOLOv5和YOLOv8占据大头YOLOX在一些特定项目里也会遇到。不同模型结构的算子集合有差别转换成昇腾OM模型时的兼容程度也不同。模型特点Atlas 300V 24G适配情况YOLOv5生态成熟ONNX导出链路顺畅算子兼容性好转换方便YOLOv7精度上限高结构相对复杂需要留意部分算子的转换配置YOLOv8结构简洁训练部署一体转换顺畅适合新项目启用YOLOX解耦头设计部署稍复杂需要调整输出层处理逻辑这里还涉及一个部署路径的选择。昇腾推理的常用路径是“训练框架导出ONNX - ATC工具转成OM模型 - 调用ACLAscend Computing Language接口做推理”。也有直接用MindSpore训练并导出的方式但我个人更推荐ONNX作为中间格式因为PyTorch模型转ONNX的链路成熟调试手段也多遇到算子报错时容易定位问题。后面所有实操步骤我都会按照ONNX中转这条路线来讲。2.3 一张卡能带多少路视频流这个问题几乎每个做视频检测的朋友都会问。实际结论是不拆开算都是耍流氓。视频流路数取决于分辨率、码率、抽帧策略、模型大小、推理精度设置等多重因素。我在项目中采用的做法是16路1080p视频流每路5秒抽1帧送入YOLOv5s模型做检测硬件解码和解码后的缩放交给DVPP数字视觉预处理模块模型推理使用FP16精度单张Atlas 300V 24G整体处理得很轻松。如果要做每路全帧率检测那就要压缩模型输入尺寸或者改用更轻量的模型结构也可以用深度学习模型在Atlas上做batch合并推理。提前说这些是想让大家对“Atlas 300V 24G YOLO”这套组合的能力边界有个整体概念心里有杆秤后面实操的时候才知道怎么调整配置。3. 部署前准备驱动、固件与CANN工具链3.1 环境总览服务器与操作系统要求Atlas 300V 24G是标准PCIe接口卡普通x86服务器或者Arm服务器都能用。我的实践环境是x86服务器Ubuntu 20.04系统内核版本根据昇腾官方兼容性列表做了核对这一点尤其重要内核不匹配会导致驱动编译失败。开始之前先确认几个硬性指标服务器有空余的PCIe x16插槽且供电满足要求操作系统是昇腾官方兼容列表里的版本我用的是Ubuntu 20.04.6 LTS已安装gcc、g、make等编译工具驱动安装时需要编译内核模块BIOS中确认Above 4G Decoding和Resizable BAR功能已开启否则可能识别不到全部显存提示拿到设备后不要急着装驱动先到昇腾社区官网查询当前卡型号对应的驱动、固件和CANN版本号然后记录下三个版本组件的兼容矩阵。版本不配套是很多“识别不到设备”问题的根源。3.2 驱动与固件安装的完整流程整机安装驱动固件的顺序有讲究先装驱动再装固件最后装CANN工具包。顺序反了或者跳步容易出现模块加载异常。第一步安装驱动。昇腾的驱动安装包一般是.run文件安装命令如下# 查看系统内核版本确认与驱动包兼容 uname -a # 给驱动包添加执行权限 chmod x Ascend-hdk-*.run # 执行安装推荐以root用户操作 ./Ascend-hdk-*.run --full --install-for-all安装完成后用npu-smi info命令查看设备信息。如果能看到卡的温度、电源、显存和芯片信息说明驱动部分正常。这里新手容易遇到的问题一片空白或者提示“No device found”。我的排查经验是先去查dmesg | grep -i npu看内核有没有加载昇腾模块的报错重点关注PCIe枚举是否成功。很多时候插槽接触不良就会导致这种问题。第二步安装固件。固件包同样是.run文件安装命令和驱动类似./Ascend-hdk-*.run --full固件安装完成一般会提示重启服务器。这个步骤不要偷懒我遇到过不重启直接装CANN后面推理初始化一直报错的情况重启一次能省很多排查时间。第三步安装CANN工具包。CANN是昇腾的计算架构相当于“驱动之上的运行时和算子库”。我使用的版本是CANN 8.0.RC1。安装后需要手动配置环境变量# 在 /etc/profile 或 ~/.bashrc 中追加 source /usr/local/Ascend/ascend-toolkit/set_env.sh环境变量配置完成后验证CANN是否正常# 查看版本信息 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg # 用随包自带的样例验证环境 cd /usr/local/Ascend/ascend-toolkit/latest/tools/ python3 -c import torch; import torch_npu3.3 安装过程中最容易被忽略的检查点很多部署项目在这个阶段就卡了一两天我把高频问题集中整理一下。内核版本与驱动不兼容。Ubuntu一般不会主动升级内核但如果有过安全补丁升级建议先核对内核版本。驱动编译失败时日志里会明确给出内核相关报错。电源供电不足。Atlas 300V 24G满载功耗不低PCIe插槽供电不够时卡可以识别但负载上去后会掉卡。确保电源功率余量充足。驱动和固件版本不一致。查询官方文档里驱动和固件的配套关系版本跳跃太大会导致初始化失败。多个昇腾设备混插。如果服务器里同时插了不同型号的卡需要仔细对照官方兼容列表。我在多人共享服务器上遇到过新卡与老卡驱动版本冲突的问题最后还是靠升级统一版驱动解决的。安装完成后有一个很好的验证手段跑一遍CANN安装包里自带的样例程序比如/usr/local/Ascend/ascend-toolkit/latest/tools下的示例确认推理接口可以正常调用。这一步跑通了环境这一关就算正式通过。4. 把YOLO模型转换成Atlas能懂的格式4.1 从PyTorch到ONNX导出前的模型固化环境没问题之后最核心的工作就是把PyTorch训练好的YOLO模型搬到Atlas上。这里要做一次格式转换步骤是这样的PyTorch训练得到best.pt权重导出为ONNX格式模型通过ATC工具将ONNX转为OM格式第一步要注意PyTorch模型里不能有动态控制流。训练时的很多逻辑在导出ONNX时会被跟踪或脚本化。推荐做法是先用torch.onnx.export导出再用onnxruntime或者onnxsim做一遍验证和精简。YOLOv5的官方仓库已经提供了导出脚本但实际项目里最好还是自己写一遍导出代码方便控制输入尺寸和输出节点import torch # 加载训练好的模型模型需要处于eval模式 model torch.load(best.pt, map_locationcpu)[model].float() model.eval() # 定义一个临时输入张量建议固定到部署时用的分辨率 dummy_input torch.randn(1, 3, 640, 640) # 导出ONNX torch.onnx.export( model, dummy_input, yolo.onnx, opset_version11, do_constant_foldingTrue, input_names[images], output_names[output], dynamic_axesNone # 如果不需要动态batch就固定shape )导出时建议固定batch为1不要开动态轴。动态shape在AT转换时处理复杂且推理性能会有损失。如果你有多个batch的需要最佳实践是导出多个不同batch的OM模型推理时按实际batch选择加载。关于导出时是否需要合并模型的前处理或后处理我的观点是前处理不要让模型承担后处理也不建议硬塞进模型图里。保持模型图干净后续排查问题会轻松很多。导出ONNX后务必先用onnxruntime跑一遍确认输出结果和PyTorch推理一致。这一步能挡住大量转换阶段的问题。4.2 ATC模型转换核心参数详解ONNX模型准备好之后用ATC工具转换成OM模型。ATC全称Ascend Tensor Compiler是昇腾的离线模型转换工具。下面是转换YOLOv5的典型命令# 设置CANN环境 source /usr/local/Ascend/ascend-toolkit/set_env.sh # ATC转换命令 atc --model./yolo.onnx \ --framework5 \ --output./yolo_bs1 \ --input_formatNCHW \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --output_typeFP16 \ --loginfo逐项解释一下--framework55表示ONNX这个不用记记4是Caffe、5是ONNX就行--input_formatNCHWPyTorch的默认张量格式就是NCHW保持默认即可--input_shape需要跟导出时的输入张量形状完全一致--soc_version根据芯片型号填写我用的是Ascend310P3不同芯片的soc类型不一样可以通过npu-smi info查看芯片型号后去官方映射表里查--output_typeFP16FP16能显著提升推理速度且对精度影响很小前提是你的模型在FP16下验证过数值误差在可接受范围内--loginfo出错时能把细节输出出来排查问题很有用转换成功后会生成一个.om文件。如果卡在算子不支持之类的报错优先考虑升级CANN版本或者换ONNX opset版本重新导出。4.3 开源YOLO模型部署时的“动态尺寸”方案实际项目里输入图片分辨率往往不是固定的。一种办法是resize到固定尺寸简单粗暴但会降低小目标检出率另一种是动态分辨率YOLO对输入尺寸有一定容忍度Atlas推理也可以设置动态shape。从稳定性和推理效率两个角度来说我个人的建议是如果业务场景的输入尺寸比较多样可以采用“尺寸分档”策略把常见尺寸预先转成多个OM模型例如640x640、960x960、1280x1280各转一个推理时按最接近的尺寸选择模型。这种做法比动态shape的坑少得多性能也更有保障。动态shape在ATC转换时能配通但实际运行时的内存分配和算子编译调度会更复杂非必要的场景不推荐。5. 推理代码编写Python侧的完整实现5.1 初始化与资源管理模型转换好之后就到了写推理代码的阶段。昇腾推理的Python接口在CANN工具包里主要模块叫aclruntime或者mindspore我项目里使用的是CANN内置的aclruntime。整体的编程思路是初始化 - 加载模型 - 准备输入输出 - 执行推理 - 解析结果。先看初始化和模型加载import aclruntime import numpy as np from PIL import Image # 初始化ACL0表示当前设备 device_id 0 aclruntime.init(device_id) # 加载OM模型 model_path ./yolo_bs1.om sess aclruntime.InferenceSession(model_path, device_iddevice_id) # 查看输入输出信息 inputs_info sess.get_inputs() outputs_info sess.get_outputs() print(inputs:, inputs_info) print(outputs:, outputs_info)这里有一点要提醒加载模型之前最好确认设备显存占用情况尤其是多人共享的推理服务器。可以用npu-smi info检查当前显存使用情况避免加载模型时因为显存不足而报错。5.2 前处理与推理执行前处理这一块需要跟模型训练时的预处理逻辑保持一致。YOLOv5训练时有一个比较固定的预处理流程resize到640x640、像素值归一化到0-1、按RGB顺序排列、数据格式为NCHW。推理侧也要复刻同样的步骤否则检测精度会明显下降。def preprocess(image_path, input_h640, input_w640): # 读取图片并转为RGB image Image.open(image_path).convert(RGB) # 缩放图片到模型输入尺寸 image image.resize((input_w, input_h), Image.BILINEAR) # 转numpy并归一化注意HWC转CHW img_array np.array(image, dtypenp.float32) / 255.0 img_array np.transpose(img_array, (2, 0, 1)) # HWC - CHW img_array np.expand_dims(img_array, axis0) # 加batch维度 return img_array # 加载预处理后的输入 input_data preprocess(test.jpg) # 以字典形式构造输入注意名字要跟模型输入一致 infer_input {inputs_info[0].name: input_data} # 执行推理 outputs sess.run(None, infer_input) # 输出通常是一个ndarray列表 result outputs[0] print(inference result shape:, result.shape)推理输出的形状通常是[1, 25200, 85]这种形式。以YOLOv5为例25200是不同尺度特征图上的候选框数量总和85 4个坐标 1个目标置信度 80个类别COCO默认。拿到输出之后需要做NMS非极大值抑制过滤重复框然后映射回原图坐标。5.3 后处理从特征图到可视化的检测框后处理是整个推理链路里我花时间最多的地方因为它直接影响“能不能用”。很多人模型转了、推理也执行了但画框画得乱七八糟或者框不全问题基本都出在后处理理解上。我这里把YOLOv5后处理拆解成几步第一步解析输出矩阵。把25200个候选框的行向量拆开前4位是坐标第5位是目标置信度后面是各类别得分。注意YOLOv5输出的坐标是相对于640x640输入尺寸的需要除以640再乘以原图宽高得到原图坐标。第二步阈值过滤。根据目标置信度先过滤掉低分框再取类别得分的最大值作为该框的最终分类得分。这里要注意有些模型输出的是类别得分已经经过了sigmoid有些则没有需要结合训练代码确认。第三步NMS去重。用经典的NMS算法按类别分别抑制重叠框。OpenCV或者NumPy都可以实现我习惯用NumPy写出NMS逻辑这样不依赖额外推理库def nms(boxes, scores, iou_threshold0.45): # 按得分降序排列 indices np.argsort(scores)[::-1] keep [] while indices.size 0: i indices[0] keep.append(i) # 计算其余框与当前框的IoU ious compute_iou(boxes[i], boxes[indices[1:]]) # 保留IoU小于阈值的框 mask ious iou_threshold indices indices[1:][mask] return keep第四步坐标还原。把NMS之后的框乘以缩放比例并加上偏移得到原图的检测结果再用于可视化或输出结构化数据。整个后处理代码写好之后建议先用网上的标准图片做验证确认项目和PyTorch原版推理的结果一致再接到业务代码里。这样后续排查问题会清晰很多。5.4 多线程与多路视频流接入业务需求是16路视频流实时检测单线程逐帧跑肯定不行。我的方案是“生产者-消费者”模型一个采集线程负责拉取RTSP流通过OpenCV的VideoCapture或者昇腾的DVPP硬解码接口读取视频帧多个推理线程组成线程池从队列里取帧做检测结果通过消息队列返回给业务模块做告警或者记录这里需要注意Atlas推理本身的调用是线程安全的但同一个InferenceSession如果被多个线程同时run性能会有损耗。更推荐的做法是创建多个推理会话每个线程独享一个session。显存足够的情况下这种方式并发性能提升明显。我实测在16路1080p视频流、每路抽帧5帧/秒的情况下线程池设置为4个推理线程单卡GPU利用率保持在80%左右CPU占用稳定在40%以内整体效果很理想。如果你要跑全帧率建议用DVPP硬解码配合多batch推理调优空间会更大。6. 性能调优与资源规划从“能跑”到“跑得更省”6.1 数据预处理与推理的流水线优化把图片从网络流变成模型输入中间有一整套链路。如果每一步都用CPU做CPU占用会飙升推理卡的利用率反而上不去。优化的核心思路就是硬件能干的活儿不要用软件干。具体来说Atlas 300V 24G的硬件编解码模块DVPP非常值得利用。它可以把视频解码、图片缩放、格式转换这些操作从CPU搬到专用硬件单元。我前期用OpenCV在CPU上做resize和色彩空间转换16路视频流直接把CPU打到60%以上后来改用DVPP接口后CPU占用直接降到了20%以下。在CANN工具包里DVPP的接口在aclruntime的ImageProcessor模块里。你可以把JPEG解码、缩放、像素格式转换都交给它import aclruntime # 创建图像处理器指定输出尺寸 img_proc aclruntime.ImageProcessor(output_width640, output_height640) # 输入数据为二进制JPEG数据 jpeg_data open(test.jpg, rb).read() # 硬件解码并做缩放 processed img_proc.process(jpeg_data)DVPP做硬解时输出数据的格式通常是YUV420SP而模型输入需要RGB格式转换也需要调整。好在CANN提供了格式转换接口前处理整个链路可以全部交给硬件效率提升非常明显。6.2 多batch推理的显存与延迟权衡BatchSize是推理性能的一个关键参数。BatchSize1时单张图片延迟最低适合低延迟场景BatchSize8或16时吞吐最高适合批处理场景。Atlas 300V 24G的显存足够大跑一个YOLOv5s的batch16模型没有压力。但在视频流检测场景里直接提高batch有一个矛盾不同路视频帧到达时间不确定凑满一个batch会引入等待延迟。我的做法是设一个“最大等待时间”比如5毫秒超时未凑满也直接推理在实时性和吞吐之间取平衡def gather_batch(frame_queue, batch_size, wait_ms5): frames [] deadline time.time() wait_ms / 1000 while len(frames) batch_size: if time.time() deadline: break try: frames.append(frame_queue.get(timeout0.005)) except queue.Empty: continue return frames这种方式在业务请求分布较均匀时能显著提升吞吐峰值时又不会因为等batch而卡顿。6.3 显存监控与多卡扩展最后提一下资源规划和监控。昇腾自带的npu-smi info命令可以查看实时的显存占用、芯片温度和功耗。正式上线前我建议用这个命令连续监控至少24小时记录不同负载下的指标表现。重点关注显存占用是否随运行时间持续增长如果是说明有内存泄漏芯片温度是否长期处于高位如果是要检查服务器风道和散热功耗是否接近供电上限接近的话需要考虑降低batch或减少并发session如果单卡负载确实达到80%以上扩容方案有两种一是在同一台服务器里插多张Atlas 300V 24G用ASCEND_RT_VISIBLE_DEVICES环境变量控制进程绑定到指定卡二是横向扩容多台服务器用负载均衡把视频流分发到各个节点。两种方案各有利弊单机多卡管理简单、网络开销小多机分布式扩展性好、容灾能力强。根据项目规模和预算选择合适的方案就行。7. 常见报错与排障实录拿这些截图对照着查7.1 驱动与设备识别问题这一节的报错是我个人经历过的真实案例整理不一定覆盖所有分支但基本是高发问题。报错现象可能原因解决方案npu-smi info显示No devicePCIe识别失败或驱动未加载检查插槽是否插紧dmesg查看内核日志确认Above 4G Decoding开启驱动安装时报错kernel not found系统内核版本与驱动包不匹配查询官方兼容列表更换匹配的驱动版本或调整内核初始化ACL失败日志提示SO未找到CANN环境变量未配置重新source set_env.sh确认路径存在模型加载报内存不足显存被其他进程占用或模型转出尺寸太大用npu-smi清理进程或减少并发session数量推理跑一段时间后掉卡供电不稳或温度过高检查电源功率和风扇必要时降低芯片功耗模式设备识别这块最值得强调的还是“先检查物理连接”。我试过排查了半天软件最后发现是PCIe插槽没插到底。这种低级失误在赶工期的时候最容易犯拿到设备第一时间先检查卡是否完全插入、供电线是否接好能省很多时间。7.2 ONNX转OM阶段的报错与解决ATC转换阶段最容易出的两类问题算子不支持以及shape配置错误。算子不支持的报错信息一般会明确指出不支持哪个算子。我遇到过一次YOLOv7模型里某个自定义算子转不过去的情况后来通过修改模型结构或者是升级CANN版本解决。CANN版本对算子覆盖范围的影响很大升级版本往往是首选。shape配置错误更多是input_shape写得不一致导致的仔细核对导出时的输入形状即可。导出前最好打印一下模型的输入形状做到心中有数。另外转换时如果--soc_version填错了也会报错提示“invalid soc version”。不确定芯片型号时用npu-smi info查询后对照官方映射表填写。7.3 推理结果不对的排查思路这个问题的隐蔽性很高因为它不是报错而是结果不正确容易让人摸不着头脑。我总结的排查思路是先跑一张训练集里的标准图片用PyTorch原模型推理得到基准结果同一张图走ONNX模型推理确认ONNX导出无损同一张图走OM模型推理对比检测框坐标和类别如果坐标明显偏移重点检查前处理的resize方式、归一化方式、通道顺序如果框正确但类别错误检查类别索引和后处理时的类别映射在我项目里最常见的原因是前处理时把RGB通道顺序弄反了以及归一化时用了ImageNet的均值方差而YOLOv5训练时用的是0-1直接缩放。这类差异单看代码不容易发现多跑几张图对比就能定位。7.4 性能不达标的调优细节如果性能跟预期差距较大优先查看这三项模型是否还是FP32。转OM时设置--output_typeFP16推理性能差距接近一倍。是否开启了AIPPAI Preprocessing。AIPP是昇腾的图像预处理加速模块把crop、resize、归一化合成到一个周期里完成性能比每个环节单独做要快不少。线程数和会话数是否合理。并发会话太少会浪费算力太多反而会因为调度开销导致性能下降。我建议从2个并发开始逐步增加直到性能不再提升为止。8. 这套组合还能怎么扩展后续可做的事情8.1 从YOLOv5平滑过渡到YOLOv8如果你的新项目用的是YOLOv8迁移成本并不高。YOLOv8的ONNX导出链路做得很好输出层结构和YOLOv5有些差异主要是解耦头带来的输出通道变化后处理逻辑需要同步调整。前处理、ATC转换流程几乎可以复用。我的习惯是拿到一个新的检测模型后先固化成固定shape的ONNX再走一遍标准转换流程再用一组标准图片测试结果。流程定型后模型换血也就是一两天的事。8.2 从单模型到多模型流水线Atlas 300V 24G的显存充足可以考虑在一张卡上同时部署多个模型。比如先用一个轻量YOLO模型做前景检测再级联一个精度更高的分类模型对检测框分类。这样能充分利用显存和算力同时业务效果更好。我当时就在同一张卡上部署了检测模型和一个车牌识别模型通过两个推理会话分别调度跑得很稳定。具体实现时只要控制好显存分配和推理优先级即可。8.3 从离线推理到边缘一体化盒子如果后续有设备交付需求可以考虑把整套环境打包成边缘AI盒子形态。Atlas 300V 24G 一台紧凑型工控机 自研管理软件做成开箱即用的目标检测一体机。这种方案在项目复制和现场交付时优势明显硬件标准化了软件打包成镜像到现场插上电接上摄像头就能跑。我目前在这条路上还在持续积累经验后续有新的成果还会继续分享。
