NPU多核切分别被同步点拖慢

一看到芯片上有多个计算簇，很多团队就自然期待吞吐按核数线性上涨。NPU在多核场景里最常见的反例，恰恰来自切分后新增的同步点、边界复制和归并等待把理论并行度吃掉了。

切分是否有效，先取决于任务能不能被切成对称负载。按空间维度分块看似直接，但卷积核边界需要 halo 区域，块越碎，重复读取的边界数据越多；按通道维度分块则要在输出处做归并，某些层还会因为通道依赖无法完全独立。表面上四个核都领到了活，实际有些核在算中心区域，有些核在反复处理边角和同步开销，尾部延迟因此被最慢那一核锁住。

同步点比计算量更容易被低估。残差汇合、拼接层、共享后处理和跨核写回，都需要所有分支在某个时刻对齐。只要其中一核稍慢，其余核心就只能空等。多核系统里最危险的不是平均负载不满，而是存在几个固定的栅栏点，把本该流动的流水线变成一段段停走。很多基准测试只统计纯算子时间，没有把 barrier 和 fence 算进去，因此现场结果总比实验值差一截。

片上网络也会改变切分收益。多个核同时拉权重、写部分和或交换边界块时，NoC 和共享 SRAM 端口会被一起占满。若调度器只关心“每核工作量差不多”，却不关心“它们是否在同一时刻抢同一资源”，多核反而会把单核时不存在的拥塞放大。某些模型在两核下还有效，扩到四核反而变慢，原因往往不在算子，而在数据交换密度超过了片上网络的甜点区。

更稳妥的做法，是先找出同步最少的切分面。能沿子图天然边界拆开的，不要硬把单层卷积撕碎；能让前后两层在同一核上连续消费数据的，不要为了表面均衡把中间结果跨核搬运。流水并行有时比数据并行更划算，因为它减少了同层内的栅栏数量，把等待改成前后级错峰推进。多核不是切得越细越强，而是切得越顺数据流越强。

负载不均还要按最坏输入看。动态形状、稀疏输入和条件分支会让某些块天然比其他块更重，静态平均分配并不能保证运行时均衡。若调度器不支持细粒度偷取，最后一核拖尾几乎无法避免；若强行加入动态迁移，又可能把同步成本重新放大。工程上通常要在“均衡”与“稳定”之间找折中，而不是盲目追求核间百分百平均。

共享输出归并也要尽量后移到更粗粒度的边界，否则每一小块都做一次合流，等待时间会像利息一样在全图里层层累积。

定位多核瓶颈时，最好单独记录各核忙时、等待时、同步等待比例和跨核搬运量。若总利用率不低但吞吐仍差，多半不是核数不够，而是同步点过密。把这些指标同层级时间线叠在一起，才能看见真正的堵塞是出在分块、归并还是片上网络。

若某些层必须跨核共享同一权重块，还要确认广播路径是否可复用，否则每轮都重新分发同一块参数，等于把并行收益悄悄折回了片上传输税。

多核能否带来收益，决定因素往往不是核多，而是同步少。只要切分先服务于数据流连续性，NPU的多核能力才不会被自己制造的等待点反向拖慢。