yolox转定量模型检测不出框

盗亦有道2026-04-21

183

地平线的开发人员您好。

近期我们在做 YOLOX 红绿灯模型的板端部署对齐时，发现一个比较明确的问题，想请你们帮忙一起定位。

我们直接从板端获取同一张真实输入的 YUV(NV12) 数据，基于同一个输入文件，分别测试了：

1.deploy_optimized_float_model.onnx

2. deploy_ptq_model.onnx

3. deploy.hbm

在这个逐步部署的过程中，我们观察到一个很明显的现象：

- 模型对 light_share0 类别检测基本稳定，但 countdown_light（倒计时灯）这个类别的置信度随着部署链路推进逐步下降，最终在 PTQ / HBM 阶段，这个类别在常规阈值下基本就检不出来了。

本次所有测试都基于同一个板端输入：

- 输入文件：/jwsu/ocr_height/images/rm_img.yuv

- 格式：NV12

- 尺寸：1280x704

-模型：六分类

##附件说明##

1. input/rm_img.yuv

板端提供的真实输入，格式为 NV12，尺寸为 1280x704。

2. models/deploy_optimized_float_model.onnx

float ONNX 模型。

3. models/deploy_ptq_model.onnx

PTQ ONNX 模型。

4. models/deploy_wb_v20260420.hbm

HBM 模型。

5. scripts/onnx_single_input_nv12_vis.py

ONNX 推理脚本，用于读取 rm_img.yuv，解码为 BGR 后送入单输入 ONNX。

6. scripts/nv12_dual_input_infer.py

HBM 推理脚本，用于读取 rm_img.yuv，拆分为 blob1_y 和 blob1_uv 后送入 HBM。

7. scripts/hbm_demo_hzli.py

推理脚本依赖的后处理代码。

8. 输入YUV推理参考.md

推理参考文档，包含 float ONNX、PTQ ONNX、HBM 的完整运行命令和输出说明。

附件:

算法工具链

技术深度解析征程6

0/600

DR_KAN
Lv.5
ptq onnx有框，hbm没框，有可能是预处理节点的参数写错了，可以按这个方向检查下。还有一个排查方法，就是用预处理归一化之后的数据，给featuremap输入量化编译的所有模型测试，看看这个情况下有没有框，可以规避预处理节点的问题。
2026-04-23
0
0
zyhang
Lv.1
您好，看起来像是精度损失比较大，校准集的准备是否正确，如果正确的话，可以先全设置为全INT16再量化转换试一下看看精度损失呢
2026-04-22
0
10
- 盗亦有道回复zyhang:
  您好。全int16按照我上面的测试过程也是到hbm就检测不出框了。但是ptq.onnx能检测出框。能否帮我看看推理代码是否正确呢？现在不太能定位到具体原因。
  2026-04-23
  0
  回复
- zyhang回复盗亦有道:
  我们对量化后的onnx模型转为bc模型以及hbm模型，然后对此bc模型和hbm模型进行了输出一致性验证，我们验证过bc模型是能检测出框的，hbm模型和bc模型输出是完全一致的，说明是你转换为hbm模型时yaml文件配置有问题，或者推理时前处理或者后处理有问题，可以给一下yaml文件配置信息吗
  2026-04-23
  0
  回复
- 盗亦有道回复zyhang:
  我们这边原始 HBM 的 YAML 配置如下：
  input_type_rt: nv12
  input_type_train: bgr
  input_layout_train: NCHW
  mean_value: 0 0 0
  scale_value: 1.0
  cal_data_dir: ../input/ref_img_npy
  cal_data_type: uint8
  quant_config: {model_config: {all_node_type: int16, model_output_type: int16}}
  实际校准数据是 ref_img_npy/*.bgr.npy，shape 为 (3,704,1280)，dtype 为 float32，数值范围 0~255。
  编译日志中看到该 HBM 最终 input_source 为 {'blob1': 'pyramid'}，并插入了 image preprocess / image convert op，最终 HBM 输入为
  blob1_y/blob1_uv。
  我们另外做了一个 featuremap/blob1 直入版 HBM：
  input_type_rt: featuremap
  input_type_train: featuremap
  input_name: blob1
  input_shape: 1x3x704x1280
  cal_data_type: float32
  这个版本直接喂和 PTQ ONNX 一致的 blob1 后，倒计时灯分数从原始 HBM 的 0.0728 恢复到 0.3780。因此怀疑原始 YAML 的 nv12/pyramid 输入
  配置、cal_data_type，或 runtime 输入口径与 PTQ ONNX 的 blob1 输入不一致。
  请帮忙确认原始 HBM 若要使用 NV12 输入，input_type_rt/input_type_train/input_layout_train/cal_data_type/input_source 是否应该这样
  配置。
  2026-04-23
  0
  回复
- zyhang回复盗亦有道:
  cal_data_type: uint8有问题，先把unit8改为float32试一下看看
  2026-04-23
  0
  回复
- 盗亦有道回复zyhang:
  改为float32了，但是倒计时灯这个框是的置信度还是很低啊。class=countdown_light score=0.0456 bbox=(946,30,992,72) 。你们之前提到bc模型可以检测出框，那这个倒计时灯的框得分如何呢？我这边的得分还是很低？
  2026-04-27
  0
  回复
- HuangHui回复盗亦有道:
  重新给你对齐一下哈：
  1. 从你给资料中有ptq.onnx以及推理脚本，使用推理脚本验证可以得到ptq.onnx的推理结果是OK的。
  2. 使用你他ptq.onnx通过脚本可以转换编译得到quantized.bc和hbm。编译时rt 和 train使用featuremap保证quantized.bc消费的的输入数据与ptq.onnx消费的输入数据一致。
  3. 使用你给的推理脚本推理quantized.bc模型（输入数据与ptq.onnx一致）得到的推理结果是OK的。你自己可以验证。
  4. 使用hb_verifer验证quantized.bc和hbm的一致性测试通过。
  
  总结，ptq.onnx精度OK，quantized.bc精度OK，quantized.bc和hbm在同样的input下有一样的推理姐结果。
  2026-04-27
  0
  回复
- HuangHui回复HuangHui:
  通过网盘分享的文件：13572.tar.gz
  链接: https://pan.baidu.com/s/1X90oHa1hsld2ihyAk-vf2Q?pwd=f8qz
  工程和代码都在这里哈
  2026-04-27
  0
  回复
- 盗亦有道回复HuangHui:
  黄工你好。你们这边的结果我这边之前也做过了，如果编译时去掉前处理，保证输入是featuremap，那么hbm和bc都可以检测出倒计时框。这条推理链路是YUV -> BGR -> blob1 -> HBM。
  但是如果是我之前的方式，也就是保留前处理。模型推理时的链路是 YUV -> blob1_y + blob1_uv -> HBM。。用的代码是nv12_dual_input_infer.py。就检测不到倒计时灯的框，我想问的问题关键是这一个。为什么会有这样的不一致？
  2026-04-28
  0
  回复
- HuangHui回复盗亦有道:
  基于你附件中体提供的ptq.onnx, 使用下面的代码时可以推理出你提到的倒计时红绿灯的哈：
  2026-04-30
  0
  回复
- HuangHui回复HuangHui:
  2026-04-30
  0
  回复