1.环境升级

1. 上述J6量产版本以OE3.2.0为例，J5 CS版本以OE1.1.74为例；

2. torch版本即将升级到2.6+cuda12.6。

1.1 docker开发

由于老版本docker存在一些兼容性问题（如工具运行失败，python包import失败等异常问题），因此使用J6计算平台的docker时需要确保docker版本满足如下要求：

• Docker（20.10.10或更高版本，建议安装20.10.10版本）

• NVIDIA Container Toolkit（1.13.5或更高版本，建议安装1.15.0）

1.2 本地部署

由于J5和J6的horizon-tc-ui以及模型转换分开发版，因此无法在同一个环境中同时安装J5和J6的PTQ模型转换环境。建议使用docker开发。

2.算法开发

2.1 浮点模型准备

J6和J5计算平台支持的DL框架范围一致，Pytorch框架支持导出为onnx进行模型转换编译，也提供了量化插件用于直接转换编译torch module；支持直接转换caffe模型；其他框架导出为onnx即可支持。各框架版本支持情况如下：

上述J6量产版本以OE3.2.0为例，J5 CS版本以OE1.1.74为例；

2.2 模型量化

2.2.1 PTQ

 

J5 和 J6 PTQ模型转换流程对比图

上图对比了J5和J6的转换流程，从使用流程上来说没有区别，J6为了支持用户灵活使用的需求，释放了Python API给客户。

2.2.1.1命令行工具 

2.2.1.2 Python API

考虑到J6支持对hbir做修改（如插入节点、修改节点名字等），因此为避免有灵活配置需求的PTQ用户无需在python脚本和命令行工具之间来回切换，因此将hmct（Horizon Model Convert Toolkit 模型转换工具）的API（接口说明请参考 用户手册-进阶内容-HMCT API Reference 章节内容)直接向用户开放，以下是一个简单的使用示例：

参考后续代码可将ptq_model.onnx转为.bc，并编译得到.hbm：

2.2.1.3 quant_config配置说明

完整的配置参数说明请参考 用户手册-训练后量化（PTQ）-PTQ转换工具-quant_config说明 章节的内容，本节仅介绍quant_config配置和J5配置方式的对应关系：

1. default校准

J6校准参数组只需配置校准数据集即为default：

2. mix校准

J6校准参数组只需通过quant_config打开layerwise_search即可：

3. 其他配置说明

2.2.2 QAT

 

J5 和 J6 QAT模型转换流程对比图

由上述对比可见，将J5模型迁移至J6时，若希望尽可能复用J5的部署代码，则不可避免的需要对模型做一些适配修改，因此需要依据下一章的介绍，写一个符合部署需要的J6模型编译脚本。

推荐依据上面流程图所示的方式进行J6模型开发：

1. 若要确认部署模型精度指标是否达标，建议测试convert后的模型，有两种方案：

   • 方案1：使用python api，复用python端前后处理，在cpu集群上评测quantized.bc

   • 方案2：使用UCP_x86版本，使用部署前后处理代码，在cpu集群上评测quantized.bc（在x86端推理quantized.bc比.hbm快，推理代码与hbm完成一致）

2.3 模型修改及编译

因为实际部署中Pyramid输出数据都是独立的内存，为了简化实现、贴合部署，J6计算平台不再支持batchN pyramid输入（即不支持推理shape第一维不等于1的pyramid/resizer模型），图像输入类模型仅支持独立地址部署。非图像输入模型支持batchN（连续地址），也支持通过拆分batch来实现独立地址部署。

本章除2.3.1节ptq与qat链路导出.bc的方式有区别之外，2.3.2 - 2.3.5的内容不区分.bc的量化方式

由于PTQ链路默认不保存convert之前的.bc文件，若用户需要基于.bc做一些修改，可使用如下方式将ptq_model.onnx转为.bc：

2.3.1 指定模型输入输出节点名称

2.3.1.1 QAT

由于 export 后的 *.bc 模型输入/输出节点name的生成规则与J5 hbm不同，因此若需要尽可能复用J5的工程代码，则建议在 export 时指定一下模型的输入输出节点的name，同时也便于有多个输入/输出节点shape一样时，可以通过*.bc 或者 *.hbm 模型的name辨别与torch模型之间的对应关系：

若想生成的bc文件输入格式与之前版本保持一致，则建议在export过程中设置 native_pytree=False

2.3.2 多Batch拆分

典型应用场景：BEV模型在部署时，多V输入来源于不同的摄像头，因此需要将pyramid输入节点沿batch维度做拆分。

2.3.3 输入数据前处理

该操作请在 convert 前完成

• mode，可选值包含：
  • "yuvbt601full2rgb" YUVBT601Full 转 RGB （默认）
  • "yuvbt601full2bgr" YUVBT601Full 转 BGR
  • "yuvbt601video2rgb" YUVBT601Video 转 RGB 模式
  • "yuvbt601video2bgr" YUVBT601Video 转 BGR 模式
  • "bgr2rgb" BGR转RGB
  • "rgb2bgr" RGB 转 BGR
  • "skip" 不进行图像格式的转换，仅进行 preprocess 处理
• 数据转换除数divisor，int 类型，默认为 255
• 均值mean，double 类型，长度与输入c方向对齐，默认为 [0.485, 0.456, 0.406]
• 标准差值std，double 类型，长度与输入c方向对齐，默认为 [0.229, 0.224, 0.225]

迁移注意事项：

插入前处理节点后输入数据处理流程如下：

部署输入数据 -> 色彩转换 -> 数据格式转换 (int 转 float， 即除 divisor) -> 减均值 mean -> 除标准差 std -> 输出（数据类型为 float）-> 量化 ->model

2.3.4 调整输入输出数据排布

迁移注意事项：

1. 插 transpose 节点建议在 convert 之前完成；

2. 请注意正确配置 transpose 的维度变换顺序，例如：

   1. 模型输入：NHWC —> transpose[0,3,1,2] —> NCHW —> model
   2. 模型输入：NCHW —> transpose[0,2,3,1] —> NHWC —> model
   3. 模型输出：model —> NCHW —> transpose[0,2,3,1] —> NHWC

2.3.5 算子删除

该操作需要在 convert 后完成，因为 convert 前模型都还是浮点输入输出，没有生成量化反量化节点：

若进行了删除动作，需要在后处理中根据业务需要进行功能补全，例如实现量化、反量化的逻辑。

OE3.0.31版本支持使用VPU推理量化反量化，只需在conver时启用vpu即可

量化计算参考代码：

Tips1：

当前qat链路的op.name较为冗长，难以通过remove_io_op(op_names=[])来删除指定节点，可暂时采用下面的临时方案删除与某输入/输出节点直接相连的节点：

Tips2：

当前argmax节点的输出结构由于reshape在cast之后（如下图所示），因此无法直接通过remove_io_op删除cast，建议用户依据执行argmax操作维度的尺寸，在torch模型中将输出的index cast到对应数据类型再导出onnx/.bc，则convert后argmax将直接以对应精度输出，不会存在cast节点。

示例：

对dim=2求max，index最大值为30239（超出int8表示范围了），则尾部插入cast转int16

qat.bc模型结构

convert后的模型结构：

2.4 性能测试及调优

使用hb_compile工具编译模型会默认生成静态性能评估文件（.html & .json）。若需要自行评测某模型的性能，具体可参考后文介绍：

2.4.1 静态性能评测

2.4.2 动态性能评测

ps：为了提高用户评测效率，工具内部自动依据模型输入大小计算了最小stride

2.4.2.1 Pyramid输入

stride计算方式（W32对齐）：

perf命令（Pyramid输入的模型其stride为动态，可以不用指定，工具会自动计算）：

假设模型输入尺寸为Y=（1,224,224,1），UV=(1,112,112,2,)

2.4.2.2 Resizer输入

perf命令：

假设希望评测的是原图尺寸为HxW=300x300，ROI=（0,0,200,200）下的性能数据，则perf命令如下所示（valid_shape和stride可以不用指定，工具会自动计算）：：

roi.txt（使用空格隔开：left top right bottom）：

2.5 精度测试及调优

2.5.1 PTQ

2.5.2 QAT

在J6计算平台上，若使用新的prepare接口，默认会调用check_qat_model，在prepare之后会生成model_check_result.txt文件。

1. 通过model_check_result.txt检查模型qconfig配置是否正确、是否有未融合的结构以及对精度不友好的共享模块。

2. 验证全 int16 精度调优，确认模型的精度上限，排查工具使用问题和量化不友好模块。若int16不达标，则建议先观察模型中每层的数据分布范围，若的确存在数值范围超出int16的计算，则代表该模型可能需要引入部分fp16的计算（若能通过优化算法将数值范围控制在更小的区间，则对性能和精度都会更加友好）。

3. 使用debug工具分析节点敏感度，依据敏感度配置模型中需要使用int16的比例。

需要注意的是，J5计算平台的定点模型是torch module/torch script格式，而J6计算平台则是hbir格式（*.bc），推理hbir和.hbm的代码如下所示：

2.5.2.1 pyramid输入

2.5.2.2 resizer输入

2.6 工具

2.7 应用开发

由于J6系列计算平台通用性提高，因此为了适应更广泛的模型推理，参考python对数据的定义方式：

1. 提供整数（int）、浮点数（float）、布尔值（bool）等基础数据类型的支持，移除部分特殊数据类型：

2. 通过stride（步长）来定义内存中元素之间的存储间隔（用户通过该参数可创建非连续的数据存储方式，例如实现图像输入在内存中以二维形态存储，并通过stride参数来完成添加/移除padding的相关操作）。不再提供“layout”信息。

3. 通过valid_shape来获取tensor的维度和每个维度有效数据的大小。

4. 用户通过stride和valid_shape信息来计算对齐后的每个维度的大小，不再提供aligned_shape信息。

即hbDNNTensorProperties结构体做出如下调整

5. 每个Tensor仅对应一个内存地址：

2.7.1 图像输入（重要）

2.7.2 非图像输入

推荐使用UCP新的推理接口，该接口可用于灵活创建同步/异步的推理任务，并通过连续创建任务的方式实现批量推理，只返回一次中断的推理方式：

再配合任务提交接口即可完成模型推理任务。