4、模型可视化与检查：使用Netron或ONNX Runtime查看模型输入输出、算子类型、动态维度，并识别潜在的不兼容算子

当ONNX模型从PyTorch、TensorFlow等框架导出后，它只是一个包含节点序列与张量形状的静态描述文件。在进入RKNN工具链进行NPU转换之前，我们必须对模型进行一次彻底的“体检”。这一环节的核心目标有三个：确认模型的输入输出接口是否符合预期、检查算子类型是否在RKNN支持范围内、识别动态维度等可能导致转换失败或推理性能骤降的隐患。本章将围绕Netron可视化工具与ONNX Runtime（简称ORT）运行时检查两条主线，系统讲解模型检查的方法论与实战技巧。

上图展示了模型检查的整体流程：ONNX模型文件分别经过Netron的静态可视化检查与ONNX Runtime的动态执行检查，两者结果汇合后形成检查报告，最终决定是否进入RKNN转换阶段。下面我们将逐一拆解每个环节的具体操作与判断标准。

4.1 使用Netron进行静态结构可视化

4.1.1 核心原理：从计算图视角审视模型

Netron是一个开源的可视化工具，它能够将ONNX文件解析为计算图（Computational Graph），以节点（Node）表示算子，以边（Edge）表示张量流动。对于RKNN部署而言，Netron的价值在于：它让我们在转换之前就能看到模型在“数据流层面”的真实结构，而非仅仅停留在框架代码层面。通过Netron，我们可以直观地确认模型的输入张量名称、形状、数据类型，输出张量的数量与含义，以及中间层的算子序列。更重要的是，Netron会显示每个算子的属性（如卷积的stride、padding，激活函数的类型等），这些属性直接影响RKNN的算子映射策略。

在Netron的界面中，点击任意节点，右侧面板会展示该节点的详细属性，包括op_type（算子类型）、inputs（输入张量）、outputs（输出张量）以及attribute（算子属性）。对于RKNN转换，我们需要特别关注那些在NPU上无法高效执行的算子，例如动态形状相关的NonMaxSuppression、Where、Gather（当索引为动态时）等。

4.1.2 操作流程：从打开文件到生成检查清单

1. 打开模型：将导出的.onnx文件拖入Netron窗口（或通过File → Open Model）。Netron支持本地文件与远程URL，但建议使用本地文件以确保版本一致。
2. 检查输入输出：点击模型最左侧的输入节点，记录name、shape（如[1,3,640,640]）、dtype（通常为float32）。点击最右侧的输出节点，确认输出名称与维度。这一步是后续编写RKNN推理代码的基础。
3. 遍历算子序列：从输入到输出，逐层点击节点，记录算子类型。重点关注卷积（Conv）、批归一化（BatchNormalization）、激活（Relu/Sigmoid）、池化（MaxPool/AveragePool）、全连接（Gemm/MatMul）等常见算子。同时标记出特殊算子，如Resize、Transpose、Split、Concat等。
4. 检查动态维度：在Netron中，如果某个维度显示为dynamic或None，说明该维度是动态的。例如[None,3,224,224]表示batch size可变。RKNN转换时，动态维度通常需要固定为具体数值，否则会报错。
5. 导出检查清单：将上述信息整理为表格，作为后续RKNN转换的参考依据。

4.2 使用ONNX Runtime进行动态执行检查

4.2.1 核心原理：以运行结果验证模型正确性

Netron只能展示模型的静态结构，但无法验证模型在真实输入下是否能正确计算。ONNX Runtime（ORT）是微软推出的跨平台推理引擎，它可以直接加载ONNX模型并执行前向推理。在RKNN转换前，使用ORT进行动态检查有两大价值：第一，验证模型在标准ONNX环境下的输出是否正确，排除导出过程中的错误；第二，通过打印中间张量的形状与值，定位潜在的数值异常或维度不匹配问题。此外，ORT还提供了SessionOptions中的enable_profiling选项，可以输出每个算子的执行时间，帮助我们识别计算瓶颈。

对于RKNN部署，ORT检查还有一个特殊意义：它能够模拟“固定形状”推理。我们可以在ORT中强制将输入形状设置为固定值（如[1,3,640,640]），观察模型是否能够正常执行。如果ORT在固定形状下报错，那么RKNN转换时大概率也会失败。

4.2.2 操作流程：编写Python检查脚本

以下是一个典型的ORT检查脚本，它完成了输入输出打印、动态轴检测与推理验证三个任务：

import onnxruntime as ort
import numpy as np

# 1. 创建推理会话
model_path = "model.onnx"
sess = ort.InferenceSession(model_path, providers=['CPUExecutionProvider'])

# 2. 获取输入输出信息
input_info = sess.get_inputs()
output_info = sess.get_outputs()
print("=== 输入信息 ===")
for inp in input_info:
    print(f"名称: {inp.name}, 形状: {inp.shape}, 类型: {inp.type}")
print("=== 输出信息 ===")
for out in output_info:
    print(f"名称: {out.name}, 形状: {out.shape}, 类型: {out.type}")

# 3. 检测动态维度
print("\n=== 动态维度检测 ===")
for inp in input_info:
    for idx, dim in enumerate(inp.shape):
        if dim is None or dim == 'dynamic':
            print(f"警告: 输入 {inp.name} 的第 {idx} 维是动态的: {dim}")

# 4. 构造固定形状输入并推理
input_data = np.random.rand(1, 3, 640, 640).astype(np.float32)
ort_inputs = {input_info[0].name: input_data}
outputs = sess.run(None, ort_inputs)
print(f"\n=== 推理完成，输出数量: {len(outputs)} ===")
for i, out in enumerate(outputs):
    print(f"输出 {i}: 形状={out.shape}, 数值范围=[{out.min():.4f}, {out.max():.4f}]")

运行上述脚本后，我们重点关注三类信息：输入输出的形状是否与预期一致（例如检测模型应输出[1,84,8400]）、是否存在动态维度（需要固定）、输出数值是否在合理范围内（如检测框坐标应为正数，分类概率应在0~1之间）。

4.3 识别潜在的不兼容算子

4.3.1 核心原理：RKNN算子支持边界

瑞芯微NPU（如RK3588、RK3566）的RKNN工具链支持绝大多数常见CNN算子，但并非所有ONNX算子都能被高效映射。不兼容算子通常分为三类：完全不支持（转换时报错）、支持但效率低（转换成功但推理速度慢）、需要特殊配置（如某些量化敏感的算子）。常见的“问题算子”包括：NonMaxSuppression（NMS，通常建议在NPU外处理）、Gather/Scatter（当索引为动态时）、Where（条件选择）、Expand（动态扩展）、Tile（重复复制）以及各种自定义算子。

为了系统性地识别不兼容算子，我们可以编写一个脚本，遍历ONNX模型中的所有节点，并与RKNN官方支持的算子列表进行比对。虽然RKNN工具链在转换时会自动报错，但提前识别可以节省调试时间。

4.3.2 判断方法：基于算子清单的自动化扫描

以下脚本展示了如何提取模型中的所有算子类型，并输出统计信息：

import onnx

model = onnx.load("model.onnx")
op_set = set()
for node in model.graph.node:
    op_set.add(node.op_type)

print("模型包含的算子类型:")
for op in sorted(op_set):
    print(f"  - {op}")

# 手动标记已知的RKNN高风险算子
high_risk_ops = ['NonMaxSuppression', 'Gather', 'Scatter', 'Where', 'Expand', 'Tile']
print("\n=== 高风险算子检查 ===")
for node in model.graph.node:
    if node.op_type in high_risk_ops:
        print(f"发现高风险算子: {node.op_type}, 名称: {node.name}")

运行后，如果发现NonMaxSuppression，建议在导出ONNX时将其移除，改为在NPU外使用CPU或GPU处理NMS。如果发现Gather且索引是动态的，考虑将其替换为固定索引的Slice操作，或者将相关逻辑移到前处理/后处理中。

4.4 案例拆解：YOLOv5s模型检查实战

下面我们以一个典型的YOLOv5s检测模型为例，完整走一遍检查流程。该模型输入为[1,3,640,640]，输出为三个不同尺度的特征图，形状分别为[1,255,80,80]、[1,255,40,40]、[1,255,20,20]（假设80类COCO数据集）。

初始现象：在Netron中打开模型后，发现输入节点名称是images，输出节点名称是output0、output1、output2。进一步检查发现，模型中包含NonMaxSuppression算子，这会导致RKNN转换失败。

分析判断：YOLOv5的ONNX导出通常包含NMS后处理，但RKNN NPU不支持该算子。我们需要在导出时设置nms=False，或者在ONNX模型中手动删除NMS节点。此外，模型中的Resize算子使用了nearest模式，这是RKNN支持的，但需要确认其坐标变换模式是否为asymmetric（RKNN推荐）。

实际操作步骤：

1. 使用Netron确认NMS节点的输入输出连接，记录其输入张量名称（通常是三个输出特征图）。
2. 使用Python脚本加载ONNX模型，删除NMS节点及其相关子图，将三个输出特征图直接作为模型输出。
3. 使用ORT运行修改后的模型，输入随机数据，确认输出形状为[1,255,80,80]等，且数值范围正常。
4. 再次使用Netron检查，确认模型结构简洁，无NMS节点。

结果对比：修改前，RKNN转换报错Unsupported op: NonMaxSuppression；修改后，转换成功，在RK3588上推理延迟从无法运行变为约12ms（FP16）。风险与代价：移除NMS后，需要在NPU外自行实现NMS逻辑，增加了CPU负载，但整体系统吞吐量提升明显。

4.5 常见误区与总结复盘

误区一：只依赖Netron，不进行动态检查。Netron只能展示静态结构，无法发现维度推导错误或数值溢出问题。例如，某些PyTorch模型在导出时，如果使用了torch.jit.trace，可能会固化某些中间张量的形状，导致动态维度被错误地固定为trace时的值。只有通过ORT运行不同形状的输入，才能暴露这类问题。

误区二：忽略动态维度的“隐性”存在。有些模型虽然输入形状是固定的，但内部可能存在动态操作，例如torch.argmax的输出形状依赖于输入内容。这类动态行为在ONNX中通常表现为Shape或Gather算子，需要特别留意。

误区三：认为所有不兼容算子都能通过“自定义算子”解决。RKNN确实支持自定义算子，但开发成本高、调试周期长。在绝大多数情况下，通过修改模型结构（如将NMS移到外部）或调整算子实现（如用Slice替代Gather）是更优解。

总结：模型可视化与检查是RKNN部署流程中成本最低、收益最高的环节。通过Netron完成静态结构审查，通过ONNX Runtime完成动态执行验证，再结合算子兼容性清单进行系统性扫描，可以避免90%以上的转换失败问题。建议将本章的检查脚本固化到CI/CD流程中，每次模型更新后自动执行，确保进入RKNN转换的模型始终是“健康”的。