企业官网建设流程全解析

先说结论：Atlas 300V 24G 确实是一块运算加速卡，而且是一块非常典型的 AI 推理加速卡。很多人第一次拿到这块卡，看到型号里有“V”，又是 24G 显存，容易拿它和训练卡、图形卡的概念搞混。它在华为昇腾产品线里的定位很清晰：面向数据中心和边缘场景的推理卡，主打高能效比，专门干 YOLO 这类目标检测模型的部署活。

这篇文章就围绕三件事展开：Atlas 300V 24G 到底是什么卡、部署 YOLO 前需要准备什么、以及从模型转换到推理上线的完整实操链路。内容会按我自己实际踩过的坑来写，适合刚入手昇腾推理卡、准备把 YOLOV5/YOLOV8 从 GPU 迁移到 Atlas 上的人参考。

1. 先搞清楚 Atlas 300V 24G 的定位与硬件规格

在部署代码之前，先把这块卡的底细摸清楚，后面解决问题才会有明确方向。昇腾产品线里带“V”的卡和带“A”的卡功能侧重完全不同，理解这一层比记住任何参数都重要。

1.1 为什么说它是"运算加速卡"，但和训练卡是两码事

Atlas 300V 24G 的定位是推理加速卡，不是训练加速卡。这里有一个关键区别：训练卡需要支持大规模矩阵计算、梯度回传、混合精度训练，要考虑多卡通信效率；推理卡的核心任务是把已经训练好的模型“跑起来”，追求的是单次推理的低延迟、高吞吐、低功耗。

用大白话说，训练是“生产”模型的过程，推理是“使用”模型赚钱的过程。Atlas 300V 24G 负责的是后者。

热词里问“atlas 300v 24g 是运算加速卡吗”，答案是肯定的。它内部集成了昇腾 AI 处理器，具备完整的张量计算单元、矢量计算单元和标量计算单元，可以对神经网络算子做硬件级加速。只是它没在设计时过多考虑训练场景的复杂通信需求，所以算力规格上会主动做出取舍。

1.2 硬件参数逐项拆解

拿我手上的这块卡为例，核心参数如下，这些数字直接影响后续部署选型：

24G 显存是这块卡非常有竞争力的点。以前很多推理卡只有 8G 或者 16G，跑一个较大的 YOLOV8X 模型做多 batch 推理，显存经常捉襟见肘，得频繁切 batch。24G 意味着你在绝大多数目标检测场景里，都不用担心显存成为瓶颈——当然，这里指的是推理，不是微调训练。

1.3 和其他昇腾卡、GPU 卡的横向对比

很多从 NVIDIA 阵营转过来的同学，习惯性想问“它相当于什么级别的 GPU”。直接做等价替换没有意义，但可以按场景做一个参考：

• 对标 GPU 推理卡（如 T4、L4），Atlas 300V 24G 在 INT8 推理场景下能效比更好，单卡部署多路 YOLO 视频流的能力很强。
• 对标自家的 Atlas 300I Duo（昇腾 310P 另一版本），300V 24G 在显存和整体规格上更高，适合单卡多模型、大模型实例的场景。
• 和训练卡 Atlas 800T（昇腾 910B）相比，300V 24G 不支持大规模分布式训练，但推理场景下性价比更高。

结论是：如果你只在 Atlas 上做推理部署，300V 24G 是最务实的选择之一，兼顾性能、显存容量和成本。不需要为了“可能以后要训练”去买旗舰训练卡，两套平台模型转换流程可以互通，训练和推理分开用不同硬件完全成立。

2. 部署 YOLO 前的环境准备与版本规划

这块最容易翻车，因为昇腾工具链的版本依赖关系非常强。驱动、固件、CANN 工具包、PyTorch 适配版本，四个组件必须能够对应上，否则模型转换阶段就会各种报错。

2.1 宿主机与硬件安装的硬性要求

Atlas 300V 24G 是 PCIe 卡，安装起来比 Atlas 800 训练服务器简单很多。我个人推荐的宿主机最低配置是：

• CPU：Intel Xeon 或 AMD EPYC 系列，8 核以上
• 内存：16GB 以上，推荐 32GB
• 系统盘：SSD，剩余空间 50GB 以上
• 操作系统：Ubuntu 20.04 / 22.04 LTS，CentOS 7.6（但需要额外处理内核兼容性）
• 内核版本：需要满足昇腾官方兼容性列表，建议使用官方发布的自研 OS 或主流 LTS

安装物理卡时注意两点：

1. 插槽优先选择 PCIe 4.0 x16 或 x8，确保带宽不成为瓶颈。
2. 卡是风冷被动散热设计，机箱必须有足够的前后风道，否则跑满负载后芯片温度会超过 85 度，直接触发降频。我踩过这个坑，一度以为模型转换后推理性能不稳定，后来才发现是机箱散热不够，芯片撞了温度墙。

安装完成后，在系统里执行lspci | grep -i ascend或者使用npu-smi info确认板卡是否被正常识别。注意，昇腾工具的命名和 NVIDIA 的 NVSMI 很像，但命令是npu-smi，别记混了。

2.2 驱动、固件与 CANN 版本对应关系

这是整个部署过程中最需要耐心的一步。昇腾官方提供的匹配逻辑是：驱动版本 + 固件版本 + CANN 版本，三者互相咬合。

以当前比较稳定的组合为例：

安装顺序不能乱：

1. 安装 HDK（包含驱动和固件），一般通过./Ascend-hdk-*.run --full一键安装。
2. 安装 CANN 工具包，包括toolkit和nnrt。
3. 配置环境变量source /usr/local/Ascend/ascend-toolkit/set_env.sh。
4. 用npu-smi info验证驱动状态为“ok”。

版本匹配的查询方法是到昇腾社区“版本配套表”里查，不要在搜索引擎里凭感觉找。装完驱动后，执行一次npumeminfo确认显存可见，再进入下一步。如果安装后发现卡状态不对，优先排查是不是固件版本旧了，很多“驱动装好了但卡亮不了”的问题，最终都是固件没升级。

2.3 PyTorch 与 torch_npu 的适配逻辑

官方推荐的 YOLO 迁移路线是：PyTorch 模型 → ONNX / 自定义导出 → ATC 工具转换为 OM 模型。这条路线的第一步，就是宿主机上要有配套的 PyTorch 环境。

我不建议在昇腾环境里直接跑原生 PyTorch 去载入模型做推理。虽然 torch_npu 也提供了一部分算子加速，但实际部署中，模型转换到 OM 以后走 CANN 底层的 ACL 接口，性能才是最稳定的。

PyTorch 环境的主要用途有两个：

1. 用于导出 ONNX 模型，或直接用 ONNX 作为中间格式。
2. 用于在开发机上做模型精度对齐、预处理逻辑验证。

因此装 PyTorch 的标准是：能运行 YOLO 源码做前处理和后处理，能和 torch_npu 一起跑一个简单的算子对齐测试。不需要反复调训练流程，跑几个 batch 确认输出没问题就行。

3. YOLO 模型迁移到 Atlas 的核心流程

从模型仓库里的 .pt 文件，到能在 300V 上运行的 .om 离线模型，中间要走一条明确的转换链路。很多初次部署的人以为“全流程都必须在昇腾硬件上完成”，其实不是这样，模型转换可以在任何一台 x86 服务器上完成，只要装了配套的 CANN 工具包。

3.1 选择正确的模型导出路径

YOLO 系列模型（YOLOV5、YOLOV8、YOLOV9、YOLOV10）在 GitHub 上都有官方仓库，导出 ONNX 的入口通常是：

python export.py --weights yolov5s.pt --include onnx --opset 11

YOLOV8 则是：

yolo export model=yolov8n.pt format=onnx opset=12

导出的 ONNX 模型会包含完整的网络结构，包括检测头。这里要注意一个关键决策点：检测头的后处理部分（比如 YOLOV5 的 Detect 层中的 decode、NMS）放在 Onnx 里，还是不放进 Onnx 里？

我的结论是：NMS 不放进 ONNX，放到应用侧 CPU 里用 OpenCV / NumPy 实现。原因有两个：

1. NMS 算子在不同版本 ONNX 上表现不稳定，ATC 转换时算子支持度不一。
2. 推理卡的算力核心是卷积和矩阵计算，把 NMS 放在 NPU 上跑反而不划算，CPU 上的高效 NMS 实现足够快。

正确做法是导出时把检测头里的 decode + NMS 部分剔除，只保留到 bbox 回归和分类输出的部分。YOLOV5 的做法是修改export.py或在导出时设置--nms关闭，YOLOV8 的检测头导出时默认就不带 NMS，直接用输出张量即可。

3.2 ATC 模型转换：配置参数详解

拿到 ONNX 文件后，使用 ATC（Ascend Tensor Compiler）工具转换为 OM 模型。

基本命令示例：

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

几个关键参数逐一说明：

--framework=5表示输入是 ONNX 格式（5 对应 ONNX，1 对应 Caffe，2 对应 TensorFlow，3 对应 MindSpore）。

--input_shape指定模型的输入尺寸，格式是节点名:维度。这里节点名images是 ONNX 模型里实际输入节点的名称，可以通过onnx.load查看，或者用 Netron 打开模型确认。维度必须是静态的，比如1,3,640,640。

--soc_version特别关键。Atlas 300V 24G 对应的是昇腾 310P 系列，但 310P 又分了 310P1、310P2、310P3。300V 用的是 310P3（具体以npu-smi info显示的芯片型号为准）。转换时写错soc_version，跑起来会报算子不支持或运行报错。官方文档里常见的是Ascend310P3，在 CANN 8.0 里也支持写成Ascend310P系列的统一值，但为了稳妥，还是查清楚实际芯片型号再填。

3.3 AIPP 配置：让预处理下沉到 NPU

AIPP（AI Preprocessing）是昇腾的一个独特特性，它可以将图像缩放、减均值、除标准差、通道转换等预处理操作固化到模型输入之前，由 NPU 硬件完成。这样做的好处是减少 CPU 到 NPU 的数据搬移，缩短整条链路的延迟。

我的 YOLO AIPP 配置示例：

aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 crop: false mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }

这个配置对应的是把图像 uint8 类型除以 255 归一化到 [0,1]。由于 YOLO 仓库里的预处理一般只做归一化，不做 ImageNet 式的 mean/std 减除，所以 mean 全部置 0。

只做这个还不够，实际部署时图像的原始尺寸不一定正好是 640×640。YOLO 常规做法是 letterbox，保持宽高比的前提下填充到目标尺寸。这个动作我建议在 CPU 侧先用 OpenCV 完成，再把处理好的 RGB 图像传给 NPU，让 AIPP 只做归一化和通道转换。如果你把 letterbox 也丢给 AIPP 做，配置会复杂很多，实际收益也不大。

3.4 输出张量与后处理设计

OM 模型的输出通常是两个或三个特征图的拼接张量。以 YOLOV5 为例，输出 shape 为[1, 25200, 85]（主要是 80 类 COCO 的情况），其中 25200 = 3 个尺度 × （80×80 + 40×40 + 20×20），85 = 4 个 bbox 坐标 + 1 个置信度 + 80 个类别概率。

后处理流程我一般这样组织：

1. 从输出张量解析 bbox 坐标，注意输出是 cxcywh 格式（中心点 x、中心点 y、宽、高）。
2. 将 cxcywh 转为 xyxy 格式，按输入图像的缩放比例换算回原图坐标。
3. 过滤低于置信度阈值的框。
4. 执行 NMS 去掉重复框。

这个流程放在 CPU 上，用 NumPy 一次性向量化实现，25000 多个框的处理耗时通常在 1~2ms 内，完全不会成为瓶颈。我见过有人在 NPU 端实现 NMS，最后算子转换失败，花了很多时间调优收效甚微，其实没有必要。

4. 用 ACL 接口完成推理应用开发

模型转换完成之后，应用开发是整个部署链路里另一个容易迷惑的点。昇腾提供了多种推理接口，比如直接用 CANN 的 C++/Python ACL 接口、或者使用 MindSpore Lite 推理框架。对于 YOLO 系列模型的部署，我用得最顺手的是 Python ACL 接口，调试方便，性能也足够。

4.1 初始化资源与加载 OM

用 Python 调用 ACL 的基本流程：

import acl # 初始化 ret = acl.init() ret = acl.rt.set_device(0) # 创建 context context, ret = acl.rt.create_context(0) # 加载模型 model_id, ret = acl.mdl.load_from_file("yolov5s.om") # 获取模型描述信息 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_size = acl.mdl.get_output_size_by_index(model_desc, 0)

这里面acl.mdl.load_from_file之后，模型就已经被加载到 300V 24G 的显存上了。推理卡上模型占用的显存和运行时的动态内存一起，共同消耗那 24G 空间。

每次推理前需要准备输入数据。如果输出格式是 uint8 的 RGB 图，可以直接从 OpenCV 的 Mat 里取出 bytes，通过acl.util.numpy_to_ptr把 numpy 数组转成指针传给接口。

4.2 数据内存管理与设备拷贝

NPU 推理不能直接拿 CPU 内存地址传给模型，需要先把数据拷贝到设备侧。这一块新手最容易绕晕。

流程如下：

# 申请设备内存 input_data = np.zeros((1, 3, 640, 640), dtype=np.uint8) input_ptr = acl.util.numpy_to_ptr(input_data) input_mem = acl.rt.malloc(input_size, 2) # 2 为对齐单位 # 把数据从 CPU 拷贝到设备侧 ret = acl.rt.memcpy(input_mem["buffer"], input_size, input_ptr, input_size, acl.ACL_MEMCPY_HOST_TO_DEVICE) # 执行推理 output_mem = acl.rt.malloc(output_size, 2) ret = acl.mdl.execute(model_id, [input_mem["buffer"]], [input_size], [output_mem["buffer"]], [output_size])

这里acl.mdl.execute是同步执行接口，调用后会阻塞直到推理完成。如果你有多路视频流要处理，可以使用异步接口acl.mdl.execute_async，配合 stream 和回调函数实现流水线并行。

推理完成后，再从设备侧把输出拷贝回 CPU：

output_data = np.zeros(output_size, dtype=np.uint8) output_ptr = acl.util.numpy_to_ptr(output_data) ret = acl.rt.memcpy(output_ptr, output_size, output_mem["buffer"], output_size, acl.ACL_MEMCPY_DEVICE_TO_HOST)

然后把 output_data 按模型输出格式 reshape，比如[1, 25200, 85]，交给后处理。

4.3 多路视频流的部署范式

用 300V 24G 部署 YOLO 做视频流分析，一个比较经典的架构是生产者-消费者模式：

• 多个视频解码线程（生产者）分别从 RTSP 流拉帧。
• 帧数据放队列。
• 一组推理线程（消费者）从队列取帧，做 letterbox 预处理，传给 NPU 推理。
• 推理结果统一交给后处理线程做数据关联和 NMS。
• 最终输出结构化结果。

由于 Atlas 300V 24G 显存有 24G，单卡可以加载多个模型实例，或者一个模型配较大的 batch，以便在单次推理中同时处理多路输入。一个实测参考：YOLOV5s INT8 模型，batch=8，处理 1080P 视频流解码头，大约可以跑 8~12 路实时分析，具体帧率取决于视频流本身的编码码率和解码资源。

4.4 自己写封装类，别直接裸调 ACL

我吃过亏，在一开始图省事，所有 ACL 调用直接写在业务代码里。后来发现设备初始化、context 管理、显存分配这些逻辑与业务耦合在一起，调试时根本分不清是业务问题还是资源管理问题。

后来整理成独立的推理封装类，包含以下接口：

• init(model_path)：负责初始化设备、加载模型、准备输入输出内存。
• infer(preprocessed_np_array)：负责拷贝数据到设备、执行同步推理、拷回结果。
• release()：负责释放显存、卸载模型、清理 context。

这样换模型、换输入格式时，只需要改封装类的内部实现，业务侧代码完全不用动。也方便在多个脚本里复用同一套推理逻辑。

5. 性能优化与实测调参思路

模型能跑通只是第一步，能不能发挥出 300V 24G 的性能是另一回事。这块卡的算力底子不差，但很多人在默认配置下跑，出来性能远低于预期，大概率是没用对调优手段。

5.1 静态 Shape 与动态 Shape 的选择

ATC 转换时，input_shape可以指定为静态值（如1,3,640,640），也可以指定动态维度（如-1,3,-1,-1）。

动态 Shape 的好处是同一模型可以接受不同分辨率的输入，但坏处是性能会有明显下降，因为 NPU 在做算子融合和内存规划时，必须考虑所有可能的形状，无法做到最优。

我的建议：生产环境一定用静态 Shape。把输入分辨率固定为 640×640，或者根据你的业务场景固定为 1280×1280，不要为了“灵活”牺牲性能。不同分辨率的需求，通过训练几个不同输入尺寸的模型、加载多个模型实例来解决，不要用动态 Shape 一个模型通吃。

5.2 显存带宽感知与 batch 策略

24G 显存是很大的优势，但 LPDDR4X 的带宽和 HBM 相比差距明显。这意味着“暴力加大 batch”不一定能线性提升吞吐。

一个可复现的调优流程：

1. 先用 batch=1 跑单帧延迟，记为 L1。
2. 逐步增加 batch=4、8、16，观察总耗时。
3. 计算有效吞吐 = batch / 总耗时。
4. 找到吞吐不再显著增长的 batch 值，作为生产配置。

从经验看，YOLOV5s FP16 模型在 batch=8 左右吞吐增长就开始放缓，继续增加 batch 只会增加显存占用和延迟，并不会带来线性的吞吐收益。YOLOV8m 这种稍大的模型，batch=4 就已经是甜点值。

5.3 数据预处理与传输的整体流水线

推理延迟不只是 NPU 计算时间，还包括：

• CPU 预处理（letterbox、归一化）
• 内存拷贝（Host→Device）
• NPU 推理
• 结果拷贝（Device→Host）
• 后处理 + NMS

其中 Host→Device 的拷贝如果做得不好，会掩盖 NPU 本身的高性能。我建议：

• 提前分配好设备侧内存，不要每次推理都malloc和free，复用同一块 buffer。
• 用acl.mdl.execute_async搭配多个 stream 和输入队列，让预处理和推理重叠执行。
• 如果预处理已经用 AIPP 在 NPU 内做了归一化，那么 Host→Device 只需要拷贝原始图像数据，减少 CPU 的归一化耗时。

实测中，同样的 YOLOV5s FP16 模型，优化前单帧延迟 18ms，优化后 7~8ms。瓶颈往往不是 NPU，而是数据搬运。

5.4 INT8 量化与精度监控

300V 24G 的 INT8 算力比 FP16 高一倍左右，实际部署时如果想压榨更多性能，INT8 量化是必选项。昇腾提供两种量化路径：

1. 离线量化：用校准数据集跑一遍模型，统计激活值分布，生成量化因子（scale、offset），再通过 ATC 转成 INT8 的 OM。
2. QAT 量化：在训练阶段加入伪量化算子，训练结束后导出带量化参数的 ONNX，再转 OM。

两种路径中，离线量化更常用，成本低。实操时把验证集里几百张代表性图像作为校准数据，量化的模型 mAP 下降通常在 0.5%~2% 左右。目标检测这类任务对量化不敏感，YOLO 模型基本能压到 1% 以内的精度损失。

量化后务必要跑一遍完整测试集对比精度，不要只跑几张图目测。我之前量化后没仔细验证，匆忙上线，后来发现小目标漏检率明显上升，重新做了校准集筛选才解决。

6. 常见报错与排查手册

把实战中容易碰到的报错按优先级整理成一张速查表，方便遇到问题时直接对症下药。

6.1 ATC 转换阶段错误

遇到Unsupported op时，最好的处理方式是升级 CANN 版本，新版算子覆盖率更高。如果升级不便，就需要在导出 ONNX 时尝试把导致报错的算子简化，比如把一些自定义 op 改写成基础算子组合。

6.2 推理运行阶段错误

推理结果全为 0 这个情况最常见，多半是内存拷贝时用了同一个指针，或者 Host 侧数据已经释放而设备还没拷贝完。建议在调用acl.rt.memcpy前打印输入数据的前几个数值，确认 Host 侧数据正确，再排查拷贝方向。

6.3 性能异常排查思路

如果硬件正常但推理速度明显达不到预期，按以下顺序排查：

1. npu-smi info看当前芯片频率，确认没有降频。
2. 检查是否用了静态 Shape。动态 Shape 会造成性能下降 30% 以上。
3. 检查 Host→Device 拷贝是否频繁调用malloc。
4. 确认输入分辨率与模型输入一致，做了多余缩放也会拖慢性能。
5. 用msprof或 CANN 自带的 profiling 工具抓到算子和耗时占比，定位瓶颈。

一个容易忽视的点：CPU 也可能成为瓶颈。如果机器 CPU 核数不多，预处理和后处理的耗时可能吞掉 NPU 省下来的时间。建议多路部署场景下，把 CPU 绑定到大核，或为预处理线程设置明显的优先级。

7. 从单卡单模型到多卡多实例的扩展思路

一块 300V 24G 是起步，如果业务量上来，一台服务器可以插多块卡。昇腾的 PCIe 卡支持在同一台机器上多卡协同，但推理场景和多卡训练的用法不一样。

多卡推理有两种常见模式：

• 数据并行：每张卡加载同一个模型实例，按视频流 ID 或帧号分发请求，适合横向扩展路数。
• 模型并行：不同卡加载不同模型，比如一张卡跑检测模型、一张卡跑分类模型，适合流水线式的多级推理任务。

Atlas 300V 24G 每张卡是独立的 PCIe 设备，多卡之间没有 NVLink 那种高速互联，多卡通信走 PCIe 交换。因此，推理场景里我不建议把单个模型切到多卡上跑——通信开销会抵消算力增益。正确做法是“一卡一模型实例”，通过外部负载均衡把请求分发到不同卡。

多卡时的代码组织也简单，主要区别是初始化时指定不同设备号：

# 进程 1 acl.rt.set_device(0) # 进程 2 acl.rt.set_device(1)

建议每个设备开一个独立进程，不要在一个进程里用多个 context 管理多卡。独立进程的好处是故障隔离，一块卡上的 bug 不会拖垮整个服务。

另外，24G 显存可以同时加载多个不同模型。比如一张卡上同时加载 YOLOV5s（精度高）和 YOLOV5n（速度快）两个实例，根据业务需求动态选择调用哪个模型，这比为了切换模型频繁重新加载要可靠得多——模型加载一次需要几百毫秒，如果每来一个请求都重新加载，延迟会不可接受。

8. 关于部署工具链的额外建议

很多人在看完官方文档后，仍然会被各种概念绕晕：Ascend CLI、ATC、ACL、MindSpore Lite、CANN、torch_npu，这些到底是什么关系？

用生活化的比喻来说：

• CANN 是整个工具链的底座，相当于操作系统。
• ATC 是模型编译器，负责把 ONNX、Caffe 等模型编译成 NPU 能执行的指令，相当于“翻译官”。
• ACL 是运行时推理接口，相当于“执行者”，翻译官编译完的程序由执行者去跑。
• torch_npu 是 PyTorch 的适配层，让你在 PyTorch 代码里能够使用 NPU 资源。
• MindSpore Lite 是另一套推理框架，和 ACL 功能类似，但接口更上层，适合不想手工管理显存的人。

对于 YOLO 部署，我推荐直接走 ONNX → ATC → ACL 这条链路，理解成本最低，调试手段最直接。

也可以考虑使用一些开源项目做二次封装。目前市面上的开源 YOLO 昇腾部署项目大多是围绕 CANN 或 MindSpore Lite 做了封装，参考价值在于理解整体调用流程，不建议只靠别人的封装而不去理解底层逻辑。因为真实业务场景的预处理、后处理、数据格式都可能不同，一知半解地搬运代码，出了问题会很被动。

9. 完整部署流程速查清单

考虑到很多读者喜欢直接照着检查，我在最后给你一个从零到一的完整核对清单，每做完一项就打勾：

• [ ] 物理安装 Atlas 300V 24G，确认npu-smi info能看到设备，状态 OK。
• [ ] 安装与驱动匹配的 HDK，升级固件，确认/usr/local/Ascend路径存在。
• [ ] 安装 CANN toolkit 与 nnrt，执行source set_env.sh。
• [ ] 在 x86 开发机上安装 PyTorch，运行一次 YOLO 的 ONNX 导出命令。
• [ ] 用 Netron 检查 ONNX 输入节点名和输出 shape。
• [ ] 编写 AIPP 配置文件，确定输入归一化方式。
• [ ] 执行 ATC 转换命令，输出.om文件，确认无报错。
• [ ] 在宿主机上用 Python ACL 接口加载 OM 模型，跑一张测试图。
• [ ] 对测试图的输出做后处理，和 PyTorch 输出的 bbox 结果对比，确认坐标基本一致。
• [ ] 用acl.mdl.execute_async改造推理逻辑，配置多个 stream 或队列。
• [ ] 跑 benchmark，找到最优 batch，记录单帧延迟和吞吐。
• [ ] 如需 INT8，做离线量化，跑完整测试集评估精度损失。
• [ ] 封装推理类，接入业务代码，准备上线。

到这里，Atlas 300V 24G 这块卡怎么用、YOLO 模型怎么迁移、性能如何调优、踩坑怎么排查，整条路径就梳理清楚了。

最后再分享一个我个人的经验：昇腾平台最怕“半懂不懂”，官方文档里确实有一些信息分散在社区，但花一个下午完整读完对应版本的“模型迁移”和“应用开发”文档，比在搜索引擎里翻一百个零散帖子都有用。版本不同，接口和参数可能完全不同，一切以你实际安装的 CANN 版本文档为准。