📚 课程目录第3章模型转换流程概览

模型转换流程概览：从ONNX/PyTorch/TensorFlow到RKNN的完整链路

在RKNN模型部署的工程实践中，模型转换并非一个简单的“拖拽-导出”操作，而是一条包含多个关键决策点的流水线。理解这条流水线的全貌，尤其是NPU子图分配在其中的锚定位置，是避免“转换成功但推理失败”或“精度达标但性能不达标”等典型问题的前提。本章将系统梳理从原始框架模型到RKNN模型的转换步骤，并重点剖析子图分配策略如何贯穿其中，成为决定NPU利用率与整体推理效率的核心枢纽。

3.1 转换流程的四个核心阶段与子图分配的位置锚定

完整的RKNN模型转换流程可以划分为四个逻辑阶段：模型解析与预处理、计算图优化、NPU子图划分与分配、代码生成与验证。子图分配并非一个孤立的步骤，而是深深嵌入在“图优化”与“代码生成”之间的关键决策层。它接收来自前端的优化后计算图，输出的是带有明确执行后端（NPU/CPU）标注的划分图。

  核心原理：RKNN工具链的底层逻辑是“异构计算”。NPU擅长处理卷积、矩阵乘、激活函数等密集型算子，但并非所有算子都能在NPU上高效执行（如某些动态形状操作、自定义算子）。子图分配的本质，是在保证功能正确的前提下，将计算图切分为若干子图，使得NPU执行的子图尽可能大，同时将无法映射的算子“隔离”到CPU执行，并通过张量拷贝节点衔接两个执行域。

3.1.1 阶段一：模型解析与预处理

此阶段的核心任务是格式统一与算子映射。工具链首先读取ONNX（推荐中间格式）、PyTorch导出的TorchScript或TensorFlow的GraphDef，将其转换为内部的IR（中间表示）。随后，工具链会遍历图中的每一个算子，与内置的算子映射表进行比对。映射表定义了每个框架算子对应到RKNN底层算子的规则，包括支持的属性、输入输出张量约束等。

输入格式处理：PyTorch模型需先导出为ONNX，TensorFlow模型建议使用冻结后的GraphDef或SavedModel。此步骤中，动态轴（如动态batch）会被固定或标记为动态。
算子映射失败处理：当遇到映射表中不存在的算子时，工具链不会立即报错，而是将其标记为“不支持算子”。这些算子将成为后续子图划分时的“障碍物”，强制切分。
属性校验：例如，ONNX中的Conv算子若使用了dilation=2，而NPU硬件不支持该dilation率，则此算子会被标记为“部分支持”，需要特殊处理。

3.1.2 阶段二：计算图优化

在算子映射完成后，工具链会执行一系列与硬件无关的图优化，以减小计算量并提升数值稳定性。这些优化直接影响后续子图划分的质量。

优化类型	具体操作	对子图分配的影响
常量折叠	将只依赖常量的算子（如Shape、Gather）在编译期计算完毕	减少运行时节点，避免在NPU子图中产生不必要的标量操作
算子融合	将Conv+BN+ReLU融合为单一算子	融合后的算子更易被NPU识别为高性能原语，减少子图切分点
冗余消除	删除无输出的Identity节点、重复的Transpose	简化图结构，降低子图划分的复杂度
精度校准	收集激活值范围，为量化做准备	量化参数的准确性影响NPU子图内算子的执行精度

3.1.3 阶段三：NPU子图划分与分配（核心枢纽）

这是本章节的重点。经过优化后的计算图，会进入子图划分器。划分器采用贪心聚类算法，从图的入口节点开始，尝试将尽可能多的连续算子划入同一个NPU子图。划分的约束条件包括：

算子支持性：所有算子必须在NPU算子列表中。
数据布局约束：NPU通常要求特定的张量内存布局（如NHWC或NC1HW10），若前后算子布局不一致，则需插入Layout转换节点，这会导致子图中断。
量化一致性：若子图内某个算子不支持量化，则整个子图可能被迫回退到FP16或FP32执行，从而降低性能。

划分完成后，工具链会在子图边界插入数据搬运节点（如Copy、Convert），并生成一张“执行计划表”，明确每个子图运行在NPU还是CPU上。

经验提醒：子图划分并非越大越好。如果NPU子图过大，导致CPU与NPU之间的同步开销增加，或者因NPU内存带宽不足而频繁等待，整体延迟反而可能上升。通常建议将计算密集且无数据依赖的算子放入NPU，将逻辑控制、动态Shape、稀疏操作留在CPU。

3.1.4 阶段四：代码生成与验证

子图分配完成后，工具链将生成最终的RKNN模型文件（.rknn）。该文件包含了NPU子图的二进制指令流、CPU子图的算子序列、权重数据以及子图间的调度信息。验证阶段通常包含两步：

精度比对：使用模拟器或开发板，对比RKNN模型输出与原始浮点模型输出的余弦相似度或欧氏距离。
性能剖析：通过RKNN Toolkit提供的profiling工具，查看每个子图的耗时、NPU利用率、数据搬运耗时。

3.2 实战场景：一个包含自定义算子的检测模型转换

假设我们有一个基于PyTorch训练的YOLOv5s检测模型，其中包含一个自定义的NMS后处理算子（非极大值抑制），该算子使用动态循环实现。在转换过程中，我们遇到了典型的子图分配挑战。

初始现象：模型转换成功，但在开发板上推理时，单帧延迟达到85ms，远超预期的30ms。通过profiling发现，NPU利用率仅为45%，且CPU与NPU之间的数据搬运耗时占总耗时的40%。

分析判断过程：

查看子图划分报告，发现自定义NMS算子被标记为“不支持”，导致整个后处理部分被强制分配到CPU。
更严重的是，由于NMS算子紧跟在检测头的Conv输出之后，工具链将检测头的最后几个卷积层也划入了CPU子图，以避免频繁搬运特征图。
这导致NPU只执行了骨干网络部分，而检测头（计算量占比约20%）在CPU上运行，且特征图从NPU搬运到CPU的带宽开销极大。

实际操作步骤：

# 1. 在ONNX导出时，将自定义NMS替换为普通算子（如TopK+循环），并标记为不导出
torch.onnx.export(model, dummy_input, "yolov5s.onnx",
                  opset_version=11,
                  dynamic_axes={"images": {0: "batch"}},
                  do_constant_folding=True)

# 2. 在RKNN配置中，手动指定子图切分点
rknn.config(mean_values=[[0,0,0]], std_values=[[255,255,255]],
            target_platform="rk3588",
            optimization_level=1,
            custom_op_config={"nms": {"type": "cpu"}})  # 强制NMS在CPU执行

# 3. 使用rknn.build()后，通过rknn.analysis()查看子图划分建议
rknn.analysis(proto_path="./yolov5s_analysis.json")

结果对比：通过将NMS强制隔离在CPU，并允许检测头卷积留在NPU，单帧延迟从85ms降至42ms。虽然仍高于目标，但NPU利用率提升至78%。进一步将NMS替换为RKNN内置的EfficientNMS插件后，延迟降至28ms。

风险与代价：强制指定子图切分点需要人工分析模型结构，且若切分不当，可能导致CPU与NPU频繁同步。此案例中，我们额外增加了约2小时的调优时间。

复盘经验：在模型设计阶段就应考虑NPU的算子支持范围。对于后处理算子，尽量使用工具链内置的插件或将其完全放在CPU端，避免让不支持算子“污染”主计算子图。

3.3 常见误区与总结复盘

在模型转换流程中，工程师常陷入以下误区，导致子图分配策略失效：

误区	后果	正确做法
认为“转换成功”即“优化完成”	忽略子图划分质量，性能远低于预期	必须查看子图划分报告，关注NPU子图占比
盲目追求“全NPU执行”	因个别算子不支持，导致整个子图回退到FP32，内存带宽爆炸	接受“NPU为主，CPU为辅”的异构模式
忽略数据搬运成本	子图边界过多，频繁的DMA拷贝成为瓶颈	尽量合并相邻的NPU子图，减少边界数量
在转换前不进行算子替换	将自定义算子直接放入模型，导致切分点异常	提前用等价算子组合替换自定义逻辑

风险提示：当模型包含动态Shape（如动态batch、可变分辨率输入）时，子图划分器可能无法在编译期确定张量大小，从而被迫将所有动态部分放入CPU。此时，建议固定输入分辨率，或使用RKNN的“动态形状”模式（需额外配置，且性能有损耗）。

总结：模型转换流程是一个“解析-优化-划分-生成”的闭环。子图分配处于优化与生成之间，是决定模型能否在NPU上高效运行的“交通警察”。工程师必须理解，子图分配的目标不是“全盘NPU化”，而是在算子支持、数据布局、量化约束和搬运成本之间取得最优平衡。掌握这一环节，意味着你不再仅仅是一个“模型搬运工”，而是能够主导模型性能的部署专家。