j6-plugin-model-check-result

分析 Horizon model_check_result.txt（模型结构与量化配置检查）

目标

在模型完成 prepare(...) 后，基于运行目录中的 model_check_result.txt，快速发现并解释以下四类问题：

1. 算子融合异常（可融合但未融合）
2. 共享模块风险（同一 module 多次调用）
3. qconfig 配置异常（dtype/高精度输出/可疑 qconfig）
4. averaging_constant 非默认值（observer 的 averaging_constant != 0.01）
5. 算子输入浮点检查（非 QuantStub/DeQuantStub 算子的输入为浮点类型）

本 Skill 聚焦“检查结果解读与修复建议”，用于连接 prepare 之后的排查阶段。

背景约束（必须知道）

• prepare 已集成 check_qat_model；通常不需要额外手动调用，直接查看 model_check_result.txt 即可。
• 该检查工具会给出“需要你复核”的线索，并非每条提示都一定是错误。
• 真正是否需要修改，必须结合模型拓扑、部署边界、精度对比结果综合判断。

本 Skill 强约束

• 只做结果分析与修复路径建议：不擅自改动大量模型结构。
• 先读结果再下结论：必须依据 model_check_result.txt 中的具体表格与条目，不做臆测。
• 分五块输出结论：
  1. 融合问题
  2. 共享问题
  3. qconfig 问题
  4. averaging_constant 非默认值提示
  5. 算子输入浮点检查提示
• 给出“是否必改”的判断等级：
  • 高优先级（明确错误/高风险）
  • 中优先级（可能影响精度/性能）
  • 低优先级（提示项，需业务确认）

重点检查项与判定标准

1) 算子融合检查（Fusable modules）

关注 Fusable modules are listed below: 段落。

若存在未融合模块，常见原因如下：

• 动态代码块里涉及替换/融合逻辑，但缺少 dynamic_block 标注
• 未融合模块为共享模块。

输出建议时要明确：

• 这是“结构正确性 + 性能/精度”问题，不一定每个未融合都必须改
• 若未融合位置伴随共享或动态逻辑，应优先处理

2) 共享模块检查（Each module called times）

关注 Each module called times: 段落。

基础判定：

• called times = 1：正常
• called times = 0：未调用（需检查是否死分支/配置问题）
• called times > 1：共享调用

关键解释：

• “共享调用”本身不必然错误
• 只有当多次调用的数据分布差异明显时，才容易因共用一组量化参数导致较大误差

建议流程：

从 called times > 1 列出候选模块，建议用户自行排查决定是否需要拆分共享模块

3) qconfig 正确性检查

重点看以下内容：

• Each layer out qconfig:
• Weight qconfig:
• input/output dtype statistics:
• Please check if these OPs qconfigs are expected.

高精度输出判定标准：

检查每个 DeQuantStub 的输入 dtype，按以下三级判定：

• DeQuantStub 输入为 torch.float32：✅ 高精度浮点输出路径已生效。上游算子输出 fp32 直连 DeQuantStub，说明该路径保持了浮点精度。标注为正常行为。
• DeQuantStub 输入为 qint16：✅ 高精度量化输出已开启。上游算子使用 qint16（相比 qint8 提供更高量化精度）进行量化，DeQuantStub 将 qint16 反量化为 float32 是标准的高精度量化输出链路。标注为正常行为，说明模型已开启高精度量化配置。
• DeQuantStub 输入为 qint8：ℹ️ 标准 int8 量化输出。这是常规的 int8 量化配置，DeQuantStub 将 qint8 反量化为 float32 是标准的反量化行为。无异常，但也不属于高精度输出。

常见异常模式：

• DeQuantStub 输入为 qint8 但用户期望高精度输出：需提示用户检查 qconfig 中是否正确设置了 qint16 或 fp32 的高精度输出 dtype
• Fixed scale / 可疑 qconfig 提示（不一定错，但必须复核）