NPU的编译器开发：动态形状支持一个让我熬夜三天的Bug去年做某款AI芯片的编译器时，遇到一个诡异的推理错误。模型在batch size=1时跑得完美，换成batch size=4就输出全零。查了三天，最后发现是编译器的内存分配器在处理动态形状时，把张量的步长（stride）算错了——它假设所有维度都是连续的，但动态形状下，最后一个维度的大小变了，前面的步长却没跟着更新。这个bug让我意识到，动态形状支持不是“加个参数”那么简单，它需要从编译器架构层面重新思考。动态形状为什么让NPU头疼NPU和CPU/GPU最大的区别在于：NPU的硬件数据流是静态规划的。CPU有乱序执行、分支预测，GPU有warp调度，它们天生能处理动态控制流。但NPU的脉动阵列、数据复用路径、DMA传输链，都是在编译时确定的。当形状变成动态，编译器面临三个核心问题：内存布局的不确定性。静态形状下，编译器可以精确计算每个张量的偏移量，甚至把多个小张量合并到同一块SRAM。动态形状下，你只知道“这个维度最大可能是64”，但实际运行时可能是1到64之间的任意值。如果按最大值分配，SRAM浪费严重；如果按实际值分配，地址计算必须硬件化。数据流图的静态化与动态化的矛盾。NPU的指令序列是编译时生成的，但动态形状意味着某些循环次数、DMA传输长度要到运行时才知道。这迫使编译器要么生成“通用指令”（性能差），要么引入硬件支持的动态调度机制（硬件复杂度高）。