NPU动态图不是多几条分支，你知道吗

模型一旦从固定分辨率走向多尺寸输入，最先失稳的常不是算力，而是执行形状本身。NPU若把动态图只理解成“支持可变尺寸”，现场很快就会碰到重编译、缓存失配和内存计划同时抖动。

动态形状的难点不在分支数量，而在每次形状变化都会改写下游约束。卷积输出步幅、张量对齐、片上缓冲切块和 DMA 突发长度，都可能随着宽高变化而改变。若编译器只保存一份静态计划，新的输入一进来就得临时重排；若计划直接失效，运行时只能回退到重新建图或重新分配缓冲。平均吞吐看着还能接受，尾延迟却会在尺寸切换处突然拉长。

守卫条件设计不清，会把这种拉长放大。很多部署把“224 到 256 都算同类输入”写成宽松规则，结果某些层虽然形状仍落在范围里，片上块划分却已经跨过阈值，原有 schedule 不再适用。继续强行复用旧计划，轻则浪费片上空间，重则触发越界保护或隐式回退。真正可靠的守卫，必须绑定关键维度、步幅约束和对齐要求，而不是只看高宽数字是否接近。

内存计划失效往往比重编译更伤现场。因为重编译至少还能在日志里看见，缓冲计划失配却常常以“偶发慢帧”形式出现。某些节点会先尝试沿用旧的激活分配，再在中途发现某层放不下而临时申请外部内存；一旦张量从片上搬到主存，后续层的读写节奏全部被改写。这样单帧并不会立刻失败，但流水线已经从确定性执行退化成碰运气的内存调度。

更稳妥的办法，是先把可变形状桶化。把输入按若干离散尺寸域归类，为每个域单独生成编译缓存和内存计划，切换时只在少数稳定档位之间跳转，而不是让运行时面对几乎连续的形状空间。这样会牺牲一点理论灵活性，却能换来更清楚的最坏时延边界。对视频流，还可以在采集端先做有限裁剪，把大部分帧压到同一形状桶里。

编译缓存键也要足够完整。若缓存只按模型名和输入尺寸索引，却忽略量化档位、后处理开关或芯片子版本，命中的计划仍可能并不兼容。现场最棘手的是这种假命中不会立刻报错，只会在某个不常走的控制分支里暴露错误布局。缓存命中率高不代表稳定，命中的计划能否在当前前提下成立才是关键。

若平台还支持在线切换多模型，缓存池就不能只按单图规模配置，否则一个罕见尺寸临时进来，极易把常用档位挤掉，后面连续几帧都要重新建图。

排查这类问题时，不能只记录总推理时间，应把形状切换次数、重编译触发原因、内存计划回退次数和外部内存占比一起打出来。若慢帧总出现在少数分辨率或裁剪比例上，说明问题不在模型本身，而在形状治理策略。把这些计数与输入分布关联后，团队才能决定是继续放开动态图，还是退回受控桶化。

动态图支持真正有价值的前提，是形状变化被压缩成少量可管理的执行形状。只要守卫条件和内存计划先被说清，NPU才不会把灵活输入变成不可预测的慢路径。