01目标
将视觉定位模型交付到高通边缘环境，在压缩模型体积的同时保留昼夜定位能力。客户已有 INT8 路径，但定位效果明显下降，需要先诊断误差，再寻找可复现的替代方案。
我负责模型转换与量化验证、定位误差分析，以及代码、结果和报告的交付整合。无法重训练且周期紧张，使“可执行的修复路径”成为重要约束。
02输入
- HF-Net 原始模型、已有 INT8 量化方案与转换配置。
- 昼夜定位评估数据、误差阈值与对应基线结果。
- PyTorch、ONNX、QNN SDK 和 CPU / HTP 等目标后端。
- 模型大小、运行资源与交付周期要求。
比较方案需要使用一致的评估条件，否则转换问题、量化问题和后端差异容易混在一起。
03用户流程
以下按部署工程师的使用任务梳理：
- 复现原始模型与既有量化路径，在同一定位评估中建立基线。
- 检查昼夜校准集和推理后端变化是否能解释或修复性能下降。
- 应用替代量化策略，再次转换并运行相同评估。
- 对照昼夜成功率、模型大小与错误样本，判断是否适合目标部署。
- 将模型相关代码、评估结果和运行说明交给后续集成人员复现。
04输出
我复现了 PyTorch → ONNX → QNN SDK 的常规 INT8 路径，检查更换校准数据与 CPU / HTP 后端后的结果，确认这些调整未解决定位劣化。
随后使用 Cross-Layer Equalization 与 Per-channel Quantization 平衡动态范围，交付相对于常规 INT8 更好地保留定位能力的替代路线，同时保持模型压缩收益。
最终产物包括量化相关代码、对比结果和报告组成的边缘部署包。交付既要能运行，也要能说明原路径为什么不足、新路径在什么条件下有效。
05任务边界
- 工作聚焦既有定位模型的转换、量化、评估与交付，不包含自动泊车系统的全部感知和控制功能。
- 无法重训练是本阶段的约束，因此采用的路线需要在现有模型上验证。
- 昼夜评估集中的恢复结果不能扩展为所有地点、相机与环境的普遍保证。
- 客户原始模型、数据和内部评估数值不在文章中公开。
06验收标准
以下为方案对比和部署交付的验证口径：
- 原始模型、常规 INT8 和替代方案使用相同数据及定位误差口径，分别检查昼夜表现。
- 不仅核对模型体积，也核对定位能力，避免将“转换成功”当作“部署可用”。
- 转换与量化过程的配置明确，评估结果能够复现。
- 代码、结果和说明互相对应，后续集成人员能够理解已验证范围与未验证条件。
具体客户签收条款未公开，文章不作额外生产性能承诺。
07迭代
先复现劣化现象，再排查校准集与后端差异，随后转向动态范围相关的量化策略。每一步都通过同一评估口径判断是否真正解决问题。
后续可围绕新场景补充验证，并持续检查资源、精度与部署维护成本。模型优化的成果应由业务所需能力衡量，体积只是其中一个指标。