[bug]: Still Crashing when i “Invoke” ROCm 7.1

快速结论：这个报错通常发生在 AMD ROCm 环境下使用 InvokeAI 的 SDXL 或 Z-Image-Turbo（ZIT）模型时，点击“Invoke”后在 VAE decode 阶段极慢甚至导致整个 Linux 系统崩溃重启；优先排查 VAE decode 阶段日志与 ROCm 驱动版本兼容性。

适用环境：InvokeAI v6.13.7（后续测试 v6.14.0-rc1），通过 Invoke Launcher 安装，操作系统为 Linux（Ubuntu 26 LTS），显卡为 AMD R9700 AI PRO（32 GB VRAM，RDNA 4 / ROCm），浏览器 FireFox。

最快修复方案：暂无确认的一步修复方案。Issue 中报告者在应用社区提供的环境变量与 invokeai.yaml 配置后，VAE decode 阶段依旧崩溃，问题在关闭时未确认解决。

注意事项：社区提到可通过 amdgpu.lockup_timeout 缓解整机冻结（见关联 Issue #9539），但该建议针对的是不同原因，且未在本 Issue 中验证；ROCm 在 InvokeAI 上的支持仍落后于 CUDA，官方维护者缺少 AMD 硬件，修复进度受限。请不要将社区配置当作官方结论。

问题场景

用户在 Ubuntu 26 LTS 上通过 Invoke Launcher 启动 InvokeAI v6.13.7，使用 AMD R9700 AI PRO（32 GB，ROCm）显卡。运行 SDXL 时生成速度远低于其 NVIDIA 3060 12 GB，运行 Z-Image-Turbo（ZIT）时在点击“Invoke”后直接崩溃并锁死整个操作系统。报告者随后测试 v6.14.0-rc1，发现 denoising 阶段变快，但 SDXL 与 ZIT 在 VAE decode 阶段仍然崩溃重启系统。

报错原文

[bug]: Still Crashing when i "Invoke" ROCm 7.1

Z image turbo completely crashes and locks up my UBUNTU system.
... either VERY slow, or crashes OS
... it is very slow during the VAE decode.. it is also where Invoke will crash and my OS restarts...
VAE DECODE still crashes system with SDXL and ZIT.

原因分析

根据维护者 @lstein 的追问，问题集中在 pipeline 的 VAE decode 阶段（而非 denoising 或 text encoding），因此可能与 InvokeAI 在 ROCm 上的 VAE decode 实现或显存管理相关。可能原因包括：
（1）ROCm 环境下的 VAE decode 显存占用或内核执行触发驱动级锁死，导致整机崩溃；
（2）ROCm 驱动版本（报告者提到从 7.2 升级到 7.14）与 PyTorch ROCm 构建不兼容，需在环境排查中确认；
（3）报告者升级到 v6.14.0-rc1 后 denoising 变快但 VAE decode 仍崩溃，说明 v6.14 的修复只覆盖了 denoising 部分速度问题，VAE decode 的崩溃属于另一个未解决根因。

环境排查

确认 InvokeAI 版本：报告者使用 v6.13.7，后续测试 v6.14.0-rc1；请在受影响的机器上记录实际版本。
确认 AMD 显卡型号与 ROCm 驱动版本：本 Issue 为 R9700 AI PRO，报告者提到 ROCm 7.2 → 7.14 的升级，需核对当前 rocm-smi 输出中的驱动版本。
确认 Python / PyTorch（ROCm 构建）版本：Issue 中未列出具体版本号，需在环境中自行核对 torch.__version__ 及是否匹配当前 ROCm。
确认崩溃发生在 pipeline 的哪一阶段：可通过观察 InvokeAI 服务端日志确认是否为 VAE decode 阶段，这是 @lstein 明确要求提供的关键信息。
确认 invokeai.yaml 中的 precision 与 attention_type 配置，社区建议为 bfloat16 + torch-sdp，但非官方结论。
确认内核参数 amdgpu.lockup_timeout：社区称默认被下调至 2 秒会导致整机冻结，建议恢复至约 10 秒，来源为关联 Issue #9539，与本 Issue 崩溃原因是否一致尚未验证。

解决步骤

先记录崩溃发生时所处阶段。崩溃时保留 InvokeAI 服务端日志的最后几行，重点确认是否为 VAE decode 阶段，这是维护者 @lstein 明确要求的排查证据。
升级到 v6.14.0-rc1 或更新版本，观察 denoising 阶段是否变快。报告者在 rc1 上确认 denoising 有改善，但 VAE decode 仍会崩溃，所以此步骤不能作为完整修复。
（可优先尝试，但本 Issue 未验证）按社区建议设置 ROCm 相关环境变量后启动 InvokeAI，例如 MIOPEN_FIND_MODE=2、MIGRAPHX_MLIR_USE_SPECIFIC_OPS=attention、FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE、FLASH_ATTENTION_TRITON_AMD_AUTOTUNE=FALSE、TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1、TORCH_BLAS_PREFER_HIPBLASLT=1、PYTORCH_HIP_ALLOC_CONF=garbage_collection_threshold:0.7,max_split_size_mb:256，并配合 --no-sandbox 启动 AppImage。报告者实测后仍会在 VAE decode 阶段崩溃系统。
（可优先尝试，但本 Issue 未验证）将 invokeai.yaml 设置为 precision: bfloat16 与 attention_type: torch-sdp，并保持 schema_version: 4.0.3。同样为社区建议，未在本 Issue 中解决崩溃。
（可优先尝试，但本 Issue 未验证）参照关联 Issue #9539，将内核参数 amdgpu.lockup_timeout 调回约 10 秒，用于缓解整机冻结；需修改 GRUB 内核启动参数并重启，属于系统级改动。
如果以上均无效，暂时使用 NVIDIA 显卡运行 InvokeAI，或者在 ComfyUI（Windows/ROCm）上处理 ZIT 等模型；报告者最终选择此路径。

验证方法

问题是否解决可以这样确认：在 AMD ROCm 环境下用 SDXL 或 ZIT 模型连续执行多次“Invoke”，观察 VAE decode 阶段是否能在不崩溃整机的情况下完成，并对比 denoising 与 VAE decode 的耗时变化。若提供崩溃时服务端日志的最后几行给维护者，也能协助确认崩溃是否已从 VAE decode 阶段消除。本 Issue 关闭时报告者仍未获得可用修复，因此上述步骤应以“尝试验证”而非“已修复”看待。