​作者​：昇腾实战派
​知识地图​：https://blog.csdn.net/Lumos_Lovegood/article/details/161601003

问题描述

当使用 TorchAir 进行图编译后，模型性能相比单算子模式出现劣化，且该问题在 warmup 阶段之后仍然持续存在，性能表现不正常。

定位思路

通常情况下，TorchAir 成图后的首次编译耗时较长，但后续推理应获得加速收益。然而，在本文所述问题中，后续推理性能依然差，最可能的原因是触发了重编译（graph recompilation），其耗时特征与编译过程高度吻合。

定位步骤

1. 检查 dynamic 参数配置

对于动态 shape 场景（如典型的语音模型），若 torch.compile 参数配置为 dynamic=False，例如：

torch.compile(model, dynamic=False, backend=npu_backend)

在该配置下，编译时不支持动态 shape。当输入 shape 发生变化时，Guards 机制会检测到编译函数发生变化，从而触发重新捕获与编译，即重编译，导致性能异常劣化。

2. 通过 profiling 采集确认

在 profiling 数据中，通过采集带有 stack 信息的数据，可以观察到 TorchAir 相关的堆栈，从而清晰判断是否发生了重编译。

3. 日志分析（最终手段）

在某些场景下，即使开启了动态 shape 捕获模式，仍可能因泛化能力不足而触发重编译。此时可通过开启 TorchAir Python 层日志获取更多信息：

import logging
import torch_npu
from torchair import logger

# 设置 Debug 日志级别
logger.setLevel(logging.DEBUG)

也可以开启精简日志，仅查看重编译相关的消息和原因：

export TORCH_LOGS="recompiles"

在日志中搜索 "Recompiling function"，即可定位到具体触发重编译的代码行，以及期望值与实际值的差异。

如上图所示，在 DiT 模型中，tensor x size mismatch 是触发重编译的具体原因。

4. 修改与修复

修复方案因模型结构而异，需要结合具体模型进行分析。常见思路包括：

• 确保输入 shape 在编译时能够被泛化覆盖；
• 调整模型代码，避免触发 Guards 检测到变化；
• 对于无法避免的动态 shape，合理配置 dynamic 参数或使用更灵活的编译策略。