你好，感谢您的反馈！我们会尽快分析问题并给出答复！
性能问题已记录。本 Issue 已标记为 performance。
初步分析：该 Issue 描述了 Wan2.2 TI2V 5B 场景下 ACLGraph 后端性能慢于非成图模式的问题。根据报告中的数据（383.9s vs 410.6s），性能回退约 7%。
根因分析：
- 当前 ACLGraph 仅对 transformer forward 做 capture/replay，外层 denoise loop 仍由 Python 驱动，每个 step 调用一次 graph replay，频繁切换带来额外开销。
- replay 前需要将动态输入 copy 到 static input buffer，copy 开销在多 step 场景下被放大。
- replay 前的全流同步（或 event 同步）破坏了异步流水，阻碍了计算与通信的 overlap。
- replay 后
safe_output_mode=True会 clone 输出，增加额外内存操作。 - 当前 ALGO=3 attention 已是 fused op，单算子下发开销占比有限，graph replay 节省的调度开销不足以抵消 copy/sync/clone 成本。
排查方向：
- 在 MindieSDBackend 中增加细粒度性能拆解日志，统计 input copy、graph replay、output clone、capture、cache hit/miss 等耗时。
- 对比完整 pipeline 成图（将 denoise loop 也纳入 capture）与当前仅 forward 成图的性能差异。
- 验证
safe_output_mode=False对精度和性能的影响，评估是否可在安全前提下关闭 clone。 - 检查 TASK_QUEUE_ENABLE=1 与 ACLGraph 的协同是否充分，是否还有 host 侧等待。
优化建议：
- 将 replay 前的同步改为更轻量的 event 同步（已部分验证有效，但收益有限）。
- 探索 static input buffer 的零拷贝或预分配策略，减少每 step 的 copy。
- 评估完整 pipeline 成图的可行性，将 denoise loop 纳入 capture 以消除 Python 层调度开销。
- 考虑在 high-step 场景中提供 ACLGraph 的自动 fallback 机制，当性能收益为负时回退到非成图模式。
建议提供：
- 性能基准数据（各阶段拆解耗时）
- 可复现的测试用例（含完整环境变量）
- 已尝试的优化手段及效果
关联分析：发现 PR #326 ([bugfix]aclgraph fix：clone static inputs in ACLGraph capture to prevent stale data_ptr precision issue) 可能与本 Issue 相关。
该 PR 状态：merged，目标分支：dev。
建议维护者确认关联关系，并评估是否已覆盖本 Issue 中描述的 copy/sync/clone 开销问题。
Bug 问题已收到，本 Issue 建议标记为 bug（ai-triaged）。
根因分析：根据标题推测，该问题可能与特定场景下的算子调用或资源管理有关。
排查方向：
- 收集完整的错误堆栈和日志。
- 确认环境版本（CANN、PyTorch、torch_npu）。
- 尝试最小化复现用例。
优化建议：请在评论中补充：错误日志、环境信息、复现步骤，以便进一步定位。
关联分析：发现 PR #369 ([Chore][docker]Rename omni image to mindiesd and switch tag to v3.0.0) 可能与本 Issue 相关。
该 PR 状态：open，目标分支：dev。
建议维护者确认关联关系。
如问题已解决，请关闭本 Issue；如需进一步排查，请补充上述信息。
Issue #188 (Performance):
性能问题已记录。本 Issue 已标记为 performance。
初步分析：
Wan2.2 TI2V 5B 场景下 NPUGraph/ACLGraph 性能收益不明显，瓶颈集中在 replay 阶段的 copy/sync/clone 操作。这通常意味着 graph capture 阶段记录的静态输入在执行时发生了数据拷贝或同步开销，导致 graph replay 的优势被抵消。
排查方向：
- 检查 ACLGraph 是否对静态输入执行了不必要的 clone 操作（PR #326 已修复此问题）。
- 确认输入张量的数据指针在 capture 和 replay 之间是否保持稳定。
- 评估是否可以通过
torch.npu的 stream 同步策略减少 sync 开销。
建议提供：
- 性能基准数据（graph 模式 vs eager 模式的端到端耗时、各阶段 breakdown）
- 可复现的测试脚本或模型配置
- 已尝试的优化手段（如调整 stream 数量、使用 NPUStream 等）
关联分析：
- 发现 PR #326 ([bugfix]aclgraph fix：clone static inputs in ACLGraph capture) 可能与本 Issue 相关。该 PR 状态：
merged，目标分支：dev。 - 发现 PR #334 ([Bugfix][Compilation]import mindiesd crashes with std::bad_alloc) 可能与本 Issue 相关。该 PR 状态：
merged，目标分支：dev。
建议维护者确认关联关系。
compile功能已优化，闭环关闭
NPUGraph/ACLGraph 在 Wan2.2 TI2V 场景下性能收益不明显
问题描述
当前 MindIE SD 已支持通过
MindieSDBackend接入torch.compile与torch.npu.NPUGraph。在 Wan2.2 TI2V 5B 场景中，可以通过--backend_mode aclgraph启用 NPUGraph/ACLGraph capture/replay。但实测发现，启用 ACLGraph 后端后，推理耗时高于非成图模式，未体现出预期的 graph replay 加速收益。
测试环境与配置
模型路径：
关键环境变量：
export ALGO=0 export TASK_QUEUE_ENABLE=1 export PYTORCH_NPU_ALLOC_CONF='expandable_segments:True' export CPU_AFFINITY_CONF=1 export TOKENIZERS_PARALLELISM=false export FAST_LAYERNORM=1推理参数：
对照方式：
# 非成图 python generate.py ... # 成图 python generate.py ... --backend_mode aclgraph测试结果
将 ACLGraph replay 前的全流同步从：
调整为 event 同步后，性能略有改善：
但仍慢于非成图模式。
初步分析
当前 ACLGraph 主要对 transformer forward 做 capture/replay，并非完整 pipeline 成图。外层 denoise loop 仍由 Python 驱动，每个 step 调用一次 graph replay。
在 Wan2.2 TI2V 场景中，ACLGraph replay 阶段存在以下额外开销：
safe_output_mode=True，会 clone 输出。ALGO=3attention 已是 fused op，单算子下发开销占比有限，graph replay 节省的调度开销不足以抵消 copy/sync/clone 成本。此外，
TASK_QUEUE_ENABLE=2与 NPU Graph capture 不兼容，成图时需要使用：export TASK_QUEUE_ENABLE=1否则会报错：
期望行为
希望优化 MindIE SD 的 NPUGraph/ACLGraph backend，使其在 Wan2.2 TI2V 等多 step diffusion transformer 场景中具备稳定性能收益，至少不慢于非成图模式。
建议优化方向
current_stream().synchronize()改为 event 同步。TASK_QUEUE_ENABLE=1。ALGO=0/1custom attention 路径的 stream capture 兼容性，避免出现：影响
当前 ACLGraph 功能可以启用，但在实际 Wan2.2 TI2V 5B 场景中性能低于非成图模式，可能影响用户对 NPUGraph 加速能力的使用预期。