NPU的编译器开发：单元测试与集成测试一个让我熬夜到凌晨三点的bug去年做某款AIoT芯片的NPU编译器时，遇到一个诡异的推理错误——模型在PC端仿真器上跑得好好的，一上芯片，分类结果全错。折腾了两天，最后发现是卷积层的权重排布在硬件内存映射时，编译器后端少做了一个维度转置。更气人的是，这个bug在单元测试阶段完全没暴露，因为单元测试只测了单个算子的计算逻辑，没测算子之间的数据流衔接。从那以后，我给自己定了个规矩：NPU编译器测试，必须把“单元测试”和“集成测试”当成两套独立的武器库，谁也别想偷懒。单元测试：别让算子变成黑盒NPU编译器的单元测试，核心是验证每个算子（卷积、池化、全连接、激活函数等）在编译器前端、中端、后端各个阶段的正确性。但这里有个坑——很多新手只测“输入输出数值对不对”，忽略了中间表示（IR）的合法性。测试什么才算到位？数值精度测试是基础，但别只给一组数据。我习惯的做法是：对每个算子准备三组测试用例——典型值（比如输入范围在[-1,1]的浮点）、边界值（比如int8量化后的-128和127）、异常值（比如全零输入、全负输入）。卷积算子还要额外测不同stride、padding组合，尤其是stride=2且padding=1这种容易在硬件地址计算上出错的场景。IR结构测试才是真正容易漏掉的部分。NPU编译器内部会把算子转换成多层IR，比如从高层图IR降级到低层指令IR。单元测试必须验证：IR的节