Question 1

为什么更新后 stable-diffusion.cpp 在 AMD RDNA2 GPU（RX 6950 XT / Navi 21）上使用 Vulkan 时突然慢了约 7 倍？

Accepted Answer

这是 master-964 (1d0a58a) 中由 PR #2134 引入的已知回归问题，该 PR 会自动选择直接卷积（implicit GEMM）。在 RDNA2 上，独立的逐算子探测会错误地选择 implicit-GEMM 的 conv2d/conv3d，导致端到端生成速度下降约 7 倍（例如，SDXL 512x512、20 步时从 10.9 秒增至 73.4 秒）。有两种修复方式：(1) 针对 master-964 的临时解决方案：在命令行中添加 `--conv-direct off` —— 这可以恢复甚至超越回归前的速度（9.5 秒，而 master-959 上为 10.9 秒）。(2) 永久修复：升级到 master-968 (8cd731e) 或更高版本 —— PR #2141 使自动选择真正对直接卷积进行基准测试，现在会在 RDNA2 上拒绝使用它，因此默认构建无需任何标志即可恢复快速。注意：这与 flash attention 无关；在此硬件上 `--flash-attn auto -> off` 的判定是正确的。

Question 2

如何修复 Windows 上 ROCm VAE 编码过程中出现的 0xC0000005 ACCESS_VIOLATION 崩溃（stable-diffusion.cpp）？

Accepted Answer

崩溃是由 sd-cli.exe 从 C:\Windows\System32 加载了一个过时的 amdhip64_7.dll 导致的——这是之前 AMD 驱动程序安装遗留下来的残留文件。较新的 ROCm/HIP DLL 安装在不同的路径下,但 Windows 会优先选取 System32 中的旧副本,导致 VAE encode 图在 ROCm 后端上运行的那一刻发生访问冲突。

修复/解决方法:将最新 AMD 驱动程序安装中的 amdhip64_7.dll 复制到与 sd-cli.exe(或 sd.exe)相同的目录中。本地目录在 DLL 搜索顺序中具有优先级,可强制加载正确的版本。AMD 已确认并复现了该问题,预计将在未来的驱动程序版本中修复过时 DLL 的清理问题。

替代方案:将 VAE 路由到 Vulkan 而非 ROCm,例如 --backend llm=cpu,vae=Vulkan1,diffusion=Vulkan1,这样可以完全避开 HIP 路径并成功完成。

Question 3

如何修复在 stable-diffusion.cpp 中使用 TAEHV VAE 切换 LoRA 时出现黑色图像和服务器崩溃（exit code 139）的问题？

Accepted Answer

这是 stable-diffusion.cpp 旧版本构建（例如 commit db99efd）在 Vulkan 后端上的一个已知回归问题：在首次成功生成图像后，更改 LoRA 配置（添加/移除 LoRA 或调整其权重）会产生完全黑色的图像，且下一次生成会导致服务器因 SIGSEGV 崩溃（退出代码 139）。该问题已由 PR #1872 修复，该 PR 修正了使用 TAEHV/TAESD 时 VAE 计算缓冲区的清理问题。解决方案：将 stable-diffusion.cpp 更新到包含该修复的构建版本——commit de298c2 或更新版本（已在 95ff762 和 fd21ecf 上确认可正常工作）。如果使用 Docker，请拉取最新镜像，例如：`docker pull ghcr.io/leejet/stable-diffusion.cpp:master-vulkan`。更新后，LoRA 权重更改可正确生效，服务器不再崩溃。

Question 4

stable-diffusion.cpp 是否支持 FLUX.3 Image Klein（Black Forest Labs）？

Accepted Answer

是的。FLUX.3 Image Klein 的首日支持已通过 PR #2143 添加。该实现覆盖了新架构：三流 double blocks（image、image_cond、txt），各流具有独立的 modulation，single blocks 中采用分离的 q/k/v projection，`ref_time_in` flow-map 时间步输入（无 CFG），以及 theta 为 10000 的 4 轴 RoPE。VAE（`AutoencoderKLFlux2`）和 Qwen3-VL 文本编码器沿用自现有的 FLUX.2 支持，但文本编码器会拼接来自 8 层（4、8、……、32）的 hidden states。采样方面，蒸馏模型使用 16 步，scheduler shift 为 6.93（基础模型：50 步，guidance 为 3.5）。请更新到包含 #2143 的构建版本，并使用来自受限 HF 仓库 `black-forest-labs/flux-3-image-klein` 的 checkpoint。

Question 5

如何修复在 OCuLink eGPU 上使用 ROCm 并启用 --stream-layers 时出现的步速极慢（825s/it）和黑屏输出问题？

Accepted Answer

速度变慢的原因是 `--stream-layers`（PR #1576）本身没有异步预取流水线：在使用 `--params-backend diffusion=cpu` 时，完整的约 16GB Q6_K 权重会在每一步通过约 6.5 GB/s 的 OCuLink（PCIe 4.0 x4）链路被串行地重新加载，而对 210 个块的反复加载会使 HIP 驱动性能退化，导致单步速度慢 20 倍并输出黑屏画面。修复方法：升级到包含 PR #1905 的构建版本，然后添加预取标志，使权重传输与计算重叠进行：

```
./sd-cli --stream-layers --layer-prefetch-depth 1 --resident-layers <N> --params-backend diffusion=cpu ...
```

`--layer-prefetch-depth 1` 会在计算期间预取下一层，从而隐藏 OCuLink 传输延迟；`--resident-layers` 用于限制滚动常驻窗口的大小，以适配显存容量（例如配合 `--max-vram ROCm0=23` 使用）。注意：报告者已关闭此 issue，理由是在最近的构建版本中已无法复现，因此只需更新到最新的 master 二进制文件即可解决该问题。

stable-diffusion.cpp

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐