NPU的编译器开发：模型量化工具集成一个让我熬夜三天的bug去年做某款AIoT芯片的NPU编译器时，遇到一个诡异的推理精度问题。模型在PC端用float32跑，mAP是0.78，量化到int8后直接掉到0.31。团队里新来的同事说“量化损失正常”，但我盯着那个0.31的数字，总觉得哪里不对——同样的量化流程，在另一款竞品芯片上能跑到0.72。后来花了三天，从量化参数传递链路一路追下去，发现是编译器在生成NPU指令时，把量化scale和zero_point的字节序搞反了。更坑的是，这个错误只在特定batch size下触发，因为指令调度器在拼接常量池时，对不同大小的tensor用了不同的内存对齐策略。这个教训让我意识到：模型量化工具集成，远不是“调个API”那么简单。它涉及数据流、精度控制、硬件约束、调试手段四个层面的深度耦合。今天这篇笔记，就聊聊我在NPU编译器里集成量化工具时踩过的坑和总结的经验。量化工具集成的三个层次第一层：校准数据的“搬运工”很多刚入行的同学以为量化工具集成就是调用torch.quantization.quantize_dynamic或者onnxruntime.quantization.quantize。但NPU编译器要做的，是把量化后的参数（scale、zero_point、量化后的权重）嵌入到编译后的二进制指令流中。这里有个关键点：校准数据集的预处理必须和推理时完全一致
)
)
