No module named ‘sageattention’

快速结论：该报错通常发生在使用 ComfyUI-WanVideoWrapper 自定义节点时，由于 PyTorch/HIP 缓存分配器在统一内存架构的 AMD APU（如 Strix Halo gfx1151）上不执行跨 Prompt 刷新，导致第二次运行显著变慢。优先通过 POST /free 手动释放内存来验证和临时解决。

问题场景

在 ComfyUI 中运行基于 ComfyUI-WanVideoWrapper（Kijai 开发的 WanVideo 封装节点）的工作流时，如 WanVideoWrapper I2V、A14B fp8、85 帧 @ 704×704、8 步等重量级任务。问题仅在 AMD Ryzen AI Max+ 395 / Strix Halo 等统一内存 APU 上复现，且无需加载特定的自定义节点即可触发（但核心问题已被确定为 WanVideoWrapper 的保留对象导致）。

报错原文

第二/后续 Prompt 运行速度约为首次的 2.4 倍慢（per-step s/it 从 ~38 min → ~87 min）。

注意：此 Issue 并未直接输出 “No module named ‘sageattention'” 报错，标题为《DynamicVRAM/caching allocator not flushed between prompts causes ~2.4x per-step slowdown on second queued run (gfx1151 / Strix Halo, ROCm)》。但如果您遇到的是模块缺失错误，请参考其他 Issue。

原因分析

经 Issue 作者后续深入测试确认，该降速问题并非 ComfyUI 核心导致，而是特定于 ComfyUI-WanVideoWrapper 自定义节点。核心 ComfyUI（如原生 SDXL 示例）的第二次运行速度与首次相同。但 WanVideoWrapper 在同一个进程中保留模型对象，导致其分配器状态在第二个 Prompt 中退化。手动 POST /free 后恢复速度，进一步证明是节点层的内存保留问题。

初始排查出的 PyTorch/HIP 缓存分配器行为（在统一内存 APU 上回收的内存布局不佳）可能是触发因素之一，但核心根因在 WanVideoWrapper 的跨 Prompt 对象复用。

环境排查

确认是否使用 AMD Strix Halo (gfx1151) 或类似统一内存 APU。
检查 ROCm 驱动版本是否正常。
确认 ComfyUI 版本（推荐最新）和 ComfyUI-WanVideoWrapper 节点版本（该节点已不再积极维护）。
检查 Python、PyTorch、CUDA 版本是否匹配硬件。
尝试使用原生 ComfyUI 工作流（如 SDXL 模板）运行两次，看是否出现同等问题——若没有，则可确认为 WanVideoWrapper 问题。

解决步骤

临时缓解（推荐优先尝试）：每次 Prompt 完成后，手动调用 POST /free 释放内存，使下一次运行恢复全速：
```
curl -X POST http://127.0.0.1:8188/free -H "Content-Type: application/json" -d '{"unload_models": true, "free_memory": true}'
```
也可在 ComfyUI 的 API 或工作流中实现自动化。
永久修复：建议将 Issue 提交至 ComfyUI-WanVideoWrapper 仓库，因为该问题已被确定为该节点的内部逻辑问题，非 ComfyUI 核心 Bug。
（可选）检查是否已启用 --highvram、--disable-smart-memory、--disable-dynamic-vram 等标志——这些在 Issue 中被证实无效，因为操作层级位于分配器之上。
（可选）如果使用 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True，注意这会导致首次运行也变慢，因此不是推荐方案。

验证方法

按 Issue 中的测试流程：启动 ComfyUI → 运行一次 WanVideoWrapper 工作流（记时） → 不重启直接再次运行同一工作流 → 观察第二次运行是否变慢 2.4 倍。
在两次运行之间执行 POST /free 命令后，第三次运行若恢复至首次速度，则说明问题已被临时缓解。
使用原生 SDXL 模板（无 WanVideoWrapper）在同一会话中运行两次，若速度无变化，则确认问题属于 WanVideoWrapper 而非 ComfyUI 核心。