​作者​昇腾实战派​知识地图​https://blog.csdn.net/Lumos_Lovegood/article/details/161601003问题描述当使用 TorchAir 进行图编译后模型性能相比单算子模式出现劣化且该问题在 warmup 阶段之后仍然持续存在性能表现不正常。定位思路通常情况下TorchAir 成图后的首次编译耗时较长但后续推理应获得加速收益。然而在本文所述问题中后续推理性能依然差最可能的原因是触发了重编译graph recompilation其耗时特征与编译过程高度吻合。定位步骤1. 检查 dynamic 参数配置对于动态 shape 场景如典型的语音模型若torch.compile参数配置为dynamicFalse例如torch.compile(model,dynamicFalse,backendnpu_backend)在该配置下编译时不支持动态 shape。当输入 shape 发生变化时Guards 机制会检测到编译函数发生变化从而触发重新捕获与编译即重编译导致性能异常劣化。2. 通过 profiling 采集确认在 profiling 数据中通过采集带有 stack 信息的数据可以观察到 TorchAir 相关的堆栈从而清晰判断是否发生了重编译。3. 日志分析最终手段在某些场景下即使开启了动态 shape 捕获模式仍可能因泛化能力不足而触发重编译。此时可通过开启 TorchAir Python 层日志获取更多信息importloggingimporttorch_npufromtorchairimportlogger# 设置 Debug 日志级别logger.setLevel(logging.DEBUG)也可以开启精简日志仅查看重编译相关的消息和原因exportTORCH_LOGSrecompiles在日志中搜索Recompiling function即可定位到具体触发重编译的代码行以及期望值与实际值的差异。如上图所示在 DiT 模型中tensor x size mismatch是触发重编译的具体原因。4. 修改与修复修复方案因模型结构而异需要结合具体模型进行分析。常见思路包括确保输入 shape 在编译时能够被泛化覆盖调整模型代码避免触发 Guards 检测到变化对于无法避免的动态 shape合理配置 dynamic 参数或使用更灵活的编译策略。