NPU的编译器开发：多核并行化与任务调度一个让我熬夜三天的bug去年做某款AIoT芯片的NPU编译器时，遇到一个诡异现象：单核跑MobileNetV2推理，延迟稳定在12ms；换成双核并行，反而飙到18ms。更离谱的是，四核模式下直接触发看门狗复位——任务调度器把NPU核心的电源域给搞崩了。当时盯着逻辑分析仪抓出来的波形，发现两个核心在争抢同一个DMA通道，而调度器还在傻乎乎地往两个核上派发相同的数据分片。这个bug让我意识到：NPU的多核并行化，远不是“把网络切成几块分给几个核”那么简单。多核NPU的硬件约束：你以为是CPU，其实是异构集群先泼盆冷水：NPU的多核和CPU多核完全是两码事。CPU多核共享缓存、一致性协议成熟，你写个OpenMP就能跑。NPU呢？每个核心可能有自己的SRAM、专用的DMA引擎、甚至不同的指令集变体。我手头这块NPU，四个核心分成两组：Core0/1共享一个4MB的本地SRAM，Core2/3共享另一个4MB，两组之间通过一个带宽只有2GB/s的环形总线互联。更坑的是，每个核心的权重缓冲区只有512KB——这意味着你没法把整个模型塞进一个核。这里踩过坑：一开始天真地按层切分，把Conv层分给Core0，Pooling层分给Core1。结果Core0算完要等Core1，Core1又在等Core0的中间结果，活生生跑成了串行。后来才明白，NPU多核调度的核心不是“分任务”，而是“分数据”。数据并行 vs
