Question 1

アップデート後、AMD RDNA2 GPU（RX 6950 XT / Navi 21）でVulkanを使用したstable-diffusion.cppが突然約7倍遅くなるのはなぜですか？

Accepted Answer

これは PR #2134 によって master-964 (1d0a58a) で導入された既知のリグレッションで、direct convolution (implicit GEMM) を自動選択するものです。RDNA2 では、独立した per-op プローブが誤って implicit-GEMM の conv2d/conv3d を選択してしまい、エンドツーエンドの生成が約 7 倍遅くなります (例: SDXL 512x512、20 ステップで 10.9s -> 73.4s)。修正方法は 2 つあります。(1) master-964 での回避策: コマンドラインに `--conv-direct off` を追加してください — これによりリグレッション前の速度が回復し、それを上回る性能さえ得られます (master-959 の 10.9s に対し 9.5s)。(2) 恒久的な修正: master-968 (8cd731e) 以降にアップグレードしてください — PR #2141 により自動選択が direct convolution を実際にベンチマークするようになり、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 を読み込むことが原因で発生します。この DLL は以前の AMD ドライバーインストールの残存物です。新しい ROCm/HIP DLL は別のパスにインストールされていますが、Windows は System32 にある古いコピーを先に選択するため、VAE エンコードグラフが ROCm バックエンドで実行された瞬間にアクセス違反が発生します。

修正/回避策: 最新の AMD ドライバーインストールから amdhip64_7.dll を sd-cli.exe（または sd.exe）と同じディレクトリにコピーしてください。ローカルディレクトリは DLL 検索順序で優先されるため、正しいバージョンが強制的に読み込まれます。AMD はこの問題を確認・再現しており、将来のドライバーリリースで古い DLL のクリーンアップが修正される見込みです。

代替案: VAE を ROCm ではなく Vulkan にルーティングします。例: --backend llm=cpu,vae=Vulkan1,diffusion=Vulkan1。これにより HIP パスを完全に回避し、正常に完了します。

Question 3

stable-diffusion.cppでTAEHV VAEを使用時にLoRAを変更すると黒い画像とサーバークラッシュ(exit code 139)が発生する問題を修正する方法は?

Accepted Answer

これは、stable-diffusion.cppの古いビルド（例：コミット db99efd）のVulkanバックエンドにおける既知のリグレッションです。最初の生成が成功した後、LoRA設定（LoRAの追加・削除、またはその重みの調整）を変更すると、完全に真っ黒な画像が生成され、次の生成でサーバーがSIGSEGV（終了コード139）でクラッシュします。これはPR #1872で修正され、TAEHV/TAESDが使用される際のVAE計算バッファのクリーンアップが修正されました。解決方法：修正を含むビルド、すなわちコミット de298c2以降にstable-diffusion.cppを更新してください（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 により追加されました。この実装は新しいアーキテクチャに対応しています: ストリームごとのモジュレーションを備えた3ストリームのダブルブロック(image、image_cond、txt)、シングルブロック内の独立した q/k/v 射影、`ref_time_in` フローマップのタイムステップ入力(CFG なし)、および theta 10000 の4軸 RoPE です。VAE(`AutoencoderKLFlux2`)と Qwen3-VL テキストエンコーダーは既存の FLUX.2 サポートから再利用されていますが、テキストエンコーダーは8層(4、8、…、32)の隠れ状態を連結します。サンプリングでは、蒸留モデルはスケジューラーシフト 6.93 で16ステップを使用します(ベースモデル: 50ステップ、ガイダンス 3.5)。#2143 を含むビルドに更新し、ゲート付き HF リポジトリ `black-forest-labs/flux-3-image-klein` からチェックポイントを使用してください。

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` はローリング常駐ウィンドウをVRAMに収まるように制限します（例：`--max-vram ROCm0=23` と併用）。注意：報告者は最近のビルドでは再現しなくなったとしてこのissueをクローズしたため、単に最新のmasterバイナリに更新するだけで解決する可能性があります。

stable-diffusion.cpp

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト