J6hbm模型推理异常

已解决

默认980482024-09-03

355

用户您好，请详细描述您所遇到的问题，详细的描述有助于帮助我们快速定位，解决问题~Thanks♪(･ω･)ﾉ

1. 芯片型号：J6

2. 天工开物开发包 OpenExplorer 版本：horizon_j6_open_explorer_v3.0.17-py310_20240705

3. 问题定位：hbm推理结果置信度低

4. 问题具体描述：bc模型利用python代码可以decode进行可视化，结果正常；但是hbm模型在c++代码中输出结果置信度偏低，无检测结果？

5. 问题：

5.1 hbm和bc模型的推理结果差异会很大吗？如何确定是由于hbm掉点导致的推理无结果？

是否是模型推理结果的取值错误导致的？以下是模型后处理的代码，有几个疑问：

5.2 模型的outputtensor是1 1 6 11，stride是384 384 64 4，stride[4]为4，是不是意味着需要4个byte去表示，那取值的时候就不能直接conf_data[idx]取值，需要分别取出conf_data[idx]、conf_data[idx+1]、conf_data[idx+2]、conf_data[idx+3]等数值？

5.3 quantiType的类型是SCALE，但是我看示例中只做了*scaleData的操作，理论上是不是还需要进行-zeroPointData？

算法工具链

征程6

0/1000

遥看瀑布挂前川
Lv.2
5.1 hbm和bc模型的推理结果差异会很大吗？如何确定是由于hbm掉点导致的推理无结果？
单独推理bc模型和浮点对比，若bc模的结果已经出现误差则export或者convert阶段就有异常了。建议检查export前后和convert前后的bc模型推理是否正常。
是否是模型推理结果的取值错误导致的？以下是模型后处理的代码，有几个疑问：
5.2 模型的outputtensor是1 1 6 11，stride是384 384 64 4，stride[4]为4，是不是意味着需要4个byte去表示，那取值的时候就不能直接conf_data[idx]取值，需要分别取出conf_data[idx]、conf_data[idx+1]、conf_data[idx+2]、conf_data[idx+3]等数值？
stride可以简单理解为，某个维度的数，代表输出 shape 对应维度的值 +1 时，在内存上需要跳过的字节大小
- stride[2] - valid_shape[3] = 64 - 28 = 36
- 表明 shape 的最后一维 padding 了 36 个字节大小
- stride[1] / stride[2] = 2048 / 64 = 32 = valid_shape[2]
- stride[0] / stride[1] = 65536 / 2048 = 32 = valid_shape[1]
- 表明其他维度均不存在 padding
- 在编写 remove padding 代码时，仅需将最后一维下标 28~63 的值略去即可
5.3 quantiType的类型是SCALE，但是我看示例中只做了*scaleData的操作，理论上是不是还需要进行-zeroPointData？
zeroPoint是0，为对称量化
2024-09-06
0
13
- 默认98048回复遥看瀑布挂前川:
  您好，
  5.1 目前是bc模型推理没问题，但是hbm推理结果异常；且log显示两者同一tensor差异很大？这个是什么原因呢，有什么工具可以继续排查呢？
  5.2 想继续请教一下，在示例中(65536,2048,64,1,)stride最后一位是表示的是用1个byte；但是我的模型output shape是（1，1，6，11） stride是（384 384 64 4），tensortype的类型是tensor type: HB_DNN_TENSOR_TYPE_S32，下图是tensor的推理结果，根据stride[4]的值对应为4个byte，取值的时候是不是也只需要取第一个结果（例如只取tensor.sysMem[0].virAddr[0]的结果；认为tensor.sysMem[0].virAddr[1]、 tensor.sysMem[0].virAddr[2]、tensor.sysMem[0].virAddr[3]是padding并不需要考虑？
  2024-09-10
  0
  回复
- kotei左文亮回复默认98048:
  “bc模型推理没问题，但是hbm推理结果异常”，首先要确定模型的输入预处理是否一样的，其次“推理结果”还涉及到后处理，特别是输出的结果解析也要确定解析的是否正确，如果这两者都是没有问题的，那就很有可能是量化的过程中的问题了。
  2024-09-18
  0
  回复
- 默认98048回复kotei左文亮:
  bc推理和hbm推理的输入都是NV12的格式，按照示例里的输入；
  输出对比是直接打印模型直接的tensor输出（见上上上图），差异是数量级别的；
  量化的过程中，发现Quantized Cosine相似度偏低，有可能是这个原因吗？有什么优化的方向呢？
  2024-09-19
  0
  回复
- kotei左文亮回复默认98048:
  上图看不清楚啊，可以传一个清晰点的吗？ Cosine相似度偏低，在模型检查的时候有没有什么特别的算子不支持？
  2024-09-23
  0
  回复
- 默认98048回复kotei左文亮:
  模型检查是通过的，没有什么特别的算子；就是calibrated cosine都挺高的，但是quantized cosine就有部分很低甚至负数；
  2024-09-23
  0
  回复
- kotei左文亮回复默认98048:
  方便上传一下模型量化的文件吗？
  2024-09-23
  0
  回复
- 默认98048回复kotei左文亮:
  您好，上传了帮忙看看哈，谢谢啦通过网盘分享的文件：j6_ptq.zip
  链接: https://pan.baidu.com/s/10duvNpNjwbBNjOgDUO1_og?pwd=ggnq 提取码: ggnq
  2024-09-23
  0
  回复
- kotei左文亮回复默认98048:
  这个模型怎么会有几十个output啊? 可以试一下增加校准数据集的数量，或者调整网络重新训练看一下结果。我也再问问更专业的人吧。
  2024-09-25
  0
  回复
- 默认98048回复kotei左文亮:
  因为是个多任务的模型，所以output会比较多；我试试增加校准数据集
  2024-09-25
  1
  回复
- kotei左文亮回复默认98048:
  结果怎么样？
  2024-09-26
  0
  回复
- 默认98048回复kotei左文亮:
  将校准数据集从100张增加到2000张，余弦相似度有一点点提高但不多；实际hbm推理还是不行
  下图是同一输入，用不同数量的校准数据集对比的optimized_float_model和quantized_model.bc
  2024-09-26
  0
  回复
- kotei左文亮回复默认98048:
  余弦相似度比较低的算子，例如Conv_101, 卷积核大小，步长，通道数有没有什么特别之处？
  2024-09-26
  0
  回复
- kotei左文亮回复默认98048:
  由于您长时间未回复，此问题就先关闭了，如还有疑问，可再发帖求助。
  2024-09-30
  0
  回复
kotei左文亮
Lv.3
可以先把不同模型的推理结果打印出来对比一下，比如输出buffer里的钱前100个数字进行对比，然后看看结果差别
2024-09-06
0
5
- 默认98048回复kotei左文亮:
  您好，把bc模型和hbm模型的输出打出来检查，发现差异很大；这个差异是否说明hbm量化损失严重？
  2024-09-10
  0
  回复
- Pipeline回复默认98048:
  是PTQ还是QAT？
  
  2024-09-10
  0
  回复
- 默认98048回复Pipeline:
  PTQ
  2024-09-11
  0
  回复
- Pipeline回复默认98048:
  两个都接了反量化还是模型直出？
  2024-09-11
  0
  回复
- 默认98048回复Pipeline:
  都是模型直出的
  2024-09-11
  0
  回复
Pipeline
Lv.2
是否计算零点取决于你的输入状态，可以用hrt_model_exec查看一下，是否考虑到量化后数据截断到对应datatype范围

2024-09-06
0
2
- 默认98048回复Pipeline:
  您好，用工具hrt_model_exec查看后，发现“zero_point data: ,”是空的，说明就不需要计算零点？
  然后有个问题，如果使用非对称量化，是否就是修改配置文件下的“calibration_parameters”下的optimization: 'asymmetric' ？这个时候就需要考虑计算zeropoint的值？
  2024-09-09
  0
  回复
- Pipeline回复默认98048:
  是的，配置文件没有设置或者default没有打开asymmetric，都不会有zero_point
  2024-09-10
  0
  回复