OE包3.7.0 J6B 模型量化编译后grid sample算子没有上BPU

已解决

默认259522026-01-27

1.J6B

2.openexplorer/ai_toolchain_ubuntu_22_j6_gpu:v3.7.0

3.问题：模型转换，模型量化编译后grid sample算子没有上BPU，实现硬件是[CPU, BPU]，导致在板端部署推理后出现多个线程（部署程序是一个进程单线程），CPU占用很高，推理耗时非常长，BPU占用的均值和最大值差异很大。（相同模型转J6M没有这个问题）

算法工具链

征程6

0/1000

Huanghui
Lv.5
你好，这个是J6B的芯片，业务应该又专门对接支持的同学的吧。
你这个 grid sample算子没有上BPU 的问题，可以关注一下上游算子的输出是int8的数据，还是int16的数据，目前BPU上运行grid_sample算子是data要求int8，grid要求int16。
2026-01-27
0
11
- 默认25952回复Huanghui:
  你好，我的模型grid_sample算子输入data是int8，grid是float（是整个模型的输入之一，类型是featuremap，float），但为什么相同的模型和输入J6M模型转换grid_sample算子是可以上BPU的呢？
  2026-01-29
  0
  回复
- Huanghui回复默认25952:
  J6B/J6M工具链内部对算子的处理策略不同很正常，J6M也是要求grid int16输入的。回到问题本身， grid 是模型原始输入之一，输入float这个可以理解，输入之后是有量化节点进行量化的呀，量化成int16不行吗？如果还是不行，你把模型分享一下吧，我看看啥情况~
  2026-01-30
  0
  回复
- 默认25952回复Huanghui:
  你好，grid的输入是int16
  2026-02-03
  0
  回复
- Huanghui回复默认25952:
  2026-02-03
  0
  回复
- 默认25952回复Huanghui:
  2026-02-03
  0
  回复
- Huanghui回复默认25952:
  收到，这样确实有点奇怪，最后确认一下：你是如何判断出 grid sample算子没有上BPU 的？
  2026-02-03
  0
  回复
- 默认25952回复Huanghui:
  在log上看到的grid_sample:[CPU，BPU]，把bc模型导出onnx显示grid_sample的grid输入的量化是在CPU上的，现在设置了remove_node_type: Quantize;Dequantize，bc导出的onnx上没有这个量化节点了（第一张图是remove前的，第二张图是remove后的。），现在正在上板部署测试推理延迟和BPU占用看看是否解决了。
  2026-02-04
  0
  回复
- 默认25952回复Huanghui:
  2026-02-04
  0
  回复
- Huanghui回复默认25952:
  你这图中不是已经跑到bpu（b30...）了吗？CPU上算子时hbtl开头的，log 中显示的有点问题，以qantized.bc转onnx中查询 hbtl 结果为准哈
  2026-02-04
  0
  回复
- 默认25952回复Huanghui:
  之前模型里是有hbtl开头的量化算子的，今天把Quantize/Dequantize remove后就去掉了，在部署代码里把grid的输入手动量化成int16，刚上板测试推理延迟在20ms以下了，但是CPU占用还是比较高，J6B CPU占15%的kdmips。
  2026-02-04
  0
  回复
- Huanghui回复默认25952:
  grid_sample在bpu就OK了，如果资源占用不符合预期，那就是其他算子导致的，还是要看是不是hbtl算子，以及hrt之后的profile.log文件
  2026-02-04
  0
  回复