企业官网建设流程全解析

前一阵有个朋友问我：Atlas 300V 24G到底是运算加速卡吗？他接了个工业质检项目，检测方案已经定了YOLO，但GPU预算一直谈不下来，正好有人推荐了Atlas系列。这个问题问得特别典型，因为很多人听到“加速卡”三个字，第一反应是“跟显卡差不多吧”，结果拿到手才发现，在Atlas上跑YOLO和GPU完全不是一条路。这篇文章就围绕我在Atlas 300V上部署YOLO的完整过程，把硬件认知、选型逻辑、环境准备、模型转换、推理代码、性能调优和踩坑经历一次说清楚，给准备上车或正在纠结的同行一个参考。

1. 先从“Atlas 300V是运算加速卡吗”这个问题说起

很多人看到“运算加速卡”这个说法会本能地往GPU上靠，觉得它跟NVIDIA T4、A10差不多，插上服务器就能跑CUDA。这个理解方向对了一半，也是后面无数坑的根源。

1.1 它确实是加速卡，但别按GPU的惯性来理解

答案先说结论：Atlas 300V是华为昇腾平台下的AI推理加速卡，核心是达芬奇架构的NPU（神经网络处理单元）。它确实“加速”计算，但加速的是神经网络算子，而不是通用的并行计算任务。它没有CUDA，不能直接跑PyTorch或者TensorFlow里那些默认走GPU内核的代码，必须走昇腾自己的工具链。

那它跟GPU到底差在哪？我用一个不太严谨但好理解的类比：GPU像是一个什么活儿都能干的通用型选手，C++程序、渲染、科学计算、深度学习样样沾；Atlas 300V更像是专为神经网络推理这条流水线定制的专用产线，卷积、矩阵乘、激活函数这些算子被硬化成专用电路，执行效率很高，但你想让它跑个通用计算，它不是干不了，而是压根不擅长。

Atlas 300V内部用的是昇腾310P系列芯片，我手头这张板卡是24GB显存版本。24GB听起来很唬人，但这里要泼盆冷水：深度学习推理卡的显存规模和训练卡不一样，它不追求单模型装得下超大batch，而是追求多路并发、多模型常驻、长稳运行。24GB对于YOLO这个级别的模型来说非常充裕，真正会被卡住的往往是算力、内存带宽和数据处理链路。

1.2 24G显存解决什么问题，钱花在哪里

先看一组我在选型时参考的粗算：YOLOv8s在640x640输入下，单路推理的模型权重加中间feature map占用，实际显存开销大约在1GB到2GB之间（取决于是否开启显存复用）。24GB意味着光从容量角度看，理论可以同时常驻十几个模型副本或者跑大批次，但你要明白一个反直觉的事实：推理卡的瓶颈通常不是“装得下”，而是“跑得动”。

Atlas 300V的定位非常清晰，就是给视频分析、工业质检、OCR、安防监控这类“多路输入、持续推理”的场景准备的。24G大显存的实际价值在于：第一，可以把多个不同模型同时常驻在显存里，省去反复加载模型的时间；第二，可以支撑比较大的batchsize，提升算力利用率；第三，给业务高峰留出缓冲，不会因为显存不足导致推理进程崩溃。

但我见过不少团队拿着这张卡当4090用，上来就想跑大batch训练，或者想直接跑未经过优化的原版PyTorch代码，结果发现算子不支持、性能拉胯，然后得出“这张卡不行”的结论。其实不是卡不行，是用法不对。推理卡就要用推理卡的打法，后面几节我会详细拆这个打法。

2. 把YOLO部署到Atlas的选型逻辑与三条技术路线

2.1 为什么这个组合适合视频推理类项目

YOLO系列模型是当前目标检测落地最广的方案之一，部署方式极其成熟，PyTorch、TensorRT、OpenVINO、ONNX Runtime都有现成路径。昇腾平台对YOLO的支持也比较积极，官方样例里长期维护着YOLOv3、YOLOv5、YOLOv7、YOLOv8相关的模型转换脚本和推理示例，所以“Atlas + YOLO”在昇腾生态里是条走得很顺的路。

从我实际测试的感受来说，YOLO部署到Atlas上有几个明显的优势：

• 部署成本可控。整卡功耗远比同级别GPU低，服务器电源和散热压力小，机房改造的成本几乎可以忽略。
• 供货和周期相对稳定。在某些项目里，通用GPU的交期和价格波动很影响进度，Atlas这种专用推理卡的供货节奏要好控制一些。
• CANN工具链内置了AIPP（图像预处理模块）、DVPP（视频解码硬加速）等专用模块，对视频流接入类项目非常友好，YOLO的前处理、编解码可以直接卸载到硬件上，CPU占用非常低。

2.2 三条路线：torch_npu、MindX SDK、AscendCL怎么选

在Atlas上跑YOLO推理，我实际接触到的路径大致有三条，很多人一开始就在这三条路里迷失。

先说说torch_npu。这是昇腾的PyTorch适配层，装完之后原版PyTorch代码里只需要把模型和tensor搬到npu设备上，很多算子能自动转换。我建议所有人都先走这条路，目的是确认模型能在昇腾设备上正确推理，排除算法层面的问题，然后再考虑性能优化。代价是这条路在性能上通常不是最优解，因为算子图可能没有完全下沉到NPU，部分算子会跑到CPU上，产生大量拷贝开销。

再说MindX SDK。它提供了一套流式推理框架，把视频解码、缩放、模型推理、后处理等步骤串成pipeline，官方对YOLO等常见模型有现成插件，适合直接做产品原型。如果你是要交付一个多路视频流实时检测系统，MindX SDK能省掉很多基建代码，但调试起来比较“黑盒”，遇到问题不如原生接口好定位。

最后是AscendCL（ACL）。这是最底层的推理API，相当于CUDA Runtime层。你需要手动管理设备、上下文、内存、模型加载、输入输出buffer，所有流程都在自己手里。优点是性能最好、调试最方便，缺点是代码量和工作量确实大，而且要对着文档一点点核对API签名。我的建议很直白：如果项目要长期迭代、性能要求高，走AscendCL；如果只是快速出Demo，走torch_npu或MindX SDK，绕开原生接口的复杂度。

3. 环境准备：驱动、固件与CANN版本匹配是第一道坎

这块我一定要放在模型转换前面写，因为绝大多数人的部署进度都卡在环境上，而不是模型上。Atlas环境安装比GPU要繁琐，因为它有驱动、固件、CANN工具包、PyTorch适配层等多个组件，而且版本之间存在强绑定关系。

3.1 装卡之后先用npu-smi确认设备状态

服务器插上Atlas 300V之后，先装驱动，再装固件，最后装CANN工具包。驱动一般是.run包，root用户下直接执行：

chmod +x Ascend-hdk-310P-npu-driver_23.0.rc1_linux-x86_64.run ./Ascend-hdk-310P-npu-driver_23.0.rc1_linux-x86_64.run --full

安装完成后，用npu-smi info检查设备状态。这个命令和nvidia-smi的地位一样，能看到芯片型号、温度、内存使用率、算力利用率。如果这里都看不到设备，后面所有操作都无从谈起。

+--------------------------------------------------------------------------------------------+ | npu-smi 23.0.rc1 Version: 23.0.rc1 | +-------------------------------+-----------------+------------------------------------------+ | NPU Name | Health | Power | Hugepages-Usage | | Chip Device | Bus-Id | AICore | Memory-Usage | +===============================+=================+==========================================+ | 0 310P | OK | 15W | 0 | | 0 0 | 0000:C1:00.0 | 0 | 1024MB / 24000MB | +-------------------------------+-----------------+------------------------------------------+

注意几个信息：Device编号、芯片型号（310P）、内存总量，以及Health状态是否OK。如果你拿到的是Atlas 300V Pro这种多芯片版本，npu-smi info可能列出多个Device，后面做多路并发时可以分别绑定不同Device。

3.2 CANN工具包与set_env.sh里藏着的坑

驱动和固件装好之后，设备已经能被系统识别，但这时还不能做模型转换和推理，因为缺少CANN工具包。CANN是昇腾的计算架构，ATC模型转换工具、AscendCL运行时、算子库都在里面。

./Ascend-cann-toolkit_7.0.RC1_linux-x86_64.run --install source /usr/local/Ascend/ascend-toolkit/set_env.sh

set_env.sh这个脚本非常关键，它把ATCL、AscendCL、opencv等库路径都加到环境变量里。我见过太多人卡在“运行atc提示找不到libascendcl.so”这个问题上，原因就是没有source这个脚本，或者source之后换了终端导致环境变量丢失。建议把它写进~/.bashrc，或者在你所有执行转换和推理的终端里固定source，不给野路子留机会。

3.3 版本匹配：驱动、固件、CANN、PyTorch适配层四者缺一不可

这套工具链里最折磨人的就是版本匹配。官网每个版本的CANN都对应一个推荐的驱动固件版本，PyTorch适配层（torch_npu）又对应一个CANN版本，它们之间有严格的兼容矩阵。我的经验是：不要追求最新版，要追求“验证过组合”。

从CANN的版本发布说明里找到那个版本推荐的配套组件版本，然后把四个组件一次装齐。如果先装了新版CANN，再去找旧版驱动，很可能会遇到driver and firmware version mismatch这类报错，这类问题的排查效率极低。

还有个常见场景是主机的Linux内核版本比较新，导致驱动编译失败。昇腾官方支持的Linux发行版和内核版本都有明确列表，我建议生产环境老老实实装Ubuntu 20.04或22.04 LTS的长期支持版本，不要图新鲜上最新内核。这个建议听起来保守，但能让你少熬两个通宵。

4. 模型转换全流程：YOLO从PyTorch到OM

模型从PyTorch训练权重变成昇腾能识别的OM格式，中间要经过两次格式转换：先导出ONNX，再用ATC工具把ONNX转成OM。关键词是“对齐”：输入输出、数据排布、预处理方式、动态维度，这些信息在两次转换中必须完全一致，任何一处对不上，后面推理结果都是错的。

4.1 导出ONNX时最容易埋雷的设置

以YOLOv8s为例，用ultralytics导出ONNX非常简单：

from ultralytics import YOLO model = YOLO("yolov8s.pt") model.export( format="onnx", imgsz=640, opset=11, simplify=True, dynamic=False, )

这里有两个地方特别容易踩坑。第一是dynamic=False，我在第一次转换时开了dynamic=True，想着后面多batch灵活一点，结果ATC转换直接报错，因为昇腾对动态shape的支持是有条件的，而且动态shape会显著增加推理时延（每次shape变化都可能触发重新构图）。如果你没有特别强的变长输入需求，就固定住分辨率，比如640x640，把batch固定为1或者一个确定值，这样做出来的OM模型时延最稳定。

第二是opset版本。ATC对ONNX算子版本有支持范围，opset 11是比较稳妥的选择。如果你用了更新版本的ultralytics，默认导出的opset可能更高，发现ATC不识别某个算子时，先别急着怀疑算子，试着降到opset 11或12再转一次。

导出之后先用onnxruntime跑一遍ONNX模型，确认它的输出格式。YOLOv8的ONNX输出是一个[1, 84, 8400]的张量（以COCO 80类为例），其中84是4个框坐标加80个类别得分，8400是不同尺度特征图上的候选框总数。这个结构后面写后处理时要用到。

4.2 ATC参数逐个拆解

ATC转换命令看起来只有几行，但每个参数都值得细抠。我实际使用的转换命令如下：

source /usr/local/Ascend/ascend-toolkit/set_env.sh atc \ --model=yolov8s.onnx \ --framework=5 \ --output=yolov8s_bs1_640 \ --soc_version=Ascend310P3 \ --input_shape="images:1,3,640,640" \ --log=error \ --output_type=FP16

参数含义我来解释一下，因为这些直接决定你后面能不能跑通：

• --framework=5：表示输入模型是ONNX格式。CANN里MindSpore、TensorFlow、Caffe等框架各有编号，ONNX是5，这个值填错了模型肯定解析不了。
• --soc_version=Ascend310P3：指定芯片型号。这里不能凭感觉填，要用npu-smi info看实际芯片型号。型号填错的话，ATC能转成功，但可能跑到不支持的算子上，或者在推理时直接报错。
• --input_shape="images:1,3,640,640"：固定输入shape。images是ONNX模型里输入节点的名称，在ultralytics导出的模型里通常就叫images，你可以用onnx.load()查看确认。这里把batch固定为1。
• --output_type=FP16：让模型以FP16精度推理。昇腾的推理卡对FP16有硬件优化，速度比FP32要快很多。但FP16对数值敏感，尤其是某些归一化方式不对的场景下，检测框精度会有小幅度下降，后面我会讲怎么验证这个问题。
• --log=error：只看错误日志。转换报错时信息会非常多，把日志级别设为error可以快速聚焦到真正的报错点。

4.3 转换后的精度和输出差异验证

模型转完不代表万事大吉，OM模型和PyTorch原模型之间可能存在微小差异，来源主要有：FP16精度截断、算子融合导致的数值顺序变化、预处理输入不一致。我强烈建议在做任何性能优化之前，先做一次精度验证。

我的验证方法是：选一张典型的测试图，分别用PyTorch原模型和转换后的OM模型前向推理，把两边的输出张量全部导出来，计算余弦相似度或者逐元素差值。

通道维度上的最大绝对误差：0.0132 余弦相似度：0.99941

如果余弦相似度在0.99以上，说明模型转换基本没有丢失信息；如果掉到0.95以下，检测框很可能会出现偏移和漏检，这时优先检查FP16是否引入过大误差，可以在ATC参数里去掉--output_type=FP16，或者检查输入数据归一化方式是否和训练时一致。

5. 用AscendCL写YOLO推理的代码骨架

如果你选了AscendCL这条路，下面这份代码骨架保存好，它是你在Atlas上所有推理业务的基础。我写的这个版本虽然是Python，但它直接映射C++的底层调用逻辑，理解之后改写C++非常快。

5.1 初始化、加载模型、准备输入输出的标准流程

import acl # 1. 初始化 ret = acl.init() assert ret == 0 # 2. 设置设备 ret = acl.rt.set_device(0) # 3. 创建context和stream context, ret = acl.rt.create_context(0) stream, ret = acl.rt.create_stream() # 4. 加载OM模型 model_id, ret = acl.mdl.load_from_file("yolov8s_bs1_640.om") # 5. 拿到模型描述，获取输入输出尺寸 model_desc = acl.mdl.create_desc() ret = acl.mdl.get_desc(model_desc, model_id) input_size = acl.mdl.get_input_size_by_index(model_desc, 0) output_num = acl.mdl.get_num_outputs(model_desc) print("input_size:", input_size, "output_num:", output_num) # 6. 申请device侧内存 input_buffer, ret = acl.rt.malloc(input_size, 2) # 2 表示ACL_MEM_MALLOC_HUGE_FIRST output_buffers = [] output_sizes = [] for i in range(output_num): size = acl.mdl.get_output_size_by_index(model_desc, i) buf, ret = acl.rt.malloc(size, 2) output_buffers.append(buf) output_sizes.append(size)

ACL这套流程对应着GPU上cudaSetDevice、cudaStreamCreate、cuModuleLoad等操作，逻辑是一样的，只是名称和参数风格不同。整个生命周期分为初始化、加载、推理、清理四个阶段，如果你深挖过CUDA，上手ACL不会太难。

5.2 预处理放NPU还是CPU：AIPP的选择

接下来是把一帧图像塞进输入buffer。这里有个岔路口：是在CPU上用OpenCV做letterbox、归一化、BGR转RGB，再拷贝到device内存，还是用ATC的AIPP配置在NPU端完成预处理？

两条路我都跑通过，区别非常明显：

• CPU预处理代码透明、好调试，而且能复用现有OpenCV代码，但会占用CPU资源，而且在host和device之间有大量数据拷贝，延迟偏高。
• AIPP预处理更像一个“硬件预处理通道”，它在模型加载时配置好，推理时直接喂原始图像即可，缩放、归一化、格式转换都在NPU端完成，延迟更低，CPU占用几乎为零，但配置错误后非常难排查——因为你看不到中间结果。

技术上讲，如果你追求极致的多路并发性能，AIPP几乎必须用。但第一次跑通流程我建议先用CPU预处理，等整体链路验证无误后再切换到AIPP。老实说，AIPP debug像在黑盒子里摸索，一个channel order配错，输出的检测框就开始乱飘，而CPU预处理是透明的，每一步都能打印中间结果。

我最终使用的是AIPP方案，关键配置如下：

aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_h: 640 src_image_size_w: 640 csc_switch: false 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 }

这里var_reci_chn_0到var_reci_chn_2是归一化系数1/255，rbuv_swap_switch: true控制的是RGB通道顺序。如果你的训练代码用RGB输入，这里就开true；如果你训练时用BGR（很多YOLO历史版本是这样），这里就要关掉。这块配错是检测框“看着没问题但位置偏移”的高频原因。

5.3 后处理与坐标解码的注意事项

推理执行完之后，输出buffer里是一个一维float数组，需要按前面说的[1, 84, 8400]结构重新解析。第一步是把它按FP16或FP32格式从bytes转为numpy数组：

output_np = np.frombuffer(output_bytes, dtype=np.float16).reshape(1, 84, 8400)

然后做标准的YOLOv8解码：把前4行作为框坐标（此时是特征图尺度，需要乘以输入尺寸与原始图像尺寸的比例），后面80行作为分类得分，通过置信度阈值和NMS过滤。注意解码逻辑必须和模型训练时一致，YOLOv8的坐标是直接回归的，不需要像YOLOv5那样做anchor解码。

后处理我建议保留在CPU上做。为什么？因为NMS这类带循环和排序的操作在NPU上并不高效，而且单张图的候选框数量有限，CPU处理的开销完全可以接受。如果一定要在NPU上做后处理，需要把NMS算子也固化成模型的一部分，配置复杂度会明显上升，收益却不大。

6. 24G显存与多路并发：性能实测和调优记录

到了这个阶段，模型已经能跑通了，接下来才是真正的重头戏——性能调优。24G显存到底能同时跑多少路YOLO，这是大家最关心的问题。

6.1 单路延迟、并发吞吐和数据能说明什么

在我手头这套环境（Atlas 300V / Ascend 310P系列芯片，CANN 7.0，YOLOv8s，640x640，FP16）下，实测单路推理延迟大约在10到20毫秒量级，这个数字对视频分析类项目来说已经够用，相当于单路25FPS以上。但我必须补一句：不同驱动版本、不同CANN版本、不同模型输入尺寸下，这个数值浮动会很大，我给的只是参考量级，不是benchmark结论。

真正要关注的是多路并发。你的业务场景往往是十几路视频流同时进，每路做独立的目标检测。这里有个很重要的概念要区分：路数和batchsize。如果你开多个进程，每个进程加载同一个模型，各自跑一路视频，那么它们抢占的是同一块NPU算力，总吞吐不一定能翻倍，甚至因为内存争抢而下降。

我的实测建议是：单模型场景下，尽量用一个进程内多线程/多stream的方式做并发，而不是开一大堆进程各自加载模型，后者对24GB显存和NPU利用率都不友好。如果板卡是多Device（比如npu-smi里能看到0和1两个逻辑设备），可以按视频流数量平均分配到每个Device上，充分利用多个芯片。

6.2 显存池与模型常驻的调优方式

24G显存的另一个玩法是多模型常驻。质检业务里往往不是只跑一个YOLO，前面可能有一个小模型做缺陷粗分类，后面接一个更大的模型做细分类，甚至还有OCR模型。如果每个模型随用随加载，光模型加载时间就能吃掉很大一部分时延。

我的做法是启动阶段把所有模型一次性加载到显存，之后整个生命周期都不再释放。上面代码里的acl.mdl.load_from_file在启动阶段执行一次，之后所有推理请求只做acl.mdl.execute。这一步看起来不起眼，但实测在多模型切换场景下能减少几百毫秒到秒级的等待时间。

如果你需要严格控制显存分配，可以用ACL的显存池配置接口。简单的思路是先预估所有模型占用的显存总量，然后给进程设置一个可用的内存上限，避免某个进程把显存吃满导致其他进程OOM。24G看着大，多路并发、多模型常驻、再加上输入输出缓冲，很快就会紧张起来。

6.3 更进阶的流水线优化思路

如果单路延迟已经降不下来，但整体吞吐还不够，我建议做流水线。

推理过程本质上是“取流-预处理-模型推理-后处理”四个阶段的循环。按最简单的串行方式，每一帧都依次走完这四个阶段，GPU/NPU在等你CPU做预处理时就在空转。流水线的思路是把这四个阶段打散到不同的线程里，CPU在预处理第N+1帧时，NPU正在推理第N帧，后处理线程同时处理第N-1帧。

在ACL里实现这个思路非常简单，靠的就是stream。每个线程持有一个stream，推理任务提交到stream后立即返回，CPU线程不需要等NPU算完才能继续。配合前面说的多路视频流，每个视频流可以绑定一个独立stream，这样NPU利用率能明显提升，整体的吞吐量比单线程串行高出一大截。

7. 我踩过的四个坑和完整排查链路

最后这部分我认为是全篇最有价值的地方。环境装好、模型转好、代码写完，这些事情花点时间都能搞定，但运行期的各种隐秘问题，才是真正消耗时间的部分。我把自己踩过的四个坑的完整排查过程写出来，你可以直接拿这套思路去套你自己的问题。

7.1 坑一：ATC转换时动态shape报错

现象：使用dynamic=True导出的ONNX模型做ATC转换，报错提示某个维度不支持动态化，直接中断。

排查链路：我先检查了ONNX模型输入节点的shape，发现batch维度是None，说明确实是动态模型。然后我尝试了两个方向：一是用--dynamic_batch_size="1,2,4,8"参数显式声明batch范围，二是在导出ONNX时固定shape。前者的转换偶尔能过，但运行时会提示shape派生失败，稳定性很差。

最终定位：问题根因是ATC对动态shape的支持并不像ONNX Runtime那么宽松，它需要模型在构图时就有确定的shape，否则算子图无法固化。我的解决方式是放弃动态shape，导出ONNX时就固定imgsz=640、dynamic=False，ATC转换一次通过。

验证结果：固定shape后推理延迟比之前动态版本下降了大约20%，因为不需要每次构图。这个坑给我的教训是：昇腾平台上的推理模型，shape固定得越死，性能越稳。

7.2 坑二：转完OM后检测框整体偏移，精度下降严重

现象：OM模型在测试集上漏检率明显高于PyTorch原模型，尤其是小目标几乎全丢。用余弦相似度对比输出张量，只有0.89左右。

排查链路：第一步我以为是FP16精度问题，去掉--output_type=FP16重新转换，用FP32推理，相似度只提升了一点点，检测框依旧偏移。第二步我怀疑是NMS阈值问题，但OM后处理我还是用原来的逻辑，排除。第三步我把目光转向预处理，打印了OM模型输入的像素值，结果发现问题：我的AIPP配置开了rbuv_swap_switch: true，也就是做了RGB通道交换，但我的训练代码本来就是RGB顺序读取图片的，等于通道被翻了两次。

最终定位：AIPP里的通道顺序配置和训练时不一致，导致模型输入分布完全不对。把rbuv_swap_switch改成false之后，相似度从0.89直接跳到0.997，检测框恢复精准。

验证结果：这个坑给所有上Atlas的开发者提了个醒——AIPP配置和训练预处理必须逐项对照，RGB/BGR、归一化系数、缩放方式，任何一个不一致，模型精度就会莫名其妙地崩。

7.3 坑三：NPU利用率低，跑不满算力

现象：多路并发调用时，npu-smi info显示AICore利用率只有30%左右，但推理延迟没有显著下降，感觉很亏。

排查链路：我先排除了代码问题，确认推理本身是在NPU上执行的。然后我检查了host和device之间是否有频繁的数据拷贝，结果发现在CPU预处理方案下，每一帧都要做一次acl.rt.memcpy把图片从host拷到device，这个拷贝的开销非常大，尤其是在多路并发时，拷贝成了瓶颈。

最终定位：解决方案是把预处理挪到AIPP里，在NPU端做缩放和归一化，host只负责把原始图像字节流传给device，避免了CPU上OpenCV预处理带来的额外延迟和内存拷贝量。更换后AICore利用率从30%升到70%左右，吞吐量提升了一倍多。

验证结果：其实还有优化空间，比如用DVPP做硬件解码和缩放，但AIPP已经解决了主要矛盾。这个坑的通用经验是：看到NPU利用率低，先别急着怪模型太小或硬件不行，优先检查数据传输链路是不是在空转。

7.4 坑四：多进程同时加载模型导致设备内存不足

现象：我用多进程方式（每个进程一个视频流）做并发测试，跑到第8个进程时直接报设备内存分配失败，应用崩溃。

排查链路：第一反应是24G显存被某几个大模型吃光了，但用npu-smi info查看，发现显存占用并没有溢出。仔细检查代码后发现，问题不在模型本身，而在于每个进程都独立初始化了ACL context和stream，并且都申请了固定的输入输出buffer，加上ACL的运行时缓存，每个进程的额外内存开销其实不小。

最终定位：一是把多进程改成单进程内多stream的并发模式，二是给每个Device设置合理的显存上限，三是对输入输出buffer做复用，不要每帧都malloc和free。这三个调整做完之后，同一张卡上同时跑的路数明显提升，内存占用始终稳定在可控范围内。

验证结果：稳定跑了72小时压测，没有复现内存溢出。这个坑提醒我：Atlas的24G显存虽然大，但多进程模式下的开销是叠加的，不能简单用“模型大小乘以路数”来算总内存。

最后再分享一点个人体会：Atlas这套工具链对刚从GPU生态过来的人确实不那么友好，很多概念要重新学，但一旦把模型转换、AIPP、stream并发这套链路理顺，它的稳定性、功耗和成本优势就会显现出来。如果你正准备在Atlas 300V上部署YOLO，我的建议是先把固定shape、FP16、AIPP这几件事一次做对，不要急着追新版本工具链。模型跑通之后，再去研究多流并发和显存池优化，这条路走下来，你的部署经验就完整了。