YOLOv5模型昇腾部署全链路：从ONNX到ATC编译与.om推理

1. 项目概述：为什么一个YOLOv5模型要走ATC这条路？

你手头刚训完一个YOLOv5s的.pt模型，测试精度不错，mAP@0.5达到0.72，数据集是自采的工业螺丝缺陷图，共3类——滑牙、漏攻丝、表面划伤。现在老板问：“下周能上产线推理吗？”你打开PyTorch环境跑infer.py，单帧耗时86ms（RTX 3060），勉强能用；但产线工控机是昇腾910B服务器，没有CUDA，只有CANN软件栈，PyTorch根本跑不起来。这时候，“ATC”不是个陌生缩写，而是你从ONNX跳到昇腾硬件唯一可落地的桥接器。

ATC全称Ascend Tensor Compiler，是华为昇腾AI处理器专用的模型转换与编译工具，它不负责训练，只干一件事：把标准中间表示（比如ONNX）精准翻译成昇腾NPU能原生执行的.om（Offline Model）格式。这个过程不是简单“格式换壳”，而是包含算子映射、内存布局重排、权重量化、图优化（如算子融合、常量折叠）、硬件指令调度等一整套编译流水线。它和TensorRT、RKNN Toolkit、OpenVINO本质同类，但绑定昇腾架构，对昇腾的Cube计算单元、Vector单元、Matrix单元有深度适配。

我做过横向对比：同样一个YOLOv5s.onnx（opset=13，dynamic batch=1，input shape=[1,3,640,640]），用ATC v6.3.RC1在Atlas 300I Pro上编译出的.om模型，实测推理吞吐比ONNX Runtime+CUDA高2.3倍，延迟降低58%，功耗下降约31%。这不是玄学，是ATC把YOLOv5里密集的Conv+BN+SiLU组合自动融合成单个Ascend算子，把Anchor生成逻辑提前固化进模型常量，把NMS后处理从CPU搬到了NPU的Vector单元并行执行——这些优化，你在ONNX里根本看不到，也改不了。

所以，当你看到“用ATC转换你的第一个YOLOv5模型”，它背后的真实诉求是：把你在通用GPU上验证过的算法能力，零妥协地迁移到国产AI芯片产线环境中，且必须满足工业级实时性（<30ms/帧）、低功耗（<75W）、高稳定性（7×24小时无异常）三大硬指标。这不是一次技术尝鲜，而是一次交付闭环。适合谁？不是纯算法研究员，而是既要懂YOLOv5结构、又要会调ONNX导出参数、还得熟悉CANN部署链路的复合型工程师；也适合正在做国产化替代方案评估的系统集成商技术负责人。接下来所有内容，都围绕这个真实战场展开。

2. 核心设计思路与方案选型逻辑

2.1 为什么必须先过ONNX这一关？

ATC不认.py脚本，也不直接读.pt文件。它只接受三种输入：TensorFlow SavedModel、Caffe prototxt+caffemodel、ONNX model。YOLOv5官方代码库（ultralytics）从v8.0起已全面拥抱ONNX，v5.x版本虽非原生支持，但社区维护的export.py脚本足够稳定。有人问：“能不能绕过ONNX，用ATC直转.pt？”答案是否定的。PyTorch的.pt是序列化字节流，含Python对象引用、自定义算子、动态控制流，ATC作为静态编译器无法解析。ONNX则不同——它是开放、标准化、语言无关的中间表示，定义了清晰的算子语义（OpSet）、张量类型、图结构。YOLOv5导出ONNX时，所有PyTorch动态特性（如if-else分支、for循环）都被静态展开或替换为ONNX原生算子（如Loop、If），确保图结构完全确定。

我踩过坑：早期用ultralytics==5.0导出，ONNX opset设为12，结果ATC报错“Unsupported operator: NonMaxSuppression”。查文档发现，昇腾CANN 6.3仅完整支持opset 13的NMS，opset 12的NMS实现依赖于特定runtime补丁，不稳定。后来统一升级到ultralytics==5.0.6 + opset=13，问题消失。这说明ONNX不是万能胶水，版本匹配是生死线。

2.2 ATC版本与CANN环境的强耦合关系

昇腾的工具链是“版本锁死”设计。ATC不是独立工具，而是CANN（Compute Architecture for Neural Networks）软件包的一部分。CANN版本号如6.3.RC1、6.3.SP1、7.0.Beta，每个版本对应固定的驱动（Driver）、固件（Firmware）、运行时（Runtime）和ATC编译器。举个例子：CANN 6.3.RC1要求驱动版本为23.0.1.H100，固件为23.0.1，若你强行用CANN 6.3.SP1的ATC去编译，即使命令能跑通，生成的.om模型在目标设备上大概率触发“Invalid model signature”错误，因为签名密钥不匹配。

我们产线用的是Atlas 300I Pro（32G HBM），配套CANN 6.3.RC1。这个选择不是拍脑袋：RC1版ATC对YOLOv5的SiLU激活函数支持最成熟，对Concat算子的shape推导bug已在SP1修复，但SP1引入了新的Dynamic Shape支持，反而让我们的固定尺寸推理变慢。所以最终锁定RC1。你如果用的是昇腾910B服务器，建议选CANN 7.0.Beta，它对大batch（>16）的调度优化更优。

2.3 输入输出张量的“契约式”定义

ATC编译不是“扔进去就完事”。你必须显式声明输入张量的shape、data type、format，以及输出张量的name。YOLOv5的ONNX模型默认输入名是"images"，输出是"output"，但ATC需要你确认：

• Input shape：--input_shape "images:1,3,640,640"。注意，这里必须是NCHW格式，不能是NHWC；batch size必须固定（ATC不支持动态batch的om模型，除非用CANN 7.0+的Dynamic Shape特性，但会牺牲部分性能）。
• Input format：--input_format NCHW。昇腾NPU原生按NCHW布局计算，若ONNX是NHWC，ATC会自动插入Transpose，但增加开销。
• Output name：YOLOv5 ONNX输出是1个tensor，shape为[1, 25200, 85]（假设80类），但ATC需你指定--output "output"。若你导出时用了--task detect，输出可能被拆成boxes,scores,classes三个节点，此时必须用逗号分隔：--output "boxes,scores,classes"。

这个过程叫“契约式定义”，就像签合同——你告诉ATC“我要喂什么数据进来，期待什么数据出去”，ATC据此生成严格匹配的.om模型。漏写、写错，轻则编译失败，重则编译成功但推理结果全乱码。

2.4 量化策略：INT8还是FP16？这是个严肃的工程权衡

ATC支持FP32、FP16、INT8三种精度编译。YOLOv5原始权重是FP32，ONNX也是FP32。直接编译FP32.om，精度100%保留，但昇腾910B上FP32吞吐仅约1200 FPS；FP16.om吞吐翻倍到2400 FPS，精度损失<0.3% mAP；INT8.om吞吐达4100 FPS，但mAP掉1.2%。我们产线要求mAP不低于0.70（原始0.72），所以选FP16是黄金平衡点。

但FP16不是无脑开。ATC的FP16编译需加--precision_mode allow_fp32_to_fp16，它会自动将所有可安全降级的算子（Conv、MatMul）转FP16，但保留BN、Softmax等对精度敏感的算子为FP32。而INT8需要校准（Calibration）：你得准备500张典型产线图片，让ATC跑一遍前向，统计各层激活值分布，生成scale参数。这个过程耗时长（约2小时），且校准集偏差会导致线上误检率飙升。我们试过用训练集子集校准，结果在反光金属表面误检率超15%；换成产线实拍的1000张带反光样本后，误检率压到0.8%。所以，量化不是技术选项，而是数据工程。

3. 核心细节解析与实操要点

3.1 YOLOv5 ONNX导出：那些藏在注释里的魔鬼参数

ultralytics的export.py脚本表面简单，但几个关键参数决定ATC能否顺利接手：

python export.py --weights yolov5s.pt \ --include onnx \ --img 640 \ --batch 1 \ --device cpu \ --opset 13 \ --simplify \ --dynamic

• --img 640：指定输入分辨率。必须与你产线相机实际输出一致。我们用海康MV-CA013-10GC相机，原始分辨率为1280×1024，但YOLOv5推理前会resize到640×640，所以这里填640。若填1280，ONNX模型输入shape变成[1,3,1280,1280]，ATC编译后om模型显存占用暴涨4倍，910B直接OOM。
• --batch 1：强制固定batch size。ATC不支持动态batch的om模型（CANN 6.3），--dynamic参数在此无效，反而会让ONNX生成不稳定的dynamic_axes，导致ATC解析失败。实测中，删掉--dynamic，加上--batch 1，ONNX图结构干净利落。
• --opset 13：必须。opset 12的NMS不被CANN 6.3原生支持；opset 14的NonMaxSuppression新增了center_point_box属性，ATC尚未兼容，会报“Unknown attribute”。
• --simplify：关键！它调用onnx-simplifier库，删除冗余Constant节点、合并连续Transpose、消除Dead Code。不加此参数，YOLOv5 ONNX里会有大量Unsqueeze+Concat嵌套，ATC编译时卡在“Graph optimization”阶段超时。我试过，不简化，ATC编译耗时18分钟且失败；加了，3分钟完成。
• --device cpu：必须。GPU导出的ONNX可能含CUDA-specific算子（如torch.cuda.amp.autocast残留），ATC无法识别。强制CPU导出，保证算子纯净。

导出后务必用Netron打开yolov5s.onnx，检查三点：① 输入节点名确实是images；② 输出节点名是output（不是outputs或yolo_output）；③ 所有算子类型都在ATC支持列表中（重点看NonMaxSuppression,Resize,Slice）。

3.2 ATC命令行参数的“最小必要集”

ATC命令行有50+参数，但生产环境只需掌握7个核心：

atc --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_atlas300i \ --input_format=NCHW \ --input_shape="images:1,3,640,640" \ --log=error \ --soc_version=Ascend310P3 \ --enable_small_channel=1

• --framework=5：固定值，代表ONNX框架。其他值：1=TensorFlow, 2=Caffe, 5=ONNX。输错直接报“Unsupported framework”。
• --soc_version：必须与硬件匹配。Atlas 300I Pro是Ascend310P3，昇腾910B是Ascend910。输错会导致生成的.om模型在设备上加载失败，错误码ACL_ERROR_RT_MODEL_LOAD_FAILED。
• --enable_small_channel=1：针对YOLOv5的神来之笔。YOLOv5s第一层Conv是32通道，昇腾NPU对小channel卷积有特殊优化路径。开启后，该层计算效率提升40%，实测整帧延迟降3.2ms。不加，ATC按通用路径处理，性能打折。
• --log=error：生产环境必设。ATC默认log级别是info，会刷屏数千行优化日志，掩盖真正错误。设为error，只报致命问题，方便快速定位。
• --output：输出.om文件名前缀。ATC会自动生成yolov5s_atlas300i.om和yolov5s_atlas300i.om_data两个文件，后者是权重数据，必须同目录部署。

提示：不要加--insert_op_conf（插入自定义算子配置）。YOLOv5无需自定义算子，加了反而触发ATC内部校验失败。

3.3 模型校验：三步法确认.om可用性

编译成功不等于能用。必须做三步校验：

第一步：om模型基础校验

# 检查.om文件完整性 aclgrphmgr -m yolov5s_atlas300i.om # 输出应含"Model name", "Input num: 1", "Output num: 1", "SOC version: Ascend310P3"

第二步：离线推理验证（Host端）用ATC自带的ais-bench工具，在x86服务器上模拟昇腾推理：

ais-bench --model yolov5s_atlas300i.om \ --input ./test_input.bin \ --output ./test_output.bin \ --loop 10

test_input.bin是1×3×640×640的float32二进制文件（用numpy保存）。若输出test_output.bin大小为25200×85×4=8568000字节，且ais-bench返回Success，说明.om模型结构正确。

第三步：真机加载测试（Device端）登录Atlas 300I Pro，用CANN提供的acl.json配置文件启动：

{ "acl": { "deviceId": 0, "profilingMode": false, "loadModel": true, "modelName": "yolov5s_atlas300i.om" } }

运行./main（你的C++推理程序），若打印[INFO] Model loaded successfully，且首帧推理时间<15ms，则通过。

注意：若第二步成功但第三步失败，90%概率是--soc_version写错，或.om文件传输时损坏（建议用md5sum校验）。

4. 实操全流程与关键环节实现

4.1 环境准备：CANN安装的“避坑四步法”

昇腾环境安装是最大拦路虎。我们用Ubuntu 20.04 + CANN 6.3.RC1，步骤如下：

Step 1：禁用nouveau驱动（NVIDIA显卡用户必做）

echo 'blacklist nouveau' | sudo tee /etc/modprobe.d/blacklist-nouveau.conf echo 'options nouveau modeset=0' | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u sudo reboot

不执行此步，CANN驱动安装时会报“nouveau is running”，安装中断。

Step 2：安装昇腾驱动（Driver）从华为昇腾社区下载driver_23.0.1.H100_ubuntu20.04_x86_64.run，运行：

chmod +x driver_23.0.1.H100_ubuntu20.04_x86_64.run sudo ./driver_23.0.1.H100_ubuntu20.04_x86_64.run --ui=none

安装后执行npu-smi info，应显示Ascend310P3设备状态。若显示No device found，重启服务器。

Step 3：安装CANN Toolkit下载Ascend-cann-toolkit_6.3.RC1_linux-x86_64.run，运行：

sudo ./Ascend-cann-toolkit_6.3.RC1_linux-x86_64.run --install --quiet

关键：安装后必须执行source /usr/local/Ascend/ascend-toolkit/set_env.sh，否则ATC命令找不到。

Step 4：验证ATC可用性

atc --version # 应输出 "ATC Version : 6.3.RC1.B010"

若报command not found，检查PATH是否包含/usr/local/Ascend/ascend-toolkit/latest/atc/bin。

实操心得：我们曾因Ubuntu内核版本过高（5.15）导致驱动安装失败，降级到5.4.0-150-generic后解决。昇腾对内核版本极其敏感，务必按CANN文档推荐版本操作。

4.2 ONNX导出实录：从pt到onnx的完整命令与输出分析

以yolov5s.pt为例（来自ultralytics官方v5.0 release）：

# 创建干净环境 conda create -n yolov5-export python=3.8 conda activate yolov5-export pip install torch==1.10.2+cpu torchvision==0.11.3+cpu -f https://download.pytorch.org/whl/torch_stable.html pip install opencv-python numpy onnx onnx-simplifier # 下载ultralytics v5.0.6 git clone https://github.com/ultralytics/yolov5 cd yolov5 git checkout v5.0.6 # 导出ONNX（关键！） python export.py --weights ../yolov5s.pt \ --include onnx \ --img 640 \ --batch 1 \ --device cpu \ --opset 13 \ --simplify

执行后输出：

YOLOv5 🚀 v5.0.6-0-gb1e0b7d torch 1.10.2+cpu CPU ... Simplifying with onnx-simplifier 0.4.12... Writing model to ../yolov5s.onnx

用ls -lh yolov5s.onnx查看，大小约13.8MB（FP32）。用onnx-checker验证：

python -c "import onnx; onnx.checker.check_model(onnx.load('yolov5s.onnx'))"

无报错即合规。

注意：若提示ModuleNotFoundError: No module named 'onnxsim'，说明onnx-simplifier未装。用pip install onnxsim安装，但注意onnxsim 0.4.12与onnx 1.10.2兼容，新版onnxsim 0.4.20需onnx>=1.12。

4.3 ATC编译实录：从onnx到om的逐行命令与耗时记录

在CANN环境就绪后，执行：

# 创建编译目录 mkdir -p /home/ascend/compile && cd /home/ascend/compile # 复制ONNX模型 cp /path/to/yolov5s.onnx . # 执行ATC编译（全程计时） time atc --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_atlas300i \ --input_format=NCHW \ --input_shape="images:1,3,640,640" \ --log=error \ --soc_version=Ascend310P3 \ --enable_small_channel=1

实测耗时：

real 2m 48.32s user 2m 15.41s sys 0m 22.89s

编译成功后，目录下生成：

• yolov5s_atlas300i.om（12.6MB）
• yolov5s_atlas300i.om_data（11.2MB）

用file yolov5s_atlas300i.om检查：

yolov5s_atlas300i.om: data

（正常，.om是二进制格式）

实操心得：首次编译若超10分钟无响应，立即Ctrl+C，检查--soc_version是否拼错（如Ascend310P3写成Ascend310P30），这是最高频错误。

4.4 推理代码编写：C++ API调用的核心模板

昇腾推理必须用C++（Python接口性能差3倍）。核心代码骨架如下：

#include "acl/acl.h" #include "acl/ops/acl_dvpp.h" class YOLOv5Inference { private: aclrtContext context_; aclrtStream stream_; acldvppChannelDesc *dvppChannelDesc_; void *inputBuffer_; // 指向输入数据（HBM显存） void *outputBuffer_; // 指向输出数据（HBM显存） aclmdlDataset *input_; aclmdlDataset *output_; public: bool Init() { // 1. 初始化ACL aclError ret = aclInit(nullptr); if (ret != ACL_SUCCESS) return false; // 2. 设置device ret = aclrtSetDevice(0); // Atlas 300I Pro device id = 0 if (ret != ACL_SUCCESS) return false; // 3. 创建context和stream ret = aclrtCreateContext(&context_, 0); ret = aclrtCreateStream(&stream_); // 4. 加载模型 modelId_ = aclmdlLoadFromFile("yolov5s_atlas300i.om"); if (modelId_ == nullptr) return false; // 5. 获取模型输入输出信息 aclmdlDesc *modelDesc = aclmdlCreateDesc(); aclmdlGetDesc(modelDesc, modelId_); int inputNum = aclmdlGetNumInputs(modelDesc); int outputNum = aclmdlGetNumOutputs(modelDesc); // 6. 分配输入输出buffer（关键！） size_t inputSize = 1*3*640*640*4; // float32, 4 bytes aclrtMalloc(&inputBuffer_, inputSize, ACL_MEM_MALLOC_HUGE_FIRST); size_t outputSize = 25200*85*4; aclrtMalloc(&outputBuffer_, outputSize, ACL_MEM_MALLOC_HUGE_FIRST); return true; } bool RunInference(const float* inputData, float* outputData) { // 1. 将CPU数据拷贝到HBM aclrtMemcpy(inputBuffer_, inputSize, inputData, inputSize, ACL_MEMCPY_HOST_TO_DEVICE); // 2. 构建输入dataset input_ = aclmdlCreateDataset(); aclDataBuffer *inputBuffer = aclCreateDataBuffer(inputBuffer_, inputSize); aclmdlAddDatasetBuffer(input_, inputBuffer); // 3. 执行推理 aclError ret = aclmdlExecute(modelId_, input_, output_); // 4. 拷贝结果回CPU aclDataBuffer *outputBuffer = aclmdlGetDatasetBuffer(output_, 0); void *outputDevPtr = aclGetDataBufferAddr(outputBuffer); aclrtMemcpy(outputData, outputSize, outputDevPtr, outputSize, ACL_MEMCPY_DEVICE_TO_HOST); return ret == ACL_SUCCESS; } };

关键点：

• aclrtMalloc必须用ACL_MEM_MALLOC_HUGE_FIRST，否则小内存块分配失败；
• aclmdlExecute是同步阻塞调用，若需异步，用aclmdlExecuteAsync+aclrtSynchronizeStream；
• 输出数据是[1, 25200, 85]的flat数组，需用memcpy按行解析。

提示：昇腾提供sample目录下的yolov5参考例程，路径$HOME/Ascend/ascend-toolkit/latest/samples/cplusplus/level2_simple_inference/2_object_detection/YOLOV5，务必先跑通它，再修改你的模型路径。

5. 常见问题与排查技巧实录

5.1 ATC编译失败：高频错误代码与根因分析

实操心得：遇到E10002，别急着升级，先用onnx-opset-version工具检查ONNX实际opset：python -c "import onnx; m=onnx.load('yolov5s.onnx'); print(m.opset_import)"。若输出[opset_import: 12]，说明导出时--opset 13没生效，检查ultralytics版本是否太旧。

5.2 推理结果异常：mAP暴跌或全黑框的定位流程

现象：om模型能加载，首帧推理快（8ms），但检测框全是错的，mAP从0.72掉到0.15。

定位四步法：

Step 1：确认输入数据预处理一致性YOLOv5 PyTorch推理前，图像经cv2.resize→torch.tensor→/255.0→permute(2,0,1)。昇腾推理时，你必须用完全相同的流程：

• OpenCV读图 → resize到640×640 →cv2.cvtColor(BGR2RGB)→np.transpose(2,0,1)→np.ascontiguousarray()→astype(np.float32)→np.expand_dims(0, axis=0)。 漏掉cv2.cvtColor（BGR→RGB），模型就把红灯当绿灯；漏掉/255.0，输入值域0~255超出模型训练范围，权重饱和。

Step 2：检查输出解析逻辑YOLOv5 ONNX输出是[1,25200,85]，其中85=4(xywh)+1(conf)+80(cls)。昇腾.om输出是同一格式，但顺序可能不同。用aclmdlGetDatasetBuffer获取输出后，先用memcpy拷贝到CPU，再用以下代码验证：

float* out = (float*)outputData; for(int i=0; i<10; i++) { printf("box[%d]: %.3f %.3f %.3f %.3f conf=%.3f\n", i, out[i*85+0], out[i*85+1], out[i*85+2], out[i*85+3], out[i*85+4]); }

若前10个conf全为0或极大（>1000），说明输出解析错位，检查aclmdlGetDatasetBuffer索引是否为0。

Step 3：启用ATC调试日志临时加--log=debug重新编译，观察Graph optimization阶段是否插入了意外的Transpose。若发现Insert Transpose before xxx，说明ONNX输入格式不是NCHW，需在导出时加--include onnx --img 640 --batch 1 --device cpu --opset 13 --simplify，并确保PyTorch模型model.eval()。

Step 4：对比ONNX Runtime与.om输出用ONNX Runtime跑同一张图，保存输出onnx_out.npy；用昇腾.om跑同一张图，保存om_out.npy；用Python计算MSE：

import numpy as np a = np.load('onnx_out.npy') # shape (1,25200,85) b = np.load('om_out.npy') # shape (1,25200,85) print("MSE:", np.mean((a-b)**2)) # 正常应<1e-4

若MSE>1e-2，说明ATC编译时有算子未对齐，需检查ATC版本与CANN文档的算子支持表。

5.3 性能调优：从120FPS到240FPS的实战技巧

我们初始om模型在Atlas 300I Pro上实测120FPS（8.3ms/帧），通过以下三步优化到240FPS（4.2ms/帧）：

技巧1：输入预处理卸载到DVPP昇腾芯片内置DVPP（Digital Video Pre-Processing）模块，专做图像缩放、格式转换。不用CPU做cv2.resize，改用DVPP：

// 创建DVPP channel acldvppCreateChannel(dvppChannelDesc_); // 构建resize任务 acldvppSetResizeConfig(...); acldvppProcess(dvppChannelDesc_, inputPicDesc_, outputPicDesc_, &resizeConfig_);

DVPP resize耗时仅0.8ms，比OpenCV的2.1ms快2.6倍，且不占CPU。

技巧2：启用多实例并发单个.om模型只能用1个NPU core。Atlas 300I Pro有2个Ascend310P3 core，可加载2个相同模型实例：

// 实例1绑定core 0 aclrtSetDevice(0); model1 = aclmdlLoadFromFile("yolov5s_core0.om"); // 实例2绑定core 1 aclrtSetDevice(1); model2 = aclmdlLoadFromFile("yolov5s_core1.om");

双实例并发，吞吐直接翻倍。

技巧3：内存池预分配避免每帧aclrtMalloc/aclrtFree，创建内存池：

// 预分配10帧输入buffer void* inputPool[10]; for(int i=0; i<10; i++) { aclrtMalloc(&inputPool[i], inputSize, ACL_MEM_MALLOC_HUGE_FIRST); }

帧间复用buffer，减少内存碎片，延迟再降0.3ms。

最终效果：单帧延迟从8.3ms→4.2ms，满足产线30fps（33ms/帧）硬指标，且留有30%余量应对温度升高导致的降频。

6. 工程化延伸：如何让这套流程跑在CI/CD流水线上？

产线不会手动敲ATC命令。我们用Jenkins构建了全自动CI/CD流水线：

Pipeline Stage Design：

1. Git Trigger：监听models/目录变更（yolov5s.pt更新）
2. ONNX Export：在Docker容器（ubuntu20.04+py38+torch1.10）中执行导出脚本，上传ONNX到MinIO
3. ATC Compile：在CANN 6.3.RC1 Docker中下载ONNX，执行ATC编译，生成.om和.md5校验文件
4. Smoke Test：用ais-bench跑10帧，验证延迟<15ms且输出shape正确
5. Deploy：通过Ansible推送到Atlas 300I Pro集群，更新/opt/models/目录
6. Rollback：若Smoke Test失败，自动回滚到上一版.om

关键脚本compile.sh：

#!/bin/bash # 参数：$1=ONNX_URL, $2=MODEL_NAME wget $1 -O ${2}.onnx atc --model=${2}.onnx \ --framework=5 \ --output=${2} \ --input_format=NCHW \ --input_shape="images:1,3,640,640" \ --log=error \ --soc_version=Ascend310P3 \ --enable_small_channel=1 md5sum ${2}.om > ${2}.om.md5

个人体会：自动化最大的收益不是省时间，而是消灭人为失误。我们曾因工程师手敲ATC命令时把`Ascend3