问题描述

使用华为昇腾310进行YOLOv5模型推理过程中，我遇到了两个关键技术问题。首先，在尝试使用GRAPH相关接口（如rungraph、addgraph）时出现兼容性问题。其次，经过模型转换后，虽然模型大小显著减小，但推理精度明显下降，且推理时间几乎没有改善。

详细问题描述

环境信息

• 硬件设备：昇腾310 AI处理器

• 软件环境：

  • CANN版本：5.0.2商用版

  • AMCT版本：0.5.0

  • 模型框架：YOLOv5（从PyTorch转为ONNX）

  • 操作系统：Ubuntu 18.04

具体问题现象

1. GRAPH接口兼容性问题

在昇腾310上调用GRAPH相关接口时，程序返回错误提示，似乎该设备不支持这些接口。尝试使用rungraph和addgraph时均出现以下错误类型信息：

[ERROR] GRAPH API call failed on Ascend 310

2. 模型量化后性能问题

使用AMCT工具对YOLOv5.onnx模型进行量化后，遇到以下问题：

• 模型大小变化：原始ONNX模型大小为135M，量化后降至34.9M，OM模型为38.1M

• 推理时间：量化前后推理时间分别为89ms和92ms，改善不明显

• 精度下降：量化后模型在测试集上mAP下降约15%，严重影响使用效果

操作步骤详述

1. 模型准备：将训练好的YOLOv5 PyTorch模型转为ONNX格式（opset 11）

2. 模型量化：使用AMCT进行量化校准

3. amct_onnx calibration --model ./RGB_v11.onnx --save_path ./RGB_v11 --input_shape "images:1,3,768,1344" --data_dir "./data" --data_types "float32"

4. 模型转换：使用ATC工具将量化后的ONNX转为OM格式

5. 推理测试：在昇腾310上运行推理并评估性能

问题解答

下表总结了您遇到的两个核心问题的关键点和初步方向，方便您快速把握重点。

问题点	关键现象	可能原因/解决方案方向
GRAPH接口兼容性​	在310上调用rungraph, addgraph等接口失败。	接口可能不直接适用于310的推理场景。解决方案是转向使用MindSpore Lite的C++ API或AscendCL接口。
量化后精度下降​	模型大小减小明显（135M→38.1M），但mAP下降约15%，推理时间未显著改善。	量化过程过于激进或校准不充分；YOLOv5的某些敏感层（如检测头）对量化耐受性差。解决方案是采用混合精度量化、使用更具代表性的校准集、并进行后训练量化（PTQ）优化。

🚧 GRAPH接口问题：理解与替代方案

您遇到的GRAPH接口（如rungraph）调用失败，很可能是因为这些接口属于昇腾AI软件栈中的Ascend Graph API或Matrix框架，它们的主要应用场景是训练构图或复杂的流式应用编排，而不是您当前进行的简单模型推理。

对于昇腾310上标准的模型推理，正确的路径是使用 AscendCL（Ascend Computing Language）​ 或 MindSpore Lite​ 的推理接口。

1. 确认接口适用范围：Ascend Graph API常用于在昇腾平台上直接构建和运行计算图，这可能更适用于训练或特定的高性能计算场景，而非您当前遇到的推理任务。

2. 转向标准的推理接口：对于离线模型（.om文件）的推理，核心是使用AscendCL接口。基本流程如下：

   • 初始化：调用 aclInit初始化AscendCL资源。

   • 加载模型：使用 aclmdlLoadFromFile或类似接口加载转换好的OM模型。

   • 准备输入输出：为模型准备输入和输出内存。

   • 执行推理：使用 aclmdlExecute执行模型推理。

   • 释放资源：推理完成后，卸载模型并调用 aclFinalize进行清理。

3. 考虑使用MindSpore Lite（推荐）：从MindSpore 2.0版本开始，官方推荐使用MindSpore Lite作为Ascend 310推理的统一入口，主发布包中的相关接口已不再维护。迁移到MindSpore Lite通常只需少量修改：

   • 上下文（Context）配置：将 Ascend310DeviceInfo替换为 AscendDeviceInfo。

   • 模型构建：简化模型加载流程，直接从文件构建。

// 以MindSpore Lite为例的简化代码示意
#include "include/api/model.h"
auto context = std::make_shared<mindspore::Context>();
auto ascend_info = std::make_shared<mindspore::AscendDeviceInfo>();
ascend_info->SetDeviceID(0);
context->MutableDeviceInfo().push_back(ascend_info);
mindspore::Model model;
// 直接构建模型，无需先序列化加载Graph
model.Build("your_model.om", mindspore::kMindIR, context);

📉 量化精度下降问题：分析与优化策略

模型量化后精度大幅下降是常见挑战，尤其对于YOLOv5这类复杂的检测模型。

1. 检查量化校准集

   • 问题：用于量化的校准集（data_dir中的图片）是否具有代表性？如果校准集图像与真实应用场景差异较大，或数量不足，会导致缩放因子（scale）计算不准。

   • 行动点：确保校准集来自训练集的分布，且覆盖不同场景、目标尺度、光照条件。尝试将校准集数量增加到1000张以上。

2. 采用混合精度量化

   • 问题：对YOLOv5所有层进行均匀的INT8量化可能会损害敏感层（如回归预测框坐标的最终卷积层）的精度。

   • 行动点：使用AMCT工具的混合精度量化功能。一个常见的策略是将网络 backbone 部分量化到INT8，而将检测头（Head）部分保持FP16或FP32精度。这能在精度和性能间取得更好平衡。

3. 尝试分层量化参数调优

   • 问题：量化算法（如KL散度、最大最小值法）的选择和参数设置直接影响效果。

   • 行动点：在AMCT中，可以尝试不同的量化算法。例如，对于权重分布不均匀的层，KL散度算法可能比最大最小值法更鲁棒。同时，检查是否有针对YOLOv5的官方量化配置文件或社区最佳实践可供参考。

4. 验证原始ONNX模型的转换效果

   • 行动点：在量化之前，先将原始FP32的ONNX模型通过ATC工具转换为OM模型，并在310上运行，评估其精度和速度。这一步至关重要，它能帮助您确定问题究竟是出在量化步骤，还是模型转换本身（例如，ATC转换过程中某些算子不支持或属性解析有误）。

💡 推理性能优化建议

推理时间改善不明显，可能与模型结构、310的AI Core利用率或内存拷贝开销有关。

• 启用AIPP（AI Pre-Processing）：在ATC模型转换时，通过AIPP配置文件将图像归一化、减均值、乘系数等预处理操作放在AI Core上执行，能显著减少Host到Device的数据传输和CPU预处理时间。

• 优化模型结构：确认YOLOv5模型中是否包含大量在310上性能不佳的算子（例如，某些特定形态的卷积或自定义算子）。可尝试使用不同版本的YOLOv5（如更轻量的v5s）或华为昇腾社区提供的优化模型。

• Profiling分析：使用Ascend平台提供的Profiling工具（如msprof）对推理过程进行性能分析，定位是哪些算子耗时最长，从而进行针对性优化。

🧩 系统性的排查与优化路线图

为了帮助您有条不紊地解决问题，建议遵循以下步骤：

1. 第一步：打通基线

   • 暂时搁置量化。将原始FP32的ONNX模型转换为OM模型，在310上运行。

   • 目标：确认非量化的模型在310上能否达到与原始环境相近的精度。如果精度仍然下降，问题核心在模型转换环节；如果精度正常，问题核心在量化环节。

2. 第二步：解决GRAPH接口问题（改用MindSpore Lite或纯AscendCL）

   • 按照前述建议，将您的推理代码迁移到MindSpore Lite的C++ API或标准的AscendCL接口上。

3. 第三步：精细化量化（如果第一步确认量化是主因）