动态形状进入NPU前，先定内存上界与缓存身份

输入长度可变，并不意味着部署时可以不设边界。把动态形状模型交给NPU前，应明确最大运行形状如何约束内存，以及已编译产物凭什么可以再次使用，否则容量故障与版本误配会在上线后集中暴露。

有界动态维度允许编译器在一定范围内推导张量大小，但内存预算应针对同时存活的张量，而不能只看输入最大尺寸。一个含残差连接的网络，早期结果需要保留到后续相加，期间其他临时张量也可能同时存在。若规划器为每个缓冲区预留上界大小，并依据生命周期复用空间，最终需求由张量尺寸和存活重叠共同决定。把所有张量最大值相加可能过于保守，只取其中最大张量又可能严重低估。

形状关系也必须进入推导。例如两个输入在模型中要求相同序列长度，分别声明相同的数值范围，并不能自动表达二者每次都相等。导出契约需要记录共享符号或等价约束，让编译器验证拼接、广播和矩阵乘法的条件。前端能够导出动态维度，也不保证目标后端支持对应的运行形状；遇到根据输入内容决定输出长度的算子，更不能只按输入维度的上下界推断其全部分配行为。

选择上界时，不能将历史观测最大值直接当成业务允许最大值。应由协议、产品规则或显式截断策略给出边界，并在入口检查；超界请求要明确拒绝或进入经过验证的替代路径。为了降低过度预留，可将常见长度分成若干档，各档单独规划，但档位增加会扩大产物数量和常驻开销。测试应覆盖上界、下界、档位切换及约束不成立的输入，确认失败发生在可控入口，而非设备执行中的越界访问。对于高度相关的多个维度，还应确认所取最坏组合是否真正可达。若约束不允许各维度同时取最大值，独立上界相乘虽然安全，却可能造成不必要的常驻空间浪费。

另一类风险来自编译产物缓存。缓存文件保存的通常是针对特定后端配置生成的可执行表示，不是脱离工具链和设备的通用模型。相同文件名不代表权重、形状约束和编译选项仍然一致；不同驱动或编译器版本也可能改变产物格式和可用指令。若应用只按模型名称查缓存，更新权重后仍可能读到旧产物，表现为新版本部署成功但输出行为没有相应变化。

因此，NPU缓存身份至少需要覆盖模型内容、相关形状约束、影响代码生成的选项，以及平台要求的兼容信息。具体哪些字段由运行时自动管理，应以工具链文档为准；应用不能绕过其校验强行导入未知来源的二进制。OpenVINO的设备文档也明确提示，编译产物跨不同软件版本不保证兼容。若缓存导入失败，应回到受控的重新编译流程，而不是吞掉错误继续使用无法确认身份的旧文件。

缓存生成还应有完整性边界。多个进程同时首次启动时，可先写入各自临时文件，完成校验后再原子发布，或采用运行时提供的并发管理，避免读取半成品。缓存命中率只反映复用机会，不能代替正确性检查；应在产物旁保留可核验的身份信息，并用固定样本进行导入后的基本回归。容量规划也要覆盖冷启动期间的编译内存，因为稳态执行所需空间较小，并不意味着首次部署也能装下。

可变输入的部署契约应同时规定空间边界与产物身份。先让形状约束可验证，再让缓存复用有依据，才能把动态执行从试运行能力变成可维护的工程路径。