企业官网建设流程全解析

最近后台收到不少消息，都是同一个问题：“Atlas 300V 24G 是运算加速卡吗？”还有人在问“用 Atlas 部署 YOLO 靠不靠谱”。这俩问题其实可以合并成一个答案：Atlas 300V 是一张不折不扣的AI推理加速卡，而且用它跑 YOLO 系列模型，恰恰是这个产品最典型、也是最成熟的用法。这篇文章就围绕这张卡，把我从硬件选型到模型转换再到推理代码、最后到性能调优的完整过程写一遍，希望能帮正在纠结选型或者卡在部署环节的人少走点弯路。

先说清楚我的使用场景：边缘侧视频流分析，目标是实时检测画面中的目标，模型用的是 YOLOv5s 和 YOLOv8s 两个版本，输入 640x640，单路视频流，要求延迟控制在 30ms 以内。后面所有步骤和坑都是在这个场景里踩出来的。

1. 先回答热搜：Atlas 300V 24G 到底是不是加速卡

这类问题之所以反复出现，是因为 Atlas 这个命名体系太容易让人懵了——Atlas 800、Atlas 300I、Atlas 300V、Atlas 500，还有各种 Pro、Duo 后缀，光看名字根本分不清谁是训练卡谁是推理卡谁是边缘盒子。我最初也绕了很久。

1.1 Atlas 300V 的产品定位

Atlas 300V 是昇腾生态里的推理卡，准确说是面向边缘服务器和数据中心推理场景的 PCIe 加速卡，核心芯片是昇腾 310P（Atlas 300V Pro 对应的是 310P3）。它不是拿来训模型的，而是拿来把训练好的模型“跑起来”的。

这张卡有几个让做边缘部署的人非常舒服的特性：

• 板载 24GB 内存，对于 YOLO 这种动辄需要多路并发或较大 batch 的推理任务，余量很足；
• 整卡功耗大概 75W 左右，不需要外接供电，一个 PCIe 插槽直接带起来，被动散热，服务器里不用专门设计风道；
• 官方标称 INT8 算力可达 140 TOPS，虽然 INT8 纸面数据和实际吞吐永远有差距，但跑 YOLOv5s 这种级别的模型，单路 640x640 输入的纯推理延迟能压到 10ms 量级，这个是实测数据，不是宣传稿；
• 自带 DVPP 硬件编解码模块，支持 H.264/H.265 解码和 JPEG 编解码，视频流场景里解码不用占 CPU。

所以结论很明确：它是运算加速卡，但它是推理加速卡，不是训练加速卡。你要是抱着“买了它就能替代 GPU 训练模型”的想法，那一定会失望；你要是想在边缘服务器上低成本、低功耗地把 YOLO 部署起来做实时推理，那它非常合适。

1.2 和 GPU 方案对比：不要用 GPU 的惯性思维看它

很多人第一次接触昇腾卡，最不习惯的就是“显存”这个概念不存在了。Atlas 300V 那 24GB 是板载内存，不是显存。在 CUDA 生态里，你把 tensor 搬到 GPU 显存，然后 GPU 直接访问；在昇腾环境里，你同样需要把数据从 Host 拷贝到 Device，但它是通过统一的 Device 内存管理来做的，ACL（Ascend Computing Language，昇腾的编程接口）会帮你管理这块内存。

另一个反直觉的地方是：这张卡不支持通用的 CUDA 代码。你手里的 YOLO PyTorch 代码不能直接“跑”在 Atlas 上，需要先做模型转换——把 PyTorch 权重导出成 ONNX，再用昇腾的 ATC 工具转换成自家的 OM 格式。这一步是很多人第一次接触昇腾卡时最大的拦路虎，我后面会专门用一整章来讲。

如果你的需求是“把现有 GPU 服务的代码原封不动搬到边缘”，那 Atlas 300V 的学习成本确实比 GPU 高一些；但如果你是从零开始做边缘部署，并且愿意按照昇腾的工具链来设计流程，那它性价比非常高——毕竟这个功耗和体积下面，单卡跑十几路 YOLOv5s 推理是毫无压力的，这是同功耗 GPU 很难做到的事。

2. 部署 YOLO 之前的软件栈准备：驱动、固件、CANN 与版本配套

在真正跑通 YOLO 之前，你首先要面对的是昇腾的软件栈。坦白说，第一次接触这套东西确实有点头大，因为它的组成比 CUDA 生态要复杂那么一点，但只要你理解几个核心组件各自该干什么，后面就顺了。

2.1 四大组件的职责划分

用 CUDA 生态来类比，昇腾的软件栈可以这么理解：

驱动和固件统称 HDK，在昇腾社区官网下的是一个 .run 安装包，比如Ascend-hdk-310P-npu_xxx.run，装的时候会自动处理固件。CANN 是另一个 .run 包，安装路径默认在/usr/local/Ascend/ascend-toolkit。

2.2 最容易踩的坑：版本配套

我在这套软件栈上踩过最深的坑，就是“驱动、固件、CANN 三者版本不配套”。表现形式很迷惑：npu-smi info能正常看到卡，但一跑 CANN 的样例程序就报E10004、E10020这类初始化错误，排查半天，最后发现是固件版本太新/太旧，和 CANN 要求的版本对不上。

强烈建议：装软件之前，先去昇腾社区找那个《CANN 版本配套表》，把你选定的 CANN 版本对应的驱动和固件版本号抄下来，然后严格按那个版本去下载安装。不要手滑装最新版，最新版不一定和你的 CANN 匹配。

我当时的组合是：Ubuntu 20.04 x86_64 + 驱动/固件 23.0.3 + CANN 7.0.0，跑通了 YOLOv5s 和 YOLOv8s。这个组合不是唯一选择，但胜在资料多，网上踩坑记录也多，遇到问题容易搜到。

2.3 安装顺序和环境变量

安装顺序有讲究，我建议按这个顺序来：

1. 装操作系统，确保是昇腾支持的内核版本；
2. 安装驱动和固件.run包，装完重启，执行npu-smi info确认能看到卡、温度频率正常；
3. 安装 CANN Toolkit.run包，安装时选择完整安装；
4. source /usr/local/Ascend/ascend-toolkit/set_env.sh，把环境变量注入当前 shell；
5. 跑一个 CANN 自带的样例，比如resnet50分类样例，确认整条链路通了再上 YOLO。

还有一个细节：如果服务器上有 NVIDIA GPU，CUDA 和 CANN 可以共存，但要注意LD_LIBRARY_PATH的优先级，别让两个运行时互相污染。我见过最奇葩的问题是libascendcl.so找不到，原因就是环境变量被 CUDA 的覆盖了。

提示：npu-smi info是排查问题的第一工具。卡的驱动版本、固件版本、算力使用率、温度、内存占用全在里面，任何异常先看它。

3. 把 YOLO 的权重变成昇腾的 OM 模型：ONNX 导出与 ATC 转换

这是整条链路里最“昇腾特色”的一步，也是新手最痛苦的一步。PyTorch 那边训练好的.pt权重，昇腾卡不能直接用，必须变成.om格式。转换链路是：.pt -> ONNX -> OM。

3.1 导出 ONNX 时要想清楚的问题

YOLOv5 官方仓库自带export.py，YOLOv8 也差不多，命令很简单：

python export.py --weights yolov5s.pt --include onnx --opset 12 --simplify

但有几个点必须提前想清楚：

• opset 版本不要盲目追高。我一开始用默认的 opset 17 导出的 ONNX，ATC 转换时报了一堆算子不支持，后来降到 opset 12 就干净了。昇腾的算子库对常见 ONNX 算子覆盖很好，但冷门算子、高版本新算子就可能没覆盖。YOLO 这种模型结构主流算子都有，opset 12 足够；
• NMS 要不要放进模型？我的建议是不要放。YOLO 官方的 ONNX 导出一般会输出三个头的原始特征，NMS 放到 Host 端用 numpy 或 OpenCV 做。虽然昇腾也提供了一些带 NMS 的模型样例，但把后处理放在 Host 端，调试时你能清楚地看到模型输出的原始张量，排查问题方便得多；
• 导出完成后，先拿onnxruntime在 CPU 上对一张测试图跑一次推理，确认 ONNX 输出是正常的，再进入 ATC 转换。这一步能帮你过滤掉一半的问题，否则你分不清是导出坏了还是转换坏了。

3.2 ATC 转换命令与 AIPP 配置

ATC 是昇腾的模型转换工具，一个典型的转换命令长这样：

atc \ --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_bs1 \ --soc_version=Ascend310P3 \ --input_shape="images:1,3,640,640" \ --input_format=NCHW \ --output_type=FP32 \ --insert_op_conf=aipp.cfg

几个参数逐个说：

• --framework=5：5 表示 ONNX，这个固定别改；
• --soc_version=Ascend310P3：这里非常容易写错。Atlas 300V Pro 对应的是 310P3，不是 310P，也不是 310B，写错会直接报错。npu-smi info能看到实际芯片型号，照着填就行；
• --input_shape：我习惯用固定 batch 的静态 shape。YOLO 部署场景里，性能优先，固定 shape 是最优解；
• --output_type=FP32：输出数据保持 FP32，方便后处理代码解析；
• --insert_op_conf：AIPP 配置文件，这个值得单独说。

AIPP（Ascend Image Pre-Processing）是一个非常强大的东西，它把图像的色域转换、归一化、抠图这些预处理直接下沉到硬件里，Host 端只需要把原始图像数据丢进去就行。我的 AIPP 配置简化后长这样：

aipp_op { aipp_mode: static input_format: RGB888_U8 mean: 0.0 0.0 0.0 min_chn_0: 0.0 min_chn_1: 0.0 min_chn_2: 0.0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }

注意这里var_reci_chn_0的值是 1/255，作用是把 0~255 的像素除以 255 归一化到 0~1。而 YOLO 官方 pipeline 里归一化也是除以 255，所以这里正好对应。如果你的训练 pipeline 用的是 ImageNet 的 mean/std，那就要改成对应的数值，不能用 1/255 硬套。

AIPP 配置最关键的坑是输入格式必须和配置里一致。上面配置写的是RGB888_U8，那 Host 端喂给模型的数据就必须是 HWC 排布的 RGB 数据。你用 OpenCV 读图读出来是 BGR，不转换直接喂就是灾难——所有颜色通道都串了，检测结果会非常诡异，后面第 5 部分我会详细讲这个坑。

3.3 转换成功的标志与动态 shape 选项

转换成功的标志是在当前目录生成.om文件，同时会有一个fusion_result.json之类的调试文件和算子编译详情。建议转换完成后用atc的离线工具或者直接写个几行的 Python 脚本加载 OM，验证输入输出形状对不对。

如果确实需要多尺寸输入，ATC 支持动态 shape，配置方式类似：

--input_shape="images:-1,3,640,640" \ --dynamic_dims="1;4;8"

但这种模式一般会关闭很多构图优化，实测性能比固定 shape 差 20%~30%。我的建议是分场景处理：固定尺寸（如 640x640）用固定 shape；需要多分辨率，就为每个分辨率各转一个 OM 模型，运行时按需加载。边缘设备上内存不紧张，多放几个模型文件完全可行。

4. 推理代码怎么写：ACL 的 API 骨架与数据流梳理

模型转换成 OM 之后，正式进入写代码环节。昇腾推理编程接口叫 ACL（Ascend Computing Language），提供 C 和 Python 两套 API。我用的是 Python，也就是 pyACL，开发效率高，性能损失在可控范围内。但无论用哪套，核心调用逻辑是一样的。

4.1 初始化和模型加载

整个推理流程的第一步，是把 ACL 环境跑起来：

import acl import ctypes import numpy as np # 初始化 ACL ret = acl.init() assert ret == 0, f"acl.init failed: {ret}" # 设置并激活计算设备，0 是设备号 ret = acl.rt.set_device(0) assert ret == 0 context, ret = acl.rt.create_context(0) assert ret == 0 # 加载 OM 模型 model_id, ret = acl.mdl.load_from_file(b"yolov5s_bs1.om") assert ret == 0 model_desc = acl.mdl.create_desc() ret = acl.mdl.get_desc(model_desc, model_id) assert ret == 0

这套初始化的顺序是固定的：acl.init->set_device->create_context->load_from_file，不要调换，否则会出现很莫名其妙的报错。

4.2 输入输出的内存管理

模型加载后，你需要跟模型描述（model_desc）拿输入输出的大小和数量，然后在 Device 侧分配内存。这一步很多教程写得太简单，导致你直接把 numpy 数组丢进去就会报“input_ptr is null”之类的错误。核心原因是：ACL 需要的是 Device 内存指针，不是 Host 内存指针。

正确的内存分配方式是：

# 获取模型输入输出信息 input_size = acl.mdl.get_input_size_by_index(model_desc, 0) output_num = acl.mdl.get_num_outputs(model_desc) output_size = acl.mdl.get_output_size_by_index(model_desc, 0) # 在 Device 上分配内存 input_ptr = ctypes.c_void_p() ret = acl.rt.malloc(ctypes.byref(input_ptr), input_size, ACL_MEM_MALLOC_NORMAL_ONLY) # 把 Host 端的图像数据拷贝到 Device 内存 # src_ptr 是 Host 端 numpy/ctypes 数组的指针 ret = acl.rt.memcpy( input_ptr, input_size, src_ptr, input_size, ACL_MEMCPY_HOST_TO_DEVICE )

然后创建一个数据缓冲区，把 Device 指针挂到 Dataset 上：

input_dataset = acl.mdl.create_dataset() input_data_buffer = acl.mdl.create_data_buffer(input_ptr, input_size) ret = acl.mdl.add_dataset_buffer(input_dataset, input_data_buffer)

输出侧逻辑一样，但要按output_num循环创建输出 buffer。很多人只分配一个输出内存，但 YOLOv5s 的输出头有四组（一组主输出加三个检测头，具体数量取决于导出方式），内存大小也不同，漏掉任何一个执行时都会崩。

4.3 执行推理与数据拷贝回 Host

推理执行本身很简单：

# 创建 stream stream, ret = acl.rt.create_stream() # 异步执行 ret = acl.mdl.execute_async(model_id, input_dataset, output_dataset, stream) # 等待 stream 完成 acl.rt.synchronize_stream(stream)

执行完之后，输出数据还在 Device 内存里，你要把它拷回 Host 才能做 NMS 和后处理。拷回方式和输入一样，用acl.rt.memcpy，方向参数改成ACL_MEMCPY_DEVICE_TO_HOST。拷回来之后，为什么有的教程里输出 shape 不对？因为你拿到的是一块连续内存，你需要结合model_desc里的维度信息把它 reshape 成真正的[batch, num_detections, 6]或三个头的形状。这个 reshape 逻辑写在后面一小节。

4.4 一个重要的资源释放顺序

代码跑完后，释放资源的顺序也必须有章法，否则轻则内存泄漏，重则进程退出时卡死。正确顺序是：

1. 销毁输入输出的 Data Buffer 和 Dataset；
2. acl.mdl.unload(model_id)卸载模型；
3. acl.rt.destroy_stream(stream)销毁 stream；
4. acl.rt.destroy_context(context)销毁 context；
5. acl.rt.reset_device(0)复位设备；
6. acl.finalize()收尾。

提示：不要在execute_async刚返回就释放 dataset buffer，一定要等synchronize_stream之后再释放。异步执行意味着调用返回时推理可能还没完成，提前释放会导致推理结果随机出错，且极难排查。

5. 部署路上最真实的那些报错：排查链路与解决记录

这一章我写几个自己真实踩过、也帮别人排查过的报错，把完整的排查链路放出来。昇腾的报错信息一直都有“信息量不足”的毛病，很多错误码官网查不到细节，只能靠经验一点点试。这些记录是我觉得对读者最有价值的部分。

5.1 报错链路一：ATC 转换时报算子不支持

这是我第一次转 YOLOv5s 时最先遇到的。现象是 ATC 转了好几分钟，然后抛出一段 Python traceback，核心内容是Unsupported op [...]。我第一次看到直接懵了，以为自己用的 YOLOv5s 结构太新，昇腾不支持。

完整排查链路是这样的：

1. 先看报错里的算子名，拿算子名去昇腾算子清单里查，确认它是不是真的不支持；
2. 发现报错的算子不是模型核心算子，而是 ONNX 导出时额外生成的一些辅助算子，比如高版本 opset 才有的Resize坐标变换模式、GridSample等；
3. 尝试把导出 ONNX 时的opset从 17 改成 12，重新导出；
4. 再跑 ATC，这次顺利通过，耗时不到一分钟。

这个坑的教训是：升级导出工具的默认版本不一定带来兼容性，反而可能引入昇腾算子库还没覆盖的新算子。如果你的模型结构不复杂，优先选一个成熟、稳定的 opset 版本，而不是追最新。

5.2 报错链路二：推理能跑，结果全乱

这是比“报错”更让人头疼的问题：模型加载成功，代码执行成功，没有任何异常，但检测框坐标全是 0，或者框的数量对但坐标完全不对。我排查了大半天，最后定位到两个叠加原因。

第一个原因是数据排布问题。我的推理代码直接用 OpenCV 读取图像，然后按照模型的input_format=NCHW做了transpose(2, 0, 1)，但这和模型内部 AIPP 配置的RGB888_U8（HWC 排布）不一致。AIPP 在硬件里做了 HWC 到 CHW 的转换，我却在 Host 端又手动转了一次，等于转了两次。

第二个原因是通道顺序问题。OpenCV 读出来是 BGR，但 YOLOv5 训练时用的预处理是 RGB，我用 BGR 喂进去，检测结果当然乱七八糟。这个问题在 GPU 上通常不容易暴露，因为很多人直接用 PyTorch 的 transform，颜色顺序对了；但到了手写 ACL 代码这一步，所有细节都得自己负责。

定位方法我建议这样：先把 AIPP 关掉（转换时不加--insert_op_conf），Host 端用纯 numpy 做归一化和 HWC->NCHW 转换，确认模型输出正常；再逐步开启 AIPP，每次只改一个变量。这样你就知道到底是 AIPP 配置错还是 Host 预处理错。

5.3 报错链路三：CANN 环境初始化失败

E10004这个错误码，你如果玩昇腾，迟早会遇上。我第一次遇到是在装完 CANN 后跑官方样例，结果初始化直接失败。npu-smi info正常显示卡，这就很奇怪了——驱动看起来是好的。

排查链路：

1. 用npu-smi info确认驱动和固件版本；
2. 发现固件版本是23.0.2，而 CANN 7.0.0 要求的是23.0.3；
3. 重新下载配套的固件包，重新安装固件，重启；
4. 再跑样例，正常通过。

这个坑的根源是：驱动负责系统识别设备，固件负责芯片底层逻辑，很多上层接口的行为是被固件版本决定的。固件和 CANN 版本不配，等于买了新灯泡但用了旧电压。装软件前先查配套表，装完第一件事永远是用官方样例做冒烟测试。

5.4 报错链路四：异步推理结果不稳定，时好时坏

这个坑更隐蔽。现象是推理 100 张图，前 90 张正确，后面某几张突然检测不到目标，或者框位置偏移。重新运行同样输入，又是同样的错，但换一批图就不一定复现。

最后查到的根源出在上面第 4 部分提到的资源释放问题上——我在某个分支里提前释放了 dataset buffer，异步推理还没真正执行完。由于执行速度和 stream 调度的随机性，偶尔能碰上“刚好执行完”的时间窗口，所以问题时有时无。

解决方法是严格保证：execute_async之后必须synchronize_stream，之后才能碰 dataset buffer。

5.5 报错链路五：输入图像内存没对齐

这个坑属于昇腾特有的。我在跑 YOLOv8s 时，把输入从 640x640 换成 1280x1280，结果在acl.rt.memcpy之前就报内存对齐错误。

原因是昇腾的 Device 内存访问有对齐要求，某些 API 对数据指针的地址对齐有要求（比如 16 字节对齐）。解决问题也很简单：用acl.rt.malloc分配内存，而不是把我自己的 numpy 数组指针直接传给 Device 侧接口。acl.rt.malloc本身就能保证对齐，这也是为什么官方 DEMO 里都要求用acl.rt.malloc而不是直接把 Host 指针塞进去。

6. 从能跑到跑得快：内存、批处理与 AIPP 的调优思路

模型能在卡上跑起来了，这只是及格线。做边缘部署，最终都要回答“性能够不够”这个问题。这一章分享几个实测有效的调优方向。

6.1 固定 shape 优先于动态 shape

在第 3 部分提过，动态 shape 会损失性能。这里给个具体数据：我用 YOLOv5s 分别在固定1,3,640,640和动态-1,3,640,640两种 OM 模型上测试，纯推理延迟从 8ms 涨到 11ms，涨幅接近 40%。原因是动态 shape 会让算子构图和内存规划走通用通路，很多静态 shape 下能做的算子融合都做不了。

因此，如果你的输入尺寸在部署时是确定的，或者能通过 padding/resize 强制到固定尺寸，那一定要用固定 shape。边缘场景里摄像头输出分辨率一般是固定的，直接预案到 640x640 完全可行。

6.2 batch 与多 stream 的取舍

单个进程内跑单路视频，延迟优先，我用 batch=1。但如果你要在同一张卡上同时处理多路视频流，有两条路：

• 把多路预处理完的图像拼成一个大 batch，一次推理处理多路，吞吐最大化；
• 开多个 stream，每个 stream 跑一路视频，互不阻塞，延迟更稳定。

我实测下来，四路 1080p 视频用 batch=4 推理，整体吞吐比开四个独立 stream 更高，但延迟抖动更大；如果你对单路延迟敏感（比如工业质检不允许某一帧卡顿），那多 stream 更合适。这个取舍没有标准答案，取决于你的业务是“吞吐优先”还是“延迟优先”。

6.3 把预处理尽量沉到底层

第一次跑通后，我用perf看了下时间分布，惊讶地发现 CPU 侧预处理（resize、归一化、通道转换）占了将近一半的开销。这还是在模型延迟只有 8ms 的情况下。

解决办法：一是用 AIPP，把归一化和通道转换交给硬件；二是用 DVPP 做 resize 和图像裁剪。DVPP 输出的图片有 16 字节对齐的要求，YOLO 这种 640x640 的尺寸完全没问题，如果是自定义尺寸要确保宽高是 16 的倍数，或者手动补边。

但要注意，DVPP 的 resize 用的是硬件插值，和 OpenCV 的INTER_LINEAR有细微差别，如果模型对输入分布非常敏感，检测精度可能会有轻微下降。我建议：精度差别在可接受范围内，就用 DVPP；如果不行，就保留 OpenCV 的 resize，只把归一化和通道转换交给 AIPP。

6.4 后处理 NMS 的优化空间

YOLO 后处理里的 NMS 是纯 CPU 计算。640x640 输入、每个头候选框几千个，numpy 版本的 NMS 大约耗 2~3ms，看起来不多，但它不占 NPU 算力。如果你对 GPU/CPU 负载有要求，可以试试 C++ 编写 NMS 或者直接使用昇腾的算子库。

对我这个场景来说，2~3ms 在 30ms 预算里完全能接受，所以我没继续优化。但如果未来需要追求极致延迟，我会考虑把 NMS 迁移到一个单独线程，或者用 ONNX 导出时把 NMS 整合进模型。

6.5 长期运行的稳定性建议

边缘服务器的部署环境通常比较恶劣，长期跑推理任务，有几个容易被忽视的细节：

• 散热：Atlas 300V 是被动散热，机箱里必须有合理风道。我用过一台没做风道的 2U 机箱，跑半小时后npu-smi info显示温度直接逼近降频阈值，性能断崖式下降；
• 内存监控：ACL 的 Device 内存分配和释放如果不对等，泄漏会越积越多。建议写个定期调用acl.rt.get_mem_info的逻辑做监控，别看漏；
• 异常退出后的资源回收：推理进程被 kill 后，Device 内存可能没被释放，重开进程偶尔会提示内存不足。解决办法是进程启动时做一次acl.rt.reset_device，或者在异常退出后重启容器/服务器。

7. 再聊聊我实际使用中的几个体会

写到最后，说几点没法归到上面任何一类、但我觉得很重要的个人体会。

第一，Atlas 300V 24G 对 YOLO 来说其实有点“大材小用”。YOLOv5s 的模型本身占用的 Device 内存非常小，24G 的板载内存更多是为了多路视频、大 batch 或更大模型准备的。如果只跑 YOLOv5s 单路，16G 版本也完全够用。选型时先算清楚：你的模型大小 × 并发路数 × 输入尺寸，就是你需要的显存下限，不用盲目上大内存版本。

第二，网上很多教程喜欢直接跑smart_300VPro之类官方应用样例，能跑通但对理解原理帮助不大。我强烈建议至少自己写一遍acl.init -> load -> execute -> 拷贝输出这条最简链路，哪怕只跑一个 YOLOv5s 的原始输出不接 NMS。只有自己手写过一遍，你才真正知道这个卡是怎么工作的，后面遇到任何问题都有排查的底气。

第三，如果只是想把 YOLO 快速跑起来，不想折腾底层 AIPP、Dataset、Stream 这些东西，可以考虑用 MindX 的 mxVision 推理框架，它封装掉了大部分细节，配置文件和输入输出接口都比较友好。但它的封装也意味着你很难深入到算子级别去排查问题。我的建议是：先用 mxVision 跑通业务，再按需下沉到 ACL，两条腿走路。

最后分享一个小技巧：所有跑通过的 ATC 转换命令和推理脚本，一定要整理成一份带版本号的文档，连同当时用的驱动、固件、CANN 版本一起保存。昇腾的版本更新比较快，同一个命令在不同版本下表现可能不一样。我吃过“三个月后重装系统，原命令跑不通”的亏，当时没记版本，排查了一下午才发现是固件升级导致的兼容问题。这种配置管理上的“笨功夫”，在长期运维时省下来的时间远超记录的那几分钟。