RKNN-Toolkit2中多输入模型转换与推理问题深度解析

问题背景

在使用RKNN-Toolkit2将LightGlue算法移植到RK3588平台的过程中，开发者遇到了一个典型的多输入模型转换与推理问题。该模型需要处理四个输入：两张图片的特征点坐标(kpts0, kpts1)和对应的特征描述子(desc0, desc1)，输入维度分别为(1,300,2)和(1,300,256)。

模型转换过程

在模型转换阶段，开发者使用Python脚本成功将ONNX模型转换为RKNN模型。转换过程中需要注意几个关键点：

1. 输入类型处理：kpts0和kpts1是整型特征点坐标，desc0和desc1是浮点型特征描述子。在量化过程中，描述子会被转换为INT8类型。

2. 量化配置：通过设置QUANTIZE_ON参数控制是否进行量化。量化时需要准备相应的数据集，对于这种特殊输入结构的模型，数据集应包含特征点和描述子的样本。

3. 输入维度固定：虽然算法支持动态输入，但为避免转换和推理时出现问题，建议使用固定维度。

Python环境验证

在Docker 2.2.0环境中，开发者通过Python脚本验证了转换后的RKNN模型可以正确推理，并获得了符合预期的可视化结果。这一步骤验证了模型转换本身的正确性。

C++推理遇到的问题

当将模型部署到RK3588板端使用C++推理时，程序在rknn_run()函数处出现段错误(Segmentation fault)。经过深入排查，发现几个关键问题：

1. 输入配置不当：在C++代码中，需要精确匹配每个输入的类型和维度。例如，desc0和desc1在量化后应为INT8类型，而非原始模型的FLOAT32。

2. 内存分配问题：输入缓冲区的大小计算需要准确，特别是对于多输入模型，每个输入的size参数必须与其实际数据大小匹配。

3. NPU核心设置：RK3588支持多NPU核心，需要正确设置core_mask参数。

根本原因分析

进一步排查发现，段错误的根本原因是模型中包含RKNN不完全支持的算子(torch.topK)。虽然在RKNN-Toolkit2 2.2.0版本的模拟环境中这些算子可以工作，但在实际板端运行时会导致崩溃。

解决方案

1. 算子替换：将不支持的算子(如torch.topK)移出模型，在外部用自定义实现替代。

2. 驱动升级：虽然不一定是根本原因，但保持驱动版本与工具链匹配是良好实践。

3. 逐步验证：先在Python环境中完整验证模型，再移植到C++环境，可以更快定位问题。

经验总结

1. 对于多输入模型，务必仔细检查每个输入的属性(type/fmt/size)是否与模型定义一致。

2. 在板端部署前，应先在模拟环境中完整验证模型，包括所有算子的支持情况。

3. 动态形状支持在RKNN中可能存在限制，固定输入形状可以减少问题。

4. 不同版本的RKNN-Toolkit对算子的支持程度不同，需要根据目标平台选择合适的版本。

最佳实践建议

1. 在模型转换阶段就开启详细日志，检查是否有不支持的算子警告。

2. 准备多样化的测试数据，覆盖各种边界情况。

3. 对于复杂模型，考虑分阶段转换和验证，先验证部分子图，再整合完整模型。

4. 保持开发环境(Docker)与部署环境的版本一致性。

通过系统性地解决这些问题，开发者最终成功将LightGlue算法部署到RK3588平台，这一经验对于其他复杂模型的RKNN移植工作具有重要参考价值。